Btrieve

[mtruese]

16 bit application runs but is not detecting btrieve which is used to access data files. Any experience getting this to work?

[leecher1337]

If you are using Pervasive SQL Server as a BTRIEVE backend, you usually get a BTRIEVE VDD driver installed that allows NTVDM to access the BTRIEVE Server. However, you can also use my version of the driver, as it has a performance optimization included: https://github.com/leecher1337/btrieve-vdd But generally, driver shipped with Pervasive SQL Server should work just fine.

For BTRIEVE detection, it's important that the Service routine for Interrupt 7B lives at offset 33h, otherwise, it won't get detected.

[mtruese]

Thanks for the response. Any idea if there is trouble using net use for printers. e.g. net use lpt2 \machine-name\printername

[leecher1337]

net use with printer works as usual (like on Win 7 32bit). Just pay attention to the usual Session isolation fuzz introduced with Windows Vista, i.e. you cannot access a printer that got mounted with net use in an admin session as a non-admin and vice versa (admin cannot use printer mounted by non-admin session). Sonet use must have been executed in the correct context, but I guess you already know that pain.

What doesn'T work is raw LPT access to the hardware port, as parvdm.sys driver shipped with 32bit Windows Versions is not present on x64, but there was no request for that so far.

[mtruese]

Thanks for the comment. I am not printing RAW and it is the correct session. I know the net use is working as I can echo out to it and it prints. Nothing from the application however. Enabled SMBv1 on both sides so I dont think that is an issue. Appreciate any other input.

Thanks

[leecher1337]

NTVDMx64 just - like normal NTVDM - opens LPTx with CreateFile() API and writes to it. Maybe you can use Process Monitor to check whether there is an error opening the LPT port. The checked (DBG) Build of NTVDMx64 also shows an error in YODA (possibly also an DebugView console) if opening the port fails. Here is a little test program that tries to open the specified file and reports whether it is successful or not: testprj.zip

I tried running it inside the DOS-Session in command.com to check if printer is accessible from there:

c:\Temp>command
Microsoft(R) Windows DOS
(C)Copyright Microsoft Corp 1990-2001.

C:\TEMP>testprj LPT2
hFile=FFFFFFFF, Err: 2
Err: 2

C:\TEMP>net use lpt2: \\server\BrotherH
Der Befehl wurde erfolgreich ausgeführt.

C:\TEMP> testprj LPT2
hFile=0000003C, Err: 0
Err: 2

Err=0 success. Err in next line can be ignored. As soon as it was accessible, I was able to print i.e. from MS WORKS.

[mtruese]

Could not get it to print. Testprj gives me Err:0 only when trying to a physical port. Any other suggestions? Otherwise looks like printing is an issue. Appreciate any assistance

[leecher1337]

As testprj is a plain 32bit Windows Application without any NTVDM dependency, this indicates that there is a problem with your (via net use) redirected printer port then, nothing related to NTVDM. Which error code do you get? 5 would be access denied, 2 would be file not found. You can check mappings of the devices via Sysinternals WinObj.

[mtruese]

Figured it out. Needed these lines in a Admin Command prompt. Appreciate your assistance.

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled

[lucasasrc]

leecher1337, I've been using your solution with DOS2USB since I was getting print errors. Inside a normal cmd, my network printer in lpt1 works fine, but in ntvdm it won't. I've tried the solution mentioned above and ran this testprj and mine is giving a different error, can you help me?

C:\USERS\LUCASA~1>testprj lpt1
hFile=FFFFFFFF, Err: 2
hFile=FFFFFFFF, Err: 3
\Device\LanmanRedirector\;LPT100000000000f625c\ceasa8006\xeroxpha

[leecher1337]

So you are maybe using a GDI printer that doesn't support output directly?

I don't know DOS2USB, but I always use DOSPR.ZIP for crappy GDI printers and it works fine too, i.e. to capture EPSON printer sequences and render it to a GDI printer of your choice and display print dialog before printing, start dospr with:

dospr -s -m lpt1

-m lpt1monitors LPT1 for printer data and -s pops up printer selection dialog (without it, it would just use the default printer). Does this help?

[lucasasrc]

Oh my, thank you VERY MUCH, it is working "perfectly". Now my Clipper program is making me select which printer I want to send but I still have one "minor" issue. The printing have some PCL commands to adjust page orientation, font size etc and it isn't reading them. There is any addon I can use to finally perfect the solution?

[leecher1337]

Does your printer support PCL natively? If so, dospr can also be used in "raw" mode (so it operates roughly like with NET USE):

dospr -s -r -m lpt1

If you want to terminate a running dospr-instance, use dospr -d, as only 1 instance should be running.

The dospr contains a file epson.seq (originally taken form printfil) which contains EPSON ESC/P sequences for certain actions. Most DOS applications should theoretically support ESC/P depending on the printer driver you select. If you have control over the control codes, you can use these sequences from epson.sql instead of PCL. See also: https://www.printfil.com/manualen/c5-1.htm

I hope that works for you.

[lucasasrc]

Perfect solution. Printing now works like intented. Now we can continue using our Clipper platform on newers computers without anything holding us. Thank you very much! @EDIT: Just a small question that doesn't effect the solution. Using -r command makes Windows PDF printing bug it up?

[leecher1337]

Glad to hear that it works for you. :)

Regarding PDF printing, I guess a PDF printer driver wouldn't be too happy with raw PCL input, as it can't rander that, so yes, using a raw printer may not give you the possibility to render a PDF via PDF printer driver. However, there are also solutions to this using i.e. GhostPCL which would render PCL output to Postscript (and process ghostscript to PDF). You can either start ghostpcl conversion directly from Clipper application (recommended) or capture printer output in some way and then just pipe it to a ghostpcl processor. See this thread for details (it contains an outdated dospr.exe version, but the rest of the files and documentation pretty much describes one possible way to accomplish PCL->PDF conversion. readme in package is in English). Forum seems to require registration, if you don't have an account, I have a copy of it that I could attach.

[lucasasrc]

Thank you very much leecher, I think I can continue on my own. Thank you for the amazing support you're providing us! 👍