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