Control-P, Control-PrScreen bug

[NimbUs]

Hello All ! Old 4DOS user (even formerly, as NDOS !) 1st time
posting in this ng :

For several years using 4DOS 8.0 I've been annoyed with the
/bug/ that when 'Ctrl-P' or 'Ctrl-Prscreen' is pressed while
no DOS printer present or available, 4DOS /locks up/
infinitely querying for Retry/Abort? EVEN after the user
presses the Ctrl-P / Ctrl-PrScreen key combo /again/ (which is
the correct way to go out of the error condition, and works
properly not only in MS-Command.com but /also/, as expected in
/old/ 4DOS versions of JP Software, including NDOS - so
presumbaly this annoying bug was introduced by "Lucho")

- Is this a known 4DOS 8.0 bug, and is there a known
fix/workaround ?
- If none, is somebody taking bug reports and working on 4DOS
nowadays ?

Sorry if all this is no news to most of you. As said I've been
a (mostly happy...) 4DOS user for very many years but not been
following this or other related fora. . There is another,
unrelated bug in 4DOS that i might report if there is interest
: that would be another newsgroup thread.

Best !

[Klaus Meinhard]

Hallo NimbUs,

4DOS support has been dead for years and years.

You'd have to find some fan with programming abiities and lots of
enthusiasm who's willing to take over developement of 4DOS (souce code
available on my 4DOS.info site).

[NimbUs]

Hello Klaus !

Post by Klaus Meinhard
4DOS support has been dead for years and years.
You'd have to find some fan with programming abiities and

lots of

Post by Klaus Meinhard
enthusiasm who's willing to take over developement of 4DOS

(souce code

Post by Klaus Meinhard
available on my 4DOS.info site).

Thank you for keeping the site alive anyway. Pity 4DOS doesn't
have an active maintainer-bug fixers anymore! I guess the bug
I am reporting is to do with 4DOS's critical error aka "int
24h" handler - won't try to examine the source code myself
though, let alone fix it, not being fluent in the 'C'
programming language :=(

[Stan Brown]

Post by Klaus Meinhard
4DOS support has been dead for years and years.

True, but it's worth mentioning that its replacement, TCC, is
available free in the "Lite" edition, TCCLE. I don't know if that
runs in pre-XP versions of Windows, but it's fine with Windows 7 and
8.1.

[NimbUs]

Post by Stan Brown

Post by Klaus Meinhard
4DOS support has been dead for years and years.

True, but it's worth mentioning that its replacement, TCC,

is

Post by Stan Brown
available free in the "Lite" edition, TCCLE. I don't know if

that

Post by Stan Brown
runs in pre-XP versions of Windows, but it's fine with

Windows 7 and

Post by Stan Brown
8.1.

This subject is /not/ to do with "Windows" ! TCC - whether the
full or LE version - couldn't be further from a 4DOS
"replacement". Despite superficial similarities, they are
completely different animals. TCC is a Windows console
program, while 4DOS is a DOS command "shell". Granted, 4DOS
/can/ run in a Windows "DOS box", but conversely TCC cannot
run under DOS.

Best

[CRNG]

Post by Stan Brown

Post by Stan Brown

Post by Klaus Meinhard
4DOS support has been dead for years and years.

True, but it's worth mentioning that its replacement, TCC,

is

Post by Stan Brown
available free in the "Lite" edition, TCCLE. I don't know if

that

Post by Stan Brown
runs in pre-XP versions of Windows, but it's fine with

Windows 7 and

Post by Stan Brown
8.1.

This subject is /not/ to do with "Windows" ! TCC - whether the
full or LE version - couldn't be further from a 4DOS
"replacement". Despite superficial similarities, they are
completely different animals. TCC is a Windows console
program, while 4DOS is a DOS command "shell". Granted, 4DOS
/can/ run in a Windows "DOS box", but conversely TCC cannot
run under DOS.
Best

I welcome discussion of TCC here. As a descendent of 4DOS I consider
it completely appropriate; particularly since we get less that a dozen
posts here in any month.

[NimbUs]

Post by CRNG

Post by NimbUs

Post by Stan Brown
True, but it's worth mentioning that its replacement, TCC,

is

Post by Stan Brown
available free in the "Lite" edition, TCCLE. 8.1.

This subject is /not/ to do with "Windows" ! TCC - whether

the

Post by CRNG

Post by NimbUs
full or LE version

I welcome discussion of TCC here. As a descendent of 4DOS I

consider

Post by CRNG
it completely appropriate; particularly since we get less

that a dozen

Post by CRNG
posts here in any month.

Certainly Sir, BUT utterly irrelevant to this thread and the
question in its OP, which is about a presumed bug in 4DOS
under PCDOS or compatible DOS, not TCC nor Windows.

Best

[Klaus Meinhard]

Hallo NimbUs,

Certainly Sir, BUT utterly irrelevant to this thread and the question
in its OP, which is about a presumed bug in 4DOS under PCDOS or
compatible DOS, not TCC nor Windows.

If you insist on using or playing around with an OS from the last
century, you'll have to get used to the frustration that practically all
programs running under any version of DOS are no longer supported. So
you'll have to live with any bugs you encounter.

Regarding your bug, have you tried a CTRL-C to get out of the loop? It
helps in many similar conditions, but of course not all.

[NimbUs]

Post by Klaus Meinhard
Regarding your bug, have you tried a CTRL-C to get out of

the loop? It

Post by Klaus Meinhard
helps in many similar conditions, but of course not all.

Of course I think I tried averything, and then some; nothing
helps except control+alt+DEL :=) The bug is present even when
4DOS is instructed to get commands line-by-line just as
"command.com" does ( setdos /L1 ). Once 4DOS's internal
printer flag has been set, ANY input character is sent to the
DOS printer driver (in addition to the standard output), so
DOS will return an error and 4DOS in turn beep at the user.
The programmer just forgot to special case Ctrl+P (or
Ctrl+Prscreen) as toggle keys for the "printing" state.

Regards

[NimbUs]

Post by NimbUs
For several years using 4DOS 8.0 I've been annoyed with the
/bug/ that when 'Ctrl-P' or 'Ctrl-Prscreen' is pressed while
no DOS printer present or available, 4DOS /locks up/
infinitely querying for Retry/Abort? EVEN after the user
presses the Ctrl-P / Ctrl-PrScreen key combo /again/

(...)

Post by NimbUs
presumbaly this annoying bug was introduced by "Lucho")

I have been misattributing, take this back with *apologies* to
"Lucho". The bug is /already/ in 4DOS 7.50 by "JP Software",
and possibly earlier. It definitely is *not* buggy in NDOS 5.0
(Norton utilities 6.01) a licensed version of 4DOS which was
my DOS command replacement of choice for many, many years...
It would be interesting to test archived versions of 4DOS.COM
and see at which point back in time this bug slipped in !
To replicate, running 4DOS (under DOS, on real iron, having at
least one parallel port registered with the BIOS and NO
printer attached), at the 4DOS prompt : type "Ctrl P" to
toggle the printer, then type the "any" key; 4DOS would try to
send the key to the PRN device and upon failure, query for
Retry Ignore Fail Abort?
At this point, the lonly way out beyond connecting an actual
printer device should be to toggle "Ctrl P" back. Then typing
"any" character should proceed smoothly, however IF the bug in
subj is present in the 4DOS version under test, you'll get the
"Write error on device PRN" Retry Ignore Fail Abort? again,
and again and again... no way out but by rebooting the machine
:(

[John R. Sowden]

You might consider fining in the documented c code where the trap for
Ctrl-p is, and where it goes. Thenwrite yoursel a simple
function/procedure that does noting, just returns. That will make
Ctrl-P not work, but also no lock up the computer.

Of course, a better solution would be to go inside the existing
procedure and add an if statement, test the printer, continue if it
passes, then "else" return is not, possibly with a beep and a "printer
not ready" message.

John

Post by NimbUs

Post by NimbUs
For several years using 4DOS 8.0 I've been annoyed with the
/bug/ that when 'Ctrl-P' or 'Ctrl-Prscreen' is pressed while
no DOS printer present or available, 4DOS /locks up/
infinitely querying for Retry/Abort? EVEN after the user
presses the Ctrl-P / Ctrl-PrScreen key combo /again/

(...)

Post by NimbUs
presumbaly this annoying bug was introduced by "Lucho")

I have been misattributing, take this back with *apologies* to
"Lucho". The bug is /already/ in 4DOS 7.50 by "JP Software",
and possibly earlier. It definitely is *not* buggy in NDOS 5.0
(Norton utilities 6.01) a licensed version of 4DOS which was
my DOS command replacement of choice for many, many years...
It would be interesting to test archived versions of 4DOS.COM
and see at which point back in time this bug slipped in !
To replicate, running 4DOS (under DOS, on real iron, having at
least one parallel port registered with the BIOS and NO
printer attached), at the 4DOS prompt : type "Ctrl P" to
toggle the printer, then type the "any" key; 4DOS would try to
send the key to the PRN device and upon failure, query for
Retry Ignore Fail Abort?
At this point, the lonly way out beyond connecting an actual
printer device should be to toggle "Ctrl P" back. Then typing
"any" character should proceed smoothly, however IF the bug in
subj is present in the 4DOS version under test, you'll get the
"Write error on device PRN" Retry Ignore Fail Abort? again,
and again and again... no way out but by rebooting the machine
:(

[Johann 'Myrkraverk' Oskarsson]

Post by NimbUs
For several years using 4DOS 8.0 I've been annoyed with the
/bug/ that when 'Ctrl-P' or 'Ctrl-Prscreen' is pressed while
no DOS printer present or available, 4DOS /locks up/
infinitely querying for Retry/Abort? EVEN after the user
presses the Ctrl-P / Ctrl-PrScreen key combo /again/

(...)

Post by NimbUs
presumbaly this annoying bug was introduced by "Lucho")

It's a late reply, I know. Is this still a problem? Is it
reproducible in virtual environments? If I can reproduce it,
I might be convinced to fix it. I don't need extra money,
so any said fix will be applied "when I feel like it."

Alternative to reproduction, is to make ctrl+p a no-op.

It's ok to email me about 4DOS, though replies here should
be sufficient.

[NimbUs]

Johann 'Myrkraverk' Oskarsson dit dans news:so13C.115778$q_1.73258

Post by Johann 'Myrkraverk' Oskarsson

Post by NimbUs
For several years using 4DOS 8.0 I've been annoyed with the
/bug/ that when 'Ctrl-P' or 'Ctrl-Prscreen' is pressed while
no DOS printer present or available, 4DOS /locks up/
infinitely querying for Retry/Abort? EVEN after the user
presses the Ctrl-P / Ctrl-PrScreen key combo /again/

(...)

It's a late reply, I know. Is this still a problem? Is it
reproducible in virtual environments? If I can reproduce it,
I might be convinced to fix it. I don't need extra money,
so any said fix will be applied "when I feel like it."

Hello, and happy new year, Johann !

It's never too late for a good deed. As for the bug in subj, it is
certainly reproducible in a proper virtual environment since it is
without any doubt a coding error. It's been a few months since I
looked so a bit fuzzy in my memory but, examination of the 4DOS 8
source for the critical error module will show 2 code paths : one
old, commented out - that is the original JPsoft and it DOES work OK
in older 4DOSes - and a new one, which unfortunately has the bug. The
/old code/ used the BIOS interrupt to query the keyboard during the
abort/retry... sequence, while the /new code/ uses the DOS -
presumably the intent was to correctly process cancellation sequences
in the event that DOS "console" I/O had been redirected. However that
"improvement" was probably not fully tested in the described
situation . As coded, "Contrl-P" entry is not singled-out (or
control-print screen) when they should be, to avoid infinte looping.

Post by Johann 'Myrkraverk' Oskarsson
Alternative to reproduction, is to make ctrl+p a no-op.

Easy indeed ! But that's "cheating"...

Post by Johann 'Myrkraverk' Oskarsson
It's ok to email me about 4DOS, though replies here should
be sufficient.

Thank you for the interest you have shown in this and of course,
please, let us know if a fix is coming !

ISTM the easiest way out would be reverting to the old, time proven,
code utilising the BIOS. It would be "as easy as" recompiling,
assuming, from your post, that you are familiar with rebuilding 4DOS
from source (though I personnally have no idea how painful it might
be). A more correct approach, i.e. fixing the /new/ code, may or may
not be time consuming. In either case I'm willing to contribute by
test and trying at home...

Regards