Practically speaking, I've found that Claude never uses collection expressions, so the feature has disappeared from my code. Before AI, the feature was looked at with skepticism by my coworkers. We like writing "var" for all variable declarations. You have to write the type on the left side if you want to declare a variable with a collection expression, and we would never do that otherwise. Can't do `foreach (var x in [1, 2, 3])`. Too often, you have to make specific accommodations in your code to allow the collection expression to be valid.
Collection expressions today are more the sort of thing that a code poet or golfer can do to prettify their code than something a newbie can count on using. It's tough to explain "you can only use this when the collection type is implied in that spot" to a newbie. The value of the base feature is still unproven for me. I'm not sure I agree, without some convincing, that collection expressions made the language more coherent rather than doing https://xkcd.com/927.
Perhaps not legally, but technically, you have an option: don't use the Microsoft Store. This isn't as wild a suggestion as it may seem to non-Windows users: the store is barely used by Windows users. You can get your own code signing certificate from a public CA, sign your own installer, and post it on your website. This is still the primary way that Windows software is distributed. Microsoft does not have a hand in any part of it; they can't cancel anything. Their only role is including the public CA in their root certificate store. If you're not shipping a kernel driver, you don't need Microsoft's permission for anything. You can still ship an .msix installer which is the same technology used by the Store.
I recently de-listed my app in the store and closed my Microsoft developer account. I was wrong for having bothered with it; just a waste of my time for no benefit. Stick to your own deployment.
It’s become neigh impossible to get your own code signing cert these days. The 2025 update from the CA forum required code signing certs to be short lived (no more three or five year certs) and stored exclusively on an HSM. As a result, most companies cross-signing these certs have moved to a subscription PaaS model where you are issued a cert but never receive custody of it, and perform signing via their APIs, and are at their mercy should they decide to block your account.
Anyway, even if you could get your own cert it would be same thing: MS could revoke or blacklist your indicate cert (though usually the grounds for doing so are much less shaky than your account being suspended for vague “tos violations”)
I was afraid of the HSM at first but for an open source developer (rather than a big company) I found it wasn't a big deal. I can't sign in GitHub Actions and I have a USB stick that lights up when I sign releases, but it hasn't been a blocker. I got mine from Sectigo Store. This isn't hypothetical, I really did it, I've got the HSM, it works. It wasn't difficult. It just cost some money and a little bit of time. "Nigh impossible" is a tremendous exaggeration. I'll concede "annoying and expensive" perhaps. If you've got the money, you can get the HSM. You don't have to re-buy the HSM when you renew your certificate.
The Microsoft Store account was painful to set up, I'll note. My developer account had also been cancelled by Microsoft for unknown reasons, and I ultimately had to set up a brand new one. New email, new name. My new account has my middle initial because I couldn't clash with the existing, closed account. My first and last name alone are banished forever from the store.
The "same thing", as you concede, isn't the same thing. Quantity has a quality of its own: one happens all the time and we're reading an article about it happening right now. In the comments there's another prominent maintainer who it happened to, and it happened to me personally! That's three right here! The other happens so infrequently that people in this same HN thread are complaining that it isn't happening enough. Can you find an example that's like Veracrypt and WireGuard? In practice, it seems they rarely do this, even when they should. You can actually view the list under "Manage computer certificates" > "Untrusted Certificates." On my computer the entire list is 20 certificates.
I'm standing by my suggestion, 100%. These aren't equivalent risks at all.
Thanks for sharing your experience. I have been code signing releases for over a decade as an indie publisher myself, until I found myself effectively iced out by the HSM requirement, the increased cost, and the shortened cert lifetimes, which, as someone with certain executive order dysfunctions, I already had a hard time being on top of with the old (multi-year) lifetimes.
I just migrated to MS artifact signing and, thank the lord, had an actually easier time getting verified than I did with the Sectigo and Comodo in the past. I’m sure I’m not representative of anyone else’s experience but having already had a developer account (with a different email and without an Azure account!) that I had already been using for the Microsoft Store might have helped, as well as the fact that I had a well-established business history (I’ve heard businesses younger than 3 years can’t get verified??), but reading all the comments here makes me very uneasy about the future.
It’s good to know the HSM route isn’t a complete non-starter. The main reason I panned it is that when I started looking into this I found that a number of companies that had previously offered the HSM route had done a bait and switch and were now keeping custody unless you were big enterprise (meaning willing to put up with 10k/yr fees). I did find a few that would allow OSS devs to sign their work, but read horror stories on Reddit and elsewhere about their freezing the account and issuing no refunds if you ask them to issue the cert in the name of your LLC or corporation instead of with your personal name (which I expressly did not want). Also, they actually were more expensive than Azure artifact signing even after the HSM cost was taken out.
I believe you. I also found that many CAs will not deal with a solo developer; that's real. But Sectigo continues to offer HSMs to solo developers. The link I used is [1], you buy the HSM along with your first certificate and they ship it to you. $300/year for the cert, $90 one-time for the HSM. That's not cheap but I think for specific developers looking for an escape from the store, it's a good price for freedom. The HSM is a USB stick with an LED on the back. The software is called "SafeNet Authentication Client" and it sets up the certificate access in your Windows Certificate Store so that signtool can use it. Prompts for the password every time (annoying).
For comparison, my code signing cert via Azure (no Microsoft store account required, can be used to self-publish binaries/installers the old fashion way) is $10/month, or about a third of the price Sectigo is charging you. I figured it was worth trying this route first, though I had to write my own basic tooling around it.
I must say your experience is interesting. I am using https://signmycode.com/sectigo-code-signing, but I have chosen Install on Existing Token (Google Cloud KMS), and it's quite easy for me to handle the stuff. I am not scared of key storage or security issue nor password protection or forget issue.
It doesn't require it, and neither does windows store. It centralizes control over apps. Apple leverage's its OS to create friction for installing apps from the web.
Microsoft and Apple uses their OS store to slowing take away control and ownership from device owners.
I have found that MS still blocks my signed and timestamped .msi files for at least a few days. From saving the downloads in Edge and then via Smartscreen once you get it downloaded.
If I submit it manually for every update it tends to go better. If more people download and install it whitelists faster. But that is highly annoying, orwellian bullshit. Might even be anti-competitive or downright illegal.
I see the same behavior with my MSIs. I've had better luck with my MSIXs. As much as I like being Store-free, I have a June 2025 release of an MSI-based app that still gets dinged by Edge and again by SmartScreen. A different MSIX-based app, with almost no users, gets dinged by Edge but not by SmartScreen. It's the same certificate. I can never be sure what other users are seeing, though.
tbh, I thought that I had built enough reputation on this particular MSI release, until testing it just now. Hate to see it :(
Thank you for that. Although it may be unlikely, I'd love to see a mass exodus away from their failed attempt to emulate all the worst aspects of appstores popularized in other platforms.
I grew up being able to download software and install it, and actually prefer that model (relying on reputational trust of the party publishing it, my own verification from other signals researched, or sandboxing techniques where appropriate).
Most users may not be aware, but a rare gem of a version of Windows that refreshingly doesn't even come with the store (or a bunch of the other unwanted bloat) is IoT Enterprise LTSC.
As a lifelong Windows user, the premise of Microsoft controlling what goes on my PC is revolting. I'm buying a tool from them, not a set of handcuffs. If it was some non-profit, open-source group running the store I might be more inclined to trust it. But ultimately the only gatekeeper on a product I own should be me. Otherwise I don't really own it, which leads to problems like this one.
Windows Forms is the answer you seek. It still receives updates to this day. I've been writing and shipping Windows Forms apps for 25 years. High DPI, dark mode, Edge web views, Blazor integration, we've got it all. Users don't even need to install .NET these days with self-contained deployment.
I will boldly claim Windows Forms is more stable than Gtk and Qt. Don't let random teams at Microsoft confuse you because they released yet another unrelated framework that you don't have to use. They are engineer-sirens trying to lure you from the true path. Let them pursue their promotions in peace while we rely on a stable workhorse.
I can't find any link, so I think I'm getting mixed up between what they consider LTS and when the upgrade tool starts prompting to upgrade. If you're on the 24.04 LTS, then you don't get prompted to upgrade until 26.04.1
> When programming, it is still important to write code that runs correctly on systems with either byte order
I contend it's almost never important and almost nobody writing user software should bother with this. Certainly, people who didn't already know they needed big-endian should not start caring now because they read an article online. There are countless rare machines that your code doesn't run on--what's so special about big endian? The world is little endian now. Big endian chips aren't coming back. You are spending your own time on an effort that will never pay off. If big endian is really needed, IBM will pay you to write the s390x port and they will provide the machine.
> There are countless rare machines that your code doesn't run on--what's so special about big endian?
One difference is that when your endian-oblivious code runs on a BE system, it can be subtly wrong in a way that's hard to diagnose, which is a whole lot worse than not working at all.
That sounds like a problem to deal with as part of your paid IBM s390x porting contract. I guess my point is: why deal with this before IBM is paying you? No other big endian platform matters, and s390x users are 100% large commercial customers. If IBM or one of their customers isn't paying you, there's nobody else who would need it. If IBM is paying you, you can test on a real z/VM that they provide. I see big endian as entirely their burden now; nobody else needs it. If they want it, they can pay for the work.
Also, endian-correct code is usually semantically clearer. For example, if you're reading network-ordered bytes into an int, an unconditional endian swap (which will produce correct results on LE systems but not BE) is less clear than invoking a "network bytes to u32" helper.
I think that's a bit different than the argument being made. We should still always use htonl() and ntohl() etc. when dealing with protocols that use network byte order (a shame we're stuck dealing with that legacy). I think even if all big-endian machines magically disappeared tomorrow, we should still do that (instead of just unconditionally doing a byte-swap).
But for everything else, it's fine to assume little-endian.
You sound like some sort of purist, so sure, if you really want to be explicit and support both endiannesses in your software when needed, go for it. But as general advice to random programmers: don't bother.
It might sound outrageous but I guard against this sort of thing. When I write utility code in C++ I generally include various static asserts about basic platform assumptions.
> running on a real Sun3, compiled with a non-ANSII compiler (Sun cc 1.22)
> this is fatal in HP-UX 10 with the bundled compiler
> OpenWatcom 1.9 compiler
> OS/2 builds
> making sure that all functions are declared in both ANSI format and K&R format (so C-Kermit can built on both new and old computers)
Oooooh! A clang complaint: 'Clang also complains about perfectly legal compound IF statements and/or complex IF conditions, and wants to have parens and/or brackets galore added for clarity. These statements were written by programmers who understood the rules of precedence of arithmetic and logical operators, and the code has been working correctly for decades.'
There's platform and there's platform. I assume a POSIX platform, so I don't need to check for CHAR_BIT. My code won't work on some DSP with 64-bit chars, and I don't care enough to write that check.
Many of the tests I did back in the 1990s seem pointless now. Do you have checks for non-IEEE 754 math?
Using C++ under Clang 17 and later (possibly earlier as well, I haven't checked) std::numeric_limits<T>::is_iec559 comes back as true for me for x86_64 on Debian as well as when compiling for Emscripten. Might it be due to your compiler flags? Or is this somehow related to a C/C++ divergence?
If I am not mistaken, is_iec559 concerns numerical representation, while __STDC_IEC_559__ is broader, and includes the behavior of numerical operations like 1.0/-0.0 and various functions.
The standard warns that macros and assertions can return true for this one, even if it isn't actually true. The warning, because that's what compilers currently do.
Its one of the caveats of the C-family that developers are supposed to be aware of, but often aren't. It doesn't support IEEE 754 fully. There is a standard to do so, but no one has actually implemented it.
Of course in my case what I'm actually concerned with is the behavior surrounding inf and NaN. Thankfully I've never been forced to write code that relied on subtle precision or rounding differences. If it ever comes up I'd hope to keep it to a platform independent fixed point library.
CPPReference is not the C++ standard. Its a wiki. It gets things wrong. It doesn't always give you the full information. Probably best not to rely on it, for things that matter.
But, for example, LLVM does not fully support IEEE 754 [0].
And nor does GCC - who list it as unsupported, despite defining the macro and having partial support. [1]
The biggest caveat is in Annex F of the C standard:
> The C functions in the following table correspond to mathematical operations recommended by IEC 60559. However, correct rounding, which IEC 60559 specifies for its operations, is not required for the C functions in the table.
The C++ standard [2] barely covers support, but if a type supports any of the properties of ISO 60559, then it gets is_iec559 - even if that support is _incomplete_.
This paper [3] is a much deeper dive - but the current state for C++ is worse than C. Its underspecified.
> When built with version 18.1.0 of the clang C++ compiler, without specifying any compiler options, the output is:
> distance: 0.0999999
> proj_vector_y: -0.0799999
> Worse, if -march=skylake is passed to the clang C++ compiler, the output is:
I do, yes. I check that the compiler reports the desired properties and in cases where my code fails to compile because it does not I special case and manually test each property my code depends on. In my case that's primarily mantissa bit width for the sake of various utility functions that juggle raw FP bits.
Even for "regular" architectures this turns out to be important for FP data types. Long double is an f128 on Emscripten but an f80 on x86_64 Clang, where f128 is provided as __float128. The last time I updated my code (admittedly quite a while ago) Clang version 17 did not (yet?) implement std::numeric_limits support for f128.
Honestly there's no good reason not to test these sorts of assumptions when implementing low level utility functions because it's the sort of stuff you write once and then reuse everywhere forever.
And as I wrote, "There's platform and there's platform."
I don't support the full range of platforms that C supports. I assume 8 bit chars. I assume good hardware support for 754. I assume the compiler's documentation is correct when it says it map "double" to "binary64" and uses native operations. I assume if someone else compiles my code with non-754 flags, like fused multiply and add, then it's not a problem I need to worry about.
For that matter, my code doesn't deal with NaNs or inf (other than input rejection tests) so I don't even need fully conformant 754.
I say nothing about code which can support when char is 64-bit because my entire point was that my definition of "platform" is far more restrictive than C's, and apparently yours.
You wrote "I generally include various static asserts about basic platform assumptions."
I pointed out "There's platform and there's platform.", and mentioned that I assume POSIX.
So of course I don't test for CHAR_BIT as something other than 8.
If you want to support non-POSIX platform, go for it! But adding tests for every single one of the places where the C spec allows implementation defined behavior and where all the compilers I used have the same implementation defined behavior and have done so for years or even decades, seems quixotic to me so I'm not doing to do it.
And I doubt you have tests for every single one of those implementation-defined platform assumptions, because there are so many of them, and maintaining those tests when you don't have access to a platform with, say, 18-bit integers to test those tests, seems like it will end up with flawed tests.
> maintaining those tests when you don't have access to a platform with, say, 18-bit integers to test those tests, seems like it will end up with flawed tests.
No? I don't over generalize for features I don't use. I test to confirm the presence of the assumptions that I depend on. I want my code to fail to compile if my assumptions don't hold.
I don't recall if I verify CHAR_BIT or not but it wouldn't surprise me if I did.
However, unless you are a super-programmer, it's very easy to introduce subtle bugs. Software I write has hit this occasionally, someone somewhere does something like cast an int to bytes to do some bit-twiddling. Checking your whole codebase for this is incredibly hard.
My modern choice is just to make clear to BE users I don't support them, and while I will accept patches I'll make no attempt to bugfix for them, because every time I try to get a BE VM running a modern linux it takes a whole afternoon.
This doesn't seem to be the same thing. The article isn't about being unable to type before JavaScript starts executing. If I understand correctly, you're unable to type until a network request to Cloudflare returns. The question is: why not allow typing during that network request? JavaScript is running and it's observing the keystrokes. Everyone understands that you can't use a React application until JavaScript is running. They're asking why the network request doesn't happen in the background with the user optimistically allowed to type while waiting for it to return.
(Separately, I don't think the article has adequately demonstrated this claim. They just make the claim in the title. The actual article only shows that some network request is made, and that the request happens after the React app is loaded, but not that they prevent input until it returns. Maybe it's obvious from using it, but they didn't demonstrate it.)
I don't think that's true in this case; the React application loads first, fully initializes, and then sends its state via Cloudflare request. It can't happen at the same time, by design. It has to happen serially. The article's claim is that you can't type during this second request. Frankly, I wonder if this is actually true at all. The article did not demonstrate this, and there's no problem if you can actually interact as soon as the React application is running. ChatGPT running abuse prevention and React applications requiring JavaScript to work are both uncontroversial, I think.
OK, I haven't looked at the exact sequencing here. But generally, once the action goes back to the anti-abuse service for checking the user can't be allowed to change what they're submitting. The view the anti-abuse system saw has to match what the app server sees.
From some minor historical experience with Mechanical Turk, I bet you could get humans to do this for one or two cents per receipt. You do them all three times for error checking for $0.03-$0.06 per receipt. I used to pay a nickel for much, much more than 5x this amount of transcription per job, and I got the feeling that I was overpaying based on how eagerly I got responses in and that I saw a lot of the same workers repeatedly.
These days, are MTurk workers simply feeding it into AI anyway, though? It's been a few years since I've run an MTurk campaign. At the time it was clear that humans were really doing it, as you get emails from the workers sometimes.
You can use `xxd` from the vim package to generate these. You'll find out pretty quickly that this is only suitable for small resources: gcc and clang blow up in both time and space on very large literal arrays. If you need to ship more than a few megabytes, find a different technique.
I used this technique for awhile, but it was too problematic for my use case. Now, I use https://github.com/lief-project/LIEF -- among other things, this project can modify Windows PE, macOS Mach-O, and Linux ELF binaries to add resources to them, then offers an API to read them back later. It's a little different for each format, but it's capable of doing all three and I was able to build a cross-platform resource-bundling system that doesn't care how big the resources are.
Yeah xxd is the correct answer. If you don't want to install a dependency and have Lua installed, or if you're just feeling a little bit frisky, you can use my function which is Production Ready™.
Xxd = function(name, input)
if not name:find'^[_%a][_%w]*$' then error('bad name: '..tostring(name)) end
local ans = {
'const unsigned int '..name..'_len = '..(#input)..';',
'const unsigned char '..name..'[] = {',
}
local t = {}
for i=1,#input do
table.insert(t, ('0x%02x,'):format(input:byte(i)))
if #t == 16 then -- 16 columns per row. arbitrary, change this if you want
table.insert(ans, table.concat(t))
t = {}
end
end
if #t ~= 0 then
table.insert(ans, table.concat(t))
end
table.insert(ans, '};\n')
return table.concat(ans, '\n')
end
I am distributing it under the terms of the GNU GPL v3. So if you put this in your codebase I will sue you into releasing your entire source. Just kidding it's MIT licensed.
Honestly that's a terrible joke. Seriously it's MIT. Here I will put the full license in this comment to illustrate how serious I am:
Copyright 2026 rweichler
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Feels like Lua is a more exotic dependency. I used to use xxd but this gets problematic when files grow (and they don't need to grow much at all), objcopy is much faster (which I didn't think would matter much, but it did) and don't have the same issues that accidentally opening the .h file in your editor or code-searching having to traverse that mess.
Yes, you'd want to gitignore it and exclude it from search etc. but you still have size issues etc. See gucci-on-fleek's comment on objcopy above for usage.
I shipped 20MB of XML with a product back in 2014; we loaded it at startup, validated it against the XSD, and the performance for this use case was fine. It was big because we did something kinda like what TFA suggests: I designed a declarative XML "DSL" and then wrote a bunch of "code" in it. We had lots of performance problems in that project, but the XML DSL wasn't the cause of any of them; that part was fine. I think "expensive" can mean a lot of different things. It was cheap in terms of development time and the loading/validation time, even on 20MB of XML, was not a problem. Visual Studio ships a tool that generates C# classes from the XSDs which was handy. I just wrote the XSDs and the framework provided the parsing, validation, node classes, and tree construction. This is as "XML proper" as I think it's possible to get.
I don't believe that .NET's XML serializer uses any of the open source projects mentioned in your post, so maybe we just have especially good XML support in .NET. I think Java has its own XML serializer, too. I bet most XML generated and consumed in the world is not one of those three open source C/C++ libraries. I think Java alone might be responsible for more than half of it.
Yes, Scintilla is a text editor engine library. It's not tied to any particular UI or technology. Out of the box it's not a text editor yet; you provide the frontend. You get all the "table stakes" right away if you build your editor on this library.
Same engine, different frontends. The engine has a series of hooks that you implement in whichever way you please for your particular interface. It's definitely the presumptive choice here.
Ah, I see! Very cool! Yeah, this is the kind of thing I was looking for, so this should give me what I need to test some proof of concepts. Thanks for the links! I do wish there were something a little more ergonomic, but I'm way too far into the begging to be choosing, here, so I'm quite happy to take what I can get.
In any case, I really do appreciate the dual links. It's so much harder to suss out the boundaries of a library with only one implementation. This was really helpful.
Collection expressions today are more the sort of thing that a code poet or golfer can do to prettify their code than something a newbie can count on using. It's tough to explain "you can only use this when the collection type is implied in that spot" to a newbie. The value of the base feature is still unproven for me. I'm not sure I agree, without some convincing, that collection expressions made the language more coherent rather than doing https://xkcd.com/927.
reply