Help needed to build a library of PROCs

[dedndave]

???
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   

[dedndave]

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

[frktons]

???
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   

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

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

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

[jj2007]

.. 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

[frktons]

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

[dedndave]

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]



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

[frktons]

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]



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

[frktons]

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:

Code Select Expand


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

Are they correct or I need to add something?

[dedndave]

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

to make a data symbol public...

Code Select Expand

        EXTERNDEF   szString

szString db 'Hello World',0

to make a PROC private...

Code Select Expand

MyProc  PROC PRIVATE.....

either way, you need to declare them in the program source with EXTERNDEF

Code Select Expand

        EXTERNDEF  SomeProc:NEAR
        EXTERNDEF  szString:BYTE

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

[frktons]

OK Dave  :t

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

[hutch--]

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.

[frktons]

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.

[Ficko]

- 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 :

Code Select Expand

*.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.

[jj2007]

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.

[Ficko]

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.