On Aug 8, 8:22 pm, Mark Kent <mark.k...@xxxxxxxxxxx> wrote:
> Linonut <lino...@xxxxxxxxxxxxx> espoused:
> > * Tim Smith peremptorily fired off this memo:
> >> Come to think of it, Windows 95 did a similar thing with DOS. DOS would
> >> initialize the hardware, load Windows 95, then Windows 95 would
> >> virtualize that DOS.
That's half right. Remember that MS-DOS was very "light" compared to
the rest of Windows 95, consuming only about 500 KILOBYTES of RAM,
while the rest of Wnidows 95 needed about 16 megabytes of RAM to run
smoothly.
The MS-DOS worked a bit like the VMWare hypervisor, a stripped down
kernel that just did the core functions. Once you were in "Windows"
mode, if you wanted to access the "console", you got a console window,
which called the same "system" calls as "real" DOS, but actually
called the windows display and I/O functions, since the "real" work
was being managed by the Windows kernel.
Again, this is not a "new" concept, IBM has been doing it since the
1960s, on their mainframes, and minicomputers such as the AS/400.
They also use this technology in AIX, and contributed some of this
technology to Linux.
Once the drivers and interrupts were isolated from the kernel using
message queues, the "bare bones" kernel used by ESX needed almost
nothing but the device drivers. The kernel could be less than a
megabyte, and the hypervisor could just translate VM calls into kernel
messages. At that point, the "console" would just be another VM,
which could send system requests to the hypervisor for configuration
purposes.
Keep in mind that many virtualized servers and even virtualized
desktops use hardware controllers that simplify interaction with
storage such as SAN or Serialized storage (SATA, SAS), so the hardware
just translates a physical "block number" into the correct drive,
cylinder, track, and sector set.
Linux drivers can also do that translation if necessary. The virtual
machines can use either virtual drives, or logical volumes spanning
any number of drives.
> Windows 95 would virtualise the DOS? I don't think so.
Once Windows 95 was started, anything that looked anything like DOS
would have to be serviced by the kernel. Windows 95 used a DOS
virtual machine that was originally developed by Quarterdeck for it's
Desqview product, which was pretty much locked out of the market by
Windows 3.0 and Windows 3.1. Desqview/X was designed to work as an
X11 "server" and applications could run using DOS graphics calls which
were converted to X11 commands which were then translated back to DOS
graphics calls or Video chip graphics calls. It was actually a very
good fit for Windows 95 and made it possible to run multiple "DOS
Windows" that could be active at the same time.
> I think his final claim is just wrong. A "thunk" layer springs to mind,
> although I forget the details.
Thunking was a problem when switching from 32 bit code to 16 bit
code. It was a particularly acute problem for early Win32
applications running on Windows 3.1, there were some severe problems
with Win32 configured Windows 3.1 or Windows for Workgroups crashing
far more frequently.
By the time Windows 95 came out, the system and drivers were 32 bit
based, and the 16 bit applications ran under that Quarterdeck
Emulator.
And by the way, the Quarterdeck Emulator was NOT stolen by Microsoft,
and was probably one of their better aquisitions, since it's ability
to reliably and effectively run both 16 bit and 32 bit applications as
a key element in the success of Windows 95 when Windows NT 3.x had
been such a terrible flop (It had a terrible time running 16 bit
applications).
|
|
