Hello All,

I have a challenge that you might be able to help me with. I have an older DOS/dBASE program that will not PRINT anywhere other than LPT1.

So I followed the instructions here:
http://geekswithblogs.net/dtotzke/articles/26204.aspx

Now I can print from the command line, but I still get the same error from the DBASE program. I was thinking that since both DOS and dBASE are looking to LPT1 that if I could get it to work for DOS the dBASE program would follow. But it seems like I am wrong. I was wondering if anyone would be able to point me in the right direction for this.

Thanks!What version of windows is this?

If XP you have to realize that the command line isn't DOS. It just HAPPENS to look a little like DOS. Every DOS based program that you execute in XP runs in a VIRTUAL DOS machine. Unfortunately not all programs runs correctly in this virtual machine.

I'm sorry I don't have a solution here, but just thought I'd share what I think might be the root of the problem.Deerpark - thanks for the reply!

The legacy program was written in dBASE 5 for DOS. THOUGH the print setup in the program just uses the default DOS printer settings. Which from what I understand defaults to LPT1. I am aware that the command line and DOS are not the same, but I was hoping that the emulation was close enough. Aparently not. The method I had posted previously will work on the second laptop I am working on, though it actually has a parallel port.

So far is seems like my only option is to use DOSPRN. Which is bad because that will allow text changes (centering, shrinking, etc.)

That is, unless I can find a computer manufacturer that will make laptops with parallel ports. Why not just save the job to a file and then use another app to print it? ?Read the comments on the article you mentioned. I have not tried it, but I like the fake printer idea.Thanks everyone for the input!

I did find out if the actual physical port was present, that the net use method was the way to go. But the computers we will be using will not have that port. ALSO, DOSPRN isn't a bad solution, which we will hopefully be using.