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.
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.
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."
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.
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
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!
Partly I think this is because Apple relies upon secrecy in order to be competitive against MS's offerings so they don't like people looking at their codebase for future releases, unlike most OSS projects. They tend to wait until they have a project completely and ready to go before they let anyone outside Apple know it exists, which often means they've reworked code for a year and the original projects has a massive load of work dumped upon them at once.
Look how long it's taken for Webkit to go back into Konqueror...That is actually a good example, although a bit clouded by all the nonsense people posted about it, when they had no idea what they're talking about. For some fairly obvious for business reasons Apple could not have let slip to MS they were working on their own browser, lest MS retaliate by canceling IE before it is ready, or introducing a lock-in into IE in some way. When Apple did release the code, they did not well document the evolution of their version. Someone commented on this in a forum and suddenly all sorts of people were claiming Apple was screwing over the Konquerer team, or intentionally obfuscating things, or violating the spirit of the license. Of course at that point, no one had asked anyone at Apple for a better breakdown and when someone did, the guys working at Apple went out of their way to help make things easier for them to re-integrate into KHTML. Mind you, because the Konquerer team was not happy with some of the design decisions Apple had made, they delayed implementing most of them. They had been used to being the only ones contributing and were not used to dealing with major contributions from other coders. Lately, they've come around with Apple and several other making regular contributions (something the Konquerer guys consider the best thing to come out of Apple's adoption) and they're moving to merging the WebKit and KHTML branches back together since Apple's contributions are more useful than the inconvenience caused by Apple's architectural decisions. The delay in getting Apple's changes incorporated, however, can't really be blamed on Apple, more than a few days, for the most part it was a conscious decision by the Konquerer developers.
...and don't even get me started on BSD/Darwin, whose policy seems to be "Open whenever we feel like it."Credit where credit is due, the BSD license does not require Apple to release their changes at all, so doing so on a delayed timetable is still a lot better than most vendors.
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 doubt it. Why do you suppose Apple publishes the Darwin source or any of the other low-level technologies they code (ZeroConf, LaunchD, etc.). They publish them because they actually see the business case for sharing the work with other companies and gaining wider adoption of said technologies. Windows API re-implementations fit in that same category. If possible, Apple would try to share the load with other players. Realistically, I think they would be prevented from using WINE because of their license to MS's code nor do I think they have a lot interest in such a project.