Isn't this protected mode, some new technology invented *grin* by NT?

On Wed, Sep 20, 2000 at 11:24:53AM -0600, X-Odus wrote:
> 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
> > >
> 
> 

Reply via email to