Nothing, this doesn't work.

Great. Is there any kind of workaround for the problem?

I'm not sure how exactly qbasic checks for ctrl-break, but you could
try to write a TSR that calls int1b (or what it was) on some key
combination.

I have no ideea how to do that, anyways I tried mapping break to printscreen and took away printscreen's mapped key and although printscreen DID work as a pause key, ctrl+printscreen didn't work. Then I tried mapping ctrl AND break to printscreen, again it was a no go.

Ctrl-break checks are woven into the dos in/out system, and as dosbox
is missing those checks (and i don't see any easy way how to add them)
it doesn't work no matter how you remap keys.
You could try booting msdos or freedos inside dosbox.

I thought DosBox emulated DOS in the first place...? Eh, whatever. I am obviously overcome by this issue due to lack of knowledge. Could you please tell me how I boot MS-DOS inside DosBox?

Well it does emulate DOS, but not perfectly (yet enough for most games).
Maybe Sample usage of a harddisc image in DOSBOX
is a nice start, not sure if it's outdated.

wd wrote:

Ctrl-break checks are woven into the dos in/out system, and as dosbox is missing those checks (and i don't see any easy way how […]
Show full quote

Ctrl-break checks are woven into the dos in/out system, and as dosbox
is missing those checks (and i don't see any easy way how to add them)
it doesn't work no matter how you remap keys.
You could try booting msdos or freedos inside dosbox.

It shouldn't be too difficult to add? INT9 should cal INT1B, and various DOS input (and output?) functions should check the Ctrl-C flag and call INT23. I haven't checked in detail, but can't be that hard... (No, I do not have time to add it myself 😀). Perhaps QBasic and others intercept the 1B directly instead of the 23, making it even easier.

JAL

Well there's a lot more around it than "just checking on dos in/out functions".
If you need it, boot dos.

> Perhaps QBasic and others intercept the 1B directly instead of the 23,
> making it even easier.

Well then -> TSR

wd wrote:

Well there's a lot more around it than "just checking on dos in/out functions".
If you need it, boot dos.

Sure, why not make DOSbox a PC emulator, and make booting DOS obligatory for it to work, even easier! 😀 Really wd, lighten up a bit, it's not a personal assault on you every time someone suggest supporting something in DOSbox that's not in there yet.

JAL

So...what??

wd wrote:

So...what??

<g> We all love you dude, really! 😀

JAL

I don't mind quitting it. Where it might be quite much.

The following will need to be done to get ctl-break to work:

rewrite mapper to handle ctrl-break, it currently banishes the combination to dev/null
with mapper passing ctrl-break, keyboard.cpp puts the break sequence(e0h 46h e0h c6h) into the kb buffer
add 1bh handler to bios.cpp; 1bh simply inserts ctrl-c into the kb buffer
add 23h handler to dos.cpp; 23h terminates the current running program/batch file(more or less just copy int 20 handler)
init 1bh & 23h vectors(at 000:006ch & psp offset 0eh)
wherever bios checking occurs, on seeing ctrl-break sequence, sets 40:0071h bit7, calls 1bh
wherever dos kb checking occurs, on seeing ctrl-c sequence, calls 23h

ih8registrations wrote:

The following will need to be done to get ctl-break to work:

This seems like a manageable task. Maybe someone can pick it up. This raises an interesting (and perhaps often asked) question: couldn't we have a list of these 'todo' tasks on the DOSbox developers page, so that someone willing to devote some time could pick it up?

JAL

The reason you won't see such lists too often is because it's the harder part; figuring out how it should work, where the changes need to be made, and the current state. The coding in this instance is rather easy. The sticking point is I don't like the mapper code. I'd scrap it before spending any time patching it, but since I don't see the current mapper being dropped anytime soon, here's an outline instead so someone else can do it. Outside of the mapper, the only fuzzy part of the outline I gave is the "whereever x checking occurs" bits which is me responding to the thread before deciding where I'd put them. That and it's more of a code cleanliness issue, 1bh could just as well be called from keyboard.cpp.

Sorry people, but the advanced terms you're all using here are beyond me. I don't even know what "rewrite the mapper" means and what to do with keyboard.cpp. Could you explain in a more... formal language?

mapper = an internal part of DOSBox that makes it possible to use say a German keyboard with programs written by naive Americans that wrongly assume that every keyboard is laid out like an American keyboard. The mapper maps/connects the real keys to the keycodes that the Americans expect. Rewriting means modifying the program code that does the remapping.

keyboard.cpp = Another part of the internal DOSBox code. The .cpp tells me that this code is written in C-Plus-Plus.

MiniMax wrote:

... with programs written by naive Americans that wrongly assume that every keyboard is laid out like an American keyboard. ...

Whoa 🤣
Just to be fair, I've seen this in some German and French programs too. It's especially annoying when the French layout is assumed, because the positions of the keys are very different from the other layouts (AZERTY).