You know we already have shims? And they copied the idea from us - so the title of this is interesting.

Copied and enhanced, the best form of flattery. 👍

I'm working on a drop in replacement for the current shimgen.exe:
https://github.com/TheCakeIsNaOH/scoop-style-shimgen

Using this type of shim also has the advantage that current shimgen is trying to read metadata from the targeted exe and use some of the string inside to generate code without even escaping it, which causes easy-to-see security issues. (https://github.com/chocolatey/shimgen/issues/59)

I'm working on a drop in replacement for the current shimgen.exe: https://github.com/TheCakeIsNaOH/scoop-style-shimgen

And I think it's not necessary to implement the GUI option as it's not being used in choco at all: https://github.com/chocolatey/choco/blob/develop/src/chocolatey/infrastructure.app/services/ShimGenerationService.cs#L74

The GUI option is actually used by Install-BinFile:
https://github.com/chocolatey/choco/blob/develop/src/chocolatey.resources/helpers/functions/Install-BinFile.ps1#L105-L107

Given it's not thoroughly tested yet (as listed in Disadvantages), would it not be appropriate to supply a compilation in the Releases section?

Also, what's your impression of this project? https://github.com/71/scoop-better-shimexe It seems like it accomplishes just about all the same things, and it has been thoroughly tested. Like your project, it's also MIT licensed. The only thing it seems to lack is the GUI option.

Why not integrate that project's code since it has been thoroughly tested? You could add what it lacks easily enough, I'm sure.

would it not be appropriate to supply a compilation in the Releases section?

As I noted above, I'm still working on it, so I'm not quite ready for a proper release yet.

Why not integrate that project's code since it has been thoroughly tested? You could add what it lacks easily enough, I'm sure.

The shim is based on that project's code:

It's the shimgen.exe part that primarily needs to testing, not the shim.exe as much.

would it not be appropriate to supply a compilation in the Releases section?

As I noted above, I'm still working on it, so I'm not quite ready for a proper release yet.

Why not integrate that project's code since it has been thoroughly tested? You could add what it lacks easily enough, I'm sure.

The shim is based on that project's code:

It's the shimgen.exe part that primarily needs to testing, not the shim.exe as much.

I'm not entirely sure I understand the need to convert the primary shim code to cpp, is there something I'm missing there?

((Also, ouch, light theme screenshots hurt. You should really use Github's dark theme.))

I'm not entirely sure I understand the need to convert the primary shim code to cpp, is there something I'm missing there?

In theory, two parts:

1. Startup Speed/overheard. Zero overhead from dotnet, in theory could be replicated via Self-contained/R2R.
2. Binary Size (compared to self-contained)

I'm not entirely sure I understand the need to convert the primary shim code to cpp, is there something I'm missing there?

Are you talking about the 71 shim written in C being rewritten in CPP by kiennq?

There is apparently a memory bug in the C version: 71/scoop-better-shimexe#9
And I known CPP better, so that is what I went with.

I'm not entirely sure I understand the need to convert the primary shim code to cpp, is there something I'm missing there?

In theory, two parts:

1. Startup Speed/overheard. Zero overhead from dotnet, in theory could be replicated via Self-contained/R2R.
2. Binary Size (compared to self-contained)

I was referring the conversion from C to CPP

@ImportTaste We're going a little off-topic here. If we need to debate the why's and language specifics, I think that should be discussed in the repository it's being created in rather than here.

@ImportTaste We're going a little off-topic here. If we need to debate the why's and language specifics, I think that should be discussed in the repository it's being created in rather than here.

I don't see why a question relating to the performance of the replacement shims wouldn't be relevant, considering the main sticking point of this issue is the poor performance of ShimGen.

However, having seen this comment: 71/scoop-better-shimexe#9 (comment) and having compiled both myself (using x64_x86 to compile a 32-bit binary, the C version is 114kb; the C++ version is 121kb, a trivial difference), I'm now convinced that @TheCakeIsNaOH is making the right call here.

I don't see why a question relating to the performance of the replacement shims wouldn't be relevant, considering the main sticking point of this issue is the poor performance of ShimGen.

The replacement that is being discussed is not a Chocolatey project and this repository is for Choco issues, not Shimgen issues or it's replacement.

I think we can make a choco package containing the better-shimgen and just replace the original shimgen while installing and place it back while uninstalling.
I have been doing so in my domain with a C# shimgen written by myself and everything works fine so far.

I think we can make a choco package containing the better-shimgen and just replace the original shimgen while installing and place it back while uninstalling.

This would not be allowed on the community repository, at least not without a special exemption.

It should work, it is what I would do to distribute it internally for testing most likely.

Just to confirm what @TheCakeIsNaOH said, we wouldn't permit a package like this on the Community Repository as those packages should not make any changes to any Chocolatey folders or the content within in (other than their package folder).