flat assembler
Message board for the users of flat assembler.

Index > High Level Languages > Assemble to .lib, write .h include in VC?

Author
Thread Post new topic Reply to topic
bobsobol



Joined: 31 May 2010
Posts: 18
Location: U.K.
bobsobol 19 Jun 2011, 16:52
Anyone know how I can use FASM to produce a .lib file that I can write a .h for and then #include into Visual C++?

The idea is that I should not have to re-compile / re-assemble the x86 source each time I compile the C / C++ source project.

That way I can create a library of highly optimised (or quite complex, low level stuff that isn't easy to read or understand in C) and manage the larger project in Visual C IDE.

Note: I'm definitely not looking for "inline" assembler in the C / C++ projects, but I don't want to distribute a .dll with the finished program.

I want the assembler source "linked" into the final executable, but "compiled" before the project is built. (possibly before it's even started)

I don't mind if the C header should actually point to a .obj or a .bin, but I've not seen Visual C do that.

I also don't mind if I have to assemble to a .obj and then use a "linklib" type tool to link all the object files into a single library... I just don't know how to do that.

I usually use fasmw, and it's all geared to producing an executable. Even though I can produce a DOS, Windows or Linux executable or library (.dll) depending on how I write the source.

Maybe I need to use fasm from the command line and give certain switches as parameters? Even so, I have no idea how to declare what should go in what section of the PE when Visual Studio links it, if what I'm producing in FASM isn't a .exe or .dll.

I hope that makes sense. Confused
Post 19 Jun 2011, 16:52
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 19 Jun 2011, 17:48
.lib is just a bunch of .obj files put together into single file. It is useful for bigger libraries, where you place each function to separate .obj file, and linker only includes those which are used in final project. If you don't need this and want to always include everything, you can simply use .obj and link it with your project.

I wrote several examples long time ago. Look at HLL section of this forum, something like "Mixing C and asm". Maybe it's in examples part of the site too.
Post 19 Jun 2011, 17:48
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
bobsobol



Joined: 31 May 2010
Posts: 18
Location: U.K.
bobsobol 19 Jun 2011, 21:01
Yes, I'd seen those examples before I posted this thread vid, and checked out the interesting stuff on your site. ^^ (can find the zip on the examples page, but can't find the topic now.) Sad

I'd gathered .lib was a collection of .obj, and what the compiler would do with different objects in the library. That's what I want. A library of code which I can include in VC projects with lots of routines (like my own mini CRT for example) that each project may only use part of.

If making a lib is too hard from FASM, and including multiple .obj files would achieve the same thing, I can do that... but then I'd want to produce multiple .obj files from the FASM source, (as various routines may rely on, or share data with each other) and I don't know how to build a FASM project to multiple target files either.

Best info I could find was in this thread

Format the ASM like:-
Code:
format MS COFF

public  StdOut as '_StdOut@4'
extrn '__imp__GetStdHandle@4' as GetStdHandle:dword
extrn '__imp__WriteFile@20' as WriteFile:dword
extrn '__imp__lstrlenA@4' as lstrlen:dword

Include '%fasminc%\win32a.inc'

section '.code' code readable executable

proc StdOut,lpszText

hOutPut dd ?
bWritten dd ?
sl dd ?
enter
        invoke  GetStdHandle,STD_OUTPUT_HANDLE
        mov             [hOutPut], eax
        invoke  lstrlen,[lpszText]
        mov             [sl],eax
        lea             eax,[bWritten]
        invoke  WriteFile,[hOutPut],[lpszText],[sl],eax,NULL
        mov             eax,[bWritten]
        return

endp     
Except there is no way I would want the variables hOutPut, bWritten and sl stored in the .code section, or a .text section, or any section with "code readable executable" permissions.

I would have thought the section would need to have "writeable" for the code to even work but... "who am I to blow against the wind."

link with:-
Code:
lib /OUT:console.lib Object1.obj Object2.obj     
(Credits to Vortex for the original post)

But how do I get FASM to produce "Object1.obj" and "Object2.obj" from one source file? Or can the object file contain lots of routines that the compiler will link only what is needed... or can I include lots of object files in a .h which, only those which are actually used in the final program end up included in the executable?
Post 19 Jun 2011, 21:01
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 19 Jun 2011, 21:54
No, linker always takes entire .obj file whenever any symbol from it is referenced[1]. You do have to compile every object file separately, and unless you want to use some kind of trickery, you should have separate .asm file for every .obj target. Then, merge produced .objs to .lib file, and then create single .h for your .lib. Linker doesn't care where some symbol is declared (.h file in your case), it only links every .obj file from which any symbol is referenced.

[1] I think there is a mechanism for having multiple independent optionally-linked things in same .obj, called something like COMDAT, but I don't know anything about it.
Post 19 Jun 2011, 21:54
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
bobsobol



Joined: 31 May 2010
Posts: 18
Location: U.K.
bobsobol 20 Jun 2011, 06:19
Your information is giving me ideas for such "trickery". ^^

If I use "proc" macro, then only used procedures are included in an object file?

So I can keep routines of similar liniage in a single file, or at least a primary code file and optional INCludes.

I can then INClude that file in several ASM files which import only 1 to a few co-dependant routines from it, (init, manipulate, despose type interdependence) and export them in the destination object file.

A batch script (or Perl, or similar) to compile all ASM files in a directory would produce my "collection of .obj files", and could then pass each of them in as a list to a single "lib.exe" command to produce the .lib file.

My .h file to associate C constants and import descriptions from the .lib can almost be an "automated-translation" from the ASM files which created the object files in the first place.

Then I can produce my general purpose runtime library of routines, optimised with the precision hand crafting of x86 which we all love. ^_^

One thing I may have to think carefully on, is co-dependant routines which may / will appear in multiple .obj files, and the likelihood of those then appearing multiple times in the same executable when linked together... but it's a start idea. I'm guessing I could build up in waves from very low level objects to the final exposed calls, and simply don't expose the very low level stuff from the .h file... or, do, just in case it can be useful for the high level code.
Post 20 Jun 2011, 06:19
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 20 Jun 2011, 16:19
Yep, that's the sort of trickery I was talking about. It gets job done, but isn't exactly nice should anyone else ever touch your sources.

Quote:
One thing I may have to think carefully on, is co-dependant routines which may / will appear in multiple .obj files, and the likelihood of those then appearing multiple times in the same executable when linked together...

And that's sort of problems using "custom trickery" usually causes Wink
Post 20 Jun 2011, 16:19
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
bobsobol



Joined: 31 May 2010
Posts: 18
Location: U.K.
bobsobol 21 Jun 2011, 09:30
Well, thank you for that vid.

Thanks to your responses, I now know 'how' and why it's such a PITFA.

Would be really nice if we could get the FASM linker to link to a .lib "collection of object" in the first place, as it could easily be very smart about the dependabilities. ^_^
Code:
format MS COFF LIB    
(doesn't exist) vote for me! \o/ Laughing
Post 21 Jun 2011, 09:30
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 21 Jun 2011, 10:00
IMHO someone developing larger project (eg. a proper library) should be capable of using other tools than just FASM. And there are plenty of tools existing which can create .lib just fine, so there's no need to duplicate this functionality in FASM. Problem of FASM is that's it is not designed to be used in cooperation with other tools. That's an advantage if you want ultra-easy asm-only project setup, but great disadvantage if you want to combine several tools for your project.

PS: My old FASMLIB was built into DLL, several several .obj formats, several .lib formats, and it was also usable by directly including by sources "the FASMy way" - all of that in versions for several different OSes. Been there, done that, it worked but it wasn't very nice.
Post 21 Jun 2011, 10:00
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.