Re: Iczelion's tutorials revisited.

JGCASEY wrote:

.... 
Its been six years since I last used assembler so I
am most likely a little bit rusty. By "local" variables
on the stack I assume something like this?


Pretty much, yeah...

push bp
mov  bp,sp

This is enough to cover parameters passed on the stack. For "local"/"automatic" variables, we also need to subtract something from (e)sp - so we can push/pop without overwriting our variables.

sub (e)sp, number of local variables * size of variable

Normally, "size" would be two (bytes) for 16-bit code, and 4 for 32-bit code. IOW, the amount to subtract is the number of *bytes* taken up by local variables, even though they're probably mostly dwords. It's okay to have byte or word variables on the stack. If you come out with an "odd" number, you want to realign the stack,,,

and (e)sp, -4

You might want a larger alignment than this - if you're using 64- or 128-bit variables, for example.

.. then you use [bp + displacement]
to access the variables,

Yeah. [(e)bp + displacement] for the parameters, [(e)bp - displacement] for local variables, actually.

then exit with, 

First, we want to restore (e)sp to its original value:

mov (e)sp, (e)bp

This has the effect of "freeing" the local variables (this is why C calls this "automatic" storage). Needless to say, we don't want to alter (e)bp in the interim!!! In 16-bit code, [sp] isn't a valid addressing mode, but in 32-bit code, we *can* do [esp + displacement], so we *can* access parameters and locals that way. The "displacement" of a particular variable will change as we push/pop, so it's a PITA to keep track of, but it frees up ebp to use as a "general purpose" register, which is sometimes worthwhile.

pop bp
ret 4    ;remove 4 or whatever number from stack.

Whether it's "ret number_of_bytes" or just "ret" depends on the calling convention. The Windows API uses "stdcall" in which "callee cleans up stack" - the Windows functions end with "ret N". The C calling convention expects "caller cleans up stack" - the C functions end with just "ret". We need to know which we're dealing with!

Another issue is the "Intel ABI" (Application Binary Interface). Personally, I think it's a misleading name, since the hardware doesn't give a damn, but that's what it's called. Functions are allowed to trash certain registers, but are expected to return others the same way we found 'em. Registers that must be saved/restored if they're altered are ebx, esi, edi, ebp, and of course esp. The return value is normally in eax, maybe edx:eax - ecx is "scratch". Being an old dos-head, I'm used to using (e)cx as a "counter", and it annoys me that calling libc or the Windows API is allowed to trash it, but that's life...

In your *own* routines, you can do it any way you like (more "maintainable" if you're consistant), but if you're calling Windows you can expect that behavior, and if Windows is calling you (your WndProc, for example), then your routine has to obey these rules.

.... 
However I couldn't find
the "teach yourself Window Assembler programming
in 21 days" book :)

"Windows Assembly for Dummies" is right there on the bookshelf next to "Military Intelligence" and "Jumbo Shrimp" :)

Betov makes a good point that you don't really "learn" the entire Windows API. You need to learn how to navigate the documentation and *find* the API(s) you need. I suppose this gets easier with practice. I've spent *no* time with Windows documentation, so the clock hasn't even started ticking for me :)

....
So what kind of programs do you write these days?

"Hello World" for Linux, mostly - not literally "Hello World", but nothing too advanced. I suppose I'm "learning" the Linux API, a little bit at a time.

.... 
I have already got as far as "processing" an image
using the QuickCam in dos and in a VC++ shell with
a LogiTech webcam.

That should be a good start - at least you'll know what to do with the camera.

It is the fairly simple API
stuff I have to get my head around.

There must be some kind of "Quick Start" document - "The Dozen Most Frequently Used APIs", or "21 APIs in 21 Days", or something. If there isn't, perhaps there should be. I *thought* that's more or less what Iczelion's tuts did...

The VC++ shell
was written using the MFC Wizard by someone else
not willing to show me how it was done.

That'd be "OOP", I guess - where "information hiding" is condidered a *good* thing (!). Perhaps *not* a good place to start if you want to learn to do it yourself...

When I saw the FASM example I thought cool, I
wonder how hard that would be?


Well, it doesn't look too bad. Can you get it to "work", as far as it goes?

I think I mentioned that I sponged a USB camera, so that I could "follow along", maybe learn how to do it in Linux... When I went to plug it in, I find I haven't *got* a USB port on this machine! (thought I did...) So that's not going to be happening... unless I can figure out what happened to the parallel-port camera I *used* to have... I still find the project "interesting".

Best,
Frank
.

Relevant Pages

  • Re: SoftIce crashes with Windows 2000 SP4
    ... > WinDbg has all GUI windows like Memory, Registers, Locals, Call Stack etc. ...
    (microsoft.public.development.device.drivers)
  • Re: Do buffers always start with the lowest memory address being the first element?
    ... The C standard does not assume a downward-growing stack, ... C allows but does not require that the array produced ... There is nothing stopping an actual C compiler on real hardware ... How are static locals in main ...
    (comp.lang.c)
  • Re: Local variables controversial?
    ... >> source that get translated into stack items at ... yet familiar with a Forth that implements locals. ... >of having hardware that executes Forth efficiently. ... >So there is controversy... ...
    (comp.lang.forth)
  • Re: singe thread per connection
    ... process is about 2000, with the practical maximum somewhat lower, and performance suffering significantly before that. ... If you use a different stack size than the default, or don't actually allocate one OS thread per Java thread, then the actual limit would be different. ... But in Windows, both in the regular Win32 API and under .NET, there are i/o mechanisms that can be used that allow a single thread to service an arbitrarily large number of i/o tasks. ... This allows a program to create just enough threads to keep all the CPU cores busy, and the Windows scheduler knows to treat those threads specially so that if the only other runnable thread is one that would do the same thing that the currently running thread would do, the currently running thread is allowed to just keep running, rather than being preempted for no good reason. ...
    (comp.lang.java.programmer)
  • Re: What do I need
    ... Most free hosting packages do not include MS-SQL. ... Too bad none of your locals do ASP.NET and SQL! ... This is available as a feature of Windows 2000 Pro. ...
    (microsoft.public.dotnet.framework.webservices)