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?"

Comments

noooo FP

[Anonymous Coward]

please not - i don't need every windows malware able to run on my mac...

Re:noooo FP

[onefriedrice]

> 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.

Re:noooo FP

[99BottlesOfBeerInMyF]

The trouble is they have NIH and so won't just work with the wine project.

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.

Not for Win32 compatibility

[SigILL]

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.

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.

Re:Not for Win32 compatibility

[Marcos Eliziario]

"As Wine proves, any reimplementation of the Win32 API is inevitably not going to be as good as the real thing."

Yeah, most of my pet spywares fail to run correctly under wine.

Re:Not for Win32 compatibility

[SigILL]

Not likely. Apple's not about to sign up to support a Microsoft API on OS X.

You realise it's an open standard, do you? Hell, it's even ISO approved.

Apple would gain a _lot_ by providing support for .NET, without losing much.

Re:Not for Win32 compatibility

[jcr]

Mind telling me what the difference is between a selling point and removing a barrier to sale, exactly?

A selling point is a reason why a product is superior to another product. A barrier to sale is a reason why a customer might be bound to stay with a different product.

You don't buy a Mac because it can run a windows app, since the cheap shit from Dell will do that, too. You buy the Mac for the things that it offers over and above what the Dell box can do.

-jcr

Re:Not for Win32 compatibility

[Space cowboy]

I'd personally hate it if they gave up the beautiful elegance that is ObjC and forced Apple developers to move to Java or .NET.

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 that often compares .NET and ObjC/Cocoa. It frequently (despite the obvious potential bias given the name of the site) argues that the ObjC method for doing something is better thought out, more elegant, or simply more capable than the corresponding .NET approach.

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:Not for Win32 compatibility

[The One and Only]

Apple isn't a hardware company or a software company. They're a systems company. They sell a complete system that they put together. The hardware might have an Intel CPU, an nVidia graphics card or a Marvell WiFi controller, and the software might have a Mach kernel, a KDE-derived web browser, or a GNU compiler, but you don't have to invent your own kitchen sink or air conditioner to build a great house, either.

Re:Watch out microsoft

[g0at]

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. Eh? Did you copy/paste this from a discussion five years ago?

-b

Most likely there for EFI

[dpokorny]

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.

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 /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.

Loading PE is not a big deal

[apankrat]

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.

Re:Win32 on OS X -- goodness

[Anonymous Coward]

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.