4 ms·

Really interesting! There is leaked source code for WINFILE from NT 3.5, maybe the answer for why this happens can be found in there: https://github.com/Hengle/

Really interesting! There is leaked source code for WINFILE from NT 3.5, maybe the answer for why this happens can be found in there: https://github.com/Hengle/windows_nt_3_5_source_code/tree/master/windows_nt_3_5_source_code/NT-782/PRIVATE/WINDOWS/SHELL/WINFILE https://github.com/Hengle/windows_nt_3_5_source_code/tree/ma... (anyone working on ReactOS or Wine probably shouldn't click this link...)

InvisibleUp 2y ago
Microsoft released the NT 4 version of it under the MIT license: https://github.com/microsoft/winfile https://github.com/microsoft/winfile
ale42 2y ago
I'd rather suspect the Windows API behind for this behavior, rather than the file manager itself. Apparently there might be leaked Windows 3.1 source code (but not all of it): https://www.betaarchive.com/forum/viewtopic.php?t=41781 https://www.betaarchive.com/forum/viewtopic.php?t=41781 (only comments here, didn't check further to see if/where this can be downloaded), but not sure if the relevant source is visible there. Windows 3.1 doesn't seem to use the same conversion as for Alt+XXX to read file names (which are stored in the OEM charset on the disk, e.g. code page 437), as typing Alt+255 enters a normal space (not event a non-breaking one).
- rep_lodsb 2y ago
  You are right, it's likely to be the conversion from OEM to ANSI. In that case, NT wouldn't have the same bug, since it uses Unicode internally (and the tables translate OEM character 255 to U+00A0). The forum post seems to be about this directory in the leaked 3.5 source: https://github.com/Hengle/windows_nt_3_5_source_code/tree/master/windows_nt_3_5_source_code/NT-782/PRIVATE/MVDM/WOW16/KERNEL31 https://github.com/Hengle/windows_nt_3_5_source_code/tree/ma...
  - ale42 2y ago
    Great question, what would happen if NT sees a FAT filesystem (therefore with 8.3 names stored in OEM charset) with a filename containing a Alt+255 (0xFF) character? Anybody with a ready VM around to test this?
  - ale42 2y ago
    Quickly had a look in the KERNEL31 source. The LDOPEN.ASM file contains calls to a routine called MyOemToAnsi, which does the character set conversion. In turn, that function either calls the actual conversion routine in the keyboard driver, or does nothing if there's no keyboard driver yet (boot phase). Didn't find the keyboard driver part, probably not part of the actual kernel so it makes sense that it's not there. Anyone knows where to find one?

InvisibleUp 2y ago

Microsoft released the NT 4 version of it under the MIT license: https://github.com/microsoft/winfile https://github.com/microsoft/winfile

ale42 2y ago

I'd rather suspect the Windows API behind for this behavior, rather than the file manager itself. Apparently there might be leaked Windows 3.1 source code (but not all of it): https://www.betaarchive.com/forum/viewtopic.php?t=41781 https://www.betaarchive.com/forum/viewtopic.php?t=41781 (only comments here, didn't check further to see if/where this can be downloaded), but not sure if the relevant source is visible there. Windows 3.1 doesn't seem to use the same conversion as for Alt+XXX to read file names (which are stored in the OEM charset on the disk, e.g. code page 437), as typing Alt+255 enters a normal space (not event a non-breaking one).

rep_lodsb 2y ago
You are right, it's likely to be the conversion from OEM to ANSI. In that case, NT wouldn't have the same bug, since it uses Unicode internally (and the tables translate OEM character 255 to U+00A0). The forum post seems to be about this directory in the leaked 3.5 source: https://github.com/Hengle/windows_nt_3_5_source_code/tree/master/windows_nt_3_5_source_code/NT-782/PRIVATE/MVDM/WOW16/KERNEL31 https://github.com/Hengle/windows_nt_3_5_source_code/tree/ma...
- ale42 2y ago
  Great question, what would happen if NT sees a FAT filesystem (therefore with 8.3 names stored in OEM charset) with a filename containing a Alt+255 (0xFF) character? Anybody with a ready VM around to test this?
- ale42 2y ago
  Quickly had a look in the KERNEL31 source. The LDOPEN.ASM file contains calls to a routine called MyOemToAnsi, which does the character set conversion. In turn, that function either calls the actual conversion routine in the keyboard driver, or does nothing if there's no keyboard driver yet (boot phase). Didn't find the keyboard driver part, probably not part of the actual kernel so it makes sense that it's not there. Anyone knows where to find one?