It's tempting to look at it that way; but that's being over-reductive. UIs of today are not the UIs of 20 years ago. Users expect much more from today's UIs, and UI toolkits necessarily get more complex as a result in order to deliver on those increased expectations.
And if you don't agree, this is Windows we're talking about. Nothing's stopping you from creating your application with Win32 except for the fact that it's going to look and feel like an application from 20+ years ago.
What do they expect that WinUI provides that classic WinAPI UIs don't?
This is not a rhetorical question. I do see some things, like antialiased drawing, etc (GDI is outdated, but I'm not convinced newer drawing could not be added.) But in general the classic ones work, including with accessibility, and are highly functional and batle-tested.
This is funny. You know, users also want games to be ridden of DRM but I don’t think the big companies cared about that for a long time. Users also want a lot of things that they never got, like a visible scroll bar sometimes.
And since Windows is primarily OEM or enterprise, I don’t know what users are going to do if Microsoft sticks to say Windows 7 UI? Like, uninstalling Windows and switching to Linux? Oh yeah, they are doing that right now.
Sure users want A or B, but that’s not important. What’s important is some idiot VP saw something and decided to push on, and other managers jumped in to grab the pie.
20 years ago was 2006. Back in those days the vast majority of UI paradigms have already been explored for decades and the standard window pane UI has existed since the 80s. The biggest difference between back then and today is the eye candy and the fact that browser based UIs took over.
Do they really though? I understand wanting to be able to use a common layout between mobile and PC devices, but even when you factor those things in there's no reason that we should've gone from something snappy at a few 100MHz to sluggish on multicore GHz processors
> it's going to look and feel like an application from 20+ years ago.
This is simply not true. You can built completely modern apps in WPF if you want. There is nothing about the framework that says your app is going to look 'old' except if you are just using default styles, and if that's the metric here then... we got bigger problems.
.. and get much less. Especially in accessibility. We've lost things like ubiquitous accelerator keys and even basics like "being able to tell where the edges of controls are or which is the active window".
The only real advantage WinUI has over WinForms is "responsive" resizing and display scaling.
Not as much of a lack of seriousness as excusing away hallucinations as not that big of a deal in what's supposed to be a researched, scholarly body of work written by humans.
In 2026, LLMs are highly intelligent. In many ways, they even surpass human intelligence and ability. Dismissing them as "bullshit generators" is utterly unserious, and shows that one does not want to deal with the reality of the situation.
I don't see anyone excusing hallucinated citations. I see people arguing that this is an overreaction by the arXiv. AI is going to become a major part of research, including in writing papers. It would be better if people would freak out a little less about that fact.
If the author just wanted to add a citation to some canonical paper (like "Attention is all you need") at the last minute, used LLM autocomplete to do it, and didn't carefully check that the citation was correct, then a year-long ban is a massive overreaction. A careless miscitation is not on the same level as something like data manipulation.
In general, I think everyone needs to be practical about what the actual risks are of LLM use. Are we worried about true nonsense flooding the arXiv? Or are we worried about tracking authorship when LLMs are involved? What's the actual concern?
> how do you exactly know how javascript works inside out?
Javascript has pretty detailed specifications. They're not exhaustive, but the article here does mention that in some of the dark corner cases they compared behavior against other existing Javascript engines.
There's also a very comprehensive test suite (Test262) that comprises almost 40,000 unit tests that exercise various aspects of the language that a new implementation can use to get a pretty good view of how much their new engine conforms to the specification.
> I sat through a conference session in the late nineties trying to understand the difference between an OLE document, a COM object, and an ActiveX control.
To be brutally honest, if you were a serious Windows developer in those days (and you were even the sort who'd have sat through a conference session on the topic); there is absolutely no way in hell you'd not understand the difference between OLE, COM, and ActiveX. Conflating these things as some sort of confusing mess either shows a lack of actual experience, a lack of competency, or a desire to falsely make things seem more confusing than they were to add some meat to an article.
This article dances with some good points, but opening up with this sort of hyperbole (and then ending it with an unabashed AI slop image filled with brand new hallucinated characters of the alphabet) just totally tanks the author's reputation.
This particular vehicle was sold at an impound auction under a court order. Any existing legal ownership of the vehicle prior to the auction was extinguished.
There was a software package a couple decades ago, I want to say it was Lotus Notes but I'm pretty sure it wasn't actually Lotus Notes but something of that ilk, that would show a small, random number of asterisks corresponding to each character entered. So you'd hit one key and maybe two asterisks would show up on screen. And kept track of them so if you deleted a character, it'd remove two.
I thought that was kinda clever; it gives you feedback when your keystrokes are recognized, but it's just enough confusion to keep a shoulder surfer from easily being able to tell the length of your password unless you're hunt-and-pecking every single letter.
Yup, it was Notes, I used it at IBM. It was an unbelievably stupid idea. Every single day people were asking why their password was wrong because they were confused by the line of stars being too long.
Yeah, I remember Lotus Notes both showing multiple filler characters per keystroke and showing different keychain pictures based on the hash of what you typed. This way you could also tell you've made a typo before submitting it.
If the hash changes after every character, doesn't that make it possible for someone to determine your password one character at a time if they know what each hash was?
I'm guessing that wasn't in the threat model at the time.
Hmm. Let's say you have 64 possible characters you can use in a password and four different images. You look over someone's shoulder and see that they go "RGBYYBRYG".
What this means is that you can now reduce your search space to approximately 16^9 passwords instead of 64^9 passwords. Which is probably very helpful if you have stolen the password hash, but not if you have to guess it by entering the password manually.
Makes sense. I was under the impression there were more than 4 outputs based on what you entered. (I've seen a similar setup that shows two hex digits)
It's still baffling, since the core idea of React only makes sense as a workaround for limitations of the browser DOM. Wrapping much more flexible 'native' widget frameworks with a React layer is pure cargo culting (same with SwiftUI).
ok, granted, but microsoft already builds a first party way to orchestrate a UI comprised of native controls. Why do they invest so much effort into WinUI and C# if they're just going to use a 3rd party solution? Presumably the windows 11 start menu does not need to run on macOS or Linux.
Because it uses C++, and C++/WinRT tooling for UI development isn't there.
The team that killed C++/CX, said it isn't their problem that there aren't Visual Studio integrations like C++/CX, and eventually left C++/WinRT in maintenance and nowadays is responsible for windows-rs repo. Better not expect too much from that repo as well.
Hopping in here to suggest that instead of running a persistent whole-ass daemon, you could just configure a systemd service, set it up to trigger off a write to a fifo, and then use filesystem permissions to restrict access to who can write to the fifo to whatever user/group should be allowed to perform the operation. (You can also do it by giving those users sudo access specifically to be able to trigger the service via systemctl; but if our goal here is to eliminate the use of setuid then any solution that uses sudo fails the assignment).
The systemd service executable is just your simple C program as-is.
Persistent whole-ass daemons aren't really the way it should be done even over in Windows, because in Windows you can attach ACLs to give permissions to start a Windows service to any arbitrary users that should be able to do so; which is spiritually equivalent to the Linuxy systemd solution.
It's about being able to perceive it as a "living" moving creature and not something different.
You can understand something below the perception threshold is supposed to be a creature because you both have a far more advanced brain and you've been exposed to such things your entire life so there's a learned component; but your dog may simply not be capable of making the leap in comprehending that something it doesn't see as living/moving is supposed to be representative of a creature at all.
I've personally seen something adjacent to this in action, as I had a dog over the period of time where I transitioned from lower framerate displays to higher framerate displays. The dog was never all that interested in the lower framerate displays, but the higher framerate displays would clearly capture his attention to the point he'd start barking at it when there were dogs on screen.
This is also pretty evident in simple popular culture. The myth that "dogs can't see 2D" where 2D was a standin for movies and often television was pervasive decades ago. So much so that (as an example) in the movie Turner and Hooch from 1989, Tom Hanks offhandedly makes a remark about how the dog isn't enjoying a movie because "dogs can't see 2D" and no further elaboration on it is needed or given; whereas today it's far more common to see content where dogs react to something being shown on a screen, and if you're under, say, 30 or so, you may not have ever even heard of "dogs can't see 2D".
I mean it's a dog so you can't exactly ask them; but this was a dog that would bark at every other dog. If he wasn't barking at Hooch because Hooch was only showing up at 24 FPS, then I'm inclined to think he didn't recognize Hooch as another dog.
The use cases for YAML that don't involve any sort of scripting vastly outnumber the use cases for YAML that involve embedding scripts into a document; so it's a little unfair and inaccurate to say that "in YAML it's kind of expected".
It is more fair to say that if your document needs to contain scripting, YAML is a better choice than JSON; for the singular reason that YAML allows for unquoted multiline strings, which means you can easily copy/paste scripts in and out of a YAML document without needing to worry about escaping and unescaping quotes and newline characters when editing the document.
And if you don't agree, this is Windows we're talking about. Nothing's stopping you from creating your application with Win32 except for the fact that it's going to look and feel like an application from 20+ years ago.