You're just talking about 'explorer.exe' being 5 mb? You're discounting the numerous DLLs which the explorer uses, or even other shared resources which are used system-wide.
And 55 MB for a native app is paltry. Even the 'Google' app on Android is 285 MB, the Gallery app of OnePlus is 70 MB.
Your standards are unfortunately warped by modern trends. Almost all popular apps are hugely bloated because the developers just don't care, the focus is on UI re-design and feature churn and the illusion of ease of development. Some counter examples (compressed installer size for convenience):
7-zip for 64-bit windows: 1.4 MiB
Winamp 5.8: 7.8 MiB
mpc-hc: 13.5 MiB (open source media player with many built-in codecs)
irfan-view: 3.4 MiB (image viewer/utility)
uTorrent: 2.3 MiB
Sysinternals Process Monitor: 1 MiB
For a truly native application, which doesn't pack a huge run-time or dependency tree, that's the expected size range. Now, it's true, it seems no one does that anymore ...
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. :)
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.
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.
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”
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.
You're discounting the numerous DLLs which the explorer uses, or even other shared resources which are used system-wide.
I see this argument brought up in demoscene discussions ("your .exe is 4KB but it uses several GB of system libraries and device drivers!") and the rebuttal is the same: I'm assuming this UWP one itself makes use of other system DLLs too, like any other Windows application will, so the comparison is between 5MB + shared and 55MB + shared.
Even the 'Google' app on Android is 285 MB
Android is a whole other story altogether. The bloat is endemic there, and emulating that is not at all something to be proud of. Windows applications can be far more efficient, as Windows' own explorer.exe shows (and even that is probably not anywhere close to "perfection", but the difference is already enormous.)
It's not just a matter of using random system functionality; I think Explorer uses the same UI code as Open/Save dialogs, in which case the UI itself necessarily lives in system DLLs. (But I'm a novice when it comes to Windows, so I could be wrong.)
Yeah, all the file tree view/list view stuff, shell namespace etc. etc. is implemented in shell32.dll, so we should probably compare with explorer.exe + shell32.dll. Everything else are basic widgets and OS interaction which clearly exists in both environments so shouldn't be counted.
And with that it is still only 4.27MB+6.81MB = 11.08MB on my system. So yeah, the bloat is real no matter how you look at it.
For a native app of Windows Explorer kind that doesn't pack massive resources, 5-10 Megs is a reasonable size.
Heck, you are forgetting than something like 3D Studio MAX originially fit on a set of floppies and I can assure you it could do FAR more than "the Gallery app" whatever the heck that poor thing is.
on the other hand, just the splash screen image for whatever $modern app can be more than the space available a floppy since you need it normal size, @2x, @3x, it's in 32-bit RGBA instead of 256 color...
The fact that it needs a splash screen in the first place is because it takes too long to start because of bloat, so in a way it's a negative feedback cycle.
> The fact that it needs a splash screen in the first place is because it takes too long to start because of bloat, so in a way it's a negative feedback cycle.
no, had to build a few apps where this was requested only for branding purposes.
The bundle also seems to include dependencies for multiple architectures and PDBs for debugging. Files.dll which would contain most of the application is ~18MB. And since it does not seem to be a managed dll, it has probably been AOT compiled and likely contains the original bytecode in addition to the native machine code.
And 55 MB for a native app is paltry. Even the 'Google' app on Android is 285 MB, the Gallery app of OnePlus is 70 MB.