DOS apps can't use COM in Windows?

DOS apps can't use COM in Windows?

Post by Dan D » Fri, 07 Apr 1995 04:00:00



On my system, I've noticed that DOS applications which try to use
the COM ports will fail if I run them from a DOS subwindow, but
will work properly if I fire them up directly from Windows (via
an icon or by double-clicking on the .exe file in File Manager).

Any idea why?  Is there any way to make them work properly when
launched from a DOS subwindow?  Thanks.
--
"Don't tread on me"

 
 
 

DOS apps can't use COM in Windows?

Post by Tony Lo » Sat, 08 Apr 1995 04:00:00



>On my system, I've noticed that DOS applications which try to use
>the COM ports will fail if I run them from a DOS subwindow, but
>will work properly if I fire them up directly from Windows (via
>an icon or by double-clicking on the .exe file in File Manager).

Do you have any windows apps running that might have taken over control
of the com port in question?   Are you using a serial mouse that's
connected to the com port your communications program is using?  Check
the type of mouse you are using and its settings.

Try changing the com port settings of the DOS app.  You SHOULD be able to
run a DOS comm program Windowed; I did it just last night to connect to a
local BBS with Kermit 3.13.

I t could also be that your DOS app simply refuses to run from a window.  
Can you run other DOS apps windowed successfully?  If so, then you'll
probably have to run the comm program full screen.

Hope this helps a little.
-

Although the moon appears smaller than the earth it
is farther away.

 
 
 

DOS apps can't use COM in Windows?

Post by Dan D » Sun, 09 Apr 1995 04:00:00



>>On my system, I've noticed that DOS applications which try to use
>>the COM ports will fail if I run them from a DOS subwindow, but
>>will work properly if I fire them up directly from Windows (via
>>an icon or by double-clicking on the .exe file in File Manager).

>Do you have any windows apps running that might have taken over control
>of the com port in question?

No.

Quote:>Are you using a serial mouse that's
>connected to the com port your communications program is using?

No.

Quote:>Try changing the com port settings of the DOS app.  You SHOULD be able to
>run a DOS comm program Windowed; I did it just last night to connect to a
>local BBS with Kermit 3.13.

I think you've misread my post.  It's not that I can't run it in a window,
it's that I can't run it when it's launched from a DOS shell window.
I *can* run it when I launch it directly from Windows without using the
DOS shell (e.g. I launch it from File Manager).

Quote:>It could also be that your DOS app simply refuses to run from a window.  
>Can you run other DOS apps windowed successfully?  If so, then you'll
>probably have to run the comm program full screen.

Again, that's not the problem.  If I launch it from File Manager, I
can run it successfully either as a subwindow or full screen.  When I
launch it from a DOS shell window, it won't run successfully either as
a subwindow or full screen.
--
"Don't tread on me"
 
 
 

1. dragging an app's debug window locks the app (COM)

I made a debug window in the app I am working on, a part of a COM component.  Then I noticed that any message-generating activities on this window (using the scroll bar or just dragging the window)locks my app. This is a multithreaded app that heavily uses synchronization tools (mutexes, events, messages).

I found numerous references (in Microsoft documentation) of potential problems in using WaitForMultipleObjects function with COM, instead of MsgWaitForMultipleObjects.  They say that since all input messages (say from dragging the debug window) are broadcasted over all windows of a thread (if CoInitialize is called - an apartment is created in the client thread) using WaitForMultipleObjects may create deadlocks (all these parasite messages are not removed from the queue of the COM-generated hidden window).  So I rewrote this app hoping that using MsgWaitForMultipleObjects would fix the problem.  Not at all!  same deadlock.  

Another possibility is that the CSingleLock class I use for locking common resources, uses WaitForSingleObject (in .Lock()) - maybe it is stuck there?  But this would mean that when using COM you have to use a home-made lock class processing these parasite messages, instead of using MFC locks.

Anyway, I am still did not get anywhere. Any ideas?

-----------------** -- Posted from CodeGuru -- **-----------------
http://www.codeguru.com/    The website for Visual C++ programmers.

2. Email Pictures JPEG BMP, and saving

3. Com Port Contention when using MS Dos App

4. speed for XP vs. 98SE

5. porting DOS apps to NT using VDD's

6. That's It!

7. Using COM port in DOS window from WIN95

8. LOOKING FOR A DOWNLOAD

9. Using Sound Cards with DOS Apps in Windows

10. Using DOS compilers to create Windows apps

11. Errors: 'Couldn't Open Com Port' & 'Com Port Already Open'

12. Interface between 16Bit DOS or 32Bit Console App and Win GUI app under Windows NT

13. ERROR: 'Couldn't Open Com Port' & 'Com Port Already Open'