Re: [guide-user] Guide ver 7 and XP

Paul Schlyter Dec 3, 2001

> ----- Original Message -----
> From: <gblair@...>
> To: <guide-user@yahoogroups.com>
> Sent: Monday, December 03, 2001 6:27 PM
> Subject: Re: [guide-user] Guide ver 7 and XP
>
>> Robust, asynchronous serial communications under Win2k (and hence WinXP
>> Pro) are a little trickier to implement than they were under any previous
>> MS operating system.
>
> I must respectfully disagree, Grant. If serial comms is carried out using
> the standard, documented, Windows API, it works equally well under Windows
> 2000 and Windows XP Pro as it does under any previous version of Windows.
> Moreoever, it's guaranteed to carry on working under any future version of
> Windows, too.
>
> What can't be done under Windows NT, 2000, or XP, is the old "MS-DOS" method
> of controlling the serial port by directly writing to its "memory mapped"
> hardware. The operating system prevents such "tampering" under these
> "secure" operating systems.

I must respectfully disagree, Chris, since I've successfully run
several MS-DOS programs doing serial I/O under Win-NT4. Perhaps it
doesn't work under Win-2K or Win-XP, but Win-NT still emulates this
in their DOS emulation. However, one must use the "standard" COM
port addresses even if some non-standard serial port hardwar is
present (or, alternatively, one must install an NT driver for the
non-standard serial port addresses).

These operating systems does not necessarily prevent such
"tampering"; they may also choose to emulate MS-DOS on some selected
port addresses. Note that such tampering with hardware ports should
be done only with 16-bit code, not with 32-bit code at the
application level: if you want to mess directly with the hardware in
32-bit code, that should be done in a hardware device driver.


> As I say, however, "obey the rules" and use the documented serial port
> access methods and there are no problems.

With that I fully agree. And that goes for any OS -- including MS-DOS,
where the rules for the serial part are "tamper with the hardware
because the OS has a lousy support".