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?"
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
Interesting. One of the major downsides to using OSX is that there isn't as much software available for it. If OSX were able to run windows executables natively (think Microsoft Office and games) that would be a major coup for Apple. Plus you wouldn't need to sit around hoping that WINE decides to support that application.
wine is LGPL so apple maybe already is using wine.
preview button, my computer does't have any preview button
> please not - i don't need every windows malware able to run on my mac...
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.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
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).
No shit it "works", but it is also incomplete. Certain types of articles don't make it into it. Most games articles won't for example, unless they also fit into another category that makes front page (like an article on game censorship that is also YRO).
So does anyone who actually read what I said have anything to say? Even if it is just showing solidarity in our dislike of slashdot's fucked up ways?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...
That's my bet too. EFI on IA64 runs Windows PE binaries (for IA64). EFI on X64 (which hasn't been implemented by many hardware manufacturers btw) runs Windows PE binaries.
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.
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.
"I've got more toys than Teruhisa Kitahara."
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. . .
I am a believer of momentum and curves.