Does anyone know where I can find a SIMPLE tutorial to get me going in MASM32. Iczelion's tuts get far too complex, too quickly.

My past experience in assembler has been with Masm 6.11 in dos, and I am now getting lost in the
wretched gobbledegook that creates and deals with windows and dialogs. I realize that this is the essence of "windows" programming, but I am finding that the tutorials out there are not helping me connect code that "does the work" to the code that "makes the windows".

I have a set of subroutines that performs a series of calculations that result in a 32 bit numerical value in the ECX register. All I need to do is display these values on the screen, but I am having one hell of a time figuring out how to do it. Any help would be appreciated.

Moggie
Posted on 2004-01-01 21:10:55 by Moggie
Maybe you'll find the art of assembly language useful. It teaches assembly with console programs only so maybe that will make it easier for you to learn.

Art of Assembly Language:
http://webster.cs.ucr.edu/AoA.html
Posted on 2004-01-01 21:33:12 by Odyssey
My friend,
If Iczelion's tutorial are way too complicated for you :grin:
Then ask me :P

But are you realy trying to learn here? let's assume you are:

Basically Windows is event based programming and you react to user or os generated events that are out of your control. No more "simple" linear programming.

The events come in the form of Messages(aka parameters) to you WndProc procedure. You just sit there and wait until a message comes and when it does you act acordingly!

So after you have created your window you can paint on it's screen (aka GDI Device context) during the WM_PAINT message that is sent to you by Windows whenever it is necesarry... Please obeserve the BeginPaint and EndPaint requirements. if you want to paint periodically then you should create a timer (for a start) and react to WM_timer messages, etc etc

Ask more questions here as you go steep by steep and/or by email to me...

However Icz's tutorials are so damn good and easy... that it makes me wonder
Posted on 2004-01-01 21:41:11 by BogdanOntanu
I think you are under the control of the messages, because you know what messages you will handle ;)

Even if you are not under the control of the order, but you are under the control of how to manipulate they, even, you can force a secuence, for example dont pain the graphic if the user is not pressed other button (start), or dont have the suficient information or bad formed info in your inputs, like you will recibe a email or some.

In some way is lenear programming, I know you know, because react to a message like WN_PAINT you will always react to it and is like a subroutine if you whant, is a part of code that is suposed to handle this special event, and like a line, if you break some in this, for example a bad assumption, you can get the next step corerct...

a -> b -> c -> d that are the step for a specific reaction or message, but for example, a bad input in the second step will cause that b become bX, where this X is a bad for the flow of the program, because it will cause that the next step, if the anterior was wrong (bX) be bad executed, yes in some way is linear, also you can have multy threads. but always tyou have a base thread... there is where your execution of your exe go normally.....

for get the d step executed correctly the anteriors should be aserted, if a step causes some wrong, htat will cause like a chain... ;)


I will like to talk more, but I dont have time now... :(

-----------------------------
By the way, you react to only the messages that you really whant to handle, some others that are passed to you, specially window events are handled automatically by other functions....

Have a nice day or night.
Posted on 2004-01-01 22:04:01 by rea
hehe i felt like this too when i started reading them that it goes too complicated too fast but that was past feeling but let me say three cheers to such a magnificient effort it rocks and rocks the hell out of any tuts that i have ever met

probably iczelion must have introduced the dialogboxparm first in series
to tut2 instead of 10 and made the people understand the message handling loop
so that windows coding comes to them naturally

but
mov wc.blah,BLAH
push blah
pop wc.blah1
register classex
takes the wind out of learning and seems to frighten the hell out of any one who is new

my first success was with DialogBoxParamA and one small button which popped up a message box saying hello world ;)
Posted on 2004-01-02 05:45:06 by bluffer
here is a tiny "Hello Console" application made with some nice code found on this board :)


so if you could fit your old code into this then you're almost there :P
Posted on 2004-01-02 08:28:50 by Hiroshimator
The main problem maybe is how you understand now asm.

But you say tht you know 16 bit code, then you know what the stack is and if grow up or down :).


Then the problem become with the windows programming.


I will share some whit you that help me out understanding win32 and others.

Here two main thigs that help me in understand it:

1) A DOS program for draw icons. (it switch from 16x16 to 32x32)
2) This follow 1, after that experience I was learning java, and I question how the objects are connected by events.


From 1 I learn some inline asm (I only copy and paste thing) the functions for the graphics (2) ;) (I think that bogdan know well this), think in this..., when you press a button of the mouse, it send a lot of in this case interruptions, then I have my routine for handle they, I get x, y and the button pressed, now I say is inside (1*) my progie :) for a little ;).

But before I do the progie, i do some interesting graphical drafts (I think), In that time I was thinking in several windows that I can move all the screen, but the buttons and other inside of the window, need move with he(5), and the root window was the background of the screen, then you know that the program will be closed if you dont have root, then following the three, you have ordered (7). Other interesting thing, was the fordware of the events(9)? you know what button was, but how you say to it that do some?, because was a DOS program, that was a switch ;) and in that moment I know what to do in that moment or event (11)., parent, etc. (You see a three here??? :) )



OK, like you see handle events is in some way hard, if you dont know.

For windows programming, the major part of this is done already:

1 and 1* painting (obtaining a device or by reaction to WM_PAINT or some other)

2 The messages of the cursor are formatted by the OS (you have WM_LMOUSEDOWN, WN_R.. MIDLE,..)

3 Know inside of what control or window (in the windows jargon) is done in major part by the OS, then OS only forward the messages to the parent window (main window) and you normally need a switch for check the message that the OS send you, and check what of your child was agains the message information.

4 Here is some interesting, I think windows have a three, but when you move some in the screen (right, left, up, down, Z-order), probably they modificate the three structure for up or down the screen in say Z order, but they not modify each x, y coordinate of the child, they only modificate the main window coordinates (for the paint start here), because each window is like a screen, then they can have a x,y starting at up-left corner, and relative position to is own parent window.

5 The three structure is important, because when you create a window the OS give a identifier, and when do the recursive check for find inside what coordinate was the event, he Inmediate know what ID is this, and sure know the main window.

6 The order of the graphical elements is done because 4, they only move the x, y coordinate of the main window, but his child have a relative position to this screen that is a window. Lets say that you have ratio buttons, inside a panel, then I think the OS have a structure some where like this:


mainWindow[102030, 300, 100, 100, 100, 1, 0]
+Menu[1234, 10, 10, 20, 100, 0, 0]
+SubMenu1[ 1235, 30, 10, 10, 100, 0, 0]
+Item[1236, 0, 0, 100, 100, 1, 0]
+panel[111, 100, 100, 200, 200, 0, 0]
+Item1[112, 10, 10, 100, 10, 0, 0]
+Item2[113, 10, 20, 100, 10, 0, 0]

, for the main window x and y are real coordinates in the screen, but for the child, they have a relative position, when the OS find say the rectangle (in a recursive check or some), for example find that the rectangle is in Item1, it see that the ID is 112, and send a message to the main window with ID = 102030, with the corresponding message, .... here can follow with 8

7 The OS have a interesting algo that work for see if a window is showed or not, and if need or not need repaint itself, and only validate specific rectangles, all, or a specific rectangle of a window. Not paint all the structure, even if the window is not showed, like I was thinking.

8 Forward of events ;), when you create a window, and sure put some where in the three (of the OS), the OS know other things that is responsible to know, like the position, the color, if is showed, the OS dont know how will react a window (if the window will show or hide in front of this event), but know what to call if a event (any event) is over this window, is called the proc of the window, a window have too a list of the events that need handle, when finally the OS know what is the ID, position of the event, it send a message, when the message is recibed by the main window, is forwared to the specific child, when emter the event to the child, is own window proc is called, and when he completes it respond with other event, lets say RATIOBUTTON_SELECTED. Sure maybe is other way, like when the OS know the ID, know at that moment the class of the window, and call directly it, and this child window, send the message that need send, a message if cant handle or a message if was handled.

9 When the window proc of the ratio button is called it send a message saying what change or other to the main window, then if for example you have three choices: white, blue, red, green :P, then a click over green, a call by the OS to the ratio button proc, he paint itself a black circle (selected) and send a message in answer to the phater via some sender (OS or a direct message), with the info of his actual ID, the message LB_SELECTED and other... dunno, then because a message was sended to the main window, is called his own window proc, in this say, giveMe the ID of the window, give me the message, if is white, pain the screen black, if is blue paint it brown, if is green count 5 sec and close the window, and you see, for paint, close, etc more events sended, recibed, acted over they, forwarded replyes (exist reply to all?, and forward), etc.

10 We are showed that the correct window proc will be called, and if necessary it will answer, with a answer to the OS (like close me.. and shure all my childs) or the main window, also maybe to other window that is not the same app.


11 ooo, nice, here you have some strategyes, for change the behaviour of a window, you can change the window proc, because what??, because the OS only know the start of the function that will be called, then simple, you can overwrite it, but save the anterior proc, in this way, you can overwrite how a window react or not....., also there exist others ways.



You understand all that I write here???

I can give a resume ;)

Hope this help you.


Have a nice day or night.
Posted on 2004-01-02 11:03:29 by rea
Due to numerous requests, I'm posting a series of tutorials geared towards total newbs.
You can find it @ http://homer.ultrano.com
I'll be adding to it as I go, and seek feedback.
If anything is unclear, or you feel I have missed some important things or placed undue emphasis on things, or not enough emphasis, or whatever, please let me know :)
Posted on 2004-03-06 21:48:42 by Homer
Well, no feedback from the natives yet, but nevermind.
The kids outside this board seem happy with my humble offering, and I have had no negative feedback sofar :)
Posted on 2004-03-07 23:52:15 by Homer