Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The NT PE executable format supports quite a few processors families.

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.



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).


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.


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.


It was almost certainly added in order to support EFI which uses PE/COFF format binaries.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: