I agree to those points, and really happy that 7-Zip still fits on a floppy (when the floppy itself is dead). The bloat is real, but it's not something specific to Windows. All three platforms, plus the web, have become bloated. But picking the 50mb size as a stick to beat an app which is still maturing is too harsh, IMO.

If it was just a regular app I'd agree, but file explorer is pretty integral to the OS experience. Any bloat there cascades as multiple instances are launched or called from other applications. As a counterexample, here's XYplorer, another file explorer alternative: https://www.xyplorer.com/ which weighs in at 7MB.

True - and reports seem to be that the actual compiled code is like 18 MiB. It's the comparison to these huge android apps that got me. I could do this for android too: keepassdroid is 4 MiB, zxing barcode scanner is 0.7 MiB ...

So many people just don't understand the scale of these things.

Thank you for mentioning IrfanView. Back in the day I used to have a cracked copy of LviewPro that was always one of the 1st programs to be installed whenever I started working on a new system. It was small, fast, and I could easily flip through all the image files in a directory.

I stopped using LviewPro probably 8, or 10 years ago, but always wished I knew of a replacement that was so efficient. I see that IrfanView also does quite a bit more. I think I have a new favorite!

Now, if you'll pardon me, I need to drop the author a kind note. :)

Yep, IrfanView is fantastic, I gladly paid the license. Sadly it's not available on Linux.

Wow one of the lucky 10 000! I can understand your happiness, I think I felt the same way probably over 15 years ago when I first found it.

ACDSee was thee shit, mate

Fastpictureviewer? I haven't found a program (on Linux too) that comes close to the performance.

It's probably not OP's code itself but usage of UWP. The apps you mentioned here are all written in pure Win32 API. HWND, HANDLE, HPEN, HDC, anyone? Just pure C (or pure C++) and some functions... Those were the days!

FWIW Total Commander's EXE and DLLs are around 8MB (the installer is 4.2MB) and uses around 6MB of RAM right now (for comparison, the new UWP Calculator uses 18MB of RAM). It is not written in pure C/C++ nor uses Win32 directly but instead it is written in Object Pascal/Delphi or Free Pascal/Lazarus (depending on the version you use) and uses VCL or LCL (well, it probably does use some Win32 directly too). Also runs on any Windows PC from Win95 to Win10.

I mention this because Delphi and Lazarus are quite high level environments to work with with rich frameworks and libraries yet you can create very lightweight applications with them (the executables will be a bit fat compared to what you can do with pure C/C++ or even pure Free Pascal, especially with Lazarus, but resource consumption is still low).

You do not need to use C/C++ with pure Win32 API to create lightweight applications and even if you use those there are frameworks that allow for easier development (e.g. WTL, Win++ or libui to mention some).

Our hardware tooling is all written in C++/Win32 and some MFC; it’s all tiny and light. Because factory controlling computers are (unfortunately imho but what can I do) older Windows versions (for us that is due to certification etc mostly) on weak but robust systems with little memory that need to run for years without issues/crashes. So lean, fast software, tested for memory leaks which can be restarted in very short times (downtime of the production line is expensive) is important.

Unfortunately those APIs seems to be kind of obsolete nowadays. All the nice things are with UWP. I think that WinAPI is not even hardware accelerated. That's a pity, but what can we expect, when Microsoft themselves botched WinAPI in their own products long ago.

Windows could be so better with their old Windows 2000 style, without all those design jumps around.

You can do hardware accelerated stuff atop WinAPI; many, sadly, don't seem to know it. WinRT, is exactly for that; it's the distillation of UWP, which can be used in a simple Win32 app [1] e.g. The modern, hardware-accelerated API for compositing on Windows is Visual Layer (available under `ABI::Windows::UI::Composition`) [2]; it can be used from a Win32 app written in pure C++ [3] and the C++/CX language extension is unneeded.

[1]: https://en.wikipedia.org/wiki/C%2B%2B/WinRT

[2]: https://docs.microsoft.com/en-us/windows/apps/desktop/modern...

[3]: https://docs.microsoft.com/en-us/windows/apps/desktop/modern...

Microsoft itself doesn't think so highly of UWP now: https://news.ycombinator.com/item?id=19883351

Oh, thanks, that's nice to know, I missed that. I always liked WinAPI style and I hope that it'll reborn.

What nice things are with UWP? I haven't seen any UWP application i'd consider "nice" :-P.

And IMO WinAPI not being hardware accelerated (although i think some parts of it, like filling and blitting, are hardware accelerated) isn't really a big issue - if anything, requiring hardware acceleration from you UI might be a hint that you are making it a bit too flashy. But that might be me preferring plain and compact UIs like those made with Win32 as opposed to website/mobile-like stuff.

"modern" UI is backwards. A lot of space wasting, hiding essential stuff, animations that are not necessary.

And then there's https://www.nirsoft.net/ full of useful utilities measured in tens of kilobytes... it's insane. The largest 64 bit exe is 249 232 bytes.

So it’s 4x the size of mpc-hc, did the sky really fall here? I’m not on a computer but quickly scanning the repo there’s a fair number of image assets, so I don’t really know that that’s a good proxy for “bloat”

why image assets are necessary with modern application? We should be using vector images by now. And vector images are tiny.

Yeah sounds like a great PR for someone to make who truly thinks this is a major issue

Yeah but 7-zip's UI is small enough to be just about unusable on my 4k monitor. Sometimes drag-and-drop is broken and sometimes windows don't resize right. Maybe if they had used a good UI library instead of rolling their own stuff, they would have to spend less time chasing a bunch of little bugs and the users wouldn't have to deal with them either.

But..but..RICH UI!!

Rich, as in "loaded with fat".