- Joined
- Jan 14, 2008
- Messages
- 9,218
- Reaction score
- 1,566
- Points
- 203
- Location
- VA
- Website
- alteaaerospace.com
- Preferred Pronouns
- he/him
What does the orbiter dev comumity think to static linking. I know dbeachy is a fan. I can do it of course, but I always felt it was wrong to give a user a runtime they cannot update. But if it's in a specific use-case (i.e. Orbiter) versus a general use-case (e.g. supporting web e-commerce), then maybe the risk is lower?
I can chime in with my two cents in the pro-static linking camp. The Visual Studio runtime libraries implement all the standard C++ library calls like new, delete, sprintf, fopen, etc. Normally, users never have to deal with installing these manually, because a program's installer is supposed to also automatically install any runtime libraries the program needs (this is of course only necessary if the program does not link statically with those libraries).
In my experience I have never had to manually upgrade a Visual Studio runtime library because of a bug, and speaking personally, if the community did discover a bug in my add-on(s) that I traced to the Visual Studio runtime libraries (which, again, seems extremely unlikely), I would much rather relink and release an updated version of my add-ons with the updated runtime libraries linked in statically rather than relying on all my add-ons' new and existing users to go out and manually install the updated Visual Studio 2013 redistributable package themselves. My reasons are:
- For new users that download an add-on, many users already have some version of the Visual Studio 2013 redistributable package previously installed by some earlier software's installer, and so installing an Orbiter add-on that requires those same redistributables would load just fine even with the already-installed (possibly buggy) Visual Studio redistributable package. They could even have a redistributable version older than the static version of the package I linked and tested with.
- By running with a different version of the redistributables than I linked and beta-tested with, it is also possible that the different (even if newer) version of the redistributable package has a bug that the version I tested with does not.
- It is neither easy nor obvious for the average user to figure out what exact version of the Visual Studio redistributables they have installed, and so this would make it harder to troubleshoot issues if indeed it was traced to a problem in the redistributable libraries.
- It is confusing for users to figure out which redistributable package they need to install: x86 vs. x64, for example. As I said, normally a software's installer automatically installs the redistributable package the software needs, but Orbiter add-ons do not typically have an installer: they are just a zip package, and so it is left to the user to read the fine print, locate the correct redistributable package, and install it separately.
- By far, the main reason I prefer to statically link with the redistributable files is to make it easier for users to install and run the add-on: with static linking, it "just works", but with dynamic linking, if the user doesn't happen to already have the correct Visual Studio redistributable files installed, it is a poor user experience when pilots try to load up a new add-on and it dies with a cryptic error in Orbiter.log. For every user who posts a question about it on the forum, there are probably 10 more who just give up and never get the add-on working. Or worse, they google for the exact error text that pops up and wind up installing one of those phony download packages that actually installs some malware.
And of course we have the Wine issue cited here.
But anyway, I am not militant about this, it's just my opinion, and I would not judge other authors for perferring dynamically linking to the redistributable files rather than statically. :tiphat:
P.S. as a side note, there is only one technical reason I am aware of to ever use dynamic linking instead of static linking, and it does not apply to Orbiter: if you are linking with another DLL or EXE that needs to free a memory back to the heap that your software allocated (or vice-versa), then you have to use dynamic redistributable linking so that both DLLs/EXEs use the same memory heap. (This would normally be considred bad programming form, however, since you should normally allocate memory in the constructor and free it in the same object's destructor.) In any case, this situation does not occur when linking with Orbiter because the Orbiter core does not free memory blocks that an add-on allocated, nor does an add-on free memory blocks that the Orbiter core allocated. In other words, the Orbiter core allocates and frees its own memory blocks, and each add-on allocates and frees its own memory blocks. You can safely pass memory blocks from different runtime heaps between DLLs and EXEs that use them, and this is what happens when a statically linked add-on runs with Orbiter.exe. (The other now-obsolete reason to use dynamic runtime linking is because it does use marginally less RAM than having each DLL/EXE include a copy of the actual code for the runtime library calls it makes in its program memory -- back in the early days of Windows, that extra several K of RAM usage did matter.)