7 ms·

The title of this article had me do a double-take: C and C++ development on Windows is great. No sanity is needed. But that's not what the article is about. Wh

by gecko 5y ago

The title of this article had me do a double-take: C and C++ development on Windows is great. No sanity is needed. But that's not what the article is about. What the article is about is that the C runtime shim that ships with Visual Studio defaults to using the ANSI API calls without supporting UTF-8, goes on to identify this as "almost certainly political, originally motivated by vendor lock-in" (which it's transparently not), and then talks how Windows makes it impossible to port Unix programs without doing something special. I half empathize. I'd empathize more if (as the author notes) you couldn't just use MinGW for ports, which has the benefit that you can just use GCC the whole way down and not deal with VC++ differences, but I get that, when porting very small console programs from Unix, this can be annoying. But when it comes to VC++, the accusations of incompetence and whatnot are just odd to me. Microsoft robustly caters to backwards compatibility. This is why the app binaries I wrote for Windows 95 still run on my 2018 laptop. There are heavy trade-offs with that approach which in general have been endlessly debated, one of which is definitely how encodings work, but they're trade-offs. (Just like how Windows won't allow you to delete or move open files by default, which on the one hand often necessitates rebooting on upgrades, and on the other hand avoids entire classes of security issues that the Unix approach has.) But on the proprietary interface discussion that comes up multiple times in this article? Windows supports file system transactions, supports opting in to a file being accessed by multiple processes rather than advisory opt-out, has different ideas on what's a valid filename than *nix, supports multiple data streams per file, has an entirely different permission model based around ACLs, etc., and that's to say nothing of how the Windows Console is a fundamentally different beast than a terminal. Of course those need APIs different from the Unix-centric C runtime, and it's entirely reasonable that you might need to look at them if you're targeting Windows.

jcelerier 5y ago
> The title of this article had me do a double-take: C and C++ development on Windows is great. No sanity is needed. we certainly have a different opinion on what "great" means. It takes less time to rebuild my whole toolchain from scratch on Linux (~15 minutes) than it takes to MSVC to download those friggin debug symbols it seems to require whenever I have to debug something (I sometimes have to wait 30-40 minutes and I'm on friggin 2GB fiber ! and that's seemingly every time I have to do something with that wretched MSVC !) Thankfully now the clang / lld / libc++ / lldb ... toolchain works pretty well on Windows and allows a lot more sanity but still, it's pretty slow compared to Linux.
- liversage 5y ago
  I agree that downloading symbols can be oddly slow but you can just turn it off, or only turn it on for specific modules. It can be helpful to have symbols for library code to troubleshoot bugs but typically you only need your own symbols and they are already on your computer with your binaries.
- gavinray 5y ago
  I just use the LLVM toolchain -- on Windows and Linux. You really can't beat clang and lld, the ecosystem and tooling is fantastic. If something absolutely requires MSVC ABI compatibility, I use "clang-cl". God bless LLVM developers.
  - pjmlp 5y ago
    That is why they are now lagging behind everyone else on C++20 support.
- torginus 5y ago
  My main gripe with writing C++ on Linux is the dependency management. If you need to do stuff that's not covered by the standard library, like interfacing with GTK or X11 you are in a world of pain. You need to probably install a distro-specific package in a distro-specific way to get the headers/symbols, use some build tool to configure those distro-specific include/so locations, and hope to god that the distro maintainers didn't upgrade one of those packages (in a breaking way) between the source commit and the time of build. If you suffer through this, you have an exe that works on your version of Ubuntu, maybe on other versions of Ubuntu or possibly other Debian-based distros. If you want it to also work on Fedora, it's back to tinkering. Tbh i think the only sane-ish way of building to dockerize your build env with baked-in versions. In contrast, you pick and SDK and compiler version for Windows, and as long as you install those versions, things will work.
  - CountSessine 5y ago
    Versus no dependency management at all? This reasoning falls apart once you need to use a 3rd party library on Windows. There’s no standard way of sharing such a thing so you always wind up packaging the whole thing with your program, and handing the whole mess to your users. Granted, writing an RPM is a special kind of hell, but at least you don’t have to package everything with your program. But actually you can still do that - I’ve done that plenty of times in embedded. You can always ship your program with its dependant libraries the way you always have to on Windows. In fact it’s a lot easier because most 3rd party libraries were originally coded on Linux and build more sanely on Linux. And RPATHs are pretty easy to figure out. Linux gives you options.
xpressvideoz 5y ago
> avoids entire classes of security issues that the Unix approach has. I wonder what these might be. You mean potential race conditions regarding file operations?
- torginus 5y ago
  When you open a file in Linux, you hold on to the reference of the underlying inode, which means if you load myLib 1.0, then update to myLib 1.0.1 using apt, then all the previously open programs will be stuck on the old version. This is a security issue at best, since unless you restart, there's no way of making sure nobody uses the old lib anymore, but more frequently a source of crashes and bugs, since myLib 1.0 and 1.0.1 might not be perfectly compatible. If I update Ubuntu, Chromium is almost 100% guaranteed to crash, (since the newly started processes use different lib versions), but I've seen other crashes as well. In summary, I can't recommend you continue using your Linux machine after an update without a restart, since you are open to an entire category of weird bugs.
  - ajuc 5y ago
    In Windows you have to restart anyway, so your problem seems to be that you have a choice in Linux?
    - deleted 5y ago
      [deleted]
    - zamadatix 5y ago
      Both have updates in which you do or don't need to restart to apply them. Both also have methods of hotpatching all the way to the kernel level depending how much it's worth it to someone as well.
  - blibble 5y ago
    there are various tools that will tell you if you have old libraries in use by walking /proc and the Chrome thing sounds rather strange as I thought Chrome forked processes from a "zygote" (a prototype process) rather than re-exec'ing() the binary (which should retain the handle to the deleted library inodes) not to mention the shared library naming scheme should prevent this sort of incompatible change from occurring
charcircuit 5y ago
>Microsoft robustly caters to backwards compatibility. This includes bugs too. I ran into an undocumented bug in select(1) IIRC that they couldn't fix since it would break backwards compatibility. I spent like a day trying to figure out why my program wouldn't work correctly on Windows.
pjc50 5y ago
> how the Windows Console is a fundamentally different beast than a terminal Yes, and almost entirely in ways that are bad. I think Microsoft have partially recognised that they're tied to compatibility with a set of choices that have lost the popularity wars and now look wrong. That's why they've produced the two different sorts of WSL, each of which has awkward tradeoffs of its own. And Windows Terminal to replace the console. But eventually I think they may be forced to: - drop \ for / - switch CRLF to LF as the default - provide a pty interface - provide a C environment that uses UTF-8 by default It's been weird working with dotnet core and seeing the "cross platform, open source" side of Microsoft, who develop in a totally different style. It's like watching a new ecosystem being built in the ruins of the old.
- zvrba 5y ago
  > drop \ for / API calls accept / as path separator (and interpret it correctly). Shell is a different beast though.
  - tcfhgj 5y ago
    I just tested in PS and found that it eat's / as well
    - deleted 5y ago
      [deleted]
  - vbezhenar 5y ago
    cmd accepts /, but you need to enclose path into quotes, otherwise it tries to interpret it as an option switch. So you would also need to rewrite all command line utilities to use something like `ipconfig --all` instead of `ipconfig /all`.
    - zvrba 5y ago
      Ah, quoting in cmd is its own kind of hell. Not so fun fact and actually the only part of Windows APIs that I truly hate (and I've worked with many of them): command-line arguments are passed to the program as a single flat string. Splitting into the argc,argv array is left to the CRT startup code.
rossy 5y ago
> I half empathize. I'd empathize more if (as the author notes) you couldn't just use MinGW for ports, which has the benefit that you can just use GCC the whole way down and not deal with VC++ differences MinGW GCC doesn't make a difference to the article. It uses the same C runtime library as VC++ and has the same problems with defaulting to ANSI codepages and text-mode streams. In fact, as far as I know, there is no native open-source alternative to the VC++ runtime that isn't a full alternative programming environment like Cygwin.
garaetjjte 5y ago
>C and C++ development on Windows is great. No sanity is needed. C++ is bearable (except the bloated piece of crap that is Visual Studio). but C is almost nonexistent. For many years their compiler lagged in standardized C features (this only somewhat improved recently) and you cannot use vast majority of system APIs, which use COM interfaces.
- formerly_proven 5y ago
  You can use COM from C... it's just even more painful.
  - ziml77 5y ago
    Exposing a COM object from C is even worse than consuming one because you need to manually implement the polymorphism. I did it from Rust once in a toy project; it was certainly interesting making it work, but I would never want to do that in a production application.
rileymat2 5y ago
A lot of the article is about string handling, I very much agree with that part of the article, having worked on a lot of legacy code built over decades before the introduction of UTF-8 compatibility. It gets worse with that old code if you try to share modules between windows and Linux applications. Additional complications come from trying to support TCHAR to allow either type of char for libraries. Anyway, I have ended up supporting monstrosities of wstring, string, CString, char *, TCHAR mushed together, constantly marshalled converted back and forth. And more: https://docs.microsoft.com/en-us/cpp/text/how-to-convert-between-various-string-types?view=msvc-170 https://docs.microsoft.com/en-us/cpp/text/how-to-convert-bet...
- CountSessine 5y ago
  Agreed! And TCHAR was the dumbest of all of them. “Not all of our libs/tools/editors support Unicode yet so use TCHAR in the meantime and then one day when our stack supports it fully then you can throw the switch and all your char*’s will be wchar_t*’s and I’m sure that’ll go really well in your codebase.”
  - cesarb 5y ago
    > And TCHAR was the dumbest of all of them. “Not all of our libs/tools/editors support Unicode yet so use TCHAR The reason for TCHAR is not "libs/tools/editors" not supporting Unicode, but the operating system itself. With TCHAR and related types, the same source code could target both Windows 95 and Windows NT, you just have to change a single #define (ok, IIRC there are actually three #defines: UNICODE, _UNICODE, and another one I can't recall at the moment) and recompile.
burntoutfire 5y ago
> C and C++ development on Windows is great. No sanity is needed. So, you might as well be insane? :D

by gecko 5y ago

jcelerier 5y ago

> The title of this article had me do a double-take: C and C++ development on Windows is great. No sanity is needed. we certainly have a different opinion on what "great" means. It takes less time to rebuild my whole toolchain from scratch on Linux (~15 minutes) than it takes to MSVC to download those friggin debug symbols it seems to require whenever I have to debug something (I sometimes have to wait 30-40 minutes and I'm on friggin 2GB fiber ! and that's seemingly every time I have to do something with that wretched MSVC !) Thankfully now the clang / lld / libc++ / lldb ... toolchain works pretty well on Windows and allows a lot more sanity but still, it's pretty slow compared to Linux.

liversage 5y ago
I agree that downloading symbols can be oddly slow but you can just turn it off, or only turn it on for specific modules. It can be helpful to have symbols for library code to troubleshoot bugs but typically you only need your own symbols and they are already on your computer with your binaries.
gavinray 5y ago
I just use the LLVM toolchain -- on Windows and Linux. You really can't beat clang and lld, the ecosystem and tooling is fantastic. If something absolutely requires MSVC ABI compatibility, I use "clang-cl". God bless LLVM developers.
- pjmlp 5y ago
  That is why they are now lagging behind everyone else on C++20 support.
torginus 5y ago
My main gripe with writing C++ on Linux is the dependency management. If you need to do stuff that's not covered by the standard library, like interfacing with GTK or X11 you are in a world of pain. You need to probably install a distro-specific package in a distro-specific way to get the headers/symbols, use some build tool to configure those distro-specific include/so locations, and hope to god that the distro maintainers didn't upgrade one of those packages (in a breaking way) between the source commit and the time of build. If you suffer through this, you have an exe that works on your version of Ubuntu, maybe on other versions of Ubuntu or possibly other Debian-based distros. If you want it to also work on Fedora, it's back to tinkering. Tbh i think the only sane-ish way of building to dockerize your build env with baked-in versions. In contrast, you pick and SDK and compiler version for Windows, and as long as you install those versions, things will work.
- CountSessine 5y ago
  Versus no dependency management at all? This reasoning falls apart once you need to use a 3rd party library on Windows. There’s no standard way of sharing such a thing so you always wind up packaging the whole thing with your program, and handing the whole mess to your users. Granted, writing an RPM is a special kind of hell, but at least you don’t have to package everything with your program. But actually you can still do that - I’ve done that plenty of times in embedded. You can always ship your program with its dependant libraries the way you always have to on Windows. In fact it’s a lot easier because most 3rd party libraries were originally coded on Linux and build more sanely on Linux. And RPATHs are pretty easy to figure out. Linux gives you options.

xpressvideoz 5y ago

> avoids entire classes of security issues that the Unix approach has. I wonder what these might be. You mean potential race conditions regarding file operations?

torginus 5y ago
When you open a file in Linux, you hold on to the reference of the underlying inode, which means if you load myLib 1.0, then update to myLib 1.0.1 using apt, then all the previously open programs will be stuck on the old version. This is a security issue at best, since unless you restart, there's no way of making sure nobody uses the old lib anymore, but more frequently a source of crashes and bugs, since myLib 1.0 and 1.0.1 might not be perfectly compatible. If I update Ubuntu, Chromium is almost 100% guaranteed to crash, (since the newly started processes use different lib versions), but I've seen other crashes as well. In summary, I can't recommend you continue using your Linux machine after an update without a restart, since you are open to an entire category of weird bugs.
- ajuc 5y ago
  In Windows you have to restart anyway, so your problem seems to be that you have a choice in Linux?
  - deleted 5y ago
    [deleted]
  - zamadatix 5y ago
    Both have updates in which you do or don't need to restart to apply them. Both also have methods of hotpatching all the way to the kernel level depending how much it's worth it to someone as well.
- blibble 5y ago
  there are various tools that will tell you if you have old libraries in use by walking /proc and the Chrome thing sounds rather strange as I thought Chrome forked processes from a "zygote" (a prototype process) rather than re-exec'ing() the binary (which should retain the handle to the deleted library inodes) not to mention the shared library naming scheme should prevent this sort of incompatible change from occurring

charcircuit 5y ago

>Microsoft robustly caters to backwards compatibility. This includes bugs too. I ran into an undocumented bug in select(1) IIRC that they couldn't fix since it would break backwards compatibility. I spent like a day trying to figure out why my program wouldn't work correctly on Windows.

pjc50 5y ago

> how the Windows Console is a fundamentally different beast than a terminal Yes, and almost entirely in ways that are bad. I think Microsoft have partially recognised that they're tied to compatibility with a set of choices that have lost the popularity wars and now look wrong. That's why they've produced the two different sorts of WSL, each of which has awkward tradeoffs of its own. And Windows Terminal to replace the console. But eventually I think they may be forced to: - drop \ for / - switch CRLF to LF as the default - provide a pty interface - provide a C environment that uses UTF-8 by default It's been weird working with dotnet core and seeing the "cross platform, open source" side of Microsoft, who develop in a totally different style. It's like watching a new ecosystem being built in the ruins of the old.

zvrba 5y ago
> drop \ for / API calls accept / as path separator (and interpret it correctly). Shell is a different beast though.
- tcfhgj 5y ago
  I just tested in PS and found that it eat's / as well
  - deleted 5y ago
    [deleted]
- vbezhenar 5y ago
  cmd accepts /, but you need to enclose path into quotes, otherwise it tries to interpret it as an option switch. So you would also need to rewrite all command line utilities to use something like `ipconfig --all` instead of `ipconfig /all`.
  - zvrba 5y ago
    Ah, quoting in cmd is its own kind of hell. Not so fun fact and actually the only part of Windows APIs that I truly hate (and I've worked with many of them): command-line arguments are passed to the program as a single flat string. Splitting into the argc,argv array is left to the CRT startup code.

rossy 5y ago

> I half empathize. I'd empathize more if (as the author notes) you couldn't just use MinGW for ports, which has the benefit that you can just use GCC the whole way down and not deal with VC++ differences MinGW GCC doesn't make a difference to the article. It uses the same C runtime library as VC++ and has the same problems with defaulting to ANSI codepages and text-mode streams. In fact, as far as I know, there is no native open-source alternative to the VC++ runtime that isn't a full alternative programming environment like Cygwin.

garaetjjte 5y ago

>C and C++ development on Windows is great. No sanity is needed. C++ is bearable (except the bloated piece of crap that is Visual Studio). but C is almost nonexistent. For many years their compiler lagged in standardized C features (this only somewhat improved recently) and you cannot use vast majority of system APIs, which use COM interfaces.

formerly_proven 5y ago
You can use COM from C... it's just even more painful.
- ziml77 5y ago
  Exposing a COM object from C is even worse than consuming one because you need to manually implement the polymorphism. I did it from Rust once in a toy project; it was certainly interesting making it work, but I would never want to do that in a production application.

rileymat2 5y ago

A lot of the article is about string handling, I very much agree with that part of the article, having worked on a lot of legacy code built over decades before the introduction of UTF-8 compatibility. It gets worse with that old code if you try to share modules between windows and Linux applications. Additional complications come from trying to support TCHAR to allow either type of char for libraries. Anyway, I have ended up supporting monstrosities of wstring, string, CString, char *, TCHAR mushed together, constantly marshalled converted back and forth. And more: https://docs.microsoft.com/en-us/cpp/text/how-to-convert-between-various-string-types?view=msvc-170 https://docs.microsoft.com/en-us/cpp/text/how-to-convert-bet...

CountSessine 5y ago
Agreed! And TCHAR was the dumbest of all of them. “Not all of our libs/tools/editors support Unicode yet so use TCHAR in the meantime and then one day when our stack supports it fully then you can throw the switch and all your char*’s will be wchar_t*’s and I’m sure that’ll go really well in your codebase.”
- cesarb 5y ago
  > And TCHAR was the dumbest of all of them. “Not all of our libs/tools/editors support Unicode yet so use TCHAR The reason for TCHAR is not "libs/tools/editors" not supporting Unicode, but the operating system itself. With TCHAR and related types, the same source code could target both Windows 95 and Windows NT, you just have to change a single #define (ok, IIRC there are actually three #defines: UNICODE, _UNICODE, and another one I can't recall at the moment) and recompile.

burntoutfire 5y ago

> C and C++ development on Windows is great. No sanity is needed. So, you might as well be insane? :D