How do I inform Windows that I'm writing a binary file?

https://devblogs.microsoft.com/oldnewthing/20260504-00/?p=112296

by ingve • 3 months ago

73 71 3 months ago

devblogs.microsoft.com

saltyoldman• 3 months ago

fopen(..., "wb") ?

qbane2• 3 months ago

It's C library taking care of the "b" part for you according to the article.

wahern• 3 months ago

It's the other way around. It's the C runtime that treats text ("t") mode differently, because the C standard specifies \n as a line delimiter but the Windows convention is \r\n. In text mode C stdio translates between \n and \r\n. In binary mode it does no translation.

lmm9• 3 months ago

The article seems to be taking the position that the C runtime library is not part of "Windows", which feels like a rather odd view to me. What is the stable API that Windows offers to application developers if not that?

ChrisSD3• 3 months ago

The Win32 API. E.g. using WriteFile to write files (https://learn.microsoft.com/en-us/windows/win32/api/fileapi/...)

It wasn't until fairly recently that the C runtime was stably shipped with Windows. Previously you had to install the correct version of the C library alongside your application.

lmm9• 3 months ago

The Win32 API. E.g. using WriteFile to write files (https://learn.microsoft.com/en-us/windows/win32/api/fileapi/...)

Which is called from what, if not C? Does windows really offer no API for writing text (rather than bytes) to files? Or does it rely on the application developer to manage line endings in their own code? Neither of those sounds very developer-friendly.

userbinator2• 3 months ago

It wasn't until fairly recently

By "recently" you mean Win95? MSVCRT.DLL has been there for at least that long.

account422• 3 months ago

Windows has shipped msvcrt.dll for a long time, even if it isn't officially supported for application use (and outdated, but that often doesn't matter).

p_l4• 3 months ago

Indeed, C runtime is not part of windows API, and it's normal to have a program include few different copies of C runtime library due to different modules compiled with different compilers/options.

C runtime library being part of OS is accidental thing in Unix, 16bit and 32bit Windows API even does not use C-compatible ABI (instead, Pascal-compatible one is present)

jcranmer• 3 months ago

There is a very unfortunate situation in Unix systems in that the library named 'libc' is serving several simultaneous different roles. One of those roles--what it is named for--is serving as the C standard library. The more important role is that the library also provides the implementation of a different standard API, the POSIX API, which is the main API used to access system details. There's also yet another role of providing the stable system interface to the kernel in most Unix implementations. On Windows, these roles are provided by different libraries: ucrt (what used to be msvcrt), kernel32, and ntdll, respectively.

And for what it's worth, the actual C standard library tends to be fairly rarely used, especially if you consider the malloc/free interface to be part of the system library rather than the C standard library. The C stdio functionality, for example, is extremely underpowered compared to the capabilities of all major operating systems' I/O libraries, and so most applications--even those written entirely in C--will choose to avoid the C standard library and instead use the more direct primitives of the system API layer instead.

wjholden• 3 months ago

Not OP, but thank you for your sharing this. If you don't mind a follow-on question, I always hear people talk about the "runtime" in languages like Go and libraries like Tokio. What is that these runtimes are doing that you cannot get from the likes of libc and these Windows DLLs?

pjmlp3• 3 months ago

Win32.

The C standard library is definitely not part of Windows.

It is now with the Universal C runtime, introduced in Windows 10, which is ironically written in C++ with extern "C" { ... }

On non UNIX clones, including Windows, it has always been the role of commercial C compilers to provide the C standard library on top of the actual C APIs.

Isamu3• 3 months ago

Going all the way back to the earliest C compilers on DOS. There was a decision made to make “\n” just work on DOS for portability of Unix programs, and to make the examples from the C programming book just work.

But in Unix “\n” is a single byte, and in DOS it is 2. So they introduced text and binary modes for files on DOS. Behind the scenes the library will handle the extra byte. This is not necessary in Unix.

I used to have to be careful about importing files to DOS. Did the file come from Unix?

criddell2• 3 months ago

Linefeed (\n) is a single byte in DOS as well.

I think you are talking about carriage return linefeed pair (CRLF or \r\n),

These control codes go back to line printers. Linefeed advances the paper one line and carriage return moves the print head to the left.

Isamu3• 3 months ago

Linefeed (\n) is a single byte in DOS as well.

In binary mode. In text mode if you printf(“Hello World\n”) you get CRLF because that’s how text works on DOS. Unix had the convention of only requiring the LF for text. And Unix didn’t have text/binary modes. That’s the compatibility hack on DOS.

These control codes go back to line printers.

Back to teletypes even. Believe me, I go back to line printers.

anitil• 3 months ago

Annoyingly I actually think '\r\n' is the correct line ending here - advance the paper and return the carriage, but I suppose unix took the simpler implementation which makes looping over characters, words (split by ' ') and lines (split by '\n') simpler as each loop only has a single comparison

kalleboo• 3 months ago

Similarly on Classic Mac OS, C compilers would map single '\n' to single '\r' which is what was the Mac OS convention.

skissane• 3 months ago

So they introduced text and binary modes for files on DOS

It actually long predates DOS

C stdio is descended from Mike Lesk’s “portable IO package” (original release circa 1973). Bell Labs ported their C compiler from Unix to Honeywell GCOS and IBM S/370 mainframes. Mainframes handle text files very differently from how Unix systems do-it is much more complex than simply changing the newline character. So in Lesk’s package, the mode parameter to copen() told you whether the file was text or binary. copen() was renamed to fopen(), and the character to indicate binary mode was changed from “i” to “b”, and hence stdio

stdio has always had text-vs-binary file distinction, on some platforms (such as Unix) it has always been a no-op, on others it hasn’t

https://archive.org/details/lesk-iolib

wpollock• 3 months ago

Interestingly, the IETF has several published RFCs for text protocols, all of which require \r\n line endings.

<https://www.rfc-editor.org/old/EOLstory.txt>

Note this does not apply to file formats (except for RFCs).

nar001• 2 months ago

I'd like to know how these "customers" even get into contact with actual people or engineers at MS, because this seems completely impossible now

How do I inform Windows that I'm writing a binary file?

Related Stories