en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en nl en en en en en en en en en de en en en en en nl en en en en en en en ja en en en en en en en nl en en en en en en en en en en en en en en fr en en en en nl en en en en en en en en en en en fr en en fr pt en en id en en en en nl en en en en en id en en en en en en en en nl en en en en en en en en en en en fr en en en en nl vi en en en en fr en en fr pt en en sv en en en en nl en en en en en en en en en en fr en en en en nl fr en en en en fr en en fr pt en en en en nl en en en en en en en en en fr en en en en nl en en en en en fr en en fr pt en en en en de en en en fr en en en en en en en en en pt en en en en en en
By logging into your account, you agree to our Privacy Policy, personal data processing and storage practices as described therein.
Forgot password or user name?
Search in titles only Search in PowerBASIC for DOS only
You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
All Time Today Last Week Last Month
All Discussions only Photos only Videos only Links only Polls only Events only
I'm a new registrant, so hopefully I have an age-old question...
Is there any way that a compiled PB3.5 DOS app will run in a Windows 95 DOS window? My app uses a com port to dial clients and, when running in a full DOS window, does not "find" the com port. Beyond that, the app suspends executing completely while the DOS window is minimized, and then continues again when the DOS window is maximized.
Obviously, I do not want to re-write my app in VB. Seems like someone should have figured out a solution to this type of problem already, since it would be a huge bridge between DOS and Windows.
Any advice would be appreciated.
I have written PB 3.5 Serial Apps too that also do not work properly under windows. The best solution that I can think of is to port your code over to PB's Console Compiler. This is a pretty easy port in most cases.
Summit Computer Networks, Inc.
Join Date: Aug 1998
5 Aug 2000, 01:24 PM
Really, you've got two problems here. The easy one first. To allow your DOS program to run in the background, you can create a shortcut on the Windows Desktop and configure it properly. Create the shortcut, right-click it, and select Properties. Go to the Misc tab and make sure there is no checkmark in Always Suspend under Background. Your program should now run when minimized. (There are a few exceptions that will prevent the program from running when minimized; I recommend you get a good reference on running Windows 95/98 for more information).
DOS serial communication programs sometimes have a hard time running under Windows. Specifically, if another program is using the serial port, Windows will prevent your program from detecting and using the serial port. Also, DOS programs can never use WinModems (sometimes called software modems). I have run lots of DOS communications software under Windows (including some written with PowerBASIC), and it works just fine.
Information Management Systems, Inc.
Information Management Systems, Inc.
Join Date: Aug 1998
6 Aug 2000, 04:26 AM
I too have written DOS COMM's applications that run fine under Windows, but there are a few tricks and snags to be aware of.
1. Windows often corrupts the flow of XON/XOFF software flow control data... always use CTS/RTS (hardware flow control) where possible.
2. Hogging the com port... edit SYSTEM.INI and in the [enh386] section, add the following line: COMxAutoAssign=2 where x is the com port number. This is necessary in Win 3.x and Win95. (I'm not sure about it's effect in 98/ME in this respect).
3. In timing-critical applications, you can tell windows that your task is a "critical section" (CS) and this halts Windows for the duration of the CS (note: this type of CS is different to a CS that a Windows programmer will come across).
PBFax is a prime example of the need for a CS during the fax session - if Windows takes away too many CPU cycles, then it can destroy the fairly critical timing of the data flow.
Here is an example of how to do it... (note that you do not want to use a CS for long periods of time or Windows may 'object')
IF BIT(pbvHost,8) THEN ' Signal Windows that this is a "Critical Section" ASM MOV AX,&H1681 ASM INT &H2F END IF CALL PBFax(Fax) ' Now fax the converted document. IF BIT(pbvHost,8) THEN ' Signal Windows to end the "Critical Section" ASM MOV AX,&H1682 ASM INT &H2F END IF
Join Date: Nov 2006
6 Aug 2000, 06:11 AM
You may try Shirlun's method, use a dos/windows bridge to do
communication tasks. you can get some information at this link:
Join Date: Feb 2000
17 Aug 2000, 10:08 PM
Just want to clarify someones post that DOS can NEVER use
WinModems.... Dynalink 56k "winmodems" come with VIP software
(installs as part of the modem driver)that maps com ports and
irqs' with the windows driver thus enabling DOS programmes to
use "winmodems". You can also download the software as a
separate package (about $29US I think), I can't remember the
address off the top of my head but its not hard to find!
Join Date: Aug 1998
17 Aug 2000, 11:17 PM
Does that price include royalty-free distribution rights? In other words, does the software need to be purchased separately for each installation or can I buy it and distribute it with my DOS applications. Also, does it work with other brands of WinModem's? I'd bet this emulation software does not provide Class 2 or Class 2.0 fax services either.
IMHO, Winmodems are simply a false-economy for "real" data transfer work or faxing. There are plenty of "real" modems available and cost is not much more than a winmodem (at least that is how it is in New Zealand).
Join Date: Aug 2000
17 Aug 2000, 11:45 PM
Please define "long periods of time" in your post above. Milliseconds, minutes??
Do you use it for the whole Faxing time, or break it up, so that WIN can have the control it so desperately needs!
Does the CS notification work in Win9X?
Join Date: Aug 1998
18 Aug 2000, 05:02 AM
I use it for the whole duration of the fax including dialing, and it seems to work fine under all versions of Win3x and Win9x. I've done preliminary testing under Win2K and it seems to work of there.
My tests were for single or two page faxes only, so at the most I've used a CS for around 2 minutes without any problems. I would not recommend doing that on a server though!
8 Sep 2000, 06:38 PM
Originally posted by Scott Slater:
I have written PB 3.5 Serial Apps too that also do not work properly under windows. The best solution that I can think of is to port your code over to PB's Console Compiler. This is a pretty easy port in most cases.
Thank you for your reply to my posted question. I'm very interested in your solution where I can port my code over to PB's Console Compiler. I'm afraid I know nothing about this, so would you please let me know where I can get this?... Or simply having someone try porting it to test the results first? I'm very interested in getting my app to work in a DOS window without rewriting it. Any help toward this goal would be very much appreciated. Best Regards, Wayne
Join Date: Aug 1998
8 Sep 2000, 08:02 PM
Serial comms in Windows is different to DOS, so you'll definitely need to rewrite portions of the code that perform port I/O.
Search the BBS for "COMM OPEN" and you should get some idea of how your code would look with PB/CC.
Copyright © 1998-2022 PowerBASIC Tools, LLC - All Rights Reserved.
Powered by vBulletin® Version 5.7.0
Copyright © 2022 vBulletin Solutions, Inc. All rights reserved.
All times are GMT-5. This page was generated at 10:52 PM.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.