Hello,

as every FASM application I've seen so far, I use the library macro to load Windows-API functions from the Windows DLLs.
Now I came across a C++ board where some "experts" said, that linking the Windows API is a bad idea because some systems won't run the application anymore, and the API functions should be loaded linked directly into EXE through a static library.

I doubt that it is true, because every Windows System should have the API DLLs included. So can I still write Windows applications in FASM as I did before, or do I have to fear that some systems won't run the application?

What do you think about their statement?
Thank you

where have you seen THAT ?!?!?

What they mean by "linking" maybe they meant linking by LoadLibrary vs. imports? Please post link

hi Denial

I do not know what you mean about some systems (are you mean linux, mac, or other version of Windows?), in my short experience using Fasm(about a half year), all my application run in windows 98 environment (and if doesn't run in windows xp or other version of windows i guest just need some adjustment). And i never think my windows application can run on linux or mac, i mean i make the application not for linux or mac environment.

for me there no need to fear. (cause from my experience there no application run on all system)

i'm sorry if what i thinking about some system is defferent from your thinking.

my regard
Senolc_eht

ps. I make my application in windows 98 environment

Of course I talk of windows systems I mean different editions like XP, ME, 9x. Sorry if this wasn't clear.
With static linking I rather mean the usage of *.lib files. Or to say it more clearly: Just link the functions you use directly into the exe. So a runtime-access through a DLL is not needed. BUT: I can just say what THEY said!!

I've already tested what they said. And I have to say that my FASM applications worked in XP and Win 9x.

@vid: It was somewhere in a German web-archive.

so if you never find an problem, what you fear of..?
and i never listening some thing that make me stop my learning, working or my faith.

my regard
Senolc_eht

If i am not mistaken, the macro will add an import section to your program and windows will fill the information at run-time. This is exactly the same that an import library.

The only exception is when the import library also have some global data that its not on the DLL but on the library. The only library I have found that does is the one for dinput8.dll. inside dinput8.lib there are some GUIDS and globals needed for use.

However this will likely make you have an error on compile time and not in run time. Unless the functions you are calling are not in the version of windows. But in this case linking with the libraries will not help you.

Maybe the C++ expert was taking about the C/C++ runtime, or other libraries that have a static equivalent. The information does not apply to import libraries that have no static library equivalent.

Doesn't sound like those people were 'experts'

If what you're talking about is linking with "user32.lib", "kernel32.lib" (etc.) instead of GetProcAddress, well, realize that those libraries are import libraries, and still end up using the DLLs. LoadLibrary+GetProcAddress should only be used if you need to use some API function only if it's available (for example layered window stuff to get transparent windows on 2k/xp), or if you're designing a plugin system.

If it's the .lib files versus fasm's "import" stuff, well, they are just two different ways of doing basically the same thing.

Thank you for your answers