Slashdot Mirror


Microsoft Open-Sources Original File Manager From the 1990s So It Can Run On Windows 10 (theverge.com)

An anonymous reader quotes a report from The Verge: Microsoft is releasing the source code for its original Windows File Manager from nearly 28 years ago. Originally released for Windows 3.0, the File Manager was a replacement for managing files through MS-DOS, and allowed Windows users to copy, move, delete, and search for files. While it's a relic from the past, you can still compile the source code Microsoft has released and run the app on Windows 10 today. The source code is available on GitHub, and is maintained by Microsoft veteran Craig Wittenberg under the MIT license. Wittenberg copied the File Manager code from Windows NT 4 back in 2007, and has been maintaining it before open sourcing it recently. It's a testament to the backward compatibility of Windows itself, especially that this was originally included in Windows more than 20 years ago.

37 of 173 comments (clear)

  1. Midi Manager by Atomic+Fro · · Score: 2

    How about open sourcing the Midi Manager so we can run that on Windows 10.
    I like my old games with MIDI music to use my hardware, not your awful software implementation.

    --

    ==================
    Hippie Logger Jock
    ==================
    1. Re:Midi Manager by pmsr · · Score: 2

      Just use Coolsoft Midimapper: https://coolsoft.altervista.or...

    2. Re:Midi Manager by UnknownSoldier · · Score: 2

      Sadly, MS doesn't care about musicians anymore. :-/ When was the last time you actually heard them talk about kernel latency? MS has embraced mediocrity for so long that they wouldn't know the first thing about inspiring greatness. Hell they STILL don't understand UI's -- they just copy the lastest fad of the decade.

      While all the cool kids are using DAWs (Digital Audio Workstation) and VSTs (Virtual Instrument) it seems like most of the creative types migrated over to the OSX. Apple _used_ to care with its Jam Packs. At least they still ship GarageBand (last time I checked) but it seems like no one cares about having a fully digital learn-to-play tutorial.

      Harmonics _completely_ squandered their opportunity with RockBand and they were even designing / selling their own hardware. If they can't even recognize the need, and instead half-ass it, I don't expect anyone else will either.

      MIDI has been a forgotten step child -- which sucks.

      Time to buy those old MIDI devices off eBay while we still can.

    3. Re:Midi Manager by AmiMoJo · · Score: 2

      Actually Microsoft mostly fixed kernel latency with Vista, when they introduced WASAPI. The system was further improved with every iteration, and Windows 10 is actually pretty good.

      https://docs.microsoft.com/en-...

      0ms latency for all applications, even using the mixer.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  2. Longevity of code/interface by david.emery · · Score: 3, Insightful

    It's a testament to the backward compatibility of Windows itself, especially that this was originally included in Windows more than 20 years ago.

    Gee, that would date this code to about the same time we were doing the POSIX standards that codified a (then) 20 year old Unix interface.

    1. Re:Longevity of code/interface by bill_mcgonigle · · Score: 3, Insightful

      Well, most of the files have the commit message "Original WinFile sources plus changes to build with VS" so it's not exactly source-compatible. The API might be but that's also how we get DDE & OLE vulnerabilities in modern code, etc. There are trade-offs.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    2. Re:Longevity of code/interface by darkain · · Score: 2

      Serious question: how many 16-bit applications do you know run natively on 64-bit hardware? If you read the notes, that is the majority of the changes. The other major change was statically linking against a particular DLL file (again, another 16-bit binary), and updating to current APIs. The vast majority of the code otherwise still works. Also as a note: WinFile predates OLE, and is actually something that has been added to the upgraded version in this code base too!

    3. Re:Longevity of code/interface by DamnOregonian · · Score: 4, Interesting
      The fucking fuck?

      There is an obscene amount of POSIX compliant code that breaks without 64-bit specific fixes. I know because I have to fix it at work.

      And don't get me started on DLL - possibly the worst design decision in all of Windows (and that's saying a lot!), particularly given how DLLs proved to be a massive attack vector on Windows systems.

      Yes, dynamic libraries were such a bad idea.
      Increased attack surface? ya, youbetcha. Trade-off? You try running 150 processes on a machine with full software stacks without sharing memory pages, and let me know how that works for you. I've done my share of hackery with linux shared objects too. There was always a trade-off in them, and Microsoft neither invented that tradeoff, or had a worse implementation of it than anyone else. They're simply the most visible.

    4. Re:Longevity of code/interface by jeremyp · · Score: 2

      Yes those pesky DLLs with their shared object code.... ... You do realise that the exact same concept exists on all all modern Unix-alikes including Linux, only they are called shared object libraries.

      Also I wouldn't bet against there being many early 90's era Posix apps that do not compile cleanly for 64 bit. For a start,, any app that assumes ints and pointers are the same size - and there were a lot - is completely broken under LP64.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    5. Re:Longevity of code/interface by TheRaven64 · · Score: 2

      Command-line stuff? Sure. Graphical stuff? Not so much. The core X11 protocol is the same, but a bunch of early X applications used X extensions that are no longer working well (or supported at all) on modern X systems. And that's assuming a statically-linked binary. Getting hold of early versions of KDE libraries is painful. Motif programs may work with an updated library, but copy and paste are now done differently by FD.o apps so don't expect copy and paste or drag and drop to work (you might have working middle-button paste of plain text, but nothing structured).

      --
      I am TheRaven on Soylent News
  3. Re:not in apples sandbox! by Lunix+Nutcase · · Score: 2

    and soon mac os will be just as locked down.

    Uh huh. We’ve been hearing this for nearly 10 years now. Every year it’s “soon” to happen and yet fails to happen.

  4. Why bother? by jellomizer · · Score: 2

    This seems more like Microsoft tossing bread to the Open Source community, appearing to be generous, while they are just interested in watching the infighting for the scraps.

    The File Manager is something that is relatively easy to make yourself, especially from such an old version. If they were to release the one they are using currently, that may mean a bit more. Just as it has a lot more features that may take a while to catalog and implement yourself.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    1. Re:Why bother? by AbRASiON · · Score: 2

      Do we absoloutely have to always hate Microsoft here?

      This is very obviously them doing something 'fun'
      At least they aren't google, far, far more evil nowadays.

  5. A Winfile fetish? by DarkOx · · Score: 2

    Really?

    I mean there has to be a bazillion alternative file manages for Windows out there if you don't like Explorer for some reason and power shell and or good old cmd.exe/command.com + xcopy, deltree and friends won't cut it for you.

    Even back in 1993 - winfile was something people without a copy of Norton Desktop used; in other words poor people, and folks with no common sense.

    --
    Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
  6. Re:Not a big deal by Anonymous Coward · · Score: 3, Insightful

    Microsoft's Windows file manager was crap enough when it was current that I paid for a third-party alternative.

    The things it has going for it over today's file manager include:
    - only focused elements are highlighted (can't count how many times I've deleted the wrong files because of focus being somewhere other than where it appeared to be -- files A was highlighted but Windows was actually focused on file B; I tapped Del to delete A but Windows deleted B)
    - show file extensions (not even an option to hide them! what feckwit has left "hide extensions" the default for so many years?)
    - distinguishable UI elements: buttons are clearly buttons, scroll bars are always visible, etc.
    - overall not-flat UI

  7. Still not better than Norton Commander by bigmacx · · Score: 5, Informative

    ...THE reference file management tool for PC geeks

    https://en.wikipedia.org/wiki/Norton_Commander

    I still use Midnight Commander on Linux from time to time, especially for quick side-by-side file/dir moves (the viewing of diff's between them is nice) and searching for content inside lots of files

    https://en.wikipedia.org/wiki/Midnight_Commander

    1. Re:Still not better than Norton Commander by thelexx · · Score: 3, Insightful

      Preach it brother. Midnight Commander is the best. Thunar and the like are pretty, but work gets done with mc.

      --
      "Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999
    2. Re:Still not better than Norton Commander by Anonymous Coward · · Score: 4, Informative

      XTree Gold was much better

    3. Re:Still not better than Norton Commander by fat_mike · · Score: 2

      If I had Mod points I'd give them to you. I can't remember what I had for lunch yesterday but totally remember Commander and how fast it was with the shortcut and arrow keys once you remembered them.

    4. Re:Still not better than Norton Commander by bigmacx · · Score: 2

      LOL, figures an AC would bring the Xtree reference. Xtree was good, but just plain ugly looking compared to NC. I used both as needed, but NC was my go-to tool in the road warrior floppy toolbox

    5. Re:Still not better than Norton Commander by bigmacx · · Score: 2

      LOL@ all the low-numbered reply'ers to this post. We're soo old. Gonna be a real riot around the floor shuffleboard in a few years...

      "I remember when there was a real chance of getting electrocuted by just touching a computer's front-panel power switch!!!"

  8. Re:OLE? by MightyYar · · Score: 2

    Pasting editable spreadsheets into Word/Powerpoint was always pretty handy, if quirky.

    --
    W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
  9. Re:Port to iOS please by jenningsthecat · · Score: 4, Insightful

    Please!!!

    I wish they'd release the source for the file manager that came with Win98 and Win2K, and I wish somebody would port it to Linux. The only decent Linux file manager I've found is Dolphin, and its deps are pretty much all of KDE core, which is huge - especially when compared with the XFCE environment I'd be using it in. I want a file manager with an integrated search function that will actually search inside files for a specified text string. Right now I use the Gnome search tool. It isn't integrated into the file manager, it's buggy, and its UI sucks, but it's the best available, short of installing the bloated and bling-laden KDE. Pretty much the only thing I miss about Windows is the File Manager. Well, except for the fact that Windows applications use File Manager for their load and save functions, which makes the interface much more consistent from one application to the next. Having a mix of GTK2, GTK3, and program-specific file dialogs like those in Libre Office, is just sucky.

    --
    'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
  10. Explorer still can't do what DOS did: by fredrated · · Score: 2

    print a list of files in a directory, like Dir>PRN.

    1. Re:Explorer still can't do what DOS did: by thegarbz · · Score: 2

      Can't you just email a screenshot of explorer into the cloud and have it automagically appear on the printer right next to you as determined by the ever watchful eye of Facebook knowing where you are at any given moment?

  11. Re:Port to iOS please by LinuxIsGarbage · · Score: 3, Insightful

    Pretty much the only thing I miss about Windows is the File Manager.

    I really don't think it's that great.Then again I usually have to struggle to keep it as "details", no thumbnails, no metadata, show extensions, shows hidden files, please don't hang when I right click a file and it loads who knows how many extra handlers.

    Well, except for the fact that Windows applications use File Manager for their load and save functions, which makes the interface much more consistent from one application to the next. Having a mix of GTK2, GTK3, and program-specific file dialogs like those in Libre Office, is just sucky.

    One downside is it's a little too rich for its own good. I remember back in the day under poor attempts to lock down a machine by hiding explorer, "run" from start menu, my computer, etc could be circumvented by opening the open window of an allowable application, and navigating to cmd.exe/command.com.

    One upside is in WinPE / WinRE that doesn't have access to a file manager, you can open notepad from the cmd window, open the open dialog, and get a bare bones explorer window for basic file management.

  12. Re:Port to iOS please by rogoshen1 · · Score: 4, Insightful

    i never understood why windows defaults to "hide extensions for known file types" -- in what god damn universe is that a GOOD idea?

  13. ReactOS by rnmartinez · · Score: 2

    I am not a dev but always interested in the stuff that goes on here. Could this be of any benefit to the ReactOS team?

  14. Re:Port to iOS please by klashn · · Score: 3, Informative

    In a universe where the 99% ruin it for the 1%. Hide file extensions for 99% of people that don't need them, let the 1% un-check the box.

  15. Why Windows hides file extensions by steveha · · Score: 3, Informative

    i never understood why windows defaults to "hide extensions for known file types"

    I agree it was never a good idea. IMHO it was done because the file extensions are ugly.

    On the Mac, every file has a "resource fork" (I guess on OS X it's no longer properly a "resource fork" but there is something equivalent) and the type of the file is coded in a spot that the OS knows how to read but which the user doesn't see. So the user types any name, and the icon is the right icon and the user just sees the icon and the chosen name.

    On Windows and Linux, the file systems don't have this "resource fork" idea, so the obvious place to encode the type of file is the extension. But the extension is user-visible.

    Linux uses the techniques pioneered in UNIX to just identify a file no matter what its name is. If it's an ELF binary, it will start with certain bytes arranged a certain way; if it's a LibreOffice document, it will start with different bytes, etc. It's trickier but more reliable: you can rename a LibreOffice document to not have its extension any more, and your file manager can still do the right thing when you double-click on it.

    But Windows just uses the extension.

    Well, hiding the extension makes Windows more like the Mac. The icon is correct, the user just sees the filename chosen by the user, life is great.

    But users are used to seeing extensions and don't worry about them much. And there was a form of attack where a Trojan Horse file would have a name like "Important Document.doc.exe" and hope the user would open it. If Windows hides the extension, then just the ".exe" part is hidden, and the user just sees "Important Document.doc" (and as I said the user is used to seeing extensions and doesn't freak out that most documents have no visible extension but this one does).

    These days, by default, Windows hides "system" directories and anything else that an uninformed user shouldn't touch. If I have to use Windows, I make sure to turn on seeing file extensions, disable hiding system directories, etc.

    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely
    1. Re:Why Windows hides file extensions by slashdice · · Score: 2

      OS X has deprecated resource forks in favor of bundles. A bundle is just a folder with a bunch of files in it (one of them is a property list that says what the bundle is). In a sense, it's a resource fork exploded into individual files.

      Finder has custom logic to display bundles so they don't look or act like folders (you can still open them as a folder but it takes an extra click);

      --
      Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
    2. Re:Why Windows hides file extensions by DamnOregonian · · Score: 3, Interesting

      On Windows and Linux, the file systems don't have this "resource fork" idea

      Funny enough, NTFS has supported the idea since inception. But extensions weren't broke, so weren't fixed. And not to mention would have been sucky for any software relying on file extensions.

      Also funny, OSX now does it by hiding extensions and interpreting the metadata inside of a folder.

    3. Re:Why Windows hides file extensions by Bert64 · · Score: 2

      NTFS does, but the ui from windows was carried over from the dos days so most user visible software is written to use file extensions and will rarely if ever use the alternate data streams for anything. I've only ever seen streams being used by malware as a way to hide.

      OSX went the other way, because they moved from their custom kernel to a unix-based system, where unix filesystems (osx originally supported UFS) don't have a concept of resource forks.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    4. Re:Why Windows hides file extensions by TheRaven64 · · Score: 2
      This is not quite true. On FAT, files had an 8-byte name and a 3-byte type. These were separate fields (though you could have two files with the same name but different types). They were exposed in the command line using a dot as a separator, so you could access the type easily. FAT also included a few other fields, such as a system flag and an archive flag (set when the file was modified so that it could be backed up incrementally).

      On HFS, files had two 4-byte types, one to identify the underlying type and one to identify the preferred app for opening the file. On *NIX filesystems there was no type and so the type was encoded in the name, using a dot as a separator (dot is a valid character in the name, so this also allowed things like .tar.gz).

      *NIX filesystems and NTFS now also include extended attributes, which allow you to store arbitrary bits of metadata relating to a file, most commonly used for ACLs or per-file encryption / compression. Unfortunately, interoperability has meant that everyone converges on the lowest common denominator and so stores file types as part of the name.

      Oh, and before you extoll the virtues of libmagic, I suggest that you look at its CVE list. It's always fun when simply viewing a file in a file browser can compromise your system, without even having to open it...

      --
      I am TheRaven on Soylent News
  16. "run the app" by hcs_$reboot · · Score: 2

    "compile the source code and run the app" is where we know the article was written by a non-programmer.

    --
    Slashdot, fix the reply notifications... You won't get away with it...
  17. Re:Port to iOS please by Eravnrekaree · · Score: 2

    What really irritates me is that Linux filemanagers cant figure out that right click and dragging and icon is supposed to pop up a context menu when it is dropped on the destination to select if you want to copy or move. Many file managers wont even ask at all. Very annoying behaviour.

  18. Re: Port to iOS please by Bert64 · · Score: 4, Insightful

    Pre-OSX MacOS didn't use file extensions at all... The filesystem used a separate metadata fork to determine file type, and wasn't reliant on something as arbitrary as the file name.

    For a system which depends upon and makes decisions based upon the file extension, hiding them is stupid, and for a system that makes no use of the file extensions hiding them (if even present at all) is irrelevant.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!