Re: direct hardware access

["Patricia M. Godfrey" PriscaMG@xxxxxxxx]

flash wrote:
> ≪create a simulated environment for them in which they _think_ they are getting direct hardware access but aren't really.≫
As I think I've said, I cannot absolutely confirm this, but I _think_
all protected mode opsyses, which includes Win 95 and up, create a
simulated environment. Certainly the 640 K of RAM in which DOS apps run
is not really the lower 640K. If it were, you couldn't have two DOS
sessions running simultaneously. I think Win maps out a block of RAM and
"tells" the DOS app, "this is the lower 640K, and as much expanded and
extended memory as you've asked for." The real addresses are something else.
> That is why Patricia is getting hard reboots with blank-screens; HAL was invented to redress just
> this case.
It doesn't happent that often. In fact, this was the first time I think
on this machine. (The Duron did it a couple of times, but that was
probably the hard drive getting ready to short out, as it eventually did.)
> I'm not sure that direct access to hardware was why Xy was blazingly
> fast; in Win9x days, lots of programs had direct hardware access and
> weren't blazingly fast. I thought it was because Xy was efficiently
> written, used memory efficiently, and made no concessions to the
> buzzers-&-bells GUI mentality of MS-Oriface. Maybe I'm wrong about that.
All those reasons apply, as does the fact that it was written in
Assembler, which is evidently the leanest, meanest coding there is. I
should have said, "one of the reasons." But "used memory efficiently"
probably implies using some memory that DOS wasn't really supposed to
use, but that was just sitting there. Lots of apps of that period did that.

Patricia M. Godfrey