red
red copied to clipboard
Native builds do not run under Windows XP even with WindowsXP target: calls D3D11 which is not supported on XP
Describe the bug Programs compiled natively with the toolchain for a WindowsXP target will not run on Windows XP. The GUI view currently depends on a Windows DirectX11 API that is only available for Windows Vista/7 and up: see https://learn.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d11-d3d11createdevice
https://github.com/red/red/blob/dd5f213623ba8b060f7d0bf4ece406ea25e9fb56/modules/view/backends/windows/win32.reds#L2855 https://github.com/red/red/blob/dd5f213623ba8b060f7d0bf4ece406ea25e9fb56/modules/view/backends/windows/direct2d.reds#L1734
has the WindowsXP target build actually been tested on a Windows XP computer or VM?
followup to #5487
To reproduce
- latest toolchain with dd5f213 , https://raw.githubusercontent.com/red/code/master/Showcase/calculator.red
-
redc -r -t WindowsXP calculator.red
- XP host, run calculator.exe
- See error
Edit: the same issue happens whether in WindowsXP target mode or MSDOS (console app) target mode
Expected behavior A WindowsXP target build should run out of the box on Windows XP SP3 / NT 5.1, or this target should be dropped entirely if it isn't going to be supported.
There isn't a way to install DirectX 11 / D3D11 on Windows XP, so this won't ever work as it is currently.
Platform version
red-toolchain-24feb24-dd5f21362
this target should be dropped entirely if it isn't going to be supported.
I think this is the best option. Much as we want to support older OSs, they need a champion who uses them and can help contribute. We have to look forward, which is already hard enough.
this target should be dropped entirely if it isn't going to be supported.
I think this is the best option. Much as we want to support older OSs, they need a champion who uses them and can help contribute. We have to look forward, which is already hard enough.
If it is too much effort, drop it. If it is a small one, keep it as there are plenty of old industrial PC/Tablets/Notebooks wich still use XP.
But as by now, I would drop it. Lets concentrate the scarse resources to what matters.
I cannot make XP runs on virtualbox 7. It should work on virtualbox 6, but I hesitate to downgrade it as it may brokes my existing VMs.
Note that the D3D API does work on Vista/Server 2008 with KB971644 installed, but the GetGestureInfo
API that is automatically imported (whether used or not) by binaries compiled with the Windows
target, is only available in Windows 7/Server 2008 R2+.
So in a sense, the current WindowsXP
target flag is really the Windows Vista/Server 2008 target 😆
Honestly I don't think it makes a lot of sense that GUI view compiled programs import (i.e require) the GetGestureInfo
API every time, so it may be good to change that in addition to removing the XP target. Many desktop programs targeting Windows 10+ never use that API (such as https://github.com/microsoft/winfile)
That would mean:
- removing the
WindowsXP
target flag/switch. - The current
Windows
target would adopt the "XP" target backend, and the touch relatedGetGestureInfo
would only be imported if needed by an imported library, or invoked explicitly.
This would be the most sensible change IMO: a baseline of working on NT6.0+ and also not automatically importing unused APIs.
View module does not support any of the touch functions on Windows anyway, so I've no idea why it imports that :D
may be fixed by adding a condition around https://github.com/red/red/blob/66af58e59b5baffcc6c3143253ecc2d564e00297/modules/view/backends/windows/direct2d.reds#L1730 for nt6+ only?
There are several places need to be modified to support XP.