Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Native Windows PE File Loading on OS X?

Journal written by ozmanjusri (601766) and posted by Zonk on Saturday December 01, @04:25PM
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?"

Related Stories

Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • noooo FP (Score:5, Insightful)

    by Anonymous Coward on Saturday December 01, @04:31PM (#21546949)
    please not - i don't need every windows malware able to run on my mac...
    • Re:noooo FP by Alan Partridge (Score:1) Saturday December 01, @04:41PM
    • Re:noooo FP by tacocat (Score:1) Saturday December 01, @05:02PM
      • 1 reply beneath your current threshold.
    • Re:noooo FP (Score:5, Interesting)

      by onefriedrice (1171917) on Saturday December 01, @05: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.
      • Re:noooo FP by Ahruman (Score:1) Saturday December 01, @06:27PM
        • Re:noooo FP by onefriedrice (Score:1) Saturday December 01, @07:24PM
      • Re:noooo FP by CarpetShark (Score:2) Sunday December 02, @07:46AM
        • Re:noooo FP by mr_mischief (Score:2) Tuesday December 04, @12:27PM
          • Re:noooo FP by CarpetShark (Score:2) Tuesday December 04, @01:17PM
            • Re:noooo FP by mr_mischief (Score:2) Tuesday December 04, @04:44PM
      • Re:noooo FP by devjj (Score:2) Saturday December 01, @05:52PM
      • Re:noooo FP (Score:5, Informative)

        by 99BottlesOfBeerInMyF (813746) on Saturday December 01, @07:13PM (#21548113)

        The trouble is they have NIH and so won't just work with the wine project.

        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.

        • Re:noooo FP by Anonymous Coward (Score:1) Saturday December 01, @10:37PM
          • Re:noooo FP by 99BottlesOfBeerInMyF (Score:2) Saturday December 01, @10:51PM
        • Re:noooo FP (Score:4, Interesting)

          by ozmanjusri (601766) <aussie_bob@nospam.hotmail.com> on Sunday December 02, @12:21AM (#21549703) Journal
          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.

          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.

          • 1 reply beneath your current threshold.
        • Re:noooo FP by dotancohen (Score:2) Sunday December 02, @03:21AM
        • Re:noooo FP by noewun (Score:3) Sunday December 02, @03:37AM
          • Re:noooo FP by BasilBrush (Score:2) Sunday December 02, @07:02AM
          • Re:noooo FP by 99BottlesOfBeerInMyF (Score:2) Sunday December 02, @02:33PM
        • Re:noooo FP by Klanglor (Score:1) Sunday December 02, @08:10AM
        • It's not quite NIH by SanityInAnarchy (Score:3) Sunday December 02, @10:38AM
          • Re:It's not quite NIH (Score:4, Insightful)

            by 99BottlesOfBeerInMyF (813746) on Sunday December 02, @03:16PM (#21553873)

            What I find frustrating about Apple is their need to so tightly control every bit of code they borrow.

            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.

        • 1 reply beneath your current threshold.
      • 2 replies beneath your current threshold.
    • Re:noooo FP by couchslug (Score:2) Sunday December 02, @10:56PM
    • Re:noooo FP by Wiseman1024 (Score:1) Monday December 03, @12:29PM
    • 2 replies beneath your current threshold.
  • Not for Win32 compatibility (Score:5, Interesting)

    by SigILL (6475) on Saturday December 01, @04: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.
    • Re:Not for Win32 compatibility by smaddox (Score:2) Saturday December 01, @04:36PM
    • Re:Not for Win32 compatibility by Anonymous Coward (Score:2) Saturday December 01, @04:42PM
    • How could it be for Win32 compatibility by Rosyna (Score:2) Saturday December 01, @04:53PM
    • Re:Not for Win32 compatibility by jcr (Score:2) Saturday December 01, @04:56PM
      • Re:Not for Win32 compatibility (Score:5, Informative)

        by SigILL (6475) on Saturday December 01, @05: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:Not for Win32 compatibility by sjf (Score:3) Saturday December 01, @05:20PM
        • Re:Not for Win32 compatibility by jcr (Score:2) Saturday December 01, @05:25PM
          • Re:Not for Win32 compatibility (Score:5, Interesting)

            by SigILL (6475) on Saturday December 01, @05: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?
            • Re:Not for Win32 compatibility by jcr (Score:1) Saturday December 01, @06:16PM
            • Re:Not for Win32 compatibility by edalytical (Score:1) Saturday December 01, @06:42PM
            • Re:Not for Win32 compatibility (Score:5, Insightful)

              by Durandal64 (658649) on Saturday December 01, @06: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.
            • Re:Not for Win32 compatibility by insertwackynamehere (Score:2) Saturday December 01, @06:49PM
            • Re:Not for Win32 compatibility by KeyserDK (Score:2) Saturday December 01, @07:24PM
            • Literally? by bar-agent (Score:2) Sunday December 02, @05:18AM
        • Re:Not for Win32 compatibility by turgid (Score:3) Saturday December 01, @05:42PM
        • Re:Not for Win32 compatibility by DrXym (Score:2) Sunday December 02, @04:49AM
    • Re:Not for Win32 compatibility by samkass (Score:2) Saturday December 01, @05:04PM
      • Re:Not for Win32 compatibility by abigor (Score:3) Saturday December 01, @05:17PM
      • Re:Not for Win32 compatibility (Score:5, Informative)

        by Space cowboy (13680) * on Saturday December 01, @05: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
        • Re:Not for Win32 compatibility by edalytical (Score:2) Saturday December 01, @06:56PM
        • Re:Not for Win32 compatibility by coolGuyZak (Score:3) Saturday December 01, @07:04PM
          • Re:Not for Win32 compatibility by rgravina (Score:1) Saturday December 01, @07:24PM
          • Re:Not for Win32 compatibility (Score:5, Interesting)

            by coolGuyZak (844482) on Sunday December 02, @12:49PM (#21552637) Homepage

            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.

          • 2 replies beneath your current threshold.
        • Re:Not for Win32 compatibility by tengwar (Score:2) Saturday December 01, @08:03PM
        • Re:Not for Win32 compatibility by 99BottlesOfBeerInMyF (Score:2) Saturday December 01, @08:32PM
        • Re:Not for Win32 compatibility by bitmonk (Score:1) Sunday December 02, @04:20AM
          • 1 reply beneath your current threshold.
        • Re:Not for Win32 compatibility by samkass (Score:2) Sunday December 02, @06:11PM
        • Re:Not for Win32 compatibility by Space cowboy (Score:2) Sunday December 02, @02:05AM
        • 2 replies beneath your current threshold.
    • Re:Not for Win32 compatibility by batkiwi (Score:2) Saturday December 01, @05:12PM
    • Adobe? Please. by jpellino (Score:2) Saturday December 01, @05:19PM
    • Re:Not for Win32 compatibility (Score:5, Interesting)

      by iJed (594606) on Saturday December 01, @05: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

    • Re:Not for Win32 compatibility by Glasswire (Score:2) Saturday December 01, @05:57PM
    • Why not Java first? by mario_grgic (Score:1) Saturday December 01, @06:54PM
    • Also by Sycraft-fu (Score:2) Saturday December 01, @09:12PM
    • Not for .Net by SoopahMan (Score:2) Saturday December 01, @09:54PM
    • Re:Not for Win32 compatibility by fm6 (Score:2) Saturday December 01, @10:23PM
    • Re:Not for Win32 compatibility by Vexorian (Score:2) Saturday December 01, @11:23PM
    • Re:Not for Win32 compatibility (Score:4, Interesting)

      by noewun (591275) on Sunday December 02, @04: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.

    • Re:Not for Win32 compatibility by cyber-vandal (Score:2) Sunday December 02, @05:58AM
    • 1 reply beneath your current threshold.
  • by gothicpoet (694573) on Saturday December 01, @04:34PM (#21546977) Homepage Journal
    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.
  • Watch out microsoft (Score:1, Interesting)

    by eli pabst (948845) on Saturday December 01, @04:34PM (#21546979)
    Interesting. One of the major downsides to using OSX is that there isn't as much software available for it. If OSX were able to run windows executables natively (think Microsoft Office and games) that would be a major coup for Apple. Plus you wouldn't need to sit around hoping that WINE decides to support that application.
  • maybe OSX already have wine (Score:3, Interesting)

    by jim.hansson (1181963) on Saturday December 01, @04:45PM (#21547101)
    wine is LGPL so apple maybe already is using wine.
  • Hmm... (Score:4, Funny)

    by FlyByPC (841016) on Saturday December 01, @04: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?
  • Well then (Score:1)

    by iminplaya (723125) on Saturday December 01, @04:48PM (#21547129) Journal
    That should explain the "gray screen of death".
  • More compatible than Vista (Score:2, Offtopic)

    by syousef (465911) on Saturday December 01, @04:49PM (#21547145)
    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 my own naivety as a child. I use XP at work and at home begrudingly. As far as I'm concerned the more cross compatibility the better since less of the apps I've spent time finding and learning to use will die a premature death.
  • Shush! (Score:1)

    by billcopc (196330) <vrillco@yahoo.com> on Saturday December 01, @04:50PM (#21547149) Homepage
    The secret is out: Leopard is really just Vista with a new skin! That would explain all the crashing and weirdness.

    Seriously, 10.5 has got to be the clumsiest OSX release ever. It introduced a ton of problems.
    • Re:Shush! by insertwackynamehere (Score:2) Saturday December 01, @07:04PM
    • Re:Shush! by gyrogeerloose (Score:1) Sunday December 02, @02:13AM
      • Re:Shush! by billcopc (Score:1) Sunday December 02, @09:44AM
  • Most likely there for EFI (Score:5, Informative)

    by dpokorny (241008) on Saturday December 01, @04: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.
  • Loading PE is not a big deal (Score:5, Insightful)

    by apankrat (314147) on Saturday December 01, @04: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.
  • by Alexx K (1167919) <alexk@theedgePERIOD.ca minus punct> on Saturday December 01, @04:55PM (#21547201)

    This is either most likely do to Microsoft's monopoly on the desktop, or because of the nature of Apple zealotry, but if Microsoft included support for running OSX binaries, people would be crying "Anti-competition!" faster than it would take to load up Notepad.

  • No (Score:1, Redundant)

    by acvh (120205) <geek@mscigar[ ]om ['s.c' in gap]> on Saturday December 01, @05:11PM (#21547333) Homepage
    There is no reason for Apple to want to be able to run Windows executables natively. As others have pointed out, malware alone would be enough reason to say no.

    More likely this is related to EFI. Less likely this is something that a developer was playing around with and forgot to delete from his code before checking it in.

  • PE Loading on x86 is easy,,, (Score:4, Interesting)

    by Jeff_at_RAD (121656) on Saturday December 01, @06: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, @08: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...
    • Macros? by argent (Score:2) Sunday December 02, @11:31PM
      • Re:Macros? by LKM (Score:2) Monday December 03, @04:48AM
        • Re:Macros? by argent (Score:2) Monday December 03, @10:38AM
  • One possibility: Xen-like co-install (Score:2, Insightful)

    by PhotoGuy (189467) on Saturday December 01, @09:45PM (#21548935) Homepage
    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...
  • by Ilgaz (86384) * on Sunday December 02, @01:09AM (#21549881) Homepage
    Since early 10.3 or 10.4, Apple OS X Safari will warn you if you (generally,accidentally) download a .EXE file or .COM file over the web saying it can be potentially harmful to your computer. I am on PPC/G5 and always thought it is sign of things to come.

  • by m2943 (1140797) on Sunday December 02, @01:11AM (#21549887)
    PE is used by Microsoft native code, but also by .NET. Apple's support of Java has slowed down and they may be looking for a replacement.

    Furthermore, C# and CLR would be a reasonable platform for them to move to, given that Microsoft is not dogmatic about what libraries to use with the CLR; they could probably even create an Objective C to CLR compiler, giving people the choice of either running Objective C as native code or as CLR bytecodes. It would also make it easier for Windows developers to develop for Macintosh.

    How prominently such support would feature in OS X would have to be seen; it might only be used for things like Silverlight, or it might become a full alternative to native development.
  • by JackMeyhoff (1070484) on Sunday December 02, @04:44AM (#21550579)
    This is the final catalyst for me to SWITCH :)
  • Update needed (Score:2)

    by ZoneGray (168419) on Sunday December 02, @09:04AM (#21551395) Homepage
    Apple needs to update their promotional materials for Leopard. Turns out it has 301 new features.
  • My guess (Score:2)

    by richardtallent (309050) on Sunday December 02, @06:43PM (#21555253) Homepage
    Reproducing or even bringing WINE up to consumer level would be a monumental task. I don't think their strategy is to support Windows apps across-the-board.

    My guess is that Apple has a secret project to integrate just enough of WINE/Crossover into OS X to support Microsoft Office, in the event that Microsoft backs down on its commitment to provide Office for Mac.

    Microsoft screwed them over before on its promised releases of Office, and Office is a de facto requirement for corporate workstations.

    Yes, iWork, OpenOffice, and Office-under-Parallels are good alternatives, but they are NOT feature-complete or performant, and are a much harder sell than "and it runs Microsoft Office too!"
    • Re:My guess by exp(pi*sqrt(163)) (Score:2) Monday December 03, @11:13PM
    • Running MSOffice? by Joseph_Daniel_Zukige (Score:1) Tuesday December 04, @07:54AM
  • binfmt_misc (Score:2)

    by oglueck (235089) on Wednesday December 05, @12:22PM (#21586837) Homepage
    Linux could do that easily with WINE and the binfmt_misc [wikipedia.org] kernel module.
  • by paulatz (744216) on Saturday December 08, @07:45PM (#21627999) Homepage

    This could be a good reason to hide (still partial) support for window executables: wine is a very good project, and even with all its glitches it can run a lot of windows apps. Maybe OSX developers are using a lot o wine code but, since it's GPL, they want (and have to) keep it secret as long as they are able to rewrite it from scratch or include it in a way that don't violates GPL licence.

    It may even be that they already violated the licence, this could be interesting to investigate, as having open source OSX would be quite nice ;-).

  • Unlikely (Score:4, Informative)

    by makomk (752139) on Saturday December 01, @05:58PM (#21547673) Journal
    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).
    • Re:Unlikely by Nermal6693 (Score:2) Saturday December 01, @07:28PM
  • by shentino (1139071) <<moc.liamg> <ta> <onitnehs>> on Monday December 03, @03:03PM (#21563517)
    I'd be modding you down myself if I had any mod points. Please keep such pejorative terms off of slashdot, thank you.
  • 13 replies beneath your current threshold.