Hello everyone!

I've got a question for you guys: Is there any way at all to use multiple source files in a project assembled with FASM?

I know it's possible to have the source separated in multiple .inc files then using the 'Include' directive to make it so everything is in a single file, but I was actually looking for something a little more elegant, as that usually ends up looking pretty confusing in larger projects, and I'm not too keen on the idea of having to include a different file for each section of the PE that references a part of the source.

What I'm trying to say is I'd like to have the source code split into several .asm modules, each one with their own .data, .text and .idata sections, then have the assembler compile them to MS COFF files and link them together automatically.

I can't seem to find a way to do it though. It would be great if FASM featured an 'Import' directive with which you could specify a source file and it would first assemble then link it to the final executable for you.

If that's not possible though, I'd appreciate if you kind people could direct me as to how exactly one should define and call public procedures in COFF object files from an .asm file that has yet to be assembled.

I can't seem to get my head around the 'extrn' definitions for importing APIs in the MS COFF files either, since apparently you can't have an import table on them, so any help with that would be greatly appreciated.

Sorry if I'm not altogether familiar with these concepts, I'm still trying to learn assembly as best I can.

Thanks in advance!

You can have all the sections you want, but FASM has no internal linker.

LnS,

Separate compile and link stages are OK with FASM (although you apparently will need linker). Import from DLLs usually requires import libraries for them (GoLink provides capability to use export directories of those DLLs to be used directly) and _/_imp_/@ name decoration in extrn directives: Linking with either

link /subsystem:windows /entry:start coff1.obj coff2.obj user32.lib

or

GoLink.exe coff1.obj coff2.obj user32.dll

produces working PE (GoLink seems to understand _/_imp_/@ decoration).

Matt Pietrek wrote nice explanation in his fine Under The Hood MSJ column relating this matter.

Thanks baldr, that's exactly what I was looking for!

Just one thing, in the definition for extrn "__imp__MessageBoxA@16" as MessageBox: dword , is the syntax supposed to reflect the following pattern: extrn "__imp__{ApiName}@{LengthInBytesOfAllArguments}" as {ExportName}: {ReturnType} for any given API? [/i]

It is more like "__imp__{ApiName}@{LengthInBytesOfAllArguments}" as {SymbolToBeUsedInSource}: {SymbolType}

Note that __imp__* are dword pointers to functions (for that reason baldr used invoke instead of stdcall)

LnS,

The pattern is simple:

1. MessageBoxA is the undecorated function name;
   
2. stdcall convention decorates name as _MessageBoxA@16 (4 arguments 4 bytes each);
   
3. declspec(dllimport) prepends _imp_, that yields _imp__MessageBoxA@16 as undecorated name for pointer in IAT;
   
4. this pointer variable gets _ prefix according to standard conventions.

I've already explained this mechanics in "extrn" topic. There is slight difference under _WIN64, step 2 is omitted (so in 64-bit User32.Lib IAT entry is named __imp_MessageBoxA).