Visual Studio 2019 and the end of Windows XP support

[sinisterseed]

Essentially.

XP has been dead since 2014, on April 8th it'll be exactly 6 years since it reached EOL status, there's no reason to still maintain support for it, it's time to move on... it's a relic at this point. It only implies extra work for virtually no payoff - judging by the survey results, less than 0.13% of the user base still use it. It's unreasonable and ridiculous.

[Graf Zahl]

XP is not dead... unless i'm a zoombie... either way thats not a excuse to not have your program working with MingW... fgs...

It wouldn't run on XP anymore anyway, all XP compatiblity code has been removed by now and the dependencies on Vista and up are a requirement. Didn't you read the first post? When running the survey last summer we has 42 XP users among 30000 reports. That's not worth any added work.

[Grizzly]

You can always run it off a Linux dual boot. Or a linux usb stick.

Or, err, install windows 10 and run Windows XP in a VM?

[wildweasel]

XP is not dead...

Except that Microsoft aren't providing security updates for it anymore, and you'd be hard pressed to find modern software that still supports it, outside of the occasional hobbyist project.

either way thats not a excuse to not have your program working with MingW... fgs...

Hey, feel like fixing that for us? Contributions are welcomed.

[Rachael]

heh and VS is required to compile this on windows? why not mingw? then it would not be a problem for XP
despite requiring useless switches just show how terrible devs are becoming nowadays...

So devs are trash, and the only evidence you have to support this claim is that they will not support an ancient operating system that you somehow have managed to be less than 1% of the holdouts still using it?

I really have nothing to say to you. It's quite obvious that you will not listen to reason no matter how it's presented to you.

[Redneckerz]

heh and VS is required to compile this on windows? why not mingw? then it would not be a problem for XP
despite requiring useless switches just show how terrible devs are becoming nowadays...

XP is an unsupported OS. Considering GZDoom's feature set, it makes little sense to support something that has seen very little usage per Graf's surveys.

The general implication that people are terrible devs for dropping support for an OS where the GZ userbase isn't located is kind of mindboggling to hear, really.

XP is not dead... unless i'm a zoombie... either way thats not a excuse to not have your program working with MingW... fgs...

Unofficially, it isn't. But officially (As in: Microsoft) it is. Its not even in an Extended Support stage.

There is a sound argument for why XP is not supported beyond the fact that even Microsoft itself does not support it anymore - The survey's. I am sure you can those and figure out the numbers that come from it.

If both arguments fall flat, then there is also a third option - Fork GZDoom and make it able to be compiled by MingW. Its open source, after all.

[drfrag]

unless i'm a zoombie

You're a zombie then (and me too). But i've actually submitted a PR to fix MinGW compilation again and as usual it's harmless.
I haven't tried to run it on XP tough, BTW there's a new and exciting crash on exit in SoftPoly.

---

Code: Select all • Expand view

Starting program: c:\DEV\gzdoom\release\gzdoom.exe
[New Thread 4048.0xbf0]
[New Thread 4048.0x6e4]
[New Thread 4048.0x768]
[New Thread 4048.0x8a4]
[New Thread 4048.0x1158]
[New Thread 4048.0xe04]
[New Thread 4048.0x11bc]
[New Thread 4048.0x101c]
[New Thread 4048.0x1498]
[Thread 4048.0x101c exited with code 0]
[New Thread 4048.0x14d4]
[New Thread 4048.0xcf0]
[New Thread 4048.0xfc8]
warning: Invalid parameter passed to C runtime function.
[Thread 4048.0x14d4 exited with code 0]
[Thread 4048.0xe04 exited with code 0]
[Thread 4048.0x11bc exited with code 0]
warning: Critical error detected c0000374

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x00000000776b40c0 in ntdll!RtlUnhandledExceptionFilter ()
   from C:\Windows\SYSTEM32\ntdll.dll
#0  0x00000000776b40c0 in ntdll!RtlUnhandledExceptionFilter ()
   from C:\Windows\SYSTEM32\ntdll.dll
#1  0x00000000776b4736 in ntdll!EtwEnumerateProcessRegGuids ()
   from C:\Windows\SYSTEM32\ntdll.dll
#2  0x00000000776b5942 in ntdll!RtlQueryProcessLockInformation ()
   from C:\Windows\SYSTEM32\ntdll.dll
#3  0x00000000776b75f4 in ntdll!RtlLogStackBackTrace ()
   from C:\Windows\SYSTEM32\ntdll.dll
#4  0x000000007765dc8f in ntdll!RtlIsDosDeviceName_U ()
   from C:\Windows\SYSTEM32\ntdll.dll
#5  0x000007fefecc10c4 in msvcrt!free () from C:\Windows\system32\msvcrt.dll
#6  0x0000000000570330 in std::default_delete<RenderMemory::MemoryBlock>::operator() (this=0x1cecc840, __ptr=0x11b93c40)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/unique_ptr.h:347
#7  std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> >::~unique_ptr (this=0x1cecc840, __in_chrg=<optimized out>)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/unique_ptr.h:274
#8  std::_Destroy<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> > > (__pointer=0x1cecc840)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/stl_construct.h:98
#9  std::_Destroy_aux<false>::__destroy<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> >*> (
    __last=<optimized out>, __first=0x1cecc840)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/stl_construct.h:108
#10 std::_Destroy<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> >*> (__last=<optimized out>,
    __first=<optimized out>)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/stl_construct.h:137
#11 std::_Destroy<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> >*, std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> > > (__last=0x1cecc848,
    __first=<optimized out>)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/stl_construct.h:206
#12 std::vector<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> >, std::allocator<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> > > >::~vector (
    this=0x1da25828, __in_chrg=<optimized out>)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/stl_vector.h:567
#13 RenderMemory::~RenderMemory (this=0x1da25810, __in_chrg=<optimized out>)
    at C:/DEV/gzdoom/src/rendering/swrenderer/r_memory.h:7
#14 PolyFrameBuffer::~PolyFrameBuffer (this=0x1da25000,
    __in_chrg=<optimized out>)
    at C:\DEV\gzdoom\src\rendering\polyrenderer\backend\poly_framebuffer.cpp:78
#15 0x00000000005705bd in PolyFrameBuffer::~PolyFrameBuffer (this=0x1da25000,
    __in_chrg=<optimized out>)
    at C:\DEV\gzdoom\src\rendering\polyrenderer\backend\poly_framebuffer.cpp:78
#16 0x0000000000401640 in I_ShutdownGraphics ()
    at C:\DEV\gzdoom\src\win32\hardware.cpp:101
#17 0x00000000005a18f3 in D_DoomMain () at C:\DEV\gzdoom\src\d_main.cpp:2899
#18 0x000000000040e35e in DoMain (hInstance=hInstance@entry=0x400000)
    at C:\DEV\gzdoom\src\win32\i_main.cpp:963
#19 0x000000000040eae6 in wWinMain (hInstance=0x400000,
    nothing=<optimized out>, cmdline=<optimized out>,
    nCmdShow=<optimized out>) at C:\DEV\gzdoom\src\win32\i_main.cpp:1289
#20 0x00000000004013df in __tmainCRTStartup ()
#21 0x00000000004014eb in WinMainCRTStartup ()


Edit: LZDoom still runs on XP (well it should).

[Graf Zahl]

I haven't tried to run it on XP tough

It won't. All code to work around missing system call entry points in XP has been removed, GZDoom won't start on XP even if compiled with MinGW.

, BTW there's a new and exciting crash on exit in SoftPoly.

Code: Select all • Expand view

Starting program: c:\DEV\gzdoom\release\gzdoom.exe
[New Thread 4048.0xbf0]
[New Thread 4048.0x6e4]
[New Thread 4048.0x768]
[New Thread 4048.0x8a4]
[New Thread 4048.0x1158]
[New Thread 4048.0xe04]
[New Thread 4048.0x11bc]
[New Thread 4048.0x101c]
[New Thread 4048.0x1498]
[Thread 4048.0x101c exited with code 0]
[New Thread 4048.0x14d4]
[New Thread 4048.0xcf0]
[New Thread 4048.0xfc8]
warning: Invalid parameter passed to C runtime function.
[Thread 4048.0x14d4 exited with code 0]
[Thread 4048.0xe04 exited with code 0]
[Thread 4048.0x11bc exited with code 0]
warning: Critical error detected c0000374

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x00000000776b40c0 in ntdll!RtlUnhandledExceptionFilter ()
   from C:\Windows\SYSTEM32\ntdll.dll
#0  0x00000000776b40c0 in ntdll!RtlUnhandledExceptionFilter ()
   from C:\Windows\SYSTEM32\ntdll.dll
#1  0x00000000776b4736 in ntdll!EtwEnumerateProcessRegGuids ()
   from C:\Windows\SYSTEM32\ntdll.dll
#2  0x00000000776b5942 in ntdll!RtlQueryProcessLockInformation ()
   from C:\Windows\SYSTEM32\ntdll.dll
#3  0x00000000776b75f4 in ntdll!RtlLogStackBackTrace ()
   from C:\Windows\SYSTEM32\ntdll.dll
#4  0x000000007765dc8f in ntdll!RtlIsDosDeviceName_U ()
   from C:\Windows\SYSTEM32\ntdll.dll
#5  0x000007fefecc10c4 in msvcrt!free () from C:\Windows\system32\msvcrt.dll
#6  0x0000000000570330 in std::default_delete<RenderMemory::MemoryBlock>::operator() (this=0x1cecc840, __ptr=0x11b93c40)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/unique_ptr.h:347
#7  std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> >::~unique_ptr (this=0x1cecc840, __in_chrg=<optimized out>)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/unique_ptr.h:274
#8  std::_Destroy<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> > > (__pointer=0x1cecc840)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/stl_construct.h:98
#9  std::_Destroy_aux<false>::__destroy<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> >*> (
    __last=<optimized out>, __first=0x1cecc840)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/stl_construct.h:108
#10 std::_Destroy<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> >*> (__last=<optimized out>,
    __first=<optimized out>)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/stl_construct.h:137
#11 std::_Destroy<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> >*, std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> > > (__last=0x1cecc848,
    __first=<optimized out>)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/stl_construct.h:206
#12 std::vector<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> >, std::allocator<std::unique_ptr<RenderMemory::MemoryBlock, std::default_delete<RenderMemory::MemoryBlock> > > >::~vector (
    this=0x1da25828, __in_chrg=<optimized out>)
    at C:/DEV/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/stl_vector.h:567
#13 RenderMemory::~RenderMemory (this=0x1da25810, __in_chrg=<optimized out>)
    at C:/DEV/gzdoom/src/rendering/swrenderer/r_memory.h:7
#14 PolyFrameBuffer::~PolyFrameBuffer (this=0x1da25000,
    __in_chrg=<optimized out>)
    at C:\DEV\gzdoom\src\rendering\polyrenderer\backend\poly_framebuffer.cpp:78
#15 0x00000000005705bd in PolyFrameBuffer::~PolyFrameBuffer (this=0x1da25000,
    __in_chrg=<optimized out>)
    at C:\DEV\gzdoom\src\rendering\polyrenderer\backend\poly_framebuffer.cpp:78
#16 0x0000000000401640 in I_ShutdownGraphics ()
    at C:\DEV\gzdoom\src\win32\hardware.cpp:101
#17 0x00000000005a18f3 in D_DoomMain () at C:\DEV\gzdoom\src\d_main.cpp:2899
#18 0x000000000040e35e in DoMain (hInstance=hInstance@entry=0x400000)
    at C:\DEV\gzdoom\src\win32\i_main.cpp:963
#19 0x000000000040eae6 in wWinMain (hInstance=0x400000,
    nothing=<optimized out>, cmdline=<optimized out>,
    nCmdShow=<optimized out>) at C:\DEV\gzdoom\src\win32\i_main.cpp:1289
#20 0x00000000004013df in __tmainCRTStartup ()
#21 0x00000000004014eb in WinMainCRTStartup ()


Here's not the place to post bug reports!

[drfrag]

Hidden. That was not a bug report but a MinGW thing.

[Graf Zahl]

That thing means I postponed the planned release you joker, now you'll have to wait for another day!

[dpJudas]

There's too many things in MinGW that relies on hacks for me to take it seriously as a compiler. If someone uses it they will have to figure out themselves why it doesn't work.

For Windows XP and Vista I'm now at the stage where I don't even care if there's an easy way that allows me to maintain support. I won't pollute my source code with the support. For Windows 7 I'll try not to break anything on purpose, as it is mostly compatible with still supported OS'es, but I won't actively test if it does. Unsupported OS means unsupported as far as I'm concerned.

[Graf Zahl]

I personally do not care about MinGW.. Using that instead of MSVC is like having Linux but not using GCC but some obscure compiler that is barely compatible with the system it's supposed to target. If its makers had shown even the slightest inkling of competence I might think differently but MinGW has a history of poor Windows support that never ever improved.

[drfrag]

That thing means I postponed the planned release you joker

But what are you talking about? My PR has not been merged yet and that's not even a problem with the PR but MinGW itself. Without the PR MinGW doesn't even compile, it's just one of those MinGW CRT crashes.
Edit: besides before the exit cleanup it crashed with all renderers, crashes on exit have always been a known issue with MinGW and it's even mentioned in the wiki. I don't think it's that bad: it's lightweight, it's free software and it works but it's not suitable for releases anymore since the old ZDoom days. I didn't mention it since i didn't consider it important.

[Rachael]

He thought that you posted an issue with GZDoom in MSVC, and that it was a crash that he would've had to investigate. And since you didn't clear that up before he had closed his development for the night, he didn't want to reopen it just to do a release that he now knows would've been okay to do in the first place.

[drfrag]

I was talking about MinGW and it was clearly a MinGW crash but first and foremost i'd never make a joke about a real problem (obviously).