You're all very welcome! There aren't any specific tutorials. You just somehow put the pieces together. Patching games that don't come with source code is a very specific kind of programming, or more like re-programming and needs the one to get familiar with x86 assembly language and studying disassembled code using tools like OllyDbg. You do find miscellaneous tutorials about certain tasks, but you're mostly on your own I think. I remember watching long time ago the tutorial that demonstrated how to make Notepad show a message box before it starts. The ones for demonstrating how to bypass copy protection in certain programs seem common, but I never found anything that demonstrated how some bugs were found and fixed in certain application/game. And the fact that every problem is unique complicates matters, plus the source code for most games is not available. When it's available, many improvements are possible, look at modern source ports of classic Doom and Quake games.
Generally, what little I've learned about programming, it all seems like some sort of complex puzzle. For example, you have a library with functionality that manipulate images, another for playing sound files and one that contains drawing routines and by combining functionality in all of them, you can make a game. It's really hard to explain and I'm not really good at these things, haven't really put anything particularly useful together from scratch. Improving other people's work is easier. I don't really understand how some people can just sit behind the computer screen and just write and write code, I usually struggle with simple things and like I said, every problem you're trying to solve programmatically is unique. Programming is essentially manipulating data that make the hardware produce the desired result. It probably takes a lot of practice, trial and error before you become proficient at it.
With this particular patch, it came down to understanding basic x86 assembly language, how Portable Executable format works (it's a container for Windows executable files and DLLs) and a couple of details from documentation on MSDN. So I thought, since I knew Max Payne did something in one of the DLLs' DllMain function, which is not supposed to be used for anything or just for really simple initialization, what if I could delay its execution by the time it would be safe to execute its functionality. So I put a variable in its DllMain where I store if the function was already called. If not, it means Windows called it as part of the game request to load its rendering library. When this happens, I bail out, since I know nothing complex (in this case, calls to Direct3D initialization routines) is supposed to be executed until the game's request to load said library is completed (otherwise you can get a deadlock), at which point, its initialization routine in DllMain can be executed without bad consequences. So by this point, I call it again on my own and this time, the check whether the routine was already called once passes and initialization completes instead of not doing anything like the first time. And no bizarre workarounds required.
This is really very special kind of problem and the only reason it came to it is the fact that developers chose to ignore documentation here:
https://msdn.microsoft.com/en-us/librar ... 83(v=vs.85).aspx When you choose to ignore the guidelines, unexpected things can happen and since it works on one computer but not other, some people put the blame on the operating system or graphics drivers. Soulbringer had the same problem before I patched it and I've read that someone discovered the "fix" which includes putting older version of one of graphics driver DLLs in its game folder. Then another person tries it and wonders why the game randomly crashes with strange error. And for the third person, the game doesn't work at all.