[Coco] Re: dskini.exe problems
stahta01 at juno.com
Tue Jan 13 19:09:45 EST 2004
I found a better link http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm
"John E. Malmberg" <wb8tyw at qsl.net> wrote in message
news:tjnyivnMxjCy at eisner.encompasserve.org...
> 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,
> probably a few other distributions.
> I do not know where I got the information about it's helper DLL as I can
> find that link at the moment.
> There is no requirement in Microsoft Windows that the CPU be put in real
> to directly access the hardware from an application program.
> Direct access to the hardware requires the code to run in a privileged
> and that means a device driver. The information needed to write such a
> is somewhat present in the MSDN documentation, but in my view it was too
> to use. In Microsft Windows, a device driver is written as a DLL and
> 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
> perform the real access. It is the APIs that are needed to change the
> size that were removed from this software simulation. Those APIs appear
> still be present in the BIOS. Windows 9x and later mosting use the BIOS
> booting, and ignore it afterword. Shadowing the BIOS into ram is just
> wb8tyw at qsl.net
> Personal Opinion Only
> Coco mailing list
> Coco at maltedmedia.com
More information about the Coco