right on Sven... thanks for the info.

and Ernie... yeah, i can definitely see the merits of doing it that way... in a real "tryin to get this program to work" environment. As it is I'm still very much at a "hey... whats THAT button do?" stage :P. But i'll be sure to keep that in mind. Btw, isn't that what that dbgwin app is for? I was poken around the BIN directory of Hutch's MASM32 package, and noticed it.
Posted on 2002-02-19 17:52:24 by TheGreatTriscuit
A debugger and an intel manual. Read about the opcodes, trace
through your code and see how memory, flags and registers are
affected by the instructions. Then a lot of playing around. That's a
good way to get more familiar with the machine.

As for debugging... it depends very much on your problems. printf
or messagebox tracing can be good and sufficient a lot of the time.
Debug-time ASSERTs can be extremely useful (checks that only
produce code in debug builds - if used correctly they can help very
quickly track down that error that never occurs because the API
call can't fail ;)). Symbolic debugging with watches that can handle
complicated expressions and let you view how your data changes
realtime can be a real lifesaver. But this is not really on the topic
of this thread and probably more suited for another thread...
might be interesting to see what tips and techniques other people
Posted on 2002-02-19 18:02:30 by f0dder
We a talking here of learning basics of machine work by
a man who is a beginner.
I was a beginner myself (the dumbest one) and the way
I suggest is the best for learning machine basics - I learn
it from moths of painfull expirience.
Iczelion tutors will teach him how to write programms for Win32
and never by itselve how to manage machine control,
they 99 % time call for other proc to do it.
About manuals.
They need to be learnt but they are NOT ENOUGH to learn
anything about machin work.
Here is usually three way to learn
1. Listen or read about it
2. Watch it in reality.
3. Try and play with it.

While usually people limited by the first, 2nd and 3d are proved
to be the best.

For example - you need to learn and memorize well
how some MMX commands work.
What you do? Just read about it?
There are a lot groun people, all passed math learning,
my last expirements showed that for most of them math
exersizes of 5th grade was too hard to solve.

What you do write a special programm to watch how those
MMX commands works?
How you can write it if are not sure what it does?
If reading wasn't enough to get it?
If you have fast loaded debuger you just type this
command - wath what it does, type it again with different
opeands - whatch again, read again, type again, watch and
in few minutes, if not seconds you'll get fool picture you could have not understand at all without it, and could have left it forever 'cause just reading can give you impression that it is too
hard for you to understand.
OK I've stopped my propoganda :)
If nobody want it - I wash my hands :)
Posted on 2002-02-19 18:19:39 by The Svin
right on Sven... thanks for the info

You are most wellcome.
Let me know when you set a debugger, I'll write
a few simple lessons \ exercizes on basics about how
easy to learn JCC and flags using debugger.
Posted on 2002-02-19 18:47:43 by The Svin
yeah, i've got OllyDbg running and i'm fiddlin with that. (btw, i've gotta agree with what you said about the tutorials to an extent. They DO tend to gloss over some stuff. But i've seen much worse)

And sorry if i'm slow to respond, I tend to wander off and go do other stuff every once in a while :P
Posted on 2002-02-19 19:28:17 by TheGreatTriscuit
What OS do you use?
Most important Key to trane (speed up you work signicantly)
F8 step, F7 trace, F2 (set remove brake point),alt-x - exit,
alt-F10 - context menu.

I'll shortly write very simple exersizes in ~ 10 exers in block with
Untill it - set fast loading into debug (I most important thing in the
begining) you need to be able after writing couple instruction to compile and load them easily in a second otherwise you most of
time will waste you time on needless actions.

Don't write full progs to look how something works - set one
test project, and just replace instruction in code section with new

on the right you can see opcode like
$+21 55 PUSH EBP
$+24 . 83C4 F8 ADD ESP,-8
$+27 . 53 PUSH EBX
$+28 . 56 PUSH ESI
$+29 . 57 PUSH EDI

you can look up this opcode and for reason to stop being
afraid of machine code write this opcode directly as db data
for example you can write
mov eax,ebx
add eax,ecx
compile, look at debug and you'll see

now you can replace code in source with
db 8BC3h
db 03C1h
compile again - and you'll see that debugger recognize it as
the same
mov eax,ebx
add eax,ecx
so their is nothing to be afraid of machine code, just numbers
meaning code of simple instruction, but you should try it at least
once to get this expirience and to know it for sure.
In proctice looking in machine opcode is at least usefull to remind
you about commands size (usefull for code size optimizations)
You can type instructions directly in debugger
press space and type instructions.
But typing instruction assume actually replacing existing instructions, so you may fill in source with some lot of fullish
instruction that you then can replace in debugger.
for example type in source
rept 256
mov eax,eax
call ExitProcess
if forsce asm to write program with 256 mov eax,eax instructions
wich you can replace with different instructions right in debugger.

write some HLL constructions like
.IF eax == 819 || ecx < eax
mov ecx,ecx
compile and carifully analize in debugger what code actually compiler made from it so the machine can handle the code with given conditions.

Good luck.
Until next time.
Posted on 2002-02-20 19:29:25 by The Svin