1. 14
  1. 7

    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, support 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 C runtime, and it’s entirely reasonable that you might need to look at them if you’re targeting Windows.

    1. 4

      Windows won’t allow you to delete or move open files by default

      Windows lets the file opener specify whether it supports concurrent delete or move via FILE_SHARE_DELETE, which is badly named and badly understood.

      I think the bigger issue, which comes back to the spirit of this article, is what to do when a program doesn’t use a Windows API that can specify this behavior: when I last looked the C runtime library didn’t let programs specify this - _SH_DENYNO is for read and write only. So there’s a lot of people who think Windows doesn’t allow deletes or moves of opened files, because they’re running on an abstraction layer that doesn’t allow it.

      1. 4

        Yeah, the entire thing leaves a sour taste in the mouth; portability shouldn’t have to mean “it’s just a different variant on Unix”.

        Hell, I actually prefer developing on Windows with the caveat that you aren’t trying to develop Unix applications on Windows. Of course you’d have a bad time. (Though I do wish the narrow Win32 APIs supported UTF-8 as a system codepage… I think Windows 10 finally fixed this.)

        1. 1

          (Though I do wish the narrow Win32 APIs supported UTF-8 as a system codepage… I think Windows 10 finally fixed this.)

          Yeah, they do; that’s mentioned in the article. I agree that probably ought to have been done earlier, but the sheer level to which normalized UTF-16 is baked into Win32 means it’s usually less mental gymnastics for me to just convert to and from at the API boundary and use the wide APIs.

          1. 1

            I opted for using the UTF-8 codepage so I don’t have to think about converting, especially with all the places the application I inherited touches the Win32 APIs. If the API boundary contained into one unit, and converting a MultiByte application to UTF-16 wasn’t so painful, I maybe have decided on a different path.

            I did file a Wine bug however.