Have anyone worked through these books?
Hi,
I was wondering if anyone had understood and worked through these books:
1/ Undocumented DOS 2ed A. Schulman 1993
2/ Root Kit Arsenal - 2009 B.Blunden
Is the discussion on these books, code/concepts, banned here?
Should I go somewhere else? Any recommendations?
Regards,
Craig
I was wondering if anyone had understood and worked through these books:
1/ Undocumented DOS 2ed A. Schulman 1993
2/ Root Kit Arsenal - 2009 B.Blunden
Is the discussion on these books, code/concepts, banned here?
Should I go somewhere else? Any recommendations?
Regards,
Craig
Comments
I just recently completed a project involving the use of such stuff, That's mostly basic stuff in that book. so if you study very hard and do A LOT of examples while learning you might get to the point you find you like it. I read it like I was born to read it. Natural I am doing something right now that I don't think has ever been done before I am now currently writing Windows programs in Windows 3.0 and 3.1 in complete Assembly Language. and I'm having a Blast doing it!
So if you work at it hard you'll get there if you have the drive to do so!
I have found that most people like playing with DOS and Win 3.1, but that's it. Very few want to code in that environment.
There are a few ideas that I would like to code, but the learning curve is quite steep.
The other push for me is to *really* understand BSOD's the knowledge needs to be quite deep. Sure you can guess on patterns and commands, but to really know...well that's the goal.
A lot of the concepts in DOS ended up in Windows, sure there is new stuff, but if you understand past, I think you can understand the new tech in Windows. For example the PSP became the PDB in Win 3.1.
I have Zero aspiration for anything other than knowledge. I subscribe to the theory of "To understand and to fix something it is best to learn how to break it."
I use Ms-Dos 6.22 extensively, but mostly with "C" and C++. I love Assembler, and I know quite a few: 8080/8085/8086/80386, PDP-11/VAX/RISC (Mips), Atmel/Microchip/RCA1802, but the last thing I want to do is program in Assembler, and I need good reasons for doing that.
I don't know the books. But are we talking Assembler, which is quite simple, or are we talking concepts? If we are talking concepts, meaning how to achieve certain functionalities, then I suggest: a) Microsoft Encyclopaedia (Ms-Dos 3), a 1500+ pages book that covers divers topics, with Assembler programs, or b) program in "C" and use Assembler for and limited to functions, as I did in a 1990 course I held at a community college; for instance, use "C" to enter two integers (as program arguments) and Assembler function to compute the sum/difference/produkt/quotient/remainder. The key learning element here is argument passing and returning between "C" and Assembler and signalling errors.
Progress to floats/strings/string functions. Progress to obtaining information that is otherwise unavailable. Progress to checking information structures, for example .OBJ/.EXE structure, partition table (including extended partitions), dynamically allocated memory. This should keep you occupied for several decades.
Ahoi (sailor's greetings),
Joachim
ps: feel free to contact me, if you need help
you can program real machines, or you can program simulators.
If you really, really want to understand machine instructions, I recommend mips R3000: Patterson/Hennessy, Sweetman and QtSpim or any other simulator (on gxemul run several unix variants), all available either inexpensively second hand or free down load.
I was paricularily impressed by Patterson/Hennessy: they took a close look at the iNTEL 8086 and remedied everything that made the 8086 slow - cache & pipeline are part of the processor, not add-ons, which leads to mindboggeling results. The pipeline nevers stalls (mips=microproccesor whithout interlocking processor states). So, after a load into a register, you cannot use this register in the next instruction, you have to wait one instruction (load hazard). You can fill this gap with a no operation, or you can rearrange your instructions, so another instruction can use this delay slot. That means, you load the last argument register AFTER the jump to the subroutine. Equivalently, you clear the priviledged state bit AFTER the return from interrupt (while still in the priviledged state. Brilliant, but a lot of programers feel uncomfortable with this, so they rather use ARMs instead.
The major intention of Patterson/Hennessy is processor design, but they take you through machine instruction examples extensively, so you approach your goal from the other side.
Ahoi,
Joachim