the true brilliance in mac os x lies in it's kernel

[nibs]

mac os x is built on top of a mach 3.0 microkernel. that microkernel (unlike the mach 2.5 kernel currently in darwin) has no os specific code. thus pretty much any other operating system can be run on top of that microkernel; furthermore multiple operating systems can be run simultaneously on a mach 3.0 microkernel. it sounds like apple is doing just that with their classic environment. i remember reading somewhere that the classic enviroment in os x was about 90% as efficient as regular mac os 9 and this is just on the developer's previews so that number is bound to grow larger. it seems like some institution could write a pc environment and expect to get performance similiar to the classic environment and probably better than mklinux (assuming apple has made further optimizations to that kernel since then). after the pc environment for os x is developed, all it would take is recompiling the original winapp source to run on that ppc architecture as opposed to x86. recompiling is much easier than porting. and once apple starts getting their g4 chips from ibm...hmmm...%90+ of a 650mhz g4 should easily blow away a 1ghz pentium or athlon chip. if only windows developers could optionally include altivec instructions just in case (or maybe you can just translate mmx/3dnow instructions to altivec)...
the apple open source project is currently looking for WinOs.app developers...

macintosh computers are the fastest platform for macintosh or windows applications...


[This message has been edited by nibs (edited 03-14-2000).]

[Orbit]

Okay.. why don't you take on this task? All you'll have to do is steal the source code from Windows from Microsoft, reverse engineer all of their proprietary technologies, and then rewrite the parts which are only in x86 assembly into PPC assembly. Pretty simple, huh?
I don't think there's anything intrinsic to Mach which makes it able to run multiple OSes on top of it.. I mean, you can set up an emulation environment over most any operating system (given that it has enough horesepower to support it). Classic, granted, isn't really an "emulation" environment in the purest sense, since OS 9 and OS X are both PPC binaries.
If it was a simple deal to create a PPC Windows (which used to exist before MS stopped targeting the PPC 620 based IBM machines), it would have already been done long ago. OS X doesn't change any of the technical details which make this absolutely impossible. Unless of course Microsoft decides to open source Windows....

I think I see pigs flying!!

[nibs]

actually, the people over at berkely have already ported dos to run on top of mach. what i was saying was if you recompiled windows app sources down to ppc binaries, all you would need is a WinOs.app type program to handle the native x86 system calls, and a modified ppc compiler which knew how to handle the x86 specific code (basically providing the new system calls which WinOs.app understands). that setup is different from a pc emulator in that dos would actually be running native with simply the dos kernel switched for the mach kernel, and the WinOs.app layer which handled the dos system calls, and watched over the dos environment preventing it from doing anything illegal in os x (since it really wouldn't have full control over the hardware). that setup should be much faster than any emulator, and basically similiar to that MacOs.app.
all you need is:
the modified ppc compiler (with the WinOs system calls)
the winos.app
the mach kernel makes this process simpler than other kernels because it leaves all the os specific code and functionality outside the kernel to be run either as servers or through emulation libraries or both. mklinux ran on top of mach. system calls in linux or mac os or windows are handled by the specific kernels. in mach all system calls are handled outside the kernel. which is why multiple os'es can be run simultaneously on top of mach.

[This message has been edited by nibs (edited 03-14-2000).]

[nibs]

more about mach:
mach was an operating system designed to be fully bsd compatible. mach 2.5 (the basis of darwin) contained the 4.3bsd kernel inside it, thus making it fully bsd compatible. mach 3.0 removed all the bsd code from the kernel, and had a server outside the kernel implement all the bsd functionality. this allows for other operating systems to be run on top of the kernel. bsd, dos, osf/1 and mac os have all been implemented on mach by the people at berkely

[This message has been edited by nibs (edited 03-14-2000).]

[Orbit]

And what I'm saying is that in order to create this "WinOS.app" you're describing, you would have to essentially rewrite windows without any knowledge of the source code. The reason Linux was able to be ported to Mach on the PPC was that Linux is completely open sourced. An app which would just re-interpret the WinAPI calls is a completely unfeasible and near-impossible thing to create. Like I said before, Virtual PC for the current Mac OS doesn't even attempt to touch emulating Windows itself on the PPC, but only the hardware on which it runs...which is an open standard.
Oh, and you mention the "DOS kernel"... sorry buddy, DOS has no kernel- it runs in real mode and needs to be mediated by the Windows kernel when Windows (95 and above) is running.

[nibs]

i see your point, i guess it would be an incredible feat to duplicate the windows api. it would still be nice to have.

when the people up at berkely ran dos on mach, it was back in 91/92. back then dos was a stand alone os and had a kernel; at that time they needed to write libraries to support the dos kernel routines as well as bios routines because dos apps at the time could bypass the kernel and communicate directly with the bios. they were able to run windows 3.0 applications as well as dos apps.


[This message has been edited by nibs (edited 03-14-2000).]

[natro301]

The API's could be taken from the open source project WINE�

P.S. Do you know where i could get the DOS port to the mach

[This message has been edited by natro301 (edited 06-17-2000).]

[natro301]

The API's could be taken from the open source project WINE�

[rogerk]

No, that Darwin runs on Mach 2.5 is not true!!! MacOS X Server runs on Mac 2.5 and Darwin was the first step to Mach 3.0!!!

[nibs]

rogerk:
you do not ressurect a 3 month old post to make an incorrect point. that's nonsense. darwin 0.1-0.3 was based on the same mach 2.5 kernel as mac os x server. darwin 1.0 & later uses apple's modified mach 3.0 microkernel. darwin was originally released as "the [crippled] underpinnings of mac os x server..." it was released simultaneously with mac os x server. it was later updated to become synchronized with the mac os x kernel...how could darwin have had a different kernel than mac os x server initially?
i really don't mean to sound rude, i'm just amused that someone would totally ignore the entire focus of my original post to pick out a minor detail...and then be wrong in the process.

natro:
from what i understand wine is written to support windows on unix within an x windows environment. the wine code might be usable, but it would either need to be re-written for aqua (quartz, quicktime & open gl) or an x windows port to mac os x would be required. seeing as x on darwin is a developing reality, that would probably be the easiest route, but since the darwin x port doesn't use any aqua interfaces (obviously) it wouldn't be the prettiest alternative. but wine ported to darwin is an eventual possibility.
apps would still need to be recompiled to ppc (unlike wine on x86 unix).
the dos emulator was available on the carnegie mach site somewhere, i'll look for it, and edit this post if i find it.
wine on darwin is a pretty good idea...if companies are willing to recompile their applications.

here's a link to the mach dos source:
the source (ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/src/i386.mdos.src.tar.Z)

here's the page i got the link from: mach info (http://www.cs.cmu.edu/afs/cs/project/mach/public/www/sources/sources_top.html)


[This message has been edited by nibs (edited 06-18-2000).]

[natro301]

thanks!