More than 1 .asm-file

[n00b!]

Hello,
sorry again for another totally noobish question, but I can't make it alone and I'm wondering if this is possible:

Can I use more than 1 asm file, like this little abstract snippet:

Code Select Expand

.386
.model flat, stdcall
option casemap :none

include windows.inc

extrn foo:proc

main:
xor eax, ebx
push eax
call foo
invoke ExitProcess, 0
end main

And then foo.asm should look like this:

Code Select Expand

.386
.model flat, stdcall
option casemap :none

include windows.inc

foo proc abc:DWORD
invoke MessageBox, 0, abc, 0, 0
ret
foo endp

main: ;But by writing this there would be 2 Entrypoints -> Error
end main

Or maybe the whole file would only contains this (only the proc):

Code Select Expand

foo proc abc:DWORD
invoke MessageBox, 0, abc, 0, 0
ret
foo endp

Does it work like in C?

Code Select Expand

#include <stdio.h>

int foo(int);

int main(void) {
printf("GO");
foo(0);
return 0;
}

Second *.c:

Code Select Expand

#include <windows.h>

int foo(int abc) {
MessageBox(0, "Hello", 0, 0);
return 0;
}

Or does the second asm have to contain only the functions and then I include it instead of linking 2 object-files?
Like this abstract-snippet:

Code Select Expand

.code
include foo.asm
main:
call foo
end main

Thanks! :-)

[zooba]

The first two are almost spot on, the only change is to remove main from the file that doesn't actually contain the entry point, and change the last line to simply END.

Compiling this involves calling ML.EXE twice (once for each file, alternatively by putting both files on the one command line) and LINK.EXE once with all the .OBJ files. Some versions of ML and LINK support wildcards but some don't, so if it doesn't work, you'll have to list each file.

Alternatively, your last idea will also work, though keep in mind that it operates exactly the same as copy-pasting the file in - section definitions, procedures, etc.

Cheers,

Zooba :U

[n00b!]

When I have "foo proc [...] foo endp" in the second file and in the first "extrn foo:proc" I get the following error (when trying to call it):

test.obj : error LNK2001: unresolved external symbol _foo

[MichaelW]

Try  "extrn foo:PROTO :DWORD". There are other methods, but AFAIK only this one will work with invoke.

[Sameer]

write
include foo.asm
in the main file and in foo.asm write

Code Select Expand


.code
foo proc abc:DWORD
invoke MessageBox, 0, abc, 0, 0
ret
foo endp

[n00b!]

Yeah, I could do it like that, thanks  :P

But I want to try out the other way, which I use all the time in C, so I want to know how it works in asm...

I don't use invoke, I simply push the parameter and call foo.
When I write extrn foo:proc the assembling works fine, but when linking the two obj-files I get the error, that foo is 'Unresolved external'.

So it seems that the linker cannot find the proc but I simply did it like the example in my first post :-(

[MichaelW]

The problem is that the name in the object module were the procedure is defined is "_foo@4", and the name in the object module that calls the procedure is "_foo". Try opening the object modules in a suitable text editor and looking at the names.

Even if you use CALL, "extrn foo:PROTO :DWORD" will still work, but you must include the parameters so ML can generate the correct name. Other possibilities are "extrn foo@4:PROC" or "extrn foo@4:NEAR", where you specify the correct name directly, less the leading underscore which will be added by ML.

In case it's not obvious, for the @N decoration on the names N specifies the size of the parameters, in bytes, normally 0, 4, 8, 12, 16, etc.

[PBrennick]

Along with all the good advice you have gotten here; remember one thing - foo.asm must be declared as public or the calling program will have a problem linking to it.

One last thing, remember that both ml.exe and link.exe accept a listing of files in a file as the input parameter as follows:

Code Select Expand


dir /b *.asm > FantsticStuff.rsp               : create a response file for ML.EXE
\GeneSys\bin\ml /c /coff @FantsticStuff.rsp


-- Paul

[MichaelW]

Hi Paul,

Your post reminded me of something I had forgotten. Even though I am in the habit of using the PUBLIC directive to make procedures visible outside the defining module, it's not actually necessary for procedures defined with the PROC directive, because the visibility is PUBLIC unless it is specifically declared as PRIVATE.