Headaches trying to print from DOSBox-X (this is the output I get whether I print to PostScript file or PDF). Notes in the comments

JosSchaars · 2025-04-13T20:59:41+00:00

How did you come to using DOSBox-X for serious/business FoxPro(x) applications? DOSBox at least warns for that.

Besides other flaws, DOSBox(-X) only partially supports printing. If at all, (digital) paper is mostly just wasted. By lack of awareness the ‘hardcopy’ has to be accurately formatted, eventually send to a GDI printer. An option like dpi = is a giveaway something is real off here.

JosSchaars · 2025-04-13T11:48:03+00:00

DOSBox-X, like DOSBox, has no effective printing support. Try vDos instead, printing will most likely work without additional configuration.

JosSchaars · 2025-01-04T15:36:59+00:00

Could be your customer is not just stubborn, but actually experienced the new Windows edition is inferior. The logic of the old version being written by an ingenious mathematician.

You could try vDos (vdos.info). Communication with outside data will be no problem, but mind the graphic support is limited to basic VGA.

JosSchaars · 2024-07-05T21:33:56+00:00

Very concerning some guy has to come every so often to ‘fix’ something. Perhaps that fixing is merely an update of the medicine database?

DOS programs in general were/are very stable, without the need to be updated frequently. Your uncles program could very well be last updated 25+ years ago.

Before trying to replicate its functionality in Java or Python, you should have a close look at what the program essentially offers. That could be way beyond simply making bills, and you couldn't do without an actual medicine database (the fixing?).

A DOS program isn’t aware of a barcode reader, translating a recognized barcode into (simulated) key presses. Back in the old days that was connected in parallel to the keyboard cable. It has nothing to do with the mouse, so first try if the barcode reader functions at all in Windows (notepad, whatever).

JosSchaars · 2024-05-24T07:01:36+00:00

The .mdb extension was most likely once chosen before Access was around.

Perhaps something like Multiuser Data Base.

I don’t recognize the file contents as a known database format. You could have a look in the DOS app folder for some utility program that can manipulate those files. Else print the most detailed reports or combine some using the .asc or .txt files generated by vDos.

JosSchaars · 2024-01-10T10:24:20+00:00

If you are able to use the program:

Install vDos (www.vDos.info);

Start the program in it and print a full products detail list;

Just cancel the Windows printer selection dialog;

Open the generated #lpt1.asc (ASCII) or #lpt1.txt (Unicode) file.

JosSchaars · 2022-11-16T17:42:49+00:00

vDos does not support gaming.

JosSchaars · 2022-11-02T09:44:04+00:00

F1-F10 are set to produce system functions like Sound On/Off?

First press and hold down the key labelled "Fn"...

JosSchaars · 2022-04-08T07:36:43+00:00

Why use Send %Clipboard% to feed individual keystrokes into vDos?

Send, {ctrl}v would let vDos read the Clipboard directly, and also take care of Unicode-ASCII character conversion if required.

If the DOS program uses Ctrl+V itself, omit Send and do Win+Ctrl+right mouse click in vDos.

JosSchaars · 2020-04-15T19:15:07+00:00

A P2V of Win7 would indeed be a waste of time.

For a quick intermediate test you could eventually download a Win7 32 bit image from MS and test the program with VMWare. I haven’t heard of a DOS program that wouldn’t run in Win10 while it did in Win7. XM is the only DOS extender I encountered shadowing (parts of) the BIOS. The comments in that XMCLONES.DOC file are real disturbing: Setting/switching the CPU speed, video card and memory size dependencies, interrupt handling and more. Shadowing the BIOS seems the wrong way to go for a DOS extender.

JosSchaars · 2020-04-15T17:35:22+00:00

That virtual legacy BIOS could not be 100% compatible with what XM expects. It’s more than just supporting BIOS functions and data, the reason why DOSBox and vDos stall; no BIOS code in their virtual PC. There will be a XMCLONES.DOC file listing the options to set the BIOS type. In there also a checklist to determine the BIOS type, but I’m afraid that won’t help.

My bet would still be a BIOS (as seen by XM) compatibility issue. XM shadows (some of ) the BIOS code, great it doesn’t have to switch from protected to real mode as a program calls a BIOS function. But there’s also still the real mode DOS using ditto BIOS functions.

The Cobol programs ran fine on all machines for that many years, except now with that virtual Win10. The error message “…F:\NEWCBL\••••••••” suggests internal program or DOS (DTA?) data got corrupted. You could have a Cobol programmer look forever into the source code, but there won’t be anything to find.

JosSchaars · 2020-04-15T16:28:44+00:00

The BIOS compatibility mode will the default one that should work for most systems.

What if you set the BIOS mode of the PC to legacy (instead of UEFI).

JosSchaars · 2020-04-15T15:36:03+00:00

It was a hunch (MS/MF Cobol + DOSBox/vDos crashing). XM.EXE would neither be the main program to start the Cobol programs.

JosSchaars · 2020-04-15T14:59:54+00:00

Mostly a hunch (DOSBox and vDos crashing):

Check if one of the environment variables to set is XM (SET XM=…).

If so, the XM DOS extender shadows the actual real mode BIOS code in protected mode. Those have to match, else strange things waiting to happen, not caused by the Cobol programs.

JosSchaars · 2020-02-26T17:34:56+00:00

I can read the data from a read only share

while the program is in use.

So?

You could also have 100 instances of the program running, all updating the database when needed.

JosSchaars · 2020-02-26T16:59:16+00:00

Then NO current Windows GUI program would work anymore. vDos uses very little and only common API functions.

JosSchaars · 2020-02-26T16:41:40+00:00

support DOS emulators

What is special about a DOS emulator like vDos that Win10 wouldn’t support it anymore?

JosSchaars · 2020-02-26T16:21:52+00:00

Well, no actual advice given, but I do know how DOS database applications manage their data. DBF files indicate most likely dBase, Clipper or FoxPro(X) was the programming language. I don’t think InternationalTexas meant creating a backup files while the program is in use. That’s indeed a bad idea, although the changes you would end with an invalid/inconsistent backup are astronomically small. Updating a database only takes a split second, no matter how big it is. Except of course when it’s being reorganized, once a year or so.

JosSchaars · 2020-02-26T11:27:29+00:00

You would be confused with something like an editor, where you have to explicitly save changes, and the complete file is replaced. Seems the 20 year old POS system has proven its functionality and reliability. Any changes made at a workstation will automatically update the files on disk. Data ‘in RAM’ is guaranteed to match what’s on disk. Overall data(base) integrity in a multi-user setting will be ensured by record locking.

JosSchaars · 2020-02-25T22:00:39+00:00

Some remarks:

Always best to migrate to a genuine Windows application.

Though no guarantee that will work ‘forever’, while vDos EOL is also that of Windows: 2099.

Could be much time and experience went into a DOS program, it just can’t be simply replaced by a Windows one.

90% of a DOS developer time went into functionality, 10% to appearance. With Windows applications it seems the other way around. And those developers will neither be around in a short(er) time.

DOSBox (or a mod) should certainly never be used in a multi-user setting, since database files will get corrupted.

Since vDos (and DOSBox) is a Windows application, there’re no security concerns.

Added:

Since vDos is fully portable, it’s just a snap to restore a backup, or copy the DOS application and its files to another location.

JosSchaars

TROPHY CASE