Windows has no concept of text vs. binary files; all I/O through WriteFile is raw bytes, and CRLF translation lives entirely in the C runtime.
Key Takeaways
The Windows kernel (WriteFile) sees only bytes; text/binary distinction is a C runtime concern, not an OS concern.
Opening with "w" vs "wb" in fopen triggers runtime-level CRLF conversion before bytes ever reach the kernel.
The old MS-DOS ioctl AH=4401h binary-mode bit applies only to character devices, not disk files; it returns ERROR_INVALID_FUNCTION on files.
The Win32 equivalent for console raw/cooked mode is SetConsoleMode, analogous to Unix stty.
Hacker News Comment Review
Commenters traced the text/binary split to early DOS C compilers deliberately mapping to CRLF so Unix code and K&R examples would work portably.
There is mild disagreement about whether the C runtime counts as “Windows”: the stable Win32 API (WriteFile) is the real contract; the C runtime was historically not shipped with the OS and required side-by-side deployment.
Notable Comments
@lmm: argues calling the C runtime “not Windows” is odd, since it was the practical API surface for most developers.
@ChrisSD: clarifies the C runtime was not stably included with Windows until recently, requiring apps to bundle the correct version.