Hacker News Reader

The author is a student, so I think we can give them a pass. Besides, the code gets compiled! It's hardly as if that if statement is contributing to bulking out the executable to 55MB.

UWP apps tend to be pretty big, especially when compared to Win32/whatever Explorer is written in. That has very little to do with the author and much to do with the framework.

It's a little dispiriting to see this as the top HN comment on a high schooler's project .

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.

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.

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.)

That said, the bloat is real.

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.

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.

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.

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.

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. :)

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

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

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!

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.

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.

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.

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...

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).

But..but..RICH UI!!

Rich, as in "loaded with fat".

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

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

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.

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.

55 MB is an absolute fuckton.

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.

This just reminded me of https://prog21.dadgum.com/116.html Things That Turbo Pascal is Smaller Than

http://html-notepad.com - distribution 2,5 Mb (compressed) http://notes.sciter.com - 2.5 Mb and on all platforms.

And these applications are not using "numerous DLLs" - just two files: app.exe and sciter.dll (and that one can be linked statically into executable).

So "yes", 50 Mb for an Explorer thing is too much.

The code has many 'smells' indeed but was written by a high schooler. If you take that into account it's really quite commendable how polished and thought-out the app is.

Sadly, I have seen 'senior' engineers write much worse code than this...

Thank you for your useless driveby code review for a student project on a third party site that could have been an educational pull request to the author.

Maybe he's just a kid, and we shouldn't shit on him?

Just for context I packaged an empty UWP app using the release flag for x64, zipped it, and the final size came out to 23.2 MB.

And there is no gradient on the title bar. That's just the background showing through due to transparency (Acrylic in UWP/Fluent design lingo).

Does Windows not remove translucency when taking screenshots, as macOS does?

No, but sometimes it seems to hide what is behind the translucency so as not to pollute the screenshot. Other times it does not seem to do this. I don't know the pattern or rationale.

Dumb question: Why is this behavior desired? If I take a screenshot I want an exact record of what is currently displayed. I don’t presume to be a normal user but am super curious about the “other side”.

I’ve run into a related behavior on iOS where I really dig some color palette while viewing in inverse colors and want to take a screenshot to capture it. The screenshot is “helpfully” stored as not-inverted color thereby stymying my efforts.

It prevents the generation of consistent screenshots and looks somewhat unprofessional. It's the same reason why product marketing shots don't have clutter on the desktop or a bunch of random applications running in the background.

I've checked WindowsApps folder once, and there were a ton of apps with an old version (x86, x64, noarch) and a new version (once again all the architectures). In total 6 (!) versions of the same application, each taking up to 60MB. Code quality has dropped significantly as well, Settings, Taskbar, Mail crash and lag.

It's because Microsoft heavily promotes the development of UWP apps these days, there are less and less programmers able and willing to spend their time writing Win32 apps, and as you can see even on HN, there are less and less people able to appreciate their effort, even among programmers.

I’m curious why it matters to you. 55MB is a trivially inexpensive amount of storage and bandwidth in 2019. It simply doesn’t make a practical difference to the vast majority of people who will use this whether it’s 55MB or 5MB.

It is a hint that the code sucks.

Is it? I feel like it's a question of prioritizing. Why focus on application size when you could instead polish a feature?

Yes it is, if someone doesn't care about creating bloated applications they wont care about creating good applications either - which includes said polishing.

A lack of concern for "bloating" does not entail a lack of concern for user experience.

Optimizing for size may be less of a priority when a developer is focused on creating a positive user experience and adding useful features. Obsessive optimization of factors that users don't care about can lead to crappy applications — see quite a few open source GUI applications as an example.

Actually as far as I can tell, the github app only mimics part of explorer.exe, explorer.exe also is what makes up your taskbar

I'd suspect the executable size has more to do with bundled libraries rather than the author having written multiple megabytes worth of if statements...

Why so harsh?

This isn't production code published by Microsoft, it's an "enthusiast's take" written by a student learning to code. Most of my college colleagues couldn't make it through FizzBuzz.

Hopefully a bright new programmer doesn't get discouraged by getting smacked down in the top comment on hacker news.

Storage is actually pretty cheap. Only RAM usage matters now. So 55mb is not that much of a big deal now. But this is an attempt by the author. No one is forcing you to use this. I dont know whats the point of being so negative to someone's efforts.

I dont know whats the point of being so negative to someone's efforts.

The author is given a very clear indication that this is not a good direction, and hopefully changes direction quickly. He actually replied to another comment I made where I gave some advice (https://news.ycombinator.com/item?id=20130696), and said he continued working on it because of "overwhelmingly-positive community feedback", despite already being aware of the limitations of UWP. Maybe if he encountered a bunch of "UWP sucks, go Win32!" comments back then, he might've come up with something far more interesting and useful.

In other words, you can blame this idiotic "positivity culture" every time you see something half-assed, bloated, or just plain broken, or when huge mistakes are made because everyone was all smiles and happiness, and no one said NO until it was too late...

This is unnecessarily negative. I’d imagine all UWP apps are that big, and who knows how much explorer.exe functionality is in DLLs you’re not counting. The author can’t help it if modern frameworks are bloated crap.

I would like to take this opportunity to recommend that everyone who is into C#/.NET Core and high-performance Windows UX development take a look at the following: https://github.com/prasannavl/WinApi

I was able to get a workable demo app going in just a few minutes using their Win32 approach. Seems very promising to me for purposes of building native-levels of performance into windows apps using managed C#. The performance statistics published on the repository seem fantastical, but I can believe it now that I've played around with a few of their demos.

55MB is about as large as the entire Win95 OS install.

> a lot of code, a lot of resource consumption, some flashy "modern" UI, yet very little in the way of actual functionality.

Ah, The Perils of JavaSchools right there.

I agree with your comment. That code is beyond horrible, and it keeps on and on. Take a look at the other trending project on HN, Open Source Electronics Lab for $30. It has some nasty surprises on it's own, code-wise.

55MB sounds OK to me. At least it is much smaller than typical Electron apps. And the piece of code you show is completely unrelated to your point.

In all fairness, that code should be trivially optimized: your computer is almost certainly not running that check.

Huh? The function is a no-op. The compiler should optimize it into nothingness, but optimization is not the point here. Or was that an attempt at humor?

I don't know how much the C# compiler optimizes code, if it does at all, but I do know that the JIT compiler is smart enough to delete this. So I came up with an awkwardly-worded response that provided information that I knew to be true.

Yes, of course it is trivially optimized out, that's still not the issue. The question is why that function (and several others) exist in the first place! Is there a bug (which is then copypasted several times) and the code is actually supposed to flip between enabled and disabled (in which case it should really be written foo = !foo)? Or something else?

Probably a copy/paste bug that the author overlooked.

Which is precisely my point.

C# has assignment and mentioning overloading by aliasing to getters and setters. The setter may be holding a shared lock and this pattern may make it release.

If I read some code like that, I would expect a comment like:

  // silly hack to get the tab control into a good state.
  // it gets confused when ...
  // and this seems to fix it.

Because setting a property can be a function call, it isn’t necessarily a no-op to set a property to itself.

Having said that, the code is still quite bad but maybe it was auto generated by a ui builder or refactoring tool.