Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Static vs Dynamic linking (Read 14787 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Static vs Dynamic linking

Is there any "official" position regarding the linking of C++ libraries in 3rd party components (code generation option /MT vs /MD), given that :

Static vs Dynamic linking

Reply #1
Static link.

Static vs Dynamic linking

Reply #2
This is how I decide on whether to link the runtime dynamically or statically. If your component is:
  • just a single fb2k DLL - there's really no need to link the runtime dynamically except size reduction, at the cost of annoying your users.
  • a single fb2k DLL with a bunch of companion DLLs - it depends on the kind of the companion DLLs. If their interface is:
    • C-like with create/delete functions and their own types, or if they use PFC - link statically to the runtime.
       
    • C++-like with use of the standard library in their interfaces or if they use templates - you probably want to link the runtime dynamically.
Don't forget that you can deploy the runtime privately by bundling the two DLLs in your component archive, but I prefer requiring my users to install the redist instead to reduce the size of the component archive.
Notice that the above flowchart doesn't cover the case of having more than one component in an archive, as that's something that you should not ever do.
Stay sane, exile.

Static vs Dynamic linking

Reply #3
static linking is just bad as it is. there's really no point using it. ms is not the only one who recommends dynamic linking, everyone recommends it who has a clue.

with static linking you make it impossible to have security and/or other updates applied to the crt. they will be applied to the system crt, but the app/dll you linked statically will still be vulnerable. the same applies to the case when you "bundle" dlls with your app. not to mention it makes no sense to have the same crt/lib in your system in several copies, possibly at different patch levels. you can do it, but it makes no sense and is a very very bad practice. it's only widespread because developers are too lazy to take care of things.

use the redist, which is maintained by windows update, or use the wdk method, with which you still use the system crt and other libs which are maintained by windows update. if you wanna try the wdk method, i can give you pointers, i use it with success for xchat-wdk and a lot of other libs.

the redist way is probably easier, it only requires some installer work, i.e. bundling the redist installer into the existing installer, or instructing your users to download and install it (which will cause a lot of bug reports coz users won't read your instructions).

as a sidenote, size is the last consideration nowadays, it just doesn't matter when you can buy a 2TB drive for 50$. you should take care of security and reliabilty first, not size.

Static vs Dynamic linking

Reply #4
Dynamically linked components can be problematic for those who use foobar2000 as a portable app.
The solution is simple(?): user can copy msvcr100.dll and msvcp100.dll in foobar2000 folder (I assume that the developer uses MSVS 2010).

And: foobar2000 itself and its official components are linked statically.

Static vs Dynamic linking

Reply #5
as a sidenote, size is the last consideration nowadays, it just doesn't matter when you can buy a 2TB drive for 50$. you should take care of security and reliabilty first, not size.

Size does matter on the internet. Both in terms of time it takes for users to download, not hitting transfer caps imposed by evil ISPs, and not to be forgotten, bandwidth costs for the HydrogenAudio server.
As for using the WDK, last I checked it had some rather ancient compilers and runtimes, without a trace of C++0x. If you want to write your C++ without going insane, you will need to use a recent runtime.
If you re-read my post, you'll see that I only advocate using a shared runtime when it's technically unfeasible to use a static runtime or MSVCRT.

As for using "installers", that's not possible with the current foobar2000 component ecosystem which mandates that a component shall be distributed in a self-contained zip file with any dependencies it requires inside. Even if it was, it'd be impossible to use them with portable installs as lvqcl mentions.

The reason why fb2k can get away from having a shared runtime is because it reinvents most of the C++ standard library in PFC, with the shared bits in shared.dll (which everyone must link). It is not feasible to rewrite arbitrary third party code to use PFC.
Stay sane, exile.

Static vs Dynamic linking

Reply #6
Dynamically linked components can be problematic for those who use foobar2000 as a portable app.
The solution is simple(?): user can copy msvcr100.dll and msvcp100.dll in foobar2000 folder (I assume that the developer uses MSVS 2010).

And: foobar2000 itself and its official components are linked statically.


why is that problematic? if you use wdk, your app will run on any windows (xp, vista, 7, 2003, 2008). win2000 penetration is about 0.5% at most, so i wouldn't count that as a showstopper.

"The solution is simple", you see? that's what i'm talking about. you are lazy, you want to get it fast, instead of getting it right.

Static vs Dynamic linking

Reply #7
Size does matter on the internet. Both in terms of time it takes for users to download, not hitting transfer caps imposed by evil ISPs, and not to be forgotten, bandwidth costs for the HydrogenAudio server.
As for using the WDK, last I checked it had some rather ancient compilers and runtimes, without a trace of C++0x. If you want to write your C++ without going insane, you will need to use a recent runtime.
If you re-read my post, you'll see that I only advocate using a shared runtime when it's technically unfeasible to use a static runtime or MSVCRT.

As for using "installers", that's not possible with the current foobar2000 component ecosystem which mandates that a component shall be distributed in a self-contained zip file with any dependencies it requires inside. Even if it was, it'd be impossible to use them with portable installs as lvqcl mentions.

The reason why fb2k can get away from having a shared runtime is because it reinvents most of the C++ standard library in PFC, with the shared bits in shared.dll (which everyone must link). It is not feasible to rewrite arbitrary third party code to use PFC.


orly? you are clearly write-only, as you managed to miss the fact that you can actually decrease size if you use wdk. and no, 1mb minus or plus does not matter on the internet anyway. so you are wrong in both cases. i only said that size should be the last point in an argument. users won't give a damn about a few megabytes.

and you also managed to ignore the rest of my post, congrats

and no, the wdk does not use ancient compilers. they are actually from vs2008, but you can use even the vs2010 compilers. you only need to use the wdk headers and libs.

Static vs Dynamic linking

Reply #8
Of course, you can forget about using those headers and libraries if you use even an ounce of the STL. It's a good thing nobody uses that.

Static vs Dynamic linking

Reply #9
I remember some Wine users complaining about my component's dependency on MSVCR libs :-| And outdated Win XP installations probably lack them too. So I chose static linking. I think that user experience is more important than several kilobytes of an overhead. Still, I'm gonna fill a gap in my linking skills and get executables static and small at the same time.
Quote
user can copy msvcr100.dll and msvcp100.dll in foobar2000 folder
That's quite a geeky solution for most users. It's up to developers to care about dependencies.

Static vs Dynamic linking

Reply #10
I did not say anything about the rest of your post because I didn't find anything worth saying about it, except that I do not consider the "omg, security!" argument a valid argument for software that is not attacker-facing.
Using the WDK headers and libraries is not an option if you write any kind of non-trivial C++. They're really only feasible if you write balls-to-the-wall idiot-grade C.

As for "size doesn't matter on the internet", I'm sure that the guy paying the HA bills disagrees strongly with you.
There's tradeoffs for everything, and in the case of fb2k, it's Really Hard to warrant/support any kind of non-private dynamic deployment. What you do for your own projects is up to you and your closet.
Stay sane, exile.

Static vs Dynamic linking

Reply #11
Quote from: kode54 link=msg=0 date=
Of course, you can forget about using those headers and libraries if you use even an ounce of the STL. It's a good thing nobody uses that.

Quote from: Zao link=msg=0 date=
Using the WDK headers and libraries is not an option if you write any kind of non-trivial C++. They're really only feasible if you write balls-to-the-wall idiot-grade C.


huh? wdk comes with stl, atl, mfc and so on. so what are you bitchin' about without a clue?

Quote from: Zao link=msg=0 date=
As for "size doesn't matter on the internet", I'm sure that the guy paying the HA bills disagrees strongly with you.


sure, if he wants a higher bill. i've already mentioned that size would actually decrease, but you're apparently left in write-only mode.

Quote from: Yegor link=msg=0 date=
That's quite a geeky solution for most users. It's up to developers to care about dependencies.


nah, it's not "geeky", it's just plain bad. and it's not at all a "solution", rather, it's a workaround of the lazy, clueless "devs" whose only perspective is file size.

Static vs Dynamic linking

Reply #12
Quote
rather, it's a workaround of the lazy, clueless "devs" whose only perspective is file size.


harhar, so you rather have brainless end users downloading crap JUST to run a teeny component?????


lawl.

Static vs Dynamic linking

Reply #13
huh? wdk comes with stl, atl, mfc and so on. so what are you bitchin' about without a clue?


edit: nevermind, confused wdk with windows sdk, which does not ship MFC/ATL.
"I hear it when I see it."

Static vs Dynamic linking

Reply #14
Unless you can justify it otherwise, the convention is to use static linking.

We reserve the right to mock you ruthlessly when users come whining about how you failed to properly distribute dynamically-linked versions.

Static vs Dynamic linking

Reply #15
Thanks,
That is the kind of answer I was expecting, in one way or another.
I'll switch to static in my next versions ...

Static vs Dynamic linking

Reply #16
Given that most (if not all) components are made using either VS 2008 or 2010, wouldn't it be better if the VC redist package was included in the Foobar2000 installer? If I'm not mistaken, it won't make much increase in the installer size as everything will be linked dynamically.

Static vs Dynamic linking

Reply #17
How does WDK approach work with 3rd party libs like BOOST? With both static and dynamic linking the linking is easy enough but how about with WDK...? Is it even possible to compile boost "the WDK way" without too much manual work?

Static vs Dynamic linking

Reply #18
kerpondile:
For Boost.Build, you would have to hack around a fair bit to get it to grok the environments that the WDK provides, as it doesn't care about what's in the path or environment variables. It would probably be feasible though, particularly if you had the assistance of a BBv2 guru in getting it into BBv2's core distribution.
As for other build systems, you would have to hope that they are able to emit nmake build scripts, otherwise you're probably quite hosed.

And then there's of course the fact that the WDK yet again has an outdated SC++L (Standard C++ Library, which people looove to misspell as "STL"), which has several known bugs, and the fact that the compilers in the WDK are VC9 era and thus do not have any C++0x features.

Yegor:
There's not a single VS2008 runtime, there's like 12 over the years with the service pack and all the hotfixes, with a serious versioning hell.
VS2010 has had one update to the runtime with SP1, but the 2010 SP1 runtime is designed to be a drop-in replacement for the RTM runtime without problems.
Stay sane, exile.

Static vs Dynamic linking

Reply #19
Quote
rather, it's a workaround of the lazy, clueless "devs" whose only perspective is file size.


harhar, so you rather have brainless end users downloading crap JUST to run a teeny component?????


lawl.


duh, I CAN'T BELIEVE. you STILL don't get it, please switch back to read-write mode, i'm begging you! would you be so kind as to do at least SOME research before making ridiculous posts like this?

if you compile your app with just VS, users have to download and install the VC redist, but users don't have to download ANYTHING if you compile your stuff with the WDK, that's THE WHOLE POINT of this method.

if my memory serves me correctly, this is at least the third time i explain you can reduce app bundle size with the wdk (and take advantage of dynamic linking AT THE SAME TIME), but you still sound like a broken record... it's not good because... just cause. cause you don't have a clue about it, so it can't work. now, let me tell you... it does. i've compiled zlib, openssl, enchant, nss, xchat and its plugins with the WDK. but nooo it won't work, i know. poor me. please, install xchat-wdk on a fresh install of xp sp0. it will run. it must be black magic i think.

ps: saying that a runtime is obsolete if it's older than 1 year is almost as ridiculous (vc10 came out last year).

Static vs Dynamic linking

Reply #20
Personally I also like the dynamic linking idea* with fb2k shipping the runtime library(ies).

*) see msdn/advantages
"I hear it when I see it."

Static vs Dynamic linking

Reply #21
Fine viktor:
* Does this method allow for usage of project files, or is it some contrived makefile method (which would be useless with FB2K)
* Is there any limit to what this method can compile for? Does it allow C++ with heavy template usage, virtual classes, etc? Is there any security issues or issues with some things like the runtime's vector<> implementation, etc?
* Which version of the MSVC runtime does it link against, the most recent, or just the MSVC6 version?

If points 1 and 2 are settled, I would love to hear more about these methods.....
FB2K especially relies on point 2 being settled in regards to certain C++ features being usable.

 

Static vs Dynamic linking

Reply #22
Quote
There's not a single VS2008 runtime, there's like 12 over the years with the service pack and all the hotfixes, with a serious versioning hell.
So? Ship the latest one.

Static vs Dynamic linking

Reply #23
So? Ship the latest one.

2008 is thankfully a closed chapter in the book, as they do not seem to release that many updates anymore.
If it had still been relevant, the latest 2008 runtime is not necessarily in any way backwards compatible with the previous versions of the 2008 runtime.
There's a complex set of forwarding to newer runtimes for some runtime versions, so a bundled "VS2008" runtime would be rather useless for any developers that weren't running exactly the right build environment, which includes among other things having just the right Windows Updates installed. If a newer runtime appears, they might have upgraded "too far".

The above outlines why privately deploying hasn't really been feasible in the past for fb2k.
Microsoft thankfully saw that SxS versioning of the runtime was a bad idea and from 10 and onward have made a backward-compatible regular set of DLLs which helps deployment scenarios like fb2k.

As for "ship the latest one", let's say that fb2k starts shipping VS10 runtimes. What should happen when Dev11 comes out, should it stop bundling the VS10 runtime, breaking any components that rely on it? Should fb2k turn into Nero, with an ever-growing installer?
Stay sane, exile.

Static vs Dynamic linking

Reply #24
Ok, this makes sense.