CODEWITHSUNDEEP
c++winapidllstatic-libraries
codekiddy
codekiddy

Reputation: 6137

linking static library into dll

In windows programing, If you have a static library which is intended to be linked with a dll library where the dll has /SUBSYSTEM:WINDOWS defined, then which of the following marcos should be defined in static library?

_LIB
_WINDOWS

I'm confusing these macros because a static library it self will never show it's own window or console on it's own, so I can't understatnd why do we need to define these macros for static library project?

Upvotes: 1

Views: 3718

Answers (2)

Ben Voigt
Ben Voigt

Reputation: 283971

Just a few points:

  • It's entirely possible for functions in a static library to create and manipulate UI, either User32 windows or console (I guess Modern UI as well).

  • Unless you provide special functions for the purpose, the application using your library can't tell what macros were used for library compilation.

  • Windows headers sometimes will provide defaults if you haven't defined any of a set of macros (e.g. WINVER)

  • These macros are only as magic as your code makes them. If you aren't testing them, then defining them is going to have almost no effect.

  • If your library does conditionally make UI features available, skipping those at compile-time with #if defined(_WINDOWS) has some advantages over run-time enable flags.

In particular, if calls to UI functions are stripped by the preprocessor, the linker won't need to add UI DLLs to the import table. Might make a difference whether your library works on Server Core installs of Windows. At the same time, runtime checks are nice because you only need to compile the library once and distribute one version. Using run-time enable flags and setting the linker to use delay-load might give the best of both worlds.

Upvotes: 1

codekiddy
codekiddy

Reputation: 6137

after fighting with google for houres and various forums and white papers I found out what all that means when using visual studio!

static library: does not need an /ENTRY or /SUBSYSTEM because the code will be linked into another code. so the library does not need a console, windnow or entry point

dll: /SUBSYSTEM should be set to WINDOWS and /ENTRY should not be set, why? no entry because in visual studio linker automaticaly creates a DllMain entry point. subsystem of dll should be set to WINDOWS link1 link2 another examle why WINDOWS

exe: /SUBSYSTEM and /ENTRY should be set explicitly, if not set, linker will again automaticaly set the subsystem AND entry point as noted in the link above.

so to answer my original question, none of the above "stupid" macros must be defined :)

Upvotes: 1

Related Questions