Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by BeauHD on from the blast-from-the-past dept.

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.

173 comments

  1. Port to iOS please by Anonymous Coward · · Score: 0

    Please!!!

    1. 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.
    2. Re: Port to iOS please by Anonymous Coward · · Score: 0

      30 year old code full of bugs, no.

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

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

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

    6. Re: Port to iOS please by Anonymous Coward · · Score: 0

      To copy the mac system that doesn't show file extensions just icons

    7. Re:Port to iOS please by Anonymous Coward · · Score: 0

      rox-filer

      Btw, "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." is obviously not true. Yes, there is a common Open and Save As dialog that's used in 99% of programs, but it's not "File manager". The Open and Save As dialogs themselves have a bunch of quirks (unmaxizamizable/unminimizable, sometimes hidden from quick switch, usually modal, they've changed a lot between different Windows releases, and they honestly quite suck when it comes to actual file management). I'd say Windows 98 is about the point that we saw Explorer reach about thebest state--show/hide tree and a client area that tried to maximize files display. An ability to have something like Dolphin instead of a multi-window approach would be preferred, but that'd require fixing their modal design.

      The one thing I'd agree with is it'd be a large improvement if there was consistent open/save as dialogs. Thankfully GTK/QT have gotten to be pretty close in design and it's possible to use the same theme (Clean-Phoenix, among others) to have very consistent client themeing if you so desire. I admit it's not perfect, but that's 99% the fault of individual developers, just like in Windows land. Libre Office in Windows is also sucky. So is MS Office, for that matter.

    8. Re:Port to iOS please by hcs_$reboot · · Score: 1

      grep -r search *

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    9. Re:Port to iOS please by Anonymous Coward · · Score: 0

      Why it broken... You cannot create files file con or lpt in the start of the name. Blocked becuase of work done in DOS2. 35+ years later you still cannot use those names try it.

    10. Re:Port to iOS please by EETech1 · · Score: 1

      I always figured it was a cheap and dirty hack to keep people from accidentally deleting the extension.

      Prevents the:
      Copy
      Paste
      Rename
      WTF did it go?

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

    12. 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!
    13. Re: Port to iOS please by TrumpThemAll · · Score: 0

      I remember the crappy os 9 file system. I had a program that shipped its manual as html and the damn is refused to open them in a browser. It's fucking html you stupid machine! I also never understood why they decided to hide the extensions in windows. It just made it easy to pass viruses around by naming it picture. Jpg.Exe. Windows hides the. Exe, so it looks like a jpg at a glance. Now that I think about it, most of the crappy ideas I windows came from copying the Mac.

    14. Re:Port to iOS please by Anonymous Coward · · Score: 0

      But it doesn't even work for the 99% of illiterate users. All it has ever done is make misdirection work by allowing malicious actors to hide the extension.

    15. Re:Port to iOS please by Anonymous Coward · · Score: 0

      In a universe where 99% click on boobies.fu2 not realizing that it has a .exe extension and assume that .fu2 is an unknown extension. (Which it is.) I guess 8x3 saves you because you only need to add 900 or so unknown extensions to the list of known extensions?

    16. Re:Port to iOS please by jenningsthecat · · Score: 1

      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.

      Interesting! I never even used that functionality in Windows Explorer - didn't know it existed. But now that you mention it I think I HAVE seen it a few times, accidentally. I guess by the time I noticed I'd been stuck in my accustomed workflow for long enough that it never even occurred to me to use it.

      Not directly on the topic of file managers, but closely tied to it, is the whole mimetypes / file extension / "Open With" ugly mess that makes Linux desktop environments such a PITA to use. Plain text files, (for example), may need to be openable by several different types of applications. Back before KiCad changed its file structure, its PCB and schematic files were plain text. But they had their own extensions, and in Windows it was easy to just assign a program for a particular extension. In Windows, I could open KiCad files in a text editor, and often did - but I had it set up so that a double-click opened them in KiCad. Not so easy in Linux, where the concept of a filetype independent of extension is pretty rigidly enforced. If I set dot-pcb or dot-sch files to open in KiCad by default, then dot-txt files also open in it. I've also run into the problem with other file types,.I suppose it's possible to get around that in Linux, but in many hours of trying I never managed to get it to work. Those rules also seem to be handled in multiple places, and they interfere with each other. I've given up and learned to accept it, but it still pisses me off sometimes that Windows Explorer was far more seamless and consistent 20 years ago than any Linux DE / file manager combo is today.

      --
      'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
    17. Re:Port to iOS please by Anonymous Coward · · Score: 0

      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.

      That is the sorriest silliest attempt at securing anything I have heard of in a long time. (GPOs as a ssecurity measure is another).

      Secure a computer? Demand login credentials, and the ordinary user get no privilege to mess with system sw - even if they know how to start up a command shell.

      Oh, you can't do that on windows - so don't use windows then, if security seems useful. For 'tricks' that 99% of users don't know, are all very well known among the lowest of script kiddies. And all virus writers know how to exploit such things too.

    18. Re: Port to iOS please by Anonymous Coward · · Score: 0

      Open/Save As dialogs have the same look and feel as Explorer, use the same icons, same layout, provides the same context menus and actions, and uses the same user settings for each folder as Explorer does, and is provided by the Explorer libraries. If it looks like a duck, walks like a duck, quacks like a duck, and a duck is its mother, I'd say it's a fucking duck.

    19. Re:Port to iOS please by Anonymous Coward · · Score: 0

      In a universe where they don't care about YOU!

    20. Re:Port to iOS please by Anonymous Coward · · Score: 0

      I agree on the consumer version. Just annoying on a server OS.

    21. Re:Port to iOS please by Lord+Bitman · · Score: 1

      All it has ever done is make misdirection work by allowing malicious actors to hide the extension.

      The extension is *definitely* not the problem there.

      Having the exact same action ("double click") perform two entirely distinct functions:

        1. View a file
        2. Execute a program with all of the permissions of the current user

      is the issue. In what universe is *that* a good idea?

      --
      -- 'The' Lord and Master Bitman On High, Master Of All
    22. Re:Port to iOS please by Anonymous Coward · · Score: 0

      Compile it yourself and you wont have as many deps.

    23. Re:Port to iOS please by cyberchondriac · · Score: 1

      This, times 1,000!
      Do file extensions actually confuse users? No, that's ridiculous. Even computer illiterate users? Still no, they either ignore, or treat them as part of the file name like everyone else. It just seems condescending, really.
      Do they help identify the file type, useful if you're searching for a particular file? Duh. (Unless there's some malware or something going on) Does lack of showing file extensions cause confusion to average Windows users? I think so; at least, all the data entry personnel where I work, for the most part they think of computers as word processors, calculators, and Facebook machines. They want a file restored but can't tell me the extension because it's hidden, and there are four or more files with the "name" they gave me. Access databases were great for that.
      It is probably the most stupid thing MS insists on doing, it unnecessarily dumbs down their users, and the first thing I disable on any workstation I use. Or come across. I've never had anyone complain.

      --

      Look back up at my post, now look back down, you're on the Internet. Now look back up. I'm a signature.
    24. Re:Port to iOS please by Anonymous Coward · · Score: 0

      So Linux is sucky and Windows is great....got it.

  2. not in apples sandbox! by Joe_Dragon · · Score: 1

    not in apples sandbox! and soon mac os will be just as locked down.

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

    2. Re:not in apples sandbox! by Anonymous Coward · · Score: 0

      Yrs, they are merging the two systems.

      Apple uses a Crock-Pot, not a flame broiler...

    3. Re:not in apples sandbox! by EETech1 · · Score: 1

      If we take their ports, they'll never even notice when we take their freedom!

  3. 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 TheFakeTimCook · · Score: 1

      Hell they STILL don't understand UI's

      Sure they do. It's called PowerShell.

    4. Re:Midi Manager by TheFakeTimCook · · Score: 1

      At least they still ship GarageBand (last time I checked)

      Not only still ship, they are actively still developing it (and Logic and MainStage, too)

    5. Re:Midi Manager by Dutch+Gun · · Score: 1

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

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

      I'm not sure I'd agree with that. MIDI is alive and well. It's just a lot of the dedicated MIDI-driven hardware has long since gone obsolete in favor of pure software solutions, which I think are ultimately both more powerful and easier to use, if slightly less impressive to look at. But MIDI is still the universal language of digital instruments.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    6. Re:Midi Manager by Anonymous Coward · · Score: 1

      Look into ASIO. It's what most Windows DAW software uses, and it's super low latency direct audio IO.

      Also you're way off base with midi, every usb and most firewire audio interfaces sold today come with MIDI.

    7. 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
    8. Re:Midi Manager by UnknownSoldier · · Score: 1

      I wasn't talking about _external_ hardware (which you are correct) but about Microsoft's support for it.

    9. Re:Midi Manager by Anonymous Coward · · Score: 0

      PowerShell is an abomination!

  4. Found the LUDDITE! by Anonymous Coward · · Score: 0, Troll

    Only LUDDITES want to manage LUDDITE files! Modern app appers use the App Apping App to app apps while apping other apps!

    Apps!

  5. 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 Anonymous Coward · · Score: 1

      *blinks* And what purpose might that be, pray tell? Sure, you're trolling, but I'll bite anyway.

      redmond won because the Unix boys kept on suing each other, leaving them and their questionable and unethical business practices free reign to become entrenched. They didn't engineer it that way, in fact there's pretty much zilch actual engineering going on in their entire code base. Lots of NIH and doing something, anything, different than Unix whether it makes sense or not. Lots of undocumented features and effort to stay bug-for-bug compatible with itself, sure. Lots of clickibunti and railroading the user. But not much in the way of actual architecting, designing, engineering. It's one reason why they have such a terrible track record with security.

      POSIX works about as well as can be expected across not just different versions of the same code, but also across disparate vendors, whereas redmond's code often isn't even documented properly. Anyone have a protocol specification for SMB, maybe?

    3. Re:Longevity of code/interface by Anonymous Coward · · Score: 0

      Remember, WinFile dates back to the late 1980's, so the source code predates ANSI C. It's not at all surprising that code would need to be updated to compile on a modern compiler.

      dom

    4. Re:Longevity of code/interface by Wrath0fb0b · · Score: 1

      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.

      Gee, that didn't define an entire GUI/Windowing system.

      Don't get me wrong, I love POSIX as much as the next guy, but it's a far more limited thing than WIN32. The closest NIX comparison would be GTK, I think.

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

    6. Re:Longevity of code/interface by Waccoon · · Score: 1

      GUIs are driven more by taste than tech, so backwards compatibility with GUIs is far more difficult and impressive.

      Even 20 years ago, many UN*X systems didn't even have a GUI, let alone have a decent one, let alone a set of standards. As a semi-power user, the lack of a good GUI is what always kept me away from Linux, and for the most part, it still does.

    7. Re:Longevity of code/interface by david.emery · · Score: 0

      Well, the whole "16'/"32"/'64" bit thing is evidence of bad original design.

      There are a few assumptions in the Unix/POSIX standards on sizeof(int) that had to be revised, but in general that interface was independent of the underlying hardware register or address width.

      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.

    8. Re:Longevity of code/interface by david.emery · · Score: 1

      It was a running joke where I worked in the '80s and '90s that the only reason I ran X Windows on my Sun workstation was because the scrolling in its "glass TTY mode" was so slow. There's a lot of truth to that. After X Windows launched, I launched EMACS and 2 shells. One was the command line for compiling, linking, etc, and the other was the game of Rogue I played when the compiler/linker was running.

      (This was for software that did not have a significant user interface.)

      And I still do stuff on the command line/Terminal.app on Mac OS X. Old habits die hard, particularly when they're very efficient at getting stuff done (and that includes muscle memory.)

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

    10. Re:Longevity of code/interface by TheDarkener · · Score: 1

      Solitare?

      --
      It is pitch black. You are likely to be eaten by a grue.
    11. 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
    12. Re:Longevity of code/interface by Bert64 · · Score: 1

      A lot of very old unix applications will still build and run on modern linux systems today, including a lot of code that actually predates linux.

      Windows is generally better at binary compatibility, largely due to keeping all the legacy dll files present in the default install while linux distros have long since removed old libs from the default install as very few people would ever use them (almost anything old that you might still want to use will have since been recompiled against the new libs).

      For source compatibility it's hard to beat linux.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    13. Re:Longevity of code/interface by Anonymous Coward · · Score: 0

      WinFile was probably written for the original Windows API (AKA Win16) and later ported to NT. Again, probably they never gave much thought to portability, it was an alien concept in Windows world then (and still is).

    14. Re:Longevity of code/interface by Hattmannen · · Score: 1

      Is this what you're looking for? https://msdn.microsoft.com/en-...

      --
      People are not wearing enough hats.
    15. 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
    16. Re:Longevity of code/interface by TheRaven64 · · Score: 1

      Other standards at the same time did, in particular the Common Desktop Environment. The X11 protocol still works and Motif was open sourced so you can still run 1993 Motif apps on a modern X system. For a given value of run...

      --
      I am TheRaven on Soylent News
    17. Re:Longevity of code/interface by Anonymous Coward · · Score: 0

      DLLs exists on linux, but the implementation is different so we don't have the same problems.

      No "DLL hell", for example.
      Installing an app does not break another because it brought a different version of some DLL they both use, and the other app is incompatible with. Just doesn't happen. If two apps really need different versions of a linux dll, then both versions will be present because the dll version number is part of the filename.

      And no, this does not lead to tons of old dll's, because most apps are comfortable with the latest version anyway.

    18. Re:Longevity of code/interface by Anonymous Coward · · Score: 0

      Sure it happens even on Linux. Try different versions of GNU libc (libc.so.6) or the libgl conflicts with nVidia's drivers and mesa for example.

    19. Re:Longevity of code/interface by Anonymous Coward · · Score: 0

      How did this possibly go unchanged for that long?
      FAT16 -> FAT32 -> NTFS
      That means we went from 8.3 filenames to long file names as art of those changes.
      We also went from maximum volume sizes in GB to TB, with associated growth in file sizes. Was the display actually laid out well enough to handle such variance in sizes 20 years ago?
       

    20. Re:Longevity of code/interface by Anonymous Coward · · Score: 0

      Yes, it's such a crime that Windows, for years, didn't break every other day like various "open source" projects on Linux just because some ADD-addled hipster pooped out another ill-conceived and incompatible beta "standard" to be discarded the next time the wind changed direction like all those before it...

    21. Re:Longevity of code/interface by Damouze · · Score: 1

      Other standards at the same time did, in particular the Common Desktop Environment. The X11 protocol still works and Motif was open sourced so you can still run 1993 Motif apps on a modern X system. For a given value of run...

      CDE was opensourced a while ago as well: https://en.wikipedia.org/wiki/...

      --
      And on the Eighth Day, Man created God.
    22. Re:Longevity of code/interface by TheRaven64 · · Score: 1

      Huh, I remember Motif being open sourced, but apparently I missed the rest of CDE. I used it on Solaris for a while but it was pretty dated even then.

      --
      I am TheRaven on Soylent News
    23. Re:Longevity of code/interface by cyberchondriac · · Score: 1

      Are you complaining about the concept and use of shared libraries in general, or just the way Windows implemented it?
      Every OS uses shared libraries, it's far more efficient and consistent to code that way.. I know that and I'm not a developer by any stretch.
      Older versions of Windows suffered from DLL hell, but that was due primarily to ignorant or arrogant developers who clobbered the default system DLLs thinking their app was the only one in the world that mattered, breaking other apps that relied on the library.
      Now that Windows can sort of sandbox that crap, DLL hell hasn't been an issue for a while.

      --

      Look back up at my post, now look back down, you're on the Internet. Now look back up. I'm a signature.
    24. Re:Longevity of code/interface by Anonymous Coward · · Score: 0

      Older versions of Windows suffered from DLL hell, but that was due primarily to ignorant or arrogant developers who clobbered the default system DLLs thinking their app was the only one in the world that mattered, breaking other apps that relied on the library.

      This, a thousand times this.

    25. Re:Longevity of code/interface by david.emery · · Score: 1

      That's exactly what I did have in mind. Not the concept of shared libraries, but the terrible Windows implementation of same. In particular, the total lack of discipline for where DLLs are stored. Maybe the security problems weren't obvious when Windows came up with its approach for DLL, but the management/configuration problems should have been blatantly obvious. This could have/should have been fixed in Win NT, which at least in theory started from an intellectual/design base that was stronger than Windows 3.

      (I still don't understand how Dave Cutler went -so far backwards- from VMS to Win NT!)

    26. Re:Longevity of code/interface by iampiti · · Score: 1

      What do you do in your job if I can ask?

    27. Re:Longevity of code/interface by DamnOregonian · · Score: 1

      Head * engineer at an ISP/Colocation/Hosting/Virtualization/you-name-it provider.
      I manage/design our network connecting 8 datacenters together, operating as a multi-homed AS,serving a little north of 10,000 residential customers, with a few thousand being fiber-to-the-home.
      ~3500 of those customers pass around 7gbit/s of traffic during peak over a single Linux router running NAT code written by me on an e3-1250.
      I write the lion's share of our software (mostly perl) to wrap it all together, and write custom solutions where necessary (again, mostly perl, but C where necessary).
      Our services are distributed across ~150 or so linux servers across our datacenters, with a few Windows servers for billing and business financials.
      Before this, I flipped burgers and hacked phones.
      I wrote the first exploit against an RSA-signed phone bootloader that I'm aware of (Motorola Razr V3), published an Android privilege escalation (psneuter), and defeated the eMMC write-protection on a generation of HTC phones (wpthis).

      What do I do? I guess i'm a technical jack-of-all-trades.

    28. Re:Longevity of code/interface by Anonymous Coward · · Score: 0

      The original Windows 95 only had FAT16, but with long file names still. (on a 2GB hard drive this was kind of an issue, huge cluster size so significant space was wasted)

      NTFS predates both FAT32 and the hack to have long file names in FAT16/32, funnily.
      I guess NT 3.1 had long file names already (I always wanted to try NT 3.51, but didn't got it running in Virtualbox)

      Seems like Windows still displays file sizes in KB? Even with a TB-sized file you will have no problem fitting a few more digits.
      I bet setting on "KB" everywhere was nice for floppy disks, which support exactly 1440KB. The down side was this little mind game : does this 720,000 KB file fit on a 700MB CD?

  6. This could help Gnome by Anonymous Coward · · Score: 1, Funny

    They should import the source immediately.

    1. Re:This could help Gnome by thegreatbob · · Score: 1

      I have a coworker who apparently agrees. You may be on to something. Or on something. Not mutually exclusive.

      --
      There is no XUL, only WebExtensions...
    2. Re:This could help Gnome by Zaiff+Urgulbunger · · Score: 1

      ^This.

      Did File Manager have the ability to bookmark a location... because I don't think the current Gnome "Files" app can. If I'm wrong, I'm sure someone will say! :D

    3. Re:This could help Gnome by Anonymous Coward · · Score: 0

      On to what? Something as self evident as the fact that Microsoft's 28 year old GUI file manager is better than anything Gnome has ever provided?

      That's not much of an insight.

  7. Not a big deal by eneville · · Score: 0

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

    Things like opendir, readdir, closedir haven't changed a great deal. $company opensources some abandonware to get some type of media attention, why's this news?

    --
    Why UNIX?
    1. 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

    2. Re:Not a big deal by Anonymous Coward · · Score: 0

      Things like opendir, readdir, closedir haven't changed a great deal. $company opensources some abandonware to get some type of media attention, why's this news?

      Because people read it, people even comment on it, like you are doing. This stuff gets posted to encourage interaction and quite clearly it works, if you didn't care about it you wouldn't have delved deep enough to get the point of posting a comment about it.

    3. Re:Not a big deal by luvirini · · Score: 1

      That is the sad truth about current Windows, while quite many things have become better, a lot has become worse. The file manager is hardly the worst culprit, but is definitely among the many things they have borked.

  8. Cool by MBGMorden · · Score: 1

    Not sure how well it holds up, but I remember strongly preferring to keep using the old "File Manager" even when "Explorer" became the preferred solution when Windows 95 was released. Not sure where along the way I begrudgingly gave it up (probably as long filenames became more popular - IIRC it was always limited to the 8.3 format).

    --
    "People who think they know everything are very annoying to those of us who do."-Mark Twain
    1. Re:Cool by Hattmannen · · Score: 1

      I have that very same recollection. Luckily, it wasn't long until I discovered Total Commander (then Windows Commander). Before that I even used to use good old Norton Commander in a DOS window, just because it was more efficient to work with. While drag-and-drop is really handy for doing one simple operation, I prefer my dual panes whenever I need to copy more than a couple of files or just create a new shortcut on the desktop.

      --
      People are not wearing enough hats.
    2. Re:Cool by TheRaven64 · · Score: 1

      The version that shipped with NT4 supported long file names - it was a straight port of the NT3.51 version where it was default and had to support long file names because NTFS did from the start. Windows 95 just included the 3.11 version. I seem to recall that you could just copy the NT version to a 95 system and have it work. I also vaguely remember that Windows 98 imported the NT version.

      --
      I am TheRaven on Soylent News
    3. Re:Cool by Anonymous Coward · · Score: 0

      Amen to that. TotalCommander is the Swiss army knife of file-managers.
      First DV (Dual View) in DOS. (Norton Commander was just a bad clone of that.)
      And then TotalCommander (still called WindowsCommander back then) in Window 3.x.
      I'm still a happy TotalCommander user every day.
      Its the first thing to go on any new Windows computer and I always carry a USB stick with it (it is portable too !).
      And the license I bought in 1994 is still valid !
      (I'm also using Mac's a lot. There CommanderOne is the only thing that comes close.)

      I will not touch Explorer or FileMan unless it is a totally locked down computer that doesn't accept USB sticks.

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

    2. Re:Why bother? by Anonymous Coward · · Score: 0

      Do you always have to deflect by bringing up google when the topic is not about google here?

    3. Re:Why bother? by jellomizer · · Score: 1

      I am not trying to hate Microsoft here. It is just that File Explorer is such a small tool. It is like them releasing the source code for the Clock App, or the Calculator.
      While the applications themselves are not without value, they are easily copied without the need of source code, even for beginner programmers.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
  10. Threadjack by Anonymous Coward · · Score: 0

    A more interesting code dump: EZ-Flash 3 kernel and Window Manager. Explorer has totally eclipsed the old file manager. At least the EZ-Flash 3 stuff heavily backs the EZ-Flash 4 which is still one of the best GBA flash carts.

  11. Linux bums have a lot to learn from Microsoft by Anonymous Coward · · Score: 0, Funny

    How is that for backward compatibility? Linux bums have a lot to learn from Microsoft (which is, btw, the best and most awesome software company in the entire universe)!

  12. 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
    1. Re:A Winfile fetish? by Anonymous Coward · · Score: 0

      I use it for its low memory footprint.

    2. Re:A Winfile fetish? by Anonymous Coward · · Score: 0

      Winfile came out in 1990 with Windows 3.0. Even then it was just minor upgrades to the MS-DOS Executive that shipped with Windows 1.x and 2.x.

    3. Re:A Winfile fetish? by LinuxIsGarbage · · Score: 1

      You might be a good potential user for Far Manager

    4. Re:A Winfile fetish? by DarkOx · · Score: 1

      NDW and Norton Commander - not the same thing.

      NDW 3.0 was still a better shell + file manager than the modern windows desktop. If it could handle hi-res and long file names; I'd still be using it.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    5. Re:A Winfile fetish? by AmiMoJo · · Score: 1

      Check out Lazy Game Reviews (LGR) on YouTube. The guy loves 90s era PCs and his enthusiasm is infectious.

      The other day he bought a top of the range Windows 95 laptop in mint condition. At the time it cost about $5000, which is over $8000 today. He powered it up for the first time, the classic Windows 95 start-up tune kicked in and the speakers ratted and distorted like the cheap 90s era 9000W PMPO crap they are, and it was glorious.

      The old X10 system for DOS was pretty good too. Back then it was pretty awesome to be able to call your computer on the phone, tell it to "turn on lamp" 27 times and see your front room light up from the phone booth down the road.

      It's all a joke now, but was cutting edge tech that many of us lusted after when we saw it in magazines.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  13. Here I had my heart all set by Virtucon · · Score: 1

    Here I had my heart all set on getting Clippy back onto my Windows 10 You're Totally Fucked Spring Edition and they give me File Manager? WTF!?!? Talk about lame.

    --
    Harrison's Postulate - "For every action there is an equal and opposite criticism"
    1. Re:Here I had my heart all set by Anonymous Coward · · Score: 0

      Forget Clippy.
      Bob is still alive and kicking. Installer is floating around on various websites.

    2. Re:Here I had my heart all set by Joey+Vegetables · · Score: 1

      A pic exists somewhere with me sitting next to Clippy in Microsoft's Cleveland area office. Had to be there for a work conference (I do use MS products in my day job), and they all knew I was a Linux geek, so they thought that would be hilarious. In hindsight I suppose it sort of is. Wish I'd gotten a copy. BTW . . . isn't every Windows version the "YTFE"??

      --

      Nonaggression works!
  14. 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 thegarbz · · Score: 1

      I still use Midnight Commander on Linux from time to time

      I still use Midnight Commander... period. It is absolutely awesome. On windows I use Directory Opus which is also a keyboard shortcutable dual window file manager.

    4. Re:Still not better than Norton Commander by Anonymous Coward · · Score: 0

      +1 for XTree. Also, for those not already aware, there's the
        XTree Fan Page with links to several Linux clones.

    5. Re:Still not better than Norton Commander by LinuxIsGarbage · · Score: 1

      Far Manager is a good substitute.

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

    7. Re:Still not better than Norton Commander by drinkypoo · · Score: 1

      You should try DirOpus (for Amiga) sometime. It got freed finally so you can just download it and run it. It makes every other two-pane file manager seem like a moldy turd.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    8. 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

    9. Re:Still not better than Norton Commander by bigmacx · · Score: 1

      WordPerfect for DOS and a well-trained office assistant could bang out an award winning letter out faster than a speeding train.

      Paper keyboard templates...those were the days

    10. 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!!!"

    11. Re:Still not better than Norton Commander by AbRASiON · · Score: 1

      Look at this adorable little chap, thinking Norton Commander even comes close to Xtree Gold, I just wanna rub your nose and pinch your cheek.

      http://www.ztree.com/ my good man, http://www.ztree.com/

    12. Re:Still not better than Norton Commander by bigmacx · · Score: 1

      LOL, you smell like an EMACS user

    13. Re:Still not better than Norton Commander by jowifi · · Score: 1

      I've found Krusader to be a pretty good tool on KDE. On Windows, Total Commander provides similar functionality.

    14. Re:Still not better than Norton Commander by Anonymous Coward · · Score: 0

      ZTreeWin still going strong. I'll use WIndows Explorer for basic copy tasks, but as soon as it goes beyond that, time to fire up ZTreeWin.

    15. Re:Still not better than Norton Commander by Anonymous Coward · · Score: 0

      > Xtree was good, but just plain ugly looking compared to NC.

      You haven't really used XTG the way it was meant to be.

      I use a NC clone almost everyday (Midnight Commander) and let me tell you: it's nice, it's useful -- but Xtree was "musical", in the sense you didn't use it, you played it.

      After memorizing the keyboard shortcuts (which were very coherent and thus easy to learn), one could operate the program almost by haptic memory (like when you remember movements done by the hand when driving a car, for instance).

      And there are good clones described in the aforementioned Xtree Fan page. BTW, by pressing F8 (IIRC), Xtree would present two file panes... useful at times, but not the whole time.

    16. Re:Still not better than Norton Commander by Anonymous Coward · · Score: 0

      Krusader also uses much less memory than Dolphin. But has terrible multiple instances/windows functionality. At least that's the case with the one I'm using which comes with Kubuntu 14.04.

    17. Re:Still not better than Norton Commander by Bert64 · · Score: 1

      I spent hours configuring DOpus to work just right, and be usable in 640x256 to avoid interlacing on an old commodore monitor... Spent ages training it to recognise filetypes etc (you feed it a bunch of example files and it works out what they all have in common - eg the file headers, then uses that pattern to match future files).

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    18. Re:Still not better than Norton Commander by Bright+Apollo · · Score: 1

      Of course, you're wrong.

      Central Point Software's PC Tools had the best suite, including the best file manager. Norton, if I recall, subsumed CPS and rebranded their file manager, and *that* was, for the longest time, ne plus ultra in file management.

      --#

    19. Re:Still not better than Norton Commander by Frederic54 · · Score: 1

      I used NC in DOS in the 90s, then WindowsCommander in windows 3, then the name change at one point to TotalCommander, I still use it in win10, it is at version 9.12. Yes I bought it like 15 years ago. I don't know how to use the Windows File Interface, I only use TC.

      --
      "Science will win because it works." - Stephen Hawking
    20. Re:Still not better than Norton Commander by dunkelfalke · · Score: 1

      Yep, same here.
      BTW thanks for reminding me to update, I am still on 9.0a RC3.

      --
      "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
    21. Re:Still not better than Norton Commander by bigmacx · · Score: 1

      Now I'm back in 1990 arguing the finer elements of ASCII based MS-DOS apps' display vs usability. Is it dementia or really Slashdot? I wonder if I might also have both NC and Xtree open in separate DESQview windows today?

    22. Re:Still not better than Norton Commander by bigmacx · · Score: 1

      OMG, PC Tools was The Shit. Very comprehensive. But looking back on it, that suite was also probably where bloatware was born. Think you had to manually pare down what you wanted to use from PC Tools to get it on a single floppy vs just throwing all of NC or Xtree on a 1.44. 1990's IT tech road warriors were notorious for losing disk#2 of anything by leaving it in the last customer's floppy drive on the way out the door...

      It's fitting Symantec bought the company, because they became the premiere vendor of Windows Server crippling bloatware.

      Thanks for bringing up PC Tools. I might have to go DiskFix this old MFM harddrive and fire up Falcon3

    23. Re:Still not better than Norton Commander by bigmacx · · Score: 1

      We are soo old. Wish we had human Expanded Memory Managers (EMM) because my 640 is full

    24. Re:Still not better than Norton Commander by Bright+Apollo · · Score: 1

      Until last year I had the entire boxed CPS suite, version 6.0. I couldn't give it away, ended up curbing it. That suite pulled out many a rescue and paid for itself in less than three months.

      I was an Apple //e kid, so I had CPS all over my disk library.

    25. Re:Still not better than Norton Commander by Anonymous Coward · · Score: 0

      > Now I'm back in 1990 arguing the finer elements of ASCII based MS-DOS apps' display vs usability. Is it dementia or really Slashdot?

      I hear '60s, '70s and '80s music now and then. Am I crazy?

      Sometimes ancient software is better, like using Wordstar for no-distraction writing.

      No need to despair. Sometimes all I need is the air that I breathe...

  15. OLE? by Anonymous Coward · · Score: 0

    Serious question: Were there any meaningful applications for OLE? I mean applications that were having a significant user base, and the user base was relying on OLE to be more efficient.
    All I can remember would be in the POC area. But I was a kid at the time, so I may have missed something.

    1. 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.
    2. Re: OLE? by Anonymous Coward · · Score: 0

      Equation editor in Word so you can have some meaningful formulas. Thatâ(TM)s about the only useful OLE there ever was.

    3. Re: OLE? by Anonymous Coward · · Score: 0

      OPC

      Industrial control using control. Seriously.

    4. Re: OLE? by Anonymous Coward · · Score: 0

      I always thought (and still do) that Equation Editor uses WMF files for standalone equations. The file format not only holds the fully editable equation, but also enough WMF to show an (albeit poor) on-screen preview, and then print beautifully.

    5. Re:OLE? by TheRaven64 · · Score: 1

      Microsoft Office uses OLE extensively. Any object embedded in an MS Office document is (was?) an OLE object.

      --
      I am TheRaven on Soylent News
  16. Someone Fix Long File Paths - Cos Microsoft can't! by Anonymous Coward · · Score: 0

    Someone please take this and fix File Manager so it uses the new flag and handles Long File Paths properly.

    Because Microsoft appear not to be able ( or bothered ) to fix this decades-old bug.

  17. Nice by Anonymous Coward · · Score: 0

    Simple and functional, unlike this current file explorer

    1. Re: Nice by Anonymous Coward · · Score: 0

      Yup, looks like we may have a viable upgrade for windows 10â(TM)s file browser.
      Iâ(TM)m going to have to try it on my w10 vm.

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

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

      Used to do that, then cut the listing out and slip it into the sleeve with the 5.25" floppy. So much faster to find a file without having to put each disk in and pull a directory listing. Of course, you had to keep it updated.

  19. Still crap by Anonymous Coward · · Score: 0

    The windows file manager was crap, and is still crap. It's a big enough pile of shit for me to fork out the $ for Directory Opus.

  20. what does he do to maintian? by AndyKron · · Score: 1

    What do you do to maintain code that's 28 years old that nobody uses? Was he updating it for Windows 10? Shows what I know about it.

  21. Better than macs version by Anonymous Coward · · Score: 0

    MS got this right a long time ago. Mac team still working on this.

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

    1. Re:ReactOS by Bite+The+Pillow · · Score: 1

      No. Their code is way past this.Unlikely to learn anything.

        Certainly you could run winfile on ReactOS but there's no demand to include it.

  23. FreeCommander by Anonymous Coward · · Score: 0

    When I set up a new computer, "FreeCommander" is the first program that gets loaded.
    Linux AND Windows
    Does it all and doesn't keep screwing the UI.

  24. NOPE by Anonymous Coward · · Score: 0

    https://i.pinimg.com/originals/59/54/cc/5954cc20eeeb8d1fd0ff97d7b6dad584.jpg

    You get a Pardon, and you get a Pardon, and you get a Pardon, and you get a Pardon, and you get a Pardon, and you get a Pardon, and you get a Pardon, and you get a Pardon, and you get a Pardon, and you get a Pardon, and you get a Pardon, and you get a Pardon - - -

  25. Sounds like a one man project. by thevirtualcat · · Score: 1

    Sounds to me like someone inside Microsoft grabbed the source code for the NT4 version of File Manager and patched it up for his own personal use on internal systems. Then he asked his manager if he could release it on Github so he could use it at home, too.

    He was probably completely shocked when he actually got approval.

    I'd be shocked if it was part of any particular open source strategy on the part of Microsoft.

    1. Re:Sounds like a one man project. by Anonymous Coward · · Score: 0

      You would be really shocked if you took 20 minutes to research MS's open source strategy. They have open sourced more projects than anyone else over the past 5 years. And not just deprecated versions of source code they no longer use internally. With the right strategy even a company that relies on proprietary systems to make a profit can leverage open source to improve their products and services. And true to form the biggest MS contributions to the open source world are cross platform developer tools. MS knows that making it easier to develop against it's OS results in more people using the rest of their software stack. While the Linux disciples still haven't figured out that people run applications and don't give a damn about the OS. Linux never made the desktop because all the only applications ended up being poorly cloned MS products.

  26. Are you sure? by ksandom · · Score: 1
    Are you sure? Are you sure? Are you sure? Are you sure? Are you sure?

    Lameness filter encountered. Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition.

    Dang it! That's the joke! Are you sure? Are you sure? Are you sure? Are you sure? Are you sure? Are you sure? Are you sure?

    --
    Funnyhacks - Wierd, unusual, and fun hacks
  27. 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 Richard_at_work · · Score: 1

      You do realise that NTFS has had "resource forks" since its early days, right?

      It just calls them "Alternative Data Streams"... they've been part of Windows NT since ... well, Windows NT.

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

    4. 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!
    5. Re:Why Windows hides file extensions by TheRaven64 · · Score: 1

      Kind of. NTFS provided a way of storing data in different streams, but did not include data stored in alternate streams in file size accounting and did not provide an interface for enumerating them. We used this to great effect when I was in school, storing a copy of Quake in an alternate stream of a 100-byte text file. There was no mechanism for the system administrators to find it and they just saw that disk space was lower than expected.

      --
      I am TheRaven on Soylent News
    6. 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
    7. Re:Why Windows hides file extensions by Lord+Bitman · · Score: 1

      These days, by default, Windows hides "system" directories and anything else that an uninformed user shouldn't touch.

      This is the actual reason. Perhaps this was your point, but I don't think you specifically mentioned it: changing the extension "breaks the file", by making its type no-longer known. There is no valid reason for a non-technical user to want to do this, so it is not a good idea to let users change it "by accident". Ever field a tech support call before "hiding extensions" was the norm? 90% of them were "my file is corrupt" because somebody renamed "Unitled3.doc" to "Report", and had absolutely no idea how to handle it / what was going on.

      --
      -- 'The' Lord and Master Bitman On High, Master Of All
    8. Re:Why Windows hides file extensions by Anonymous Coward · · Score: 0

      The problem with hiding extensions is the default action of an .exe is "execute" which is how you get viruses. Try your unix file manager; the default isn't execute.

    9. Re:Why Windows hides file extensions by DamnOregonian · · Score: 1

      You're kinda correct.
      While there is no POSIX defined way to have extended file attributes, *BSD, Solaris, and Linux all provide mechanisms to store metadata along with an inode, typically in k:v pairs, which would have been sufficient to provide the file type resource fork that they had with UFS.

      Also, ADS is used by Microsoft itself mostly. You're right it doesn't have much use in user code.

    10. Re:Why Windows hides file extensions by DamnOregonian · · Score: 1

      and did not provide an interface for enumerating them

      Not from any user interface, it didn't. But it was there in the API all along.

    11. Re:Why Windows hides file extensions by DamnOregonian · · Score: 1

      Also, I wasn't talking about ADS. ADS are children of the $DATA file attribute.
      All information about an NTFS file is stored in a set of extensible attributes. It would have been trivial to add a new $FILETYPE attribute.
      This is how symbolic links are implemented in NTFS.

    12. Re:Why Windows hides file extensions by munch117 · · Score: 1

      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

      That approach has terrible security. You download a file thinking it's one thing, but the launcher figures out it's something else and launches a completely different application from what you expected.

      Years back, that trick was used to attack a Windows image viewing component. All you needed was a compromise in one of the many file formats that Windows supported, and all you had to do to trick people into viewing a virus-bearing file in that format was to rename the file to *.jpg. No extension hiding needed.

      I really hope Linux desktop environments haven't taken to replicating that bit of stupidity. We were supposed to have learned not to do that.

  28. "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...
    1. Re:"run the app" by Anonymous Coward · · Score: 0

      I am a programmer, and I don't understand what you're getting at.
      Could you elaborate?

  29. Title doesn't match summary by Anonymous Coward · · Score: 1

    They open sourced the file manager SO THAT it can run on Windows 10? But according to the summary it already does and that is the greatness blah blah blah. Open sourcing it doesn't change whether it works or not. And windows 10 already has a file manager so they don't need the old one to work anyway.

    This story seems pointless.

  30. Re:Port to iOS please - DirOpus by gabrieltss · · Score: 1

    Even better - Run Directory Opus (Windows) on Linux - I already have!
    I have run it on Suse 10 It's far superior to the Windows File manager. I used DirOpus on the Amiga and it was awesome then too.

    --
    The Truth is a Virus!!!
  31. Winfile for Windows 2.x? by Anonymous Coward · · Score: 0

    Allegedly there was a beta Program Manager/File Manager for Windows 2.x that at the time was downloadable from the Microsoft BBS. If that was true, it does not seem to have survived on the web. Anybody still have this or know more about it?

  32. Re:Someone Fix Long File Paths - Cos Microsoft can by Anonymous Coward · · Score: 0

    > Because Microsoft appear not to be able ( or bothered ) to fix this decades-old bug.

    They are professional. Professionals don't aim at achieving excellence.

    They aim at making things good enough and set aside new ideas for the next version to make sure there's continued interest.

    Amateurs aim at making things awesome and release new ideas as soon as possible to keep users interested on their software.

    Hence, open source evolves faster.

    Don't expect a lot from closed software -- because you won't get what you pay for.

  33. That original version sucked by Tony+Isaac · · Score: 1

    If you deleted a bunch of files, it would refresh the entire list between every delete, causing it to take an agonizingly long time. Copy / paste had the same problem.

    They fixed this in Windows 3.1, and then proceeded to find ways to make the process take longer ever since, mostly by trying to compute how long the process would take. Nowadays, it takes Windows as long to do the time calculation, as it would to just delete the files!

  34. NT 3.51 apps run on modern operating systems by eggstasy · · Score: 1

    At least they used to, not sure about Windows 10.
    I managed to hack together a semi-functional desktop environment that looked like Windows 3.1 because NT 3.51 apps looked the same and were compiled for 32-bit Windows APIs.

  35. meh by sad_ · · Score: 1

    now release the rest of the windows 3.1 sourcode.

    --
    On a long enough timeline, the survival rate for everyone drops to zero.
  36. Windows hides more than that. by Anonymous Coward · · Score: 0

    Part of the sony rootkit was exploiting the windows "hide system files" where "system file" was __FILE__. And the only way to get at that file was to boot up under something else (tm) and navigate to the area. Windows sure as shit won't let you remove a worm or virus if MS has decided it is named like an "important system file".

    Worse is this excuse doesn't hold up since when you delete an app it will not decide whether or not the "important" dll files et al are no longer used, it wants the user, who it insists is too fucking dumb to handle FUCKING FILE EXTENSIONS!!!!, to work out if it's removed. Despite never giving ANY info as to why it it could be there still.

  37. So can I get a title bar and actual borders back? by Anonymous Coward · · Score: 0

    I know the answer is 'no' since the display design is separate.... but seriously, why take away the ability to make borders larger, visible, and clickable. And don't give me any B.S. about it being aesthetically pleasing. I need to work on this dammit.

  38. Win 7 UI by iampiti · · Score: 1

    This isn't very interesting at this point IMO but if they could opensource the whole Windows 7 UI so that it could run in Win 10 that would be something else :P

  39. Really? POSIX? Great? by Anonymous Coward · · Score: 0

    The only reason POSIX was even needed was that the legacy *nixes had forked to the point that compatibility had become a happy accident, or an explicit design decision, but always an exception.

    Also, how much software was actually coded to the POSIX standards? Not that much in the end. All the major application vendors eventually gave up on the idea of *nix compatibility. They would support one *nix and that was it; it was "use the required *nix if you want to use our application. And you'll use the supported OS versions too. This is non-negotiable."

    POSIX was a nice effort and sounded good but it wound up being too little, too late.