Native Windows PE File Loading on OS X? 397
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?"
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
Watch out microsoft (Score:1, Interesting)
maybe OSX already have wine (Score:3, Interesting)
Re:Loading PE is not a big deal (Score:2, Interesting)
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.
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?
Re:Not for Win32 compatibility (Score:3, Interesting)
So why to the EULA's of MS's own apps forbid you from running them on non-MS operating systems?
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
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?
Re:Watch out microsoft (Score:3, Interesting)
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).
PE Loading on x86 is easy,,, (Score:4, Interesting)
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).
Re:Something to ponder (Score:3, Interesting)
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).
Re:Not for Win32 compatibility (Score:4, Interesting)
Re:Not for Win32 compatibility (Score:2, Interesting)
Re:Offtopic; Slashdot's fucked up RSS feeds (Score:1, Interesting)
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?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:Not for Win32 compatibility (Score:3, Interesting)
I'm sure that jumping on the Windows NT bandwagon looked like a good bet to Tandem, DEC, and SGI.
-jcr
Re:Most likely there for EFI (Score:3, Interesting)
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.
Re:noooo FP (Score:4, Interesting)
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.
Re:noooo FP (Score:3, Interesting)
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. . .
Re:Not for Win32 compatibility (Score:4, Interesting)
Adobe is pissed because it can't figure out how to squeeze more money out of a saturated market. Even though the design/print/pre-press market is large, it's finite and it's not growing much. Adobe has already sold everyone who wants or needs one a copy of Photoshop, and so they've been forced into release-constant-upgrades cycle to try and generate more revenue. So, I think Adobe's pissed they can't dump the print and pre-press market altogether and just move full scale into Flash, PDF and whatever other web technologies they can think of. And I think they're doubly pissed that, last I checked their annual report, about half the revenue from their print/design/pre-press sales come from the Apple world. So, instead of dumping that business, or spinning it off, they have to expend the time, money and effort to support two platforms. Adobe isn't pissed because of anything Apple's done. Adobe's pissed they can't dump their "legacy" apps and follow whatever will make them the most short-term profit, overall corporate health be damned.
Adobe hasn't been the same since Warnock and Company sold out and the bean counters took over. They're now a marketing company which happens to release some software from time to time. Their days as a company which produced technology which got you excited are long over.
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.
Re:Not for Win32 compatibility (Score:1, Interesting)