Smaller Scoop shim executable

[jewlexx]

I have created an alternative Scoop shim executable called miniature (because it's very small), in an effort to replace the rather large shim executable currently used, as well as its sister .shim files.

This executable uses Windows' STRINGTABLE Resource to embed the target executable and arguments in the shim directly, removing the external .shim file, and erasing the need to read from disk, and parse said file altogether.

It also weighs in at 20KB, which is about 17% of better-shim-exe at 113KB.

There's also a sister program in the same repository used to create these shims, as unfortunately it's not as simple as editing a text file.

I understand this is not a big problem I've solved, and this solution may introduce more issues, but it may be time to update the default shim used by Scoop (especially since better-shim-exe hasn't had an update in 6 years), using more modern technologies, and a much smaller footprint.

[chawyehsu]

While I believe it does feel more modern sometime using Rust (if it's the point you want to express), the size difference does not convince that much. As I understand it the comparsion seems to be unfair that the miniature executable is dynamically linked (I haven't inspected it though, seems obvious), while the 71shim is statically linked.

There's discussion about whether should the shim executable be dynamically linked before, no decision was made though. For reference, the size of kiennq-shim would be <17KB when it's dynamically linked.¹

The current shims are robust enough, improved for years. But users might want to use their own shim implementation, and this is why I tried to propose ScoopInstaller/Scoop#6209. FWIW, the priority of the feature is low though.

Footnotes

1. https://github.com/kiennq/scoop-better-shimexe/issues/12 ↩

[jewlexx]

I'm not too sure what you mean when you say its dynamically linked? The main decrease in size was from removing the standard library altogether, and I've not consciously dynamically linked anything.

I do however understand the lack of urge to replace the current shim implementation, as it does do it's job.

[jewlexx]

I tried compiling with crt statically linked, and it does increase the size of the binary dramatically.

I still like the proposition of a self-contained shim that doesn't rely on a .shim file, but I do completely understand the hesitancy to replace the current shim implementation.

[chawyehsu]

Just inspected, and it does link dynamically.

dumpbin.exe /DEPENDENTS .\miniature.exe
Microsoft (R) COFF/PE Dumper Version 14.43.34809.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file .\miniature.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    kernel32.dll
    user32.dll
    shell32.dll
    oleaut32.dll
    VCRUNTIME140.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll

  Summary

        1000 .data
        1000 .pdata
        2000 .rdata
        1000 .reloc
        4000 .text

By contrast:

dumpbin.exe /DEPENDENTS .\supporting\shims\71\shim.exe
Microsoft (R) COFF/PE Dumper Version 14.43.34809.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file .\supporting\shims\71\shim.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    SHELL32.dll
    KERNEL32.dll

  Summary

        2000 .data
        7000 .rdata
        2000 .reloc
       14000 .text

[jewlexx]

I've just released a new version which prints the following output from DUMPBIN:

dumpbin /dependents target/x86_64-pc-windows-msvc/release/miniature.exe
Microsoft (R) COFF/PE Dumper Version 14.41.34120.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file target\x86_64-pc-windows-msvc\release\miniature.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    KERNEL32.dll
    USER32.dll
    SHELL32.dll
    OLEAUT32.dll

  Summary

        1000 .data
        1000 .pdata
        1000 .rdata
        3000 .text

Sorry to keep bothering you but does this mean its statically linked? I removed all references to the c runtime, and as far as I can tell it works entirely without it, with some help from compiler-builtins.

[kiennq]

It doesn't depend on vcruntime14 so it should be good even if you install it on previous version of Windows.
For statically link or not, it still depends on 4 dlls so strictly saying, it's not fully standalone. But we don't have .lib files for those 4 dlls anyway so statically link against them are impossible and a waste since they're always shipped together with Windows.

Talking about size saving, there're other options like ScoopInstaller/Scoop#3910, which essentially make it a single executable file and other files are just a hard link to it. That will save much more if you think of the number of shim files we are installing normally.

[jewlexx]

I wasn't aware of #3910. That seems like a good option too, and as @chawyehsu was saying hopefully there'll be some movement on configuring shimming, with custom executables and/or hard links as an option.