We are currently testing our reservation software InnSpectre to use with new Windows 10 machines and vDOS. Everything seems to be going fantastic except one one spot. Of course this is a big issue for us. Here is a list of what we are currently doing:
For ease in testing I have copied the vDOS.exe, config.txt and autoexec.txt files to my ISCDemo folder.
I double click on vDos.exe and then type ah.exe at the command prompt.
Press F1 to go to the main menu.
Press F3 to go to the Check-in screen.
If you press the ESC key to exit, you get the message at the bottom of the screen to press ESC again to exit.
When you hit the ESC key the second time vDOS locks up.
You have to use taskmanger to close the window.
It doesn't matter if you check someone in or not. This function appears to be working in the other screens. F3 Check-in is the only one i've found so far that fails.
I have included a OneDrive link below that is the ISCDemo directory we are using for testing. If it doesn't work from there you can copy the files into any local folder and they should work.
Your executables are EXEPACKed, At first I suspected vDos detection scheme of these files, or handling them. That had me going on wild goose chase.
It came down to an exception in handling conditional jumps with 16 bit offsets. For speed vDos maintains a combined CS:IP 32 bit pointer. It added the offset to that pointer, but with 16 bit offsets the CS has to be masked out first; the destination address is wrapped in the CS segment. With the combined CS:IP this can go wrong, resulting in the program jumping to an incorrect address…
Strangely this bug has been around for some time, you are the first with a program using this conditional jump, going wrong. I updated the vDosSetup file, so you can download and test that.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tracking down the origin of such a problem is often like finding a needle in an unstable haystack moving around. Because of user interaction and deviations in the system clock, the moment the problem surfaces is different each run. So first is to stabilize and minimize the haystack; find a good starting point from where there’s at least no user action anymore. Gladly with vDos that is fairly easy; the problem was with the second Esc key. Determine how the program gets that key by logging BIOS Int 16h keyboard calls returning the Esc key. The first one was retrieved by subfunction 11h (Check for key), followed by 10h (Wait for key). The second one by a single 10h; the program just waits for a key. After passing on the second Esc key to the program, let vDos log what instructions are executed by the program, at what address, what register values/flags…
Then do the same with a vDos version (2017.08.01) that hasn’t the problem, and compare both logs. Complication was that both versions had the same mishap/bug, while your program ‘handled’ (that is ignored) the CPU exceptions caused by jumping to/executing non-intentional (bogus) code. One might also think that offending conditional jump would be executed rather prompt after the Esc key is retrieved. It was only after almost 75 thousand (!) instructions. Many deviations in that first pile of instructions like the program getting the system time, triggering background tasks at different moments. So one needs some experience to skip what’s not essential/related and not get lost after a couple of thousand instructions.
Jos
Last edit: Jos Schaars 2018-06-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are currently testing our reservation software InnSpectre to use with new Windows 10 machines and vDOS. Everything seems to be going fantastic except one one spot. Of course this is a big issue for us. Here is a list of what we are currently doing:
For ease in testing I have copied the vDOS.exe, config.txt and autoexec.txt files to my ISCDemo folder.
I double click on vDos.exe and then type ah.exe at the command prompt.
Press F1 to go to the main menu.
Press F3 to go to the Check-in screen.
If you press the ESC key to exit, you get the message at the bottom of the screen to press ESC again to exit.
When you hit the ESC key the second time vDOS locks up.
You have to use taskmanger to close the window.
It doesn't matter if you check someone in or not. This function appears to be working in the other screens. F3 Check-in is the only one i've found so far that fails.
I have included a OneDrive link below that is the ISCDemo directory we are using for testing. If it doesn't work from there you can copy the files into any local folder and they should work.
https://mrwizardusa-my.sharepoint.com/:f:/g/personal/thewizard_mrwizardusa_net/ElbKbdL81TZHtn_Zg9SyqKABL9fqKnScMPUgDiCOIQpH0A?e=M4kEAQ
Thanks for all your help and a great product!
Darrin
That had me going for some while.
Your executables are EXEPACKed, At first I suspected vDos detection scheme of these files, or handling them. That had me going on wild goose chase.
It came down to an exception in handling conditional jumps with 16 bit offsets. For speed vDos maintains a combined CS:IP 32 bit pointer. It added the offset to that pointer, but with 16 bit offsets the CS has to be masked out first; the destination address is wrapped in the CS segment. With the combined CS:IP this can go wrong, resulting in the program jumping to an incorrect address…
Strangely this bug has been around for some time, you are the first with a program using this conditional jump, going wrong. I updated the vDosSetup file, so you can download and test that.
Jos
Jos,
Great detective work!!! The problem is fixed and we are back on track testing.
Tracking down the origin of such a problem is often like finding a needle in an unstable haystack moving around. Because of user interaction and deviations in the system clock, the moment the problem surfaces is different each run. So first is to stabilize and minimize the haystack; find a good starting point from where there’s at least no user action anymore. Gladly with vDos that is fairly easy; the problem was with the second Esc key. Determine how the program gets that key by logging BIOS Int 16h keyboard calls returning the Esc key. The first one was retrieved by subfunction 11h (Check for key), followed by 10h (Wait for key). The second one by a single 10h; the program just waits for a key. After passing on the second Esc key to the program, let vDos log what instructions are executed by the program, at what address, what register values/flags…
Then do the same with a vDos version (2017.08.01) that hasn’t the problem, and compare both logs. Complication was that both versions had the same mishap/bug, while your program ‘handled’ (that is ignored) the CPU exceptions caused by jumping to/executing non-intentional (bogus) code. One might also think that offending conditional jump would be executed rather prompt after the Esc key is retrieved. It was only after almost 75 thousand (!) instructions. Many deviations in that first pile of instructions like the program getting the system time, triggering background tasks at different moments. So one needs some experience to skip what’s not essential/related and not get lost after a couple of thousand instructions.
Jos
Last edit: Jos Schaars 2018-06-01