how to suppress Runtime error 200?

[nelgin]

I'm trying to help a sysop configure a game. I gave him a copy of all my configuration files including the .dosemu directory. It displays a welcome screen but then exists. Comparing logfiles, the only difference is that he's seeing

Warning: PKT: Cannot open sock

so I'm guessing there's some sort of permissions issue, but under what circumstances would this be generated so I can try and figure out what permissions need fixing?

Thanks,

[stsp]

This message is completely spurious.
Please ignore it, and its now fixed (not printed).

[stsp]

Also it is likely he have a more recent
git build of dosemu2. Maybe you need
to upgrade to reproduce the problem.
Maybe something got broken.

[nelgin]

His does say kernel 1.7 and mine is 1.6

FDPP kernel 1.6 [GIT: ] (compiled Jul 14 2023)

FDPP kernel 1.7 [GIT: ] (compiled Sep 21 2023)

So yes, his definitely is more up to date and, to be honest, I think I'd prefer to keep my working version. I'll see if I can get the updated version on my test box.

[stsp]

In principle, upgrading is a reversible,
and therefore safe operation. You can
later downgrade and get the same state
as initially.
I can't remember a single occasion of
dosemu2's corrupting user's setup the
way downgrade no longer helped.
The only thing I really care about, is
to never destroy user's data. Which is
why there will be no "upgrade wizards"
or alike potentially unsafe things.

[nelgin]

My version is 2.0pre9-8198-a5de3997d+202307141931ubuntu20.04.1 amd64 so I've asked the other sysop to try and downgrade and see if that fixes the issue, rather than me upgrade and end up breaking mine.

Thanks,

[nelgin]

can't create local /var/run/user/1030/dosemu2 directory

that's new for a start...

[stsp]

Maybe, but its not a big problem.
We use new /var/run/user dir, but
its optional, so ignore that msg.

[nelgin]

Now, this is interesting. I downgraded dosemu of my home bare metal linux box and when I run the game I get:
Runtime error 200 at 2DEF:0091

But works fine on the dosemu on my VM.

tppatch patchcrt and run200 don't fix it. It's not compressed.

I may have to open a report on this. I am running jammy but have the focal version installed on the VM that works.

I removed dosemu2 and friends from my bare metal box and reinstalled focus versions of dosemu2 fdpp,

Not quite sure what's going on here...

[stsp]

You likely had no KVM available
under VM, so the speed was considerably
lowered and no "runtime error 200".
Sorry to disappoint you but you need
to patch all the "runtime error 200" bugs
by hands, if the automatic patchers do
not help. If the problem is easily reproducible,
I can do it for you if you upload the binary.
Its not a difficult task at all.

[nelgin]

If it'd not difficult, I'd like to give it a go but I'd need some instruction on how to :)

[ecm-pushbx]

If I understand correctly you just want to patch out the division? Assuming that the timing isn't actually needed?

Like what @stsp suggested you can intercept int 0 (division error). My debugger, lDebug, hooks int 0 by default. It is possible your application's run time will itself intercept int 0. If so, trace the application or jump to int 21h entrypoints using a permanent breakpoint set by bp new ptr ri21p then multiple g commands. Use dim 0 to see whether int 0 is hooked by your application yet. Once it is, disable the prior breakpoint with bd all, add a new breakpoint like bp new ptr ri00p then run with g to return control to the debugger upon an int 0 call. Then disassemble the caller of the int 0 using u ptr [ss:sp] or to see some more context try u ptr [ss:sp] - 10. Note down what instructions to overwrite. You can also calculate h (linear SSSS:OOOO) - (linear PSP:100) where SSSS:OOOO is a segmented address. This will hint at where in the executable image your code is found. Run the remaining part of your application using another g command.

Then you can use ldebug /f progfile.exe to load a DOS executable (even if MZ .EXE) as a flat binary, find the instructions that you had noted (make sure to account for the MZ .EXE header if any), and overwrite them. Afterwards run a w command to write back changes to your executable. This only works well if the executables are not compressed.

[stsp]

Oh, I wouldn't use that method. :)
So why your debugger can't for example
use DPMI to hook the realmode
exception 0? Then all this complexity
is not needed, and yes, turbopascal
progs do hook int0 exactly to print
the "runtime error 200" msg. If they
didn't, we could avoid any patching.

[ecm-pushbx]

Oh, I wouldn't use that method. :) So why your debugger can't for example use DPMI to hook the realmode exception 0? Then all this complexity is not needed,

The debugger does not ever enter PM of its own doing, so even if I knew how to do that it wouldn't work in the modes model of lDebug.

and yes, turbopascal progs do hook int0 exactly to print the "runtime error 200" msg. If they didn't, we could avoid any patching.

If so, my trace/breakpoint suggestions should work.

[stsp]

If so, my trace/breakpoint suggestions should work.

You need to put a watch-point to
the IVT entry 0 to do that reliably.

The debugger does not ever enter PM of its own

Then I'll do the trick in comcom32.
as it is a DPMI client. I can introduce
the r200fix command, similar to
loadfix.
Can someone with TurboPascal at
hands, compile a simple helloworld
with runtime error 200 for me, so
that I can add the r200fix to comcom32?

[stsp]

OK, actually it is already attached to
that ticket. :) So no worries.

[nelgin]

Ok, not sure if I'm doing this right. I ran dosemu then got the pid of dosemu.bin then did dosdebug pid
I ran my program casino /L and now I'm doing ct on the dosemu side

I'm using tc to automatically step through, if I just use g then the program exits and no indication of an issue on dosdebug.

[nelgin]

CASINO.ZIP

I give up. CASINO.EXE and CRCSETUP.EXE both need a fix. If you want to try them, it should run as is with CASINO /L

[stsp]

This program is packed by an
unknown packer. So its a good
case for adding a comcom32-based
work-around.

[stsp]

Anyway, here's the tutorial, as
promised:

$ dosemu ./CASINO.EXE -T -H1
<go to another terminal>
$ dosdebug

DOSEMU Debugger V0.6 connected
- type ? to get help on commands -
system state: stopped
AX=0000  BX=0000  CX=0000  DX=0000  SI=0000  DI=0000  SP=fffe  BP=0000
DS=0040  ES=0000  FS=0000  GS=0000  FL=00033202
CS:IP=ff10:020b       SS:SP=0000:fffe

ff10:020b F4               hlt

system state: stopped
AX=0000  BX=0000  CX=0000  DX=0000  SI=0000  DI=0000  SP=fffe  BP=0000
DS=0040  ES=0000  FS=0000  GS=0000  FL=00033202
CS:IP=ff10:020b       SS:SP=0000:fffe

ff10:020b F4               hlt

dosdebug> bpint 0
dosdebug> g
system state: stopped in real mode while in DPMI
AX=1523  BX=0f8d  CX=ebc3  DX=7448  SI=01fb  DI=0010  SP=0a88  BP=1502
DS=00ad  ES=00ad  FS=4553  GS=554d  FL=00033302
CS:IP=15af:0239       SS:SP=15af:0a88

15af:0239 3403             xor  al,03

dosdebug> 
INT 0x00, system state: stopped in real mode while in DPMI
AX=6490  BX=00fa  CX=0037  DX=06eb  SI=0264  DI=006c  SP=7ff8  BP=7ffa
DS=3127  ES=0040  FS=4553  GS=554d  FL=000b7297
CS:IP=2e9c:0091       SS:SP=397b:7ff8

2e9c:0091 F7F1             div  cx
system state: stopped in real mode while in DPMI
AX=6490  BX=00fa  CX=0037  DX=06eb  SI=0264  DI=006c  SP=7ff2  BP=7ffa
DS=3127  ES=0040  FS=4553  GS=554d  FL=00033297
CS:IP=2f15:010c       SS:SP=397b:7ff2

2f15:010c B8C800           mov  ax,00C8

dosdebug> u 2e9c:0091

2e9c:0091 F7F1             div  cx
2e9c:0093 A3E682           mov  [82E6],ax
2e9c:0096 1E               push ds
2e9c:0097 0E               push cs
2e9c:0098 1F               pop  ds
2e9c:0099 BA3801           mov  dx,0138
2e9c:009c B81B25           mov  ax,251B
2e9c:009f CD21             int  21
2e9c:00a1 1F               pop  ds
2e9c:00a2 C3               ret
2e9c:00a3 8E069E02         mov  es,[029E]
2e9c:00a7 2680268700FE     and  byte es:[0087],FE
2e9c:00ad 3C07             cmp  al,07
2e9c:00af 7406             je   00B7 ($+6)

dosdebug> 

So in this example we found the
offending div cx and its context.
Unfortunately, due to the packer,
its not possible to find it in the
executable.

[nelgin]

This is good info. I did try a couple of unpackers on it. I guess I can see if I can find any more that might work on it.
Thank you.

[stsp]

There is some anti-debugger trick
employed, and all unpackers I tried,
get GPF. But dosdebug have no
problems tracing this. So maybe
Andrew will implement the dosdebug-based
unpacker. :)
But for now the simplest solution
is to implement the suppression
mechanism in comcom32.

[nelgin]

program helloworld;

var
    a : integer;
    b : integer;
begin
    a := 5;
    b := 0;
    writeln('Hellow world!');
    writeln(a div b);
end.

Would that work?

E:\>hello
Hello World!
Runtime error 200 at 0000:004c

rename hello.exe.txt to hello.txt
[HELLO.EXE.TXT](https://github.com/dosemu2/dosemu2/files/12823229/HELLO.EXE.TXT)

[nelgin]

This is an unpacked version, I hope.
CAS.EXE.TXT

[stsp]

Now you surprised me. :)
You managed to remove the encryptor.
Its still packed, but the unpacked
version is now here:
cas.exe.gz
So how have you done that?

[stsp]

So here's your patched version:
cas_p.exe.gz

[nelgin]

Haha! I'm not just a pretty face you know... ;)

cup34.zip will have cpu386.com - I had to use a virtualbox DOS instance, it wouldn't on dosbox or dosemu2.

cup386 casino.exe cas.exe /7 /s

What did you do to the CAS.EXE after you downloaded it? Which packer was used?

[stsp]

The packer was called Diet.
You could likely remove also that
by unpacking for the second time
with cup386.

So the main trick was to not use
dosemu at a first place...
Andrew, I think you really need to
implement the dosdebug-based
unpacker then. :)

[stsp]

I opened the ticket
dosemu2/dosemu2#2110
as a reminder.

[andrewbird]

@stsp : Unfortunately my outside project is taking longer than expected, so I doubt I'll get back to Dosemu soon, or at least until the weather breaks for the winter.

[nelgin]

When I used dosemu to run cup386.com it just exits.

Not sure if this will help.

ERROR: unexpected CPU exception 0x0e err=0x00000004 cr2=3a66c588 while in vm86 (DOS)

Real-mode state dump:
EIP: 1dcc:0000112e ESP: 1bc6:000001f4  VFLAGS(b): 01011 00110010 10000000
EAX: 4c4908cd EBX: 4c4901f6 ECX: 534f0000 EDX: 3a6502ee VFLAGS(h): 000b3280
ESI: 6d6527e7 EDI: 645c088c EBP: 3a65091e DS: 02ee ES: 1bc6 FS: 3253 GS: 653b
FLAGS: SF IF RF VM VIF  IOPL: 3
STACK: 00 00 00 00 00 00 55 53 45 52 -> 2a 03 7a 08 cd 08 dc d8 ca 18
OPS  : 00 00 66 0a 64 0a 00 00 6f 0a -> 67 0a 6d 0a 76 0a 00 00 00 00
        670a6d0a            1dcc:112e or   ch,[ebp+000A]

[stsp]

The only way to check is to
run under windows. They also
have dpmi for ring-3 apps.
If cup386 doesn't work there,
then for now its not going to
work under dosemu2.
A bit different situation about
dosbox as dosbox is supposed
to run protmode apps directly.
So I don't know why it doesn't
work for you there.

[stsp]

@andrewbird please get back at any time!
The unpacker will wait for you, I promise. :)
As well as all the other things.

[stuaxo]

I wonder if Teddy Matsumoto is still around and would be up for releasing the source of Diet ?
https://www.bttr-software.de/freesoft/arc2.htm