WinFile comes back from the dead.

Posted on by

WinFile!

Yes, this WinFile.  So Microsoft apparently went through their Windows NT 4.0 source code tree from 2007, and decided to pull this tool out, and send it out into the world.  It’s available in a ‘original’ version, and a ‘v10’ version which includes the following enhancements:

  1. OLE drag/drop support
  2. control characters (e.g., ctrl+C) map to current short cut (e.g., ctrl+c -> copy) instead of changing drives
  3. cut (ctrl+X) followed by paste (ctrl+V) translates into a file move as one would expect
  4. left and right arrows in the tree view expand and collapse folders like in the Explorer
  5. added context menus in both panes
  6. improved the means by which icons are displayed for files
  7. F12 runs notepad or notepad++ on the selected file
  8. moved the ini file location to %AppData%\Roaming\Microsoft\WinFile
  9. File.Search can include a date which limits the files returned to those after the date provided; the output is also sorted by the date instead of by the name
  10. File.Search includes an option as to whether to include sub-directories
  11. ctrl+K starts a command shell (ConEmu if installed) in the current directory; shfit+ctrl+K starts an elevated command shell (cmd.exe only)
  12. File.Goto (ctrl+G) enables one to type a few words of a path and get a list of directories; selecting one changes to that directory. Only drive c: is indexed.
  13. UI shows reparse points (e.g., Junction points) as such
  14. added simple forward / back navigation (probably needs to be improved)
  15. View command has a new option to sort by date forward (oldest on top); normal date sorting is newest on top

Which is quite the list of things to add to the old WinFile.

You can find the source & binaries on github.

8 thoughts on “WinFile comes back from the dead.”

          • I think this thread is seriously underestimating the work involved. It’s doable (it’s just work), but there’s quite a bit of it.

            1. This source is from the NT version of Winfile. Getting it to run on Win9x involves removing security support and compiling it for ANSI (8 bit chars.) This build is currently broken.
            2. Getting it to run on Windows 3.1 with Win32s requires removing all the CreateThread calls and replacing them with messages. I’m unclear on exactly why these were ever here; obviously the 16 bit version didn’t have them.
            3. Getting it to run on Windows 3.0 means replacing all of the file management parts (which use a Win32 API) with their corresponding DOS APIs. It probably also means dealing with the bonkers 16:16 memory model. Things like ExtractIcon don’t exist there, so expect some manual parsing of executables to find their icons.
            4. Getting it to run on Windows 2.0 would involve a lot of refactoring. I’ve seen MDI done on 2.0 (Word and Excel both did it) but it’s not a platform feature so there’d be a lot of reimplementing. Also, note the File Manager displays text with icons, but 2.0 doesn’t support owner draw controls (ever wonder why MS-DOS Executive didn’t do this?) Again, this can be reimplemented by owning the whole thing and using GDI, but that means reimplementing a list box from scratch. I suspect that a lot of control functionality that winfile has implicitly been using would be found to be missing in trying to do this; one way to think about WinFile is it was released with 3.0 as an app demonstrating all of the new capabilities and UI paradigms of 3.0.

            Honestly I’m not expecting much of this to happen unless new people really step up for it. If I had to guess, (1) will happen but even (2) is currently looking unlikely. I know there are not well informed opinions on the internet (but Windows was ancient and didn’t have all the stuff you need!) but in this case there’s a lot of truth to it. The further back you go, random things just don’t exist and need to be redone. It’s not going to be a recompile.

          • Oh, one other thing…going back to true 16-bit means writing a toolbar from scratch. Win32s 1.30 provides the Win95 one (which the code currently uses), and NT 3.x has a different/older one that the code could use, but I don’t see anything in the MSVC 1.5 headers for this.

            (In all seriousness, it’s amazing how much Win 3.x was a smoke and mirror show where applications coded sophisticated functionality outside of the platform. Although it gave the appearance of being capable, it was the apps themselves doing all the work. Win95 cleaned a lot of this up – the custom 2-D icon canvas in Program Manager became ListView, the tree in File Manager became TreeView, the various toolbars became a control, status bars became standardized, etc. Trying to write for Win 3.x involves reinventing a lot of wheels.)

Leave a Reply