Ctrl-Break

[oneillph]

My old DOS program (Javelin) was written to receive and act on Ctrl-Break under certain circumstances.  When I hit Ctrl-Break, nothing happens.  Suggestions?

(From what I can tell, my keyboard is issuing Hex 46 as expected.)  (Search terms: Ctrl Break)

Thank you, Patrick

[Jos]

I’m afraid Javelin hooks into the DOS Control-C/Control-Break handler, interrupt 23.
On keyboard input, DOS will call this interrupt the moment Ctrl-Break is entered. vDos however won’t, would be rather complicated to fully implement, while virtually no program uses DOS keyboard input. If I recall correctly, only the MS Link program and probably some other command line utilities do.

You could start vDos with the log option (….vDos.exe /log), and see if the generated vDos.log file contains a line: Int 23 => XXXX:XXXX.

Don't know, but maybe DOSBox implements interrupt 23?

Jos

[oneillph]

Thank you very much for your quick response. I will start vdos with /log to see. I assume I will have to hit ctrl-break while Javelin is running - is that Correct?

Otherwise vdos is great! I tried dosbox, but it didn't work nearly as well.

[Jos]

You only have to start Javelin, no actual Ctrl-Break required.
That eventual Int 23 => XXXX:XXXX line indicates Javelin expects Int 23 to be called if Ctrl_Break is used, what vDos doesn’t do.

Jos

[oneillph]

The log file has this line:
Int 23 => 3432:24fa

[Jos]

So Javelin does indeed hook into Int 23, to execute some code of its own if Crtl-Break is pressed in a DOS ‘get keyboard input’ function.

As mentioned, virtually no DOS program uses this far too basic DOS ‘get keyboard input’. So sorry, but it ends for Javelin under vDos.

Jos

[oneillph]

Thanks! This is not a show-stopper for me. I would only need to use ctrl-break to break out of a running macro when I attempt to enter an invalid value in a field. So if I am careful, this rarely occurs. I will be careful, and continue to use Javelin and vDos. Thank you for your help.

[zy]

Aug 14, 2020 21:48:46 GMT 1 Jos said:

As mentioned, virtually no DOS program uses this far too basic DOS ‘get keyboard input’. So sorry, but it ends for Javelin under vDos.

Jos

The Clarion 2.1 Professional Developer (CPD 2.1, written in the late 1980s) uses Ctrl-Break when the processor is running a compiled Clarion 2.1 program (.pro) to open the Clarion debugger window. So I think it is inaccurate to say that "virtually no DOS program uses this." Clarion 2.1 was very popular in the 90s. I wrote full industrial system in Clarion 2.1 back in those days. My client has been using this software to run his Mill for over 30 years. He stull uses it today and has no intentions of rewriting or switching to canned software to handle his custom needs. I have been trying (with no luck so far) to get the full CPD 2.1 environment (including the Ctrl-Break function in the processor that starts the debug module) in the following environments: vDosPlus and DOSBox-X. When Ctrl-Break is pressed when the processor is running in either of those emulators, nothing happens. I assume this is a problem similar to the one reported by the OP in this thread. You said to him, "So sorry, but it ends for Javelin under vDos." Did you mean that function will never be implemented in vDos and that Javelin users should use a different DOS emulator? Does it also mean that the CPD 2.1 will never fully run in vDos and that I should also look elsewhere to be able to run it?

We do just fine with VMWare on my client's virtual Windows Server 2003 machine, and I support it using Oracle's VM VirtualBox, but both of these environments run slower than molasses in January. They also eat up tremendous resources and take forever to boot up. My client was hoping to migrate his software (and my CPD 2.1 development environment) to something faster. That's why I've been looking for a DOS emulator that starts up in seconds and simply runs the DOS programs.

If vDos will never support this functionality, it is doubtful that vDosPlus ever will, as it is (apparently) an almost dead project. I have posted a request that DOSBox-X enable this Ctrl-Break. That emulator is very actively supported, but I don't know if or when the request will ever implemented. If vDos will never support this feature (and vDosPlus and DOSBox-X possibly won't either), do you have any suggestions of other DOS emulators I haven't tested yet that might handle this?

I have gotten his system running and mostly tested in the Clarion 2.1 runtime under vDosPlus (which is very fast) and DOSBox-X (which is 5 to 10 times slower). So we might be able to use either of those, and possible even vDos, as long as I don't use the Clarion 2.1 debugger in the emulator. I suppose, worst case scenario, I can continue to run Oracle VM VirtualBox running a virtual Windows 7 running it's virtual XPMode - a virtual within a virtual within a virtual, which is probably why it is so slow, using this setup to debug changes to his programs I'm still supporting as well as new programs my client is always asking me to develop in Clarion 2.1.

Do you have any advice or possible good news for me?

Thanks in advance,
Zy

[Jos]

Well, I could have said "virtually no DOS end-user program uses this.". And vDos is primary meant for running end-user programs. That excludes programming tools, one should then temporary use a virtual DOS machine if Ctrl-Break is needed?

I don’t know of other DOS emulators than DOSBox and mods that would be able to run Clarion. Perhaps a virtual FreeDOS would be an option, though that would give you a rather isolated environment. And no idea if for instance printing is a practical feature.

With correct settings, DOSBox (don’t know about DOSBox-X) should be able to run faster than vDosPlus (https://www.youtube.com/watch?v=wSo7hYFHA7g).

If you don’t get a response/solution from the DOSBox-X team, get back in a week or so.
I could eventually add a rather simple:
Set the BIOS break flag when appropriate.
Starting a DOS function, check if this flag is set. If so and Int 23 is hooked/replaced, start that routine.
If it returns AL=0 end the DOS program, else continue with the DOS function (http://www.ctyme.com/intr/rb-4110.htm).

Though no idea if this will actually work/suffice. There could be pitfalls like DOS not running in the virtual machine.

Jos

[zy]

Oct 14, 2020 14:55:58 GMT 1 Jos said:

With correct settings, DOSBox (don’t know about DOSBox-X) should be able to run faster than vDosPlus

If you don’t get a response/solution from the DOSBox-X team, get back in a week or so.

Hello Jos,



Thank you very much for your swift reply. I really appreciate it. If you don't mind, I'm going to link Wengier to your reply above. Perhaps it will give him some ideas. He was the primary developer of vDosPlus (a basically dormant project) and is now working exclusively with the DOSBox-X team. He usually answers issue posts within 24 hours. I am privileged to have such excellent support from both of you.

I am most intrigued with the possibility of DOSBox-X running faster than vDosPlus with the right settings. I would be happy to use DOSBox-X over vDosPlus, if we could get the speed out of it that would make my long time client happy. And also because DOSBox-X is Wengier's current project and focus.

I'll post again here if needed.

Thanks again, Jos.

~ Zy 

[Jos]

Fine by me.

Jos

[Jos]

A warning if your program is used in a multi-user setting: DOSBox (and mods) will in time corrupt database files (https://www.vdos.info/faqs.html - SHARE - Record locking (RL) by multi-user applications).
If data is corrupted, you can only hope it’s ‘noticed’ early on by your program (mostly breaking down), so there’s a recent backup to fallback to.

Essentially there’s no way you can test this, or prevent by whatever DOS program code. It’s a matter of time and how frequent data is modified.
You should at least verify the DOSBox-X team recognizes this problem. If so, if it is solved.

Jos

[Wengier]

Jos: Yes, I can confirm DOSBox-X does have code implementing record locking, even though the code is apparently Windows only but independent from the RL code in vDos/vDosPlus. Unlike (original) DOSBox and most other forks which focuses on DOS gaming, DOSBox-X is designed to go way beyond DOS gaming (so it covers things like DOS applications, Windows 3.x/9x etc), and the record locking is indeed implemented, although not by me.

[Jos]

Just implementing record locking (RL) won’t do it for DOSBox mods:

“…Some DOSBox mods 'support' RL, but turn out to be a disaster. Besides exclusive access, the internal program data has to match what’s actually on disk that moment. DOSBox (mods) caches disk operations, possibly outdated data lurking all around (the network). One DOSBox mod ‘solution’ first updates the caches with RL. That doesn’t do it either: Local caches at other PC’s will still destroy the delicate database structures. Especially indexes are vulnerable due to the very compact and structured organization.”

Jos

[Wengier]

Jos: Disk caching in DOSBox-X is completely optional (unlike DOSBox). With the setting nocachedir=true DOSBox-X will not cache disk operations at all. And the record locking code has apparently been around in DOSBox-X for some time.

By the way, DOSBox-X is not just another DOSBox mod as its goal is very different. It is of course based on DOSBox, but both vDos and DOSBox-X are derived from DOSBox.