This seems like an odd issue to me but I'm hoping I'm just missing something simple. I am running an old 16-bit ms-dos inventory program in vDos and most of my testing has worked well but some of the modules, each inside their own EXE that are all called by the main program when needed, have the numbers entered into them off by one. For example, putting a "1" in on the affected modules menu screens causes the program to report that you can't eneter a "0" as an option, and putting any other number between 2 and 22 (the last option) will call the menu item 1 less than (2 calls 1, 3 calls 2, etc.). Within the modules that have this issue it is not limited to just the menu. Searching for line number are also off by 1 in the same way (searching for line number 10 will actually find line number 9).
It does not appear to be a keyboard/input issue as the correct number is being displayed before Enter is pressed and even using the default menu selection takes you to the item one less (for example: It defaults to menu item 22, which is "Exit", and just pressing Enter without inputting a number over the 22 will take you to menu item 21 instead).
This is only an issue in about 1/3 of the modules (which are all the newer modules). They all run correctly in NTVDM on 32-bit Windows even using the same installation (but have different issues there that we are hoping vDos will solve).
Any ideas/input would be greatly appreciated!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By change, I got yesterday something similar reported:
Using the vDos FPU to do integer calculations, the result is sometimes 1 off:
2+2 (9 significant positions) -> 4
2+2 (8 ,,) -> 3 !!!
Maybe your program is doing something simular: menu item number + menu page offset = 22+0 -> 21. At least -0 + 4 was reported to produce 3 (at 4 positions).
It seems not logical to use the FPU for integer (non-floating point) calculations, certainly not for small numbers. But this should of course still be correct. Didn’t yet come to investigating that.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This seems like an odd issue to me but I'm hoping I'm just missing something simple. I am running an old 16-bit ms-dos inventory program in vDos and most of my testing has worked well but some of the modules, each inside their own EXE that are all called by the main program when needed, have the numbers entered into them off by one. For example, putting a "1" in on the affected modules menu screens causes the program to report that you can't eneter a "0" as an option, and putting any other number between 2 and 22 (the last option) will call the menu item 1 less than (2 calls 1, 3 calls 2, etc.). Within the modules that have this issue it is not limited to just the menu. Searching for line number are also off by 1 in the same way (searching for line number 10 will actually find line number 9).
It does not appear to be a keyboard/input issue as the correct number is being displayed before Enter is pressed and even using the default menu selection takes you to the item one less (for example: It defaults to menu item 22, which is "Exit", and just pressing Enter without inputting a number over the 22 will take you to menu item 21 instead).
This is only an issue in about 1/3 of the modules (which are all the newer modules). They all run correctly in NTVDM on 32-bit Windows even using the same installation (but have different issues there that we are hoping vDos will solve).
Any ideas/input would be greatly appreciated!
By change, I got yesterday something similar reported:
Using the vDos FPU to do integer calculations, the result is sometimes 1 off:
2+2 (9 significant positions) -> 4
2+2 (8 ,,) -> 3 !!!
Maybe your program is doing something simular: menu item number + menu page offset = 22+0 -> 21. At least -0 + 4 was reported to produce 3 (at 4 positions).
It seems not logical to use the FPU for integer (non-floating point) calculations, certainly not for small numbers. But this should of course still be correct. Didn’t yet come to investigating that.
Jos