mov hInstance, rv(GetModuleHandle, NULL)

[hutch--]

I chuckle at the rhetoric surrounding the use of macros, the distinction is whether you are using a MACRO assembler or not, if you are, why cripple it with 1980s assumptions. I am out of the generation that coded assembler like an assembler dump in the old days and occasionally i still do for private code but with the last couple of projects I did in MASM including QE 4.0 I extensively used the masm32 library and macros because of the sheer complexity of the code and wrote a pile of new ones for it as well.

When you have the option of macros like MASM and now JWASM, you in fact choose where you use them as is appropriate to the task being performed, MASM's .IF notation is useful enough but I regularly use the SWITCH notation from the macros and its variant SWITCH$ as it allows faster coding and more flexible coding which is consistent with a MACRO assembler.

Its well and good to talk about coding in bare mnemonics and most of the old fellas have done so for years but there is more to programming than the barest code possible, sheer complexity which is often not all that speed related is better handled with properly tailored macros as it improves the logic and readability of the code. While many high level languages ape this capacity with their prebuilt macros that are part of the language, a MACRO assembler allows you to make a capacity that does exactly what you want and this makes it a more flexible and more powerful tool in many instances than a compiler.

I originally wrote QE in a basic compiler many years ago because of its excellent inline assembler but after having written 3 versions from scratch in basic, the sheer advantages in writing it in MASM justified doing it that way and that gave me the range I needed from some high level code to very low level code and this was possible because of having a developed library, macro system and the capacity to write a number of specialised macros for very complex internal components of the project.

[sinsi]

I think the problem is that you, hutch, have an intimate knowledge of the macros (obviously heh).
Let's face it, your macros.inc is 117K, that's a lot of code to wade through.
I think of masm32 (using only macros) as being a bit like basic/vb/delphi, lots of assignments and then lots of api calls, all hidden.
(not a criticism of masm32).

The macros I use are usually the print ones, since someone here is obsessed with LAMPs  :bg

[Rockoon]

Its not supposed to be all or nothing, hutch.

Using macros is fine. Over-using them isn't.

The same is true of every paradigm be it macros, oop, garbage collection, templates, and so on.

If you cannot get a grip on what state the underlying machine is in by looking at code in front of you, then quite frankly you no longer have good code. There is only so much the human mind can handle at one time. If the state of the machine is so unimportant that you can get away with being oblivious to it, then I dare say that assembler is the wrong tool for the job in front of you.

High level languages get a pass because the state of the machine isn't important. Instead its the state of the abstract machine thats important, and that abstract machine is greatly simplified where modifications to this simple state are intuitive, standardized, and enforced.

We all have our reasons for writing in assembly but they mainly boil down to a small list:

Performance
Size
Control
Necessity

Most all those macros in a monolithic macro include file do not enhance performance or size, usualy they degrade both because they have to be generic. Nor do you maintain control when you are using them since the author of that include file is the one actualy in control when you use it, and its so damn large its hard to even tell if you make a change somewhere that it wont break something else in it because all sense of dependency is lost because of how monolithic it is.

This leaves necessity, and I think most of us do not fall into that group, but I think those that do also by necessity cannot use the vast majority of such include files because they are programming for ring0 or a different OS.


I havent a clue what side effects or performance characteristics a given macro in the monolith might have, and if i'm going to bother to take the time to investigate then I might as well skip it and do without it. At least when I do without it, a month from now when I'm performing debugging/maintenance/optimization I wont again be wondering what side effects or performance characteristics that same macro might have.

[hutch--]

> Using macros is fine. Over-using them isn't.

The problem here is that over and underuse varies with the individual programmer. If someone never learnt the .IF notation it would look strange to them if they always coded in pure mnemonics yet the programmer that uses code like.

Code Select Expand


print "Howdy Folks",13,10


has not thrown anything away, it just saves shovelling through console API calls just to dump something on the screen as a result. Macros are a form of programmer controlled automation and at least the ones in the masm32 project are documented and the source is available. It means you can just use them, use them as reference or just write your own if you don't want to code the area manually.

The main factor is for a person who does not want to learn their own or someone elses macros, they can always write the code manually but that type of code was what made assembler the laughing stock of programming 10 years ago, now thwey whinge but they don't laugh anymore.  :bg