Binary release of SCUMMVM for Windows

General chat related to ScummVM, adventure gaming, and so on.

Moderator: ScummVM Team

Post Reply
carlo_bramini
Posts: 21
Joined: Sat Aug 08, 2015 3:27 pm

Binary release of SCUMMVM for Windows

Post by 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.
User avatar
Dark-Star
Posts: 146
Joined: Sun Oct 30, 2005 9:36 pm
Location: Reutlingen, GERMANY

Re: Binary release of SCUMMVM for Windows

Post by 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
Posts: 21
Joined: Sat Aug 08, 2015 3:27 pm

Re: Binary release of SCUMMVM for Windows

Post by carlo_bramini »

Dark-Star wrote: Sun May 02, 2021 10:46 pm 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.
User avatar
Dark-Star
Posts: 146
Joined: Sun Oct 30, 2005 9:36 pm
Location: Reutlingen, GERMANY

Re: Binary release of SCUMMVM for Windows

Post by 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...
User avatar
rootfather
ScummVM Team Member
Posts: 94
Joined: Tue Mar 31, 2015 11:59 am
Location: Germany
Contact:

Re: Binary release of SCUMMVM for Windows

Post by rootfather »

carlo_bramini wrote: Tue May 04, 2021 9:24 am 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.
Post Reply