Forgot your password?
typodupeerror
BSD Operating Systems

Running Mac OS X Binaries With NetBSD 177

Posted by Hemos
from the making-it-work dept.
An anonymous reader writes "KernelTrap has an interesting article about an effort to add a Mach and Darwin binary compatibility layer to NetBSD. The project has evidently already made a fair amount of progress, currently working to stabilize the WindowServer emulation portion that will then allow NetBSD to run Mac OS X graphical applications."
This discussion has been archived. No new comments can be posted.

Running Mac OS X Binaries With NetBSD

Comments Filter:
  • Fantastic (Score:4, Funny)

    by Evil Adrian (253301) on Sunday January 05, 2003 @12:02PM (#5019741) Homepage
    That's great, really, but what is there to discuss? Now we can run apps from OS X on OS Y (my apologies), happy day. Next topic!
    • I'm a bit lost too about what to say (say nothing :). I guess people want their OS to have all possible bells and whistles. All other (than mac) NetBSD's ppc ports seem to run on quite exotic hardware and if you have a mac you want macos-x too, right?
  • Great idea (Score:1, Redundant)

    by nurb432 (527695)
    Now one can run native Xapps, windows AND OSX apps on a unix box.. ( in theory at least )

    Best of all the worlds combined. Run the app you need, on an OS you can trust.

    • by __past__ (542467)
      ... you only have to make sure both your windows and OS X binaries are for the same processor architecture.
      • Which is possible: I have Windows NT 4.0 PPC and DevStudio 5.0 can compile with NT PPC as target. Of course, porting to BSD would probably be easier than using WinePPC (is there such a thing?). BTW, some old Mac programs are ported so badly that you could almost call them "windows binaries", too. E.g. C&C 1 uses DirectX, and I've still got a MFC 4.0 OLE library in my extension folder :-(
    • Re:Great idea (Score:4, Informative)

      by AtATaddict (531517) on Sunday January 05, 2003 @02:09PM (#5020348)
      Umm.... you could just buy a Mac and VirtualPC, then install Xfree86 in rootless mode. Seems like a simpler means to the stated end, considering that a Mac running Mac OS X is a "unix box".
    • i agree with you. however, some of us just can't wait for NetBSD to follow the largest and most popular BSD based *nix OS . . . . i can already do [grantstern.com] what they're just gettin runnin for NetBSD.

      now i'm really lookin forward to installing NetBSD on my Quadra 660av [lowendmac.com]. kudos to NetBSD!

  • That's pretty cool, but personally I'd probably just run OS X, it's a very nice OS. I can see where this would be nice though. Now if they can make this run on x86s (I know, VERY though, that requires emulating a ton more stuff) then I'll rush to download it.
    • Re:Neat but... (Score:2, Interesting)

      by fdisk3hs (513270)
      The point is that you can run Mac OSX, Irix, Linux, Solaris, you-name-ix binary precompiled even commercial software on a PPC machine running NetBSD. EVEN machines that don't support OSX, like that iMac 233 or PowerMac 180 that you have sitting around... Sounds useful.

      But, yes- you can only run PPC binaries. M68k or x86 will not work.

      lr
      • EVEN machines that don't support OSX, like that iMac 233 or PowerMac 180 that you have sitting around... Sounds useful.
        I don't know about the PowerMac, but: Since when does OSX not work on an iMac 233?

        I'm running on an even older beige G3, no problem.

      • Ok, so when did IRIX or Solaris run on PowerPC? Just because they provide binary cross-OS compatability, doesn't mean they also provide processor emulation. This emulation is probably just a system-call shim layer, like FreeBSD's Linux emulation. The code still runs native, but syscalls are translated and sometimes emulated.
  • Linux port? (Score:1, Interesting)

    by Selanit (192811)
    Very cool. I wonder if it could be ported to Linux once they've got working okay on FreeBSD. Then Linux would be able to run Mac OS X apps -- the Mac OS X versions of Photoshop and Word come to mind. One major barrier to the adoption of Linux on the desktop is the percieved lack of familiar applications, and Photoshop and Word are high on the list. Word has been pretty well taken care of by the Crossweaver WINE stuff, but Photoshop is still missing. Gimp is great and all, but most graphics professionals would rather keep using the package they're already familiar with than try to learn a whole new one, which is frankly often not as capable as Photoshop.
    • You realize this is only for NetBSD/PPC, right? I'm sure this would be great news for the Linux PPC users, but it won't affect most of us. Stick with WINE, I guess (CrossOver Office is very sweet, though).
    • Re:Linux port? (Score:2, Insightful)

      by damiam (409504)
      Running Photoshop or Office would require a complete reimplimentation of Quartz, Aqua, Carbon, and quite a few other OS X technologies. Besides, even if successful, it would only work under LinuxPPC. The work necessary to get Wine to run Photoshop well is a small fraction of what would be needed to port all OSX API's to Linux.
    • why on earth would i want to kludge linux on a Mac to run OSX apps when I can just run OS X? you'll notice that the project is still only for ppc machines, and while LinuxPPC/YDL is nice, i really prefer X...it's just so much better a *nix on the Mac...
      • ...because GNU/Linux is Free as in Freedom.

        • And most people want computers to be practical, as in paycheck.

          I don't really give a whiz about freedom. I'll use the best tool for the job. Sometimes it's a Mac, sometimes it's Linux, sometimes (but not very often) it's Windows. If I can use something with a BSD license, I will, but that doesn't govern my decision. Maybe I'm getting old, but I'm starting to think of all of this push for GNU, the Green Party, and the like as simple immaturity on the part of people who don't have enough other things to do in the real world. Call that a troll if you like, but it's about how I feel.
          • Maybe I'm getting old, but I'm starting to think of all of this push for GNU, the Green Party, and the like as simple immaturity on the part of people who don't have enough other things to do in the real world.

            Congratulations, and welcome to the real world. :)

          • Re:OK, but... (Score:2, Insightful)

            by demon (1039)
            Then just go right ahead and use what makes you happy. If you like Windows, or OS X, or whatever, use it. Just because some people like to hack on stuff for the hell of it, doesn't make no nevermind to you, or shouldn't anyway. It doesn't affect your ability to use your platform of choice. So why complain about someone doing this?
    • Re:Linux port? (Score:5, Interesting)

      by KAMiKAZOW (455500) <kamikazow@hotmail.com> on Sunday January 05, 2003 @12:49PM (#5019920)

      Mac-On-Linux [maconlinux.org]

      What Is Mac On Linux?

      Mac-on-Linux lets you run MacOS under Linux/ppc. MOL runs natively on the processor, i.e. it is very fast. Unlike most mac emulators, MOL can run MacOS 8.6 and later WITHOUT A ROM IMAGE.

      Feature List

      - Supports MacOS 7.5.2 to 9.2.2, 10.1 and 10.2
      - Linux can be booted inside MOL
      - Full screen video
      - MMU accelereaded X video
      - Audio support
      - Block device support (Ide, Scsi, Zip, Jaz)
      - ADB & USB support for mouse and keyboard
      - Ethernet
      - Runs natively - good speed!
      - Very compatible
      - Idle sleep (8.6 or later)
      - Session save and restore (temporary unavailable)
      - AltiVec support
      - Multi-session support


      OK, it's not binary compatibility, but unlike COMPAT_MACH and COMPAT_DARWIN it does already work. But COMPAT_MACH and COMPAT_DARWIN are very interesting and worth keeping an eye on it.


      Oh, BTW.... From the MOL-FAQ:

      Q: Does it run on i386 hardware?
      A: No, MOL can only run on PowerPC hardware since no emulation is performed. However, adding a PowerPC emulator for x86 is under consideration.

      • You forgot to mention this special fact from the Mac On Linux homepage.

        "News Flash:
        Sep 5: It is now possible to boot MacOS X in MOL."

        Which links to..

        "Hot News:
        Sep 5: Boot MacOS X in MOL 0.9.65!

        It is now possible to run MacOS X within MOL. Both MacOS 10.1 and 10.2 are supported. The new MOL version also contains support for little endian (remote) X displays. A couple of performance improvements have also gone into this release."

        Q: Why don't they port this to BSD, instead of reinventing the wheel?
        A: This is OpenSource dude, don't you get it?
        • *BSD's COMPAT_* are better than MOL and plex86 because there is no overhead of a secondary kernel.
          • I've saw once such "COMPAT" - Wine. Comparing to stable and fast MOL, Wine is crashy and slow. I don't expect good results from BSD if they will do it like Wine.
            • They won't, at least if it's as good as the other COMPAT stuff in NetBSD. You can boot (and I have done so - don't ask why, you don't wanna know) a Sun 3 with a full SunOS install with a NetBSD kernel instead of a kernel from Sun. You can even run (once again, don't ask but I've done this) SunOS binaries on a pre-PPC Mac running NetBSD.


              Basically, what the COMPAT stuff emulates is not the somewhat ill-defined layer between libraries and applications in Windows, but the very well defined (and open-sourced) layer between the kernel and user-land. In order to make it useful, I'd suspect you'd need almost a full OSX installation.

              • So, basically COMPAT on NetBSD works the same way as MOL, doesn't it?

                Or, wait, what about devices? The biggest problem of MOL is that every device has to be reimplemented. As a result, today the MOL user can forget about virtually all USB and Firewire devices: printers, scanners, cameras. Is this the same problem with NetBSD's COMPAT?

                • Well, I'm not terribly familiar with this particular implementation, but that's not quite the same as MOL. MOL basically allows you to boot MacOS (X or Classic) in a "virtual Mac" that runs under Linux/BSD/whatever. The COMPAT stuff allows the NetBSD kernel to replace the normal OS kernel. So, only a single kernel is running, which means that all your devices and filesystems should be identical under OSX as under NetBSD whereas with MOL, you have the standard BSD or Linux kernel plus the Classic or OSX kernel on top of it.


                  Under most versions of Unix, there is a very similar interface between the user application and the kernel. Basically, the COMPAT stuff just says "Well, this program is a MacOS X program so when it makes a call that looks like A, it really means B under NetBSD so go do that and I'll reformat the results back to what the binary is expecting". The result is that the OSX binary is really running natively under NetBSD so any device supported by the NetBSD kernel *should* be supported by OSX. It looks like their present state is trying to get enough of the OSX device interface working for that to happen.

    • One major barrier to the adoption of Linux on the desktop is the percieved lack of familiar applications, and Photoshop and Word are high on the list.

      This is the most often reason for Linux not being adopted on the desktop that I see. Why does it matter? What would possess someone to switch OS's just to use the same program that has been shoehorned into a different OS? If something is working (i.e. Photoshop running on an Apple) there isn't a compelling reason to switch. The percieved lack of familiar programs is usually just preventing people that already using Linux from using it full time.

      If Photoshop or Office was native to a Linux desktop then that may put a dent - but only a very small dent, look at Apple's success - in the desktop world. Why is it so hard for Linux advocates to accept that Linux belongs as a server, for now. Now that it has pretty, user-friendly UI's people want to force it on the desktop for everyone...maybe that isn't right, though.

      It would take some killer app (or a significant outside influence) to get the regular Joe-user to switch from a system that works to the point they expect (i.e. Windows, with the occasional crash now in XP) to Linux.

    • Re:Linux port? (Score:3, Insightful)

      Very cool. I wonder if it could be ported to Linux once they've got working okay on FreeBSD. Then Linux would be able to run Mac OS X apps

      You're making a lot of assumptions. Firstly, that such an emulation system could be completed in any reasonable amount of time, and could keep up with Apple. Obviously, that isn't the same kind of issue as it is with Wine as Apple is a lot smaller, and to be frank, Windows has far more APIs and features to the developer than OS X does (at present).

      Secondly, you're assuming Apple would let this happen. They can't stop a cleanroom implementation, but they can copyright the artwork which is a big deal to Mac users. Wine has to have its own artwork for instance (but not for the widget toolkit, as the Win98 L&F is so basic it can't really be copyrighted). Not that nice distinctions like code vs art would bother Apple, they have a long history of abusive lawsuits.

      Finally you're assuming that such an emulator could emulate PPC opcodes at a reasonable speed, which is a) hard and b) unlikely.

      Bear in mind that doesn't say "You can run MacOS apps on NetBSD", far from it, they have some of the basics of Mach IPC working. They haven't even started on graphics support. If there's something we've all learnt from Wine (which has 2 companies working on it as well as hundreds of volunteers), it's that cloning another OS's APIs is a lot of work, and as most of the MacOS APIs are not simply lifts of their UNIX equivalents, they are Apple proprietary (iokit/coreaudio etc), that's no less amount of work.

      • Please stop comparing COMPAT_MACH to WINE. The WINE project is attempting to build cleanroom implementations of the Win32 API. The COMPAT_MACH folks are working on binary compatibility. If you want to talk about APIs look up GNUStep which is an implementation of the OpenStep specification. That is a project more analguous to WINE because it is actually attemping API reimplementation. If this project gets everything working it could allow NetBSD to be a drop-in replacment for Darwin as a BSD subsystem and kernel. WINE and GNUStep on the otherhand would be drop-in replacements for application level APIs.
      • Finally you're assuming that such an emulator could emulate PPC opcodes at a reasonable speed, which is a) hard and b) unlikely.

        Opcode emulation is probably the easiest part of emulating the PPC. Much harder is the emulation of all those registers with the handful in x86. This will be much easier with x86-64 (AMD) because you have twice as many registers, but you still have to determine which registers are being acted on and swap the contents of registers in and out as you go -- basically, the same thing modern CPUs do internally to reduce the cost of context switches (register renaming) except you're going to have to do it in software. You might be able to avoid that in the case of a transmeta CPU, but the proper way to do that with a TM chip is to make it emulate a PPC anyway. I really hope someday transmeta manages to emulate something other than x86, and further that we end up with systems with multiple TM CPUs on them so that we can emulate multiple CPUs of different architectures.

        Incidentally, CPU-manufacturing companies are really goddamned annoying. Why oh why can the FACT SHEET for a processor not tell you in simple terms how many general purpose registers it has? You have to go all the way to the user manual... Anyway the G3 has 32 GPRs and 32 FPRs (floating point), I had that noted down already and didn't want to look up the G4 to see if it has more (it probably doesn't, except for altivec.) I'm only familiar with four GPRs on x86; [E]AX through [E]DX. There are a number of index registers, many of which can be used as GPRs, but which in practice nearly always must be used for their design purpose. Of course motorola uses GPRs for indexes so the real number of usable GPRs is closer to four times as many than eight times as many as it at first appears.

        In any case that's a LOT more registers! You think context switches are bad now...

    • One major barrier to the adoption of Linux on the desktop is the percieved lack of familiar applications, and Photoshop and Word are high on the list
      Already on 2003, and we still read people wining about the unavailability of Word on Linux. Jeez...
      Me and my whole organization use StarOffice/OpenOffice for a long time ago, and we don't need MS Office. When we want to send a document outside the company, we convert it to PDF. Whenever we receive a MS Office document from outside, we open it it StarOffice/OpenOffice. When we need to check if the conversion was well done, we open the document in Microsoft Word Viewer, Excel Viewer and Powerpoint viewer, which:
      • Are freeware
      • Run fine under Wine
      • Open MS Office documents from versions 97 to XP

      When will people realize that if compatibility was so crucial, then we would still be using Wordstar or an even older wordprocessor?

      Regarding Photoshop, Corel Photopaint and Gimp are excellent replacements. I know they don't have all the prepress features of Photoshop. But most Photoshop users don't use prepress features!

  • I was thinking of getting a PowerPC computer and install GNU Darwin on it, but unfortunately GNU Darwin is dropping PowerPC and Cocoa support, so it is kind of useless. Considering that NetBSD runs just about every computer out there, the ability to run OSX binaries is greatly appreciated. I really hopes this becomes popular and that is really DOES run OSX binaries well, cuz then I'll be VERY happy. Mmm. OSX compatiblilty...
  • by guroove (231050) on Sunday January 05, 2003 @12:05PM (#5019755) Homepage
    It's only the NetBSD/powerpc port. The biggest problem with MacOSX is that it only runs on Macs. If I'm going to pay all that money for a shiny new Mac, I'm going to run Apple's shiny new operating system.
  • That's awesome (Score:5, Insightful)

    by Burgundy Advocate (313960) on Sunday January 05, 2003 @12:06PM (#5019760) Homepage
    But one question: is there anything Apple can do to stop this?

    If you remember, they've been *very* anal in the past about some things they consider to be "their stuff", such as the look and feel of the OS. I can't see them just sitting around and watching while all their OS capabilities are matched (or, for that matter, exceeded).

    If they sent C&D letters for freakin' themes, I doubt they'll just sit around while their API is emulated. They've show themselves to be rather devious, and I'd be a little worried if I was a NetBSD developer.
    • Note that this only appears to be working in the PowerPC port. Apple has been, so far, pretty laid back about the MacOnLinux project, which emulates classic MacOS on top of LinuxPPC boxes -- after all, you have to buy their hardware either way.

      We'll see if they start "Thinking Differently" about that approach now that it's OSX involved instead of Classic, but I'd be at least slightly optimistic: they haven't tried to shut down the GnuStep projet recently, and that's much more of a danger to them than this.
      • Isn't that because GNUStep is working on the open OpenStep specification?
        • Re:That's awesome (Score:3, Informative)

          by Graymalkin (13732)
          Most of Cocoa that doesn't deal directly with Darwin/OSX related functions is basically a strait reimplementation of OpenStep. IIRC the Building Cocoa Applications: A Step-byStep Guide by Simson Garfinkle and Mike Mahoney is pretty much code identical to what was in NeXTStep Programming: Step One: Object oriented Applications.

          A GNUStep application if binary compatible with Mach/Darwin would run without recompilation or localization.
    • If they sent C&D letters for freakin' themes, I doubt they'll just sit around while their API is emulated.

      This project isn't emulating the MacOS APIs, they're getting the basics up and running so they can drop in actual code libraries from OS X. Unlike Wine which is actually recreating all the APIs, this is just a fun hack basically, no danger to Apple as you still need a Mac and a copy of MacOS for it to work.

      I seriously doubt we'll see a Mac equivalent of Wine for a very long time, the amount of effort it takes is just too huge given the absence of any must have apps on the Mac (apps with no equivalent on other platforms). Wine is essential because of the huge amount of software that simply doesn't have Linux equivalents (or not very good ones) and probably never will, ie Lightwave, DreamWeaver, Flash and so on, and of course huge numbers of custom business apps. The Mac doesn't really have any such apps, the closest I can think of are the iApps, but there are lots of equivalents for them even on the Mac itself, and I don't know of any custom business apps that are Mac only.

      • Re:That's awesome (Score:1, Insightful)

        by Anonymous Coward
        Yes, and basically everything they are reimplementing already exists as open source in Darwin...

        So basically this is replacing the Darwin system with NetBSD to allow the proprietary OS X parts to run under a different kernel.

        However, unlike emulating other monolithic Unixen, emulating Mach and Apple's driver frameworks requires a lot of extra functionality, so they are sort of re-creating the Darwin kernel backwards - instead of a Mach kernel with BSD functionality added, it'll be a BSD kernel with Mach functionality added. BSD and Mach have been related quite closely historically, anyhow, consider that the virtual memory subsystem of 4.4BSD was from Mach... And then there is Lites, the BSD kernel that runs as a user process under Mach.

        So we can basically look at it this way - mixing Mach and BSD kernels in various ways has been something people have been doing for a long time, and it doesn't look like people will stop doing it.
    • Re:That's awesome (Score:2, Interesting)

      by andrewski (113600)
      Their API isn't just emulated, it's already implemented. It's called GNUstep and it runs on almost any *nix platform, and quite a few non-*nixes as well. Most, but not all, OS X (cocoa) applications will run just peachy with a recompile on many platforms.

      Darwin with GNUstep implements approximately 75% of the functionality of OS X, right down to the resolution independant rendering (GNUstep uses Postscript, OS X uses PDF).

      If everyone is so up in arms about running OS X on their Intel computer, just fucking get Linux or Darwin and run GNUstep. Most freeware for OS X should work just fine if you compile it. Due to the great object-oriented nature of Openstep, you could probably fix any that didn't in a matter of minutes or hours.

      I was running GNUstep (with the Ghostscript back-end) and Windowmaker for a while before I got my Powerbook G4.
    • I doubt they'll just sit around while their API is emulated.

      'their API', is, to a very large extent, taken from NextStep, which they bought to get Steve Jobs back. It's already been cloned (pretty much) by the GNUStep project [gnustep.org].
  • by eyeball (17206) on Sunday January 05, 2003 @12:08PM (#5019762) Journal
    Oh now look what you did: You woke the swarming team of Apple lawers on a beautiful sunday morning. They're going to be extra pissed.

  • by RAMMS+EIN (578166) on Sunday January 05, 2003 @12:08PM (#5019763) Homepage Journal
    Or should that me...of course NetBSD runs it? Whew...imagine the possibilities. NetBSD runs on next to anything, and can run binaries in all those formats. /me installs NetBSD on his watch and tries to load Mail.app Dangit! Doesn't work. What crap is this???
  • Taken to its logical extreme, it appears that these guys would create a de facto x86 OSX. What would be missing? Obviously the OSX UI (could easily be cloned)...and some multimedia stuff. What else?
    • by kakos (610660) on Sunday January 05, 2003 @12:14PM (#5019790)
      Quite wrong. These guys are making a binary compatability layer, not emulation. You will not be able to run OS X applications on an x86 box running NetBSD, only a PPC box running NetBSD.
    • Obviously the OSX UI (could easily be cloned)...and some multimedia stuff. What else?

      What else? I shit load of cash in lawyer fees, that's what.

      I've only "used" OS-X at a Mac Store a couple of times, but REALLY liked it. Like I'd even go so far as to dump all this OSS/Linux/M$/whatever stuff to have one Mac box. It left that great of an impression on me. But what you are suggesting is pure suicide. I would LOVE for Apple (read as: Steve Jobs...) to release an x86 version of OS-X. I'd buy it in a heart beat (I love KDE3.1, but OS-X... mmmm...). But I just don't see that happening. There's FAR too many hardware configs to consider. Apple as only one hardware config to think about: Apple's Hardware. That's REALLY easy to program for.

      Aside, take a look at KDE-Look [kde-look.org]. There's a couple Window Decrations that are basically OS-X, and then there's Mosfet's widget set. OK, OK, there's more to OS-X than the look of it, I know. I'm just saying that there's MUCH cheaper ways to achive the same goal.

      KDE3.1 + Aqua WD (I forget the exact name, I don't use it) + Mosfest's Liquid Widgets + CodeWeaver's Crossover + the dirt cheap prices of x86 hardware == Heaven (if it's a Mac you're looking for). Just thought I'd say it. We already have most of the parts available to us. It's just the matter of doing it...
      • IMHO, the hardest part to copy, clone or imitate in Mac OS is the way the OS extends outside the Apple software.

        The much appraised Mac 'look & feel' bases itself on all developers sticking to the UI conventions and guidelines, nicely outlined in this guide [apple.com] for porting over Win32 apps.

        The longer you use Mac OS, the more you'll appreciate this 'cultural' aspect of the OS.

        Having used Windows XP a lot lately, I've been quite happy with the OS and 'Window Manager' itself, but as soon as I actually use an other app, the whole experience breaks down.

        Keyboard shortcuts vary, widget placement is random, the tone of dialog varies and in general, application interoperability seems harder.

        Funny how so many people lust after the visual aspect of the UI, risking lawsuits from Apple, while the 'feel' part - the real magic of Mac OS - is quite publicly available AND applicable in form of UI guidelines [apple.com].

        It won't hurt your Win/Linux app to apply some/all of these guidelines instead of no guidelines at all.

        J
      • KDE3.1 + Aqua WD (I forget the exact name, I don't use it) + Mosfest's Liquid Widgets + CodeWeaver's Crossover + the dirt cheap prices of x86 hardware == Hell

        - No self contained applications. Installation process is _not_ "grab the app and drag it to your favourite place"
        - No intelligent framework system. Try to use a KDE 1.0 app with your KDE 3.1 libraries. It breaks, because the goddamned _size_ of the _classes_ in fucking _C++_ has changed. Even if it were _source_compatible_ it wouldn't work, because of C++'s stupit ABI. (Note: Objective C doesn't have this problem :-)
        - No Project Builder. Use it, then you'll understand.


        Those are only a few, but I'll stop here. It's indeed a Mac I'm looking for, and that's because it's thought out. It's not because I like the _look_ of the GUI. In fact, if you choose your tools by their looks, you probably have a larger problem than not having a Mac...
  • by zubernerd (518077) on Sunday January 05, 2003 @12:11PM (#5019778)
    to use this, since it is only binary compatability. So You will still need to buy PowerPC based computers. And who is one of the largest and most noted for selling powerPC based PCs... Apple Computer; so why not just run MacOS X?
    I know you can buy third party PowerPC computer, but they are more expense than Apple's machines.
    I do appricated their effort, it is probably a good exercise in programming skill.
    It would be useful if it was on x86, but there are plenty of problems with that; see
    http://www.emaculation.com/ppc.shtml [emaculation.com]


    (This is not a flame, just an observation)
    • to use this ... You will still need to buy PowerPC based computers. And who is one of the largest and most noted for selling powerPC based PCs... Apple Computer; so why not just run MacOS X?

      Buying an Apple computer complete with operating system means you're unlikely to want to install NetBSD if your already happy with MacOS X. However, have you seen the cost of MacOS X "upgrades"? £100+ in the UK for what is essentially bugfixes and performance improvements in the VM system. Then NetBSD in the long term starts to look very affordable, ignoring the fact that it outperforms MacOS X on the same hardware (quite remarkable until you consider how fundamentally poor Mach is as a desktop OS kernel).

      Chris

      • 100+ in the UK for what is essentially bugfixes and performance improvements in the VM system.

        I'll bet you anything that OSX apps under NetBSD will be significantly buggier and worse performing than under OSX, even unupgraded versions. This looks a lot like Wine for PPC, and we all know how reliable Wine is, even after ten years of development.

        • I'll bet you anything that OSX apps under NetBSD will be significantly buggier and worse performing than under OSX

          If, and that's a big "if" at the moment, this compatability layer gets completed then expect OSX aps to run faster and as stable under NetBSD. Why? Well unlike Wine or GNUStep, NetBSD compatability layers don't emulate an environment like Win32 or OpenStep, but a Unix-like kernel. Look at the Linux or Irix compatability layers in NetBSD as an example. By enabling Linux compatability in my kernel, and installing a few application level libraries from SuSE Linux, I can run most Linux binaries on the same architecture.

          So to be frank, you may still need a copy of OSX lying around from which to get those application level libraries (although GNUStep is fast approaching a state where that wont be necessary). On the performance and stability front, look to the glowing reputation of existing compatability layers in all three of the *BSD's.

          Chris

        • Wine is 100% fundamentally different. It's a reimplementation of the Win32 API as a huge library, with a custom debugger and an LE/PE binary loader strapped onto it. What these guys are doing is implementing a kernel-space binary loader, and using native libraries and binaries to do the rest. It will run OS X WindowServer and everything else. All they have to do is load and run Mach-O binaries with the interfaces they expect. It's like running Solaris/SPARC binaries on UltraLinux, which has worked pretty well (from what I understand - I don't own SPARC hardware myself, so I only know what I hear) for some time now.
    • There are still a whole lot of people, like myself, that already own Apple hardware,but are ready to make a switch to a maximally open source solution. This would be ideal for me. I have a G3 300hz PPC, and would like run primarily Linux or {Net,Free}BSD but would still need to use Dreamweaver for my work sometimes.

      Doing the reverse-- running X11 inside of OS X feels like too much overhead and complexity. Typing in X11 applications is often slow this way. Plus, OS X isn't completely open source, so it's hard to tinker with and debug.

    • WINE offers binary compatibility. So you need to buy a PC pased computer running Windows. And who is the largest seller of Windows for PCs... Microsoft; so why not just Windows?
      • If Windows had a native UNIX layer that interfaced with the Windows kernel, then maybe your analogy would actually work. But since there's no real option on a Windows box for using all of the UNIX programs you've come to know and love, it's just not the same.

        (Cygwin is a poor pacifier for the real thing. I know, I still have to use it every day. At best, it works like it's supposed to, but much of the time, it's just a waste of time and effort.)

      • Nice anology, but you're overlooking a couple of things. First off, OS X is widely seen as a great OS, combining the power and stability of Unix with some nice features of NEXTSTEP and the beauty of Aqua. Windows is widely seen as an unstable and insecure OS that everybody feels forced to use because everyone else uses it. Really, these operating systems are apples and oranges. The same goes for the hardware part. OS X only runs on a slim variety of hardware, known to generally be more expensive than x86 hardware of comparable performance. There is little competition in the PowerPC market, and it's not exactly commonplace to build a Mac-compatible from parts. I would go as far as to say that, where buying Apple machines is the easiest way to get PowerPC hardware, and building from parts is the hardest way (except manufacturing parts yourself) to get a machine capable of running WINE, it's usually easier to do the latter. It's not like you need to buy a PC based computer running Windows to use WINE. You can buy the computer without Windows. You can buy it with Linux and WINE installed. You can even build it from parts without too much effort. Try that for a PowerPC box and tell me if it feels different.
    • Today it is true that emulating a PowerPC (especially with 64 bit ppc on the horizon) is problematic but as processor speeds continue to increase it will become more reasonable to emulate processors, perhaps several at once.

      It would be amazingly ironic if netbsd's ability to run on every platform invented since the MMU ended up being coupled later with the ability to emulate a bunch of different processors and actually catapulted it to the top of the technology heap.

  • Nifty. (Score:5, Informative)

    by Anonymous Coward on Sunday January 05, 2003 @12:13PM (#5019786)
    Which will come first - Apple cracking down or them getting WindowServer to run on i386? Some info from http://hcpnet.free.fr/applebsd.html [hcpnet.free.fr]

    What works?

    On NetBSD/i386: nothing. On NetBSD/powerpc, most UNIX binaries, such as ls, sh, or vi will work. No Graphical User Interface (GUI) based program will work for now. We are able to startup WindowServer up to the first attemps to use the IOKit. See the kernel traces for WindowServer and for mach_init to discover how far we have been.

    Here is what have been implemented so far:

    Mach-O binaries loading

    Mach system calls handling

    Minimal Mach ports, messages and rights support, so that simple program are able to link and run.

    Signals handling (except for siginfo) Minimal multithreading support

    Support in ktrace/kdump to display Mach messages (useful for debugging)

    Hacks to get mach_init starting (and to get it behaving as bootstrap mach_init)

    Support for port rights carried by Mach messages
    Here is what is in the TODO list:

    Implement Mach notifications for destroyed ports, dead names, and no sender ports

    Re-implement enough of Darwin's IOKit to get

    WindowServer actually displaying something.

    Use COMPAT_MACH for COMPAT_OSF1 (Tru64 binary emulation on NetBSD/alpha), to get multithreading working.

    Get Darwin binaries to link and run on NetBSD/i386

    • Notice the part you didn't quote:

      "Once we will have a fully functionnal Darwin binary compatibility on NetBSD/powerpc (if that happens some day), we will just have to grab Mac OS X libraries to run any MacOS X program"

      I.e. you would still have to have the whole Mac OS windowing, graphical, and multimedia (QuickTime) environment for something like Photoshop to run. That's a far cry from just getting Darwin running.

      The only legal way to get the Mac OS libraries is to buy Mac OS from Apple. Or reimplement them in a legally defensible way. Good freaking luck.
      • by Anonymous Coward
        Big deal. So you buy OSX 10.1 (can be found new and legally for 50 bucks) and you're set. I don't care if I don't get the whole thing for free or not as long as it works. What's the problem?
    • Which will come first - Apple cracking down or them getting WindowServer to run on i386?

      I'm betting that WindowServer is a PPC binary; good luck running it on x86.
  • What about... (Score:2, Insightful)

    by Squidgee (565373)
    Running Gnustep [gnustep.org] on NetBSD? It has most of the NEXTStep/OS X libs already ported over to Linux (And therefore easily ported to NetBSD)...
    • Re:What about... (Score:4, Interesting)

      by LizardKing (5245) on Sunday January 05, 2003 @12:23PM (#5019826)

      Running Gnustep on NetBSD? It has most of the NEXTStep/OS X libs already ported over to Linux (And therefore easily ported to NetBSD)...

      GNUStep is already in the NetBSD packages collection, in several packages split across devel and x11. Install it along with WindowMaker and you've got a convincing NeXT clone ...

      Chris

    • Re:What about... (Score:5, Informative)

      by SiMac (409541) on Sunday January 05, 2003 @12:56PM (#5019941) Homepage
      GNUStep allows for source-level compatibility. This is good for people who plan on targeting Mac OS X as well as Linux, but it's not good for people who want to run Mac OS X apps that run on Mac OS X but not on Linux, such as the Mac OS X window server and Finder. These applications would never be ported to GNUStep, as easy as it is, because Apple wouldn't do it. In addition, this should allow Carbon applications as well as Cocoa applications to run on NetBSD.
      • With binary compatibility in the applications objects, it should be trivial to build plug-in replacements for Apple's frameworks. GNUstep and Cocoa both use Objective C, which does not care about an objects structure, only about exported methods (contrary to C++). That means that it could indeed be possible to run Cocoa applications natively on NetBSD using GNUstep: after all, the Cocoa applications are completely isolated from the implementation of their window/GUI server.
    • Many Cocoa apps link to CoreServices for which there is no alternative.
  • This is a very cool idea. However, I'm willing to bet it won't look as nice as this [apple.com].

    This will be one of those things where it's cool because you can do it, but is there really any reason to do it? Kinda like Mac on Linux [maconlinux.org].

    • MOL (Score:4, Interesting)

      by dmaxwell (43234) on Sunday January 05, 2003 @12:59PM (#5019955)
      Um...I use MOL and have found it to be far from pointless. I use MOL mostly to run a FirstClass groupware client. The reason why I run Linux on a Pismo Powerbook is that I have an environment mostly identical to my x86 Linux machine at home. This means Linux largely frees me from worrying about underlying architecture (Wine and so forth aside). I have not found OSX to be so insanely great that I should blow away my Linux partition. Believe it or not there are good reasons to prefer Linux over OSX.

      I have also found MOL to be far more reliable than Classic on OSX. Classic is much slicker in that OS 9 apps run directly on the Quartz desktop and one can cut and paste between apps. This also means it is more complex and therefore failure prone. My boss has no end of trouble with it. Classic icons go missing or change themselves into another apps icons. Some Classic apps will lock and won't release control to the Aqua UI. This means the machine is locked up for end user intents and purposes. Classic inflicts HFS metadata problems and some instability on OS X and kills much of OS X advantages if one has to make heavy use of OS <=9 apps. On the other hand if the OS 9 in my MOL sessions screws up then I can kill it and restart without affecting my Linux session. Since I boot my MOL session from an image I have an advantage normally only associated with virtual PC. If that boot image gets messed up, I can replace it from a backup quickly. Incidentally, MOL is very close to running OS X acceptably...eye candy and all.

      MOL is can also be used as a user mode Linux. One can boot another acceptably fast Linux inside a virtual machine. This is useful for things like kernel development. MOL is far from pointless.
    • Actually, I use Mac-on-Linux pretty frequently. Linux has pretty weak support for HFS+ partitions -- even with the hfstools package. If I ever need to access a HFS+ formatted CD, I fire up MOL, mount my linux Home directory via netatalk, pop in the CD, and copy the needed files.
    • They aren't intending to recreate OS X bear in mind, it's merely a fun hack.

      In particular they aren't intending to recreate the widget toolkit it seems, or indeed, many of the libs at all, they just want Mach/Darwin compatability in NetBSD. You'd still need to buy a Mac with an OS X license for it to work.

      That makes it fundamentally different to Wine by the way for those who are wondering - wine is a complete reimplementation of the Windows APIs so you can run Windows apps without buying Windows. This is just letting NetBSD use some OS X code, not quite the same thing.

  • I wonder if this could be used to get an increase in speed for running OS X apps without the overhead of the OS X GUI? If it eliminates the eye candy effects, I'd bet it'd be noticeably faster.
    • No, from the page:

      Once we will have a fully functionnal Darwin binary compatibility on NetBSD/powerpc (if that happens some day), we will just have to grab MacOS X libraries to run any MacOS X program

      This means, NetBSD might have the original OS X GUI (including overhead and eye candy effects ^_^) in the future.
      Making GNUstep [gnustep.org] binary compatibe with Quartz should be the solution you're looking for (in that case, it would also work with the original Darwin).

    • No way!!! OS X is the best OS in existence!!! Because all the 520 Slashdot posters say so in their "Linux sucks OS X rules" posts!
      OS X's GUI slow? Are you out of your mind? Of course it's not slow! The highly advanced Aqua GUI is the fastest GUI in existence because of OpenGL acceleration! I don't have a Mac but Slashdot says so so it must be true!

  • If they'd get it running on x86 the slowness would most certanly be outweighted by the coolness.
  • by porkface (562081)
    I get the feeling this isn't the direction Apple had in mind when they released all that code. I got the feeling they wanted people working on compatibility layers for Darwin, not for non-Apple OSes. I think Apple has the ability to pull the plug at any time, so it might be nice to see some of this work going both ways.

    Most FreeBSD users I know have no interest in Photoshop or Office anymore now that the alternatives are as mature as they are. I think users of any BSD would enjoy this new compatibility, but I think it could be just as valuable to everyone (except MS) if MacOS X gained some compatibility layers.

    • If Apple were indeed so pissy about the use of their code they wouldn't have released it or based it on a fully documented Microkernel. They also probably wouldn't have based their application level API of choice on a fully documented API.

      It doesn't matter if someone writes an implementation of Cocoa and a Darwin binary compatibility layer for [insert kernel name here]. If you're running any of Apple's code it means you either bought the software from them or bought a machine from there that software came on. If I made cars and you bought one from me and promptly lit it on fire when you got home I would not car as long as your money was good.

      Having a binary compatibility layer like this means NetBSD could act as a drop-in replacement for Darwin at some point. The OO fundamentals of OSX are designed to allow this, even if it is someone else who does it. This sort of stuff just gives Apple more cool factor among the compile everything from source open source project hacking geeks that two years ago spoke their name with a spite and bitterness reserved only for a special few.
  • by gh0ul (71352)
    What about apps like iTunes, or iCal... wonder if those will work.. if it can do graphical apps, keep in mind there is Office v.X for MacOS X.. does this mean Word on BSD?!

  • by linuxislandsucks (461335) on Sunday January 05, 2003 @01:55PM (#5020263) Homepage Journal
    A question..

    The status report link is from 1/2002...

    Did anybody bother to read it before posting?

    70 people so far did not..

    The actual project ot watch is not NetBSd..in that they don't have the nice Apple relationship like Darwin does..

    In fact if my memory is right the proejct was stopped because they were duplicating Darwin's efforts..

    To see if MacOSx will run under intel machines check Darwin porject site not NetBSD!

    Come on People read once in awhile ..it will not harm you!

    Show yourself to better than those wintel geeks who don't even read but jsut spout what MS Gates wants..

    • WRONG (Score:1, Informative)

      by Anonymous Coward
      Besides the awful spallilng in this post, it is also wrong. The mailing list post referenced in the blurb is from 1/3/2003. Check [google.com] the Google mailing list archive if you want. Who the hell modded this troll up? Check first.
    • According to what their webserver said the last-modified date is, the page was last changed _yesterday_. I'm sure that the author is just doing what I've done so many times - writing the number of the previous year, because it's become burned into his brain.
  • OK, this is probably a stupid idea but..

    Anyone know what kind of speed a powerpc emulator running on a x86 would get?

    If this OSX apps on BSD/PowerPC jazz works, what would you get if you coupled it to a powerpc to x86 emulator and had OSX running on a x86?

    Even if it ran at half the speed you might end up getting a cheaper 'mac' because x86 hardware is cheaper?
    • Half the speed? A tenth of the speed would be more realistic I think. PPCs have 32 general purpose registers, which would have to be emulated on the register-starved x86. This would perhaps be feasible on an Opteron or Itanium but not on that 2 decade old POS called x86.
    • The speed would be shitty as I understand it. It is relatively fast to emulate x86 on the PowerPC architecture because you've got a metric buttload of GPRs to store whatever you need for emulation. The reverse is a problem since x86 has so few GPRs you need to spend lots of cycles just emulating the larger number of GPRs, far more than you're actually spending doing operations. You'd be running at around a quarter speed or less compared to a native binary. The most bad-ass Pentium 4 than is going to be running about the equivilent of a 700MHz PowerMac if that. For the price of that bad-ass P4 system you could buy a PowerMac off eBay or smalldog.
    • AFAIK - there is NO PPC emulator. Lots of hoaxes and vapor. No emulator.
  • Realizing the 'open source' (sort of) nature of Darwin, I've thought of doing this myself (for linux).. but just didn't have them time.

    For those who think this is a dumb idea.. you're not seeing the bigger picture. Currently, MacOS X only runs on G3 and G4 apple machines designated by Apple unless you boot Linux and install Mac On Linux (similiar to Plex86 for PPC). If you can run OSX applications on Linux, NetBSD, etc.. then you wouldn't need the overhead of a VM. Your RS6000 could run OSX with minimum overhead. From NetBSD you could run from the same machine, binaries compiled for: OSX, Linux, FreeBSD, and NetBSD.

    Personally, I don't like OSX; However, I wouldn't mind being able to run natively on Linux: Internet Explorer, Quarx Express, etc.. Not to mention that Quartz is a pretty neat looking, X11 compatable (with Xfree86-rootless) windowing system.

    This is more important for Linux than NetBSD, only because NetBSD currently has poor support for devices on many PowerPC machines (compared to Linux), especially laptops.
  • Every project needs a cool name. WINE is for running Win(dows) binaries. So what to call this?

    How about "OSXE"? Pronounced "Oh sexy."

All warranty and guarantee clauses become null and void upon payment of invoice.

Working...