Slashdot Mirror
plex86 ported to NetBSD/i386
hubertf writes "plex86 is now works on a second Open Source operating system. So far plex86 only
supported Linux as host platform, and thanks to Frank van der Linden of Wasabi Systems, it
now also works on the i386 port of the NetBSD multi-platform operating system.
Tested operating systems include FreeDOS beta 4, MS-DOS 6.22, Red Hat 6 Linux and NetBSD 1.5.
See the NetBSD site for more information.
Any decently written application for a UNIX variant (including Linux here) should run with very little effort on any UNIX variant.
Alas there are more and more bad programs that use Linux peculiarities, making the port unnecessary hard (and thus sinning against the common UNIX philosophy).
The longer a program is isolated on one UNIX variant, the bigger chances are that it will be hard to port afterwards, that it will rely upon non-standard API's i.e. bad design. Thus it is good for the program to be ported ASAP.
Closed source drivers are not an issue, because most hardware is architechture-specific. Meaning that a driver for my PC's TV-tuner card would not be much use in my Apple G4, because my TV-tuner card won't work in my G4. Or my soundcard, or my videocard, or my modem. So there's no point in emulating the driver on a different system, because the hardware can't be used anyway.
So now we're written an entire processor emulator (x86 only) so that the very small minority of people that are using Linux on alternative hardware will be able to run WordPerfect? The majority of closed-source Linux applications that most people would want to run, are games. And games are very performance sensitive, so they don't take well to being emulated; a task that's guaranteed to kill your speed.
It's just not really a very useful feature to have.
Darwin is the core of Apple's Mac OS X but it's Open Source, BSD-compatible & runs on x86 as well as PowerPC. Indeed Apple has made special effort to release Darwin for x86, it's not just by happenstance.
Thus the original very cogent point that Plex86 could be ported to Darwin running on x86. No where was mentioned MacOS X or PowerPC (though they've been brought up many times in other places recently.)
I agree that this would indeed be very interesting, if only for the surrealism.
Who could have predicted 5 years ago that Jobs would return to Apple, have a coup & take over the company, then have Apple buy Next, Open Source the core of their OS, build in BSD-compatibility, make it backwards-compatible with the notoriously idiosyncratic MacOS then release it. To then put an emultor on top of this whole series of suprises would be frosting*.
Please folks, before you invest the effort into posting please read what the original poster says & not what you guessed from a quick scan.
* Yes there's VirtualPC etc. but they're MacOS-only and just not as neat as Plex86 though they're arguably more stable & more polished, as well as technically much more sophisticated.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
I would love to see plex86, bochs, or even VMware support Apple's Intel version of Darwin (aka OS X). I haven't been able to get it running on any CPU emulators or physical machines. It seems to me that these emulators would find quite a niche in the OS development market.
Can anybody explain, exactly, why some OS/emulator combinations don't work? I assume it has to do with unsupported hardware (i.e. Darwin only work with Intel PIIX IDE controllers, and maybe all the emulators emulate a VIA controller)
---- I made the Kessel Run in under 11 parsecs.
Normally porting any code to a different platform helps getting rid of platform specific bugs. This time it's "just" a different OS but it still helps Plex86 and NetBSD.
And I want to test running NetBSD-1.5 inside Plex86 running on NetBSD-1.5:)
This is muchos cool!
The classic "hello world" program in C can be ported to any OS. (Mac, Windows, etc.)
I generally agree with your remark about unix software being easily ported to other unix-alikes. At least for user-space things. For the most part.
Kernel space things may be much more difficult to port. You may be dealing with totally different API's. Or even different concepts, for an extreme example, such as kernel loadable modules, vs. VXD's, vs. Mac OS "Extensions", etc. (Using the term "kernel space" very loosly here.)
A bad program may, as you say, be unnecessarily be difficult to port. But a program difficult to port is not necessarily bad.
The question that has not been asked here is: how much of Plex86 is user-space? Doesn't it involve some Kernel trickery in order to achieve the virtualization? I got that impression from Kevin Lawton's paper here: http://www.plex86.org/research/paper.txt
I'll see your senator, and I'll raise you two judges.
Porting this to NetBSD really isn't the same as porting to Windows or BeOS. BSDs and Linux share a very similar programming interface, most software can be ported between Linux and the BSDS without too much extra work, and in the long run probably keeps code that may be very linux dependent from being introduced. The biggest effort in porting Plex86 was probably the kernel module, the rest probably just needs to be adjusted to not make use of a few linux specifics.
In the long run, a small outlay of effort porting to NetBSD gains more developers who could work on Plex86. A port to FreeBSD would also be a very good thing.
treke
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
First of all, Bochs is not exactly a superb emulator, but even if it was, why would having it as a kernel module be any better than running it as an application? Except that, as a kernel module, it's conceivable that it could bring your whole system down.
Implemented the way you describe, a kernel-level emulator could only allow binaries to be run on the same sort of system, with a different processor. So my x86 Linux binaries could be made to run on my Alpha Linux box. Where's the advantage there? It wouldn't let me run Windows applications on my Alpha, unless I installed Windows into the Boch's virtual hard drive. And that's no better than just running Bochs as a regular application.
The reason it is important to "port" projects over when there still in development, and far from complete is two fold.
One -- Once the full version is complete it will be very difficult to start porting it, having to deal with inconsitancies in unixes and other OS's. Not to mention optimizing it for a platform, may have to be done at a lower level, which would be easy if it were built into the tree early, and hard if it were done later (so it might never happen)
Two -- By forcing yourself to develop cross platform, you run into the limitations of your design and logic sooner, forcing you to fix it. Cheap workarounds get tossed out in favor of better solutions, because cheap workarounds and sloppy hacks are system dependant, and your working cross several platforms. Just look at what a POS Netscape 4.x is (ok so there is nothing better for unix at the moment) under unix, and under macintosh. It was designed for win32 first, and not designed cross platform. The win32 version is great, and I almost never have problems with it, although I cannot say the same for the linux/freebsd/mac versions. Now compare those to QuakeIII. I've never had it crash in windows, or in Linux, or on a macintosh. (I've had numerous QuakeII crashes under linux though) And its fast under all three systems.
Now nobody reading this here is John Carmack (exept of course for John, if he reads this far down in the posts) so yea, none of us are going to pull it off quite as well, but we can at least try. Come to think of it, its probably the least painfull way we could all improve our own projects.
You are only young once, but you can stay immature indefinitely.