I run Claude Desktop inside a Hyper-V VM. My VM doesn't have the "Virtual Machine Platform" feature installed at all. The app accepts this and simply disables the Cowork tab. I wonder if there's some other way to block the creation of the VM to force Claude Desktop onto this code path without having to uninstall Hyper-V.
That said, Claude (both Desktop and CLI) ships on Windows without any sandboxing support for Code. They only have sandboxing for Linux and macOS. If you need to run it on Windows, I really recommend running it in an isolated VM, which then allows you to omit the "Virtual Machine Platform" feature in the VM and solves this issue. The "Windows Sandbox" OS feature provides such a VM without needing another Windows license.
UTF-16 is the internal format of the ICU library (International Components for Unicode, the support library from the Unicode standards people) which is a common way to add "full fat" Unicode support to a programming language. This has knock-on effects everywhere. If you're using ICU, you either use UTF-16, too, or you constantly convert back and forth every time you interact with ICU. You're often best off using UTF-16 in memory and only converting to UTF-8 when you write files or transmit over the network.
Microsoft wrote their own replacement and it's better-integrated into Office than the old editor was. Search for "insert equation" in the Office search box. The new one supports both the old editor's style of input and actual LaTeX inputs. Heed the dates on articles talking about it: TFA is from 2018 before they wrote the new editor.
30 years ago, in C89 and pre-standard C++, it was the case that `int foo()` in C is a function that accepts any parameters, and in C++ it is a function with no parameters. In C89 you have to write `int foo(void)` if you want no parameters. This counterexample to C++ being a superset of C was well-known even back then.
Another well-known counterexample is implicit conversion from void*. In C89 you can do `int* foo = malloc(100);` but in C++ it requires an explicit cast from void* to int*.
I don't believe there was ever a time, even pre-standardization, when C++ was a strict superset of C; it always had little incompatibilities here and there.
> I had forgotten than you can build a perfectly legal enum from an integer out of the bounds of the enum's range. And a switch statement is non-exhaustive
These are solved by the new feature described in the article that we're commenting on right now. They're giving us unions and exhaustive switch. Ctrl+F "canonical way to work with unions" in the article to see an example. One of the best parts about C# is they never stop bringing useful features from other languages back home to us in C#. It makes for a large language with a lot of features, but if we really want something, we'll eventually get it in C#.
I helped out on this image-to-bits transcription, doing manual verification of the automated work. I did the whole thing by hand: I sliced the ROM images into strips that excluded parts of the image that don't encode bits, used my tablet and stylus to manually place a black dot on every 1 bit, then wrote a trivial program that detected the presence or absence of the black dot in each cell. From my perspective, the ROM is organized like a series of "ladders" where the 1 bits are missing legs of the ladder, and I was placing dots on the missing legs. I compared my results with the ML output and manually re-checked each bit where we disagreed.
The submit button in the post box says "add comment" vs. "reply" depending on what kind of message you're posting, and the link under comments says "reply" while articles don't have that link. I called it the "top-level descriptive comment on their Show HN post" because I agree just "comment" vs. "reply" alone could be confusing. What's a better way to describe the comment that an author posts with their Show HN to begin the discussion vs. replies that are made in response to specific comments? I genuinely don't know how many more terms I could have loaded onto that phrase to make it clear which post I was talking about. That wasn't supposed to be a confusing part of my post.
Yes, I'm obviously aware of that. We're all capable of seeing em dashes and staccato sentences. My reply mentions, explicitly, that their top-level comment was AI written (reusing portions of their AI-written readme) and that their replies are human written. I chose my words carefully; HN itself uses the terminology "comment" for top-level messages and "reply" for sub-level messages, and I used the phrase "top-level" to further disambiguate it. I apologize if that was confusing but what I said was accurate and carefully considered. I further agreed that they should not have done that. That one comment seems to be their only crime here. You then took the opportunity to soapbox about a bunch of things that OP did not do, in the message that I replied to.
I don't have anything to add. It just seems like you misunderstood my message.
This OP hasn't done any of those things. They are here discussing the project, and it's clear all of their replies are human-written. The AI use is stated up front in the readme. They posted a 12 minute YouTube video demonstrating that the project works, with narration that indicates English is not their first language. The git commit messages are all classic short human messages. It's a genuinely neat project that obviously has no commercial motivation. Their crime appears to be using AI to clean up their non-native English in the README and then reusing some of that README text in the top-level descriptive comment on their Show HN post. Indeed, they should not have done that for their comment, but the rest of these accusations are just soapboxing about AI. You could have written this comment anywhere; it has nothing to do with this post.
I'm not disagreeing, but I will point out that COM reference counting is an atomic integer operation. That's expensive. boost::local_shared_ptr exists because std::shared_ptr does sometimes cause performance problems. std::shared_ptr must be used sparingly. It's unlikely to matter in a UI scenario with long-lived objects because it, indeed, does use reference counting sparingly.
I don't think AWS says so explicitly, but it's commonly known that T2/T3/T4 use live migration to balance workloads across hosts. This is necessary when oversubscribing hardware (which is the explicit purpose of these families) to avoid hot spots. This may be the "runtime interruption behavior" that the author sees. Use an instance family with dedicated CPU capacity if this matters to you. With T2/T3/T4 you are explicitly asking for variable performance to save money.
"Short of..." indeed. You already know the answer, although it doesn't need to be general; it only needs to work on a single codebase.
A recent and highly relevant example is the migration of the TypeScript compiler to Go. They did not use an LLM to translate the code. Instead, they used LLM assistance to write a deterministic TypeScript-to-Go translator and then used that to translate the code. I have far more confidence in this approach than in letting the LLMs rip on the translation itself.
Even if I wanted a Windows-specific UI, I still wouldn't choose WinUI 3. You can ignore it.
At my day job, I choose Windows Forms with Blazor mixed in. That's old reliable Win32 tech + modern web tech, without any modern Windows tech mixed in.
Before R3 was PR1 and PR2, hence the 3. It didn't jump from DR8 to R3 like the article says. The discs were labeled "Preview Release" and "Preview Release 2" and they're common to find on eBay.
I got my start with the R3.2 demo disc. This was a free CD you could order for the cost of shipping. It was a live CD that booted directly into BeOS (maybe with the help of a boot floppy, in those days). I was hooked as soon as it booted (fast, even from CD!) and I clicked around for a few minutes.
I think you're directionally right but the bit about the web browser confused me. Haiku ships with WebPositive. You'll remember NetPositive from the R5 days. That's one of the few things Haiku does have.
Just because a hypocrite says something doesn't mean that thing is wrong. If a drug addict tells you not to use drugs, they're still right about that. UBI is the solution, isn't it? Capitalism both requires everyone to have a job while at the same time providing no guarantee that jobs are available. The idea doesn't get tainted just because the words left the mouths of a few rich hypocrites. We have to do it despite them.
Can you give an example of a language ecosystem that went with reflection-based JSON serialization/deserialization and then went on to regret it? I can't think of any, and don't agree with your conclusion. It works great, and manually writing serialization and matching deserialization code is terrible, annoying, error-prone work.
> EV certificates no longer bypass SmartScreen. Years ago, signing files with an Extended Validation (EV) code signing certificate would result in positive SmartScreen reputation by default, but this behavior no longer exists. EV certificates may matter for enterprise procurement, but they no longer impact SmartScreen behavior. Paying a premium for EV solely to avoid SmartScreen warnings is no longer justified.
It's expensive. I don't agree that it's harder, in the sense of TFA's technical struggles getting it to work. If you've got the money for the certificate, passing OV and signing the binary is easy. The difficulty of signing isn't the big problem we face on Windows. The main issue is that signing barely does anything: you still get hit with SmartScreen blocks even though it's signed. The return on your investment of time and money is just showing your name as the publisher in the SmartScreen prompt. The only way to avoid the SmartScreen prompt is by building reputation with lots of installs.
I still prefer this over having a Microsoft developer account and publishing in the store--I hate having to put my software through arbitrary store review processes--but it's not a good situation. SmartScreen is just about the worst thing ever to happen to indie developers on Windows. We're right there in the thick of it with macOS developers: different details, same struggle. Both of our corporate overlords want you to distribute software in their store, and you get the sense that they would end self-distribution entirely if they thought they could get away with it.
I note that TFA's author edited the post after-the-fact, changing the line about Windows. It originally claimed that Windows worked fine and they got "just an EXE" and that was that. I assume they finally tried it for real on a civilian computer and saw the SmartScreen block.
That said, Claude (both Desktop and CLI) ships on Windows without any sandboxing support for Code. They only have sandboxing for Linux and macOS. If you need to run it on Windows, I really recommend running it in an isolated VM, which then allows you to omit the "Virtual Machine Platform" feature in the VM and solves this issue. The "Windows Sandbox" OS feature provides such a VM without needing another Windows license.