Searching \ for '[OT]: Com port base address' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/ios.htm?key=port
Search entire site for: 'Com port base address'.

Exact match. Not showing close matches.
PICList Thread
'[OT]: Com port base address'
2001\03\29@112052 by Dave

flavicon
face
Hey,

Does anyone know of a way I can find out the base address of the different
com ports in my program I am making under Windows. Thank for your help.

Regards,

Dave

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\29@180137 by David Duffy

flavicon
face
David Stubbs wrote:
>Hey,
>
>Does anyone know of a way I can find out the base address of the different
>com ports in my program I am making under Windows. Thank for your help.

com1            Hex 3F8
com2            Hex 2F8
com3            Hex 3E8 (?)
com4            Hex 2E8 (?)
Unlike LPT ports, com ports have fixed base addresses.
Regards...

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\30@010232 by dr. Imre Bartfai

flavicon
face
Hi,
AFAIK, LPT ports have also fixed base addresses, namely
0x3BC, 0x378 and 0x278. If any of them missing, the assignment shifts.
BTW, the comx addresses below could be also changed (swapped), especially
in newer BIOSes.

Regards,
Imre

On Fri, 30 Mar 2001, David Duffy wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\30@083930 by John Pfaff

flavicon
face
Under DOS and Windows the addresses are stored in the BIOS data area as
follows:

0040:0000 COM1 Port Address
0040:0002 COM2 Port Address
0040:0004 COM3 Port Address
0040:0006 COM4 Port Address
0040:0008 LPT1 Port Address
0040:000A LPT2 Port Address
0040:000C LPT3 Port Address

- John

{Original Message removed}

2001\03\30@084543 by Bob Ammerman

picon face
I sent David a private message re: this topic, but I don't think I sent the
same info to the list (sorry if I already did).

It is  a _very_ bad idea to directly access the UART in Win32. For starters,
it won't work at all for NT/2000. Also, we are starting to see more and more
environments where COM ports are implemented without a conventional UART
being there at all (USB, for example).

You really should bite the bullet and learn how to do what you need with the
Windows API. I've implemented quite a few things using the API, and while it
is a pain, it can (almost?) always get the job done, if you are creating
enough.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)


{Original Message removed}

2001\03\30@085144 by Bob Ammerman

picon face
> I sent David a private message re: this topic, but I don't think I sent
the
> same info to the list (sorry if I already did).
>
> It is  a _very_ bad idea to directly access the UART in Win32. For
starters,
> it won't work at all for NT/2000. Also, we are starting to see more and
more
> environments where COM ports are implemented without a conventional UART
> being there at all (USB, for example).
>
> You really should bite the bullet and learn how to do what you need with
the
> Windows API. I've implemented quite a few things using the API, and while
it
> is a pain, it can (almost?) always get the job done, if you are creating
> enough.

er.... s/creating/creative/

> Bob Ammerman
> RAm Systems
> (contract development of high performance, high function, low-level
> software)
>
>
> {Original Message removed}

2001\03\30@085201 by David VanHorn

flavicon
face
>
>You really should bite the bullet and learn how to do what you need with the
>Windows API. I've implemented quite a few things using the API, and while it
>is a pain, it can (almost?) always get the job done, if you are creating
>enough.

Mr Bob:

Would it be possible to write a low level driver, that would take data from
COM1, and make it appear as COM2,3,4... and likewise with outbound data,
collecting from COMx and moving it to COM1?

I realize that there would need to be a protocol, and I've worked that bit
out already.

The mystery to me, is how to create "virtual" comports.
I think this is similar to how USB serials work, since there's no
conventional uart hardware there.


--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\30@090250 by Bob Ammerman

picon face
> >
> >You really should bite the bullet and learn how to do what you need with
the
> >Windows API. I've implemented quite a few things using the API, and while
it
> >is a pain, it can (almost?) always get the job done, if you are creating
> >enough.
>
> Mr Bob:
>
> Would it be possible to write a low level driver, that would take data
from
{Quote hidden}

In Win32, your various COMn ports are created by the device drivers that
support whatever serial port hardware you have. There is no fixed
relationship between a specific piece of hardware and the corresponding 'n'.

You should have an appropriate driver for whatever serial port hardware you
have. Windows comes, out of the box, with a driver for conventional UART
based serial ports. Smart and dump multiport cards are available from many
places like Digiboard. USB interfaced serial ports are starting to become
common.

To move data from one such port to another doesn't require any 'low level
driver' but rather an application that reads from one port and writes to the
other.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\30@091326 by David VanHorn

flavicon
face
>
>In Win32, your various COMn ports are created by the device drivers that
>support whatever serial port hardware you have. There is no fixed
>relationship between a specific piece of hardware and the corresponding 'n'.
>
>You should have an appropriate driver for whatever serial port hardware you
>have. Windows comes, out of the box, with a driver for conventional UART
>based serial ports. Smart and dump multiport cards are available from many
>places like Digiboard. USB interfaced serial ports are starting to become
>common.
>
>To move data from one such port to another doesn't require any 'low level
>driver' but rather an application that reads from one port and writes to the
>other.


I may not be using the right language here. I'm not a windows programmer.

What I've got is a device that packs 8 serial ports into one at high speed.
(AVR and max3110s)
The output looks like:
<FF><08><03>hi <FF><04><07>YAHOO!!

That's Flag, Port 8 says 3 bytes "hi " Flag, Port 4 says 7 bytes "YAHOO!!"

There's also a command channel that manages handshaking, and a virtualized
port on my end, for some hardware that usually comes in on a serial port. I
just make it look like another of the muxed ports.

What I'd like to end up with, is somethign that runs on win(XX) that would
strip these data out from the real com1, and present it to the system as if
com 2,3,4,5,6,7,8,9 exsted (Or maybe they do now..)
On the outbound side, it would catch any data sent to comX, package and
ship it out in the above format.

There's some additional complexities with buffer management, and hardware
handshaking on com1.


--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\30@092614 by Bob Ammerman

picon face
----- Original Message -----
From: David VanHorn <spam_OUTdvanhornTakeThisOuTspamCEDAR.NET>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Friday, March 30, 2001 8:47 AM
Subject: Re: [OT]: Com port base address


> >
> >In Win32, your various COMn ports are created by the device drivers that
> >support whatever serial port hardware you have. There is no fixed
> >relationship between a specific piece of hardware and the corresponding
'n'.
> >
> >You should have an appropriate driver for whatever serial port hardware
you
> >have. Windows comes, out of the box, with a driver for conventional UART
> >based serial ports. Smart and dump multiport cards are available from
many
> >places like Digiboard. USB interfaced serial ports are starting to become
> >common.
> >
> >To move data from one such port to another doesn't require any 'low level
> >driver' but rather an application that reads from one port and writes to
the
> >other.
>
>
> I may not be using the right language here. I'm not a windows programmer.
>
> What I've got is a device that packs 8 serial ports into one at high
speed.
{Quote hidden}

if
> com 2,3,4,5,6,7,8,9 exsted (Or maybe they do now..)
> On the outbound side, it would catch any data sent to comX, package and
> ship it out in the above format.
>
> There's some additional complexities with buffer management, and hardware
> handshaking on com1.

Gotcha.


Ok, to do this you'd need two pieces:

1: A device driver to provide the simulated serial ports. To do this you'd
need to get the DDK (device driver kit) from Microsoft and spend quite a bit
of time figuring it out. Non-trivial to say the least. This driver could
possibly directly access the real COM port, but you'd probably be better off
having it work with:

2: An application (or NT service) that reads the data from the real COM port
and hands it off to the device driver (via a private API) to be sent to fake
COM ports and vice versa.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\30@093150 by David VanHorn

flavicon
face
>
>Ok, to do this you'd need two pieces:
>
>1: A device driver to provide the simulated serial ports. To do this you'd
>need to get the DDK (device driver kit) from Microsoft and spend quite a
>bit of time figuring it out. Non-trivial to say the least. This driver
>could possibly directly access the real COM port, but you'd probably be
>better off having it work with:
>
>2: An application (or NT service) that reads the data from the real COM
>port and hands it off to the device driver (via a private API) to be sent
>to fake COM ports and vice versa.

Hmm.. I seem doomed.

I don't even know anyone who can write windows device drivers.

The original theory was that the application I designed this for, would put
in a lower layer that would handle this, but it's not happening.

--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\30@103635 by James Paul

flavicon
face
All,

If I remember correctly, COM ports 1,2,3&,4 are at base addresses
of 3F8, 3E8, 2F8, and 2E8 respectively.

                                           Regards,

                                              Jim





On Fri, 30 March 2001, Bob Ammerman wrote:

{Quote hidden}

> {Original Message removed}

2001\03\30@125751 by Dave

flavicon
face
I know that. I just wanted to do it in code.

Regards,

David Stubbs

WEB: http://www.nti-uk.com
TEL UK: 07968 397782


> {Original Message removed}

2001\03\30@125755 by Dave

flavicon
face
Hi,

I noticed they were allways the same on the comps I used but is this always
the case?

Regards,

David Stubbs

WEB: http://www.nti-uk.com
TEL UK: 07968 397782


> {Original Message removed}

2001\03\30@130803 by Dale Botkin

flavicon
face
Yah...  my one publicly-released bit of Shareware for the PC was a utility
to swap COM and LPT port addresses around from the command line.  I think
that was around '85.

Dale

On Fri, 30 Mar 2001, John Pfaff wrote:

{Quote hidden}

> {Original Message removed}

2001\03\30@132444 by Barry Gershenfeld

picon face
[BIOS TABLE]
> 0040:0000 COM1 Port Address
> 0040:0002 COM2 Port Address
> 0040:0004 COM3 Port Address
> 0040:0006 COM4 Port Address
> 0040:0008 LPT1 Port Address
> 0040:000A LPT2 Port Address
> 0040:000C LPT3 Port Address

[ADDRESSES]
>> com1            Hex 3F8
>> com2            Hex 2F8
>> com3            Hex 3E8 (?)
>> com4            Hex 2E8 (?)
>> Unlike LPT ports, com ports have fixed base addresses.

>I noticed they were allways the same on the comps I used but is this always
>the case?

Therein lies a tale (you knew this was coming...)

The way IBM designed it in the BIOS was that the ADDRESSES would
not be fixed.  They would be assigned to be COM1, COM2... as they
were found during bootup.

Problem was, that built-in serial port software was so terrible
that it couldn't be used at "high speeds" (this being 1200 bps
and higher, acoording to the IBM manual).  So everybody wrote
their own drivers and just started going directly to the port
addresses.  Once that was done, it became habit and anything
that didn't agree was considered "broken".  I remember in
Windows 3.1 you could go into the COM port setup and generally
if you found the "wrong" port address mapped you would just
manually change it "back" to what we were all used to.

None of this nonsense happened with the parallel printers, so
to this day most everything works with LPT1, etc.,  no matter
which of the 3 possible addresses shows up there.

And since they weren't mentioned, they (parallel) are:
03BC
0278
0378

The idea was that one was always found on the color card; one
was always on the mono card; and the third was for add-on
cards.  That way you shouldn't get conflicts when you stuffed
all those cards into the same box.

You know, I never actually answered the question.  The answer
is they are designed so they don't have to be, but if you
try to change them you'll almost always get into trouble
somewhere.

Barry

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\30@144220 by Dave

flavicon
face
Cool,

I'll just hardcode them into the app but give the user the option of
changing them if they know what they should be. Thanks for your help and the
nice story :)

Regards,

David Stubbs

WEB: http://www.nti-uk.com
TEL UK: 07968 397782


> {Original Message removed}

2001\03\31@014850 by Peter L. Peres

picon face
> The output looks like:
> <FF><08><03>hi <FF><04><07>YAHOO!!

And of course <FF><FF> is an escape for <FF> in both directions, isn't it
?

You need to find someone who can write a VxD for you and debug it and give
you all the rights (or release it freely). You can check out Windows
device driver development costs on the net.

If you had emulated the hardware of one of the better known multiport
cards you might have used their drivers. This may or may not entail some
copyright/patent violation.

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\03\31@033851 by spam

flavicon
face
To write directly to a com port from windows,
I suggest you get a general memory / IO driver like
TVicHW, which you will find at any Delphi site.

If you run NT, you are not allowed to touch the ports, whereas
Windows 98 does not care what you do. Just use inline assembly.
Memory is harder, interrupts even harder.
TVicHW does it all for you.

If you need to know more, just let me know.
Kent

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\03\31@054210 by dr. Imre Bartfai

flavicon
face
Correct. However, 0000 is not a valid address, rather means "port does not
exist".
Regards,
Imre

On Fri, 30 Mar 2001, John Pfaff wrote:

{Quote hidden}

> {Original Message removed}

2001\03\31@054626 by dr. Imre Bartfai

flavicon
face
Hi,

as I wrote, in most cases, but not necessarily. You may even write the
said BIOS cells to swap ports.

Regards,
Imre


On Fri, 30 Mar 2001, James Paul wrote:

{Quote hidden}

> > {Original Message removed}

2001\03\31@061253 by Bob Ammerman

picon face
> You need to find someone who can write a VxD for you and debug it and give
> you all the rights (or release it freely). You can check out Windows
> device driver development costs on the net.

Or give you limited rights for use with this program.

> If you had emulated the hardware of one of the better known multiport
> cards you might have used their drivers. This may or may not entail some
> copyright/patent violation.

Hard to do this when we're talking about a notebook without PCMCIA or USB or
anything more advanced than serial/parallel ports.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\03\31@074555 by Alok Dubey (OCS-BLRAKS-AVS)

flavicon
face
Are the IRQs fixed too?
Alok

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2001\03\31@092221 by David VanHorn

flavicon
face
At 08:18 AM 3/31/01 +0300, Peter L. Peres wrote:

>If you had emulated the hardware of one of the better known multiport
>cards you might have used their drivers. This may or may not entail some
>copyright/patent violation.

Wouldn't have worked here.
The task is to put many devices onto a portable, which has only one serial
port.
No bus, no USB, no PCMCIA..

--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body



'[OT]: Com port base address'
2001\04\01@155846 by Peter L. Peres
picon face
>> If you had emulated the hardware of one of the better known multiport
>> cards you might have used their drivers. This may or may not entail
>> some copyright/patent violation.
>
>Hard to do this when we're talking about a notebook without PCMCIA or USB
>or anything more advanced than serial/parallel ports.

Windows knows nothing of the hardware, except what it (decides to) see. By
emulating a fourport or other card's register level programming I/F one
should be able to use their driver (which should already be in the
Windows driver database). I do NOT suggest that this be done on a
commercial basis. Rather as a one-off or special purpose equipment.

Peter

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


2001\04\02@091150 by John Pfaff

flavicon
face
I think you're misunderstanding the table.  Starting at address 0040:0000
(or 0000:0400 if you want to segment it differently) you will find a table.
As Bob Ammerman pointed out (I forgot to) you can only access the hardware
directly from DOS, Windows 3x and 9x; it won't work under NT/2000; don't
know about ME.
Here is an example of what you will find, starting at address 0040:0000

0040:0000 F8 03 F8 02 E8 03 E8 02
0040:0008 BC 03 78 03 78 02 XX XX

meaning of course that COM1's I/O addresses start at 03F8, COM2's I/O
addresses start at 02F8, and so on.  When DOS, etc, boot up, they scan a
known set of addresses for the ports.  When they find the hardware the stick
the address in the table.  We had a project where we had to put a COM port
at a non-standard address (DOS couldn't find it on its own).  This was on a
little PC/104 i386EX processor with DOS and there were issues with com
ports, a long story.  Anyway, as part of our initialization we had to stick
our own address into the table.  Pretty simple.

{Original Message removed}

2001\04\02@142220 by Tom Handley

picon face
  Bob, I also write drivers for Windows up to 98 (Not NT). Since I write
a lot of code to test products via the serial and parallel port, I do
not want Windows bothering me... While I also write Multi-Tasking'-
friendly code, Frankly, I miss UNIX and the Amiga... The Amiga, under
"Intuition" and the "Exec" allowed us to do both in a rather elegant way
thanks to Carl, Jay Minor, and many others.

  There are times where you simply need to disable, or prempt, Windows,
to gather crucial data from the various hardware ports. While this is
not needed for the general community, it is crucial for folks involved
with engeneering and other interests. It would be interesting to hear
from folks from National Instruments as how they handle this need while
providing a GUI in a Windows 9x and NT environment.

  - Tom

At 08:55 AM 3/30/01 -0500, Bob Ammerman wrote:
{Quote hidden}

------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\02@144110 by Bob Ammerman

picon face
----- Original Message -----
From: Tom Handley <thandleyEraseMEspam.....TELEPORT.COM>
To: <EraseMEPICLISTspamMITVMA.MIT.EDU>
Sent: Monday, April 02, 2001 2:20 PM
Subject: Re: [OT]: Com port base address


{Quote hidden}

Windows serial port drivers can actually do a surprisingly good job of
keeping the port busy and getting input to your app in a timely manner. On
the other hand if you are doing some kind of tricky, timing dependent,
out-of-band signalling using RTS or somesuch .... good luck.

Windows parallel port support stinks -- other than use as a standard printer
interface, forget it.

Again: There is probably little reason to bypass the Windows serial driver
for most applications (especially 3-wire (RX,TX,GND type applications). And
there are lots of good reasons to use the driver.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\03@043516 by Alan B. Pearce

face picon face
>It would be interesting to hear
>from folks from National Instruments as how they handle this need while
>providing a GUI in a Windows 9x and NT environment.

I would suspect that proper use of interrupts and multithreaded code would be
the answer. While Win9X is not a multithreaded environment I suspect that it
will handle properly written multithreading code in a nice manner which would
get close to the proper multithreaded NT environment.

I would guess that having Labview work nicely would also be dependant on not
running other CPU intensive programs which have not been well written:)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\04\03@044136 by dr. Imre Bartfai

flavicon
face
HI,

I think I did not misunderstand the table. However, I did not say it
exactly, maybe. I wanted to say: if the table contains a word which has
the value of 0000, it did not refer to a serial port having base address
0000, rather it means that particular port does not exist. Of course, 40:0
is a valid BIOS cell.

Regards,
Imre

On Mon, 2 Apr 2001, John Pfaff wrote:

{Quote hidden}

> {Original Message removed}

2001\04\03@073808 by Bob Ammerman

picon face
> >It would be interesting to hear
> >from folks from National Instruments as how they handle this need while
> >providing a GUI in a Windows 9x and NT environment.
>
> I would suspect that proper use of interrupts and multithreaded code would
be
> the answer. While Win9X is not a multithreaded environment I suspect that
it
> will handle properly written multithreading code in a nice manner which
would
> get close to the proper multithreaded NT environment.

Note: Win9X _is_ indeed a multithreading environment. It will do almost
anything multithreading related that NT will do, except for asynchronous
(overlapped) I/O and a few fancy queueing operations.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\04\03@082623 by Alan B. Pearce

face picon face
>Note: Win9X _is_ indeed a multithreading environment. It will do almost
>anything multithreading related that NT will do, except for asynchronous
>(overlapped) I/O and a few fancy queueing operations.

But as I understand it (and from what you say here as well) it is co-operative
multithreading, not pre-emptive multithreading like NT.

This really just means that if a program is properly written and gives up its
time slot on a regular basis then everything runs all right. If the program is
not correctly written for a co-operative environment it will not run right.

NT forces the thread to give up its time slot and the context is saved to be
continued as some later time. This allows a badly written multithreaded program
to run (provided it has not produced "close embrace" lockouts).

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\04\03@084930 by Bob Ammerman

picon face
>Note: Win9X _is_ indeed a multithreading environment. It will do almost
> >anything multithreading related that NT will do, except for asynchronous
> >(overlapped) I/O and a few fancy queueing operations.
>
> But as I understand it (and from what you say here as well) it is
co-operative
> multithreading, not pre-emptive multithreading like NT.

No, Win31 was cooperative multithreading, as are NT/2000/XP and Win9x/Me
among any 16-bit applications. But Win32 is multithreaded on both Win9X/Me
and WinNT/2000/XP.

> This really just means that if a program is properly written and gives up
its
> time slot on a regular basis then everything runs all right. If the
program is
> not correctly written for a co-operative environment it will not run
right.

This applies only to 16-bit code, relative to other 16-bit code on any
platform. (ie: 32 bit programs can preempty 16-bit code on all the
platforms).

> NT forces the thread to give up its time slot and the context is saved to
be
> continued as some later time. This allows a badly written multithreaded
program
> to run (provided it has not produced "close embrace" lockouts).

The expression is usually 'deadly embrace' :-)

And Win9x/Me does the same thing for 32-bit programs.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...