Slashdot Mirror
Native Windows PE File Loading on OS X?
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?"
please not - i don't need every windows malware able to run on my mac...
I don't think this is intended for Win32 compatibility. Apple has every reason not to do that, because it will mean there will be no more native versions of high-profile applications such as Photoshop. Adobe is probably already pissed off there won't be a 64-bit version of Carbon, which requires them to rewrite the entire UI of Photoshop in Cocoa to be able to release a 64-bit version of it. Giving them an easy way out by offering Win32 binary-level compatibility isn't in Apple's best interest there.
.NET platform for OS X.
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
Error: password can't contain reverse spelling of ancient Chinese emperor
wine is LGPL so apple maybe already is using wine.
preview button, my computer does't have any preview button
A recent article was talking about how much less reliable Leopard seems to be than Tiger.
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?
Paleotechnologist and connoisseur of pretty shiny things.
-b
myselfmusic
The most probable reason for Apple to have partial support for the PE executable format is EFI. Both the firmware itself and all of the drivers embedded within it use the PE object format.
/System/Library/CoreServices/boot.efi -- it has the same "This program cannot be run in DOS mode." at the beginning of the executable like every other PE executable.
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
The actual problem is resolving all external dependencies of Windows-bound binaries. If the Win32 API is somehow emulated (see Wine project for some "minor" details), this leaves (an ungodly mess of) COM interfaces. Then even if this is taken care of, Apple is going to be quite exposed to a legal beating from MS.
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.
3.243F6A8885A308D313
Try not to say the same thing twice in your subject, because that's redundant, which means you're saying the same thing twice and being redundant.
My grandmother used anecdotal evidence all the time, and she lived to be 120 years old.
That is not true. Anyone remember when IBM did this with OS/2? It killed the market for OS/2 software, because every developer just wrote for the lowest common denominator (Windows) instead of making "native" OS/2 software. Adding Windows application support in Mac OS X would kill the platform slowly.
This seems unlikely. Self-extracting zips are basically a standard zip file with an extractor .exe stuck on the front. Since the zip header is at the end of the file, there shouldn't be any need to parse the PE format (in fact, I don't think it'd help).
Our game middleware products load PE format binaries on GNU/Linux and MacOS. It's like 200 lines of code to load and fix up a DLL - not difficult at all.
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).
...there have also been plenty of complaints that the OSX version is buggy and doesn't run as well.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.
Plus how many people avoids becoming switchers because you can't run games?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.
When did they release a Mac version of Halo? What about Halflife?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?
I think Gruber had it right when he said that Apple wants its users to think of Windows as the new Classic, i.e. if Windows apps run inside Mac OS X, they should do so the way Mac OS 9 apps used to run inside OS X: With distinctly different windows, in a separate environment, and a bit glitchy. Users need to be reminded that running Windows apps is not the preferred choice, but merely a last resort.
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...
You can't read articles on censorship through the RSS feed. It's one of those clever meta jokes by the editors.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
Look how long it's taken for Webkit to go back into Konqueror...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.
...and don't even get me started on BSD/Darwin, whose policy seems to be "Open whenever we feel like it."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.
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 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.