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.
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"
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).
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:
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".
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.
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.