Working Virtual Machine

[HStewartGitHome]

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.

[the-grue]

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!

[HStewartGitHome]

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.

[stsp]

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:

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

[HStewartGitHome]

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

[stsp]

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.

[HStewartGitHome]

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.

[stsp]

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.

[HStewartGitHome]

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.

[HStewartGitHome]

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.

[stsp]

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.