DEBUG.EXE: the machine at your fingertips.
For one with a feel for basic things, one of the great things in MS-DOS was the ability to enter into direct contact with the inner workings of the machine through DEBUG.EXE with almost no learning curve at all. All that was needed was a knowledge of the x86 instruction set (plus a few commands). And you could see memory dumps and machine code almost at once! You could even disassemble the BIOS.
Anything like this in present day software? The answer is a plain no, I know. So what do I mean by this question? Only two things: is there among software produced by the linux community a debugger satisfying both the conditions of utmost usage simplicity and the bare capacity to let you see code anywhere in memory? |
My personal favorite was the debugger and the Integer Basic interpreter that were all crammed into the Apple ][. I also enjoy playing with my Apple-1 :) and KIM-1.
No, the only way today to "have the machine at your fingertips" is with a virtual machine ... or something like a CP/M or DOS emulator. I, too, miss those glory days. |
That makes two of us! By the way, how do I cp a lot of files without CRT output?
EDIT: Had the Apple hard disk a absolute 0 sector analogous to the MBR? |
Trying to see anywhere in memory would lead to a segfault, and thank goodness and protected mode for that.
|
That's the point. No segfaults, no processor exceptions, absolute rule! You could even read or write the MBR (sector absolute number zero), with 5 DEBUG.EXE instructions for making a backup or restore your MBR.
Protected mode was the beginning of the debacle. After that, we all lie slaves to the machine, which decides by herself what can be done and what cannot be done. |
Greetz
Well, actually those days aren't dead. You still can. FreeDOS has DebugX which is 32bit. That shouldn't be too awful surprising when Debug.exe was essentially just scaled down Assembly. |
Yeah... today I was curious and typed in DEBUG in the DOS prompt (Freedos): and there it was! I used to write:
>A 0100 MOV AX,0102 0103 MOV BX,200 0106 MOV CX,0 0109 MOV DX,0080 010C INT 13 010E >G10E and there I was reading the MBR. To write a backup onto sector 0, I could not used the DEBUG commands, for they were dependent on DOS int 21h, which did not access track 0. But BIOS did, of course! So loading the backup into memory with a DEBUG command, then the same five machine instructions wrote the backup onto sector 0, changing MOV AX,0102 for MOV AX,0103. Why use any other thing? That is the name of simplicity. So DEBUG.exe was written in assembly? Easy to imagine. I have a MASM 6.11 in a CD-ROM. Microsoft of Argentina gave it to me for free, as I was telling them I wanted to write some driver using 32 bits. Finally, I must have emptied there patience, and they sent me the 32-bit assembler home. But I discovered it did not include the linker! |
Quote:
|
The basics and something else (thanks for the links). I remember when using the 586 (the breakthrough to 32 bits was in the 386 I think to remember) the "enormous" width of the code column in the listings. When I plunged into the 586 Intel manuals, I was amazed by seeing that CPU was like a universe in itself! So complex and extensive it was. I had made a great effort to understand protected mode in the 286, the great initiator, and had tried my hand writting some programs which just allocated and wrote the tables and had even played with the interrupt descriptor tables (IDT). In short, it was great fun, but to keep with the enormous complexity of the Pentium I was just too much. Of course it was downwards compatible with even the 8086/88, just as the Intel processor in the machine I bought a year ago is.
In Linux I've used plain as, the GNU assembler, but that was a long time ago. And I even made my first steps with gbd. A pity I left it. Instructions such as MOV, ADD, SUB and JMP are the very mnemonics used by Intel in the x86 CPU programmer's reference library and in the hardware reference. They are called machine code or just instructions. The 8086, and the 8088, the 8-bit hardware brother of the former, the 8086 having a 16-bit wide data bus, and being the first Intel processor that went into the IBM PC, had instructions to perform division and multiplication. The IDIV instruction, in its memory-word version, executed in 59-67 clock cycles, with each clock cycle = 500ns. The x86 Intel processor I have now in my machine, a direct descendent of the 8086 and downwards compatible with it, executes that instruction for quadruple the memory-word size in only at most 4 clocks with each clock = 1/2.60GHz = 0.38ns when running at full speed. This is a long way from the IBM XT Personal Computer (which really ran at some 3.8MHz) and an improvement by a factor of nearly 4000 in speed. However, the difference between a bad algorithm and a good one, it could be the case that it were ten to the power of a thousand or make the computer run for as long as the age of the universe [the universe is infinitely younger than that]. I could give concrete examples of this but the length of this post menaces with reaching astronimical figures as well. So, glad to meet you and until the next one. |
Quote:
The kinds of debuggers that bypass that are used, on Windows, mainly by blackhats wanting to break software copy protection. |
Quote:
|
When I worked at (big computer place) we used debug to get into all sorts of stuff. It was still a great tool even into much later OS's. Debug really could get into almost any part of the system that few other apps could. I know of no linux app or way to get to some of the stuff.
|
All times are GMT -5. The time now is 10:57 PM. |