[Coco] Re: dskini.exe problems

[John E. Malmberg]

In article <bu0s4o$a5d$1 at sea.gmane.org>, "Tim S" <stahta01 at juno.com> writes:
> I looked for rawrite_win could not find it, but found ntrawrite.
> http://ntrawrite.sourceforge.net/
>

The actual program name is rawrwitewin, and it is part of RedHat and Suse, and
probably a few other distributions.

I do not know where I got the information about it's helper DLL as I can not
find that link at the moment.


There is no requirement in Microsoft Windows that the CPU be put in real mode
to directly access the hardware from an application program.

Direct access to the hardware requires the code to run in a privileged context,
and that means a device driver.  The information needed to write such a driver
is somewhat present in the MSDN documentation, but in my view it was too sparse
to use.  In Microsft Windows, a device driver is written as a DLL and sometimes
given the extensions of .drv or .vxd.

This is different than the usual mode that a DOS box runs in.  A Dos box
usually runs in x86 emulation mode where the direct access to the hardware
or the bios is simulated by software exceptions that use a device driver to
perform the real access.  It is the APIs that are needed to change the sector
size that were removed from this software simulation.  Those APIs appear to
still be present in the BIOS.  Windows 9x and later mosting use the BIOS for
booting, and ignore it afterword.  Shadowing the BIOS into ram is just wasting
RAM.

-John
wb8tyw at qsl.net
Personal Opinion Only