|
Post by chris5050 on Apr 23, 2021 11:37:04 GMT 1
I have just downloaded vDos to try it for the first time to see if it will allow me to run my old DOS program under Windows10 64bit.
I get this error illegal descriptor type 0 for int D2 when the program starts up.
I am just asking if you have any more information about what this means, please??
|
|
|
Post by Jos on Apr 23, 2021 12:10:12 GMT 1
Hard to tell, your program is running in protected mode, and the emulated CPU gets hardware interrupt D2. That interrupt is however never generated in vDos. Can you start vDos with the log option (….vDos.exe /log) and submit the generated vDos.log file.
Jos
|
|
|
Post by chris5050 on Apr 23, 2021 13:46:39 GMT 1
Here is the log file:
vDos 2020.03.01 C: => (Local) C:\vDos\
38.68 Execute: xrun5.exe - mainmenu.pgm Int 2f unhandled call 1600 Int 2f unhandled call 1687 Int 1B => 47b:0002 Int 23 => 47b:0013 Int 24 => 199:26ce Int 28 => 47b:002a Int 15 => 47b:002f Int 1C => 47b:0025
|
|
|
Post by Jos on Apr 23, 2021 15:53:39 GMT 1
That doesn’t clarify much. Can you send me (by wetransfer) the XRUN5.EXE file. The program doesn’t access any file before the exception, so that will do.
Jos
|
|
|
Post by chris5050 on Apr 23, 2021 19:18:45 GMT 1
Hi Jos, The exception seems to happen in MainMenu.pgm (a BASIC program I wrote). XRUN5.EXE is the runtime BASIC language.
If I call XRUN5.EXE ACCOUNTS.PGM (a program normally called from MainMenu) then I get a normal error from Accounts: eg File Not Found (since MainMenu has not set up the filenames, etc) But no vDos error for unhandled call.
I will try to find the source code for MainMenu (last used about 15 years ago) and see if I can spot likely causes. From memory I think it could be setting screen colors, calling DOS commands, loading several other programs that each go into a separate 64k area of memory (handled by XRUN5).
If any of those are likely to be illegal under vDos please comment. Otherwise do not worry any further :-) And thank you very much for your support so far.
Chris
|
|
|
Post by Jos on Apr 23, 2021 19:34:54 GMT 1
The exception you get can’t be explained by anything done by your program. Even not by vDos going entirely bogus. The routine handling hardware interrupts and eventually generating that exception is simply never called with interrupt number D2.
Jos
|
|