My R&D department does a lot of work with com ports.
Communicating to devices via com ports, programming
devices. In windows 98 the com ports worked just fine
without fail. Since we have Windows 2000 and or Windows
XP installed they loose commnications a lot of the time.
They also get the com ports so hung up that the only way
to "fix" the problem is to either reboot the system, or go
into device manager and disable and re-enable the device.

Is this related to how the new operating system's handle
com ports, how they are configured, or is it that the
software is not compatible with this version of windows.
This is happening on multiple machines. Help

Your problems may lie in the fact that in DOS-based systems
your app can get "hands on" the real hardware, while in
NT-class systems they cannot, and must instead use defined
APIs to go through the "virtual" hardware interface. Some
instructions are illegal in the latter systems, and sometimes
app code has to be changed.

(Just a thought. Maybe that's not the problem.)

Roundy wrote:

> My R&D department does a lot of work with com ports.
> Communicating to devices via com ports, programming
> devices. In windows 98 the com ports worked just fine
> without fail. Since we have Windows 2000 and or Windows
> XP installed they loose commnications a lot of the time.
> They also get the com ports so hung up that the only way
> to "fix" the problem is to either reboot the system, or go
> into device manager and disable and re-enable the device.
>
> Is this related to how the new operating system's handle
> com ports, how they are configured, or is it that the
> software is not compatible with this version of windows.
> This is happening on multiple machines. Help

"Roundy" <(E-Mail Removed)> wrote in message news:01e601c4a4d0$d3d2b1d0$(E-Mail Removed)...
> My R&D department does a lot of work with com ports.
> Communicating to devices via com ports, programming
> devices. In windows 98 the com ports worked just fine
> without fail. Since we have Windows 2000 and or Windows
> XP installed they loose commnications a lot of the time.
> They also get the com ports so hung up that the only way
> to "fix" the problem is to either reboot the system, or go
> into device manager and disable and re-enable the device.
>
> Is this related to how the new operating system's handle
> com ports, how they are configured, or is it that the
> software is not compatible with this version of windows.
> This is happening on multiple machines. Help

It all depends on the design of the com ports, and the
devices used on them. Devices used under Win2K
must allow for its Hardware Abstraction Layer, and
must not demand direct access to com ports. Such
access was allowed under Win98. So there may be
device driver issues as well as hardware issues.

Rick

Is there a way to resolve this? Maybe have the app run in
compatibility mode, or will that not solve anything?
Thanks for the help.
>-----Original Message-----
>Your problems may lie in the fact that in DOS-based
systems
>your app can get "hands on" the real hardware, while in
>NT-class systems they cannot, and must instead use defined
>APIs to go through the "virtual" hardware interface. Some
>instructions are illegal in the latter systems, and
sometimes
>app code has to be changed.
>
>(Just a thought. Maybe that's not the problem.)
>
>Roundy wrote:
>
>> My R&D department does a lot of work with com ports.
>> Communicating to devices via com ports, programming
>> devices. In windows 98 the com ports worked just fine
>> without fail. Since we have Windows 2000 and or
Windows
>> XP installed they loose commnications a lot of the
time.
>> They also get the com ports so hung up that the only
way
>> to "fix" the problem is to either reboot the system, or
go
>> into device manager and disable and re-enable the
device.
>>
>> Is this related to how the new operating system's
handle
>> com ports, how they are configured, or is it that the
>> software is not compatible with this version of
windows.
>> This is happening on multiple machines. Help
>
>.
>

I'm not sure what compatibility mode might accomplish; never use it.

As far as I know, if the problem is as speculated (you're up against
the "illegal instruction" wall), the only solution is a code rewrite.
Common problem; some houses elect to update their software, others
just settle for product obsolescence. It's a business case decision,
dev cost vs revenue, for this product vs other products.

Roundy wrote:
> Is there a way to resolve this? Maybe have the app run in
> compatibility mode, or will that not solve anything?
> Thanks for the help.
>
>>-----Original Message-----
>>Your problems may lie in the fact that in DOS-based
>
> systems
>
>>your app can get "hands on" the real hardware, while in
>>NT-class systems they cannot, and must instead use defined
>>APIs to go through the "virtual" hardware interface. Some
>>instructions are illegal in the latter systems, and
>
> sometimes
>
>>app code has to be changed.
>>
>>(Just a thought. Maybe that's not the problem.)
>>
>>Roundy wrote:
>>
>>
>>>My R&D department does a lot of work with com ports.
>>>Communicating to devices via com ports, programming
>>>devices. In windows 98 the com ports worked just fine
>>>without fail. Since we have Windows 2000 and or
>
> Windows
>
>>>XP installed they loose commnications a lot of the
>
> time.
>
>>>They also get the com ports so hung up that the only
>
> way
>
>>>to "fix" the problem is to either reboot the system, or
>
> go
>
>>>into device manager and disable and re-enable the
>
> device.
>
>>>Is this related to how the new operating system's
>
> handle
>
>>>com ports, how they are configured, or is it that the
>>>software is not compatible with this version of
>
> windows.
>
>>>This is happening on multiple machines. Help
>>
>>.
>>