Less than a month from previous release. :grinning:
If you've been following the issues tab, you saw that a good bunch of the problems reported there had something to do with Visual C++ runtimes redistributable. To be honest, I myself had my share of problems with that. I can tell you that most of the time I intentionally deny admin permissions to Steam before it attempts to "perform first time setup" - to avoid that random time when VC redist randomly decides to enter an infinite loop for random reasons.
After #15, I looked around on how to achieve static linking. As I told @Mgamerz on Skype, I would've done it sooner if I knew this was possible, but somehow I always had the impression that anything generated under Visual Studio had to depend on something from Microsoft (besides Windows itself). And here they are: file size is larger, but the need of a separate VC runtime install, apart from those "performed" by Steam/Origin, is gone. In other words, if vanilla games are already running on your machine, you won't need to worry about "tricks" or whatever to get my binkw32 proxies to work for you.
The ASI loader will load plugins from one folder only now. As @Mgamerz pointed in #12, the old way of looking for plugins in two places can cause game crashes, and even some other oddities as I found myself.
From DLL Search Order at MSDN:
"If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL."
Turns out that the only way of bypassing that is to load DLL's by specifying their full path, which is how the ASI loader actually loads ASI files with LoadLibrary. :sweat_smile:
With the new code, the ASI subfolder is effectively the main place for ASI plugins now. The game's executable folder will only be used if the ASI subfolder is missing, or nothing could be loaded from there (either because of no files or load error).
OK, so... huh, 7 months since last release?
The new log file scheme attempts to write the log file to the current user's Documents folder first, where write rights are normally available to anyone (well... I mean anyone who is a "current user" anyway). With #8, it came to my attention that people may install the game to (or run it from) a protected folder like Program Files.
A WinAPI function called SHGetKnownFolderPath is used to get the user's Document folder. If it fails, then the game's folder will be used instead. And as that is an already proven minefield, I coded the log writing function in a way where no crash may occur if the log file hasn't been properly created.
I mentioned PathCombine in #8, but I figured it wouldn't be needed as the documentation for SHGetKnownFolderPath explicitly says the returned string doesn't contain a trailing backslash. I was in doubt about the case where the user has mapped his/hers Documents to the drive root... well, who the hell would map Documents to the drive root?
SHGetKnownFolderPath works only on Windows Vista or above, so XP purists will have to resort to r1 if they want compatible binkw32 patches.
The binkw32 projects are now under VS2015, and require the VC++ 2015 runtimes. The target platform version is "8.1", but according to MSDN Windows 8.1 SDK is backward compatible to Vista and 7. The WINVER and _WIN32_WINNT macros are defined as 0x0601 (Windows 7), reflecting my decision of not supporting older versions of Windows.
I don't know if this is worth mentioning, but the reason why files in this release are .zip instead of .7z is because I still haven't installed a dedicated file packager/compactor on my new PC. Maybe I should keep the future releases like this, .zip works "out of the box" on Windows anyway.
After almost 6 months and 15 commits... due to popular demand (#2) , I'm making now a proper release for this repository.
I don't think I need to write too much here... "install" instructions are already pretty clear in the main readme.