I wrote a small program that creates a correct include file containg API names exported by a given DLL. It means that one won't care about missing includes, he just needs to have this DLL and my program in the system. Unfortuantely I didn't have so much will to create intuitive and nice GUI so the only interaction with user is commandline .

Usage: apiresolve dllname.dll
Example: apiresolve opengl32.dll

In the directory where the program was run, after a second there'll be an dllname.inc (in this case opengl32.inc) file with API names. I coded it so that it omits widechar APIs (these ended with W), but I include a sourcecode so anyone can change it easily. Hope you'll like this little proggie. I wrote it, because needed to write some OGL stuff, and didn't want to create ImportDirectory by hand.

EDIT: New v2.0 release with some enhancements due to requests from board. Support for ANSI names, Unicode names or both at the same time. Rewritten from scratch

EDIT2: New v2.1 can output includes to use with 'format MS COFF' also

EDIT3: Version 2.2. Fixed issue with MS COFF format. It is now like:

EDIT4: Fixed a bug with MS COFF format (thx flaith, sorry for so long time to fix it.... I just forgot )

EDIT5: Again some new bug was found. This time in PE format include, always the last import was badly output. Fixed in 2.3.1 version

EDIT6: There's a new Length Disassembly Engine version which is the base of ApiResolve engine for COFF format. New ApiResolve is compiled with the current LDE

Very nice Reverend!!!! This will help a lot ! Amazing you should say opengl, I was in the process of converting the opengl function proto's. Good Work Wish you would've posted this a week ago.
MadMatt

like dll2inc

madmatt: hey, thx a lot, I also needed it for opengl
Vasilev Vjacheslav: I don't know dll2inc. Do you mean that such a program existed before? So why there were so many libraries' includes missing?

So for now I think that decard can even remove section with includes from his page, and put there my program as it can create include file for any dll. What do you think?

The imports are not all - there remains the problem with equates. Some kind of H2ASH might be useful, but that would be a bit harder project.

yes, such program existed before, i found two versions: at comrade homepage (he is author) and at wasm.ru page

It'd be a more difficult project, because a parser would have to be written. Not exactly a parser, but the program would have to (just as C/C++ compiler) interpret all equates, structeres, etc. and write them in a fasm way

Uploaded new version in the first post

That's one amazing program!

Thanks!

Yes it would be - though one has been done for MASM so its not impossible (h2inc)
Though h2inc does has its problems.......it seems to be unable to convert quite a number of c headers i have

It would also be nice to have a feature to create include files that import in this style:



This is useful for MS COFF format.

In your PE.inc, it is recommended you use = for numerical constants (those IMAGE_ ones), instead of equ

This recommendation is no longer true for all cases - if the constant values don't involve calculations and you don't need to forward-reference them, the EQU might actually be better (faster) than =.

this is new info for me. can u explain more?

The recommendation to use = for all equations when possible was because the symbol table for EQU constants was much slower in the old implementations. In the newer versions of fasm this was fixed, and EQU might be even actually faster in some cases, as it get fully processed at the preprocessing stage, so assembler doesn't have to chew it in the each pass.
For example:

is no worse and might be even better in performance than:

In the first case assembler sees only the

line, since this is what it becomes after preprocessing. In the second case assembler sees both the lines and processes "ALPHA" in the same way as it would process the label.
However if you need to forward reference ALPHA label you should use =. Also for the calculated constants like:

it's better not to use EQU, consider this:

If you used

you would get

which is perhaps not what would you want. Well, you could define it like:

but also note that if BETA and GAMMA are labels, it will be more suitable for assembler to access the single ALFA label (and BETA and GAMMA only to calculate its value in definition) than to access two labels each time.

So the general conclusion might be: for numerical values you should use =, as it was designed for this purpose, but if the EQU works for your needs in your case, you don't have to change it.

Did you check my MASM to FASM function prototype converter?

http://board.flatassembler.net/topic.php?t=588

comrade: I started to code MS COFF output, but I'll have to write length disassembler engine first, because now it searches for 0C2h, xxh, xxh or 0C3h. And it works in most cases but sometimes not eg.:
And then it outputs wrongly

Disassembling is an unsure technique to get the number of parameters. You will be able to cover most cases, but never all. FASM has some special 'PCOUNT' includes that have the number of parameters for most Win32 API. However, the most sure way that I see would be to extract information from import libraries (MS .lib)

In first post there's an updated version which enables an option to output includes for 'format MS COFF'. I made it with my LDE engine, because now the program 'knows' where starts and where ends any opcode, so it can easily find 'retn' opcode.

Even though there are some flaws. For MS COFF it assumes that all exports are stdcall. So the program will work with most of windows libraries corectly, but eg. wsprintf from user32.dll is outputed wrongly. Unfortunately my program reads from binaries, from compiled version and there's no info, whether the function is stdcall or ccall.
Also if the library has some obfuscated code, my LDE engine might get wrong, so the whole output won't be ok. But I guess such situation is nearly impossible to happen

comrade: I don't know why, but I just in the moment saw your answer. I didn't see it before, so I didn't even concern what you were talking about. If I thought about it this way I may never write LDE engine But in whcich cases do you think reading from binary will output wrongly? (instead of stdcall/ccall problem)

DLL functions may have runtime decryption, or a very complex system of jumps where the actual C2 XX XX may be hidden away. You will never be certain with a disassembler, but it is better than nothing so all cool