pcmos386v501
pcmos386v501 copied to clipboard
roelandjansen
Working Virtual Machine
I have a working virtual Machine of PC-MOS/386 which is really amazing since when I was working on PC-MOS in the Late 80's or early 90's, Virtualize the 386 was consider not possible and something the Intel Architects were working on it.
The virtual machine has a Gig of storage and 16 meg of memory and $386.sys does function which was the big surprise. This was created on VMWare and not sure if anybody else has done this.
Hey Stewart! I haven't tried it on VMWare, but I use VirtualBox a lot for working on my open source projects. I do a lot of development work on Linux with DosBox as the glue.
At one point, I had PC-MOS/386 running in a VM with 4 virtual serial ports that connected over to a Linux VM. Using this, I could have several virtual serial "users" on at the same time. More of an "I wonder if this works..." exercise and, surprisingly, it did work!
At the time Software Link was having troubles, and I went to Intel for Interview that did not work because at time they want C/C++ developers and I remember talking to P5 (Pentium Architect) and he mention that they working on Virtual 386 - at that time I wanted to add support for Windows 3.1 which had additional issue where Microsoft did not allow it to be DPMI client because of issue with IBM and OS/2 at that time.
This Repo brings back a lot of memories.
when I was working on PC-MOS in the Late 80's or early 90's, Virtualize the 386 was consider not possible and something the Intel Architects were working on it.
The problem basically bailed down to 2 things:
- Intel allowed to read system registers (CRx, IDTR, LDTR, GDTR, TR) from user-mode, so the classical trap-n-emulate approach didn't work: you couldn't fake the values of these registers. The guest would read the real values set by the host, no matter what. This was recently amended by UMIP addition, but they still forgot about popf, which, when run in user-mode, would ignore IF flag, not allowing you to virtualize it. Spectacularly, the PVI extension that was supposed to allow the virtualization of IF, also forgot about popf. Intel is very funny.
- Virtualizing MMU was problematic because the host OS and the hypervisor itself pre-occupy some address space, so what would you do if the guest also maps that same space?
So after a few broken attempts, they just looked into the nested execution framework on AMD chips, and implemented VTx.
And there are many other examples when Intel looks like the place driven by idiots. :)
Note that today the CPUs are very powerful, and the JIT techniques are very advanced. Even without hardware-assisted nested execution, you can virtualize intel CPUs with an adequate performance by using the JIT engine. This was of course not possible when you worked on PC-MOS.
The virtual machine has a Gig of storage and 16 meg of memory and $386.sys does function which was the big surprise.
It was probably a surprise for you only because run.sh doesn't do that. But run.sh is just a quick way of checking your build, w/o creating any bootable images and running virtual machines. With a full-blown virtual machine you can of course get everything to work as it should on a real PC.
at time they want C/C++ developers
Was C++ popular in 80s? I suppose you mean C here.
P5 (Pentium Architect) and he mention that they working on Virtual 386
That was likely PVI - as I said, they forgot about popf, so basically it was just another broken attempt. They never managed to fix virtualization, and at the end, just looked into AMD work and implemented the nested execution framework instead of infinitely keep trying to fix the virtualization.
I wanted to add support for Windows 3.1 which had additional issue where Microsoft did not allow it to be DPMI client because of issue with IBM and OS/2 at that time.
But does MOS have a good enough DPMI server to handle that kind of things? I very much doubt. But if it does, then it would be cool to implement another variant of $386.sys - as a DPMI client. Much better compatibility, will even work with run.sh.
My thought it must be VT-x and not supported in the Pentium
I remember playing with C++ in the 80's and have Stroustrup book in my lap currently - But it copyright 1990 - so possibly not much in the 80's
As for DPMI - if I could remember it was hybrid between _386.asm and _dpmi.asm which I not sure the source ever survived over the years. I went to Microsoft because of work on DPMI - actually another failed interview.
I was at The Software Link until April 1992
My thought it must be VT-x and not supported in the Pentium
If that was 80s, then most definitely not, as according to wikipedia, the first VTx-enabled CPU was released in November 13, 2005. PVI appeared around 1993 I think, so looks way more plausible for your story. :)
I remember playing with C++ in the 80's and have Stroustrup book in my lap currently
Unless you already had a look, you would probably be amazed with how different it is now to what it was back then. :)
As for DPMI - if I could remember it was hybrid between _386.asm and _dpmi.asm
Oh, you mean _386.asm as a dpmi client? But that would be cool to have! Sad you have lost it.
I went to Microsoft because of work on DPMI - actually another failed interview.
Perhaps dpmi was no longer compelling in their view. :) Although its quite strange, as even WinME is built on top of DPMI to some degree.
If that was 80s, then most definitely not, as according to wikipedia, the first VTx-enabled CPU was released in November 13, 2005. PVI appeared around 1993 I think, so looks way more plausible for your story. :)
Yes at time of talking to Intel, it was not possible. But they were working on it in the future.
Oh, you mean _386.asm as a dpmi client? But that would be cool to have! Sad you have lost it.
If I remember correct it was sort of hybrid extra driver that was tied to _386.ASM with additional functionality. But I gave it up when Windows would not accepted it as client. I got interesting message on CompuServe that only person could answer the question is Steve BaImer or Bill Gates and not related to my company.
Yes at time of talking to Intel, it was not possible. But they were working on it in the future.
Over 15 years later future! Almost a time machine. PVI would be only a 3-4 years future, which doesn't sound like a time machine to me.
Windows would not accepted it as client.
This is very very strange. Microsoft could have problems with winos2 because os2 replaced windows's DPMI server, and only left the windows's DPMI client part (and even that - in a patched form) under their own DPMI server.
Now as you wanted only to write a DPMI client for windows, rather than to replace their DPMI server, there couldn't be any problems at all, because everyone and his dog wrote a DPMI clients for windows-3.1. There was no need to contact Steve Balmer to just write the DPMI client for windows.
It was a political statement because of situation between Windows and OS/2 Warp at the time. In the end it did not matter much. OS/2 is dead.
Keep in mind I was trying to make Windows 3.1 386 Protected mode a client of PC-MOS so it could run on top PC-MOS and Windows 3.1 block the calls to make it happen. I forgot the actual calls but I have actual specification somewhere.
Unless you already had a look, you would probably be amazed with how different it is now to what it was back then. :)
I actually found an older Stroustrup book from 1986 which when I graduated GaTech and started at Software Link. C++ then was like Turbo Pascal was and it change quite much over the years. It ways it change into todays C# and Java languages. The big problem today is that C++ has much more limited employment opportunities and assembly has even less.
Keep in mind I was trying to make Windows 3.1 386 Protected mode a client of PC-MOS
OK, so you probably indeed wanted to replace their DPMI server then. :) As this is what os/2 did, and that's what became problematic with MS, AFAIK.
It ways it change into todays C# and Java languages.
In some ways - perhaps yes (eg they only prepare the reflection feature for the next C++ standard, and other languages already have it), but AFAICT C++ is also heading towards zero-overhead abstractions, to favour generic programming rather than OOP, to functional programming, and to many other things that would keep making it special and interesting. :)
The big problem today is that C++ has much more limited employment opportunities
I wouldn't say that, because I have friends that went to google to work on chromium, and its all C++. yandex also have lots of C++ developments. I just think that the C++ employment opportunities require much higher skills now than it was 20+ years ago, as the C++ niche have shifted to completely different areas that most of other modern languages do not cover.
and assembly has even less.
As a primary skill - of course. But basically any os or hypervisor developers are interviewed for an assembly knowledge among other things. I.e. I wouldn't expect any success for a system-level programmer w/o any assembly knowledge.