The only difference here were the size values on Windows but for this initial call they have been useless for a long time. When this code was written the console buffer still had a fixed width that needed to be set before adding any text.
* the window class name was still ASCII, thanks to some totally pointless and ultimately dangerous type cast to LPCTSTR which rendered all type checks ineffective.
* use wWinMain instead of WinMain so that a Unicode argv gets created. For whatever reason, the ANSI startup leaves this variable empty.
* added a 'disablecrashlog' CCMD for Windows. It is a lot more useful with a debugger present to get the standard crash notification from the system which allows opening a debugger than the crash log and no option to open a debugger.
With localization for non-Latin languages on the support list the multibyte API doesn't cut it anymore. It neither can handle system text output outside the local code page nor can an ANSI window receive text input outside its own code page.
Similar problems exist for file names. With the multibyte API it is impossible to handle any file containing characters outside the active local code page.
So as of now, everything that may pass along some Unicode text will use the Unicode API with some text conversion functions. The only places where calls to the multibyte API were left are those where known string literals are passed or where the information is not used for anything but comparing it to other return values from the same API.
currentUILevel is now primaryLevel.
For ZScript, currentVMLevel was added. This is also exported as 'level' and will change as needed.
This also means that no breaking deprecations will be needed in the future, because in order to sandbox a level only 4 variables need to be handled: level, players, playeringame and consoleplayer.
The remaining global variables are not relevant for the level state.
The static 'level' has been mostly removed from the code except some places that still need work.
This made reviewing the code for accessing the global state hard, because the doomdef.h contains mainly constants, this particular item was the only thing in there that represents actual engine state.
Since the SpawnedThings array is still available when polyobjects are spawned it makes no sense to create an expensive linked list in P_SpawnMapThing.
This can be done far better by scanning through the array again and collect all matching items in a second array.
At least one version of Windows SDK (10.0.17134.0) has broken _pgmptr/_get_pgmptr()
It points to an empty string for multi-byte character set applications
GetModuleFileName() is now used instead regardless of compiler/toolchain
Added extra guard against unexpected program paths to avoid crashes
https://forum.zdoom.org/viewtopic.php?t=60598
Restored old exception handling for 32-bit Windows executable
Tested on 32-bit Windows XP (previously exited without notification), 64-bit Windows 7 and 10 (previously deadlocked in system DLLs)
This is to ensure that the Class pointer can be set right on creation. ZDoom had always depended on handling this lazily which poses some problems for the VM.
So now there is a variadic Create<classtype> function taking care of that, but to ensure that it gets used, direct access to the new operator has been blocked.
This also neccessitated making DArgs a regular object because they get created before the type system is up. Since the few uses of DArgs are easily controllable this wasn't a big issue.
- did a bit of optimization on the bots' decision making whether to pick up a health item or not.
This one was particularly nasty because Windows also defines a DWORD, but in Windows it is an unsigned long, not an unsigned int so changing types caused type conflicts and not all could be removed.
Those referring to the Windows type have to be kept, fortunately they are mostly in the Win32 directory, with a handful of exceptions elsewhere.
- Replaced GTK/OS X (note different from Cocoa) clipboard code with SDL clipboard API.
- Removed requirement to link to GTK in order to compile with GTK support.
- GTK is no longer init'd if the GTK IWAD picker is not used.
- Our usage of GTK is such that the dynamic loader can work with both GTK2 and GTK3 depending on what's installed.
- Since we're accumulating a lot of library loaders I've built a generic interface as FModule which replaces TOptWin32Proc and the loaders in the OpenAL and Fluidsynth code.
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
This cuts down on as much message noise as possible, outputs everything to a file specified as a parameter and then quits immediately, allowing this to run from a batch that's supposed to check a larger list of files for errors.
Multiple outputs get appended if the file already exists.
The RichEdit control can become quite slow with large amounts of text being added constantly.
Since anything that gets added while the game is running can't be seen anyway unless a fatal error is produced, it buffers the text locally now, without any processing, and only adds it to the RichEdit control in case a fatal error causes the control to be displayed again.
