COM1 under Foxpro Dos & Windows XP ?

Hello guys,

I have a application in foxpro 2.5 dos running in Windows XP environment.
they got a cash drawer that opens when issuing a command to the com port.
under dos (command prompt) I created a text file called drawer.txt that contains 00000000 (8 zeros)
and created a batch file that copies that file to the com port
copy drawer.txt com1
when in dos prompt I issue the command kick , the drawer opens.

So I opened my application and where I wanted to open the drawer, I wrote
and closed the application thinking it will work ...
well it didnt !
it gives me "Error writing to port...."
please help me....

PS. there is a printer connected to the LPT port and it is functionning okay...
and the drawer is on COM1
Who is Participating?
Now heres an interesting wee snippet I just came across Pierre. (I'm assuming my suggestions above failed)
Although they are waiting to get data from the com port I notice they are sending a command before they get the data back.

As per Response number 6 here 1/2 way down the page,
Try the mode command in your batch file.
From dos if you do a mode com1 /status you in theory should see the same as me.
Status for device COM1:
    Baud:            1200
    Parity:          None
    Data Bits:       7
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON

So it's going to use those settings in the VDM in all theories.

But most serial devices I know of definately don't use 7 data bits.
I can also see RTS circuit: ON  So ready to send (RTS) means I can send out COM1
I'd be interested to see your results for the MODE COM1: /status command
Adding MODE COM1: baud=1200 parity=N data=8 stop=1 as the first line in your batch file before you send your command could indeed help. (I'm running out of ideas but this sounds feasable)
Windows itself defaults com ports to MODE COM1: baud=9600 parity=N data=8 stop=1
I'd try them both unless you know the baud rate your cash register is expecting.

Heres the problem the way I see it.
You are running under windows 16 bit VM for your program.
Windows inherently especially with Windows 2000, XP etc... HATES things especially older programs having direct access to hardware. It should be talking to windows.
As per rgbeans tip here
"The concept violates one of the basic principles of these OS's - no direct access to the hardware by an application - everything must go through the OS."

NOW you running it from a "dos prompt" is actually runing it from inside a windows component. Yes the dos prompt is a windows component and can talk to windows properly without talking through the VM.

Ways to go?
Without seeing the source for the program itself thats hard.
Have you tried running the application in compatability mode?
(Create a shortcut that starts the App, right click on the shortcut, select properties, Under the compatability tab, check "Run this program in compatability mode for", and I'd select Windows 95 or 98, then click apply). Try them all and see if they have any effect.

Try changing your batch file
From copy drawer.txt com1
to cmd /c copy drawer.txt com1

Those would be my first 2 tests.

FoxPro DOS 2.5 is 32-bit.
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Not necessarily.
Here is a fix for Foxpro from Microsoft as an example.

"In the 16-bit version of FoxPro version 2.5a or 2.5b for MS-DOS"
I know of no one using anything but 32-bit of FoxPro for DOS under WinXP.

If it were FoxPro for Windows, that is truly ugly 16-bit.
The old 16-bit version used expanded memory.  The 32-bit version uses extended memory.  The difference in the file that was run for development (to create a standalone exe) is one had an "L" suffix while the extended had the "X" suffix.  FoxProX.exe would use the extended memory that a PC has and is/was 32-bit.
Any feedback on the suggestions?
I'm wondering whether or not you can treat that device like a printer on COM1: and then use the ??? command to send that string as output to that pseudo-printer device as far as FoxPro is concerned.
Or, since you have
copy drawer.txt com1
what happens when you add a colon after the com1?
copy drawer.txt com1:
ammounpierreAuthor Commented:

ammounpierreAuthor Commented:
was wondering , If I create an executable in VFP that would open a form in which I have MSCOM port to COM1 and after few seconds writes to that ports then releases the form...
but that's too much hassle for a "silly" thing... as to open a drawer... could it be that complicated in WinXP ???
ammounpierreAuthor Commented:
?? anyone ?
even the com component I did in vfp did not work under dos.
it did not kick the drawer...
error writing..
Thanks for the accept Pierre.
Can you tell us what settings you changed since I could not see the results of the MODE COM1: /status command?

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.