I would have to say that you are right......., to a point. The way that
Windows actually functions is by swapping in and out many modules to a
"kernel" which sits on top of command.com. Each of these modules can only
access certain information directly, and the rest of what each one does must
be handled by WinAPI member functions of the various appropriate classes.
So in a way it is a hardware multiplexer, but only to a point. This limit
is best shown by running XTreeProGold in a dos window. XTree does all of
its own disk operations directly (pissing off windows...), and thus it does
not run inside of a true "virtual machine" at all. As for the idea that
different types of applications run differently in the API based on their
word-length--that is also not quite the case. 16-bit apps are serviced by
the rundll.exe module and (originally) kernel.exe while 32-bit apps are
serviced by the rundll32.exe module and kernel32.exe. All Win32
applications are still only modules of the base "kernel" of the API handler
code set. Anything that does not run as a swappable module is run as a
client to a windowlap.exe module "semi-virtual-machine" in which there are
no true virtualization protections (see the XTree example).
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of X-Odus
> Sent: Wednesday, September 20, 2000 1:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Thoughts. (multi processor)
>
>
> I don't think many people realize that windows in itself is a hardware
> multiplexer. Just full of VM's. To my knowledge each and every
> program is run
> in its own VM (except for 16bit apps that are all run in the same one).
>
> Drew Northup wrote:
>
> > I think you forgot something......: MS-Windows isn't an
> Operating System in
> > the purist sense. Command.com will let you block disk access for a time
> > (that is how the old NDD 7.0 and Speedisk (4.0?) used to work under DOS
> > without getting "interrupted" by a disk write), but kernel.exe and thus
> > kernel32.exe are "simulated multiprocessing" handlers, and thus
> you cannot
> > (currently.., the people at MS are working on this) properly "lock out"
> > access to a disk (or anything else for that matter) unless you
> are talking
> > specifically about the "critical time" for each Win32
> executable (which are
> > all modules of kernel(32?).exe)--which is locked out to prevent massive
> > horrid errors in any form of execution that may take place on
> the machine.
> >
> > Drew Northup, N1XIM
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf
> > > Of Kenneth Arnold
> > > Sent: Wednesday, September 20, 2000 12:15 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Thoughts. (multi processor)
> > >
> > >
> > > On Tue, Sep 19, 2000 at 07:49:51PM -0400, Drew Northup wrote:
> > > > Great thought..., but once again Intel has broken it before you
> > > could even
> > > > try. The main problem with the multiprocessor argument is
> not just the
> > > > ring0 code (which is a real pain) it is also that SMP was
> > > designed with the
> > > > intention that you never know what process is running on which
> > > processor,
> > > > and thus the user level stuff doesn't know any "better" as
> to what it is
> > > > really doing at the hardware level. OH well, maybe later.......;^)
> > > >
> > > > As for using a hard drive instead of a file, you have one MAJOR and
> > > > undeniable sticking point.....partition tables & hard drive access
> > > > permissions. In LINUX and other UNIX-like systems, you must
> > > mount a drive
> > > > manually. However, in many, many other systems, a hard drive
> > > partitions of
> > > > a matching type are AUTOMATICALLY mounted on boot. Thus
> you'd have two
> > > > systems writing to a filesystem that they can both see AT
> THE "HARDWARE"
> > > > LEVEL and there is no host, no master, no "in charge"
> system controlling
> > > > disk access. This leads to unbelievable data loss and other
> > > catastrophic
> > > > problems. If you'd like proof of this, set up a joint scsi bus
> > > between two
> > > > machines, format a partition on a drive as something that
> they can both
> > > > access as something that they can both access, and then make
> > > sure that they
> > > > can both mount the partition. Then try to write to the
> drive from both
> > > > machines simultaneously. The drive will become
> unrecoverably corrupted.
> > > > Granted, we wouldn't be trying to do exactly the same
> thing, but I think
> > > > that I made my point that the logistics of the issue of RAW
> > > disk access by
> > > > the guest are just way beyond what we would even want to
> > > consider right now.
> > >
> > > So you do like dosemu and "strongly suggest" unmounting the drive
> > > first. Or,
> > > if you're really keen at hacking code, write a filesystem access
> > > layer. Sounds
> > > quite a bit too hard to work on right now, though. As for the
> > > other systems,
> > > there is usually some kind of locking mechanism to at least
> > > prevent fsck-type
> > > utilities from mucking around with it at the same time (which
> > > would be the only
> > > real cause of concern if you find a way to tell the OS to
> keep its buffers
> > > flushed) -- I'm thinking Windows here; Norton Disk Doctor somehow
> > > puts a "lock"
> > > on the drive and Speed Disk complains about that. Considering how
> > > much other
> > > stuff you can muck around with in Windows, I wouldn't be at all
> > > suprised to
> > > find a way to do all fs ops async, disable all disk caching,
> > > and/or totally
> > > block access to a partition for a certain length of time. Of
> course there
> > > will always be the user who thinks that they can run Linux under
> > > Linux using
> > > raw access to the same partition... oops.
> > >
> > > Kenneth
> > >
>
>
