Slashdot Log In
Native Windows PE File Loading on OS X?
Journal written by ozmanjusri (601766) and posted by
Zonk
on Sat Dec 01, 2007 05:25 PM
from the to-what-purpose-and-determination dept.
from the to-what-purpose-and-determination dept.
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?"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
noooo FP (Score:5, Insightful)
Re:noooo FP (Score:5, Interesting)
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.
Parent
Re:noooo FP (Score:5, Informative)
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.
Parent
Not for Win32 compatibility (Score:5, Interesting)
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
Re:Not for Win32 compatibility (Score:5, Interesting)
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.
I was just about to post this myself... It makes a lot of sense for Apple to support .NET on Mac OS X. For a start C# is now the flagship language for Windows development and not supporting it may be the difference between getting hundreds of ported apps and not getting them at all. As a Mac user and .NET developer I think it would be a big mistake for Apple to ignore .NET.
I wonder if this is how the sandboxed iPhone SDK, which is to be available in February, will be implemented
Parent
Re:Not for Win32 compatibility (Score:4, Insightful)
Parent
Re:Not for Win32 compatibility (Score:4, Interesting)
Even so, of course Photoshop should be rewritten for the new framework. After all, when a proprietary technology corporation decides to screw over their third-party developers and customers, isn't it the American Way to bear all the costs and keep paying them money?
Parent
Re:Not for Win32 compatibility (Score:5, Insightful)
No. The big selling points are what you can do with the Mac OS. Boot camp is more in the vein of removing a common barrier to a sale.
-jcr
Parent
Re:Not for Win32 compatibility (Score:5, Insightful)
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
Parent
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.
Parent
Re:Not for Win32 compatibility (Score:5, Insightful)
Parent
Re:Not for Win32 compatibility (Score:5, Funny)
Yeah, most of my pet spywares fail to run correctly under wine.
Parent
Re:Not for Win32 compatibility (Score:5, Informative)
You realise it's an open standard [wikipedia.org], do you? Hell, it's even ISO approved [iso.org].
Apple would gain a _lot_ by providing support for
Parent
Re:Not for Win32 compatibility (Score:5, Interesting)
Sure I can... a little.
Right now, the world's colleges and universities are churning out Java & C# programmers. Those are the popular languages, the ones for which you can almost literally open up a can of programmers for.
Not so with Objective C. It's even starting to get problematic to find competent C++ programmers.
Microsoft's seen the proverbial storm coming, and has been working on an alternative for their aging and clunky Win32 API. Remember a few years back, when the Redmontians announced that Vista (then called Longhorn) would only support
Meanwhile, Apple is tied to Objective C. A language few people are willing to learn (remember "Objectionable C"?). For very valid technical reasons, Apple is slowly moving its developer base over from C/C++-written Carbon apps to Cocoa apps written in Objective C. However, this makes it even harder for software vendors to find competent developers for their Mac OS X offerings.
So, enter
Is that enough of a quantification for you?
Parent
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.
Parent
Re:Not for Win32 compatibility (Score:5, Informative)
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 [dotnetdeve...ournal.com] that often compares
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
Parent
Re:Not for Win32 compatibility (Score:5, Interesting)
You fail to differentiate between .Net and C#. By and large, I criticize the former. I can see where you might get the wrong idea, though, so I'll elaborate.
The .Net framework suggests that the prototype for an event is as follows: "ret_type event( Object sender, EventArgs_subclass e )". Compare with a "typical" windows callback mechanism: "ret_type function( HWND hParam, WPARAM wParam, LPARAM lParam )". Suspiciously similar, neh? HWND corresponds to "Object sender", and the W- and L- PARAM objects are wrapped into EventArgs.
EventArgs and its sub-classes encapsulate all of the data given to a particular handler, much like W- and L- params, which changed meanings depending on call context. Some EventArgs subclasses also perform odd tasks, for instance the CancelEventArgs.Cancel [microsoft.com] property. This is the downright stupidest OOP implementation I've ever seen. Cancel is not data, it's an action. I don't want to specify the "cancelness" of the data, I want to cancel an operation. A better design would be to send a message back to the sending object that says, "I can't validate this." Unfortunately, because .Net event handlers use the ambiguous "object handle." I'd need a cast before I could send my response.
The complexity of implementing a cancel message is likely greater than CancelEventArgs, but the solution is far more intuitive. We don't even need to go as far as sending a message, though. Provide a real type to the sender argument (for instance, ICancelableControl, or just Control), and provide a Cancel method, and I'd be happy.
Performance is a shoddy argument for the lack of a message passing system, because .Net treats the event system as a messaging network anyway. AFAIAC, use events, but add more formality to the event system. Call your EventArgs what they are -- a message--and type the sending object appropriately. Finally, differentiate functioanlly between events and multicast delegates. Events should manage their subscription list; if an object subscribing to an event is garbage collected, fail silently. If the event lacks subscribers, then succeed.
And now for something completely different.
Everyone knows MSDN is a steaming pile of crap. What's worse, Microsoft seems to be doing very little to correct that image. IMHO, this is a mistake. As a developer, my first exposure to .Net is through MSDN--fundamentally, it's marketing for techies. It should be thorough, describing how components interact, typical real-world use cases for code, the history or motivation of a particular interface, etc. MSDN should serve the same function as an O'Reilly book--set a mood and mindset for development.
MS can spend as much money developing the perfect language as they want, but without the proper supporting tools--and don't get me started on the woes of VS--their efforts piss people off. This is precisely the motivation for the GGP's note that Objective-C developers are so "happy" and my "bullshit" post.
Parent
Hmm... (Score:4, Funny)
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?
Most likely there for EFI (Score:5, Informative)
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
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.
Running Windows apps natively would make no sense (Score:5, Interesting)
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...
Re:Watch out microsoft (Score:5, Funny)
-b
Parent
Re:Watch out microsoft (Score:5, Informative)
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.
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.
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?
Parent
Re:Win32 on OS X -- goodness (Score:5, Insightful)
Parent
Unlikely (Score:4, Informative)
Parent