BusinessVision Turbo fails to start

[edbored]

I'm evaluating vDos as a way to migrate an old (1998) BusinessVision Turbo application.

I'm getting the windows "how do you want to open this file" when one of the application extensions are called (COBLIB.DLE).

Autoexec:

use f: \\lnxbox64\edward\edward\fakeroot
f:
cd bv
call bv2

bv2.bat (program is in F:\BV):

ECHO OFF
SET P1=%PATH%
PATH=\bv;%PATH%
SET COBDIR=\bv
TBOTURBO
PATH=%P1%
SET P1=

Log file:

vDos 2019.05.01
0.11 C: => (Local) C:\vDos\
F: => (Remote) \\lnxbox64\edward\edward\fakeroot\

Execute: TBOTURBO.EXE
0.12 Int 2F unhandled call 9700
Int 2F unhandled call 9800
Int 2F => 208:002d

Execute: COBLIB.DLE
0.34 Int 2F => original
1.11 Delayed logging, set w/o DOS call:
Int 22 => original
14.64 vDos ended by EXIT (0)

I was thinking that "DLE" file might be similar to the old Turbo Pascal overlay files, except that I found this in some ".LBR" files:

"Micro Focus COBOL Library File" - and the DLE file contains reference to Micro Focus as well.

Is there anything I can do to make this work?

Thanks.

Cheers,

EdB

[Jos]

What if you run the application locally?
So copy edward\edward\fakeroot to the Windows drive.

Jos

[edbored]

That worked - moving the \BV folder to "C" (vDos C:) and changing the autoexec to match (removed the "USE F: ...) allowed the program to run.

I then added a data folder to \BV then even manage to load company data - which is awesome (vDos is very slick)!


I tried setting this up as "portable" - copying vDos.exe, autoexec.txt and config.txt to \\lnxbox64\edward\edward\fakeroot folder and ran.

Back to COBLIB.DLE error:

LOG file


         vDos 2019.05.01
    0.17 C: => (Remote) \\lnxbox64\edward\edward\fakeroot\

    0.20 Execute: C:\bv\TBOTURBO.EXE
         Int 2F unhandled call 9700
         Int 2F unhandled call 9800
         Int 2F =>  208:002d

         Execute: COBLIB.DLE
         Program not executed/loaded (2): COBLIB.DLE

         Execute: C:\bv\COBLIB.DLE
    0.42 Int 2F => original
    1.20 Delayed logging, set w/o DOS call:
         Int 22 => original
    7.76 vDos ended by EXIT (0)

Not sure where to go next - but very encouraged this can be made to work!

(One thing, "fakeroot" folder is on a Linux box if that makes a difference).

EdB

[edbored]

Just FYI, here's the result of "SET"


WIN_VDOS=
COMSPEC=C:\COMMAND.COM
PROMPT=$P$G
PATH=\bv;
COBDIR=\bv


EdB

[Jos]

I already thought it would be Linux (\\lnxbox64).
Problem will be Windows doesn’t correctly report what a .DLE file is supposed to be if it’s located on a non-Windows drive.
That is corrected for .EXE, .COM and .OVL files, I’ll add .DLE files.

Jos

[edbored]

Yeah, "lnxbox" is a pretty good indicator...


I moved "fakeroot" from the linux box to a Win7 vm on my laptop, and it ran nicely.

At this point, I think I'm good - the customer using BV is migrating from Win7 to Win10 - so it should be fine on his site.

He's using a workstation as the "server" for three other PCs. I'm trying to convince him to start using a NAS instead, so recognizing those .DLE files might be needed some day.

Thanks for great support!

I just need to confirm on customer site that the printers will be recognized - they are currently mapped with "net use lptx \\server\printer /persistent:yes" - so I don't expect any issues with setting up the printer in windows and using LPTx=SEL:"printername"


Going to try and get this tested by Monday.

Cheers,
EdB

[Jos]

You should indeed urge the customer to get a NAS. Not depend on a Windows workstation with an user ‘messing’ around!

.DLE files are added to the list of exceptions in the next vDos version (expected release March 1st). But to get rid of a questionable (based on extensions) list of exceptions, I’ll probably tackle it more direct: Read the supposed header data upfront (is anyway read for DOS executables later on), then determine if the file is a DOS executable and forgo getting the info Windows delivers.

"net use lptx \\server\printer /persistent:yes" has/had a major limitation: The printer has to support ASCII data streams. LPTx=SEL:"printername" is far more flexible: Optionally addressing the printer as before with the RAW option, it adds printing to (virtual) Windows-only (GDI) printers, and more (Printing.pdf).

Jos

[edbored]

I spent yesterday testing everything with the customer - did initial testing on a Win10 vm on my laptop connecting to his data, then converted one of his Win7 workstation to Win10.

There was an issue with printing - I tried LPTx=SEL:"printername" (with and without RAW) - didn't work.

Found this in the printing forum:

LPT1="%windir%\system32\print.exe" /D:LPT1 #LPT1.asc

Success!

Customer actually went for the "high-five" when the invoice print test came out.

He bought the network license on the spot...

Good news about next version supporting NAS for DLE - the data and setup lives on the owner's workstation, and he's pretty aware of the need NOT to mess around, but...

Thanks for quick support - and let m e repeat: you have a really slick product!

EdB

[Jos]

Thanks for the compliment, but strange that LPTx=SEL:"printername" didn’t work.

You didn’t add that literally to config.txt, vDos complaining it’s an invalid option?

For DOS LPT1 It has to be:
LPT1=SEL:"printername_as_shown_by_the_printer_selection_dialog if_no LPT1=_line".

Jos

[edbored]

Yes of course: it was actually LPT2=SEL:"Invoice" (this is an old dot-matrix printer shared as "Invoice").

I'm back to see him tomorrow - I'll try a few more things.

Thanks.

EdB

[edbored]

<bonk><bonk><bonk>

Don't mind me, that's just the sound of my banging my head on the desk...

I visited the customer to make sure all is well.

Changed the printer setting to:

LPT2=SEL:"\\servername\Invoice" RAW

That worked perfectly.

Because, you know, it's called Invoice as defined on THIS workstation, but it's actually installed on that box over there!

Also took the time to tweak the colours - managed to fix a long-standing (some 25 years) complaint the customer had about this program...

Did I mention you have a slick and very cool program?

Customer is extremely happy - he was told it was "impossible to run an old DOS program in Win10" and that his options were:
- new windows business software ($5k+) to manage his shop; or,
- virtualize his win7 boxes and run them on sub-net in a new ESXi server ($5k+); or,
- get new win10 workstations and run the DOS program in a VM on each box($5k+, excluding time to reinstall all win apps and xfer data)

Instead, for each of his workstations (and a laptop), we:
- cloned the HDD to new SSD
- put the HDD aside as "backup"
- did an in-place upgrade from Win7 to Win10
- set up vDos on the box with the database
- shared that vDos folder so all other workstations could run his program.

Total cost (including my time) about $1600.

And given the move from HDD to SSD, everything flies.

Customer is currently looking forward to hearing from the various software and networking sales people who quoted the other options - so he can tell them that "it AIN'T impossible to run DOS in Win10" and "now go away".



EdB

[Jos]

Glad to hear you got it all working fine.

In time, you may switch to LPTx= w/o RAW. Printing to any (virtual) Windows installed printer, like www.vdos.info/faqs.html - Printing - Digital printing with stationary (PDF). Though you’ll have to experiment with HORZ: and VERT:, those are metrics orientated (we Europeans were left behind too long).

Hope you didn’t spent too much time with COLORS=. That can be very time consuming, so it’s dropped in the next version. No one seems to use it, instead there will be a THEME=<0-9> directive. See www.vdos.info/screenshots.html - Control a remote... - FoxProX: The same, a… The next version will also even be more slick, though not all seem to like that. Insisting om a blinking cursor, colors, double lines, and more 'original' stuff.

Software and networking sales people are like car sales people, but w/o any DOS knowledge. So for the latter, not really to blame. And DOS apps in Windows 32/NTVDM can be cumbersome/complicated. Running those in vDos should be more reliable.

Jos

[Jos]

Addition:

Although vDos should extend your DOS app(s) lifespan to that of Windows (2099), the best solution still remains the switch to genuine Window apps.
You ‘only’ have to be very cautious to what is offered replacing the DOS app. It’s all about functionality, not looks or bloat! Some horror stories about failed (and costly) Windows migrations.

Jos