Hello everyone! This is my first post on the forum!

I have been playing with ASM since a couple days (but thought about it for a longer time), coming from a background of java and other similar languages such as c. I've always wondered how things worked behind the scene.

Anyway, I have started to get a pretty good feel into how to read ASM and understand more or less the different ways to write simple programs in Windows x84 system.

Here is my question: Let's say I write the HelloWorld example such as


From what I understand, WriteConsole is a macro (Or a function?) that does some code behind the scene to print some text to the terminal. In order to see what this function is actually doing, where do I have to go? I have found, in KERNEL32.INC, a signature that seems to tell the amount of parameters required in order to use WriteConsole, but I didn't manage to understand what is really does, or where to go from there.

Hopefully this makes sense

If you are originating from the high level world, it should be easy to understand.

But if this is your first programming language then you'll need to learn a couple of things first before you get to this part.

I have been programming in Java for the past 3 years and I've done a lot of c programming in University. So far, I haven't had much problems with ASM, it doesn't feel too different from the high level world (Of course there is still a lot to learn.).

After writing the OP, I've realized that I should probably look more into how macros work.

When you see invoke -- it calls a Win32 API function, so WriteConsole is not a macro. To see, what WriteConsole does -- load that code into debugger (I suggest OllyDbg) and once debugger stops at that line -- press F7 -- and debugger should STEP-INTO the function in question. However, I must say, that code there is just a set of calls to other functions in Windows Core.

Whoa, that's neat! Thanks.

As a general explanation, code like that is usually very OS dependent. I remember when I was getting into asm, I wanted to learn how to write the stuff to the console myself and do everything else at the most basic level, and I assume that's what you're after. The problem is that a lot of it can't be done so simply and a lot of it isn't as interesting and low-level as you might think. The actual implementation of WriteConsole is probably just a call to an API that implements an emulated terminal as just another window, which, like all windows, is drawn by the GUI compositor (thing that draws pixels for the GUI). You could probably get just as much information from debugging how a window is drawn.

To anyone who knows, can drivers be debugged? That would be an obvious prerequisite to seeing how the Windows driver draws the pixels. And even then, you'd probably just see a call to the GPU, which you can't debug.

The thing is, I tought it was the way everything was done in ASM. Anytime someone woul talk to me about ASM, it would seem like it was way too hard and useless. Then I started to talk to retired programmers and most of them would tell me they never programmed in any other language than ASM. This week, I found the book "Art of Assembly Language Programming and HLA" by
Randall Hyde so I'm starting to see for myself.

They're retired because they're old. They probably recommend Fortran, too. Don't listen to that, either. There used to be a lot of programming in asm (before HLLs were invented and widely used).That's not really the case anymore. It's just not productive enough to be used commercially without a REALLY good reason.

I look at it more as a hobby, something to learn because you value the knowledge itself, not because you expect to get a job doing it.

Yes drivers can be debugged but not the way you debug User mode apps.

The WinDDK comes with debugging tools for such purposes. WinDbg is one of the best debuggers too. It can do kernel mode(via ports) and User mode debugging.

Wait, invoke appears to be a macro:

is the same as:

Yes -- the same.

I'd recommend you download AMD Volume 3 (or Intel Volume 2) manual for a list of general instructions, as this will help you to disambiguate instructions from assembler directives and macros [as well as help you understand what happens in hardware]. You'll notice that some of these map to C operators e.g. shl is <<, not is ~.

> invoke AllocConsole

if you set subsystem to console you don't have to alloc it later

> I'd recommend you download AMD Volume 3 (or Intel Volume 2)

or the only volume on Intel 80386 (less instructions)