Nothing wrong with using AI for software development, but your product landing page being chock full of LLM-isms is an honest signal about how much care was put into this project.
Also, it somehow, bafflingly, against all odds, manages to use 60% more memory and 3x as much CPU as the underwhelming XAML task manager that comes with windows. How about we figure out how to use fewer resources, rather than way more resources, than the already unreasonably inefficient thing that Microsoft ships?
Also, I find it funny that this TMOG thing seems to apply a special rule such that its own process does not appear in the dashboards by default.
My one data point is that Casey’s handmade hero series, and his immediate mode gui video from way back in 2005, are what introduced me and some friends to an entirely new way to build graphical user interfaces, and I do feel a great appreciation for that. Guys like Ryan Fleury (of RadDbg) and Vjekoslav Krajacic of Filepilot similarly credit Casey with their “radicalization” :)
To your point though, it was less about specific technical knowledge conveyed by these videos and more about him evangelizing a high level approach that many folks otherwise wouldn’t have considered
I want more things like that old hand made hero to exist in the world, but, from an interview with Casey himself, it doesn’t pay well enough to justify. Someone with the chops to put that together is in a position to be doing something much better incentivized.
> Open source is the very worst thing currently going on because it is so incredibly exploitative, it's far more exploitative than any actual company is of the workers who work at the company.
> Even the people who are getting paid in open source are getting massively underpaid to do it compared to how much the people who are using their code are making, it's nothing compared to the power that is accreted by the people who have co-opted that work thanks to the open source model. And then mark zuckerberg gets to define how the internet works despite having paid for almost none of the software that his company actually needed to make that work.
> It's like feudalism or serfdom, these people did the work and got nothing for it. It's like you took the worst aspects of capitalism for workers and the worst aspects of socialism for workers and put them together, that's open source. You get no power and you get no money.
> It's exploitative whether the people chose to be exploited, just because someone chooses to let you exploit them does not mean that you didn't exploit them. And for the record that's how most exploitation works; convincing people to do something that turns out to be very bad for them and very good for you, and that's exactly what the open source movement has turned out to be.
> I really don't see the "we post stuff on github under a gpl2 or lgpl or apache or mit license", all that is to me now is just exploitation. You can say that there's solutions but until someone demonstrates that those solutions work, it's the standard "real communism has never been tried" argument. AGPL is the only thing that I've seen so far that's an attempt to fix these fundamentally unfair compensation practices.
This is the first I've heard of these critiques from him, and as someone who loves open source/Linux, and belives it makes the world better in many ways, I think they're pretty valid. The model has major issues in at least two distinct ways:
1. Not paying for the labor corporations exploit. GPL is better here, but still imperfect. MIT/BSD is awful here. It wouldn't matter in an ideal post-scarcity society, but we don't live in that yet, so it does matter. Until post-scarcity, a better model would route revenue from exploitative capitalist uses back to the creators and/or their desired sinks.
2. The open source bait-and-switch - startups using open source to get users and then pulling up the ladder and going closed source and monopolistic once they have achieved scale to enforce/ achieve lock in.
Usually when I talk to very staunch FOSS zealots they're bewildered that someone would care what a corporation does with their code... at least as long as the license terms are adhered to.
In fact they don't seem to care about money at all, often believing all corporations/capitalism are bad, and that they and everyone else should just be poor and live in the woods or something.
I feel like if you plotted open-source vs proprietary code percentages against the rate of innovation, it would be a bell curve: once you start giving away too much, the incentive to innovate diminishes.
You can get a sub 20kb executable with C in MSVC and no weird tricks, i.e. just setting a particular combination of compiler/linker flags, like /NODEFAULTIB, /MERGE, /FILEALIGN:512 etc. Small enough that it's basically nothing, downloads in a couple of seconds over 56k dialup, and you get to use normal tooling. This is the compromise that makes the most sense to me, for products you're actually shipping. If you want to try out the nocrt approach, honestly the LLMs do a fine job of writing you some replacements for the parts of the crt that you likely want i.e. memcpy/memcmp/strlen helpers, with x64/arm64 SIMD and all.
Set /HEAP:4096,4096 and /STACK:65536,4096, write yourself a simple 100 line growable arena implementation, use that, avoid the heap entirely. Very quick and easy way to get a real windows program up and running that uses about 500kb of commit at baseline.
You end up with only ntdll.dll, kernelbase.dll, and kernel32.dll loaded. Trying to eliminate any of these becomes pretty painful and you venture into the territory of weird tricks that are expensive to maintain.
Then you load User32.dll, and you get 2MB of commit and 1MB of private bytes. Throw in a Message Box, and it's 272KB more private bytes and 388K more commit.
Windows 10 makes it literally impossible to write something that uses low memory and uses an actual window.
True, the project where I used the approach above was a TUI, so windows terminal sort of eats the impact of stuff like user32 and dwrite for you.
One trick I know of to make user32 a bit more lightweight is to call ImmDisableIme prior to creating your first window. This disables a lot of the TSF integration, which is notably quite slow. Not sure if it impacts memory footprint but worth a try. It of course does what the name says and disables IME support, so not a viable option if you have users who need IME
I can guarantee you that Raymond had zero input on any of these decisions. He values fundamentals, quality, and customer satisfaction more than anybody. But ultimately, is just an "individual contributor" engineer down in the trenches following orders. He probably feels the same way you do about this stuff. The real question for me is, why does a famous person like him, with so many options open to him about where he works and what he works on, continue slogging away in Redmond.
My best guess is that he has devoted most of his working life to Windows, and it would be painful give up on it. He has lived through many dark periods, i.e. ME, Vista, Windows 8, and is probably optimistic about the pendulum swinging back towards quality/fundamentals eventually.
Raymond's work often uses analogies to everyday, real life situations to make the technical stuff more relatable. Sometimes, these end up being bizarre and even nightmarish. It's like a glimpse into some alternate world where the denizens are adversarial, hyper pedantic, scheming, criminally insane, or just plain stupid.
"Sometimes I’m in a hurry, and I want to make sure I am the next person to get served at the deli counter. To do this, I find whoever has the lowest number, knock them unconscious, and steal their ticket. But sometimes somebody else comes in who’s also in a hurry. That person knocks me unconscious and steals my ticket. My plan is to set my watch alarm to wake me up periodically, and each time it wakes me up, I find the person with the lowest number, knock them unconscious, and steal their ticket. Is there a better way?"
"This is like asking for a cheeseburger and then trying to peel every last bit of cheese off the patty to turn it into a plain hamburger."
"This is like driving up to a bridge, seeing a 'Bridge out of order' sign, then getting out of your car, moving the sign, driving onto the bridge, falling into the river, and then complaining to the car manufacturer that their car doesn’t work."
"This is like calling the natural gas utility company’s emergency number to report a major gas leak in your house. The gas company sends a technician over, and they can’t find any leak. They ask how you came to suspect that there’s a gas leak, and you tell them, 'Oh, I didn’t smell anything. I called you because I’m hoping to learn more about how to recognize the smell of gas. Do you have any tips?'"
"This is like 'I have this cupboard full of rubbish, so I will solve that by nailing the doors shut'"
"It’s like asking, 'What happens to the phrase 1 cup sugar when I eat my cookies?' The phrase 1 cup sugar was part of the instructions for making the cookies"
I hesitate to make this sound positive, but to their credit, the leadership at Microsoft who likely steered the weather app towards using the web stack at least correctly identified a major problem: there is not a single good native UI framework for Windows today.
Was switching to webviews the right solution to that problem? Absolutely not. But at least we can admit they were in a difficult position.
At the time this bloated weather app was probably developed, the choice that most of the rest of the shell and in-box apps were making was C++/WinRT paired with System XAML (i.e. Windows::UI::Xaml aka WinUI 2 aka UWP XAML) via the still-marked-as-experimental-in-2026 islands API (DesktopWindowXamlSource) like the taskbar/control center/file explorer/etc. Or worse, actual UWP, such as the Start Menu, Settings app, or Notification Center. This can have a decent-ish memory footprint - Control Center, for example, uses about 150MB of commit and 30MB of working set. Still not good, but not atrocious either. But even for this mediocre level of performance and efficiency, you end up paying a very high cost in terms of development time and expertise required. This stack "just works" like 70% of the time, but the other 30%, you're scratching your head figuring out where you forgot to hold a strong reference across a co_await boundary. Or figuring out why a XAML ListView corrupted its recycling pool in korea because window messages reentered a nested message loop started by XAML's outbound RPC call that's only made in the TextBlock code for east asian languages. You get a razor thin veneer of user-friendliness, i.e. MVVM, x:bind, co_await ("hey, this is just like C# + WPF!") on top of a 60% finished UI framework and a terrible programming language feature which is quite possibly one of the leakiest abstractions in the history of the world (C++ coroutines). The fact that Raymond Chen managed to write a blog series on C++ coroutines in Windows that is 60 posts long is damning: https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=10...
On top of all this, Microsoft's status in the industry has dropped. And they have absolutely no structured technical training program for new employees. I guess just pray you get paired with a decent mentor. So, young employees fresh out of undergrad who are asked to work in these codebases are super unproductive and make mistakes on a regular basis that cause inscrutable memory corruption bugs.
For a time, leadership was wildly flailing around trying to find some alternative to this madness. At the time when this bloated weather app was developed, the hot idea was that we should be switching to the web stack for native experiences. There was some low effort hand waving about how WebView2 would be continuously improved, we would mitigate the memory footprint by sharing webviews, etc.
My position is that there's no reasonable choice for building efficient native UX on windows today except by targeting a lower level graphics API like DirectX, Vulkan, OpenGL, or even software rendering in GDI, rather than a GUI framework. Most serious software on windows ends up going down the route of literally building their own UI framework, i.e. web browsers, office, adobe suite. If you don't mind the dated look/functionality of win32's stock common controls, that's also a decent option. I've heard that Qt is okay, but haven't tried it.
One final note: if anyone is earnestly wondering whether WinUI 3 is perhaps, finally, an end to all the bloodshed, my take is: no It is (currently) UWP XAML wearing a trenchcoat, plus a needless namespace change that broke compat, plus the baffling choice to run a copy of the compositor in-process in order to - wait for it - be able to ship WinUI 3 apps downlevel to Windows 7 and have acrylic work correctly!!! (to their credit, they have signaled that they are reversing this decision and moving back to the system compositor). WinUI 3 has the potential to be good, but appears to be too underfunded to achieve its potential.
Lots of iGPUs just end up being backed by system memory. But even then, this is a ridiculous hand wavy excuse. A 4000x2000 RGBA buffer is 32MB. That only explains 2.7% of the weather app's devastating memory footprint.
They don't want you to remember that Windows XP's minimum system requirements specified 64MB of RAM. This weather app uses 20 times more memory than an entire operating system from 25 years ago.
Normally I don’t give much attention to online layoff rumors, but George is very credible and allegedly has some inside sources. I do wonder if this will be a tipping point for gaming industry unions.
Also, it somehow, bafflingly, against all odds, manages to use 60% more memory and 3x as much CPU as the underwhelming XAML task manager that comes with windows. How about we figure out how to use fewer resources, rather than way more resources, than the already unreasonably inefficient thing that Microsoft ships?
Also, I find it funny that this TMOG thing seems to apply a special rule such that its own process does not appear in the dashboards by default.