Having Problems With MACROS.ASM

[Robert Collins]

There appears to be a conflict with using MACROS.ASM and other include files. On several occasions I
have run into different problems, although at the time I did not know what was happening because I was
too new to understand some of the errors I was getting and of course I always assumed it was I that was
doing something wrong.

Now, I know that all those errors I used to get were caused by using the MACROS.ASM file and certain
other include files from the masm32\include library.

I don't remember the previous errors but I encountered one today so I know it is the MACROS.ASM file
that is causing the error.

I am trying to write a Winsock program and I need both the 'wsock32.inc' file and the MACROS.ASM file
but I am unable to have both in my project.

Another problem I have encountered with the MACROS.ASM file is that many of the macros in this file
are dependant of other macros. I tried pulling out the macro I was using in my program and put it in a
seperate local file but as it turns out it will not function by itself. I cannot look at the macro
and determine what are the other macros it is depending on.

I guess this is just one of those things that one must contend with and have someway to work around
these problems.

In this particular case it turns out that both files have the name 'select' in it. In the MACROS.ASM file
it is the select macro and in the wsock32.inc file it is the name of a function. Now I can get around
this problem but when it comes down to having too many such conflicting names it becomes a nightmare
to try and sort everything out.

This name conflicting problem brings up the following question. How does a person who creates macros
for the general use control names of labels in his macro so that they wont conflict with names used in
the program? Let's say I write a program and in this program I have hundreds of labels and now I go
and get a file that contains alot of macros that I now need to use and many of the macros also have the
same name labels used within the macro definitions. This results in a catastrophe. Now I have two
choises; 1) do not use the file of macros or 2) change all the conflicting labels in my program.     

[P1]

Robert,

It all boils down to your style of coding.  There is no right way or wrong way to solve this.  MASM is flexible enough to support many styles of coding.

A suggestion:  Typical practise would to start a MyProjectSupport.asm and include into your main MyProject.asm file.

Copy all of the Macros.asm file into it.  Then Modify the erroring Macro Name to something else like Select_M because it is just a name conflict.

Regards,  P1  :8)

[hutch--]

Robert,

Comment out the equate "select" in the macros.asm file. That solves the problem and it will be removed in the next version. The problem was reported by another member a couple of months ago.

It is part of the design of the macro support system to have macros calling other macros.

If you encounter problems that are NOT of a user nature, report them rather than whinge about them. With labels in macros, look up the usage of LOCAL within a macro and you will see that the assembler replaces each local with a unique value so you can use,

Code Select Expand


    LOCAL label


in as many macros as you like.

It just happens to be the case that learners are usually not in a position to redesign a system so we are not in a position to take much notice without a firm example to track the problem down.

Also note that the replacement MACROS.ASM file has already been posted in the MASM32 subforum that corrected the problem.

[Robert Collins]

Comment out the equate "select" in the macros.asm file.

If there are other projects and they use the 'select' macro would not commenting out the equ then cause the other projects to have errors?

[hutch--]

I originally put the "select" equate there for people who wanted some stylistic variation but as it clashes with an existing name in the winsock include, I have commented it out in the latest distribution of MACROS.ASM. You should not have any problems with that name clash using the most current version posted in the MASM32 subforum.

[donkey]

Perhaps use a conditional compile on the select label, not sure if this is the correct MASM syntax but...

IFNDEF select
    select equ <someequate>
ENDIF

That way it will only equate it if you haven't already used it for something else.