The MASM Forum

I need to organize the routines I'm coding, and others I've already coded,
in a rational way in order to be able to use them without a lot of
hassle, in my programs or in other PROCs.

The last time I did something of this kind was about 25 years ago
with a different progam language, so I need some advice on how
to build the routines in the correct way, ready to be "stored" inside
a library, and used when needed.

Many of you have far more experience and knowledge about assembly
than I could ever achieve at my age, and so who can I ask for advice?
Yes you guessed it.  :biggrin:

Let's start with the first PROC, and proceed step by step until it is
ready to be put in a library and used from there.

I recently coded the routine to format dword unsigned integer numbers
with localized thousand separator and leading spaces in order to have a
right aligned fixed lenght string.

First things first.

1) I'd define the PROC in this way:
FormatDW PROTO Num:DWORD, FormattedStr:DWORD, LenFmt:DWORD

because I want to use the PROC passing it the number to format, the pointer to the
returned string and the lenght of the string to be returned, like:
INVOKE FormatDW,Num2Format,  PtrStr, 7

2) Because the PROC uses localized data that I get with an API, and two more PROCs
to fill 2 supporting arrays, is it better to leave them outside the FormatDW PROC, or
making them part of the same routine? 

I think this is enough for the first post.

I hope your suggestions, examples, and personal coding styles will help me to find a
good way to organize the coded/coding stuff.  :t

Frank

first, you can build and manage a static library using LIB.EXE
which is a stub that actually runs LINK.EXE
so - you can do it just by using LINK
add - subtract - replace - list - OBJ modules

if you have such a library....
the routines that are referenced get "pulled" into (linked with) the EXE you are building
so - if one module references another - that module gets pulled in automatically

but - things are linked on a per-module basis
if you reference one symbol in a module, the entire module gets linked

creating several smaller modules may make for a larger library, but a smaller EXE, in the end
that's because each object module contains a certain amount of overhead info

Thanks Dave.

I'd like to create a static library. So what exactly I do?
Let's say I have a source module called FormatDW.asm.
Does it need to be declared in some particular way or the
bare PROC is good enough?
Next step, I don't have a lib for the time being, and let's
say I'd like to create a new one called MyLib.lib.
What do I do then?
Something like lib module add library? or what?

Frank,

Have a look at how the masm32 library is built, its done the right way. Important factors are granularity, put each procedure in its own module and you never get more than you need. If its going to get the guts bashed out of it, write it with no stack frame for a little more speed in some circumstances.

http://www.masmforum.com/board/index.php?topic=15480.msg126841#msg126841 (http://www.masmforum.com/board/index.php?topic=15480.msg126841#msg126841)

on that post is a very simple library
to see how it is build, just look at the batch file
it also has an INC file and an EXE that was built using the LIB

i think the same is true of Hutch's masm32 library - the batch file is in there, someplace   :P
you might also look at how Hutch does his INC files
notice the IF ELSE ENDIF at the very beginning and the very end of each INC

Quote from: hutch-- on January 10, 2013, 02:15:27 PM
Frank,

Have a look at how the masm32 library is built, its done the right way. Important factors are granularity, put each procedure in its own module and you never get more than you need. If its going to get the guts bashed out of it, write it with no stack frame for a little more speed in some circumstances.

Thanks Steve, Better to have a look at already existing libraries, you're right.  :t

Quote from: dedndave on January 10, 2013, 02:27:51 PM
http://www.masmforum.com/board/index.php?topic=15480.msg126841#msg126841 (http://www.masmforum.com/board/index.php?topic=15480.msg126841#msg126841)

on that post is a very simple library
to see how it is build, just look at the batch file
it also has an INC file and an EXE that was built using the LIB

i think the same is true of Hutch's masm32 library - the batch file is in there, someplace   :P
you might also look at how Hutch does his INC files
notice the IF ELSE ENDIF at the very beginning and the very end of each INC

Ok Dave, I'll see it and try to understand some basical things that I miss.  ;)

you will find that it's very easy   :t

what Hutch said about organization...
notice how he put some of the data items in their own modules
that makes them "reusable", so to speak

one example of that is bintbl.asm

Quote from: dedndave on January 10, 2013, 02:36:58 PM
you will find that it's very easy   :t

what Hutch said about organization...
notice how he put some of the data items in their own modules
that makes them "reusable", so to speak

one example of that is bintbl.asm

Oh yes, I like them reusable. After I've seen all the passages
to create, insert, modify, delete modules from a static lib, then
it'll be easy. At the moment I don't know about anything  :icon_eek:

Another thing I'd like to understand, among the others, is if I can use
some sort of IDE/TOOL to manage the process, or I have to use the
command line LINK/LIB commands to undertake the task.
BAT files are one option, what about other options, if any?

Alex sent me these notes about the main operations involved.
I put them here as a reminder for the job I'm going to do.

Thanks Alex

Quote
First you should assemble all your .asm files to the OBJ files.
ML /C /COFF file.asm
(you will get file.obj)

Create library:
LINK /LIB objectfile1.obj objectfile2.obj /OUT:libraryname.lib

Delete objects from it:

LINK /LIB /REMOVE:objectfile1.obj libraryname.lib

List object modules in it

LIB /LIST libraryname.lib

Add objects:

LINK /LIB libraryname.lib object1.obj

i don't know of any graphical interface for it
although, it wouldn't be hard to create one
maybe it's because - you build it - you update it once in a while - you use it - lol
it's not as though you spend a lot of time managing the library

back in the old days, you had a different set of libraries for each of the 16-bit memory models
it might have been nice to have a GUI app for that   :P
we used a lot of conditional assembly and batch files to do it
but - the interface was a little different
you could do it on the command line, or type LIB and get a prompt for commands
newer versions don't use the +/- commands, i don't think

at the command prompt, type "LIB /?" - it will give you a list of available switches
i think they all work directly with LINK, as well - but are not listed with "LINK /?"
Microsoft (R) Library Manager Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: LIB [options] [files]

   options:

      /DEF[:filename]
      /ERRORREPORT:{NONE|PROMPT|QUEUE|SEND}
      /EXPORT:symbol
      /EXTRACT:membername
      /INCLUDE:symbol
      /LIBPATH:dir
      /LIST[:filename]
      /LTCG
      /MACHINE:{ARM|EBC|IA64|MIPS|MIPS16|MIPSFPU|MIPSFPU16|
                SH4|THUMB|X64|X86}
      /NAME:filename
      /NODEFAULTLIB[:library]
      /NOLOGO
      /OUT:filename
      /REMOVE:membername
      /SUBSYSTEM:{BOOT_APPLICATION|CONSOLE|EFI_APPLICATION|
                  EFI_BOOT_SERVICE_DRIVER|EFI_ROM|EFI_RUNTIME_DRIVER|
                  NATIVE|POSIX|WINDOWS|WINDOWSCE}[,#[.##]]
      /VERBOSE
      /WX[:NO]

in addition to what Alex mentioned, you can also "extract" a module to create an OBJ from a library module
batch files are a good way to go to save some typing

EDIT:
i see you can get the list from LINK with "LINK /LIB"

Two hints:
- use JWasm for testing, ml for the release version. Building the MasmBasic lib takes 13 seconds with ML but only 6 with JWasm
- use the private key word for procs that serve only inside the module - saves a few bytes for the name and makes testing of the main proc easier.

Quote from: jj2007 on January 10, 2013, 05:20:24 PM
Two hints:
- use JWasm for testing, ml for the release version. Building the MasmBasic lib takes 13 seconds with ML but only 6 with JWasm
- use the private key word for procs that serve only inside the module - saves a few bytes for the name and makes testing of the main proc easier.

Hi Jochen, thanks for the hints. As you know I like very much
examples, so please add the syntax of jwasm to assemble
modules to be stored into a library, and the same for the use
of private.
2 small lines will save me about 1 hour searching. (http://masm32.com/board/index.php?action=dlattach;topic=1091.0;attach=926)

Quote from: dedndave on January 10, 2013, 03:49:39 PM
i don't know of any graphical interface for it
although, it wouldn't be hard to create one
maybe it's because - you build it - you update it once in a while - you use it - lol
it's not as though you spend a lot of time managing the library

I think that during the developement process of one or more libraries, you DO spend
time adding, updating, correcting bugs...
But you are right, it is not difficult to build an interface, I did it some decades ago.
I had to select the module and the operation to do, and the appropriate BAT file
would have done the remaining operations. Just to save some typing, you know.
To spare some dozens of coding hours I'd probably do it in PBasic.
I'm sure Jochen has done something to manage the MasmBasic library, in the latest
few years.  :P

i was thinking, if i wanted to do something along that line,
i might want it in the form of a right-click context shell extension

you right-click on a library, and get a set of operations to select from
same for an object file, with a smaller set of operations

Quote from: dedndave on January 11, 2013, 01:06:38 AM
i was thinking, if i wanted to do something along that line,
i might want it in the form of a right-click context shell extension

you right-click on a library, and get a set of operations to select from
same for an object file, with a smaller set of operations

ERROR #000 - Unable to perform requested task.  ::)

???
lol

you have to write it, first   :P

of course, you can add right-click context items that point to batch files
just don't expect a GetOpenFileName dialog or a list of modules to pop up   :biggrin:

i use context-menu batch files to build, now   :P
i have a minor issue to work out in the batch files
otherwise, it works great   :t

(http://img802.imageshack.us/img802/9618/context.png)

Quote from: dedndave on January 11, 2013, 01:24:57 AM
???
lol

you have to write it, first   :P

of course, you can add right-click context items that point to batch files
just don't expect a GetOpenFileName dialog or a list of modules to pop up   :biggrin:

What a pity, my old DOS proggie gave me a list of modules to pick from.

Quote from: dedndave on January 11, 2013, 01:39:46 AM
i use context-menu batch files to build, now   :P
i have a minor issue to work out in the batch files
otherwise, it works great   :t

(http://img802.imageshack.us/img802/9618/context.png)

It looks interesting, when you fix it would you be so kind to show me
how did you accomplish it?
This time tha payment is in golden pounds
(http://www.bullionbypost.co.uk/media/uploads/images/2012/05/16/1_coin_thick.jpg)

Quote from: frktons on January 10, 2013, 10:47:18 PM
.. please add the syntax of jwasm to assemble
modules to be stored into a library, and the same for the use
of private.

1. Syntax is the same as for ML, but I use RichMasm to do that, so I am used to hitting F6 ;-)
   Under the hood you'll see something like this:
   \Masm32\bin\%oAssembler% /c /coff @libtmpXY.rsp
   if errorlevel 0 goto okml

   echo ASSEMBLY ERROR BUILDING LIBRARY MODULES
   exit

:okml
   echo.
   \masm32\bin\%oLinker% -lib libtmp*.obj /out:"%oLibName%.lib"

2. ReadData proc private hPipe
LOCAL PipeBytes, buffer[8000]:BYTE

Quote from: jj2007 on January 11, 2013, 02:12:03 AM

1. Syntax is the same as for ML, but I use RichMasm to do that, so I am used to hitting F6 ;-)
   Under the hood you'll see something like this:
   \Masm32\bin\%oAssembler% /c /coff @libtmpXY.rsp
   if errorlevel 0 goto okml

   echo ASSEMBLY ERROR BUILDING LIBRARY MODULES
   exit

:okml
   echo.
   \masm32\bin\%oLinker% -lib libtmp*.obj /out:"%oLibName%.lib"

2. ReadData proc private hPipe
LOCAL PipeBytes, buffer[8000]:BYTE

Thanks Jochen,

other stuff to study and meditate upon. Yes, F6 is definitely better.  :P

a little trick for posting images...

you can resize the image for display   :P
[img width=48 height=48]http://somesite/image.gif[/img]

(http://www.bullionbypost.co.uk/media/uploads/images/2012/05/16/1_coin_thick.jpg)

adding the context menu item is fairly easy
later today, i will post a how-to guide with pictures   :t

i also have right-click - New - Assembler Source
and a template that defines the new source file

Quote from: dedndave on January 11, 2013, 02:32:19 AM
a little trick for posting images...

you can resize the image for display   :P

Code Select Expand

[img width=48 height=48]http://somesite/image.gif[/img]

(http://www.bullionbypost.co.uk/media/uploads/images/2012/05/16/1_coin_thick.jpg)

adding the context menu item is fairly easy
later today, i will post a how-to guide with pictures   :t

i also have right-click - New - Assembler Source
and a template that defines the new source file

Resize done.
Waiting for your how-to.  :t

The question of the night.

While I'm preparing the 4 PROCs to put inside a library and
use a test prog to see them in action, some questions arise.

After I have the 4 PROCs ready, before assemblying them and
put inside the LIB, Should I declare them PUBLIC or something
like that?
And in the main prog the PROTOs have to be written in a particular
way?
These are two of the PROTOs declared in main prog:

    FormatNumDW PROTO Dest:DWORD, Src:DWORD
    ConsoleSize PROTO MaxRows:WORD,  MaxCols:WORD   

Are they correct or I need to add something?

PROC's are public by default
data is private by default

to make a data symbol public...
        EXTERNDEF   szString

szString db 'Hello World',0

to make a PROC private...
MyProc  PROC PRIVATE.....

either way, you need to declare them in the program source with EXTERNDEF
        EXTERNDEF  SomeProc:NEAR
        EXTERNDEF  szString:BYTE

actually, i think a PROTO will work for a PROC   :P

OK Dave  :t

I'll try in a couple of days and post the results, if any  :lol:

Frank,

The trick is to put all of your library modules for a particular library into one directory them build it from scratch. If you use the MASM link stubs you use their notation, you can also build libraries using Pelle's library manager and you get very good results. This much, the size of a library simply does not matter, its the size of the inserted binary code that matters at LINK time that is the important factor and here again, ALWAYS put each algorithm into its own module so that when you link the final executable, you only ever get the modules that you directly call, not other junk bundled with it that is never executed.

You can mess around adding and extracting code from a library but if its your own source code, you are faster and better organised by building the complete library each time. Build times may have been a problem with an i386 or other similar antiques but on any modern processor, they are so much faster that building the complete library each time is a fast and reliable operation.

Yes Steve,
I think these are good programming principles that come out of
your exeperience in the field.  :t
These principles go beyond Assembly language, every language
should use them in my opinion.
Of course jwasm, polink, polib are good alternatives, quite reliable
and probably faster. They could also produce better final code.
I've do test everything, and it is a long process, but I like it.

Quote from: jj2007 on January 10, 2013, 05:20:24 PM
- use JWasm for testing, ml for the release version.......

Why ? :icon_eek:
I mean why "ml for release version" ?

I am building my libraries from RadASM like :
*.obj,O,$B\JWASM.exe /c /coff /Cp /Zg /zlf /zls /nologo,*.asm

the "/z.." switches are stripping junks from the individual object files so if you have a big library you can see quite a little bit of size reduction compared to ML.

Quote from: Ficko on January 11, 2013, 11:41:04 PM
I mean why "ml for release version" ?

JWasm is 99.x% compatible, but it remains work in progress ("progress" in a positive sense ;)). Therefore, to be on the safe side I prefer to do the release version with ML 6.15.

Quote from: jj2007 on January 11, 2013, 11:54:26 PM
Therefore, to be on the safe side I prefer to do the release version with ML 6.15.

So you are assuming that ML 6.15 is a 100%, flawless product.  :eusa_snooty:

Quote from: Ficko on January 12, 2013, 12:30:11 AM

Quote from: jj2007 on January 11, 2013, 11:54:26 PM
Therefore, to be on the safe side I prefer to do the release version with ML 6.15.

So you are assuming that ML 6.15 is a 100%, flawless product.  :eusa_snooty:

No, I assume that the majority of coders here use some flavour of ML.exe and are dependent on its bugs ;-)

Considering my LIB is going to be an experimental one, for my
own private use, I can afford both the bugs of MASM & Jwasm.

So if anyone want to experiment with the PROCs, feel free to do
it, but post your results or comments in this thread, for the benefit
of all members.

The first routine I put into the LIB is ConsoleSize to allocate a
fixed size console, with choice for number of Rows and columns.
It actually doesn't manage improper input, so be consistent
with the requests you do when INVOKING it.  :lol:
Attached also a Test pgm to see it in action. 

that looks good but, i would use a method similar to what Hutch does with masm32.lib
very much like what ms does with .H includes and LIB's

he creates a masm32.inc file
that inc file contains all the prototypes for the functions in the lib
i would also put any structures or constants (equates) that are related to those functions in the inc file
to save a little typing, you could make this the first line in the inc
    includelib MyLib.lib
when you update the library, you update the include file to go with it

now, when you want to use functions from the lib in a program source...
    include    MyLib.inc

bang - you have the includelib, prototypes, structures, and constants required to use the library functions

Quote from: dedndave on January 13, 2013, 01:33:08 PM
that looks good but, i would use a method similar to what Hutch does with masm32.lib

he creates a masm32.inc file
that inc file contains all the prototypes for the functions in the lib
i would also put any structures or constants (equates) that are related to those functions in the inc file
to save a little typing, you could make this the first line in the inc

Code Select Expand

    includelib MyLib.lib

when you update the library, you update the include file to go with it

now, when you want to use functions from the lib in a program source...

Code Select Expand

    include    MyLib.inc

bang - you have the includelib, prototypes, structures, and constants required to use the library functions

Yes Dave, you are right, and that will be the way it is going to work.
For the time being I'm setting all the things that are needed, as
BAT files, EXTERNDEF, and so on. And many of these things, including
the syntax of LINK/LIB/MASM for building modules and managing the LIB
are not at all clear. As I finish the first group of PROCs it'll be a pleasure
to comment and correct whatever needed and start building the INC file
as the PROCs require.

Frank,

Forgive my humour but with the amount of time posting in this topic you could have built many libraries.  :P

Quote from: hutch-- on January 13, 2013, 02:02:55 PM
Frank,

Forgive my humour but with the amount of time posting in this topic you could have built many libraries.  :P

I enjoy the debate as much as coding, sometime even more  :lol:

And, I'm not in a hurry, if I don't code for 1 week or 3 months, that's
perfectly fine.  :P

 :biggrin:

Nah, this is a sales pitch, plonk 'em all into a directory, get the batch file right and its SLAP BAM, THANKYA MAAM !

Quote from: hutch-- on January 13, 2013, 05:19:15 PM
:biggrin:

Nah, this is a sales pitch, plonk 'em all into a directory, get the batch file right and its SLAP BAM, THANKYA MAAM !

Steve, this is an occasion for learning something, so I've to go slowly.
As a matter of fact, I'm quite lost about the data definition.
I'm trying to define data in an include for the main prog, and find a way
to make them visible to the other PROCs using them.

Because MASM complains, I assume something is wrong with PUBLIC, EXTERNDEF,
and the like.

With EXTERNDEF I should solve all my problems apparently, but I didn't find yet
the correct way to use it.

The most difficult thing, for lack of info, is the definition of a STRUCT in the main
include:


    FmtNum16S  STRUCT
       Billions   BYTE    20H
       Millions   DWORD   20202020H
       Thousands  DWORD   20202020H
       Units      DWORD   20202020H
       StrZT      BYTE    00H
       Dummy      WORD    0000H
    FmtNum16S  ENDS


After I define the STRUCT, I don't know how to make it usable from other
modules.
If I use EXTERNDEF FmtNum16S: it doesn't seem enough.
If I define an actual STRUCT data like:
FmtNum16  FmtNum16S <>
and after I make it PUBLIC with:EXTERNDEF FmtNum16:
the called PROC doesn't see its components:
       Billions   BYTE    20H
       Millions   DWORD   20202020H
       Thousands  DWORD   20202020H
       Units      DWORD   20202020H
       StrZT      BYTE    00H
       Dummy   WORD  0000H

so these simple things, when info are incomplete become
quite difficult to manage.  ::)

the attachment on this post in the old forum shows how to put data into a lib and access it from the main program
http://www.masmforum.com/board/index.php?topic=15480.msg126841#msg126841 (http://www.masmforum.com/board/index.php?topic=15480.msg126841#msg126841)

when i started that thread, i was using the old "public/extrn" method
if you read through the thread, you will see that the guys straightened me out and i updated the attachment

Quote from: dedndave on January 14, 2013, 05:59:49 AM
the attachment on this post in the old forum shows how to put data into a lib and access it from the main program
http://www.masmforum.com/board/index.php?topic=15480.msg126841#msg126841 (http://www.masmforum.com/board/index.php?topic=15480.msg126841#msg126841)

when i started that thread, i was using the old "public/extrn" method
if you read through the thread, you will see that the guys straightened me out and i updated the attachment

Dave, This is understandable. But I'm having problems with a STRUCT,
what's the correct sintax for declaring a STRUCT with EXTERNDEF?
See my previous updated post.

include file:
S struct
member1 DWORD ?
member2 DWorD ?
S ends

EXTERNDEF foo:S

some lib module:
.data
    foo S <>

Quote from: frktons on January 14, 2013, 05:43:55 AM
The most difficult thing, for lack of info, is the definition of a STRUCT in the main
include:

Code Select Expand


    FmtNum16S  STRUCT
       Billions   BYTE    20H
       Millions   DWORD   20202020H
       Thousands  DWORD   20202020H
       Units      DWORD   20202020H
       StrZT      BYTE    00H
       Dummy      WORD    0000H
    FmtNum16S  ENDS


After I define the STRUCT, I don't know how to make it usable from other
modules.

I have not been following this thread, but if the "modules" are separately assembled then why not include the structure declaration in the modules, either directly or by way of a common include file.

http://masm32.com/board/index.php?topic=1255.msg12571#msg12571 (http://masm32.com/board/index.php?topic=1255.msg12571#msg12571)

put the structure definition in the INC file !!!

the data definition (that uses the structure definition) goes in the asm source or in the module, as appropriate

Quote from: MichaelW on January 14, 2013, 06:18:28 AM

I have not been following this thread, but if the "modules" are separately assembled then why not include the structure declaration in the modules, either directly or by way of a common include file.

Yes Michael, the modules are separately assembled.

Do you mean that I should repeat the STRUCT definition for each
module using it? If I only use the name and the EXTERNDEF directive
is it not enough?

Quote from: dedndave on January 14, 2013, 06:25:57 AM
http://masm32.com/board/index.php?topic=1255.msg12571#msg12571 (http://masm32.com/board/index.php?topic=1255.msg12571#msg12571)

put the structure definition in the INC file !!!

the data definition (that uses the structure definition) goes in the asm source or in the module, as appropriate

Yes Dave I put the STRUCT definition in the include file, and the include
is only included by the main prog. Maybe, because the STRUCT is used
from both main and external PROC, this is not enough.
I declared with EXTERNDEF the STRUCT in the external PROC, but something
is missing.

We have somewhat of a terminology problem here. STRUCT is used to declare a structure, so it's a type declaration that can be used in a data definition, or as a template for accessing data, or in this case as a qualifiedtype in an EXTERNDEF statement, but only if at the point of usage the assembler recognizes the type. And AFAIK for the assembler to recognize a type it must be an intrinsic type, or a previously declared structure, union, or record, or a type previously defined with TYPEDEF.

Quote from: qWord on January 14, 2013, 06:17:00 AM
include file:

Code Select Expand

S struct
member1 DWORD ?
member2 DWorD ?
S ends

EXTERNDEF foo:S

some lib module:

Code Select Expand

.data
    foo S <>

Thanks qWord.

Quote from: MichaelW on January 14, 2013, 07:24:53 AM
We have somewhat of a terminology problem here. STRUCT is used to declare a structure, so it's a type declaration that can be used in a data definition, or as a template for accessing data, or in this case as a qualifiedtype in an EXTERNDEF statement, but only if at the point of usage the assembler recognizes the type. And AFAIK for the assembler to recognize a type it must be an intrinsic type, or a previously declared structure, union, or record, or a type previously defined with TYPEDEF.

Thanks Michael, I probably tried to use a struct [in an external module]
that was not correctly defined in that module, so at assembly time MASM
complained about it, the EXTERNDEF and the name of the struct were
not enough. Probably it is better just to pass the pointer to the area and
define the struct inside the called PROC:

main proc

area db 16 dup(?)
ptr_area dd area
...
INVOKE calledPROC, ptr_area
...



MyStruct STRUCT
     Field1  DWORD ?
     Field2  DWORD ?
     Field3  DWORD ?
     Field4  DWORD ?
MyStruct   ENDS

.data

.code

CalledPROC PROC PtrArea:DWORD

....

mov eax, PtrArea
ASSUME  eax:PTR MyStruct
mov [eax].Field1, "some"
mov [eax].Field2, "ASM "
mov [eax].Field3, "code"
mov [eax].Field4, "work"

ASSUME eax:NOTHING

CalledPROC ENDP


ok
probably something i suggested is not correct, here
that is to put the "includelib MyLib.lib" line in the INC file
if you remove that line from the INC file and put it in the program source file....

now, you can include the INC file in both the program source and the module source
the structure definition will be available for both sources

After a long process of testing, correcting, updating, the small
library is ready for the tests and comments.
Attached the sources, the lib, and a test program to use the PROCs
inside the LIB.

Any comment, suggestion, improvement is welcome.  :biggrin:

The example in the attachment declares a structure, along with an EXTERNDEF statement and a prototype, in an include file that is included in both modules, defines a structure variable and initializes it in the first module, then calls a procedure in the second module to display the initialized values. Instead of working through a pointer, the second module directly accesses the structure variable.

Quote from: MichaelW on January 14, 2013, 11:57:45 AM
The example in the attachment declares a structure, along with an EXTERNDEF statement and a prototype, in an include file that is included in both modules, defines a structure variable and initializes it in the first module, then calls a procedure in the second module to display the initialized values. Instead of working throught a pointer, the second module directly accesses the structure variable.

Thanks Michael, your help has gone in the right direction.  :t
This time you answered to a previous question of mine, and
gave me a simple solution for something that was driving me mad.

Yes, if not follow good practice something in building libraries will go you mad. But everything genius is simple – so, batch build could be done by maker utility, and calling with differ options batch file. Develop of course better in IDE simple that easy work with files.
So, each library mought consist of standard catalogs structure :
Demo
   MyDemo
Doc
Include
Source
   MyModule
Test
   MyModule
In inc-files better to use PROTO keyword for PROCs, then EXTERNDEF.

Batch file :

@echo off

if not %1. == . set options=%1=1
if not %2. == . set options=%options% %2=1

nmake /f my-lib.mak LIBNAME=my-lib-ma %options%
if errorlevel 1 goto NO_MAKE

echo ----------------------------------------
echo Successful build of My-Lib v.1.0.0.0 :
echo ----------------------------------------
echo  Lib\
dir /B Lib\*.*
echo  Demo\
dir /B Demo\*.*
goto TERMINATOR

:NO_MAKE
echo -----------------------------------------
echo   Build of My-Lib v.1.0.0.0 not down !
echo -----------------------------------------
echo Check search includes path INCLUDES and
echo library files of MSVCLIBS and SDKLIBS.
echo -----------------------------------------

:TERMINATOR
Makefile is go by principle of building sources by whole catalogs :

PROJ          = My-Lib

MODEL         = F
PROCESSOR     = 6
ASMMACROS     =
LIBDIR        = Lib

asm           = ml
lib           = lib
link          = link

asmflags      = /c /nologo
libflags      =
linkflags     = /RELEASE /MACHINE:IX86 /DYNAMICBASE /NXCOMPAT /NOLOGO /MANIFEST:NO

!ifdef DEBUG
asmflags      = /Zi $(asmflags)
libflags      = $(libflags)
linkflags     = $(linkflags) /DEBUG
!else
asmflags      = $(asmflags)
libflags      = $(libflags)
linkflags     = $(linkflags) /LTCG
!endif

!if "$(MODEL)" == "F"
WIN32         = 1
asmflags      = $(asmflags) /Dmodl=FLAT /coff
!elseif "$(MODEL)" == "H"
asmflags      = $(asmflags) /Dmodl=HUGE
libflags      = $(libflags) /PAGESIZE:64
!elseif "$(MODEL)" == "L"
asmflags      = $(asmflags) /Dmodl=LARGE
libflags      = $(libflags) /PAGESIZE:64
!elseif "$(MODEL)" == "C"
asmflags      = $(asmflags) /Dmodl=COMPACT
libflags      = $(libflags) /PAGESIZE:64
!elseif "$(MODEL)" == "M"
asmflags      = $(asmflags) /Dmodl=MEDIUM
libflags      = $(libflags) /PAGESIZE:64
!elseif "$(MODEL)" == "T"
asmflags      = $(asmflags) /Dmodl=TINY
libflags      = $(libflags) /PAGESIZE:64
!else
! ERROR Model $(MODEL) - not supported !
!endif

!ifdef DEFFILE
linkflags     = $(linkflags) /DEF:..\$(DEFFILE)
DLL           = 1
dump          =
!else
dump          = dumpbin /exports $(LIBNAME).dll >$(LIBNAME).lst
!endif

!ifndef MSVCLIBS
MSVCLIBS      = "\MSVC\VC\Lib"
!endif

!ifndef SDKLIBS
SDKLIBS       = "C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib"
!endif

!ifndef LIBDIR
LIBDIR        = Lib
!endif

!ifndef LIBNAME
LIBNAME       = $(PROJ)
!endif

!if "$(MODEL)" == "F"
WIN32         = 1
!else
! ERROR Model $(MODEL) - not supported !
!endif

!ifdef DLL
$(LIBDIR)\$(LIBNAME).dll : asmobj
$(rc) $(rcflags) $(LIBNAME).rc
@move $(LIBNAME).res $(LIBDIR) >NUL
@cd $(LIBDIR)
@dir *.obj /B >objects.rsp
@$(link) /SUBSYSTEM:WINDOWS /DLL $(linkflags) /LIBPATH:$(MSVCLIBS) /LIBPATH:$(SDKLIBS) /OUT:$(LIBNAME).dll $(LIBNAME).res $(OBJS) @objects.rsp
@del $(LIBNAME).res
@del objects.rsp
@del *.obj
@$(dump)
@cd ..
!else
$(LIBDIR)\$(LIBNAME).lib : asmobj
@cd $(LIBDIR)
@del My-Lib-DLL.obj
@dir *.obj /B >objects.rsp
@$(lib) $(libflags) /OUT:$(LIBNAME).lib @objects.rsp
@del objects.rsp
@del *.obj
@cd ..
! endif


asmobj :
@echo Assembling code $(PROJ) for Windows x86
@echo ------------------------------------------
@if not exist $(LIBDIR) md $(LIBDIR)
@cd Source
@cd MyModule
@dir *.asm /B >sources.rsp
@$(asm) $(asmflags) $(ASMMACROS) @sources.rsp
@del sources.rsp
@move *.obj ..\..\$(LIBDIR) >NUL
@cd ..
@cd ..


Hi Adamanteus,
for building all at once a library with many PROCs, the use of a make file
is a good idea. But I'm going to develop each single PROC, test it and when
ready I'm going to insert it inside the LIB, adding it to pre-existent PROCs.

I need probably an interactive interface to select single PROCs, and give the
command to assemble, insert, update... the LIB.
For the time being I'd better build this interactive tool that executes the batch
files I already prepared, than to start a new study on make files.

First things first, and so far I need more this interactive tool than make files.

you could do something like Hutch does to build the masm32 library
have a look at the make.bat file that is a remnant in the masm32\m32lib folder   :P
he simply does a DIR into a text file, then uses that text file as a response file for the assembler
when he gets to the link command, he just uses "*.obj"
it's a short batch file that does a lot of stuff

Quote from: dedndave on January 15, 2013, 11:58:37 AM
you could do something like Hutch does to build the masm32 library
have a look at the make.bat file that is a remnant in the masm32\m32lib folder   :P
he simply does a DIR into a text file, then uses that text file as a response file for the assembler
when he gets to the link command, he just uses "*.obj"
it's a short batch file that does a lot of stuff

Yes, this a good stuff for building a LIB all at once. Not my case however.

I'd say that library anyway building all at once - after you made procedure and putted to it.
So maybe for stable part of library use common methods, and for adding to it developing part use normal makefile with timestamp checks procedures  :

PROJ          = My-Lib

OBJECTS       = Source\MyModule\Proc1.obj \
Source\MyModule\Proc2.obj

MODEL         = F
PROCESSOR     = 6
ASMMACROS     =

asm           = ml
lib           = lib

asmflags      = /c /nologo
libflags      =

!ifdef UNICODE
ASMMACROS     = $(ASMMACROS) /DUNICODE
!endif

!ifdef DEBUG
asmflags      = /Zi $(asmflags)
libflags      = $(libflags)
!else
asmflags      = $(asmflags)
libflags      = $(libflags)
!endif

!ifndef LIBDIR
LIBDIR        = Lib
!endif

!ifndef LIBNAME
LIBNAME       = $(PROJ)
!endif

!if "$(MODEL)" == "F"
WIN32         = 1
asmflags      = $(asmflags) /coff
!elseif "$(MODEL)" == "H"
asmflags      = $(asmflags) /Dmodl=HUGE
libflags      = $(libflags) /PAGESIZE:64
!elseif "$(MODEL)" == "L"
asmflags      = $(asmflags) /Dmodl=LARGE
libflags      = $(libflags) /PAGESIZE:64
!elseif "$(MODEL)" == "C"
asmflags      = $(asmflags) /Dmodl=COMPACT
libflags      = $(libflags) /PAGESIZE:64
!elseif "$(MODEL)" == "M"
asmflags      = $(asmflags) /Dmodl=MEDIUM
libflags      = $(libflags) /PAGESIZE:64
!elseif "$(MODEL)" == "T"
asmflags      = $(asmflags) /Dmodl=TINY
libflags      = $(libflags) /PAGESIZE:64
!else
! ERROR Model $(MODEL) - not supported !
!endif

$(LIBDIR)\$(LIBNAME).lib : $(OBJECTS)
!@copy $** $(LIBDIR) >NUL
!@$(lib) $(libflags) /REMOVE:$(**F) $*.lib
@cd $(LIBDIR)
@$(lib) $(libflags) $(LIBNAME).lib $(**F)
@del *.obj
@cd ..

.asm.obj :
@$(asm) $(asmflags) $(ASMMACROS) /Fo$*.obj $*.asm