Running Mac OS X Binaries With NetBSD

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

Comments

Fantastic

[Evil Adrian]

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!

Neat but...

[MBCook]

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

[fdisk3hs]

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

Re:Neat but...

[Octorian]

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.

That's great news but...

[guroove]

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

[Burgundy Advocate]

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.

Re:That's awesome

[Doktor Memory]

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.

Re:That's awesome

[Ponty]

Isn't that because GNUStep is working on the open OpenStep specification?

Re:That's awesome

[IamTheRealMike]

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

[Graymalkin]

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.

Re:That's awesome

[andrewski]

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.

Re:That's awesome

[rweir]

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.

Now look what you did

[eyeball]

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.

Of course it runs NetBSD!

[RAMMS EIN]

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

Is this a de facto x86 OSX?

[Ars-Fartsica]

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?

Re:Is this a de facto x86 OSX?

[kakos]

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.

Re:Is this a de facto x86 OSX?

[xanadu-xtroot.com]

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

You still need a PowerPC machine

[zubernerd]

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


(This is not a flame, just an observation)

Re:You still need a PowerPC machine

[LizardKing]

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

Re:You still need a PowerPC machine

[Arandir]

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?

Re:You still need a PowerPC machine

[drinkypoo]

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.

Re:You still need a PowerPC machine

[tres]

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

Re:You still need a PowerPC machine

[RAMMS EIN]

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.

Nifty.

[Anonymous Coward]

Which will come first - Apple cracking down or them getting WindowServer to run on i386? Some info from http://hcpnet.free.fr/applebsd.html

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

Re:Nifty.

[Wesley Felter]

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

[Squidgee]

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

[LizardKing]

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

[SiMac]

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.

Re:What about...

[anarkhos]

Many Cocoa apps link to CoreServices for which there is no alternative.

I wonder if it will look as good as Aqua?

[Znonymous Coward]

This is a very cool idea. However, I'm willing to bet it won't look as nice as this.

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.

Re:I wonder if it will look as good as Aqua?

[killerc]

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.

Re:I wonder if it will look as good as Aqua?

[IamTheRealMike]

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.

Re:Great idea

[__past__]

... you only have to make sure both your windows and OS X binaries are for the same processor architecture.

Would It Be Faster Than OS X?

[Bones3D_mac]

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.

Re:Would It Be Faster Than OS X?

[KAMiKAZOW]

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 binary compatibe with Quartz should be the solution you're looking for (in that case, it would also work with the original Darwin).

Re:Would It Be Faster Than OS X?

[FooBarWidget]

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!

Re:Linux port?

[damiam]

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.

OK, but...

[caveat]

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

Re:OK, but...

[Reality Master 101]

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

[demon]

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:OK, but...

[Ponty]

No they don't. I can use OpenWrite.app on my NeXT until the day the darned thing turns to dust to edit my OpenWrite documents. I don't care if I have the source or not.

The line for me would be if I had to "subscribe" to my software to keep using it like MS wants. (I don't actually use Office, but bear with me.) If they ever did that, I'd standardize on a different program, or if none fulfilled my needs, I'd simply stick with Word 2000 or whatever the current version is.

Re:OK, but...

[Ponty]

The subtlety of your nuance is both redundant in its declaration and lacking in its application.

I don't recall ever claiming to be either official or correct. It's my opinion. Just like your opinion is yours. The statement of opinion embodies no claim to be officially correct or anything else along those lines.

Re:OK, but...

[Reality Master 101]

Only idealists can make positive change.

That's overly simplistic. As usual, reality is a lot more complicated.

There is no doubt that idealists (radicals if you will) can be a catalyst for change. But it's extremely rare that they actually make the changes. Almost by definition, idealists are incapable of implementing change because they want instant gratification and are impatient with the realities of implementation. And even then, they are often incapable of seeing a larger picture that reasonable people can disagree with their "idealism". Take environmentalism. If the typical idealist enviro had their way, every forest would be off-limits to logging. Period. But the ignores the reality that logging is not intrinsically evil, and that wood is a renewable resource.

I'm reminded of one of my favorite scenes from Lawrence of Arabia:

Feisal: The world is delighted at the picture of Damascus liberated by the Arab army.
Allenby: Led, may I remind you, sir, by a British-serving officer.
Feisal: Ah yes. But then Lawrence is a sword with two edges. We are equally glad to be rid of him, are we not?
Allenby: I thought I was a hard man, sir.
Feisal: You are merely a general. I must be a king...

It's up to us realists to slowly, painfully -- but practically and fairly -- make the changes that society needs. We are the ones that are most capable of seeing all the sides of an issue and balancing everyone's needs.

Like I said, idealists have a place as catalysts to move things along quicker than they might have moved along, simply because they raise the priority of something. But it's unfair and untrue to say that realists never make changes without them, because its simply untrue. Idealists just believe that to be true because the pace is always slower than they want it, and they don't see the realists as having the "passion" of change.

I agree with you about opportunists to some extent, in that they aren't often dedicated to "progress". However, that doesn't mean it doesn't happen by accident. Opportunists create a lot of jobs, which is the single greatest resource that can be created when it comes to social progress.

Re:Linux port?

[jelle]

Time for a PlexPPC, similar to Plex86...

Re:Linux port?

[KAMiKAZOW]

Mac-On-Linux

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.

MOL

[dmaxwell]

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.

Re:Linux port?

[KAMiKAZOW]

It does alredy exsist. It called Mac-On-Linux.

Not what Apple wanted

[porkface]

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.

Re:Not what Apple wanted

[Graymalkin]

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.

Re:Linux port?

[IamTheRealMike]

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.

The hardest part to imitate...

[Judge_Fire]

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

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

J

Re:Missing Apple libraries

[jaoswald]

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.

ah How DUMB are slashdoters?

[linuxislandsucks]

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

Re:ah How DUMB are slashdoters?

[demon]

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.

Re:Great idea

[AtATaddict]

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

maybe the way to a cheap mac?

[SKicker]

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?

Re:maybe the way to a cheap mac?

[Graymalkin]

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.

Re:maybe the way to a cheap mac?

[teamhasnoi]

AFAIK - there is NO PPC emulator. Lots of hoaxes and vapor. No emulator.

Re:Great idea

[kraksmoka]

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 what they're just gettin runnin for NetBSD.

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

If i only had more time.

[GiMP]

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.

Re:Linux port?

[Graymalkin]

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.

Re:Linux port?

[norwoodites]

*BSD's COMPAT_* are better than MOL and plex86 because there is no overhead of a secondary kernel.

Re:Linux port?

[drinkypoo]

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

Re:Missing Apple libraries

[jaoswald]

Perhaps surprisingly, it probably isn't illegal!

I'm assuming that this NetBSD kernel+shim is being used to replace just Apple Open Sourced components , in which case, you seem to fall within the scope of section 2B of the Mac OS X License.

To be totally careful, your step 2 would have to be Joe User nukes the shipped Darwin kernel with his new kernel, but I doubt it makes a difference, as long as it is the same computer; the computer can run only one of them at a time.

2. Permitted License Uses and Restrictions. ...
B. Certain components of the Apple Software have been or may be made available by Apple on its Open Source web site (http://www.opensource.apple.com/) (collectively the "Open-Sourced Components"). You may modify or replace only these Open-Sourced Components; provided that: (i) the resultant Apple Software is used, in place of the unmodified Apple Software, on a single Apple-labeled computer; and (ii) you otherwise comply with the terms of this License and any applicable licensing terms governing use of the Open-Sourced Components. Apple is not obligated to provide any maintenance, technical or other support for the resultant Apple Software.

Name for the project

[Mignon]

Every project needs a cool name. WINE is for running Win(dows) binaries. So what to call this?

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

Re:Linux port?

[axxackall]

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.

Re:Linux port?

[fgodfrey]

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.

Run it on FBSD

[nurb432]

That was my plan, as im sure it would be ported over.

I commend the NetBSD people, but i still use FreeBSD for now since im only running i386 chips these days.

Re:Run it on FBSD

[nurb432]

Emulation..

I read the word 'emulation' and I didn't see it specify which architecture, so one would assume its emulated.. sooo would run on i386 too..

I read it fast so I could have missed them saying it was ppc only..If so, then I guess I'm outta luck.

Re:Linux port?

[axxackall]

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?

~tell RAMMS+EIN

[SHEENmaster]

about html <br> tags.

Re:Linux port?

[fgodfrey]

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.