LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   General (https://www.linuxquestions.org/questions/general-10/)
-   -   DEBUG.EXE: the machine at your fingertips. (https://www.linuxquestions.org/questions/general-10/debug-exe-the-machine-at-your-fingertips-4175498215/)

stf92 03-14-2014 03:08 PM

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?

sundialsvcs 03-14-2014 04:22 PM

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.

stf92 03-14-2014 04:51 PM

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?

metaschima 03-14-2014 05:00 PM

Trying to see anywhere in memory would lead to a segfault, and thank goodness and protected mode for that.

stf92 03-14-2014 05:37 PM

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.

enorbet 03-15-2014 12:48 AM

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.

stf92 03-15-2014 01:39 AM

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!

enorbet 03-15-2014 02:55 AM

Quote:

Originally Posted by stf92 (Post 5134906)
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 I walked away with my 32-bit assembler. But I discovered it did not include the linker!

It's not just written in Assembly. It IS Assembly, or at least one iteration of it. MOV, ADD, SUB, JMP etc are all examples of Assembly Instructions. H E R E is a site with a list of free Assemblers and Linkers. Note that Linux gcc has some capability for linking assembly code but there are also really good, really free linkers for both 32bit and 64bit. It's nice that you got that version free but v8 is free at the above link, although NASM is probably a better choice for Linux. Even better, you already know all the basics from using Debug!

stf92 03-15-2014 04:39 AM

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.

dugan 03-15-2014 05:49 PM

Quote:

Originally Posted by stf92 (Post 5134748)
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.

Modern operating systems, as you acknowledge in your second paragraph, are designed specifically to not allow that. If this is the kind of programming you want to do, get a microprocessor or microcontroller. Or run FreeDOS, I guess.

The kinds of debuggers that bypass that are used, on Windows, mainly by blackhats wanting to break software copy protection.

stf92 03-15-2014 06:03 PM

Quote:

Originally Posted by dugan (Post 5135239)
Modern operating systems, as you acknowledge in your second paragraph, are designed specifically to not allow that. If this is the kind of programming you want to do, get a microprocessor or microcontroller. Or run FreeDOS, I guess.

The kinds of debuggers that bypass that are used, on Windows, mainly by blackhats wanting to break software copy protection.

Let me tell you, the revolution was initiated by the hardware, not the software. It was in the microprocessor field that protected mode was born. And, alas, a microcontroller is a very different thing from a microprocessor. This, is a CPU. The former, is only a computer altogether put in a single chip. And notice I say 'only'. I do not like microcontrollers, though it seems they will come to dominate the world.

jefro 03-15-2014 07:28 PM

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.