Unable to print using FP Dos under Vista

[CouponPages]

I still have a handful of clients who 2.6 Dos applications, so I decided to test them under Vista in order to be prepared for compatibility questions.

What I found was that in my particular setup, which is a USB printer redirected to LPT1 via a NET USE does not work. I get a printer not ready error whenever I print.

I even tried sending text files to the port using "COPY FILE MYFILE.TXT to LPT1", which gives me a "Write fault error writing device LPT1". Even trying to pass a file back to the operating system with commands like "run copy (filename) prn" generates errors, which means the system blocks the devices. This happens even if I run my command prompt as Administrator.

The main reason some of my clients still use the DOS version is that they print multi-part forms on dot-matrix printers and the DOS version cranks them out at blazing speeds.

FoxPro 2.6 for Windows does not have this problem. I can print directly, and I can use COPY FILE MYFILE.TXT to LPT1 without errors. For what it's worth, simply having them run the legacy code in the Windows version is a decent workaround, but I was wondering if this could be the final nail in the DOS coffin.

Has anyone else tried printing in the DOS version?

 

[cricket]

Please clarify if all these commands, you listed as failing under Vista, work under WinXP.

 

[CouponPages]

Yes. I have a two hard drives in the same system. I have never had a problem with printing in XP.

Here are the facts:

1. I set up a standard share for the USB printer.

2. From a command prompt I issue the following without errors:
NET USE LPT1 \\Computername\Printername

3. To confirm the connection, I typed "DIR >LPT1", the printer responded by printing the current directory. This works fine in every version of Windows, including Vista.

4. I then start the DOS FoxPro 2.6 EXE and type "DIR TO PRINT", or any command that can print... "Printer Not Ready... Retry?".

5. I also tried "Copy file "filename.txt" to "lpt1" ... this generates a "Write fault error writing device lpt1... Abort, Retry, Ignore, Fail?" prompt... ditto for writing to PRN or LPT1.TXT.

6. Another oddity is that the old behavior of calling a file something like "LPT1Test.txt" no longer directs to the printer port... it now actually generates a filename.

7. I tried making a shortcut to the application itself, then adding "Full control" to the user... and tried "Run as Administrator"... still nothing.

8. Another odd thing... If I try to type "RUN copy filename lpt1", I get a "File not found... 0 file(s) copied", which made me think I had the wrong filename... but it was correct. Then I assumed it must be running the shell from outside the working directory, so I added the entire path to the command... still nothing. Last, I tried "Run DIR c:\pathname\myfile.ext" and believe it or not, the size, date and time stamps are there and they are accurate... but the filename is hidden. This clearly means Vista is blocking Dos programs from accessing certain directory attributes.

9. In fact, when I put "copy filename.ext lpt1" into a batch file then tried to run it... it didn't work, nor did going to the command prompt and typing it directly. For whatever reason the option to copy a filename to a port is not allowed, nor can you use type filename.ext >lpt1.

10. I even tried the old standard "PRINT Filename.ext"... which you would think was bulletproof... no luck.

11. Based upon these tests it's clear that FoxPro must be using a similar technique internally to print and since they block these kinds of redirection, it can't print.

12. There are two other ways to try to print that I have NOT yet tried, but will as soon as I can move some printers around. First, I have not tried printing to a share on ANOTHER computer. Second, I have not tried to print to a parallel port (my laptop does not have one, but I use a USB to parallel to reach my printer).

Assuming they are blocking applications from using older file access methods, there may not even be hope in running
FoxPro 2.6 for Windows has no troubles running the exact commands and it seems to run quite well under Vista, although from what I have read it may not run under the x64 versions because they eliminated 16 bit support.

If I am not alone in this problem this is a clear sign that Vista is going to be a real challenge for Dos users. I'm assuming Virtual PC will always be an option (I'll need to try that too), but native support looks tough.

 

[tesar]

Coupon,
as i have not Vista, only XP,
interest me if help "PrintFile" ...
(question missed from VFP, why ?)
Tesar

 

[cricket]

Can you attempt to resolve your problem in 2 stages.
Stage 1 - use a traditional parallel printer arttached to LPT1
Stage 2 - use USB printer

 

[CouponPages]

Unfortunately, the only PC in my office with Vista does not have a parallel port, so I can't test that configuration.

I tried a direct connection to a USB printer (without a USB/Parallel adapter), that didn't work either.

This morning I also tried to change the security settings of the printer in the control panel... I added full control to the Everyone group, and it still fails.

The thing that brings me to believe this is part of a much bigger issue is that even when you try to use the RUN command to try to access files, Vista seems to block access to them. Vista clearly is going to be a real challenge for legacy DOS programs like FoxPro 2.6.

The ironic thing is that the only clients of mine who still use the DOS versions do so because it was the most reliable way to send pure text to the printer (for muti-part forms in dot-matrix printers).

I'm worried that even if an oddball hack can be found to let it print, the underlying file access permission issues could be an even bigger hurdle down the road. I'll need to stress that anyone using Vista will need to run the Windows versions.

That said, I decided that I would check the version of Windows when each program starts, and put a warning on the screen if they were running Vista. Unfortunately the function OS() returns DOS 05.00, which is what previous versions of Windows returned.

 

[Foxtech]

hi Coupon,

You try to download the printfil utility to see if it works or not.

http://www.printfil.com

FoxTech

 

[ihabaloul]

I am using DOSPRN.EXE program which solve such problem.

 

[dbMark]

At least some of your problems may be explained here in this Knowledge Base article:

Help and Support Knowledge Base #926657

http://support.microsoft.com/kb/926657

Some 16-bit DOS-based Programs and the Command Prompt will not run in full-screen mode in Windows Vista

SYMPTOMS
You may find that some 16-bit DOS-based programs do not run in full-screen mode in Windows Vista. You cannot set a Command Prompt (CMD) window to display in full-screen mode.

Note: This symptom only applies to 32-bit versions of Windows Vista. 16-bit programs are not supported on 64-bit versions of Windows Vista.

CAUSE
The issue occurs because the Vista device drivers do not support running all of the DOS video modes. The Vista device drivers are based on the Windows Vista Display Driver Model (WDDM).

WORKAROUND
You may be able to work around this problem by installing the Microsoft Windows XP version of the video drivers for your video adapter. Contact the manufacturer of your video adapter for more information about how to obtain the Windows XP version of the video drivers for your video adapter. (See the MS article for vendor contact information.)

(I found this KB article referenced as an explanation on a dBase forum.)

 

[dbMark]

Perhaps I should add that my prior post meant to say that you may have fewer 16-bit program problems when using the 32-bit version of Vista, whereas 16-bit programs are not "supported" at all in the 64-bit version of Vista. Hmm, does "not supported" means maybe 16-bit applications work, maybe they don't?

Anyway, in your testing, you may need to differentiate between the issues encountered in 32-bit and in 64-bit versions of Vista.