rsi.trp is unstable

[stsp]

serserv /tr=rsi doesn't give a
stable debug experience under
DOS. You can see the problem
almost immediately, for example
F5 (Go) in debugger doesn't work.
Tracing kinda works, but it traces
wrongly.

Using /tr=cw is OTOH very stable.
So either RSI should be fixed, or
the documentation should be
updated to not mention it (or
mention that its broken).

[stsp]

Note that I didn't succeed in
using RSI traps with dos32a.exe
at all. I think only dos4gw support
those traps. Was this ever opened
in a dos32a bug tracker, or is it
not supposed to work on dos32a?

[jmalak]

We incline to use Causeway Extender, because we have source code and maintain it.
Now all DOS OW tools are linked with Causeway Extender which is bounded to executable.
It looks like rsi trap file is broken somehow and need to fix.
It is hard to say if it is dos32a issue or our rsi trap issue.
Generaly rsi trap should use DPMI call if it is available otherwise it uses rsi specific API.
May be that in rsi trap is bug and somewhere is used rsi specific API even if DPMI function is available.
It is trouble with debugging, but DOS32a Extender executable should works, because OW CRTL should use DPMI services if available. Anyway OW CRTL startup code recognize DOS4GW, Causeway and dos32a extenders as DOSX_RATIONAL and can use something rsi specific. But use of DPMI API is preferred to minimise CRTL dependency on Extender. Mostly some low-lvel API is used for hardware, I don't know what rsi API function are simulated by dos32a.
It is very very long time when I programmed for DOS Extenders.

[stsp]

The problem with dos32a is
much worse than with dos4gw.
With dos4gw the traps are
unstable. But with dos32a
(renamed to dos4gw.exe):

DOS/32A -- DOS Extender version 9.1.2
Copyright (C) 1996-2006 by Narech K.
DOS/32A fatal (3003): file ".\RSIHELP.EXP" does not contain any valid exec format

So this seems completely unsupported?

[jmalak]

It is wrong way, you should simply try to use rsi target with dos32a executable.
If it doesn't works then no possible debug dos32a executable, it needs specific trap file which doesn't exist or must be part of dos32a.

[stsp]

So if I do not rename dos32a
to dos4gw, then I get this:

Unable to locate DOS extender. Probable cause: incorrectly set PATHUnable to loc
ate DOS extender. Probable cause: incorrectly set PATH

Please fix those msgs.
Many of them do not have NLs.

[stsp]

It is very very long time when I programmed for DOS Extenders.

Let me know if you need any
assistance in creating the
wdw-enabled linux setup.
Its definitely easier to start
from some reliable setup,
and I am pretty sure I am
the only one who actually
have it ready. :)

[jmalak]

The definitely OW debugger has no support for dos32a extender that such executable cannnot be debugged by OW debugger.
If somebody need it then debug trap file must be develop for dos32a.
But I thing it is not a problem to link it with Causeway Extender for debugging and release it with dos32a extender if necessary.

[jmalak]

Please could you extend "debugging" section in Wiki by description of your configuration for DOS remote debugging on Linux.
It could be usefull for other users.

[stsp]

But I thing it is not a problem to link it with Causeway Extender for debugging and release it with
dos32a extender if necessary.

I don't even need to link anything
with CW. CW seems to be a drop-in
replacement. So I just build for
"dos4g" target, and then I can run
with dos4gw and debug with cw
by just specifying /tr=cw.
So CW is really great.

Please could you extend "debugging" section in Wiki by description of your configuration for DOS remote
debugging on Linux.

Do you know if its possible to set
up dosbox to create pts for virtual
comport? I did my setup with dosemu,
which is probably not good for your
wiki. Although if you want wine there,
then dosemu can also do well?

I think this all depends on the fact,
whether or not you will fix the linux
port of WD. If yes - why to add various
hacks to wiki. But if no, then lets just
add wine, dosemu and whatnot?

[jmalak]

But I thing it is not a problem to link it with Causeway Extender for debugging and release it with
dos32a extender if necessary.

I don't even need to link anything with CW. CW seems to be a drop-in replacement. So I just build for "dos4g" target, and then I can run with dos4gw and debug with cw by just specifying /tr=cw. So CW is really great.

I think it is due to DOS4GW extender is not bind to executable (not permitted by licence for WATCOM) . if you debug with CW trap it load CauseWay Extender for debug and run executable under CauseWay Extender correctly.
There is also difference in debugging with rsi and cw.
rsi trap use DOS4GW 16-bit debug interface (DOS4GW has 16-bit core) but cw uses Causeway 32-bit debug interface.
rsi trap is 16-bit but cw trap is 32-bit even if both debug 32-bit application.

Please could you extend "debugging" section in Wiki by description of your configuration for DOS remote
debugging on Linux.

Do you know if its possible to set up dosbox to create pts for virtual comport? I did my setup with dosemu, which is probably not good for your wiki. Although if you want wine there, then dosemu can also do well?

I think this all depends on the fact, whether or not you will fix the linux port of WD. If yes - why to add various hacks to wiki.
But if no, then lets just add wine, dosemu and whatnot?

of cause rsi trap and Linux wd will be fixed it is not abandoned, but it is not priority one.

[stsp]

Please could you extend "debugging" section in Wiki by description of your configuration for DOS remote
debugging on Linux.

I wrote a new page now:
https://github.com/open-watcom/open-watcom-v2/wiki/Remote-debugging-under-Linux-(Ubuntu)
Let me know what do you think
of it. It really looks so simple, much
simpler than your windows setup.

It could be usefull for other users.

Have anyone ever asked about
remote debugging from linux to
DOS, before myself?

[stsp]

Also I think you have a few bugs
in your windows wiki page. It says:
wdw -trap=ser;4 /download "application executable name"
Whereas my page explicitly says this:

Note that the argument order is important: /download must be after the file name, or it will try to open
the file locally, instead of downloading it via the debug connection.

I think you really need to swap
/download and an app name.

[stsp]

It really looks so simple, much
simpler than your windows setup.

Of course I meant to say that
using linux is much simpler than
windows, including for OW, for
running DOS etc.
Not sure if it could sound as
bashing to your howto, but
maybe it did, since there were
no more replies in any thread. :)
I only meant that linux = simple.