Windows File Manager re-released | Hacker News Reader

Windows File Manager re-released

github.com

97 pointsriboflavin48 comments

Before object oriented programming, before threading, GUI applications were massive co-operative multitasking C switches:

https://github.com/microsoft/winfile/blob/master/src/winfile...

Found a C "goto" in that code, too - eek. Maybe there was a good reason...

There's nothing wrong with goto in C.

It's a good pattern to DRY-up resource-releasing unwind code. In an ideal world, there would be closures, RAII and fluent interfaces (macros) that would wrap allocation, deallocation, error and success handling without needing C++ and avoiding resource leaks.

    int
    some_func(void) {
      int result = ERR;

      HANDLE foo = alloc_foo();
      if (!foo) goto err0;

      HANDLE bar = alloc_bar();
      if (!bar) goto err1;

      if (do_something_else() < 0) goto err2;

      result = OK;
    err2:
      release_bar(bar);
    err1
      release_foo(foo);
    err0:
      return result;
    }

As with everything in C, it must be used with care and thought. It can come back and bite you in the future if use frivolously.

Nothing wrong with using goto, sparingly. It's the preferred way for error handling in C.

Nobody has code like this anymore

    10 I=1
    20 PRINT "HELLO "
    40 PRINT %I
    50 IF (%I > 3) 10 40
    30 PRINTLN "WORLD"
    45 PRINTLN
    42 I=%I+1

Notice no goto statement, yet lots of implicit gotos.

What about a Goto within a switch statement that's within another switch statement in a function that's 3000 lines long?

I mean, as far as I know, most would still implement this the same way.

Surely there could be a GUI framework that'll handle these Win32 Messages and dispatch them to your callbacks in your `Application` object but your application could be dealing with all sorts of messages not covered by your framework like WM_SYSCOMMAND, WM_POWERBROADCAST, WM_DEVICECHANGE, etc. and you'll find yourself with this classic Win32 Message Queue handling switch even in modern C/C++ Win32 GUI codebases.

Whenever you are interfacing with the Win32 API directly to set up and run a GUI application, this pattern will emerge: https://gist.github.com/nathan-osman/18c2e227ad00a223b61c0b3...

I set up Windows 98 on an old Pentium III for vintage gaming. I had forgotten how simple, fast and "you have one job" this is. Definite install on my Windows 10 machines.

OK, trying not to over-react here, but the OLD Ctrl+F FILE SEARCH WORKS, and it's frickin' fast.

It doesn't do fuzzy matching (PR, anyone?) but Goto Directory (Ctrl + G) is also great and instantaneous.

Only drive C: is indexed, though.

Voidtools Everything is going to remain my Windows search tool for now.

Tried "Everything"?

> Tried "Everything"?

Yes, that's what I said I use.

My bad, I read your program as 'Voidtools' and didn't realise we are talking about the same thing.

I like it. It feels so simple and straightforward.

It's so fast, easily the most responsive GUI on my PC. Far easier navigation than modern explorer too.

Can we go back to this in get rid of all this "modern" multi threaded, hardware accelerated crap?

Multi-threaded is usually good.

Hardware acceleration is usually good.

I'm not sure why you think modern software is slow, but it is definitely not those two things, unless they are implemented EXTREMELY naively, which is far, far less common than one would think.

> I'm not sure why you think modern software is slow, but it is definitely not those two things

I think modern software is slow because it's slow (despite having vastly more powerful computers), those 2 things along with the language apps written in are the major technical differences between old software and modern software. If theory doesn't match reality then the theory must be wrong.

This app starts is more responsive than my windows start menu.

Yes, the application starts very quickly and feels instant (which is how ALL software should be, dammit.)

I GUARANTEE you that any lack of multi-threading or hardware acceleration is not the cause for the speed, but rather the simplicity of the application. It's as complex as it needs to be to perform its job, and not more.

Today's unfortunate software development practices stack layer upon layer of abstraction on top of the CPU; far more than was the case when this application was written. As such, more modern applications are bogged down with the weight of all of this stuff.

Developers today have forgotten that "mo' code means mo' problems" and are quite happy to reference any stupid library they come across in order to make things feel simpler. What they've actually done is make things far more complex, and complexity is the undying, always victorious, enemy of performance.

I don't like that modern applications are slow, either. They aren't slow because of multi-threading and hardware acceleration, I promise. They're slow because of piles of stupid decisions on how software should be built.

No. Multi-threading and hardware acceleration is objectively faster for many workloads. The problem is over-engineered, one-size-fits-all solutions, especially multiplatform and/or written in Javascript.

Back in the day, we had built-from-scratch programs that could only do exactly what they were intended to do on a specific platform, instead of doing things like shipping a gamepad driver with your all your text apps[0].

[0] https://josephg.com/blog/electron-is-flash-for-the-desktop/

And if you want the neat, small calc.exe back, I used this: https://winaero.com/blog/get-calculator-from-windows-8-and-w...

> F12 runs notepad or notepad++ on the selected file

Did Microsoft accidentally admit that MS notepad is worthless?

What a throwback! I'll still keep using Total Commander (ex. Windows Commander) since the first day I had a PC.

But no Space Cadet pinball.

https://devblogs.microsoft.com/oldnewthing/20181221-00/?p=10...

Third parties may have your back.

Oh, this is so quick.

Port to OSX?

Works with Wine, I'd like a port to Linux Arm64 though, it's a nice graphic file manager. On the other hand, ranger is adequate.

Ranger is by far the most useful file manager I have ever used. It's quick and powerful. The only thing that keeps it in the minor leagues is how big the learning curve is for anyone that doesn't know Vim shortcuts.

Love the triple pane.

I'd argue such a file manager is meant for people who prefer and are used to Vim shortcuts. I just tried Ranger. Got image preview and Solarized theme working, but it does hang on previews it seems.

For a GUI one, I can recommend fman (fman.io) as it uses the Sublime paradigm (shortcuts plus a command palette). It isn't FOSS though.

Also worth mentioning nnn, fff, and filet. All Ranger-inspired file managers that are faster and more lightweight (listed in order of ascending speed).

Far easier said than done, I'm sure.

This is an old-school Windows app with a Win32 message loop and using the raw Win32 interfaces for drawing.

Sounds like a challenge. I think the most interesting way to do it would be to re-implement enough of the Win32 API in OS X to make it run.

Unfortunately you'd get something that looks much more like a Mac app but maybe that would be a good thing.

> I think the most interesting way to do it would be to re-implement enough of the Win32 API in OS X to make it run.

Well, that pretty much describes Wine, and it does work in Wine on macOS. (I know, that's kind of boring, though...)

I would hope it wouldn't require implementing the entire Win32 API! :)

Wait what...ok...cool...but...why?

No ribbon.

No special folders, so you always know exactly where you are on disk.

Actual buttons, instead of the flat theme.

Windows explorer has gotten a little bit "magical" for my taste. There are all these different kinds of special system folders that invoke different view logic somehow. Sometimes you just want to see the actual file system.

Well, that's because Explorer doesn't navigate the file system, but the shell namespace.

I have never heard of that. I mean, I don't doubt it's true, but I think I just want to see the files usually. But then again, I don't know what that means.

As a simple example, you can explore into a zip file as if it were a file system folder. This is really useful, but you're obviously no longer dealing with just plain old file system paths.

Also things like "My Computer", the recycle bin, the network, phones connected via MTP, etc. It's basically something the actual file system is only a part of, and yes, some file system locations are hidden, some are merged, some are redirected, etc.

Maybe it's for people annoyed at Explorer taking upwards of 30 seconds to display folders with lots of files in them.

I have a single folder (no subfolders) with 650,000 files in it, and the Win10 explorer is plenty fast if nothing in that folder is currently changing. Even if a single file access time changes it will spend 20-30 minutes trying to display the change, despite the access time not being displayed for any file.

If you open the folder 1 second after the file access time is updated, it's instantaneous, as before.

There's good and bad here. NTFS is a HELL of a lot better at handling stupid amounts of files in a folder like this than it used to be. But maybe it could handle a single file attribute change without losing its kind for 30 minutes.

Maybe the problem is storing so many files all in one directory? /me ducks

NTFS with default settings will actually degrade a fair bit on such a folder. You probably have to disable 8.3 legacy filename generation to make this work (or the usual pattern of using the file name prefix as folder names beneath that folder).

Reply on news.ycombinator.com