dosbox version?

cv may use unsupported debugging features so i don't really expect it to work fine (this is unrelated to the error you get though).

I have CodeView 4.01, as part of an installation of MASM 6.11, running in DOSBox. Works OK as far as I know; setting breakpoints, single-stepping, etc.; although I probably don't push it too hard, and have only used it with real mode programs. It was awhile ago that I set it up, but IIRC it was picky about which of its DLL files are used. These are the files in my installation: CV.EXE, TOOLS.INI, SHD1.DLL, TLD1LOC.DLL, EMD1D1.DLL, EED1CXX.DLL. Had to manually add an entry in TOOLS.INI for the DOS execution model DLL; which I put just before the end like this:

1[cvw]
2native:EMD1D1.DLL
3
4[end]

MASM 6 also needed some fiddling to get working in DOSBox, which I won't go into unless the information is of use to you.

I GOT IT TO WORK! WHAT A GREAT PRODUCT!
During my testing, I had zapped in 4 'INT 3''s 'cause WinDbg would NOT
stop on it, even using the LOAD MODULE event filter. When I went back to the original CV.EXE, it now, FINALLY, works (source, single-step). I assume
the lack of the proper instructions caused the failure (I zapped over the initial JMP, the MOV, another MOV, and a LODS (the latter 3 were getting the S0C4's); I always re-fix'ed them in core when I was testing).
THANK YOU! I will be making a donation as I FINALLY(!) got CV back. Your product is WELL WORTH IT!!!
PWB/ML still works OK under native DOS.
I had to use LINK563 over LINK (crashes) via MS under native DOS.
NMAKE crashes, even the new NMAKE15 from MASM32, but I have been running PWB/ML, LINK(563), and now CV manually, which is fine with me.
Also, THANKS FOR THE VERY QUICK replies, UNLIKE MS!!!

As an FYI, I FINALLY FIXED CV.exe (CodeView 4.01) to run in Win7 !!!

I ended up forcing a CALL to alloc memory from whatever it was to a fixed 16K:

025f:013b CALL (t thru as B 4)
02df:000b CALL 025f:0dbf (t)
CALL 4192 (t)
025f:41a3
D1EB SHR BX,1

;* zapped these 2 instructions (CV.exe+15235h):
D1EB SHR BX,1
D1EB SHR BX,1

;* with:
BB0004 MOV BX,0400h
90 NOP

;* at this point, BX used to be 2 (paragraphs=32 bytes); now, it's 400h (16*1024 bytes)

MOV AH,48h (alloc memory)
INT 21h

NOW THIS WORKS FROM A NATIVE DOS PROMPT (DOSBox not needed), instead of crashing at CV.exe+11F6A (025f:0eda) due to the DS:SI page being freed:

CVzap DAYOFWK.EXE

and runs completely thru, including source, single-stepping to the end of the app, then Q.

Still, DOSBox runs PWB completely thru, and I think is still the preferred way to go; I just wanted to show how MicroSoft tried to screw us.

M I C R O S O F T . C A N . G O . T O . H E L L !!!

A final (HOPEFULLY!) FYI regarding all these MASM611 problems that MS tried to
FORCE on us in Win7 (and also in later Win6 versions):

Both original LINK.exe and CVPACK.exe modules had to be similarly zapped as follows:

LINK+263F1h
VER D1EB D1EB SHR BX,1 / SHR BX,1
REP BB00 0490 MOV BX.400h / NOP

CVPACK+1b1bbh
VER D1EB D1EB SHR BX,1 / SHR BX,1
REP BB00 2090 MOV BX,2000h / NOP

These 3 zaps are just B 4 the INT 21h/48h (alloc memory).

As w/CV, LINK can be named differently and invoked manually in a native DOS Prompt.
However, LINK attaches (via INT 21h/4Bh) CVPACK if the LINK /CO option is used
(which is required so that CV will work properly), so CVPACK has to keep the same name.
I'm pleased to say that DOSBox works with this zapped version (CVPACK) via PWB as well.
I assume (tho did not test) that the zapped versions of CV and LINK would also run
correctly under DOSBox.

I will NEVER buy another MicroSoft product again!!! And their complete lack of support
of ANY Win7 problem:
. at least 3 WinDbg flaws w/16bit:
. won't stop on a 16bit module via Event Filter/Load module
. must assemble in my own INT 3
. won't stop on an attached module
. LINK invoking CVPACK; had to debug CVPACK stand-alone
. post-mortem debugging results completely wrong (not as in live debugging):
. IP wrong via !ANALYZE -v
. BAT&EXE>Start Menu
. can no longer drag to Start Menu; must change properties, then drag that new icon
to Start Menu so that the WORKING DIR can be maintained (Win4&6 did NOT do this)
is DISGUSTING!!! NOT A WORLD-CLASS COMPANY!!!

Another fyi:

If anyone needs to stop on a 16bit program via WinDbg, this will do so
(ABSOLUTELY NO(!!!) HELP AT ALL FROM LOUSY HORRIBLE MICROSOFT!!!):

1. copy \Windows\System32\dosx.exe to the DOSBOX MOUNT DIR
2. using DOSBox, run 'EXEHDR -v dosx.exe'
3. get the Entry Point (ie: 078f:000a in Win7)
4. zap the copy's EP to 078f:0009 (1 back) and also zap in an INT3 (0xcc) there:
DISP 7AF9h (must account for the 200h-byte filler at the front of the program)
VER 00
REP CC
DISP 0014h (the MZ header)
VER 000A
REP 0009
re-run EXEHDR to verify the EP is correct
5. in \System32:
rename dosx.exe to dosxWIN7.exe (so u can put it back when u r done)
copy the zapped version here
will probably have to deal w/security BS!
6. run WinDbg & load your executable
. PF5 (go) until the INT 3 stops in DOSX.exe (the 2nd INT 3):

Loading [C:\windows\system32\DOSX.EXE]
(6c8.42c): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=000000ff edx=00000529 esi=00000009 edi=00000222
eip=00000009 esp=00000222 ebp=0000091e iopl=0 vif nv up ei pl nz na po nc
cs=0cc8 ss=0ca5 ds=0529 es=0529 fs=0000 gs=0000 efl=000a4202
0cc8:0009 cc int 3 (<== this is what was zapped in step4 above)

. copy the following to \Program Files\Debugging Tools for Windows (x86)\fndint21.txt

t "r? $t1=(@$ip+1) ; r? $t2=(@$ip+2) ; r? $t3=(@$ip+3) ; .if @@((*@$ip == 0x##) && (*@$t1 == 0x##) && (*@$t2 == 0x##) && (*@$t3 == 0x##)) {d $ip l10} .else {$<fndint21.txt}"
|
| <== can also use 'p' if your bytes u r searching for are NOT in a CALL
this will produce MUCH LESS output; however, using this same technique,
u can see the INT21's used in dosx.exe if u want
will probably have to deal w/security BS!

REPLACE THE ABOVE 4 '##' WITH any 4 consecutive bytes in your program near the beginning;
try to pick bytes that aren't very common to, in this case, dosx.exe;
for me, I used: cd213a06

. run the exact same command on the WinDbg command line;
the 1st time, it gets it started:

eax=00000000 ebx=00000000 ecx=000000ff edx=00000529 esi=00000009 edi=00000222
eip=0000000a esp=00000222 ebp=0000091e iopl=0 vif nv up ei pl nz na po nc
cs=0cc8 ss=0ca5 ds=0529 es=0529 fs=0000 gs=0000 efl=000a4202
0cc8:000a b83905 mov ax,539h

the 2nd time (just hit the arrow up key and ENTER) because, for whatever reason, it doesn't work the 1st time!!??
eventually it will stop on the 4 consecutive bytes u r looking for:

FOLLOWING DONE AUTOMATICALLY:
0:000> t "r? $t1=(@$ip+1) ; r? $t2=(@$ip+2) ; r? $t3=(@$ip+3) ; .if @@((*@$ip == 0xcd) && (*@$t1 == 0x21) && (*@$t2 == 0x3a) && (*@$t3 == 0x06)) {d $ip l10} .else {$<fndint21.txt}"
...
0:000> t "r? $t1=(@$ip+1) ; r? $t2=(@$ip+2) ; r? $t3=(@$ip+3) ; .if @@((*@$ip == 0xcd) && (*@$t1 == 0x21) && (*@$t2 == 0x3a) && (*@$t3 == 0x06)) {d $ip l10} .else {$<fndint21.txt}"
0000:e164 cd 21 3a 06 0c 00 74 04-b4 00 eb 03 b8 66 00 b4 .!:...t......f..
=========== (4 consecutive bytes found)
eax=00002a00 ebx=00000010 ecx=000000ff edx=00000e17 esi=00000000 edi=00000400
eip=00000024 esp=00000410 ebp=0000091e iopl=0 vif nv up ei pl nz na po nc
cs=0e14 ss=0e17 ds=0e17 es=0e04 fs=0000 gs=0000 efl=000a4202
0e14:0024 cd21 int 21h

. at this point, u can debug your program

7. rename the original dosx.exe back

ALL THIS BECAUSE MICROSOFT REFUSES TO STOP ON OUR PROGRAMS!!!!!!!!!!!!!!!!!!!!!!!!

Note for everybody else: ONLY modify system files like dosx.exe if you ABSOLUTELY know what you're doing. It's your own responsibility.

TOTALLY AGREE!!! In fact, I should also mention that zapping dosx.exe is NOT needed if u use 'p' over 't'; 't' takes WAY TOO LONG from the initial INT 3, but 'p' only takes a few seconds. So, as long as your choice of the 4 consecutive bytes is NOT within a CALL, there is NO REASON to change dosx.exe...