Native Windows PE File Loading on OS X? 397
ozmanjusri writes "Coders working on Wine for Mac have found that the Mac loader has gained its own undocumented ability to load and understand Windows Portable Executable (PE) files. They found PE loading capabilities in Leopard that weren't there in Tiger. Further dissection showed that Apple is masking references to 'Win' and 'PE' in the dll, which means it's not an accidental inclusion. Is Apple planning native PE execution within OS X?"
noooo FP (Score:5, Insightful)
Re:noooo FP (Score:5, Interesting)
Except windows malware is just that: malware written for Windows. While it could potentially run, malware wouldn't automatically become a problem. You'd have a much easier time accidently running OS X malware than Windows malware. Think of it as WINE for OS X (which is apparently exactly what it is or will be except Jaguar can load the binaries itself). People running Windows binaries via WINE on Linux don't experience the same problems with malware because the expected security flaws in the underlying OS and/or applications aren't there.
In short, if Apple plans to implement a built-in WINE-like ability to run some Windows binaries in OS X, there is no reason to suspect it will cause a breeding ground for Windows malware. Malware only has the opportunity to run if it can somehow get installed.
Re: (Score:2, Offtopic)
Save the stereotypes for Digg, please.
Re:noooo FP (Score:5, Informative)
Apple? NIH?!? Umm, the BSD subsystem, Webkit from KDE, OpenStep from Next, BeOS bits recreated, MAC from TrustedBSD, PDF as the basis for their display from Adobe, dtrace from Solaris, Apache, CalDav from Oracle... I could go on.
Apple might avoid the WINE codebase, but only because they have rights to much of an older version of the Windows API directly from having won a lawsuit against MS quite a while ago when MS stole their code. I don't think Apple would otherwise have a problem supporting WINE and I would not be surprised if Apple employees have submitted code to WINE or one of the offshoot projects. I think, however, they're probably content with the current ease of running Windows apps, inconvenient enough that not many mainstream developers can ignore OS X, but easy enough so that businesses are not put off and people are not afraid of trying OS X as their primary OS. I would not be surprised, actually, if this feature was added at the request of Parallels, whose latest RC supports making Windows apps the default for opening filetypes in OS X (which will launch the VM and open the file in the specified application.
Re:noooo FP (Score:4, Interesting)
Apple might even license Win32 code from Microsoft.
There's writing on a lot of walls for Microsoft.
The EU legal settlement will eventually, despite the bitter fighting, force them to open their APIs to anyone.
They're facing an onslaught of low-end Linux machines like Asus Eee PC and the Walmart $199 box. So far, their response has been to lower the price of Windows below $40 for Eee PC owners. That's going to be hard to sustain when other buyers balk at paying three times Asus' price.
Vista won't drive any new sales, and looks losing anyone who was waiting for a sign from above.
Essentially, all MS has left to sell on the OS front is compatibility with the enormous back-catalogue of Windows applications.
Being able to sell Win32/FX as an API pack to other OS vendors might be a way out for MS. The future of computing looks like hypervisors and VMs anyway. Most tech savvy people already run Windows in a VM on their preferred OS (or vice versa) already.
Selling a portable API would just be going with the flow.
Re: (Score:3, Interesting)
Webkit isn't "from KDE". Apple started with KHTML and went from there, but saying "WebKit from KDE" sounds like they just copied it, which isn't at all true.
Quartz and its related technologies aren't based on PDF: they're original Apple technologies from the ground up. Some of Quartz correlates pretty closely to PDF, but they are not at all the same tech.
Just being pedantic. . .
It's not quite NIH (Score:3, Insightful)
What I find frustrating about Apple is their need to so tightly control every bit of code they borrow. Look how long it's taken for Webkit to go back into Konqueror... and don't even get me started on BSD/Darwin, whose policy seems to be "Open whenever we feel like it."
Thus, I suspect that, were Apple to include Wine, they'd fork it, improve it quite a lot (though largely in ways that can't easily be integrated back into Wine
Re:It's not quite NIH (Score:4, Insightful)
Partly I think this is because Apple relies upon secrecy in order to be competitive against MS's offerings so they don't like people looking at their codebase for future releases, unlike most OSS projects. They tend to wait until they have a project completely and ready to go before they let anyone outside Apple know it exists, which often means they've reworked code for a year and the original projects has a massive load of work dumped upon them at once.
That is actually a good example, although a bit clouded by all the nonsense people posted about it, when they had no idea what they're talking about. For some fairly obvious for business reasons Apple could not have let slip to MS they were working on their own browser, lest MS retaliate by canceling IE before it is ready, or introducing a lock-in into IE in some way. When Apple did release the code, they did not well document the evolution of their version. Someone commented on this in a forum and suddenly all sorts of people were claiming Apple was screwing over the Konquerer team, or intentionally obfuscating things, or violating the spirit of the license. Of course at that point, no one had asked anyone at Apple for a better breakdown and when someone did, the guys working at Apple went out of their way to help make things easier for them to re-integrate into KHTML. Mind you, because the Konquerer team was not happy with some of the design decisions Apple had made, they delayed implementing most of them. They had been used to being the only ones contributing and were not used to dealing with major contributions from other coders. Lately, they've come around with Apple and several other making regular contributions (something the Konquerer guys consider the best thing to come out of Apple's adoption) and they're moving to merging the WebKit and KHTML branches back together since Apple's contributions are more useful than the inconvenience caused by Apple's architectural decisions. The delay in getting Apple's changes incorporated, however, can't really be blamed on Apple, more than a few days, for the most part it was a conscious decision by the Konquerer developers.
Credit where credit is due, the BSD license does not require Apple to release their changes at all, so doing so on a delayed timetable is still a lot better than most vendors.
I doubt it. Why do you suppose Apple publishes the Darwin source or any of the other low-level technologies they code (ZeroConf, LaunchD, etc.). They publish them because they actually see the business case for sharing the work with other companies and gaining wider adoption of said technologies. Windows API re-implementations fit in that same category. If possible, Apple would try to share the load with other players. Realistically, I think they would be prevented from using WINE because of their license to MS's code nor do I think they have a lot interest in such a project.
Re: (Score:3, Informative)
Not for Win32 compatibility (Score:5, Interesting)
However, consider that the PE file format is also used by Microsoft's Common Language Runtime (CLR/.NET). Therefore, I think this is a preparatory move to start offering a native implementation of the
Re: (Score:2)
May take some engineering, but it seems like it could be possible.
Re:Not for Win32 compatibility (Score:4, Insightful)
Re: (Score:3, Informative)
The basic capability provided is that of shared memory XImages. This is essentially a version of the ximage interface where the actual image data is stored in a shared memory segment, and thus need not be moved through the Xlib interprocess communication channel. For large images, use of this facility can result in some real performance incr
Re:Not for Win32 compatibility (Score:4, Interesting)
Even so, of course Photoshop should be rewritten for the new framework. After all, when a proprietary technology corporation decides to screw over their third-party developers and customers, isn't it the American Way to bear all the costs and keep paying them money?
Re: (Score:2, Interesting)
Re: (Score:3, Informative)
Re: (Score:2, Insightful)
You have any special insight that would suggest why they _wouldn't_ want to be as compatible with Windows as possible, being that they're trying hard to convince people to switch? Why they wouldn't want a PC that can already run all of the Windows software on the shelves, without the painful experience of
Re: (Score:3, Insightful)
Because if they did, customers could choose between machines that sorta run Windows applications (Macs) or machines that run Windows applications properly (PCs). As Wine proves, any reimplementation of the Win32 API is inevitably not going to be as good as the real thing.
Providing compatibility with Windows through VMWare or Parall
Re:Not for Win32 compatibility (Score:5, Funny)
Yeah, most of my pet spywares fail to run correctly under wine.
Comment removed (Score:5, Insightful)
Re: (Score:2)
Boot Camp/VMWare/etc helps to sell computers, so to Apple its a good thing.
Re:Not for Win32 compatibility (Score:4, Interesting)
Re:Not for Win32 compatibility (Score:5, Insightful)
A: I don't.
Mac OS, iTunes, the iTunes Music store, etc exist for one purpose: to sell Macs, iPhones, iPods, etc. The software simply isn't where the company makes the money. The old regime almost bankrupted Apple by switching to a Microsoft-like software licensing model... so I doubt that Apple would go back to that.
Not at all Microsoft-like (Score:3, Insightful)
No, the experiment with Mac clones was not at all Microsoft-like. Microsoft makes money every time Dell ships a PC with Windows installed, and Apple lost money every time Power Computing shipped a clone with Mac OS 8 installed.
The reason is pretty simple. Apple should have priced OS licenses such that it wouldn't matter to its bottom line whether the hardware had been made by Apple or a cloner. The price of an
Re:Not for Win32 compatibility (Score:5, Insightful)
Re:Not for Win32 compatibility (Score:4, Insightful)
A bundle of hardware and software designed to work properly together. That's a big selling point, no hassle with drivers, no hardware conflicts etc.
Windows could never provide the same level of integration unless microsoft start producing hardware against (remember the jazz platform?) and linux could but would really need the hardware maker to roll their own distro.
The only other place you get good integration between hardware and software, is at the high end.. Think z/OS, Solaris/Sparc, AIX etc
Comment removed (Score:5, Insightful)
How could it be for Win32 compatibility (Score:2)
Re: (Score:2)
So they've got support in the loader, and perhaps some future version of MacOS X will have WINE-alike code for the API and syscalls (or a
Re: (Score:2)
Re:Not for Win32 compatibility (Score:5, Informative)
You realise it's an open standard [wikipedia.org], do you? Hell, it's even ISO approved [iso.org].
Apple would gain a _lot_ by providing support for
Re: (Score:3, Insightful)
On the otherhand, I doubt this is the full story. I'd bet on "you can run your windows apps without running windows" before I'd bet on, ".NET programmers wanted, no Mac experience necessary."
Re: (Score:2)
Apple doesn't have a mature enough sales force or market stability to aim at the enterprise markets that
Re: (Score:2)
Re:Not for Win32 compatibility (Score:5, Interesting)
Sure I can... a little.
Right now, the world's colleges and universities are churning out Java & C# programmers. Those are the popular languages, the ones for which you can almost literally open up a can of programmers for.
Not so with Objective C. It's even starting to get problematic to find competent C++ programmers.
Microsoft's seen the proverbial storm coming, and has been working on an alternative for their aging and clunky Win32 API. Remember a few years back, when the Redmontians announced that Vista (then called Longhorn) would only support
Meanwhile, Apple is tied to Objective C. A language few people are willing to learn (remember "Objectionable C"?). For very valid technical reasons, Apple is slowly moving its developer base over from C/C++-written Carbon apps to Cocoa apps written in Objective C. However, this makes it even harder for software vendors to find competent developers for their Mac OS X offerings.
So, enter
Is that enough of a quantification for you?
Re:Not for Win32 compatibility (Score:5, Insightful)
Instead, Apple is offering Python and Ruby Objective-C bridges, and that makes a lot more sense. They've got bridging support for arbitrary scripting languages into the Objective-C runtime, enabling web developers to write native Mac OS X applications using native APIs. Whatever Apple does with respect to additional language support in the future, you can bet Objective-C will be a part of it. The language allows for a lot of dynamism and flexibility, and on top of that, it's a strict C superset, which means that there are no special wrappers required to call down to the POSIX layer. So it's just easy to bridge other languages with it.
At the end of the day, Objective-C just doesn't get the credit it deserves. It's a very well thought-out language with lots of power. Most people just don't see it because they think Objective-C is Apple's "proprietary" language or some such nonsense.
Re: (Score:2)
Re: (Score:2)
Universities doesn't just churn out Java & C# developers. At least not in copenhagen
I've only had two courses that had specific language requirements for assignments was "Functional programming" (ML) and "Object Oriented Programming & Design" (JAVA).
You don't learn to master a language - they are just a tool. You learn how to pick the right tool. (That includes knowing what it does and how it's different).
Re: (Score:2)
Do you even know what "quantification" means?
"churning out" "popular" "a can of" "a few years back" "a language few people are willing to learn" "slowly" "makes it even harder" "reasonably fast (getting faster)" "plenty of mindshare" "most importantly" "isn't much" "simply an additional one"
You do realize those are all quantitative expressions, right?
Re:Not for Win32 compatibility (Score:4, Insightful)
Not right now, no. But it's half past twelve here. In the morning. And I'm writing posts in a language that's not my mother tongue. I'm actually amazed my posts are halfway coherent and readable.
But to get back on the subject, you probably want to see hard numbers regarding this. Well, there aren't any. Developing a platform has always and will always depend on guesses. That's because we're dealing with people here, who have those nasty undefinable things called "preferences". We can only guess what's going to work out, and what isn't.
And right now,
Re: (Score:3, Interesting)
I'm sure that jumping on the Windows NT bandwagon looked like a good bet to Tandem, DEC, and SGI.
-jcr
Re: (Score:2)
I don't necessarily agree. If a student who only learned Java in school has to learn Objective-C, he has to learn to deal with more or less manual memory management. This is simply not a concept a lot of people can grasp, and it takes a lot of experience to get decent at debugging memory errors and keeping track of what's going on under th
Re: (Score:2)
Objective-C 2.0 has garbage collection, so that's not really an issue anymore. Regardless memory management isn't conceptually that difficult. Pointers to a Cocoa programmer for all intent and purpose are the same as references. It's only in C that pointers are a big deal, think pointer arithmetic.
I definitely disagree here. Objective-C is fairly easy language to pick up, but master? No way.
Okay, you're probably right. I think I meant "reasonably productive."
Re: (Score:3, Interesting)
So why to the EULA's of MS's own apps forbid you from running them on non-MS operating systems?
Re: (Score:2)
This is all just wild speculation. I'd personally love it if Apple replaced its aging Cocoa/Objective-C/XCode infrastructure with something more modern like
Re: (Score:3, Insightful)
I'd personally love it if Apple replaced its aging Cocoa/Objective-C/XCode infrastructure with something more modern like .NET or Java, but I don't think it's going to happen anytime soon.
Well, Apple has cut loose the Java bindings to Cocoa, so I guess you're right.
I've only dabbled with Cocoa in order to learn Objective-C, but the whole thing seems super elegant, and Objective-C itself is SO much nicer to work with than Java - it's like C combined with Python (very dynamic). The class hierarchy is clean and not particularly deep. I don't know, I personally think moving to, say, Java for infrastructure would be a step backwards (and I say this as someone whose current contracts are all big
Re: (Score:3, Informative)
it's like C combined with Python
Ugh, you make it sound hideous. Objective-C is C combined with Smalltalk. It's not quite as elegant as C combined with Self would be, but it's quite close. The Smalltalk philosophy is very different from Python. Python piles a load of badly thought-out crap into the language and makes something that's a third rate OO language, a second rate procedural language and a fourth rate functional language. Smalltalk aims to make the language almost as small as possible an implements everything at the library
Re:Not for Win32 compatibility (Score:5, Informative)
I've said it before, and I'll say it again now: Objective C is exactly at the sweet spot for a computer language - it has all the power of C (it's a formal superset), the nice features of a true object-orientated language (OOP, garbage collection, protocols, etc.), adds in dynamic dispatch (thus removing the need for generics), and does it all by adding about a dozen commands to the C language. The only thing against it is the unfamiliar (to C/C++ programmers) syntax. Really, though, how hard is it to make the mental leap to [myObject insertObject:xxx atPosition:yyy] from myObject->insertObjectAtPosition(xxx,yyy) ? And which is the more readable ?
Plus, the class library is *very* well designed. It makes easy things easy, and hard things possible. A lot of hard things are pretty easy too... There's a site [dotnetdeve...ournal.com] that often compares
Objective C is a classic example of how a simple clear approach can reap huge rewards in terms of usability and flexibility. It's not the over-designed bloat-fest that is C++ (template metaprogramming ? Really ?), and it's not the raw pedal-to-the-metal-hear-the-engine-scream-in-protest of plain old C. I've never yet met anyone give it a fair try (ie: write a real program in it) and not end up loving the language.
Simon
Re: (Score:2)
Re: (Score:3, Insightful)
As far as a layman is concerned, the former is more readable, but less understandable. I expect most formally educated programmers (meaning college) to prefer the latter. Why? A few reasons:
Re:Not for Win32 compatibility (Score:5, Interesting)
You fail to differentiate between .Net and C#. By and large, I criticize the former. I can see where you might get the wrong idea, though, so I'll elaborate.
The .Net framework suggests that the prototype for an event is as follows: "ret_type event( Object sender, EventArgs_subclass e )". Compare with a "typical" windows callback mechanism: "ret_type function( HWND hParam, WPARAM wParam, LPARAM lParam )". Suspiciously similar, neh? HWND corresponds to "Object sender", and the W- and L- PARAM objects are wrapped into EventArgs.
EventArgs and its sub-classes encapsulate all of the data given to a particular handler, much like W- and L- params, which changed meanings depending on call context. Some EventArgs subclasses also perform odd tasks, for instance the CancelEventArgs.Cancel [microsoft.com] property. This is the downright stupidest OOP implementation I've ever seen. Cancel is not data, it's an action. I don't want to specify the "cancelness" of the data, I want to cancel an operation. A better design would be to send a message back to the sending object that says, "I can't validate this." Unfortunately, because .Net event handlers use the ambiguous "object handle." I'd need a cast before I could send my response.
The complexity of implementing a cancel message is likely greater than CancelEventArgs, but the solution is far more intuitive. We don't even need to go as far as sending a message, though. Provide a real type to the sender argument (for instance, ICancelableControl, or just Control), and provide a Cancel method, and I'd be happy.
Performance is a shoddy argument for the lack of a message passing system, because .Net treats the event system as a messaging network anyway. AFAIAC, use events, but add more formality to the event system. Call your EventArgs what they are -- a message--and type the sending object appropriately. Finally, differentiate functioanlly between events and multicast delegates. Events should manage their subscription list; if an object subscribing to an event is garbage collected, fail silently. If the event lacks subscribers, then succeed.
And now for something completely different.
Everyone knows MSDN is a steaming pile of crap. What's worse, Microsoft seems to be doing very little to correct that image. IMHO, this is a mistake. As a developer, my first exposure to .Net is through MSDN--fundamentally, it's marketing for techies. It should be thorough, describing how components interact, typical real-world use cases for code, the history or motivation of a particular interface, etc. MSDN should serve the same function as an O'Reilly book--set a mood and mindset for development.
MS can spend as much money developing the perfect language as they want, but without the proper supporting tools--and don't get me started on the woes of VS--their efforts piss people off. This is precisely the motivation for the GGP's note that Objective-C developers are so "happy" and my "bullshit" post.
Re: (Score:2)
Adobe? Please. (Score:2)
Re:Not for Win32 compatibility (Score:5, Interesting)
However, consider that the PE file format is also used by Microsoft's Common Language Runtime (CLR/.NET). Therefore, I think this is a preparatory move to start offering a native implementation of the .NET platform for OS X.
I was just about to post this myself... It makes a lot of sense for Apple to support .NET on Mac OS X. For a start C# is now the flagship language for Windows development and not supporting it may be the difference between getting hundreds of ported apps and not getting them at all. As a Mac user and .NET developer I think it would be a big mistake for Apple to ignore .NET.
I wonder if this is how the sandboxed iPhone SDK, which is to be available in February, will be implemented
Re: (Score:2)
I think you're right about the intention of PE format giving
Re:Not for Win32 compatibility (Score:4, Interesting)
Adobe is pissed because it can't figure out how to squeeze more money out of a saturated market. Even though the design/print/pre-press market is large, it's finite and it's not growing much. Adobe has already sold everyone who wants or needs one a copy of Photoshop, and so they've been forced into release-constant-upgrades cycle to try and generate more revenue. So, I think Adobe's pissed they can't dump the print and pre-press market altogether and just move full scale into Flash, PDF and whatever other web technologies they can think of. And I think they're doubly pissed that, last I checked their annual report, about half the revenue from their print/design/pre-press sales come from the Apple world. So, instead of dumping that business, or spinning it off, they have to expend the time, money and effort to support two platforms. Adobe isn't pissed because of anything Apple's done. Adobe's pissed they can't dump their "legacy" apps and follow whatever will make them the most short-term profit, overall corporate health be damned.
Adobe hasn't been the same since Warnock and Company sold out and the bean counters took over. They're now a marketing company which happens to release some software from time to time. Their days as a company which produced technology which got you excited are long over.
Win32 on OS X -- goodness (Score:2)
Re:Win32 on OS X -- goodness (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3, Insightful)
maybe OSX already have wine (Score:3, Interesting)
Re: maybe OSX already have wine (Score:3, Informative)
Hmm... (Score:4, Funny)
Now we find out that Leopard has some Windows compatibility. Maybe they're just making it bug-for-bug compatible?
How long until we hear Apple take up the "it's-not-a-bug-it's-a-feature" line?
More compatible than Vista (Score:2, Offtopic)
I'm no fan of OSX, but nor am I a fan of Vista. Unpopular as the view is I don't think Linux is "ready for the desktop" either. SO I'm going to be one of these sad people that clings to XP for as long as they can. The bottom line is I can't stand Vista for its restrictions (Microsoft has been behaving very badly in the last couple of years) and I can't stand OSX because I've suffered badly many years ago due to Apple's tactics and
Re: (Score:2)
Re: (Score:2)
I think if you get screwed over by a company you should learn from it. Apple does dubious things even now. Like crippling iTunes. I also had to babysit an eMac at work a few years ago and saw it die horribly within a month (motherboard died), then
Re: (Score:2)
Re: (Score:2)
Most likely there for EFI (Score:5, Informative)
If they want to natively host EFI development and not use Windows to do it, then some level PE support is required.
Just take a look at
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
I, for one, griped at Intel about EFI the first time we tried to do any useful automation on Itanium with it -- EFI is glorified DOS, except without any of the useful tools available for DOS. Intel would have been miles ahead if the would have made a linux BIOS/preboot environment instead.
Loading PE is not a big deal (Score:5, Insightful)
Lastly, "Is Apple planning native PE execution within OSX?" - if they were _planning_ that, they wouldn't include this into a production release of the OS. This means that it's already used for something. The big question is what exactly.
Re: (Score:2, Interesting)
That, or they implemented the support in such a way that conditional compilation (using #ifdefs) was significantly more complicated and bug-prone than just leaving it in and not documenting it. If you've ever written a C program that had to behave differently on different platforms, you've doubtlessly run
Re: (Score:3, Insightful)
It's common to include "unused" code and undocumented interfaces in an OS, especially if they are benign.
For example, Quartz 2D Extreme (QuartzGL) has been available since 10.4 was released, and it's still disabled, and enabling it is not officially supported as it may cause stability issues. Yet they did
PE Loading on x86 is easy,,, (Score:4, Interesting)
The two wins are that we have one binary on all x86 platforms (which usually means testing on one platform is sufficient) and that the MS compiler generates faster binaries. The downside is that when you *do* have to debug on the non-native platforms, you must resort to printf-style debugging.
You also have to replace the default MS crt, because they make a lot of Win32 calls that you don't want to have to emulate. We just have a tiny OS layer for memory, file IO, threading, audio, and video that is native (about 30 functions).
Running Windows apps natively would make no sense (Score:5, Interesting)
The idea is to tell users "Yeah, you can run your Windows apps using Parallels or VMWare if you really have to, but if you can, we'd much rather you ran real Mac applications." Running Windows apps quasi-natively by implementing the APIs would send the wrong message; it would put Windows apps on the same or a similar level as Mac apps. That's a bad thing: The Mac relies on Mac-only or "better on Macs" applications; the high quality of software is one of the Mac's selling point. If developers could write Windows apps and they would run on Macs just fine, hey, why not write Windows apps and have five or ten times the market at no additional cost?
Of course, I'd personally love to see something like this; Office for Macs is about to lose support for Macros, so I'll probably have to run Office in Parallels, soon. Come to think of it... Maybe that's Apple's way of fixing Microsoft's Macro Mistake? Maybe the idea is to let Windows Office run natively on Macs?
Anyway, Apple's actions have been extremely hard to predict recently, so I'm not ruling out anything. Maybe they are indeed going to give the Windows APIs the Carbon treatment...
On what fantasy planet do you live on? (Score:2)
Re: (Score:2)
And that's coming from the WINE guys. To be honest, I'm not a Windows guy so I don't know that much about the ins and outs of the licensing, but I don't think it's that absurd if the WINE people are legitimately suspicious that they're adding some form of WIN32 capability. Maybe you can enlighten me on why that would be impossible for Apple to do, but WINE can get away with it?
The sheer amount of work. (Score:2)
Keep in mind most of the software they release is acquired through purchase or license and then revamped and maintained. Not that they don't make a lot of changes and improvements, but I don't see them making a Win32 subsystem from scratch.
But I _can_ see them taking the ECMA standard and adding support for the more advanced features in WinForms w/Cocoa bindings and stuff, thus creating a nifty ecosystem of cross-platform software, a native Silve
Re: (Score:3, Funny)
Re: (Score:2)
Re:Watch out microsoft (Score:5, Funny)
-b
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
From who? Most of the people I know who have used both say that Mac Office 2004 is better than Office 2003 for Windows (and they think that makes no sense and they don't get what the hell is wrong with Microsoft).
Re:Watch out microsoft (Score:5, Informative)
Umm, I've mostly heard complaints that the Windows version is buggier actually. There is plenty of software that is badly ported or not available on OS X, but you picked a crappy example. Of course it cuts both ways, since iTunes on Windows is pretty crappy by comparison, and you can't get OmniGraffle at all.
Some, but not as many as most people on Slashdot probably think. The hardcore gamer market is not as large as it is vocal. The casual gamer has a several year old machine and by the time they own one that can play a given game, most of them (especially outside the hardcore market) are ported to OS X. The top 10 games in a given year account for about half of game sales, and the last time I checked, 8 out of 10 had been ported within a year.
That's where a lot of people are misled. Most gamers could not run Halo on their machine for years, even if the owned a PC. And what most people care about is The Sims. In fact, if you look at the list of top selling games of all time, according to wikipedia you have:
Do you see how the average, gamer who is not hardcore would not be too perturbed by the lack of choice?
Re: (Score:2)
Re: (Score:2)
The popularity of Parallels and VMWare Fusion is boggling because there really isn't that much of
Re: (Score:2)
Re: (Score:2)
However, compatibility with specific programs is trickier. The sole reason that I use VMWare is to run Microsoft Access (among the worst database apps I've ever had to use, though to be fair I do think the 2007 version actually managed to be an improvement). But
Re: (Score:2)
isn't as much software available? (Score:3, Funny)
Re: (Score:2)
Malware's not much of an issue (Score:3, Insightful)
Unlikely (Score:4, Informative)
Re: (Score:3, Interesting)
Why would anyone cry that? If Microsoft started doing that folks would mostly be too busy being shocked, because it would primarily benefit Apple: Developers could write software natively for OSX using Objective C, Cocoa, and (otherwise) Apple's native toolkit, and be able to still target Microsoft's audience, rather than writing only for the lone larger-audience pr
Re: (Score:3, Informative)
Developers could write software natively for OSX using Objective C, Cocoa, and (otherwise) Apple's native toolkit, and be able to still target Microsoft's audience, rather than writing only for the lone larger-audience proprietary platform and leaving Apple's userbase unable to run their software.
Back to the future! NeXT did exactly that in a previous life, after their hardware business dried up, as OPENSTEP [wikipedia.org].
Any software Apple produces for Windows will probably be using this win-cocoa layer, particularly as carbon and any legacy carbon support they might have had in Windows is defunct. For everyone else there's GNUstep [gnustep.org]
Re: (Score:2)