There is C0, a stripped-down version of C popular in academia [1]. Great for teaching because it's conceptually simple and easy to write a compiler for. But with a couple of additions (like sized primitive types) it might match what you are imagining
Netflix obviously wanted a Korean show, otherwise they wouldn't have funded Koreans to make the show in Korea, they would have funded Americans to make the show in Hollywood.
I applaud Netflix for actually embracing diversity of content and having great shows produced outside Hollywood, and the results speak for themselves (not just Squid Game).
The opt-out is to use the unicode windows APIs (the functions ending in "w" instead of "a"). This also magically fixes all issues with paths longer than 260 characters (if you add a "\\?\" prefix or set you manifest correctly), and has been available and recommended since Windows XP.
I'm not sure why the non-unicode APIs are still so commonly used. I can't imagine it's out of a desire to support Windows 98 or Window 2000.
It should have been supported approximately 20 years earlier than that. I was coding against Win32 looong before 2019 and wondering for years why they wouldn't let you.
An explanation I heard ~10 years prior is that doing so exposed bugs in CRT and nobody wanted to fix them.
> An explanation I heard ~10 years prior is that doing so exposed bugs in CRT and nobody wanted to fix them.
What I've heard is that the issue is not with the CRT, but with applications using fixed-size byte buffers. IIRC, converting from UTF-16 to any of the traditional Windows code pages requires at most two bytes for each UTF-16 code unit, while the UTF-8 "code page" can need three bytes. That would lead to buffer overflows in these legacy applications if the "ANSI" code page was changed to UTF-8.
CRT in a form of msvcrt.dll file had a de-facto presence in Windows since the end of 1990s. Later on, since 2018 or so, CRT availability was formalized in Windows API in form of ucrtbase.dll module.
It is extremely hard to create an application that doesn't depend on CRT on Windows. CRT provides tables for handlers of SEH exceptions and provides the default event handlers. Win32 headers have hard dependencies of the handler tables CRT provides. So you need to go quite a bit out of your way to hack deep Win32 headers. Loading DLLs etc also may call CRT functions.
You can read Mingw64 source to see how many hacks they had to do to make it work.
I have been developing for Microsoft platforms since MS-DOS 3.3, Win16 and Win32 development without any function from standard C library has been a thing for decades, for those doing C development without caring about portability, like demoscene competitions and gaming.
That's the "vcruntime" not the "ucrt". There has been a distinction since the ucrt was made an official part of the OS.
It's very easy to make a win32 program without the ucrt filesytems APIs so long as you don't mind being platform-specific (or making your own cross-platform wrappers).
Does that mean that in this UTF-8 mode, GetCommandLineA would, when the full-width double quote occurs in the command line, return the UTF-8 bytes for that double quote, rather than steamrolling it to an ASCII double quote with the WorstFit mapping?
Yes, I wanted to suggest the same. I modified some old tools I wrote 15 years ago to do that a while ago. Not because I was aware of any vulnerability, but because a few places still used char* and I figured this would basically make it never fail with any weird filenames regardless of the code page.
So now it seems even if you think your app is fully Unicode, still do this just in case? :)
As mentioned elsewhere in this discussion, 99% of the time the cause is likely the use of standard C functions (or C++ `std::string`…) instead of MS's nonstandard wide versions. Which of course is a ubiquitous practice in portable command-line software like curl.
So the culprit is still the software writer. They should have wrapped the C++ library for OS-specific behavior on Windows. Because they are publishing buggy software and calling it cross-platform.
curl first released in 1996, shortly after Windows 95 has born and runs on numerous Windows versions even today. So, how many different versions shall be maintained? Are you going to help one of these versions?
On top of that, how many new gotchas these “modern” Windows functions hide, and how many fix cycles are required to polish them to the required level?
If we're talking about curl specifically, I absolutely think they would (NOT "should") fix/workaround it if there are actually common problems caused by it.
Yes it would have required numerous fix cycles, but curl in my mind is such a polished product and they would have bit the bullet.
I'm sure people who develop it doesn't want money and fame, but they're just doing what they like. However, curl has commercial support contracts if you need.
> Sounds like a thankless job to fix obscure worstfit bugs.
It may look thankless, but it's not. curl is critical infrastructure at this point. While https://xkcd.com/2347/ applies squarely to cURL, it's actually nice that the lead developer is making some money out of his endeavor.
They fix bugs because they simply want their product to be better, if if I were to take a guess? Like, I'm sure curl's contributors worked on OS-specific problems before, and it wouldn't be the last.
> to fix obscure worstfit bugs.
Again my premise is "if there are actually common problems caused by it". This specific bug does sound like that, at least not for now.
You also have to use wmain instead of main, with a wchar_t argv, otherwise the compiled-in argparser will be calling the ANSI version. In other words... Anyone using MSVC and the cross-platform standardised and normal C system, are hit by this.
Oh, and wmain is a VisualC thing. It isn't found on other platforms. Not standardised.
>I'm not sure why the non-unicode APIs are still so commonly used.
Even argv is affected on Windows. That's part of the C and C++ standard, not really a Windows API. Telling all C/C++ devs they need to stop using argv is kind of a tough ask.
I think the issue is that native OS things like the windows command line, say, don’t always do this. Check the results of their ‘cd’ commands with Japanese Yen characters introduced. You can see that the path descriptor somehow has updated to a directory name with Yen (or a wide backslash) in it, while the file system underneath has munged, and put them into an actual directory. It’s precisely the problem that you can’t control the rest of the API surface to use W that is the source of the difficulties.
Using \\?\ has a downside: since it bypasses Win32's path processing, it also prevents relative paths like d:test.txt from working. Kind of annoying on the command line with tools like 7z.exe.
> I'm not sure why the non-unicode APIs are still so commonly used. I can't imagine it's out of a desire to support Windows 98 or Window 2000.
Nowadays, it's either for historical reasons (code written back when supporting Windows 9x was important, or even code migrated from Windows 3.x), or out of a desire to support non-Windows systems. Most operating systems use a byte-based multi-byte encoding (nowadays usually UTF-8) as their native encoding, instead of UTF-16.
I share your recommendations of always using PWSTR when using windows apis.
> I'm not sure why the non-unicode APIs are still so commonly used
I think because the rest of the C world uses char* with utf-8, so that is what people are habituated to. Setting the ACP to CP_UTF8 would have solved a lot of problems, but I believe that's only been supported for a short period of time, bafflingly.
Also most of the popular NAS setups. I'm pretty happy self-hosting everything on my Unraid server. I just checked, all of the tools in the article are in Unraid's App center (except Streamyfin which is a phone app). And if something isn't you can add docker containers or VMs as necessary.
I use pinchflat mostly for archiving channels that occasionally take videos down. It technically has an inbuilt video player, but that's more for "debugging". The intended non-archival usecase is have the download folder picked up by your Plex or Jellyfin and watch it there.
Of course that deprives you from interaction with the actual youtube content. But for support, $1/month on the creator's patreon goes further, and for engagement you can join the creator's discord. The only thing you are really missing out on is feeding the youtube algorithm.
APPX (the installer format used by the windows store) and its successor MSIX contain decent security improvements, including filesystem and registry virtualisation and a capability-based permission system.
After the limited success of the windows store you can now get the same in standalone installers. It has been adopted by approximately nobody
I feel like calling "shows panic when presented with liquids to drink" a fear of water is a perfectly fine shorthand. Even if it might not be a literal fear of all forms of water, only water you are supposed to drink
We got a certificate with a company that's the local equivalent of an LLC, and have seen certificates issued to private individuals. As far as I can tell it's up to the issuer who they support in their verification process. Many of them are pretty inflexible with somewhat arcane processes designed decades ago (with ancient websites portals to match), so your experience may vary
An additional detail is that there are two levels of code signing certificates, normal and EV (extended validation) certificate. EV certificates make windows completely drop the low-reputation screen and causes many antivirus solutions to trust you but are expensive and are a bit of a pain to get. Normal certificates are cheaper and comparatively easier to acquire, but only give partial benefits (less scary screen from Windows, some leeway from antivirus).
In Europe, statistically nearly every car older than 10 years is manual. With the recent improvements in automatics they are finally catching on in Europe.
You may be able to find an old automatic or CVT car in Europe, but you would need to look for a while
Volvo made automatic versions of its cars from the late sixties onwards. A colleague had an automatic 244 in the early 1980s.
Here in Norway automatics are not finally catching on, they are ubiquitous and the driving instructors' association is campaigning to get the rules changed so that you can pass the driving test on an automatic and later simply do a conversion course to allow one to drive manual.
And of course it will all be moot quite soon because EV sales already outnumber ICE sales nearly nine to one here. Volkswagen and Hyundai no longer sell ICE cars in Norway. Volkswagen still sells ICE vans and pickups though.
That's because Europeans prefer small cars, in which automatics really sucked until maybe 15-20 years ago. They were inefficient and heavy, and the engines in those cars didn't have a ton of excess power.
1: https://c0.cs.cmu.edu/docs/c0-reference.pdf
reply