DLL loading done by Windows instead of an injector

[arukateru]

Is your feature request related to a problem? Please describe.

The injector can crash or not start up for whatever reason sometimes, and it also creates an extra 2 processes (itself and dllhost) that are not necessary.

Describe the solution you'd like

In my opinion, it is a much stabler and safer option to have the DLL automatically be loaded into the application by Windows than it is to use an injector.

Area of issue

Installation/Other

Alternatives you've considered

No response

Additional context

No response

[ge0rdi]

Open-Shell uses COM emulation as primary mean of loading into Explorer. That way our code is loaded when Explorer initializes some COM class during initialization.

This is official way supported by Windows.

Injection is used just after installation (to load into existing Explorer right away) or when COM emulation fails to load Open-Shell during startup for whatever reason.

I'm not sure if that is what you meant. So if you have more concrete ideas how to improve Open-Shell, please, let us know.

[arukateru]

I think it fails to load it every time, because in my testing the injector always must be running for Explorer to load Open-Shell. I'm not sure how StartIsBack does it, but its DLL gets loaded by Explorer every time including when it is running as admin or running on the system account and with no injector process.

[ge0rdi]

I see that during Explorer startup our StartMenuHelper gets loaded (via COM emulation) and it then runs StartMenu.exe -startup to hook the Explorer. So basically the hooking method is the same no matter of circumstances. We use COM emulation just to trigger the hooking early with Explorer.

Not sure why it is done like this, it dates back to Classic Shell. I guess it can be improved so that there is no need for StartMenu.exe to run.

BTW Do you have any issue with Open-Shell starting? Or is it just about improving things?

[NeedsMoar]

I have a suggestion for standardization's sake

https://github.com/microsoft/Detours

Looking at the injection code on this end it's some custom-written binary patching stuff that's really simplified and will work as long as nothing changes significantly about the binary builds. It's x86/x64 only, too. Normally I'd say if it works it works, but Microsoft has the above library specifically to do things like inject DLLs into other binaries and redirect functions... It's been around for a long time and is the supported way of doing things, or at least as supported as it gets. It has its own disassembler so it can trace and find an appropriate patch point in the case of trampolines and does the patching more safely regarding large memory and some other things.

There are bugs for ARM64 right now but it has support for that arch as well if your project ever felt like supporting some future Windows ARM device which I'm sure will have an even less usable start menu. :P