Does anyone know where I can get info on static library file format. I was wondering if its possible to add static library support to a language that doesnt natively support it. I'm happy to accept I may need to write a preprocessor or use some kind intermediate convertion process. I'd like to use another language for non speed critical stuff and use static libs written in asm for some large integer math routines. Is this a possibility or a stupid idea ??

Posted on 2004-03-22 14:36:56 by Emerson
This is as good a place as any to start :

Posted on 2004-03-22 15:02:11 by donkey
http://www.microsoft.com/whdc/hwdev/hardware/PECOFF.mspx - okay document about COFF, Archive, PE, and special import library format.

Which language are you using that doesn't natively support static libraries?
Posted on 2004-03-22 15:08:43 by f0dder
Hi guys.

Thanks for the links, I'm getting a good handle on how it all works.

@f0dder - PowerBasic. It supports inline asm, but its a little restricted in that you cant access Type members directly and a few other small annoyances. Other than that, It's very small, fast and efficient with a good string engine !!

Posted on 2004-03-23 07:12:59 by Emerson
A, powerbasic - that load of crap. I had a brief look at it, and I must say that I wasn't impressed with it's code generation. And now you say that it doesn't support static libraries? :rolleyes:
Posted on 2004-03-23 08:08:30 by f0dder
Hey f0dder,

what other basics are you comparing it agaist ?

RealBasic is 2.2meg for Hello world, and PureBasic is as stable as a three legged chair.

What flavor would you choose if you had too ?

Posted on 2004-03-23 12:56:03 by Emerson
I'm not comparing it against other basics, I'm comparing it against other languages in general. And I'm a bit more interested in code performance than executable speed (though 2.2 megs for hello world does sound like a VERY nonmodular runtime library). However, to put it mildly, I was very unimpressed with the code generation of powerbasic, especially when holding it against the claims on their site. And if you have to use a DLL to yank in some high-performance asm or C code... :-s (yes yes it has inline asm, but that's not always what you want).

It may be an okay tool to "get things done", but so are delphi, borland c++ builder, visual basic, perl, python, ... - however, the PB guys claim their code is "very fast, very tight", but use some pretty suboptimal constructs. Their claim of "no runtimes" is a lie (well, depends on your definition of 'runtimes'), et cetera.

Might be an old version of powerbasic that I used (PowerBasic for Windows v7.0), but considering the attitude & arrogance of PB developers (and some users), I am lead to belive it's a generic thing - also considering the lack of technical info and the general closedness & secrecy of the PB stuff.

I'd prefer even GCC code generation to PowerBasic, and a more scripting-oriented language like Python if I needed the "easyness" that basic offers.

Of course it's just my own very personal and semi-objective opinion, but I think powerbasic is a pile of shit and that there are better & higher performing and even free alternatives available. And that PB doesn't at all live up to modern languages & compiler technology.

I would feel cheated if I had paid for this product.
Posted on 2004-03-23 13:44:39 by f0dder

Thanks for the link; just here is a question. Why the structure of import libraries is so complicated? Why M$ made it difficult to understand?
Posted on 2004-03-23 14:37:15 by Vortex
The "old" import library format might seem complicated, but that's because it consists of regular COFF object files to make the stuff work. And making the stuff work like it does (only including necessary functions, only creating a DLL thunk if one-or-more imports are used, etc.) requires some semi-spiffy stuff.

The new-style import libraries are a LOT simpler (and generally sorta easy iirc), and quite smaller, too.

(old-style import libs could be used with more or less any linker, new-style import libs, iirc, require specific support.)
Posted on 2004-03-23 15:17:15 by f0dder
If COFF is the old style, what's the new? And does VC 6 support it? How much more efficient is it?
Posted on 2004-03-24 12:08:28 by SubEvil
kernel32.lib from vs.net: 188kb. kernel32.lib from masm32v7: 688kb. I'm not sure which version of link.exe was the first to upgrade the import library format, but link.exe is the only component that needs to be upgraded.

The difference is mainly that the "old format" had fully defined COFF objects with all the sections and symbol trickery, while the new format has special "import records" which are a lot more efficient - the linker creates the necessary structures instead of pulling them in directly from the .obj members of the .lib files.
Posted on 2004-03-24 13:12:05 by f0dder
Kernel32.lib from GoAsm: 0 Bytes, no stinking import libraries with GoLink :alright: I seriously hate those things.
Posted on 2004-03-24 13:51:19 by donkey
Hehe ;) - it's a good way to bring DLL support to a lot of languages though, as it doesn't require any *language* modification as long as the language is built around a compile/link phase.

But sure, implibs are annoying, and they can bring namespace corruption, which is annoying. Not to mention that it's unsuitable for "on the go" development tools, unless you have a large USB memory device or don't mind carrying a bulky CD :)

Off-Topic: I wonder where the "quick reply" box went?

Weird, now it's back :confused:
Posted on 2004-03-24 13:56:59 by f0dder
It's one of the strongest features of the GoAsm assembler suite. I like the fact that I can set up a list of DLL's to search during the link process or if I need a one-shot import I can be more explicit:

invoke Kernel32.dll:GetModuleHandleA, NULL

It allows me to use multiple DLLs with the same export names at load time. There can be no conflict when you are explicit. Of course you also just set up a list of "normal" DLLs that are searched when a symbol is unresolved. The other big advantage is that it can also automatically import variables so all I have to do to have RichEd20 loaded by the PELoader is :

mov eax,

Static code libraries are just as easy:

invoke masm32.lib:dwtoa, eax, offset szDword

You only have to specify the lib the first time you call the function, after that it is not needed. Not to mention a command line switch to add the code for MSLU directly to the exe.
Posted on 2004-03-24 14:24:04 by donkey
I think that the best option (besides writing pure assembly) is getting rid of the standard C library by changing the entry point as you have said. Then of course you must write again almost everything but that's (in my opinion) the best option of them all.

Posted on 2004-03-25 10:28:50 by Eternal Idol Birmingham
Here is an example of 1 Kb Hello world application created with Pelle's C compiler.
Posted on 2004-03-26 13:29:47 by Vortex
Please try to be constructive to the topic at hand.

Opinions are welcome, critical or not. But out right attacks are not warrented or welcome. Especially from someone who was once a MOD for this board, you know the rules yet you still think your above them somehow. Hutch, if you want to continue this crap, do it on *your board*. :mad:

f0dder, while i personally think you were mearly excersising you opinions abstractly and not directed at any one person but rather a product, please try not to entertain Hutch's attacks in the future, as they ultimatley go no where useful and every one loses. :rolleyes:

All this asside,

If at all possible I would like to see this thread continue on its origional topic of designing around the COFF static lib format. Its an interesting topic that does not get discussed enough ~ dispite the fact we are all interested in low level assembly.

Posted on 2004-03-28 13:59:32 by NaN

kernel32.lib from vs.net: 188kb. kernel32.lib from masm32v7: 688kb.

Hi f0dder,

My kernel32.lib is 161 Kb. :) The tool inc2lib (using Pelle's MS link compatible linker Polib) outputs smaller import libraries.
Posted on 2004-03-28 14:24:24 by Vortex
Hehe, sorry NaN - but I call crap crap, especially if it's a product that is hyped up to be something it's not. And it's a bit hard not entertaining the old guy's attacks, I find him a great source of humour ;). But sorry, yes, it does lead nowhere and has a thread-ruining effect.

Interesting, vortex. I wonder if the .inc files you used to generate that import library has all the same definitions as the kernel32.lib import library from vs.net2003? Also, whether polink generates both the 1st and 2nd linker member headers - only the first member is necessary, but the second can speed up link times because of it's lexical sort.

It might be that polink generally creates smaller libraries - nice. I wouldn't lose any sleep over ~27kb when both generate new-style libraries, though.

Btw, remember that this method of constructing libraries only works for pure import libraries - there are libraries that have both static code/data as well as imports. Hutch doesn't seem to be aware of this, and thus some IID_* data is missing, for instance, and htmlhelp.lib and uuid.lib are useless.
Posted on 2004-03-28 14:57:48 by f0dder

To address your original question, the binary format of a PB exe is not well suited for patching or code injection as its internal register usage and optimisations are not easy to follow.

As PB handles FP assembler with no problems, I would be very surprised if you could not write the code directly in assembler. You certainly could write a very small DLL using MASM which would perform fine but you already have that capacity with PB.

If you could post the assembler code you have in mind, I have no doubt that it could be written in PB and if you suffer any more abuse for using PB, feel free to ask the question in the masm forum where you can garrantee that you will not be abused.

Posted on 2004-03-28 20:15:14 by hutch--