Various People said:
It crashes
It's been stated already, but it bears repeating. We can't fix anything that we can't reproduce, and don't have a crash dump for. A crash dump is not a guarantee that a fix will happen, but nothing
can be fixed without one.
I repeat,
if you do not post a crash dump, then we cannot fix it!
Is there any reason to be using SE's windowed mode over what Windower was doing before? So far that is making Windower less useful and I haven't heard any benefits.
This requires a pretty lengthy explanation, but here goes my best shot at explaining this as simply as I can.
Unfortunately Windower 4 is based on a codebase that is somewhere around 14 years old. The project has passed through many hands. Some of these people wrote
very good code, others... did not. All of these people had different ideas about how to do things, and used
very different code styles.
We have found multiple instances where two or more completely different code paths are used to achieve
exactly the same thing. Did you know that Windower has not one but
two completely different ways to run a command on a new thread? Well, both @ and ! will do exactly that, but they do so using entirely different code paths. It took us something like 4 hours to untangle the code and come to the conclusion that both of them do in fact do exactly the same thing. Ultimately, it has become very difficult to reason about how various internal components within Hook interact with each other.
When we first learned that the function hooking library used by Windower, the one it had been using since the very first release of 1.0, was broken in the preview builds of Redstone 2 (what would later be known as the Windows 10 Creators' Update), I initially tried to accelerate my work on Windower 5. Windower 5 is a complete rewrite that uses its own custom hooking library, and therefor isn't affected. However, it became clear that it was not going to be possible to get enough of the project completed to be a viable solution.
I want to make it clear that this is
not Microsoft's fault. The techniques that are being used here are not "normal". Code injection and rewriting machine code to redirect function calls are the kinds of things viruses do, not normal programs. These techniques generally make use of various undocumented or unsupported quirks of the Win32 API, and Microsoft is under no obligation to keep software that does these things functional. The fact that everything has worked as well as it has for the last 14 years speaks volumes about Microsoft's commitment to backward compatibility.
But I digress. At this point I began the daunting task of replacing this broken library. I had already written a new one for Windower 5, so it shouldn't be that hard to just swap out the broken one for the new one, right? If only things were so easy...
When I wrote the library for Windower 5, I had no intention of it ever being used in Windower 4. I wrote it using features from the newest C++ standards, C++11 and C++14 (these are years, not version numbers). And this brings us to the first problem. For as long as I have been involved with the project, Windower has only been able to build using the Microsoft Visual C++ 2008 Pro compiler. This compiler only supports C++98. When I attempted to import the project into Visual Studio 2017 (which has Microsoft's newest C++ compiler) I was greeted with about 10,000, yes ten thousand, compiler errors. In total it took me about 2 days to work through and fix all of these errors.
When I was done fixing compiler errors. I was finally able to delete the old library and copy in the code from v5. Getting everything to build from here took another 4 hours or so, then finally... the moment of truth. Up until now I had absolutely no way to test any of my work. I just had to keep working, and
hope that I didn't break anything. I clicked run, and everything
seemed to work. But it was late, and I needed to sleep. I checked my changes in to Git, and handed a build off to Byrth, who got various people to test it.
When I checked IRC in the morning it turned out that things had not all gone according to plan. There were
a lot of problems. Some things flat out crashed, others caused the game to deadlock. Arcon fixed most of these over the night, but there was one bug that he couldn't figure out: alt-tab didn't work.
We tried everything we could think of. We poured over all of the code. We found and fixed dozens of obscure, long-standing bugs. We even went as far as to comment out every piece of code related to keyboard input that we could find. But no matter what we tried, we could not get alt-tab to work. Finally, out of desperation I tried to use SE's Windowed mode, and... it worked. Alt-tab worked just like it's supposed to.
We knew that people had reported performance issues with SE's windowed mode, but we had little choice. Shipping Windower with a broken alt-tab was simply not an option, and we do not have the manpower to maintain yet another code base on top of 4.2, plugins and the addon repository. The scope of the changes required to get 4.3 working were simply too great to keep it in sync with 4.2. We
had to move forward using SE's windowed mode.
With some digging (and a tip from an anonymous source) we were able to track down the most egregious performance killers in SE's code and patch around them. With the help of testers we were able to find and fix most of the rest of the serious bugs. (Believe me the stuff you guys have talked about in this thread is just the tip of the iceberg.)
At this point, we had fixed all of the known issues at the time, and we decided we should push 4.3 out on the dev build channel. Byrth wrote up the OP for this thread, and you can see what has unfolded since then.
Quite a few bugs were found and fixed on the dev builds. When we stopped receiving reports of new issues, and we were reasonably confident that we had fixed everything, we pushed the changes to live. And then the ***storm began...
To everyone here who is complaining about the lack of testing, please remember that we're a
very small team. We don't have the resources to do large scale testing. We
rely on people playing on the dev builds to find bugs for us, because there's only so much a few guys on the internet with a couple computers can do. 4.3 was up for
weeks on the dev update stream, and we only pushed it out on the stable update stream once people stopped reporting bugs.
If you want well tested, stable releases, we need people to play on the dev builds. You can have both installed at the same time. If something breaks on dev, report it (with crash dumps!) and fall back to playing on the stable builds while we fix it. If you're not willing to do that, then it's not really fair to tell us that we didn't test thoroughly enough if some bugs slip through the cracks.
