Forgot your password?
typodupeerror
OS X Operating Systems Software Windows

Native Windows PE File Loading on OS X? 397

Posted by Zonk
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?"
This discussion has been archived. No new comments can be posted.

Native Windows PE File Loading on OSX?

Comments Filter:
  • noooo FP (Score:5, Insightful)

    by Anonymous Coward on Saturday December 01, 2007 @05:31PM (#21546949)
    please not - i don't need every windows malware able to run on my mac...
    • Re:noooo FP (Score:5, Interesting)

      by onefriedrice (1171917) on Saturday December 01, 2007 @06:32PM (#21547483)
      > please not - i don't need every windows malware able to run on my mac...

      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.
  • by SigILL (6475) on Saturday December 01, 2007 @05:32PM (#21546961) Homepage
    I don't think this is intended for Win32 compatibility. Apple has every reason not to do that, because it will mean there will be no more native versions of high-profile applications such as Photoshop. Adobe is probably already pissed off there won't be a 64-bit version of Carbon, which requires them to rewrite the entire UI of Photoshop in Cocoa to be able to release a 64-bit version of it. Giving them an easy way out by offering Win32 binary-level compatibility isn't in Apple's best interest there.

    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.
    • by smaddox (928261)
      Couldn't they just run the UI as 32bit and the actual algorithms as separate 64 bit processes?

      May take some engineering, but it seems like it could be possible.
      • by cnettel (836611) on Saturday December 01, 2007 @05:38PM (#21547025)
        UI includes showing the actual images. Sending them over IPC is certainly not wise from a performance standpoint.
        • Re: (Score:3, Informative)

          by Anonymous Coward
          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 [reptiles.org] 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 incr
    • Re: (Score:2, Insightful)

      by Anonymous Coward
      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
      • Re: (Score:3, Insightful)

        by SigILL (6475)

        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?

        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 Parall

      • by jcr (53032) <[jcr] [at] [mac.com]> on Saturday December 01, 2007 @05:59PM (#21547239) Journal
        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

        • Remember that Mac is a hardware company. The ultimate goal of Apple is to sell hardware -- who gives a shit what you do with it. If anything, a customer using a Mac as an overpriced PC is a better customer that isn't going to need support for OSX, patches etc.

          Boot Camp/VMWare/etc helps to sell computers, so to Apple its a good thing.
          • by EveLibertine (847955) on Saturday December 01, 2007 @07:20PM (#21547817)
            bullhonky. Apple _was_ a hardware company. Since they started selling x86 pc's, the only way to distinguish them from any other pc out there is with their software. They are a software company when it comes down to it.
            • by duffbeer703 (177751) * on Saturday December 01, 2007 @08:36PM (#21548235)
              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.
              • 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
            • by The One and Only (691315) * <[ten.hclewlihp] [ta] [lihp]> on Saturday December 01, 2007 @10:30PM (#21548901) Homepage
              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.
          • by Bert64 (520050) <[moc.eeznerif.todhsals] [ta] [treb]> on Sunday December 02, 2007 @08:48AM (#21551171) Homepage
            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
    • I don't understand how this could be for Win32 compatibility. Just being able to load the PE executable format does not mean you can actually use anything in PE executables. It's required before anything else is done, sure, but it doesn't mean compatibility. Especially since you'd still need PE files to load. And then you'd need shims. Lots of shims. Just look at WINE, loading PEs doesn't seem to be a huge part of it. It could just be necessary support so a third party can finish the job (kind of like all t
      • by cduffy (652)
        As you say -- you'd need shims, and wrappers, and a whole lot more -- but none of those will work until you've got support in the loader.

        So they've got support in the loader, and perhaps some future version of MacOS X will have WINE-alike code for the API and syscalls (or a .NET CLR interpreter, if that's what they're going for). It's groundwork. If Apple never included parts of a feature until the whole thing was production status, there wouldn't be read-only ZFS support in OS X right now.
    • by jcr (53032)
      I think this is a preparatory move to start offering a native implementation of the .NET platform for OS X.

      Not likely. Apple's not about to sign up to support a Microsoft API on OS X. They very explicitly state that you're on your own if you run Windows with boot camp, for example. They don't supply a WMA plug-in for Quicktime (leaving that up to a third party), and they know better than to try going down that rathole.

      I think that recognizing PE files is all about EFI, and nothing more.

      -jcr
      • by SigILL (6475) on Saturday December 01, 2007 @06:02PM (#21547257) Homepage

        Not likely. Apple's not about to sign up to support a Microsoft API on OS X.

        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 .NET, without losing much.
        • Re: (Score:3, Insightful)

          by sjf (3790)
          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."
          • You're spot on.

            Apple doesn't have a mature enough sales force or market stability to aim at the enterprise markets that .Net is thriving in. I know of large Mac shops that are totally screwed right now because key features (like directory integration) that they absolutely need simply don't work in Leopard at the moment. Apple was kind enough to ship hundreds of Leopard only computers that will be useless for months.
        • by jcr (53032)
          You realise it's an open standard, do you?

          So what?

          Apple would gain a _lot_ by providing support for .NET, without losing much.

          Can you quantify this supposed gain? Do you have any idea of what the costs of support it would be?

          Didn't think so.

          -jcr
          • by SigILL (6475) on Saturday December 01, 2007 @06:42PM (#21547557) Homepage

            Can you quantify this supposed gain?

            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 .NET programs natively? Back then the world evidently wasn't ready for it. But it's slowly becoming ready, because it's getting harder and harder to find competent C++ programmers.

            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 .NET. It's reasonably fast (getting faster), it has plenty of mindshare, and most importantly: there isn't much in the way of a legacy code base for it. Supporting .NET doesn't mean hurting your own APIs, its simply an additional one.

            Is that enough of a quantification for you?
            • by Durandal64 (658649) on Saturday December 01, 2007 @07:49PM (#21547955)

              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.
              Having the "dime a dozen" crowd develop for your platform isn't without its drawbacks. I hear a lot of comments from Windows converts saying that the Mac indy developer scene is smaller than Windows, but the software is almost always of much higher quality and polish. When you make it easy to develop for your platform, you attract lots of developers (good), but the signal-to-noise ratio drops significantly (bad).

              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 .NET programs natively? Back then the world evidently wasn't ready for it. But it's slowly becoming ready, because it's getting harder and harder to find competent C++ programmers.
              Based on what I've heard from Windows developers, Microsoft needed a good Win32 replacement because Win32 sucked. I've seen some Win32 code; it's not pretty, and the way the UI code connects to what's happening on the screen is a complete mystery to me. When I learned Cocoa and Objective-C, the connections were intuitive and obvious.

              Meanwhile, Apple is tied to Objective C. A language few people are willing to learn (remember "Objectionable C"?).
              I'm sure that'll change in February of 2008. Then lots of people will probably be interested in learning Objective-C.

              So, enter .NET. It's reasonably fast (getting faster), it has plenty of mindshare, and most importantly: there isn't much in the way of a legacy code base for it. Supporting .NET doesn't mean hurting your own APIs, its simply an additional one.
              Apple tried that kind of thing before with the Java/Cocoa bridge. It's now been deprecated because it was a pain in the ass to maintain, and no one was using it. A .Net bridge would require that Apple map all the .Net standard classes to their own. They might be able to do toll-free bridging to underlying CoreFoundation types (like dictionaries, strings, etc ...), but I don't know if C# supports the kind of dynamic typing that makes it possible through the C/Objective-C combination. I suspect it does. But it'd still be a lot of work.

              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.
            • I agree with you but I would like to add how I feel it's ridiculous that people can't program stuff outside of Java and C# because of colleges teaching it. I am a college freshman and I am learning everything in Java but I'm confident I could translate the ideas to other languages if I were to learn the syntax. But then again, I'm actually interested in computers and have been since 8th grade, some people I feel just major in compsci with no real interest in it. But what are you really learning if you can'
            • by KeyserDK (301544)
              A bit offtopic...

              Universities doesn't just churn out Java & C# developers. At least not in copenhagen :)

              I've only had two courses that had specific language requirements for assignments was "Functional programming" (ML) and "Object Oriented Programming & Design" (JAVA).
              You don't learn to master a language - they are just a tool. You learn how to pick the right tool. (That includes knowing what it does and how it's different).
        • Re: (Score:3, Interesting)

          by turgid (580780)

          So why to the EULA's of MS's own apps forbid you from running them on non-MS operating systems?

    • by samkass (174571)
      PE is also the format for EFI, which Apple uses. It could be a step towards a more powerful boot loader.

      This is all just wild speculation. I'd personally love it if Apple replaced its aging Cocoa/Objective-C/XCode infrastructure with something more modern like .NET or Java, but I don't think it's going to happen anytime soon.

      • Re: (Score:3, Insightful)

        by abigor (540274)

        I'd personally love it if Apple replaced its aging Cocoa/Objective-C/XCode infrastructure with something more modern like .NET or Java, but I don't think it's going to happen anytime soon.

        Well, Apple has cut loose the Java bindings to Cocoa, so I guess you're right.

        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

        • Re: (Score:3, Informative)

          by TheRaven64 (641858)

          it's like C combined with Python

          Ugh, you make it sound hideous. Objective-C is C combined with Smalltalk. It's not quite as elegant as C combined with Self would be, but it's quite close. The Smalltalk philosophy is very different from Python. Python piles a load of badly thought-out crap into the language and makes something that's a third rate OO language, a second rate procedural language and a fourth rate functional language. Smalltalk aims to make the language almost as small as possible an implements everything at the library

      • by Space cowboy (13680) * on Saturday December 01, 2007 @06:25PM (#21547435) Journal
        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.

        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 .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.

        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
        • Years ago I was reluctant to switch to the Mac because I was a C++ programmer. But after switching to the Mac and using Objective-C for awhile I never ever want to use C++ again. I cringe whenever I have to use Java which is often cause I'm in college. Objective-C is one of the nicest languages I've programmed. I can't see how anyone would dislike it.
        • Re: (Score:3, Insightful)

          by coolGuyZak (844482)

          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 ?

          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:

          • Most institutions teach java, C#, or C++ in their core curriculum. Programmers simply know the syntax better.
          • The programming paradigms
    • by batkiwi (137781)
      .Net capability (and focus) could also explain the lack of Java updates.
    • No tears. Adobe had just as much time as any other developer abotu Xcode and Intel, and then spent the better part of a year doing their best huminahumina Jackie Gleason imitation when they failed to produce universal binaries along with most of the rest of the major developers.
    • by iJed (594606) on Saturday December 01, 2007 @06:44PM (#21547581) Homepage

      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

    • by Glasswire (302197)
      Frankly the LAST application that would still be Mac native, if OS/X could run Win32 apps would be Photoshop. You want a big application like that to be native.
      I think you're right about the intention of PE format giving .NET support though.
    • by noewun (591275) on Sunday December 02, 2007 @05:04AM (#21550479) Journal

      Adobe is probably already pissed off there won't be a 64-bit version of Carbon, which requires them to rewrite the entire UI of Photoshop in Cocoa to be able to release a 64-bit version of it.

      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.

  • This is pretty fascinating. If Apple were able to run Win32 executables at some point out of the box it would add a great deal of value to their platform -- especially if it worked well enough to do things like run all of those games that you can't play on OS X so far.
    • by Anonymous Coward on Saturday December 01, 2007 @06:16PM (#21547385)
      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.
      • by jcr (53032)
        Bingo! Give the man a cigar!

        -jcr

  • by jim.hansson (1181963) on Saturday December 01, 2007 @05:45PM (#21547101) Homepage
    wine is LGPL so apple maybe already is using wine.
    • 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 program
  • Hmm... (Score:4, Funny)

    by FlyByPC (841016) on Saturday December 01, 2007 @05:48PM (#21547125) Homepage
    A recent article was talking about how much less reliable Leopard seems to be than Tiger.

    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?
  • Wouldn't it be funny if OSX ended up better able to load old exes than Vista.

    I'm no fan of OSX, but nor am I a fan of Vista. Unpopular as the view is I don't think Linux is "ready for the desktop" either. SO I'm going to be one of these sad people that clings to XP for as long as they can. The bottom line is I can't stand Vista for its restrictions (Microsoft has been behaving very badly in the last couple of years) and I can't stand OSX because I've suffered badly many years ago due to Apple's tactics and
    • by pavera (320634)
      how did you suffer badly *many* years ago from OSX its only been out for 6 years, I wouldn't say that is many, and even then it was 10.0, so of course it sucked. Apple's "tactics" hurt you as a child?! wow, that's funny that you were scarred for life by a computer company's tactics when you were 6.

      • by syousef (465911)
        I suffered years ago from Apple. I bought a IIe at a premium just as the Mac came out, then Apple decided to close distribution and I had to drive a couple of hours to get any software legally (whereas I WAs able to buy software from a department store previously).

        I think if you get screwed over by a company you should learn from it. Apple does dubious things even now. Like crippling iTunes. I also had to babysit an eMac at work a few years ago and saw it die horribly within a month (motherboard died), then
        • by Baricom (763970)
          Unfortunately, for every bad story about Apple, there's another bad story about Microsoft. I'm a Mac user, but only recently - I just switched a little over a year ago. Microsoft's insistence on using buggy and inflexible copy protection was the tipping point for me. At least with OS X, there are no serial numbers to lose, no constant berating me for being a pirate, no machines suddenly "bricked" because Microsoft has decided that you don't deserve the Genuine Advantage, and no bundling of an inferior br
    • Unpopular as the view is I don't think Linux is "ready for the desktop" either.
      It's unpopular because it's a generalization. For me, it works perfectly.
  • by dpokorny (241008) on Saturday December 01, 2007 @05:50PM (#21547153)
    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.

    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 /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.
    • by ElMiguel (117685)
      But why would they try to hide this capability if that was the reason?
      • I'm in the camp that's hoping for .Net on OS X, but one reason is "Apple doesn't want developers to rely on the functionality".
    • Re: (Score:3, Interesting)

      by poopie (35416)
      That's my bet too. EFI on IA64 runs Windows PE binaries (for IA64). EFI on X64 (which hasn't been implemented by many hardware manufacturers btw) runs Windows PE binaries.

      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.
  • by apankrat (314147) on Saturday December 01, 2007 @05:53PM (#21547179) Homepage
    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.
    • Re: (Score:2, Interesting)

      by NTiOzymandias (753325)

      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.

      That, or they implemented the support in such a way that conditional compilation (using #ifdefs) was significantly more complicated and bug-prone than just leaving it in and not documenting it. If you've ever written a C program that had to behave differently on different platforms, you've doubtlessly run

    • Re: (Score:3, Insightful)

      by jim3e8 (458859)
      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.

      It's common to include "unused" code and undocumented interfaces in an OS, especially if they are benign.

      For example, Quartz 2D Extreme (QuartzGL) has been available since 10.4 was released, and it's still disabled, and enabling it is not officially supported as it may cause stability issues. Yet they did
  • by Jeff_at_RAD (121656) on Saturday December 01, 2007 @07:10PM (#21547747) Homepage
    Our game middleware products load PE format binaries on GNU/Linux and MacOS. It's like 200 lines of code to load and fix up a DLL - not difficult at all.

    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).
  • by LKM (227954) on Saturday December 01, 2007 @09:03PM (#21548397) Homepage
    I think Gruber had it right when he said that Apple wants its users to think of Windows as the new Classic, [daringfireball.net] i.e. if Windows apps run inside Mac OS X, they should do so the way Mac OS 9 apps used to run inside OS X: With distinctly different windows, in a separate environment, and a bit glitchy. Users need to be reminded that running Windows apps is not the preferred choice, but merely a last resort.

    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...

What this country needs is a good five dollar plasma weapon.

Working...