Slashdot Mirror
PetrOS - NT alternative?
Anonymous Coward writes "Trumpet Software, the company well known for its Trumpet Winsock package has been quoted in the
press as having their own version of a Win32 platform operating system, called PetrOS.
They are working out if they can release it without affecting MS's API intellectual property, from the
" They claim to have a 100kb microkernel, and run native NT executables. Anyone have more details?
The NT Kernel doesn't implement the Win32 API. That is implemented by another layer, a client layer that talks directly to the NT API (which is undocumented). The client layer is the Win32 API and runs alongside various other client APIs.
Putting the Win32 API directly into the kernel is short sighted, and implies that Win32 API is all that this kernel is capable of running. That means it's already nearly obsolete before it's even out the door.
In a sense, it's the equivalent of calling a kernel which has the BASH shell (and almost nothing more) directly into a lightweight kernel and claiming that it is a new lean-mean Linux.
Since the doj recognizes that spliting up ms would be worse to the IT industry, I wonder how serious they were with opening code. I read on zd that the doj was considering it as a more radical alternative if nothing else would work. We would have now 3 monopolies all shoving proprietary code down our throats instead of 1 and suns Scott McNeally acknowledges this if ms is split up. ATAT became more powerfull after it was split. I believe all the ms executives are behind this corporate screw up in the trial. This was just my opinion of course. Wouldnt it be great if win32 api's were freely available to all and we would have beos win32 for games and redhat win32 clone for workstations and servers and caldera and suse for win32 compadible bussiness desktops. Perhaps this new OS could also come into the picture.
:-(
After this the win32 will be everwhere though and be bad for possix.
But we would have choices and if all these different distros of windows (linux, be, ect)and if posix is included perhaps win32 would die.
Another great thing could happen with apple. Apple would relise that win32 is the thing after this new wave of windows clones and would add win32 api support into mac osx so non computer people could have access to a stable OS thats way easier and supperior to use then windows.
I truly hope that the doj will force ms to release the win32 api.
If they could get a current DirectX running on this (without the GUI), wouldn't this make a nice fast low-overhead environment in which to run my games ? (The only reason for Windows, after all.)
\\'
I did an experiment also.
Using VMWARE, I tried installing Windows NT Workstation 4.0 with varying memory settings. Here's the results.
8 MB = Refused to Install
12 MB = Refused to Install
16 MB = Installed, ran slowly
32 MB = Installed, ran much better than 16MB.
Then after I installed with 32MB, I started reducing the RAM on the already installed NT.
32 MB = Booted fine, as expected.
16 MB = Booted fine, but slower.
12 MB = Booted fine, but really really slow.
8 MB = Blue Screen of Death on bootup.
I thought it was interested that the installation program wouldn't let you install with 12MB, but that NT would boot with 12MB.
It sounds like he's concentrated on getting the command line programs working and doesn't have a GUI yet. Since (I'm guessing) the GUI is the bulk of the work, this hardly counts as a Windows clone.
But, I actually like the approach. I wonder if the Wine folks wouldn't have made faster progress by following the same strategy. As it is now, there are lots of programs that "sort of do something" under Wine, but few useful ones that really work 100%. If the command line stuff worked WELL it might draw more developers to finish the job.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
Those aren't part of the kernel though. They just provide API's to developers, that happen to implement some basic OS services (or what NT considers basic). The _real_ kernel is NTOSKRNL.EXE which on my work system (which I think is SP4) is 927,552 bytes (the bit that provides core system services like threading, process control, etc). Big compared to 100k, and huge compared to QNX Neutrino's 20k. I didn't want to refute your point - just provide a bit of accuracy.
,hacker Perl another Just)'
Matt.
perl -e 'print scalar reverse q(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Well, its a microkernel so that 100kB comparision to NT isn't really accurate. What the microkernel represents is the smallest amount of code that allows it to schedule processes, manipulate memory and load in other modules. As soon as a user does something silly like try to use it the microkernel will have to load in code that handles ethernet, graphics, input/output devices etc.
A more accurate comparision would be from a fresh boot what is the graph of memory consumption of each OS while running this script in SuperWizzyWorks 2000?
Whatever this PetrOS thing is, I've got to hand it to Trumpet Software - they *really* made a difference 6 or 7 years ago with their Trumpet Winsock stack. Way before Microsoft acknowledged the Net's existence, Trumpet was there to help us poor non-Unix folks get on the web. One of the few shareware programs I actually paid for. :-) I wondered what they were doing these days... I'm not sure there's much of a market for a TCP/IP stack under Windows anymore.
I wonder if these folks even realize the implications... forget embedded (win32 is a bad idea for the embedded market anyway), think emulation -- win32 drivers and applications running with no overhead under any OS you like.
If this is legal (and you can bet MS will be trying hard to prevent it from being) then we may just have hit the point where even OS-specific software and drivers aren't OS-specific any more.
Of course the obvious MS response is to immediately make some incompatible API changes that break this new micro-OS, and patent them so far up their asses that a programmer couldn't extract them without reaching down their mouths with a plumber's snake. We'll have to see how the legal side of this evolves.
1) You need a copy of windows to run. To do it legally costs $$$, especially NT.
2) Running a whole second OS is a serious resource hog.
3) It's effectively running on a second (virtual) computer, in its own little sealed box. Why not just get a second computer and a monitor/keyboard/rat switch?
Wine provides the Win32 system calls to a Linux process, allowing things like a windows CGI program to do credit card validation to be spawned from Linux' Apache. It may never run every windows program in existence, but:
1) Neither does any one version of Windows.
2) I don't own every windows program in existence. I only care about the ones I have (which these days, are mostly games, half of which actually run under DOS.)
3) This is legacy support. 50% of the legacy windows programs out there aren't Y2K compliant anyway, and an amazing number of people are limping along with "good enough for now" 3.1 installs left over from the 1980's for their daily word processing and checkbook balancing/payroll. (Sheesh, last year I helped a friend of a friend copy his comic book store inventory system from an old 386 SX with a 100 meg hard drive to an old 386 DX with a 200 meg drive. Only reason he left the old system was he'd tried Dos 6 doublespace and the drive started to eat itself.)
We don't HAVE to support the latest and greatest Windows apps, those companies are still around and we can lobby for a native version as we penetrate farther and farther into "grandma" land and our usage numbers go up with drool-proof interfaces like Gnome and automatic install/configuration and pre-installs. And we ALREADY support a lot of the old stuff, and creep farther every day.
The Wine people are adding new APIs faster than Microsoft is. They're better at it. Someday, they'll catch up.
Rob
I haven't seen it yet, but apparently NT5 has a "single user mode" that's command line only.
--
Business. Numbers. Money. People. Computer World.
Much less troublesome than the Trumpet Winsock was the Microsoft 32-bit winsock built in to Windows for Workgroups. (It's essentially the same 32-bit networking that's built in to W95).
--
Business. Numbers. Money. People. Computer World.
Actually, there is (WTS).
--
Business. Numbers. Money. People. Computer World.
Using NTFS for video? He deserved what he got. Keep in mind that NTFS was designed for increased reliability, not raw speed.
The times I've dealt with video capture on NT, I've given the capture software/hardware a raw AV scsi drive to play with... anything less really isn't worth your time unless your just fooling around.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
Inside the Native API
Inside Native Applications
Just out of curiosity, I took a look at native.exe (from the applications article) - the only dependency is on NTDLL.DLL, which weighs in at 347kb on my NT4 SP4 machine. Keep in mind that ntdetect.com, ntldr, hal.dll Though I have to admit the exports for it look a little weird... it looks like it implements a good chunk of the standard C library, and I want to know who thought exporting functions like "PropertyLengthAsVariant" were absolutely vital to the kernel...
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
It may be true, but it certainly can't be running an NT compatible Win32 system. The NT microkernel is but a tiny pary of the NT kernel. The microkernel is responsible for thread scheduling, multiprocessor sync, interrupt handling and little else. The mukernel needs the other kernel mode services (large) of NT to even begin to provide a Win32 system.
This sounds a lot like saying that Linux is capable of running a web server, X windows, Netscape, Emacs, yadda-yadda, and it can fit on a floppy too. Note, not at the same time, but it can. The floppy sized piece is a small part of the whole that can do wonderful things. I'm sure that the Trumpet people rely on other kernel mode services to provide a system that can run anything at all.
To their credit though, the Trumpet people couldn't take functionality OUT of the mukernel to reduce it's size to ~100K, so that size is a result of tweaks. But then again, we don't know how large that functionally comparable piece of M$-NT is per their distribution of it.
-- What you do today will cost you a day of your life.
Microkernels are a great way to do things.
:)
I've used/developed for QNX in a real-time environment, and I was very impressed.
But, the thing to remember is that small size comes at the cost of functionality and performance. After reading your link and some of the ones from there on, I'm under the impression that beyond a bootable POSIX, browser and web server, there's not much there on that floppy. And I noticed that it uses a two stage boot process to get going. Step one bootstraps a decompressor, and step two loads the decompressed system into memory. That OS, off the floppy, is probably on the order of 4MB+...
The QNX installation I worked with included a full OS (complete with those bells and whistles like grep, awk and vi), the full Photon windowing system (not just the GUI support for the browser) the developer support for TCP/IP, and Photon, and a nuts-to-the-wall C/C++ compiler from Watcom.
The install was about 100MB+, and still wouldn't run Quake.:) It's nice to have a 45K mukernel, but it is more important to have the code for the whole system efficient and fast. Even if the mukernel is half a meg, it must be fast before anything else - except where size trully matters, like on a satellite.
-- What you do today will cost you a day of your life.
That probably includes debugging code since it's a beta release.
If anyone is interested in learning about the NT kernel go to www.sysinternals.com. Learn more about our enemy....
It wouldn't be a true NT clone unless it crashed 3 times a day, and cost more than a typical family car to keep running.
Bowie J. Poag
The coolest thing about this is that with a 200kb NT, it would be possible to use it as an NT emulator, making it possible to load NT device drivers under other OS's. A little linux-NT bridge could easily be built, where the drivers would get all of the NT services they expect.
This would be very helpful for getting "alternative" OS's like BeOS, Linux, MacOS, OS/2, (and now, PetrOS) etc. running on currently unsupported hardware.
-m
Check out some _commercial_ unices, which _don't_ keep their kernels compressed like Linux - you'll be in about the same ballpark as NT's kernel booted - between 1.5MB and 3.5MB. Are _these_ slow and bloated? Kernel size measures _nothing_ (except maybe how small a system you could comfortably use on a stripped-down system).
Easter eggs. If you hold down QCKRTISO whilst saying the Lord's Prayer backwards and tipping milk into your keyboard, it displays random pictures from Bill's family photo album. This is why stuff like GIF decoders have to be in kernel space under Windows NT; the "photo album" Easter egg requires them to work.
While I think they are heading in the right direction, it doesn't sound like they have gotten very far according to the article. Thus far they have only run a command-line program that uses very few system calls (the Borland compiler). Consider what is needed by a compiler:
CreateFile, CloseHandle, etc. - Minimal file operations
VirtualAlloc, GlobalAlloc, etc - Minimal memory management
Plus a half a dozen misc functions. They state in the article that they haven't even started on the GUI, perhaps the hardest part. You can't just clone a few bits kernel32.dll and winnt.dll and say you have a windows clone. They also make no mention of how they plan to implement DDK which, IMO, would be the whole point of making a windows clone. Without device drivers what good is an OS?
The WINE project is *way* beyond this. Also WINE benefits tremendously by having a linux core and thus a solid device driver base behind it. Having said that, there are 2 problems with Wine. The first will probably never be surmounted, and that it will never be able support hardware that has win32 only drivers, and many of the APIs Microsoft has developed don't exist under linux so even if someone was willing and able to port, they couldn't. Take Direct3d for example. The best you could hope is to make a D3D->GL layer inside WINE, but it's not a very good mapping. Then there are weirder things like : CryptoAPI, Telephony API, etc.. where there is nothing at all like it under linux.
The second problem with WINE is that it is a single process solution. It makes no attempts to emulate the entire system, just the current process. This means you can't : debug a process, drag and drop, and other forms of IPC that many programs depend on. I believe this can be fixed, but will require a fairly big change to WINE.
Another project to look at that is very interesting is the FX!32 system by DEC. This system actually runs under NT, so they didn't have to write APIs except to thunk from 64->32->64. But it can run native intel binaries with very little slow down by doing dynamic code translation.
(wow, I just noticed "Linux" is not the Microsoft Spell Checker)
-- Virtual Windows Project
If this is true, and is running an NT compatible Win32 system, this shows how really inefficient the coders @ Microsoft really are (or are pushed to be)...
WaitForMultipleObjects
Afaik that doesn't do more than waiting for multiple objects to finish. In Unix, you could simply wait for each single one to terminate without much overhead (pthread_join).
MsgWaitForMultipleObjects
A design mistake (of Win32)
ReadFileEx/WriteFileEx
man aio
PulseEvent
You do know how to use message passing or other forms of IPC? The event functions could be easily replaced by pipes, for example.
Yes, I admit that Unix wasn't designed with multithreading in mind. In contrast, if you look at the recent standards formulated by POSIX and implemented by many vendors, you will notice that developing your application will not be limited by the API. In practice, being used to work with Microsoft "solutions" becomes a limiting factor.
Try implementing some applications using some of the extensive multithread APIs in the NT OS, such as
WaitForMultipleObjects
MsgWaitForMultipleObjects
ReadFileEx/WriteFileEx (async i/o)
PulseEvent (some of the event stuff is really cool)
and then come back and feel embarrassed for being an ignorant Linux would be all your life.
The applications may or may not be poor in your opinion. However the OS is fantastic. Some subsections of it are problematic (I don't like the registry as a device for instance, and it's support for multiple consoles is poor, and networked GUI), however the core of the OS is amazingly well thoughtout and designed by experienced software engineers.
Cheers
There are more than 1000 functions in the native API (ntoskrnl.exe + hal.dll are the modified microkernel). A minimum part is available to user mode via ntdll.dll. Unfortunately less than 10 per cent are documented by MS.
There is also a GPL'ed implementation of that microkernel: its name is ReactOS. It is planned a Win32 server on top of it and probably a POSIX+ one in the future. This project borrows some code from Wine. You can download the pre-alpha code (no GUI yet!) from www.reactos.com.