[Coco] Re: dskini.exe problems

[Tim S]

I found a better link http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm

Tim S

"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,
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
>
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>