I'm finding that some old programs which worked perfectly under DOS,
Win95 and Win98 behave differently on XP unless I invoke them from
within COMMAND.EXE instead of running them in a console window
(CMD.EXE).
 
Here's a sample prototype program that is designed to be a transparent
filter. It copies std in to std out *exactly*, without the translation
sometimes done by C programs. Note that this is in the form of a debug
script.

--- cut here ---
a 100
;read:
mov ah,3f          ;read
xor bx,bx          ;std in
mov cx,-300        ;# chars
mov dx,200         ;buff
int 21             ;dos fct
jc 11b             ;err:
mov cx,ax          ;# read
jcxz 11b           ;eof:
;cx = # chars, dx = buff
mov ah,40          ;write
mov bx,1           ;std out
int 21             ;dos fct
jnc 100            ;read:
;err:
;eof:
ret
;end:

r cx
1c
n filt.com
w
q
--- cut here ---

If I enter the command lines

filt
filt

the second time the program exits without waiting for input. (XP Home
or XP Pro, SP1) but it does work properly when input is redirected to
a file.

Also, I've noticed that CMD.EXE interprets command lines containing
input redirection and pipes differently from DOS, Win 95 and Win 98.

On DOS or older Windows:

 foo | bar <baz.txt

feeds the contents of baz.txt to the pipeline "foo | bar" while on XP
it needs to be:

 foo <baz.txt | bar

Suggestions? Are there some other DOS calls I should be using to avoid
this behavior?

"E P Chandler" <epc8@juno.com> wrote in message
news:7f64e2ff.0406122201.483df3e1@posting.google.com...
> I'm finding that some old programs which worked perfectly under DOS,
> Win95 and Win98 behave differently on XP unless I invoke them from
> within COMMAND.EXE instead of running them in a console window
> (CMD.EXE).
....
> If I enter the command lines
>
> filt
> filt
>
> the second time the program exits without waiting for input. (XP Home
> or XP Pro, SP1) but it does work properly when input is redirected to
> a file.
....
> Suggestions? Are there some other DOS calls I should be using to avoid
> this behavior?

Once you terminate input with EOF (^Z), subsequent invocations do
mysteriously fail.  Perhaps the DOS emulation layer is expecting you to do
some cleanup before you terminate the program?  It works correctly when run
under COMMAND.COM, so if you need backwards compatibility, use the correct
interpreter.

> Also, I've noticed that CMD.EXE interprets command lines containing
> input redirection and pipes differently from DOS, Win 95 and Win 98.
>
> On DOS or older Windows:

DOS does not interpret command lines; COMMAND.COM does.

Non-NT-based versions of Windows also use COMMAND.COM.

>  foo | bar <baz.txt
>
> feeds the contents of baz.txt to the pipeline "foo | bar" while on XP
> it needs to be:
>
>  foo <baz.txt | bar

CMD.EXE is not COMMAND.COM.  The former is a Win32 program which opens a new
DOS emulation session for each COM or MZ EXE command.  The latter is a DOS
COM file run under a single DOS emulation session, including any commands
you enter.

CMD.EXE is not backwards compatible with COMMAND.COM, though it has a
similar interface; that is why NT-based Windows versions still provide
COMMAND.COM.

S

-- 
Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

"E P Chandler" wrote:
> I'm finding that some old programs which worked perfectly under
> DOS, Win95 and Win98 behave differently on XP unless I invoke
> them from within COMMAND.EXE instead of running them in a
> console window (CMD.EXE).

1) command.exe is really command.com

Just adding something that kind of supports what you are saying.

In using XP:

I've noticed that SOMETIMES, when I start cmd.exe, the processor
goes into a 100% useage state. This is particularly true if I first run
Programmers WorkBench ( PWB.EXE ) from the cmd.exe. Not
only that, but it doesn't do this 100% of the time. It seems to start up
after a certain set of programs are run, or if the computer hasn't been
rebooted in a month. There seem to be some serious memory mgmt
problems in XP that didn't exist inside of Windows 98. :-)

I've believe that XP is just as buggy or even buggier than the first
version of Windows 95. Microsoft introduces new bugs with each
update they provide, so it keeps getting buggier and buggier.

Basically, whenever you run a DOS program you need to be
aware of what was running prior to starting a cmd.exe prompt.

I got around the 100% CPU useage last week by typing the
following at the DOS prompt:

start command.com

There are some options you can apply to the start command,
and I won't say that starting PWB.Exe pushes the processor
into 100% useage state all the time, as currently, tonight, it
does not do it tonight. So I'm thinking the problems I had
a week ago are currently resolved and that they were due to
another application that might have run in the last month.

It was pushing ntvdm.exe up to 100% in processor useage
and the machine would slow down 100000%. The room temp
went up a degree or two as well. :-(

Make sure you grab last weeks updates. I think there was an
update last week and maybe that fixed the problem.

HTH.

-- 
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.

> I've noticed that SOMETIMES, when I start cmd.exe, the processor
> goes into a 100% useage state. This is particularly true if I first run
> Programmers WorkBench ( PWB.EXE ) from the cmd.exe. Not
> only that, but it doesn't do this 100% of the time. It seems to start up
> after a certain set of programs are run, or if the computer hasn't been
> rebooted in a month. There seem to be some serious memory mgmt
> problems in XP that didn't exist inside of Windows 98. :-)

There are. XP has problems with app working sets vs. cache balancing and 
nonpaged memory fragmentation. Once, after running without restart for 
about a week, XP refused to allocate 8MB of contiguos memory (on a 512MB 
machine!) for my driver. I can't believe that it happened due to lack of 
nonpaged pool, since its usage was not greater than usually. But after 
rebooting, everything worked OK.

> I've believe that XP is just as buggy or even buggier than the first
> version of Windows 95. Microsoft introduces new bugs with each
> update they provide, so it keeps getting buggier and buggier.

Say - the first version of Windows NT. It is what 2000 and XP inherit from. 
But Windows 9x are much MORE buggier than all NTs together.

> I got around the 100% CPU useage last week by typing the
> following at the DOS prompt:

That's why when I start DOS programs, I usually set ntvdm.exe priority to 
Low.

-- 
Ivan

"Ivan Korotkov" wrote:
> But Windows 9x are much MORE buggier than all NTs together.

Thanks for the comments, Ivan. I'm not starting an argument, just
going to point out some things.

There was one year that I installed over 1000 systems with
operating systems, and by far the most installed operating system,
I have ever installed is Windows 98. That used to be and maybe
still is my favorite OS. I haven't used it in a year or 18 months
though.

I said WinXP is very buggy and buggier than the first version of
Windows 95. I still stand by that statement. But I'll disclaim that
I am only speaking in a hardware point of reference and in
reference to Plug and Pray and the drivers that are installed.

I am aware of the fact that people have had Win NT 4 up and
running for years at a time without a reboot, and I have done the
same with Windows 98 as well, and the only reboots done on
such a system were because of software installations requesting
a reboot. There are and/or were ways to prevent having to do
a Windows 98 reboot after a hardware install, and Windows
2000 was supposed to do this for the Win NT family, but
Microsoft has pushed the reboot problem into Windows 2K,
as it is during the reboot, that the system files are backed up and
it's always good to have that good configuration in place in case
the system fails for whatever reason. The same is true for Win98
and all operating systems that followed.

I still believe the plug and play on Windows 98 has fewer bugs
than any other Microsoft operating system that is currently
available, unless Microsoft updated that plug and play software
in order to create bugs so they can sell a newer OS.

I think Windows 98 handles bugs and system crashes a little
better than Windows XP. I've had seen more crashes on Win2k
systems as well.

The CTRL+ALT+DEL sequence brings up TaskMan.Exe and I
will agree with you that the TaskMan.exe program with WinNT
is much better than the one that comes with Win98 or even any
Win9x but that is just a small program that handles the details
in very specific situations. The window it displays is definitely a
much nicer window than what you get with Windows 98/Me.

-- 
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.

"Jim Carlock" <anonymous@127.0.0.1> wrote:
>
>In using XP:
>
>I've noticed that SOMETIMES, when I start cmd.exe, the processor
>goes into a 100% useage state. This is particularly true if I first run
>Programmers WorkBench ( PWB.EXE ) from the cmd.exe. Not
>only that, but it doesn't do this 100% of the time. It seems to start up
>after a certain set of programs are run, or if the computer hasn't been
>rebooted in a month. There seem to be some serious memory mgmt
>problems in XP that didn't exist inside of Windows 98. :-)

Are you joking???  There has never been a Windows 98 machine that could go
a month without rebooting.  48 hours was an outstanding record.

I'm not sure why you don't blame PWB for your problems.

>I've believe that XP is just as buggy or even buggier than the first
>version of Windows 95.

Then you believe incorrectly, because that statement is complete nonsense.
Windows 95 was a system held together with duct tape and bailing wire.

I commonly run 20 processes on my XP box, including Excel, Mozilla,
Internet Explorer, Thunderbird, Visual Studio, several VIMs, five cmd
shells, a Cygwin shell, a virtual desktop utility, and a set of embedded
tools.  I have an ATAPI DVD drive and CD burner, 6 USB devices and a 1394
CD duplicator.  They run all week without rebooting.  You couldn't have
done that with *4* Windows 95 systems.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

Tim Roberts <timr@probo.com> wrote:
> Are you joking???  There has never been a Windows 98 machine that could 
> go a month without rebooting.  48 hours was an outstanding record.

I've never seen one either, but I have routinely seen one week.

IMHO, a big inherent instability problem with MS-Win9* is
the Registry.  It needs to be kept clean (MS-REGCLEAN.EXE)
and defragmented (16 bit access?).  The only way to defrag
the Registry is multiple (~3) defrag-reboot cycles.

With this heavy maintenance, MS-Win9* seldom (once per quarter)
crashed due to the OS.  Without it, a machine could crash
several times a day -- time for mtce.

> I commonly run 20 processes on my XP box, including Excel, Mozilla,

I'm not sure MS-Win9* is stable with this many.  It depends
on low (first 640KB) memory for some tasks.

MS-Win9* is obviously limited, but actually works so long
as you are careful to stay within it's limitations.  It is
nowhere near as robust as OS/2, *BSD, Linux or MS-WinNT.
But there was no good reason to expect it to be.

-- Robert

>> I commonly run 20 processes on my XP box, including Excel, Mozilla,
>
>I'm not sure MS-Win9* is stable with this many.  It depends
>on low (first 640KB) memory for some tasks.

More important is the limited amount of ressources like handles and
some gui stuff. A single program loosing them can bring down the whole
OS in less than an hour of normal use, same goes for DPMI memory holes
in DOS programs (usually resulting in increased swap space only, but
repeated loss isn4t healthy either). Under NT/2k, the same programs
usually only slow down a bit without affecting other processes - the
only remarkable issue is the ever increasing memory usage of those
processes.
However, using only programs without such flaws you can also run
dozens of programs simultaneously for days as well.
Anyway, the best side of Win9x is its DOS-compatibility, allowing
quite a lot of direct (or thin-layered) hardware accesses not possible
under NT based versions, as well as it does run fast enough with less
than 64MB as well...

TS <nomailhere@deinmeister.de> wrote:
> More important is the limited amount of ressources like handles and
> some gui stuff. A single program loosing them can bring down the whole
> OS in less than an hour of normal use, same goes for DPMI memory holes

Good point.  I believe MS-Win9* can recover resources when
leaky apps are shutdown.  Then you just need to restart the
leakers before they sink the ship.

But this is hardly MS-Win9* fault.  That OS was not designed
to deal with hostile/defective apps.  MS-DOS doesn't even
have a COMMAND.COM restart facility (Ctl-Alt-Ins frees mem
and reloads COMMAND.COM; TSR anyone?)

> repeated loss isn4t healthy either). Under NT/2k, the same programs
> usually only slow down a bit without affecting other processes - the
> only remarkable issue is the ever increasing memory usage of those
> processes.

Certainly MS-WinNT fails more gracefully and has better protection
against defective apps.  So does Unix because it was designed to
deal with hostile user code.

> Anyway, the best side of Win9x is its DOS-compatibility, allowing
> quite a lot of direct (or thin-layered) hardware accesses not possible
> under NT based versions, as well as it does run fast enough with less
> than 64MB as well...

True.  That direct hardware access is sometimes important.
What do BIOS mfrs do these days for reflashing?  Distribute
a boot disk image?

-- Robert

> 

"Tim Roberts" <timr@probo.com> pmse v diskusnmm prmspevku
news:ivlvc01ia6kdl85vrr37r137vtuq1qgrev@4ax.com...
> "Jim Carlock" <anonymous@127.0.0.1> wrote:
> >
> >In using XP:
> >
> >I've noticed that SOMETIMES, when I start cmd.exe, the processor
> >goes into a 100% useage state. This is particularly true if I first run
> >Programmers WorkBench ( PWB.EXE ) from the cmd.exe. Not
> >only that, but it doesn't do this 100% of the time. It seems to start up
> >after a certain set of programs are run, or if the computer hasn't been
> >rebooted in a month. There seem to be some serious memory mgmt
> >problems in XP that didn't exist inside of Windows 98. :-)
>
> Are you joking???  There has never been a Windows 98 machine that could go
> a month without rebooting.  48 hours was an outstanding record.
>

IMO, maximum possible time for running Win9x was given by some 32-bit
counter, which computed ticks (miliseconds) from system start. When it
overflowed, system stopped. I'm not sure, if there is any SP for that bug.

(2^32) / 1000 / 60 / 60 / 24 = 49,7 days

Zdenek Sojka

"Tim Roberts" wrote:
> Are you joking???  There has never been a Windows 98 machine
> that could go a month without rebooting.  48 hours was an
> outstanding record.

:-)

Well, I'm telling you I had a Win98 machine that ran a year without
rebooting. Perhaps it was because I didn't play around with unknown
software, perhaps it was because I wasn't doing as much development
as I am doing now. I found Win98 very very stable, unless I was
playing with buggy software, ie buggy software meaning software in
which the crash could be duplicated over and over by the same set
of events (and there was some of that software around).

XP crashes a couple times a month on me ( and maybe it is buggy
software that does it, but currently it's all Microsoft software and they
are bugs that Microsoft conveniently supplies ). And the plug and
play software that comes with XP is specifically what I was refering
to, because buggy software will crash any system, even Win NT.

And continuing on, I'll give you some examples of the XP bugs...

Specifically, refering to the Plug and Play stuff, and the hardware
configuration within XP...

Windows 98, you could go into the device manager and delete a
network adapter and reinstall the network adapter to correct
problems. You can't do that with Windows XP. Windows XP
tends to call a newly detected network adapter as Network
Adapter #2, or #3, or #4. Windows 98 NEVER had that problem.

Also, another example... hooking up a camera to a USB port,
Windows 98 would ALWAYS refer to the camera by its name.

Windows XP on the other hand refers to the NEW device as:

Camera the first time.
Camera #2 the second time.
Camera #2 the third time
Camera #2 the fourth time.
Camera #3 the fifth time.
Camera #3 the sixth time.

Mine is currently up to Camera #5 after about 10 seperate hookups.
The network adapters are up to Network Adapter #6, and that's after
deleting the device from the Device Manager.

And this happens even though it's hooked up to the SAME darn
USB port.

These are XP bugs. They did NOT exist or could be remedied in
Windows 98.

Hope that helps. Don't blindly follow any path because you might
turn left when a canal was dug and now the path turns right.

-- 
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.

On Thu, 17 Jun 2004 04:39:30 +0000 (UTC), "Jim Carlock"
<anonymous@127.0.0.1> wrote:

<snip>
>These are XP bugs. They did NOT exist or could be remedied in
>Windows 98.
They did exist, somewhat, in the registry.  Deleting a device did not
always get rid of all entries.  So, adding the device again got new
numbers, internally.  This was not normally apparent to the user,
however, if you dig thru the hardware Enum entries you see the old
junk, which did not normally cause any problems.

Your description of XP's naming stupidities sounds like ANOTHER good
reason to avoid it.

<snip>
-- 
Arargh405 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

> Good point.  I believe MS-Win9* can recover resources when
> leaky apps are shutdown.  Then you just need to restart the
> leakers before they sink the ship.
>
It's been a while since I used 9x, and I haven't bothered to
research/confirm this, but it certainly didn't _feel_ like it
was able to reclaim all resource types. And then there's the
severity of the leaks - especially GDI leaks are fatal.
A small programming error, like forgetting a call to ReleaseDC,
will eventually lead to a BSOD.

> True.  That direct hardware access is sometimes important.
> What do BIOS mfrs do these days for reflashing?  Distribute
> a boot disk image?
>
Flashing is actually possible directly 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...

> 
>>True.  That direct hardware access is sometimes important.
>>What do BIOS mfrs do these days for reflashing?  Distribute
>>a boot disk image?
>>
> 
> 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!
> 
> 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.

Greetings

Markus

[snip]

I can confirm this partially. My Windows XP prof. notebook is plugged to 
my ink printer sometimes via paralell port. The printer otherwise is 
connected via USB to another PC. Every time I plug in the printer, 
Windows XP detects it new, even if it has been installed already all day 
long...hm. A printer with this name on this port installed is not the 
same as a printer with this name on this port now connected or what?

To the network cards: I had that phenomen with a PCIMCIA nic on a W2K 
notebook as well! I think I didn't delete the card when removing it 
first time...just nervong needless...and if it's not plugged in, you 
can't access it and change IP-adress to give its IP to another card you 
just pkugged in. The IP is used then by the invisible, unplugged other 
card and so it's lost on that PC...crap! DOS did better on that...

Greetings

Markus

Arargh405 wrote:
> They did exist, somewhat, in the registry.  Deleting a device did
> not always get rid of all entries.  So, adding the device again got
> new numbers, internally.  This was not normally apparent to the
> user, however, if you dig thru the hardware Enum entries you see
> the old junk, which did not normally cause any problems.

:-)

I'm specifically talking about 98 not Me, not 95. I've installed hardware
on 1000s of 98 systems, and XP has the same PnP problems that 95
had. If 98 had these problems, I never saw them on 1000s of systems,
and I did have 98 running for a year without a reboot.

There were a couple of things that I used to do on Win95 systems in
a time that I avoided using the registry or editing the registry. I used to
boot the systems up into safe mode and then go into the device
manager, and you'd see all the multiple entries there for a mouse, for
a NIC, for a video controller, and if a device was removed and then
a new device reinstalled, you'd see references to the old devices
there. The way to fix a problematic system was to delete all the
devices there, which in effect took out the references in the registry,
and then reboot the system letting it detect the hardware all over again.

This fixed some systems and I'd know that it was one of the other
device drivers that was affecting things... and Win95 was confused.

Win98 pretty much fixed those problems. I had to quit using the
method described above with the advent of Win98. I've always
felt the PnP on a Win98 system was far superior to the PnP on any
other OS in existance. I haven't used Win98 in a year or so I'm not
qualified to say that that is the way it still is. I do have a Win98
system sitting next to my desk with a 4GB HDD that I haven't
started up in over a year that I was going to throw Win95 on, to
test some software installation... but I haven't gotten around to it. I
have to install another motherboard into it and I think that will tell
me alot, because it has all the UDMA 100 technology that wasn't
present when 98 was in use.

Just a question. I haven't really dug into the registry in a long time
on such a system, and I'm wondering if you are 100% certain
about your comment above. I'll be certain to test out my USB
drive on it to see if that has the enumeration problems that XP
has. I don't remember it having that problem with the camera
though, as I have had this digital camera for about 5 years now.

-- 
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.

On Fri, 18 Jun 2004 03:04:35 +0000 (UTC), "Jim Carlock"
<anonymous@127.0.0.1> wrote:

>Arargh405 wrote:
>> They did exist, somewhat, in the registry.  Deleting a device did
>> not always get rid of all entries.  So, adding the device again got
>> new numbers, internally.  This was not normally apparent to the
>> user, however, if you dig thru the hardware Enum entries you see
>> the old junk, which did not normally cause any problems.
>
>:-)
>
>I'm specifically talking about 98 not Me, not 95. I've installed hardware
>on 1000s of 98 systems, and XP has the same PnP problems that 95
>had. If 98 had these problems, I never saw them on 1000s of systems,
>and I did have 98 running for a year without a reboot.
Yep, "4.10.1998"
>
>There were a couple of things that I used to do on Win95 systems in
>a time that I avoided using the registry or editing the registry. I used to
>boot the systems up into safe mode and then go into the device
>manager, and you'd see all the multiple entries there for a mouse, for
>a NIC, for a video controller, and if a device was removed and then
>a new device reinstalled, you'd see references to the old devices
>there. The way to fix a problematic system was to delete all the
>devices there, which in effect took out the references in the registry,
>and then reboot the system letting it detect the hardware all over again.
>
>This fixed some systems and I'd know that it was one of the other
>device drivers that was affecting things... and Win95 was confused.
>
>Win98 pretty much fixed those problems. I had to quit using the
Yes, I agree.  98 is a LOT better.
>method described above with the advent of Win98. I've always
>felt the PnP on a Win98 system was far superior to the PnP on any
>other OS in existance. I haven't used Win98 in a year or so I'm not
>qualified to say that that is the way it still is. I do have a Win98
>system sitting next to my desk with a 4GB HDD that I haven't
>started up in over a year that I was going to throw Win95 on, to
>test some software installation... but I haven't gotten around to it. I
>have to install another motherboard into it and I think that will tell
>me alot, because it has all the UDMA 100 technology that wasn't
>present when 98 was in use.
>
>Just a question. I haven't really dug into the registry in a long time
>on such a system, and I'm wondering if you are 100% certain
>about your comment above. I'll be certain to test out my USB
>drive on it to see if that has the enumeration problems that XP
>has. I don't remember it having that problem with the camera
>though, as I have had this digital camera for about 5 years now.

Pretty sure.  I was just browsing the registry, and there certainly
oddities.  2 C drives, 2 D drives . . .   Part of that is probably
because this hard drive has been in several systems, each faster,
without doing a reinstall. And on different drives, too. I just
deleted everything in device manager, and struck the cloned drive in
the new system.

If you want to see a partial registry dump, send me an email, and I
will send you a copy.  

Also, the original 98 wasn't all that swift in handling USB devices,
that supposedly got cleaned up in 98SE, but to what extent, I don't
know.

-- 
Arargh405 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

>> 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.