And why? We can see that a number of those architectures eventually got a WindowsCE release.
Notably the Dreamcast ran WinCE on SH4 CPU.
Internally, NT first targeted Intel i860, not x86. This was a deliberate decision to break old assumptions. It was designed to be multiplatform from the beginning. The fact that it had an NT syscall layer but also a Win32 one, then formerly an OS/2 subsystem, also reflected this heritage of adaptability, multi-platform, portability etc.
Mostly because that format is not strictly speaking Windows-specific but comes from Unix System V release 4. Also various oddball embedded platforms use the full NT-style PE COFF as their native object/image format (but these usually either specify i386 as machine type or place some invalid value there).
Re:Windows NT for GameCube/Wii
by sumtechguy on Tuesday March 04, 2025 @04:02PM
(#43259772)
That is controlled by this bit in the subsystem field.
https://learn.microsoft.com/en-us/windows/win32/debug/pe-for...
Subsystems https://learn.microsoft.com/en-us/windows/win32/debug/pe-for...
There are also a few others usually NE for older win16 and LE for OS2 and other interesting win16 overlay types.
Re:Windows NT for GameCube/Wii
by RobotToaster on Tuesday March 04, 2025 @12:43PM
(#43257796)
Wait, does that mean there's a risc-v version of windows?
If there is, it isn't public. .NET does apparently have RISC-V architecture support in some sense due to a pull request by a Samsung engineer.
https://github.com/dotnet/runtime/pull/82382
From a technical standpoint, there's no reason Windows couldn't be brought to RISC-V in some form or fashion. It's designed for that portability.
Re:Windows NT for GameCube/Wii
by cokernel_hacker on Tuesday March 04, 2025 @08:39PM
(#43261640)
It was almost certainly added in order to support EFI which uses PE/COFF format binaries.
https://learn.microsoft.com/en-us/windows/win32/debug/pe-for...
I just like the valid MSDOS stub header executable on the front of every DLL and executable.