I'm a bit puzzled what it tries to do here. Wonder if our seek on NUL matches that of real DOS.

1  60723059: FILES:Special file open command C0 file NUL
2
3  60723060: CPU:Illegal/Unhandled opcode 63
4
5  60723062: PIC:0 mask F9
6
7  60723064: PIC:0 mask F8
8
9  60723064: PIC:1 mask EC
10
11  60723078: CPU:Illegal/Unhandled opcode 63
12
13  60723097: DOSMISC:DOS:Unhandled call 5C al=00. Set al to default of 0
14
15  60723098: CPU:Illegal/Unhandled opcode 63
16
17  60723106: DOSMISC:DOS:Unhandled call 5C al=01. Set al to default of 0
18
19  60723107: CPU:Illegal/Unhandled opcode 63
20
21  60723120: CPU:Illegal/Unhandled opcode 63
22
23  60723131: IOCTL:NUL:SEEK
24
25  60723132: CPU:Illegal/Unhandled opcode 63
26
27  60723140: IOCTL:NUL:SEEK
28
29  60723141: CPU:Illegal/Unhandled opcode 63
30
31  60723150: CPU:Illegal/Unhandled opcode 63
32
33  60723194: FILES:Special file open command C0 file NUL

If you want to get deeper into this I can create a version that gives more info on those 2 calls and logs a lot more stuff.

Some stuff uses "open C:\TEST\NUL" to see if a directory exists, does that work?

wd wrote:

Some stuff uses "open C:\TEST\NUL" to see if a directory exists, does that work?

should work. the check for device name has special code to check leading directory for existence.

remcohn, is this a self-developed application or a commercial one?

special debug build: http://dosbox.linuxsecured.net/remcohn.exe
changes : http://dosbox.linuxsecured.net/remcohn.diff

please post the log regardless wether it works.
If it does work please stick around so we can determine exactly what fixed it. (and remove possible not right code)

It doesnt work, still the same error.
I attached the log file again.

It seems that it does a 4E:findfirst(=find file or directory) just after it creates the file

1  27534008: FILES:file create attributes 0 file C:\APW\00865837.TMP
2
3  27534009: CPU:Illegal/Unhandled opcode 63
4
5dos 6866 14
6
7exist
8
9  27534019: CPU:Illegal/Unhandled opcode 63
10
11dos 1A28 8932
12
13  27534042: CPU:Illegal/Unhandled opcode 63
14
15dos 4E28 8932
16
17  27534048: CPU:Illegal/Unhandled opcode 63
18
19dos 1A28 893E
20
21  27534066: CPU:Illegal/Unhandled opcode 63
22
23dos 4E28 893E
24
25  27534072: CPU:Illegal/Unhandled opcode 63
26
27dos 5950 0
28
29  27534083: CPU:Illegal/Unhandled opcode 63
30
31dos 3C28 893E

Given the fact that 59 is also called (get extended error info) This might be clue.

a version that will tell us which name it searches
http://dosbox.linuxsecured.net/remcohn2.exe

Its a commercial application.

Here the log of the app with remcohn2.exe

Remco

the logs looks okay. It creates 2 tempfiles. (first checks if the directory exists, then it checks for the temp file (not exist => createfile)

then it writes and reads data from them.

I don't know if the fat read/write/seek routines are 100 % correct (harddrive images are relatively new)
I can imagine something going wrong there, but as you stated that it didn't work on a mounted directory drive I don't know what is wrong. I can't help you further currently without having the application, which isn't possible for a commercial (copyrighted) work.

Hm app with no name besides APW? Damn.

Are the .TMP files readable? Maybe you can post them here (the ones
referenced in the log, if they aren't deleted by the app).

Is the application correctly installed, ie. within dosbox? (using windows)
Where is GENGRAPH.EXE and similar stuff located?

Hm, i was trying it with a diskimage. have tried the same thing with a directory-mount now, and the checkts it does at startup work then. but then it fails a bit later. i attached the log again.

its made with remcohn2.exe

Remco

Nothing you can do about it.

you see something wrong wd ?

No 😀

Maybe the author of this thread can give this a try: start dosbox, then start a second shell (for example, 4dos or freedos), then try run the application in the second shell.

ah I allready found the bug a while ago.
Application wants to find NUL with findfirst.
A fix is currently being tested by the betatesters

Only a short question for DosBox developpers: was this get fixed?

devices can be found with findfirst. If that is what you are talking about.