Hello everyone,
I foolishly believed that Codeview could debug 16 bit code running under Win 7 simply because it worked under XP SP 3. It doesn't. In a previous post to this forum, Clive suggested that it might not. I can report that it doesn't. period. The codeview window opens, but it does not respond to keyboard/mouse input.
There is no information I could find at MSDN library on this matter. Someone else here might have better info of course than I do.
Assuming that my claim is correct, could someone suggest a debugger for 16 bit code that would work under Win 7? Or is this simply hopeless?
Thanks,
Mark Allyn
without a virtual environment of some kind, win 7 64-bit does not support 16-bit code
Hi DednDave,
That seems definitive. It is indeed hopeless. Oh, well....Thanks.
Mark
Hi Dedndave,
But, what bothers me about this is that the 16 bit program I wrote assembles just fine with ml /c /omf /Zi /Fl segtst.asm and moreover it links without any problem with link16 /map /codeview segtst.obj,,,c:\stdlib\stdlib\lib\stdlib.lib.
...and it runs
...and if I execute c:\debug segtst.exe the ancient old debug pgm runs like a top. All of this under Win 7.
Honestly, I could use a bit of a tutorial on why codeview won't work except in what you call a "virtual environment". Hope I'm not being a pest.
Regards,
Mark
oh - maybe you are using win7 32-bit
anyways, codeview may not work properly because of the way it sets breakpoints
or it is in some other way violating modern protection mechanisms
like - trying to access data at 40:0, or revectoring interrupts, etc
Hi.
You could try a virtual environment such as DOSBOX, VirtualPC,
or Bochs to run your debugging session. Those may emulate a
real mode better than Windows 7.
HTH,
Steve N.
Steve,
I'm completely unfamiliar with DosBox. Their home page doesn't mention compatibility with Win 7, but assuming it does run on Win 7, would it know what to do with the debugging symbols generated by link16 and ml? Or are these symbols transparent to DoxBox? I suppose if it is truly a Dos emulator it would have to know what to do with the debug information....someone had to debug the games that were originally written for Dos. maybe I'm answering my own question.
Thanks for the tip. It certainly might be the solution.
Regards,
Mark
the symbols have nothing to do with DosBox :P
Hi Dedndave,
Thanks for confirming my guess.
According to DosBox's ReadMe there is no particular danger in using their product. Hope they're right cause I'm going to give it a try later today.
Regards,
Mark
The CodeView symbols just sit behind the executable, the normal DOS loader doesn't even see them or load them, they are effectively out-of-band data in the executable format.
Now the classic DOS CodeView debugger uses a number of 80286 era protected mode type tricks to act more like a DOS extender as I recall, and hide outside of regular DOS's memory space. The OS/2 one might be worth a look, but with all these things your linker is probably generating the most modern version of the symbol format, and assorted older versions of CodeView are probably not going to be able to parse them. Using an older 16-bit linker might help with that, but you're wading into about 25-years worth of old crap that Microsoft wants to move beyond.
I'm surprised Dave hasn't thrown SYMDEB at you, it might at least run, and you'd create .SYM files from .MAP files with MAPSYM.
Hi Clive, Dave, Steve
I can confirm that DosBox works fine on Win7. Their home page does not explicitly state this, but a quick test showed that it runs a little 16 bit app without a problem.
I'm not entirely clear on how to run Codeview under DosBox. The version of CodeView I am using came with a distribution of MASM 6.15 in the /bin file. I'll play around with this some more.
The version of link16 that I am using is the same one as distributed with Masm32. I do not know offhand its version number.
Thanks for clarifying the location of the debug symbols. I thought it was strange when no .pdb or .dbg file was generated. I know I am reprising stuff that happened many years ago and that can be done much more efficiently now. But, I got interested in memory segmentation and one thing led to another...a slippery slope.
I'll let you know how things turn out with codeview.
Regards,
Mark
Clive, Dave, and Steve,
Well, Codeview does indeed work fine on DosBox under Win 7. I haven't tested all the codeview features, but so far everything behaves as one would wish.
I suppose I should now invest in a bunch of 16 bit games...
Thanks to all.
Mark
CodeView symbol dumping tool.
Clive,
Thanks for the file. I'll try it out.
Regards,
Mark
Hello Clive,
I dumped codeview using your program. Is there a primer on how to read the tables?
Regards,
Mark
DumpCV is somewhat of a toy application, it tries to parse or break down the internal content in a semi-coherent form, but it gets updated now and again when people find files that break it. I use it as a diagnostic tool and test platform for my symbol extraction library.
The thing to remember when deciphering the symbols is to think of various scopes, the function, loops, local variables. Or compounded statements in C ie { }. A subroutine is described as several levels of nesting. Depending on the compiler and linker setting you can see more detail, including things like source files and line numbers. Symbols can be broken down by module/object, or describe the public symbols in the final executable. Finally the symbols can have hash tables, and the format/algorithms/binning of those tables have changed over time, in most cases these aren't of much interest, they just permit quick cross-referencing via symbol name. Certainly in the beginning the goal was to just load the symbols as a big binary blob the debugger could just navigate, rather than have to parse/process itself. In that respect the linker, and tools like CVPACK, basically processed the data into an easily digestible form.
I've dug around with this stuff quite a lot over the years, and played with most of the 16-bit C, Pascal, Fortran and Basic compilers Microsoft released. I have a lot of the 32-bit ones too, and also the Borland and Watcom tools.
There used to be material on the MSDN discs, but I suspect getting access to what you want might be difficult. Never was really well documented, at least in terms of being able to generate it with 100% confidence. I just built tools to extract symbols for my debuggers and disassemblers. I do a half-assed job of parsing the "type" information because I've never had a pressing need for it. The PDB files are an abstracted extension where the CodeView data evolved into a new form. The documentation on these is even more sparse, and I'd hazard Microsoft can't decipher all the formats they created simultaneously. The other draw for moving to PDB files was the ability to handle incremental compiling/linking.
The often cited spec is "Microsoft Codeview 4.0 Symbolic Debug Information Specification"
"Improve Your Debugging by Generating Symbols from COM Type Libraries"
http://www.microsoft.com/msj/0399/hood/hood0399.aspx
Hello Clive,
Thank you for your elucidation of dumpcv and more generally the status of debugger documentation. I looked at the Pietrek article and this is a start, at least, in getting a better appreciation of this extremely complex field. I'll also look at the MSFT document reference you gave.
As an aside (partly because it probably belongs in a different thread), I have had rotten luck making windbg work with 32 bit C programs and I thought perhaps codeview might be a reasonable substitute, at least for 16 bit code. And so it is, especially on XP SP3, less so for Win7. As seems to be universally (or nearly, at any rate) true, Ollydbg has been my preferred debugger for 32 bits. But, I always wanted to make Windbg go, although its user interface is much less friendly than Olly.
Thanks very much for your help and for the copy of dumpcv. It deserves a lot more study, even if it is "just a toy".
Regards,
Mark
as Clive mentioned, for 16-bit code (including 16-bit programs that may have 32-bit instructions) you can use SymDeb
it isn't CodeView, but it works, and it is compatible with the symbol files generated by MapSym
although you may want to use CodeView, it might be handy to have on hand for comparison testing
i never liked CodeView and used SymDeb for years
i used it to dis-assemble many 16-bit programs, including much of DOS :P
i even used it to dis-assemble SymDeb - lol
Hi Dedndave,
I haven't used Codeview much because I'm early on in the stages of figuring out 16 bit dos stuff. It is certainly less user friendly than Olly! But it is just as certainly more user friendly than Windbg. I really struggle with that one.. and it usually wins too. Disheartening.
I will certainly have a look at SymDeb. Thanks for attaching it. I'll test drive it tomorrow afternoon and report on my experience.
Regards to you and Clive,
Mark
Hi Dedndave,
OK, so I have been trying SymDeb. First glance it looks a lot like Debug.exe except it has a bunch more commands. The one I couldn't find was a Restart command....is there one? I also couldn't figure out how to use the X commands for symbols.
Thanks for putting me onto this program. Certainly easy to invoke.
Mark
well - besides the commands, there are 2 main advantages over debug:
1) it supports symbols
2) it disassemble some 32-bit code
there is no restart, that i am aware of
you can set the DS and ES regsiters to point to the PSP
set CS:IP to the entry point
set SS:SP to the stack base
that may or may not be the same as restart, because data has been modified
also easy - Q command, then F3 at the prompt :bg
use the "r" command to set registers
I'm going to park this material here in case it's useful to anyone, and that it will show up in Google, and I can find them rapidly later.
This document covers the OMF Object and Library format used by Microsoft, along with ELF and DWARF
Tool Interface Standard (TIS)
Portable Formats Specification, Version 1.1
http://www.acm.uiuc.edu/sigops/rsrc/pfmt11.pdf
This one covers the PE format and CodeView symbols
Tool Interface Standard (TIS)
Formats Specification for Windows, Version 1.0
http://www.x-ways.net/winhex/kb/ff/PE_EXE.pdf
Robert Collins (TI, Transmeta, nVidia) has these in separate documents
http://www.rcollins.org/intel.doc/Tools.html
ftp://ftp.x86.org/manuals/tools/sym.pdf
ftp://ftp.x86.org/manuals/tools/pe.pdf
ftp://ftp.x86.org/manuals/tools/omf.pdf
ftp://ftp.x86.org/manuals/tools/elf.pdf
ftp://ftp.x86.org/manuals/tools/dwarf.pdf
ftp://ftp.x86.org/manuals/tools/winform.pdf
Here's the 1.2 ELF specification
http://refspecs.freestandards.org/elf/elf.pdf
And a repository much historical material
http://www.osdever.net/cottontail/
Tools Developer Documentation, multiple platforms and formats
http://www.openwatcom.org/index.php/Developer_Documentation
Good evening, Clive
Thank you for posting this material. Very helpful.
Regards,
Mark Allyn