4

I used _setmode(_fileno(stdout), _O_U8TEXT).

I am trying to understand how wprintf() differs from printf(), so I am trying to understand the difference betweem putc() and fputwc(). I thought the difference was that fputwc() could write 1–2 bytes and putc() only one byte. This was the case when using them to write one byte long characters to a file, but when I use them to write to stdout, they were different.

The letter L'é' is equivalent to 233, which is one byte long. So I thought that using putc(233, stdout) would work as fputwc(233, stdout), but it does not: only fputwc(233, stdout) works, even though both work equally when using them to write to a file. The other command wrote nothing.

Hence my question: how does the (Windows) terminal know if I wrote a wide character or a normal character?

Schilive
  • 187
  • 7
  • 2
    When you say "Windows Terminal" are you referrring to the **actual** multi-shell host application named "[Windows Terminal](https://github.com/microsoft/terminal)" (which is unrelated to Visual Studio) or are you referring to the `conhost`-generated "console" Windows that text-mode processes appear in? Or are you referring to Win32's stdin/stdout handling in general? – Dai Oct 01 '22 at 04:55
  • 1
    _"The letter L'é' is equivalent to 233, which is one byte long."_ - This _probably_ won't work because Windows' API functions that handle text come in either "ANSI" or "Wide" versions (y'know: `CreateWindowA` vs `CreateWindowW`) - the "ANSI" functions assume you're using an old-school "Code page" (**not** any form of Unicode, especially not UTF-8) - so that `U+00E9` code-point for `é` might actually be interpreted as some legacy character - these functions are completely irrelevant and obsolete today. – Dai Oct 01 '22 at 04:58
  • 1
    _"even though both work equally when using them to write to a file."_ -if both of those functions seemingly behave the same when writing to a file then _that's unusual_. The documentation for `_setmode` says that if you use `_O_U8TEXT` then [using any nonwide print functions will trigger an `assert`](https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode?view=msvc-170) (i.e. a program crash). – Dai Oct 01 '22 at 05:02
  • @Dai, if the answer to this question is "yes", I'll declare my stupidity to the United Nations. Are "print()", "wprinf()", etc. ways to talk to the OS? – Schilive Oct 01 '22 at 06:12
  • 1
    Yes. All IO in any modern computer system _necessarily_ goes through the OS. While most Win32 functions are userland (and run in-proc) eventually there will be a syscall which enters kernel-mode. – Dai Oct 01 '22 at 06:19
  • @Dai, I guess your comments answer my question. For some reason, I forgot everything was a syscall and thought the C commands were independent of the OS, when the implementation of the commands is OS-dependent. Thank you very much! BTW, the reason I feel like an idiot is because I've just printed in Linux in x86 and heard Guildo van Rossum talking about Amoeba needing C libraries, and other similar things. Again, thank you. – Schilive Oct 01 '22 at 06:28
  • @Dai, according to the StackOverflow community, should I delete this question? – Schilive Oct 01 '22 at 06:29
  • "should I delete this question?" - **no** - it's a good question - I'll post an answer sometime tomorrow, methinks - assuming no-one beats me to it. – Dai Oct 01 '22 at 06:36

0 Answers0