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: Change of rules regarding plugins (Read 5216 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Change of rules regarding plugins

Hey guys!

I was just wondering: wouldn't it be a good course of action if all plugins got released as static builds? I realize they are a bit bigger but so what. The gain in size is negligible and chaos and mayhem are avoided... I've been using foobar for some time now and there's tons of strange M$ (and others) libraries in my foobar folder. If all plugins for 0.9 would be released static though, at least the new install will not be so cluttered.
For example: foo_mod is the only component that needs bass.dll. the audioscrobbler-plugin needs the libcurl.dll and so on. Why not stuff those releases neatly into one file? Or are there some legal troubles I'm unaware of?

Change of rules regarding plugins

Reply #1
Unless the developer of said plugin is clueless, plugins will only link to libraries available on all target OS'es (msvcrt.dll, for instance, is there since Win98).

Now, unless you can unwrap bass.dll from the Petite protection and then use something like PeBundle to attach it to your plugin (or do it yourself manually), you'll pretty much have to link it dynamically as it is. Same thing for most non-statically-linkable libraries.

What you're proposing as a rule is more of a common sense measure that sane developers are already using.

Change of rules regarding plugins

Reply #2
Quote
Unless the developer of said plugin is clueless, plugins will only link to libraries available on all target OS'es (msvcrt.dll, for instance, is there since Win98).[a href="index.php?act=findpost&pid=338019"][{POST_SNAPBACK}][/a]
So you're suggesting that developers only use libraries that are 7 years old?

Change of rules regarding plugins

Reply #3
No, that's not what I'm saying. What I'm saying is, if they want to use libraries that are not commonly widespread, they should link them statically.

Change of rules regarding plugins

Reply #4
That causes a lot of extra memory overhead. There is no reason for several plugins, Office, and other programs to load their own CRT for themselves. There is absolutely nothing wrong with DLLs since Windows 2000.

Change of rules regarding plugins

Reply #5
Quote
if they want to use libraries that are not commonly widespread, they should link them statically.
[a href="index.php?act=findpost&pid=338320"][{POST_SNAPBACK}][/a]

they should just distribute them correctly if they are dynamically linked instead of just assuming the user will get them if they don't already have them (since you're likely to piss people off / worry those who don't understand when the error message on loading appears).  static has it's benefits but really the developer should think ahead and if they need support dlls then to make sure they create at least a basic installer to handle it all).

but as FrozenSpoon points out, you have a larger memory overhead by static linking which even with modern machines having a decent amount of ram, if everyone did it then it would be used up even easier than it already is at times.

-daz

Change of rules regarding plugins

Reply #6
zyrill never said anything about statically linking C runtime libraries. Statically linking libraries that are already included with the OS would obviously be a braindead thing to do.

Instead, he pointed out, that dyanamic linking libraries which get included with foobar2000 or its components, should be linked statically to the relevant components instead.

Statically linking libraries that are only used by a single component does not have a memory overhead, rather the opposite - unreferenced symbols are thrown out.
Why don't we all act silly for a while, just like me?

Change of rules regarding plugins

Reply #7
The only C runtime library that is included with all relevant versions of Windows (up to Windows XP and 2003) is the VC6 runtime, while the C runtimes for VS7.0 and VS7.1 are usually installed per application like Microsoft recommends.
Edit: To make things worse, there are different (sometimes incompatible) versions of the several runtimes available; for example there exist different versions of msvcrt.dll (the VC6 runtime).

It should be noted that VC6 is not capable of compiling the foobar2000 0.9 SDK. All the 0.9 betas have used static linking.

Unused parts of dynamically linked libraries will not be paged in at runtime. Even though used an unused parts may be mixed in a single memory page, the choice of algorithms and datastructures used in a component usually has a far greater impact on the working set size than that, but that should be discussed in another thread.

Statically linking additional libraries may not be possible because there is no static version of the library available (because the library is distributed only as binary) or because of licensing issues (think LGPL). I think how to link additional libraries should be decided by the component developer on a case-by-case basis.

Nevertheless, a developer should in all cases make it clear what DLLs a component needs, and include them with the component, or if that is not possible at least provide instructions on how to obtain them.

Change of rules regarding plugins

Reply #8
Perhaps you could just zip all required lib's.

If the user already has the prerequisites filled, than all he is doing is overwriting the file.

Change of rules regarding plugins

Reply #9
Some of us package each of our components separately, which would either mean a separate download for the run-time code, or bundling 800KB worth of run-time code with each component. It also makes the dependencies much more obvious, and thus prone to user shoving them in their system folder when they shouldn't.