Fails to run on (newer) 32bit Windows with ucrt
32bit ruby using ucrt has started to fail on newer Windows with "unexpected ucrtbase.dll" -> https://github.com/ruby/ruby/blob/3fb7d2cadc18472ec107b14234933b017a33c14d/win32/win32.c#L2591
The problem is that ruby depends on ucrt internals and those have apparently changed with newer versions.
See https://github.com/msys2/MINGW-packages/pull/10878 and https://github.com/msys2/MINGW-packages/issues/10896 for some background and a potential fix. But ideally ruby wouldn't depend on Windows internals like this.
Updated by naruse (Yui NARUSE) 8 months ago
Why Ruby depends to
- to associate socket and fd: CRuby creates fd with dummy file handle and set socket to emulate Unix-like behavior
- to implement overlapped I/O for Windows 2000/XP
- to emulate fcntl(2)
If you know a better way to implement above use cases, we will migrate to that.
Updated by MSP-Greg (Greg L) about 2 months ago
An issue exists elsewhere, see https://github.com/oneclick/rubyinstaller2/issues/308#issuecomment-1268851455. I'm just the messenger, I don't have the knowledge needed for this issue.
Quoting the response from ArminG-MSFT:
Hello this is Armin from Microsoft. We encountered the same or at least a very similar issue in our internal compatibility testing. What seems to be the issue is that Ruby is relying on undocumented/unsupported behaviour. It is trying to retrieve a pointer to an internal variable __pioinfo inside urtbase.dll. That itself is not supported, but from our debugging and looking at the code in win32.c it looks like it is doing it by walking back from the ret assembly instruction in _isatty(). But this assumes the ret instruction will be the last instruction in that _isatty().
The issue is that certain optimizations can move function code beyond a ret instruction, so the common/typical instruction path is shorter. And new optimizations we applied to recent ucrtbase.dll builds did exactly that in _isatty(). So it looks like Ruby is now looking at the wrong location and no longer finding __pioinfo.
Short term we'll be rolling out a fix that for this function that undoes this optimization, which should fix this specific error for the many Ruby users in the wild. But it would be great if Ruby can be fixed to not use undocumented behaviour, or perhaps at least be more robust in its function traversal. Note though that at some point we may break it in some way that is not so easily fixed.
The offending code is in win32\win32.c function set_pioinfo_extra.
Feel free to correct me though if our understanding is incorrect.