[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: direct hardware access



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