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...
UI includes showing the actual images. Sending them over IPC is certainly not wise from a performance standpoint.
Umm...one of Apple's biggest selling points for the Mac if you go into any store that sells one is that it can "still run all of your Windows stuff." They've changed architectures over to Intel-based PC's.
You have any special insight that would suggest why they _wouldn't_ want to be as compatible with Windows as possible, being that they're trying hard to convince people to switch? Why they wouldn't want a PC that can already run all of the Windows software on the shelves, without the painful experience of having to use Vista (which they reference more and more often in their commercials)? I think not.
Because if they did, customers could choose between machines that sorta run Windows applications (Macs) or machines that run Windows applications properly (PCs). As Wine proves, any reimplementation of the Win32 API is inevitably not going to be as good as the real thing.
Providing compatibility with Windows through VMWare or Parallels is a lot better in that respect. And if a virtual machine should fail, so what? It would only make Microsoft or the virtual machine maker look bad, not Apple.
Besides, as I said in my original post: I think the moment Apple starts offering integrated Win32 binary-level compatibility is the moment software vendors stop offering Mac-native applications. And that's the point where Apple might as well start bundling the current version of Windows with their systems.
Error: password can't contain reverse spelling of ancient Chinese emperor
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
one of Apple's biggest selling points for the Mac if you go into any store that sells one is that it can "still run all of your Windows stuff."
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
The only title of honor that a tyrant can grant is "Enemy of the State."
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.
I've only dabbled with Cocoa in order to learn Objective-C, but the whole thing seems super elegant, and Objective-C itself is SO much nicer to work with than Java - it's like C combined with Python (very dynamic). The class hierarchy is clean and not particularly deep. I don't know, I personally think moving to, say, Java for infrastructure would be a step backwards (and I say this as someone whose current contracts are all big Java projects). But that's just my opinion.
If I had mod points, you'd get them. This is a good point. There are a lot of .NET programmers out there, and anything to encourage coding for a platform has to be a good thing.
On the otherhand, I doubt this is the full story. I'd bet on "you can run your windows apps without running windows" before I'd bet on, ".NET programmers wanted, no Mac experience necessary."
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
The only title of honor that a tyrant can grant is "Enemy of the State."
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
Not right now, no. But it's half past twelve here. In the morning. And I'm writing posts in a language that's not my mother tongue. I'm actually amazed my posts are halfway coherent and readable.
But to get back on the subject, you probably want to see hard numbers regarding this. Well, there aren't any. Developing a platform has always and will always depend on guesses. That's because we're dealing with people here, who have those nasty undefinable things called "preferences". We can only guess what's going to work out, and what isn't.
And right now,
Error: password can't contain reverse spelling of ancient Chinese emperor
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.
As far as a layman is concerned, the former is more readable, but less understandable. I expect most formally educated programmers (meaning college) to prefer the latter. Why? A few reasons:
It's not perfect, though. I'd appreciate a few idioms from Objective-C to be "ported" to C#, particularly aspects of RTTI and message passing (functions, delegates, and events in C# are irritating). IMHO, it's far more elegant the Obj-C way.
I agree with your sentiment that Cocoa development is superior to .Net. My theory of why .Net sucks a nut, comparatively, is as follows:
I still prefer C# and .Net, as sick as that may sound. My background is heavily Java and C# based, which makes the Objective C environment is too clunky for me to like (The @'s, #'s, and XCode-IB code integration are painful). Apple tries to alleviate this by providing (admittedly, great) tools to manage that business, but it always comes off as applying gauze to a gaping chest wound.
btw, thanks for the link :)
--
* Quite frankly, I think both suck. I'd like a strange frankenstein syntax. "myObject <- [message_name arg1: xxx arg2: yyy];" It's more clear than either of the other two, IMHO. Until then, I'll take C-style. As a further aside, I dislike 'dot syntax' wholesale.
Q: Where do I go to buy OS X for my commodity PC?
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.
Conformity is the jailer of freedom and enemy of growth. -JFK
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.
In Repressive Burma, it's not just your connection that dies. slashdot.org/comments.pl?sid=314547&cid=20819199
Adopting Wine would have its limitations.
Being a hook for Parallels (as some have suggested) isn't super efficient (a whole virtual PC just to run Windows apps is a lot of overhead; Parallels is awesome, but I doubt Apple is catering specifically to them).
Emulating or copying in some form or other the hundreds of COM objects isn't practical either.
But what if they allowed you to pop in your XP (or Vista, ugh) CD, and do an install of XP right inside OS X (a bit Xen-like) and cross-launch apps seamlessly, sharing the file system (in a Crossover Office-like way). That would really rock. (Keeping the Windows apps appropriately sandboxed of course.) Crossover Office (and coLinux, to a degree) achieve inter-OS compatibility by leveraging actual OS code, with native hooks into the host operating system. When it works, it's far more efficient that emulating an entire machine.
The more I think about it, the more I'm hoping that will be their approach.
If they can have XP (or Vista, once again, ugh) run, properly licensed, inside/alongside OS X seamlessly, it would bring people to Apple in droves. The switch to X86, allowing people to bail to Windows if their "switch" didn't work, and the efficiency of Parallels on an X86 platform (no emulation of every instruction), truly won over a lot of people to the Mac camp, myself included. This final step would be a major coup, and a natural final step in helping people get away from dependency upon Windows as their sole operating system...
Keeping my fingers crossed...
Love many, trust a few, do harm to none.
Or when a 3rd paty developer has been cruising on old frameworks for years, never committing themselves to an upgrade because the so-called "proprietary technology corporation" might be out of business soon. Honestly, Adobe should have seen this coming years ago, but instead they just decidd not to do any real development work on the Mac.
Apple sell complete systems...
A bundle of hardware and software designed to work properly together. That's a big selling point, no hassle with drivers, no hardware conflicts etc.
Windows could never provide the same level of integration unless microsoft start producing hardware against (remember the jazz platform?) and linux could but would really need the hardware maker to roll their own distro.
The only other place you get good integration between hardware and software, is at the high end.. Think z/OS, Solaris/Sparc, AIX etc
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
A barrier to sale is "why not", a selling point is "why".
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.