Giters

red / red

Red is a next-generation programming language strongly inspired by Rebol, but with a broader field of usage thanks to its native-code compiler, from system programming to high-level scripting and cross-platform reactive GUI, while providing modern support for concurrency, all in a zero-install, zero-config, single ~1MB file!

Home Page:http://red-lang.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

wesinator opened this issue · comments

commented

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

red/modules/view/backends/windows/win32.reds

Line 2855 in dd5f213

"d3d11.dll" stdcall [

red/modules/view/backends/windows/direct2d.reds

Line 1734 in dd5f213

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

commented

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.

commented

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.

commented

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.

commented

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.

commented

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