4DOS 7.5 Ctrl-P BUG :=)

Jul 2, 2017
4
0
#1
Hello everybody ! I'm aware 4DOS is no longer developed, can we still discuss a bug/regression (it was not present in old 4DOS versions, including Norton licensed NDOS; but is present is the newest 4DOS 7.50 and its "freed" successor 8.0,) and ask if the bug was discussed earlier, if there is a known fix or workaround ?

The bug is when using "Ctrl-P" (or Ctrl-"Prtcreen" ) at the 4DOS command line; il there is an error (such as NO printer attached...) it is IMPOSSIBLE to escape the perpetual asking for "Retry ? Abort ?" prompts, except by "Ctrl-Alt-Del" or reset...

The normal escape from this infernal loop is by the user typing "Ctrl-P" again (to toggle the 'echoing to PRN' status) then answering 'A' for abort.

It works OK when using MS-Command.com (or, indeed, old 4DOS versions) but NOT with current versions (JPSoft's or "free") - the "Ctrl-P" which should toggle the invalid "printing" status" does NOT toggle, instead it is swallowed like any other character and sent to the (not existing or in error) printer !!! :=(

I'll note that the "SETDOS /Lx" state has no effect on the reported bug.

Apologies if 4DOS is off-topic on this forum (I assumed everything is ON-topic on THIS subforum at least...) and thanks in advance to anybody willing to help with, or discuss this sorry matter.
 
#2
You may want to ask your question in the discussion section of the vDOS site.

4DOS is the command processor for vDOS.

Although, I just tried Ctrl-P under vDOS (4DOS), and do not get an error message, probably because 4DOS has been modified for vDOS.

If you are comfortable doing so, you could download the 4DOS source code, and make modifications yourself to solve your Ctrl-P issue.

Joe
 
Jul 2, 2017
4
0
#3
Hi, Joe Caverly, sir ! Thanks for caring...

> 4DOS is the command processor for vDOS.
> Although, I just tried Ctrl-P under vDOS (4DOS), and do not get an error message, probably because 4DOS has been modified for vDOS.

Well, no, I don't think so : it is because vDOS is NOT DOS. It's a Windows (64 bit only, even) program, I'm talking about using 4DOS on real "iron", under (real mode) DOS (MS-DOS, PC-DOS, DRDOS or compatible...). ...

> If you are comfortable doing so, you could download the 4DOS source code, and make modifications > yourself to solve your Ctrl-P issue.

It's not this user's "problem", it's 4DOS serious "bug", and regression ! Perhaps in its "critical error" (aka "int 24h") handler. Clearly, testing missed it while the program was in active development :=( I'm certainly not going to "solve" it myself, though I could "work around" it in certain ways. Is there absolutely no chance the program's vendor would pride himself of issuing a patch for this issue ? Who better than him could quick-fix this, as this is a regression from older versions, so he could certainly identify the probem by comparing sources ?

Otherwise, do you all know whether the authorised developper of newer versions of 4DOS for FreeDOS ("Lucho") could be contacted thru the internet and how ?
 
Jul 2, 2017
4
0
#5
...there was a utility package for 4DOS called InkUtils.
It has a utility called "Critical Error" that may or may not help your Ctrl-P issue.
Joe
Thanks again. That may help (or, indeed, it may not) with the (not mine) Ctrl-P/Ctrl-PrScreen issue. The satisfactory workaround I have been using is one of professor Salmo gathered "Garbo" set of freeware/shareware DOS utilities, viz; "VPRINT.COM" - a TSR that hooks all (DOS/BIOS) accesses to the PRN, redirecting character output to a disk file. [There are several similar utilities out there,] VPRINT is good - and indeed with VPRINT loaded and active, control-P does not lock the computer any more :=)

Any idea how to contact Luczezar Georgiev (Lucho) ?
 
Jul 2, 2017
4
0
#7
Looking back through PC Magazine articles, I found an article on how to create the program NOPRINT.COM
Yep, that would work (with caveat it's for an old style PC/XT keyboard controller, not fully correct for a modern PCAT/MF2 type. It should work as is, in practice.Edit: assuming an ATcompatible-BIOS, I would rather intercept int 15/4F of course) This said I like to have VPrint resident anyway (I keep it in the UMBs) so I can "print" to a file from almost any DOS program, as well as from the command line....
 
Last edited: