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?"
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.
/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.
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
Dude, most X servers running on Linux, Solaris, *BSD and a host of other modern UNIX systems make liberal use of IPC, in the form of the MIT-SHM shared memory extension:
The basic capability provided is that of shared memory XImages. This is essentially a version of the ximage interface where the actual image data is stored in a shared memory segment, and thus need not be moved through the Xlib interprocess communication channel. For large images, use of this facility can result in some real performance increases.
Additionally, some implementations provide shared memory pixmaps. These are 2 dimensional arrays of pixels in a format specified by the X server, where the image data is stored in the shared memory segment. Through use of shared memory pixmaps, it is possible to change the contents of these pixmaps without using any Xlib routines at all.
This extension goes back nearly two decades. Yes, 20 years! Lower-end computers 20 years ago were able to use UNIX IPC, for high-performance graphics, in a very usable manner. There's no reason why a computer from today, especially a high-end Mac, couldn't effectively use shared memory in such a fashion. This is especially true on Mac OS X, which does offer the UNIX-like functionality that is required. Combined with the brilliant minds at Adobe (they hire a large number of the top Indian graduates each year), there's no reason why they couldn't get Photoshop working using such technology.
Uh, he means the image you're editing/viewing in your PhotoShop window. The overhead of passing "control" messages from a UI widget to a process are trivial. The overhead of passing large (uncachable) image data structures between processes isn't.
You realise it's an open standard, do you? Hell, it's even ISO approved.
Apple would gain a _lot_ by providing support for
Error: password can't contain reverse spelling of ancient Chinese emperor
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.
.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.
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
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
Physicists get Hadrons!
This seems unlikely. Self-extracting zips are basically a standard zip file with an extractor .exe stuck on the front. Since the zip header is at the end of the file, there shouldn't be any need to parse the PE format (in fact, I don't think it'd help).
Wonder no more; it won't be.
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.
...there have also been plenty of complaints that the OSX version is buggy and doesn't run as well.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.
Plus how many people avoids becoming switchers because you can't run games?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.
When did they release a Mac version of Halo? What about Halflife?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?
Objective-C is not quite as elegant as Smalltalk. In Smalltalk flow control structures (while loops, and so on) are part of the language and so you can add new ones as first class citizens. If you don't know Smalltalk, then you really should try it; you can't claim to understand object oriented programming until you understand Smalltalk.
I am TheRaven on Soylent News
I think you've probably misunderstood something. The LPGL doesn't mean that Apple would be free to hide its presence or source code or anything of the kind. It just means that it is allowed to link Wine into proprietary programs. They would still need to both inform the world that they have included Wine, and to provide its source code and a way to rebuild both Wine itself and any programs that would be linked statically against Wine. This is in contrast with the GPL only in the way that proprietary programs are not even allowed to link against GPL'ed code.
Any software Apple produces for Windows will probably be using this win-cocoa layer, particularly as carbon and any legacy carbon support they might have had in Windows is defunct. For everyone else there's GNUstep
You can't read articles on censorship through the RSS feed. It's one of those clever meta jokes by the editors.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
AFAIK, at WWDC 06 developers were told Carbon would have full 64 bit compatibility. This year at WWDC Apple said "nope, we changed our minds.". This is why many developers are mad. But, I'm with you still. It's been fairly obvious that Apple doesn't want to put more effort into Carbon than they have to and that it'll be losing support sooner rather than later.