Trying to test an app starts but cannot select menu items

[stepgr]

Hi guys,

we have an old (cobol probably) app that up until XP we could use in our machines fullscreen
also.  After windows 7 we could only run in a window and now with windows 10  cannot longer use
it at all. I was trying to see if it will be possible to work with it  but seems that after the initial 
startup of the application although it doesn't stop working I can't select with the keyboard the options
that are available on screen . The application works you can select some items  and you can exit 
normaly . I dont know if any print screens wil help you guys give a clue as to what is going on . 

In order for the app to work we had to modify the following in config.nt : 


device=%SystemRoot%\system32\ansi.sys  
(it works fine in vdos no need to load ansi.sys as it seems) .

and in autoexec.nt  we were loading a kb driver only

thanks for any hint/help

George

[Jos]

Could be the app uses INT 9 to communicate with the keyboard. vDos doesn’t emulate that low level interface.
To make sure, you could start vDos with the log option (….vDos.exe /log). If that contains a line Int 9 => XXXX:XXXX, the app indeed hooks into Int 9 and it ends for vDos.

Jos

[stepgr]

Thank you Jos,

the funny thing is that is not completely unresponsive , some areas of the screen 
seems to be out of reach. Where will I find this log file in ?

George

[Jos]

That file is named vDos.log and created in the directory of vDos.

Jos

[stepgr]

OK I did that here is a portion of it :

vDos 2020.03.01
C: => (Local) C:\vDos\
J: => (Remote) \\debgp\shared\

0.09 Execute: run.EXE - main00 a k l=y2k_1.lib l=y2k_2.lib
Int 24 => 3ca:0539
Int 2f unhandled call 1600
Int 15 unhandled call 1022
Int 2f unhandled call 1687
Int 23 => 3ca:05d2
Int 2f unhandled call 8000
Int 2f unhandled call 8100
Int 2f unhandled call 8200
Int 2f unhandled call 8300
Int 2f unhandled call 8400
Int 2f unhandled call 8500
Int 2f unhandled call 8600
Int 2f unhandled call 8700
Int 2f unhandled call 8800
Int 2f unhandled call 8900
Int 2f unhandled call 8A00
Int 2f unhandled call 8B00
Int 2f unhandled call 8C00
Int 2f unhandled call 8D00
Int 2f unhandled call 8E00
Int 2f unhandled call 8F00

and ends with :
0.35 Int 2f unhandled call B700
0.48 DOS:IOCTL Call C unhandled
Int 2f unhandled call B700
1.14 Delayed logging, set w/o DOS call:
Int 22 => original
3.73 Int 2f unhandled call B700
Record locking verified for DOS J:
3.76 Int 2f unhandled call B700
Int 2f unhandled call B700
Int 2f unhandled call B700
10.82 Int 2f unhandled call B700
Int 2f unhandled call B700
11.40 Int 2f unhandled call B700
12.20 Int 2f unhandled call B700
Int 2f unhandled call B700
Int 2f unhandled call B700
Int 2f unhandled call B700
16.25 Int 2f unhandled call B700
Int 2f unhandled call B700
Int 2f unhandled call B700
Int 2f unhandled call B700
17.21 Int 24 => original
17.79 Delayed logging, set w/o DOS call:
Int 23 => original
20.57 vDos ended by EXIT (0)


can you make something out of it ?

George

[Jos]

Well, the good news: Int 9 isn’t used.

The first “unhandled call” lines seem to be the app probing te system, for instance if DOS is running under Windows.
No reporting of the app not able to find/open files or start an external program. Though the app does open (and read or write) a file located on DOS J: (Record locking verified for DOS J:).

That would leave the various “Int 2f unhandled call B700”, the installation check for APPEND resident. Never saw this being used in a DOS app, it basically enables to open a file w/o specifying the path in the open operation.

You could try if starting APPEND program of FreeDOS (http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/append.html) before the app will reveal what’s going on.

Jos

[stepgr]

Thanks I will look more into it

George

[stepgr]

Even with append executed beforehand , nothing changes in the log file , just for clarity you meant something like : append c:;j: ?

[Jos]

It would be something like APPEND j:\debgp\shared.

Int 2f-B700 (APPEND - Installation check) is called repeatedly. So one would expect APPEND is needed, before the app even attempts to open a file.
But if no <invalid path> or <file not found> messages are added to the log file, it’s a mystery what the app is trying to do after the Int 2f calls and why it seemingly fails.
I would need a running copy of the app to eventually have a look.

Jos

[stepgr]

I don't know for the copy , I would have to get permission from upstairs first .

Edit:  Note that the same happens even when transferring the app into vdos drive C: 
and execute from there.  What puzzles me though is why although the app doesn't hang 
or crash (in dosbox it crashes on startup ) It seems unresponsive to some screen areas, other
than that you can select some items, perhaps something with the screen draw or fonts ?

[Jos]

So it seems more or less consistent, though can’t be related with things like screen draw or fonts.
Something else would be the issue. Does it effect your actual DOS apps at all. I assume you created some testbench.

Jos