[Coco] Re: dskini.exe problems

[Tim S]

I think I found a link to it
http://mirror.calvin.edu/suse/dosutils/rawwritewin/

NOTE: it needs a DLL if it is used on 9x Windows

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

>