Currently, if you want to include windows headers & libraries, you write the following:
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
include \masm32\include\gdi32.inc
includelib \masm32\include\kernel32.lib
includelib \masm32\include\user32.lib
includelib \masm32\include\gdi32.lib
Also, header files (at least the ones in masm) don't prevent double inclusion.
So, I'd like to propose the following way to use header files.
Including libraries:
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
include \masm32\include\gdi32.inc
Header files: (ex. kernel32.inc)
ifndef KERNEL32_INC
KERNEL32_INC equ <KERNEL32_INC>
includelib kernel32.lib
... original file ...
endif
Also, the libraries should be in the LIB path, so you can access them immediately with their name (without path). This doesn't make a difference when writing in pure assembly, but if you start making static libraries which depend on other static libraries, there is a pitfall which I encounter regularly. Simply said, it's been more than once that the C++ compiler couldn't find \masm32\lib\kernel32.lib .
It's just an idea that came up in mind. Tell me if you like it or not.
Stan,
You must have an old version of the includes, they have had a duplicate lock for some time now.
; ===========================================
; certidl.inc copyright MASM32 1998 - 2005
; ===========================================
IFNDEF CERTIDL_INC
CERTIDL_INC equ <1>
CertServerRequest PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD
MIDL_user_allocate PROTO :DWORD
MIDL_user_free PROTO :DWORD
ELSE
echo -----------------------------------------
echo WARNING Duplicate include file certidl.inc
echo -----------------------------------------
ENDIF
Ah, I see. :red
I should wipe those old masm versions off my hard disk.
What do you think of the includelib idea?
Hello,
Something useful
ToutEnMasm
Quote
LIB user32,gdi32,kernel32,shell32,comctl32,comdlg32,masm32,ole32,oleaut32
Quote
; ---------------------------------------------------
; return an arguments specified in "num" from a macro
; argument list or "-1" if the number is out of range
; ---------------------------------------------------
getarg MACRO num:REQ,args:VARARG
LOCAL cnt, txt
cnt = 0
FOR arg, <args>
cnt = cnt + 1
IF cnt EQ num
txt TEXTEQU <arg> ;; set "txt" to content of arg num
EXITM
ENDIF
ENDM
IFNDEF txt
txt TEXTEQU <-1> ;; return -1 if num out of range
ENDIF
EXITM txt
ENDM
; -----------------------------------------------
; count the number of arguments passed to a macro
; This is a slightly modified 1990 MASM 6.0 macro
; -----------------------------------------------
argcount MACRO args:VARARG
LOCAL cnt
cnt = 0
FOR item, <args>
cnt = cnt + 1
ENDM
EXITM %cnt ;; return as a number
ENDM
LIB MACRO args:VARARG
LOCAL acnt,buffer,var,boucle,buf1
acnt = argcount(args) ;macro argcount , nb d'arguments
var = 1
:boucle
buffer equ getarg(var,args) ;macro getarg
buf1 CATSTR <include \masm32\include\>,buffer,<.inc>
buf1
buf1 CATSTR <includelib \masm32\lib\>,buffer,<.lib>
buf1
var = var + 1
IF var LE acnt
goto boucle
ENDIF
ENDM
ToutEnMasm,
That's a nice idea :U
I like Stan's idea about putting the includelib INSIDE the include file. :U Why ever hassle with having to worry about it.
... and if you drive this idea to maximum, you got this ...
;windows.inc file in \masm32\include
....
IFNDEF _wininc_
_wininc_ equ <1>
... definitions as given inside this file ...
; --- at the end of windows.inc, insert this :
; --- coder: toutenmasm
; ---------------------------------------------------
; return an arguments specified in "num" from a macro
; argument list or "-1" if the number is out of range
; ---------------------------------------------------
getarg MACRO num:REQ,args:VARARG
LOCAL cnt, txt
cnt = 0
FOR arg, <args>
cnt = cnt + 1
IF cnt EQ num
txt TEXTEQU <arg> ;; set "txt" to content of arg num
EXITM
ENDIF
ENDM
IFNDEF txt
txt TEXTEQU <-1> ;; return -1 if num out of range
ENDIF
EXITM txt
ENDM
; -----------------------------------------------
; count the number of arguments passed to a macro
; This is a slightly modified 1990 MASM 6.0 macro
; -----------------------------------------------
argcount MACRO args:VARARG
LOCAL cnt
cnt = 0
FOR item, <args>
cnt = cnt + 1
ENDM
EXITM %cnt ;; return as a number
ENDM
LIB MACRO args:VARARG
LOCAL acnt,buffer,var,boucle,buf1
acnt = argcount(args) ;macro argcount , nb d'arguments
var = 1
:boucle
buffer equ getarg(var,args) ;macro getarg
buf1 CATSTR <include >,buffer,<.inc> ; MODIFIED !!
buf1
buf1 CATSTR <includelib >,buffer,<.lib> ; MODIFIED !!
buf1
var = var + 1
IF var LE acnt
goto boucle
ENDIF
ENDM
; simple add the files you need ...
LIB user32,gdi32,kernel32,shell32,comctl32,comdlg32,masm32,ole32,oleaut32
ELSE
echo ------------------------------------------
echo WARNING Duplicate include file windows.inc
echo ------------------------------------------
ENDIF
Now it's enough to inlude "windows.inc" to your source, the rest is included by the patch ...
looks like a great idea
my alternate includes, excludes gdi lib and makes a smaller .exe
Quote from: daydreamer on December 07, 2006, 05:02:13 PM
excludes gdi lib and makes a smaller .exe
Doesn't make a difference if you don't use it. The linker just doesn't include it.
Compile times can be reduced if you leave out WINDOWS.INC, though the amount of functionality lost is considerable and generally not worth it.
Cheers,
Zooba :U
Guys,
All of this stuff is viable if you can get it to work properly but what is not viable is breaking some massive number of already written programs that use the existing system of a matching include and library file. It may be an extra typing issue but its not a performance issue and the other factor is the association between an include file and a matching library that is lost with burying the two together.
My alternate include style is:
include \masm32\ultrano\bank\base.inc
start:
print "hello world"
invoke ExitProcess,0
end start
Here all usually-used includes/libs and OOP objects and my custom libs and macros get included. This code compiles in less than 200ms - so I see no point in trying to avoid windows.inc .
Instead of modifying the standardized contents of the masm32 package (like windows.inc in this case), it's much better to make an include-file to contain your custom macros.
Hi Hucth,
I cannot understand why a simple macro simplifying the typing breaks the assocation between the include file and the import library. Is there any reason?
Hello,
Quote
I cannot understand why a simple macro simplifying the typing breaks the assocation between the include file and the import library. Is there any reason?
I agree with that.
If the macros are included in windows.inc ,old codes couldn't be damage with that because ...they don't use them.
ToutEnMasm
ToutenMasm,
You did a nice job with those macros! They are a little long, but they appear to be dependable.
Paul
Something similar-
uselibx macro args:VARARG
for arg,<args>
include arg.inc
includelib arg.lib
endm
EndM
uselibx user32,kernel32,shell32,comctl32,comdlg32,gdi32
Hello,
Hello,
I become red with all this compliments,But i am not the only one that wrote it.
It's a work that had be done here in a post.Hutch made a good work to solve a bug with it.
After some tests on all the many macros that were posted,I only find the good one that accept the multiline statements and improve it in my code.
If my memorie is good,seems you have contributed also.
The macro can be shorter .... with a bug
If you use FOR ... ,these products an internal error when the include file have macros in it.
To include in windows.inc and save backword compatibility a IFNDEF argcount made the JOB
ToutEnMasm
There is also the uselib macro in the macros.inc (masm32 package)
Improvements can made a choice
ToutEnmasm
Quote
comment * -------------------------------------------------
The "uselib" macro allows names that are used for
both include files and library file to be used in a
list without extensions. Note the following order
of include files where WINDOWS.INC should be
included first then the main macro file BEFORE this
macro is called.
include \masm32\include\windows.inc
include \masm32\macros\macros.asm
uselib masm32,gdi32,user32,kernel32,Comctl32,comdlg32,shell32,oleaut32,msvcrt
------------------------------------------------- *
uselib MACRO args:VARARG
LOCAL acnt,buffer,var,lbl,libb,incc,buf1,buf2
acnt = argcount(args)
incc equ <include \masm32\include\>
libb equ <includelib \masm32\lib\>
var = 1
:lbl
buffer equ getarg(var,args)
buf1 equ <>
buf1 CATSTR buf1,incc,buffer,<.inc>
buf1
;; % echo buf1
buf2 equ <>
buf2 CATSTR buf2,libb,buffer,<.lib>
buf2
;; % echo buf2
var = var + 1
IF var LE acnt
goto lbl
ENDIF
ENDM
; -----------------------------------------------
Quote from: ToutEnMasm on December 08, 2006, 03:05:39 PM
If you use FOR ... ,these products an internal error when the include file have macros in it.
I'm afraid I don't understand. Can you give an example please?
Since that is so similar to the one in GeneSys, I will post ours, also.
In Macros.asm:
uselib MACRO namelist:VARARG
FOR item, <namelist>
include \GeneSys\include\item.inc
includelib \GeneSys\lib\item.lib
ENDM
ENDM
In Windows.inc:
use_std_SDK MACRO
include \GeneSys\macros\macros.asm
uselib kernel32,user32,gdi32,shell32,comctl32,comdlg32,msvcrt,shlwapi,advapi32,GeneSys
ENDM
In a project:
include \GeneSys\include\windows.inc
use_std_SDK
ToutenMasm,
Quote
To include in windows.inc and save backword compatibility a IFNDEF argcount made the JOB
Hutch already has an IFNDEF test to ensure there will be no duplicates. Just make sue you put the new macro into windows.inc ahead of the ELSE statement near the end of the file. I have tested this for myself, also. I am no genious when it comes to macros (just get by, barely) but if the tests are okay then I am satisfied.
Thank you for this great idea.
Paul
For the "internal Error" with FOR ,follow this link
http://www.masm32.com/board/index.php?topic=2370.msg23924#msg23924
It's a message from ML.
This message is not generated with all the macros included in an include file.
Perhaps if someone is a best searcher than me ?.
ToutEnMasm
ToutenMasm,
I have searched all of the include files in the GeneSys Project. None of them contain any for loops, okay?
Paul
Okay Paul,
The link is only to remenber the problem and to take care of it.
I have pass some times before find it!.
ToutEnMasm
ToutenMasm,
Thank you for everything. You are a very thorough man and quite helpful.
Paul
Wow. I had some vague recollection of looking at this before but couldn't find anything. It's tough getting old :(
From memory the "uselib" macro in the macros file in masm32 was one of Paul's ideas. I think it works OK and it is useful for people who want to use it but I would still warn anyone against modifying the WINDOWS.INC file as the method I have for its maintainance has the entire file split up into about 30 seperate file which are joined in sequence for each modification. Its a particularly piggish file to modify and can come down around your ears with the "error count exceeds 100" message very easily.
What I would suggest if anyone needs to run a macro before the WINDOWS.INC file is to make an include file that has the macros first THEN call WINDOWS.INC and any libraries that are required after it. The simplified include file for masm32 "masm32rt.inc" is a reasonable model here and it allows a programming system designer to have a unique file that performs any specific customisation without interfering with the content of WINDOWS.INC.
It is not stubbornness that I will not change WINDOWS.INC but part of the original design of the MASM32 Project which intentionally countered the trend of calling a single include file that then called a whole range of file with buried include files that were very hard to find and even harder to edit. I am referring to the C/C++ model here of calling WINDOWS.H and leaving the rest to a set of conditional includes driven by varous IFDEF and similar statements.
By design the MASM32 Project requires symetrical include files and library files so that the programmer ALWAYS knows what is necesasary and what will work. When I first started the MASM32 project include files from a variety of different sources were all over the place like a mad women's **** (sewerage) and no-one could build anyone elses programs because of this incompatibility. Rejecting the C/C++ model and designing the symetrical include and library file system solved all of these problems and made assembler code written in MASM very reliable.