X86 compilation fails

[broihon]

X86 compilation fails

[Broihon]

The compiler error is caused because the calling convention of ImTheTrashMan is wrong. Casting it is a terrible idea and if called would cause a crash on x86.
I haven't used the debug builds in years and don't know why I've changed the calling convention on them. Compile it with /Gd and it'll be fine (Settings -> C/C++ -> Advanced -> Calling Convention). This will be fixed in the next version.

Micro optimizations like that are pointless. I prefer to use const only for ensuring const correctness. The compiler does the rest.

Spaces in the name look a lot better than GHInjectorX86 and I don't see how spaces would ever cause issues.

The project can handle both unicode and multibyte and basically doesn't use TCHAR at all. However there are a few string references in the DllMain which cause issues because I haven't used the correct unicode macros with %ls which then causes vsprintf_s to do dumb shit and to deadlock (instead of maybe calling the fucking handle I've installed like 2 lines before???).
Again, I'll fix this in the next update but I've tested it now and there aren't any issues with multibyte and unicode.

[netcorefan1]

Thanks for your support. So, from what I understood casting should always be avoided whenever possible especially in X86. When a casting is added and project compiles without even a warning it is easy to feel a fake sense of safety. Thanks for the quick fix, you saved me future headaches from trying to understand where could come from the crashes.
I couldn't work without Debug builds, because is the best and only way where I can see and learn what the code does.

You're right about micro optimizations, it's R# that present so many and sometimes I am tempted to disable them because can become annoying and intrusive.

I rarely see assemblies with spaces and even VS projects templates does not contains space. I believe it is not compliant because can create problems with escaping, namespaces which are tied to assembly name and many other things scripting included. However, in your case (and my too) is different, once the library is loaded it make no more difference if it was loaded as GHInjectorX86 or "GH Injector - X86".

Yes, the deadlock was exactly what I experienced when I tried to load the library and I had hard time trying to figure out the root of the cause because it doesn't even generate an exception or a timeout. It just block for always. Yes, I am afraid that calling the handled at the right time would avoid the issue, but not sure if leaving the uncorrect unicode macros would have caused other troubles.

Would you consider to publish the new releases on NuGet? The process is simple and can be enabled directly from VS. Once enabled you just press the publish button and your lib is on the repo. In this way you can also enable SourceLink support which allow us to step through code if we need and this does not affect in any way how you normally compile the project. Honestly, I think that today no one can survive without NuGet. In addition to that it will makes your lib available to much more people (most of them search packages directly inside VS and if your isn't there they don't know about its existence). I discovered your library just by accident and a good dose of luck.

While exploring the lib I saw many interesting functions that would be very useful, but they are not exported and therefore I cannot access them from my code. It would be nice if you could expose more things from the library.

Your library really deserve to be known from the community!
Thanks