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.
The Mac equivalent of Win32's WriteProcessMemory requires your program to be setgid procmod, so essentially you'd need Administrator access. This probably makes Mac malware considerably more difficult to make than on other platforms. Even Linux lets programs ptrace each other on all by the strictest of SELinux modes. Also, on Linux, a lot more machines have GDB installed, so malware could pipe to it when SELinux does interfere. Few Mac users have GDB installed.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
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).
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).
Breakfast served all day!
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).
After all, it's not the general consensus that Microsoft's platform is hurting for good software. (I'm pretty unhappy with software availability on Windows, but I'm not exactly your general audience -- and I recognize that; even then, it's not OSX-specific software that I miss when working on win32, but nifty, Freely licensed POSIX-centric toolage like pexpect).
...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...
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
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;
Disclaimer: I didn't even read grandparent, and your post seems reasonable enough.
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.
Don't thank God, thank a doctor!
You've got it. Jumping on a microsoft bandwagon is a very bad business decision, as any company who signed up for "plays for sure" now knows.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
The old regime almost bankrupted Apple by switching to a Microsoft-like software licensing model
:(
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
That that is is that that that that is not is not.