Live data from Hacker News

Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

github.com

81–90 of 187 posts

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#81

It's funny to see the gradient in the title bar, contrasting with the bland borderless-sea-of-whiteness of the rest of the UI. > FilesUwp.Package_0.5.0.0_x64.zip 54.4 MB Nearly 55MB, compressed , for something that attempts to mimic some of the functionality of the regular explorer.exe, is quite frankly ridiculous. I don't have a system to check right now, but I believe even latest Windows 10 has an explorer.exe http…

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

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#82
post #29

Earlier quoted context omitted.

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 i…

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.

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#83

It's funny to see the gradient in the title bar, contrasting with the bland borderless-sea-of-whiteness of the rest of the UI. > FilesUwp.Package_0.5.0.0_x64.zip 54.4 MB Nearly 55MB, compressed , for something that attempts to mimic some of the functionality of the regular explorer.exe, is quite frankly ridiculous. I don't have a system to check right now, but I believe even latest Windows 10 has an explorer.exe http…

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.

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

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#84
post #24

Earlier quoted context omitted.

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

But..but..RICH UI!!

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#85
post #75

Earlier quoted context omitted.

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.

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#86
post #24

Earlier quoted context omitted.

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

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.

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#87

It's funny to see the gradient in the title bar, contrasting with the bland borderless-sea-of-whiteness of the rest of the UI. > FilesUwp.Package_0.5.0.0_x64.zip 54.4 MB Nearly 55MB, compressed , for something that attempts to mimic some of the functionality of the regular explorer.exe, is quite frankly ridiculous. I don't have a system to check right now, but I believe even latest Windows 10 has an explorer.exe http…

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.

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#88
post #35
post #24

Earlier quoted context omitted.

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

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 IrfanVie…

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

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#89
post #60

Earlier quoted context omitted.

First of all, most files are nowhere near 10 levels deep, let alone hundreds of levels. Second, we don't have to do a naive update every single time a file is changed. We can amortize the cost by updating the parent folder sizes only when the file size is changed by a significant amount since last update (say, 10%). And we can do this process recursively is the parent directories. This was it only takes O(1) time to…

> most files are nowhere near 10 levels deep, let alone hundreds of levels. Filesystem (and low-level in general) stuff must consider worst cases. There is a lot of software out there doing weird things. For instance, npm created a very deep folder hierarchy for a long time (so deep it messed up some path length restrictions in fact). One way or another the worst case is going to be hit. And then what? The entire com…

> So you have a log file inside a folder. Because it just keeps growing line by line then the folder's size is never updated. Now you have many Gb's of log file in that folder, and the folder says it is using "4Kbytes".

You misunderstood what I meant. I didn't mean we should only update if a single change is significant. I meant we only update when the cumulative changes since last update is significant. An example:

Let's say we create a 1mb file. The next time the file is changed, we only update the parent if the change is more than 10% (the new size is greater than 1.1mb or less than 0.9mb). For example if it is a log file and each line is 100 bytes, we update the parent after 1000 new lines (even though the 1000th line is still only 100 bytes). (of course the number of lines before the update depends on the size of the file, so if we had a 1GB log file, we would update after 1000000 new lines).

It is trivial to prove that the estimate is never off by a factor of more than 10% (even for the parent folders). So this is not a "half-assed broken-by-design feature" since it provides strong guarantees in bounds and at least in my personal day-to-day usage, I almost never care about the exact size of a folder but want to have a rough idea of how large it is.

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#90
post #80
post #28

Earlier quoted context omitted.

As awesome as the Win2k source leak probably is from an educational standpoint, I don’t want to taint myself with illegal source code. I hope they eventually decide to open source more things, even if it was just older things.

Taint yourself with illegal source code? What does that even mean?

It means that if you read the Win2k source code, any code you write could well be challenged as a copyright infringement.
Post reply on HN