Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native builds do not run under Windows XP even with WindowsXP target: calls D3D11 which is not supported on XP #5489

Open
wesinator opened this issue Feb 25, 2024 · 5 comments

Comments

@wesinator
Copy link

wesinator commented Feb 25, 2024

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

"d3d11.dll" stdcall [

hr: D3D11CreateDevice

has the WindowsXP target build actually been tested on a Windows XP computer or VM?

followup to #5487

To reproduce

  1. latest toolchain with dd5f213 , https://raw.githubusercontent.com/red/code/master/Showcase/calculator.red
  2. redc -r -t WindowsXP calculator.red
  3. XP host, run calculator.exe
  4. See error
    redc_calc_view_windowsxp_target_d3d11 dll_not_found

Edit: the same issue happens whether in WindowsXP target mode or MSDOS (console app) target mode
image

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

@wesinator wesinator changed the title GUI native builds do not run under Windows XP even with WindowsXP target: calls D3D11 which is not supported on XP Native builds do not run under Windows XP even with WindowsXP target: calls D3D11 which is not supported on XP Feb 25, 2024
@greggirwin
Copy link
Contributor

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.

@GiuseppeChillemi
Copy link

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.

@qtxie
Copy link
Contributor

qtxie commented Feb 26, 2024

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.

@wesinator
Copy link
Author

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 related GetGestureInfo 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.

@hiiamboris
Copy link
Collaborator

View module does not support any of the touch functions on Windows anyway, so I've no idea why it imports that :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants