Debugging causeway applications

[16bitPM]

Does anyone have experience with the Causeway DOS extender?
I'm trying to debug some examples in the source distribution. All of them crash the computer the moment I try to single-step the first instruction.

I tried using no drivers except HIMEM.SYS, with EMM386, and with the RDOSUMB driver.

For example:

ML screen32.asm
WL32 screen32.obj
WD /tr=cw screen32.exe


WD starts and shows the code correctly. I press F8 and *crash*.

Sometimes CTRL-ALT-DEL works, sometimes not 

Computer is an AMD 80386DX-40 with 20MiB of RAM.

[_japheth]

Does anyone have experience with the Causeway DOS extender?

yes....

I'm trying to debug some examples in the source distribution. All of them crash the computer the moment I try to single-step the first instruction.

I tried using no drivers except HIMEM.SYS, with EMM386, and with the RDOSUMB driver.

For example:

ML screen32.asm
WL32 screen32.obj
WD /tr=cw screen32.exe


WD starts and shows the code correctly. I press F8 and *crash*.

There's a DOS sub-forum. It's labeled "16-bit", which isn't quite correct for Causeway, but it's the correct place for such topics.

Also, please provide source code - that's a matter of course, IMO. Otherwise, usually only wild guesses are possible...

Causeway is probably the best DOS32G/W compatible extender. Nevertheless, for assembly programs, you are perhaps better off reading the documentation for this extender ( provided with OW ).

Masm-compatible sample:

Code Select Expand

.386
.model flat
.stack 4096

.data

text1 db "Hello, CW",13,10,'$'

.code

_start:
push ss
pop ds
mov edx, offset text1
mov ah,9
int 21h
mov ah, 4Ch
int 21h

    end _start

Assemble with ML, link with "wlink system causeway f sample.obj".


 -

[16bitPM]

There's a DOS sub-forum. It's labeled "16-bit", which isn't quite correct for Causeway, but it's the correct place for such topics.

Also, please provide source code - that's a matter of course, IMO. Otherwise, usually only wild guesses are possible...

Assemble with ML, link with "wlink system causeway f sample.obj".


-

Thank you,

I'll post in the right forum next time.
As for the source code, I just tried to assemble the following examples, shipped with the distribution of CW (unmodified). They are in the BIN directory and of course available on Github.

• MULTNEAR.ASM
• MULTFLAT.ASM
• SCREEN32.ASM

Your example code behaves no different. Linked with WL32, single step causes an immediate system reset. Linked with WLINK, it hangs the computer.
The code runs normally without debugger.

[_japheth]

As for the source code, I just tried to assemble the following examples, shipped with the distribution of CW (unmodified). They are in the BIN directory and of course available on Github.

Ok, I restricted myself to the Causeway binaries shipped with Open Watcom v1.9. Not sure if the binaries in github are fully compatible with Open Watcom's debugger WD.

Your example code behaves no different. Linked with WL32, single step causes an immediate system reset. Linked with WLINK, it hangs the computer.

WD itself is a DOS-extended application. This binary uses the Rational DOS-extender DOS4G/W - IMO not the most stable extender. However, on my system WD starts fine and I can single-step thru the sample.

[16bitPM]

I've gotten somewhat closer.
Causeway applications linked with WL32 execute but can't be debugged.
When linked with WLINK they crash.
One of the example programs, SCREEN32, bails with exception #0D error code 0.
Your example oddly DOES work with WLINK (but still crashes in WD).

[_japheth]

I've gotten somewhat closer.
Causeway applications linked with WL32 execute but can't be debugged.

I'm not 100% sure, but AFAIU the CauseWay linker WL32 links the protected-mode binary in its very own format ( 3P ). To debug such binaries, the CauseWay debugger (CWD) is supposed to be used.

OTOH, the Watcom linker WLINK, if using Watcom's CauseWay support, links the protected-mode binary in LE/LX format. This is the format to be used for Watcom's debugger WD ( the binary loader in this case is CWHELP.EXE ).

So, in my understanding, one shouldn't mix the "standalone" CauseWay tools (WL32, CWD) and the Watcom tools ( WLINK, WD, CW.TRP & CWHELP.EXE).

When linked with WLINK they crash.

You'll have to tell which version of Watcom you're using: Watcom v11, Open Watcom v1.9 or Open Watcom v2.0. At least for Open Watcom v2.0 I can tell that WD's DOS support is severely broken currently. I suggest using Open Watcom v1.9.

[16bitPM]

I'm not 100% sure, but AFAIU the CauseWay linker WL32 links the protected-mode binary in its very own format ( 3P ). To debug such binaries, the CauseWay debugger (CWD) is supposed to be used.

OTOH, the Watcom linker WLINK, if using Watcom's CauseWay support, links the protected-mode binary in LE/LX format. This is the format to be used for Watcom's debugger WD ( the binary loader in this case is CWHELP.EXE ).

So, in my understanding, one shouldn't mix the "standalone" CauseWay tools (WL32, CWD) and the Watcom tools ( WLINK, WD, CW.TRP & CWHELP.EXE).

Well, dang! I wasn't aware of that! Turns out CWD can successfully debug both formats.

You'll have to tell which version of Watcom you're using: Watcom v11, Open Watcom v1.9 or Open Watcom v2.0. At least for Open Watcom v2.0 I can tell that WD's DOS support is severely broken currently. I suggest using Open Watcom v1.9.

I use OpenWatcom 1.9. I just did a complete reinstall too, just to be sure that some file didn't get botched up somehow, but that isn't it. It's running on an 80386, but I don't think that's the issue.

[_japheth]

I use OpenWatcom 1.9. I just did a complete reinstall too, just to be sure that some file didn't get botched up somehow, but that isn't it. It's running on an 80386, but I don't think that's the issue.

Probably not. Also, 20MB should be enough for both WD and your Causeway app.

What were the exact commands to build the binary with WLINK? Btw, symbolic debugging can be activated by:

Code Select Expand

ML -Zi sample.asm
WLINK debug c system causeway file sample.obj op cvp

That allows symbolic debugging on my machine - don't miss the cvp option ( activates the CVPACK tool ).