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:Not for Win32 compatibility (Score:4, Insightful)
Re:Not for Win32 compatibility (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 having to use Vista (which they reference more and more often in their commercials)? I think not.
Re:Not for Win32 compatibility (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 Parallels is a lot better in that respect. And if a virtual machine should fail, so what? It would only make Microsoft or the virtual machine maker look bad, not Apple.
Besides, as I said in my original post: I think the moment Apple starts offering integrated Win32 binary-level compatibility is the moment software vendors stop offering Mac-native applications. And that's the point where Apple might as well start bundling the current version of Windows with their systems.
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.
Comment removed (Score:5, Insightful)
Re:Win32 on OS X -- goodness (Score:5, Insightful)
Re:Not for Win32 compatibility (Score:3, Insightful)
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 Java projects). But that's just my opinion.
Re:Not for Win32 compatibility (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."
Comment removed (Score:5, Insightful)
Malware's not much of an issue (Score:3, Insightful)
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: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:Not for Win32 compatibility (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:
It's not perfect, though. I'd appreciate a few idioms from Objective-C to be "ported" to C#, particularly aspects of RTTI and message passing (functions, delegates, and events in C# are irritating). IMHO, it's far more elegant the Obj-C way.
I agree with your sentiment that Cocoa development is superior to .Net. My theory of why .Net sucks a nut, comparatively, is as follows:
I still prefer C# and .Net, as sick as that may sound. My background is heavily Java and C# based, which makes the Objective C environment is too clunky for me to like (The @'s, #'s, and XCode-IB code integration are painful). Apple tries to alleviate this by providing (admittedly, great) tools to manage that business, but it always comes off as applying gauze to a gaping chest wound.
btw, thanks for the link :)
--
* Quite frankly, I think both suck. I'd like a strange frankenstein syntax. "myObject <- [message_name arg1: xxx arg2: yyy];" It's more clear than either of the other two, IMHO. Until then, I'll take C-style. As a further aside, I dislike 'dot syntax' wholesale.
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.
Re:Not for Win32 compatibility (Score:5, Insightful)
One possibility: Xen-like co-install (Score:2, Insightful)
Being a hook for Parallels (as some have suggested) isn't super efficient (a whole virtual PC just to run Windows apps is a lot of overhead; Parallels is awesome, but I doubt Apple is catering specifically to them).
Emulating or copying in some form or other the hundreds of COM objects isn't practical either.
But what if they allowed you to pop in your XP (or Vista, ugh) CD, and do an install of XP right inside OS X (a bit Xen-like) and cross-launch apps seamlessly, sharing the file system (in a Crossover Office-like way). That would really rock. (Keeping the Windows apps appropriately sandboxed of course.) Crossover Office (and coLinux, to a degree) achieve inter-OS compatibility by leveraging actual OS code, with native hooks into the host operating system. When it works, it's far more efficient that emulating an entire machine.
The more I think about it, the more I'm hoping that will be their approach.
If they can have XP (or Vista, once again, ugh) run, properly licensed, inside/alongside OS X seamlessly, it would bring people to Apple in droves. The switch to X86, allowing people to bail to Windows if their "switch" didn't work, and the efficiency of Parallels on an X86 platform (no emulation of every instruction), truly won over a lot of people to the Mac camp, myself included. This final step would be a major coup, and a natural final step in helping people get away from dependency upon Windows as their sole operating system...
Keeping my fingers crossed...
Re:Not for Win32 compatibility (Score:1, 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
Re:Not for Win32 compatibility (Score:1, Insightful)
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), assuming they didn't just fork Crossover, Cedega, or the newest version of Wine that's not LGPL'd. I don't know who to blame for this situation, actually -- it seems like Apple is not playing nice with others, yet with all the code there (well, most of the time), it seems like the projects which got forked could be re-integrating a lot of Apple improvements a lot faster.
Comment removed (Score:3, Insightful)
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:Loading PE is not a big deal (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 not simply compile it out, but left it in as an undocumented option.
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 OS license was initially set too low, perhaps out of optimism about the extent to which Apple's hardware sales would be cannibalized. When sales turned out to be cannibalized quite a bit, instead of adjusting to the circumstances, Apple simply killed the cloning program