Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devblogs.microsoft.com

Post reply on HN
Print view View original

11–20 of 74 posts

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

#11

Post by p_l »

lmm wrote: post #9
ChrisSD wrote: post #5

Earlier quoted context omitted.

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.

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

The whole issue is specific to C and languages that copied C or use its runtime underneath in implementations (like Python)

For reference, Unix has no API other than bytes either.

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

#12

Post by criddell »

Isamu wrote: post #7

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 us…

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.

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

#13

Post by ChrisSD »

lmm wrote: post #9
ChrisSD wrote: post #5

Earlier quoted context omitted.

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.

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

Calling it from C does not mean you need a full C standard library to exist. For example, much of the C standard library is itself written in C. But it's a "freestanding" C which assumes only a minimal set of library functions exist (e.g. functions for copying memory from one place to another, filling memory with zeroes, etc).

And you can of course use non-C languages to call the Win32 API. Or even directly using assembly code.

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

#14

Post by lmm »

ChrisSD wrote: post #13
lmm wrote: post #9

Earlier quoted context omitted.

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

Calling it from C does not mean you need a full C standard library to exist. For example, much of the C standard library is itself written in C. But it's a "freestanding" C which assumes only a minimal set of library functions exist (e.g. functions for copying memory from one place to another, filling memory with zeroes, etc). And you can of course use non-C languages to call the Win32 API. Or even directly using ass…

> you can of course use non-C languages to call the Win32 API. Or even directly using assembly code.

Is that a supported/official API though? On Linux you "can" put your arguments in registers and trigger the system call interrupt directly, and I think Go programs even do this, but it's not the official interface and they reserve the right to break your program in future updates, at least in theory.

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

#15

Post by Isamu »

criddell wrote: post #12
Isamu wrote: post #7

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 us…

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.

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

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

#16

Post by lmm »

p_l wrote: post #11
lmm wrote: post #9

Earlier quoted context omitted.

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

The whole issue is specific to C and languages that copied C or use its runtime underneath in implementations (like Python) For reference, Unix has no API other than bytes either.

> The whole issue is specific to C and languages that copied C or use its runtime underneath in implementations (like Python)

So it's "specific to" almost all programming languages in actual use. That's a rather esoteric point.

> For reference, Unix has no API other than bytes either.

Unix does offer an API for writing C-standard in-memory text strings to Unix-standard on-disk text files, it just happens to be the same one as the API for writing in-memory binary strings to on-disk binary files.

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

#17

Post by Pannoniae »

lmm wrote: post #14
ChrisSD wrote: post #13

Earlier quoted context omitted.

Calling it from C does not mean you need a full C standard library to exist. For example, much of the C standard library is itself written in C. But it's a "freestanding" C which assumes only a minimal set of library functions exist (e.g. functions for copying memory from one place to another, filling memory with zeroes, etc). And you can of course use non-C languages to call the Win32 API. Or even directly using ass…

> you can of course use non-C languages to call the Win32 API. Or even directly using assembly code. Is that a supported/official API though? On Linux you "can" put your arguments in registers and trigger the system call interrupt directly, and I think Go programs even do this, but it's not the official interface and they reserve the right to break your program in future updates, at least in theory.

Calling win32 from other languages is supported, calling it from assembly is supported (as long as you use the calling convention properly, obviously), using ntdll to bypass the win32 API is not supported.

Basically on Linux the syscalls are the equivalent of Win32 except much narrower in scope.

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

#18

Post by userbinator »

ChrisSD wrote: post #5
lmm wrote: post #4

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?

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.

It wasn't until fairly recently

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

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

#19

Post by teraflop »

lmm wrote: post #14
ChrisSD wrote: post #13

Earlier quoted context omitted.

Calling it from C does not mean you need a full C standard library to exist. For example, much of the C standard library is itself written in C. But it's a "freestanding" C which assumes only a minimal set of library functions exist (e.g. functions for copying memory from one place to another, filling memory with zeroes, etc). And you can of course use non-C languages to call the Win32 API. Or even directly using ass…

> you can of course use non-C languages to call the Win32 API. Or even directly using assembly code. Is that a supported/official API though? On Linux you "can" put your arguments in registers and trigger the system call interrupt directly, and I think Go programs even do this, but it's not the official interface and they reserve the right to break your program in future updates, at least in theory.

Sure. C has never been the only language supported on Windows.

For instance, Delphi had a period of popularity for Windows application development, and AFAIK it has always used its own runtime library which is completely independent of the C runtime.

Go does not trigger low-level system call interrupts on Windows. (It does that on Linux, but Windows syscall numbers are not stable even across minor Windows updates, so if Go did that, its Windows binaries would be incredibly fragile.)

On Windows NT, Go uses the userspace wrappers provided in Windows system libraries such as NTDLL.DLL and KERNEL32.DLL. But those too are entirely separate from the C runtime.

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

#20

Post by anitil »

criddell wrote: post #12
Isamu wrote: post #7

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 us…

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.

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
Post reply on HN