Binary release of SCUMMVM for Windows

[carlo_bramini]

Hello,
I was wondering if there is a particular reason because the stable executables of SCUMMVM for Windows are released as a single, big monolithic file without much dependencies rather than the main executable and a number of extra DLLs.
Sincerely.

[Dark-Star]

What do you mean? Why ScummVM comes with only 4 DLLs instead of, say, 8, 13 or 53?

Or why those 4 DLLs are there and not also included in the .exe?

[carlo_bramini]

What do you mean? Why ScummVM comes with only 4 DLLs instead of, say, 8, 13 or 53?

Well, this is my case as an example: the speed is not exactly the best when you run SCUMMVM on an Intel Atom, but if you select FluidSynth support then the program slow down a lot, becoming quite difficult to use. However, the performances can change greatly if FluidSynth is compiled for using rendering sound with 32bit floating point math rather than 64bit math. If the SCUMMVM executable was compiled by connecting to external libraries, I could do it in a simple manner, by just replacing the DLL with another one.

However, it is also true that I can rebuild SCUMMVM myself in that way... but, for future releases, I was just wondering if the decision to have not "8, 13 or 53" external DLLs was linked to some particular needs or not. I don't think it is a problem of disk space, because at the end it is more or less the same.

Sincerely.

[Dark-Star]

No idea if there was any deeper thought into this, but one advantage of compiling as much as possible statically (i.e. into the EXE) is that it saves you some trampoline jumps and allows link-time optimization, which can potentially improve speed.

In your case, though, I guess it would be better to compile an optimized build for your architecture...

[rootfather]

Well, this is my case as an example: the speed is not exactly the best when you run SCUMMVM on an Intel Atom, but if you select FluidSynth support then the program slow down a lot, becoming quite difficult to use. However, the performances can change greatly if FluidSynth is compiled for using rendering sound with 32bit floating point math rather than 64bit math. If the SCUMMVM executable was compiled by connecting to external libraries, I could do it in a simple manner, by just replacing the DLL with another one.

However, it is also true that I can rebuild SCUMMVM myself in that way... but, for future releases, I was just wondering if the decision to have not "8, 13 or 53" external DLLs was linked to some particular needs or not. I don't think it is a problem of disk space, because at the end it is more or less the same.

Distributing ScummVM as static as possible is indeed done on purpose, since we can then use optimization strategies like LTO. Furthermore, it avoids a lot of issues since we had library version issues in the past, so even though swapping out DDLs is indeed possible, it might break and cause unnecessary support overhead. SDL2 is excluded here since it's quite robust and we were indeed able to work around some specific issues by swapping out the DLL file.

While I fully understand what you are trying to do here and it makes sense to me - I consider this a very edge case.

The way the Win32 executable is distributed/built won't change in the near future, sorry.