Regshot Static

[lajjal]

I have searched so I think this not in the forum yet but I might have missed it. Does anyone know the difference (other than size) between the regular and static releases of RegShot at regshot.ru? They look and act the same.

[Hydaral]

You can have two types of dependency linking: dynamic and static. Dynamic assumes that the libraries can be found in a specific location (eg \windows\system32), and may not be packaged with the app. Static means that any dependencies that are required are in a sub-directory of the app (and usually packaged with it, that's why it is larger).

Static ensures the most portability.

[lyx]

Sorry, but this is simply untrue information.

Dynamic linking means that libraries which an application needs, are stored in seperate files (think "DLLs"). When the application is launched (or in some cases afterwards), these libs are then attached (linked) to the application. It's called dynamic linking, because this attachment happens when the application is launched/running. WHERE those additional files may lie, is completely up to the OS and the programmer. On windows, DLLs are typically searched in multiple locations - first in the application directory (or some subdirectory), then in system32 and a few other places.

Static linking means, that these additional libs are attached to the application already at the moment when the application is compiled - as a result, these DLLs are then stored INSIDE the executable. If an application statically links all required libs, the result is a single executable file, that contains everything.

There are pro's and con's for both approaches, and what makes sense partially even changes on a per-lib basis. What for portability matters simply is that all uncommon dependencies (libraries) are distributed together with the application and reside inside the application directory - regardless of if its multiple files or just one big file.

Thats the theory and technical background. In practice, developers often handle dyn-linked releases and static-linked releases differently: For dynlinked releases, they tend to NOT distribute some required DLLs with the application (they expect that you do already have them installed somewhere (i.e. yes "system32")), while for static-linked releases, they just put everything into the executable. So, even though technically, dynlinking and staticlinking should make no difference to portability, the way how developers handle it may result in static-linked binaries to be more portable.

[lajjal]

So it seems that, to be effective, one must have both the dynamic and static versions.

[SYSTEM]

So it seems that, to be effective, one must have both the dynamic and static versions.

One of the most important advantages of dynamic linking is smaller executable...

[lajjal]

I think I totally missed the point here but I see the light correctly now, I hope. I was thinking that the dynamic / static thing had to to with the function of regshot but it's really just whether the programmer included library files when regshot was complied or left them out to be found in the OS when run. So for the best coverage the static is preferred because it expects less from the operating system. This would be important if the app is to run in wine.

[lyx]

Correct. If an application just puts everything into the app dir as an executable and multiple "Dynamically Linked Libraries" (DLLs), that would work just as well, but for portability, just downloading a statically linked app is easier, because you dont need to figure out IF the dev actually distributed all required files.

Also something to take into account: Since on windows, DLLs are usually automatically searched in multiple places (typically first the app dir, subdirs, then system32 and other OS-dirs), it is on windows possible to make an app portable, that did not put all required files in the appdir. The most impressive example is directX: If a game requires a certain directX version, then you can just copy the required DLLs into the appdir, and it will then work on any machine, even if it doesnt have a certain directx update installed. The only trouble with this really nice property of windows, is figuring out which DLLs outside the appdir an application actually needs. There are tools for that, but the procedure requires some lowlevel-programming understanding and isn't straight forwards - thus, endusers are typically not able to make use of this feature.

[Hydaral]

Sorry, but this is simply untrue information.

Dynamic linking means that libraries which an application needs, are stored in seperate files (think "DLLs"). When the application is launched (or in some cases afterwards), these libs are then attached (linked) to the application. It's called dynamic linking, because this attachment happens when the application is launched/running. WHERE those additional files may lie, is completely up to the OS and the programmer. On windows, DLLs are typically searched in multiple locations - first in the application directory (or some subdirectory), then in system32 and a few other places.

Static linking means, that these additional libs are attached to the application already at the moment when the application is compiled - as a result, these DLLs are then stored INSIDE the executable. If an application statically links all required libs, the result is a single executable file, that contains everything.

Weird, I did actually know that, but for some reason when I was writing the post, I wrote the thing about sub-directories. I chose Delphi as my preferred programming language precisely because the statically linked executable was smaller than the C++ one.