Clarion Professional Developer 2.1 needs Ctrl-Break passed to the executing program in order to open the Clarion debugger.

[zydanielson]

I'm writing this up as a Feature Request. As I'm new to DOSBox-X, I really don't know if this is a bug or not. Perhaps a moderator can decide.

The Clarion Professional Developer 2.1 is a suite of exes that looks like this:

When you highlight "Editor" and press Enter, it runs cedt.exe. Esc is used to exit the editor, which returns you to the developer suite above. "Compiler" runs ccmp.exe, etc. The process of developing a Clarion 2.1 program is to use the Editor to create a source file with extension ".cla". Then you use the Compiler, which creates a compiled version with extension ".pro" - also called a processor file. Then you use the Processor (cpro.exe) to test and debug the program. Here is the main menu of my client's system, written in "master.cla" and compiled to "master.pro":

Running the Clarion 2.1 Processor inside VMware or Oracle VirtualBox, when I click Ctrl-Break, I get: The debug module has opened up on top the running "master.pro" allowing me to examine variables, trace, step through a line of code at a time, set breaks, etc. Also, as you can see above, the debugger says "Stopped for: Ctrl-Break". This indicates that both VMware and VirtualBox are sending a true Ctrl-Break to the Clarion processor module, opening the debugger.

An Explanation of a Menu Standard in Clarion Professional Developer 2.1 When a menu such as "master.pro" above is executing (in any DOS environment), pressing the first letter of a menu item is designed to move the highlight to that menu item. In the "master.pro" menu you'll notice there are two items beginning with "C". These are "Clients" and "Cloth". Pressing C on the keyboard moves the highlight selection back and forth between these two options. This works as desired using DOSBox-X.

The Problem When I run "master.pro" in cpro.exe inside DOSBox-X, pressing Ctrl-Break does not open the Clarion debug module as it does in other virtual DOS environments such as VMware and Oracle VirtualBox .

What I Suspect Might Be Happening I tried pressing Ctrl-C to see if that would produce the hoped-for Ctrl-Break behavior. But Ctrl-C seems to send a "c" to the Clarion Processor, causing the highlighted menu selection to move back and forth between "Clients" and "Cloth" just as before. This gives me the impression that DOSBox-X does not pass a true Ctrl-Break or Ctrl-C to the executing Clarion Processor.

The Desired Behavior I don't need Ctrl-C to work, but I do need Ctrl-Break to work so that the Clarion Processor will open the Clarion Debugger. There is a runtime environment (crun.exe) that runs the Clarion 2.1 programs without the overhead of the Clarion 2.1 debugger. In my testing so far, this works fine with DOSBox-X. But my client (to this day) asks for modifications and new additions to his Clarion 2.1 system. Without the capability of sending Ctrl-Break to the Clarion Processor (cpro.exe), I am unable to develop and test new programs, or to debug programs already written. If DOSBox-X was not designed to send a true Ctrl-Break to the program executing inside it, then this is a Feature Request. If it should be capable of doing this, I haven't found out how to accomplish it, meaning it might be a Bug.

VMware and Oracle VirtualBox work fine in both the runtime and the processer/debugger. My whole reason for turning to DOSBox-X was for speed. When running in those other virtual environments, we are running a virtual Windows 7 with XPMode inside that: a virtual within a virtual within a virtual. It is slow as molasses in January. I sure would love to be able to set aside that environment and develop and run Clarion 2.1 programs in DOSBox-X alone.

I look forward to hearing your comments and responses.

Thank you, Zy Danielson

[Wengier]

@zydanielson Great! Please feel free to let us know if you have any issues or suggestions. Thanks!

[joncampbell123]

Okay...

Apparently DOSBox-X injecting 0x0000 into the keyboard buffer is exactly what Compaq systems do with CTRL+BREAK.

But the question is... what do actual IBM systems do? That after all is canonical to the IBM PC platform.

Digging out the PS/2 model 30 to test.

Top section is me typing CTRL+C and the bottom section is me typing CTRL+BREAK.

[joncampbell123]

Toshiba laptops do the same thing too, apparently.

[Wengier]

Interesting - there are indeed different types of PC systems running DOS which may sometimes have different behaviors. Sure, they can be checked out. I think users like @sikthehedgehog may want to help testing too.

[joncampbell123]

PS/2 model 30 testing is delayed because the 1.44MB drive seems to have lost the ability to read floppies. This system also has a dead RTC, which means it normally throws 161 and 163 errors and the boot disk has to have a special signature to fool the BIOS into thinking it's a diagnostic disk. However if you prod it into booting with F1, it will boot from CF if you put in an XT-IDE-CF card. So having borrowed the card from my Tandy, I will begin testing.

[joncampbell123]

Yup, even on the PS/2 model 30, the BIOS returns 0x0000 from INT 16h when you hit CTRL+BREAK.

[joncampbell123]

Actually there's one crucial detail I forgot to check:

INT 16h AH=0h/AH=10h returns 0x0000 on CTRL+BREAK, but that's probably because that INT 16h call has no way to indicate that there's no keystroke but that it must return because of CTRL+BREAK?

I need to check what INT 16h AH=1h/AH=11h returns on CTRL+BREAK. Does it indicate that a keystroke is available (for AH=00h to return 0x0000) or does it indicate there is no keystroke whatsoever?

I also wonder if the BIOS data area flag (40:71) bit 7 is checked by INT 16h and cleared by AH=0h.

If it works the way I think, CTRL+BREAK should not add anything to the keyboard buffer, and the 0x0000 value is purely made up by INT 16h when the BIOS break flag is set while it's waiting for a keystroke.

I also verified just to be sure that INT 18h on PC-98 returns nothing whatsoever (nothing added to keyboard buffer) for the STOP key, but that it functions just like CTRL+BREAK.

[Wengier]

Yes, we are trying to continue to improve the quality of the new feature even after it works.

By checking out the actual DOS behaviors in different types of PCs and eventually implement them in the code with a machine setting or so, DOSBox-X will become more flexible and users can select a machine type they want to emulate and then have the feeling that they are running a real DOS system with such PC configuration. Thanks for all the work!

[joncampbell123]

Haven't checked yet, but the FreeDOS EDIT.COM built into drive Z: seems to handle INT 16h AH=11h in a manner that suggests I'm right.

I noticed if INT 16h AH=11h returns scan code AX=0, whether or not ZF is set or clear, EDIT.COM doesn't go on to fetch the scan code. The result of course was that once CTRL+BREAK was hit, any further keyboard input was ignored.

Which is why INT 16h emulation as currently committed was written to silently eat the 0x0000 scan code when polled.

[zydanielson]

I reopened the issue, since you are still working it.

You guys are awesome.

[joncampbell123]

Uh, nope. INT 16h returns the 0x0000 CTRL+BREAK scan code the same as any other. So AH=11h/AH=01h will signal a scan code present.

Which means if you use EDIT.COM from FreeDOS, you should not hit CTRL+BREAK unless you want to lose the ability to type anything.

So DOSBox-X is doing everything right except for the silent eating of the 0x0000 scancode on INT 16h AH=11h/AH=01h.

The only other change is that DOS CON device emulation needs to poll using INT 16h AH=11h and read using AH=10h like MS-DOS does. But that should not be listed here because that's not specific to CTRL+BREAK handling.