Re: dos functions behave differently under windows XP
From: f0dder (f0dder_spicedham_at_flork.dk)
Date: 06/22/04
- Next message: f0dder: "Re: Virtual memory"
- Previous message: whisper: "Re: memory copying onto video memory"
- In reply to: Markus Humm: "Re: dos functions behave differently under windows XP"
- Next in thread: Zdenek Sojka: "Re: dos functions behave differently under windows XP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 22 Jun 2004 02:36:35 +0000 (UTC)
>> Flashing is actually possible directly from windows :)
>
> But afaik many do still provide a bootimage with some flavour of DOS,
> esp. since DR DOS 8 is around... hehe... ;-)
> Afaik M$ singed a treaty with Novell some years ago that would prevent
> Novell to release a Novell DOS 8 (has M$ feared this?), now we do have
> some sort of it and M$ can't do anything...hehe!
>
I used to do DOS bootdisk boots for flashing too, but it's rather
bothersome, and there isn't much reason for it. It's perfectly safe
under windows, you don't have to use a slow floppy drive, you can
do with a single reboot rather than win->dos->win, etc. I guess the
reason that many people still boot to dos to do it, is that not all
companies have released windows flashers, and that people are still
paranoid about running this kind of thing from windows.
>> And, well, you can still have as direct hardware access as
>> you want, if you write a kernel mode driver. Direct HW access
>> is rarely a good idea on a pmode OS though...
>>
>>
> Hm, depends. For drivers for the hardware it would be a good idea I
> think, otherwise they won't be able to use their hardware. But okay
> these drivers must comply to the rules of the driver APIs defined.
> Which could mean registeriung of used resources etc.
>
Yes, obviously the driver for a piece of hardware does need some form
of communication with the hardware :) - what I mean, though, is to
play by the rules of your platform, and on windows this means using
the HAL rather than direct port bashing (not too bad, considering the
latency of in/out), and following the driver model.
Oh, and not doing direct hardware access unless necessary. Things like
direct harddrive access, for instance, can be done through the win32
API. COMMs I/O, unless you need hispeed low-latency, can, too.
- Next message: f0dder: "Re: Virtual memory"
- Previous message: whisper: "Re: memory copying onto video memory"
- In reply to: Markus Humm: "Re: dos functions behave differently under windows XP"
- Next in thread: Zdenek Sojka: "Re: dos functions behave differently under windows XP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
