Visual Studio 2019 and the end of Windows XP support

Here, developers communicate stuff that does not go onto the main News section or the front page of the site.
[Dev Blog] [Development Builds] [Git Change Log] [GZDoom Github Repo]

Moderator: GZDoom Developers

Re: Visual Studio 2019 and the end of Windows XP support

Postby sinisterseed » Sun Jan 19, 2020 10:55 am

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.
Last edited by sinisterseed on Sun Jan 19, 2020 11:24 am, edited 1 time in total.
User avatar
sinisterseed
GZDoom RO Translator & Raze Tester
 
Joined: 05 Nov 2019
Twitch ID: sixhundredsixteen
Github ID: sinisterseed
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Visual Studio 2019 and the end of Windows XP support

Postby Graf Zahl » Sun Jan 19, 2020 11:07 am

mysoft wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Visual Studio 2019 and the end of Windows XP support

Postby Grizzly » Sun Jan 19, 2020 11:12 am

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?
User avatar
Grizzly
 
Joined: 06 Sep 2018

Re: Visual Studio 2019 and the end of Windows XP support

Postby wildweasel » Sun Jan 19, 2020 11:19 am

mysoft wrote: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. :mrgreen:
User avatar
wildweasel
change o' pace.
Moderator Team Lead
 
Joined: 16 Jul 2003

Re: Visual Studio 2019 and the end of Windows XP support

Postby Rachael » Sun Jan 19, 2020 11:55 am

mysoft wrote: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? :roll:

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Visual Studio 2019 and the end of Windows XP support

Postby Redneckerz » Sun Jan 19, 2020 12:22 pm

mysoft wrote: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.

mysoft wrote: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. :wink: Its open source, after all.
User avatar
Redneckerz
To it's ports i may have seen
Spotlight Team
 
Joined: 25 Nov 2019
Discord: Redneckerz#8399
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Legacy GZDoom)

Re: Visual Studio 2019 and the end of Windows XP support

Postby drfrag » Sun Jan 19, 2020 12:29 pm

mysoft wrote: unless i'm a zoombie

You're a zombie then (and me too). :P 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. :P
Spoiler:

Edit: LZDoom still runs on XP (well it should).
Last edited by drfrag on Sun Jan 19, 2020 12:45 pm, edited 1 time in total.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Visual Studio 2019 and the end of Windows XP support

Postby Graf Zahl » Sun Jan 19, 2020 12:35 pm

drfrag wrote: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.

drfrag wrote:, BTW there's a new and exciting crash on exit in SoftPoly. :P
Code: Select allExpand 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!
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Visual Studio 2019 and the end of Windows XP support

Postby drfrag » Sun Jan 19, 2020 1:38 pm

Hidden. That was not a bug report but a MinGW thing.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Visual Studio 2019 and the end of Windows XP support

Postby Graf Zahl » Sun Jan 19, 2020 1:45 pm

That thing means I postponed the planned release you joker, now you'll have to wait for another day!
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Visual Studio 2019 and the end of Windows XP support

Postby dpJudas » Sun Jan 19, 2020 1:49 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Visual Studio 2019 and the end of Windows XP support

Postby Graf Zahl » Sun Jan 19, 2020 1:59 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Visual Studio 2019 and the end of Windows XP support

Postby drfrag » Sun Jan 19, 2020 3:07 pm

Graf Zahl wrote:That thing means I postponed the planned release you joker

:shock: 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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Visual Studio 2019 and the end of Windows XP support

Postby Rachael » Sun Jan 19, 2020 4:34 pm

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Visual Studio 2019 and the end of Windows XP support

Postby drfrag » Sun Jan 19, 2020 4:58 pm

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).
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

PreviousNext

Return to Developer Blog

Who is online

Users browsing this forum: No registered users and 0 guests