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?"

8 of 397 comments (clear)

  1. noooo FP by Anonymous Coward · · Score: 5, Insightful

    please not - i don't need every windows malware able to run on my mac...

  2. Loading PE is not a big deal by apankrat · · Score: 5, Insightful

    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
  3. Re:Not for Win32 compatibility by jcr · · Score: 4, Insightful

    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."
  4. Re:Win32 on OS X -- goodness by Anonymous Coward · · Score: 5, Insightful

    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.

  5. Re:Not for Win32 compatibility by jcr · · Score: 5, Insightful

    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."
  6. Re:Not for Win32 compatibility by Durandal64 · · Score: 4, Insightful

    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.
  7. Re:Not for Win32 compatibility by duffbeer703 · · Score: 4, Insightful

    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
  8. Re:Not for Win32 compatibility by The+One+and+Only · · Score: 5, Insightful

    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