Why does the Directory.GetFiles method sometimes ignore *.html files when I ask for *.htm?


The documentation for the Directory.Get­Files method says

When using the asterisk wildcard character in a search­Pattern, such as “*.txt”, the matching behavior when the extension is exactly three characters long is different than when the extension is more or less than three characters long. A search­Pattern with a file extension of exactly three characters returns files having an extension of three or more characters, where the first three characters match the file extension specified in the search­Pattern. A search­Pattern with a file extension of one, two, or more than three characters returns only files having extensions of exactly that length that match the file extension specified in the search­Pattern. When using the question mark wildcard character, this method returns only files that match the specified file extension. For example, given two files, “file1.txt” and “file1.txtother”, in a directory, a search pattern of “file?.txt” returns just the first file, while a search pattern of “file*.txt” returns both files.

A customer reported that one of their programs stopped working, and they traced the problem to the fact that a search for *.htm on some machines was no longer return files like awesome.html, contrary to the documentation. What’s going on?

What’s going on is that the documentation is trying too hard to explain an observed behavior. (My guess is that some other customer reported the behavior, and the documentation team incorporated the customer’s observations into the documentation without really thinking it through.)

The real issue is that the Get­Files method matches against both short file names and long file names. If a long file name has an extension that is longer than three characters, the extension is truncated to form the short file name. And it is that short file name that gets matched by *.htm or *.txt.

Even as originally written, in the presence of short file names, the documentation is wrong, because it would imply that a search for reallylong*.txt could match reallylong_filename.txtother. But try it: It doesn’t. That’s because the short name is probably REALLY~1.TXT, and that doesn’t match reallylong*.txt.

What happened is that short file name generation was disabled on the drive at the time the files were created, so there was no short file name available, so there was consequently no SHORTN~1.HTM file to match against.

The documentation should really say something more like this:

Because this method checks against file names with both the 8.3 file name format (if available) and the long file name format, a search pattern like “*.txt” may return unexpected results. For example, the file longfilename.txtother may be returned if the short file name for the file is LONGFI~1.TXT.

Update: It looks like the documentation has added my alternate remarks, but they kept the original misleading remarks as well, so now it’s double-confusing. And to make things even more confusing, the original misleading remark has been made even more misleading in the part where it talks about question marks overriding the three-character rule. This is another failed attempt to explain observed behavior. If you search for “file?.txt”, it will not match “file1.txtother”. But the reason is not that the question mark overrides the three-character rule. The reason is that the short name for “file1.txtother” is “FILE1~1.TXT”, and the question mark matches only one character.

Comments (68)
  1. Gabe says:

    I use this "feature" routinely. For example, whenever I need to find an Excel file and don't know whether it's .XLS or .XLSX, I just search for *.XLS and I find it either way.

    I can't imagine writing code to rely on it, though. How could a person write documentation that describes the behavior in such detail and not think that there must be something wrong. Surely they didn't think somebody intentionally designed a system where only in certain circumstances an extension of exactly 3 characters is supposed to find extensions of 3 or more characters!

  2. NIck says:

    Looks like your changes have been added to the documentation and the original essay removed :)

  3. RP7 says:

    @Nick,

    Not when I visit.  I see both the original incorrect note as well as an extra note which says some but not all of what Raymond is saying.  The statement that using "?" forces an exact match on file extensions is simply wrong, but you can see how they came up with it. "Test?.txt" won't match "test1.txtother".  But "test??.txt" will.

  4. John Doe says:

    So much for .NET's portability.  For actually accurate results, one still has to filter out what Directory.GetFiles returns.  And this is a core class, not e.g. WinForms.

    @NIck, but they forgot to update Directory.GetFileSystemEntries.

  5. Nick (a different one) says:

    @640k: Sure, disable short name generation. Otherwise, longfilename.txtother is also named longfi~1.txt (or whatever prefix). Or skip using the match pattern on Directory.GetFiles, write your own .Where() clause, and turn it back into an array (Directory.GetFiles(path).Where(f => f.ToLower().EndsWith(".txt")).ToArray()).

  6. alegr1 says:

    Short names need to go away. Should be disabled by default. Nobody cares anymore. If some retarded enterprise runs some retarded program, just load a virtual XP.

    [News flash: There are a lot of retarded enterprises with retarded programs out there. -Raymond]
  7. Henke37 says:

    Fun fact: As already covered, the file system is responsible for deciding what the short name is for a long name. Not all file systems do it the same way.

  8. Brian_EE says:

    @Raymond: "The documentation should really say something more like this…"

    Perhaps this is a good application of the mantra "Be somebody" blogs.msdn.com/…/10116870.aspx

    [I was somebody already. That's how the second note got there. -Raymond]
  9. RaceProUK says:

    @John Doe: In this case, .NET is at the mercy of the underlying OS/filesystem.

  10. alegr1 says:

    [News flash: There are a lot of retarded enterprises with retarded programs out there. -Raymond]

    Yep. And, all these 10 years since your link (or 11?), they're still running Windows XP. Why does Microsoft want to kill its support, then?

  11. alegr1 says:

    [News flash: There are a lot of retarded enterprises with retarded programs out there. -Raymond]

    That link is a bad example, because MS doesn't even support 16 bit programs in the server SKU (and the client 64 bit SKU) anymore.

  12. Daniel says:

    Really reminds me of some "This bug cannot be fixed because it would break existing code" discussions… (And yes, I've had them. 10 year old obvious bugs that MUST not be fixed…)

    Honestly: At some point you have to draw a line. Short file-names are a thing of the 16-bit area. Windows 7 (x64) doesn't support 16-bit applications anymore. So why are we still talking about short file-names?

    [Because there are 32-bit applications which rely on short file names (often by accident). Just look at all the PROGRA~1 entries in your registry. -Raymond]
  13. Maurits says:

    I assume searchPattern is just handed to FindFirstFile? If so I would like to see all of the searchPattern remarks go away and be replaced with a "see FindFirstFile" link.

  14. Joshua says:

    I personally think it's retarded that .NET's find files doesn't pass FindExInfoBasic to FindFirstFileEx but it wasn't available at the time. FindFirstFile's wildcard expansion is getting really long in the tooth anyway.

  15. Zan Lynx' says:

    I've been disabling short file names on my home-built systems since Vista. So if there have been programs using PROGRA~1 in the registry, they haven't been working. And I haven't missed them. Perhaps it has been saving me from useless programs that like to run on user login.

  16. alegr1 says:

    [Just look at all the PROGRA~1 entries in your registry. -Raymond]

    Those programs would not work with legacy non-English OS, anyway.

  17. Stefan Kanthak says:

    > News flash: There are a lot of retarded enterprises with retarded programs out there.

    > -Raymond

    Most of Windows users dont use those retarded programs!

    You dont need to cripple Windows for ALL users just to support some braindead retards.

    And: 64-bit applications MUST support "long filenames", and 64-bit Windows does not support NTVDM any more.

    Stop the cargo cult!

    > Because there are 32-bit applications which rely on short file names (often by accident).

    These accidents can be fixed: turn off short filename generation!

    > Just look at all the PROGRA~1 entries in your registry. -Raymond

    NONE. Since 1997!

    JFTR: see MSKB 164351 (yes, rather old)

    [HKEY_LOCAL_MACHINESystemCurrentControlSetControlFileSystem]

    "Win95TruncatedExtensions"=dword:00

    [The problem is that everybody probably will encounter at least one retarded program. I had to deal with one just the other day. It was an old game. Not only did it require XP, it required that you be logged on as an administrator. -Raymond]
  18. 640k says:

    @alegr1: It is those programs which are responsible for opening an explorer window on every boot when using non-English OS. This was apparently such a common bug that microsoft had to compensate for it in later oses.

  19. ANon says:

    [I was somebody already. That's how the second note got there. -Raymond]

    @Brian_EE

    For the record, there's a lot of good discussion on that original post about exactly why people DON'T want to "Be Somebody," especially at MS.

    If you're ALREADY 'somebody,' your problem gets resolved. If you're not, people just go "Who is this jackass trying to be?" and ignore the problem (at best).

  20. Mark (The Other Mark) says:

    I almost expected Mr. Chen's link to be to my companies Website.

    Just the other day, we had folks ask how to get an application working on 64 bit Win 7. Turned out the error message was that it was a 16 bit app.

    Now they want to try it in DOSbox.

  21. Joshua says:

    [it required that you be logged on as an administrator. -Raymond]

    Old game requiring admin = writes to the install directory. Usually just give permissions away and it works. I'm not surprised UAC redirect didn't fix it. It never worked correctly.

  22. alegr1 says:

    [I had to deal with one just the other day. It was an old game. Not only did it require XP, it required that you be logged on as an administrator. -Raymond]Yep, that's a very important enterprise piece of software. And just another day, I wanted to run old Vikings game. Unfortunately, it wanted bare DOS and real Sound Blaster.

    [Enterprise software is in many ways quite similar to crappy XP games: They're crappy, they're designed for XP, nobody has the source code. -Raymond]
  23. alegr1 says:

    [Enterprise software is in many ways quite similar to crappy XP games: They're crappy, they're designed for XP, nobody has the source code. -Raymond]That's why Software Gods created virtual machines.

    [Enterprise software is worse than crappy XP games. XP games don't care about interoperating with the other apps or files on the system. But if you have an Enterprise app that wants you to drag/drop some content from an Excel spreadsheet, or to drop your 2014 budget document for scanning, you're kind of stuck. -Raymond]
  24. 640k says:

    Is there a way to search for *.txt without searching for *.txtother?

  25. frenchguy says:

    @Gabe: wouldn't searching for *.XLS* do the trick?

  26. Simon says:

    I commonly use short file names to work around applications/scripts which don't like spaces in file names. If it doesn't like c:Program Files, c:Progra~1 (or even c:/Progra~1) may well work. Some of these apps/scripts were developed on Linux/Unix, where spaces in file names are officially allowed but in practice far more frowned upon than on Windows, and then ported to Windows. But I've even seen it in software originally developed for Windows (oh, our default install directory is C:VENDOR, we never tested it with "C:Program FilesVENDOR", why did you change it to that?)

  27. Joshua says:

    > we never tested it with "C:Program FilesVENDOR", why did you change it to that?

    In our case, we did test it. It worked just fine until Vista's UAC came along and we ended up with too many side-reactions with too many third-party applications (MS-Office, Adobe PDF, some third-party image viewers, scanning drivers, etc.) that we gave up and said C:ProgramsVENDOR.

    Every once in awhile, somebody tries it again. BOOM.

  28. Harry Johnston says:

    @640k: having received all the potential matches, it shouldn't be too hard to check whether the names as returned actually match or not.

  29. Chris Crowther says:

    I really hate methods that don't do what you intuitively expect them to.  If I ask for *.htm I expect to get *.htm. not *.htm and maybe *.htmsomething depending on how the filesystem is feeling.  If I wanted *.htm and *.html I'd do *.htm? and double check the results for any other extensions that might have been included in the process.

    An overload that let you indicate that you want to include short file name in the search wouldn't be a terrible thing, though I suspect laborious bordering on infeasible.

  30. Malcolm says:

    Creating virtual machines is all good and well, until your Powers that Be decide that all 32 bit OSes are evil, and your only option for old 32 bit 'rubbish' is to run it on Server 2003 32 bit. Which gives you about one year's breathing space …

  31. Joshua says:

    @Malcolm: I'm just waiting to see the output of the tech support call for a 16 bit service ending up requiring somebody to try to purchase server CALS for Windows 8.1 workstation 32 bit.

  32. lucidfox says:

    So why does a core method in the supposedly "cross platform" .NET expose Windows implementation details?

  33. Joker_vD says:

    This blog usually is a good morning reading for me, but today it ruined my mood, because I was reminded again that "short file names" exist.

    I really wish there was some other OS besides Windows and Linux to use, without so many unfixable design decisions from the past. But nobody with required knowledge and skill will try and write a whole new kernel today, unfortunately.

  34. Stefan Kanthak says:

    > The problem is that everybody probably will encounter at least one retarded program.

    Dump them in your garbage bin, next to all the other "rotten" programs which don't run any more on current systems, which need administrative privileges or cant handle "long" filenames.

    > I had to deal with one just the other day. It was an old game. Not only did it require XP,

    > it required that you be logged on as an administrator. -Raymond

    Welcome IRL. Sometimes you'll have to dump old things; but you can get new ones which work on current systems, without the need for any quirks.

    The original/first "Designed for Windows" specs, published about 19 years ago, had 1. applications must run without administrative privileges, 2. applications must install below %ProgramFiles% and 3. applications must write their data to %APPDATA% as MINIMUM requirements.

    It REALLY time to enforce these basic rules and dump all non-compliant crap.

    PS: it was Microsofts deliberate decision more than 20 years ago NOT to enforce "clean programming" for their new Win32 API and "New Technology" OS, which both were incompatible to the previous Win16 API and DOS/DOS-based Windows, from the very beginning. You grew exactly the programmers you wanted!

    [You tell a company to dump the program that is central to running their business. See how far you get. -Raymond]
  35. Stefan Kanthak says:

    > "Test?.txt" won't match "test1.txtother".  But "test??.txt" will.

    This is but just an accident.

    The "short" 8.3 name of "test1.txtother" can be "test~1.txt", "test~2.txt", "test~3.txt", "test1234.txt" or "testabcd.txt" etc. Only the first three short names will match. The next million names but not.

  36. Stefan Kanthak says:

    > Those programs would not work with legacy non-English OS, anyway.

    Of course they would work on non-english OS!

    The 8.3 names are created on the running system. If "%ProgramFiles%" happens to be a "long" filename starting with "Progra", then "Progra~1" would be the (first) generated short name.

    Only the "retards" who wrote "PROGRA~1" in their code (cf. MANY *.INF from our beloved manufacturer) were bitten on some non-english OS.

  37. Stefan Kanthak says:

    > and your only option for old 32 bit 'rubbish' is to run it on Server 2003 32 bit. Which

    > gives you about one year's breathing space …

    Nope, you have 5 years to go with 32 bit NT 5.x, and some more years with 32 bit NT 6.x

    Windows Embedded POSReady 2009 (which is an english Windows XP with SP3) is in main stream support until next patch tuesday. After that you get another five years of extended support. Updates are provided via Windows Update.

  38. Kirby FC says:

    @ Stefan Kanthak

    "The original/first "Designed for Windows" specs, published about 19 years ago, had 1. applications must run without administrative privileges, 2. applications must install below %ProgramFiles% and 3. applications must write their data to %APPDATA% as MINIMUM requirements."

    Unfortunately, there is no penalty for not following the "Designed for Windows" spec, i.e., Bill Gates doesn't come to your house and kick you in the groin.  Sure, you can't put a nice fancy "Designed for Windows" sticker on your product's box, but most of the really crappy software is only used internally by businesses.

    And that's the dirty little secret, that's not so secret.  The business world is filled with millions of applications that:

    (a) are very poorly written and just barely work,

    (b) will stop working if you make any change (hardware, operating system, etc),

    (c) can't be fixed because you don't have the source code, because it was written by a third party vendor who no longer exists or no longer cares,

    (d) or was written by an incompetent programmer who is no longer with the company, nobody understands how the program works, and the only way to "fix" it would be a complete re-write. Which, due to the cost, isn't likely to happen in your lifetime.

    This is why there are still so many computers running Windows XP today.

  39. KapilK says:

    I propose two separate APIs depending on whether they use the 8.3 names – DIRECT~1.GETFIL~1 vs Directory.GetFiles.  :-)

  40. Azarien says:

    I don't see the problem. Just don't rely on the fact that search patterns be reliable. If you really REALLY need exact matches only (and you probably don't) just filter out the results.

  41. Daniel says:

    Little Side-Story: Short-Names can be very conflicting if you use different user names and folder redirection.

    I recently ran into a problem with COM Server Registration (Original Delphi code always registers the TLB path as short-name…). Long story short: I've managed to get the same (short) folder name twice which means that the lookup of the TLB failed when loading the DLL.

    Problem: I've installed the registered the COM Server as Admin which looked at the "Program Files (x68)" and created a new short name with ~1. However as user, the ~1 already existed (as redirected folder. A legacy of an earlier installation where an application wrote data to the user directory).

    It took me several hours debugging to realize the actual source of the problem…

  42. Cesar says:

    @Joker_vD: There's also MacOS, but it's from the same family as Linux.

    Other than Windows, the only surviving systems with non-negligible install base are from the Unix family. Even phones are based on Unix systems nowadays.

    As for short file names: a file having a second, invisible name (unless you open the command line and use the "dir" command) is really confusing. As others have noted, folder redirection is really confusing. Both have in common that they are not visible in the user interface, breaking the user's mental model (in which a file has only one name, and paths don't change magically all the time).

    Backwards compatibility might be great, but it can't go on forever; someday, you have to clean the accumulated cruft, before it collapses under its own weight.

  43. Rick C says:

    "Dump them in your garbage bin, next to all the other "rotten" programs which don't run any more on current systems, which need administrative privileges or cant handle "long" filenames."

    Sure, we'll just spend $2300 or so on Installshield and totally rewrite our installer builder just because our current ancient version of XXX Installer only has a 16-bit installer on the installation CD.

  44. Rick C says:

    (which is to say, XXX Installer ships with both a 16- and 32-bit version on the CD, but the actual software on the CD that installs the software (i.e., what autorun.inf launches) is 16-bit, so you can't even install the 32-bit version on 64-bit Windows!)

  45. alegr1 says:

    @Rick C:

    You've had it coming for LONGLONG time.

  46. Neil says:

    The Windows NT 3.51 common dialogs didn't take this into account, so if you used an application that tried to open *.htm;*.html files then all the .html files got repeated.

  47. smf says:

    @Simon  

    What is annoying is when space in file name problems don't get picked up and the default is to install in a directory other than program files. People in QA will instantly ignore the default and refuse to test anything else until the issue has been fixed, when in reality it's not a blocking issue.

    Yes it's crappy enterprise software, but enterprise software is always going to be crappy as there aren't enough customers to justify spending enough time on writing the software properly. You won't be given enough development time to do it properly because it would push the delivery date passed what has been promised, but when the bugs come back later then they can blame you for not doing it properly in the first place.

  48. Stefan Kanthak says:

    > Sure, we'll just spend $2300 or so on Installshield …

    You dont need InstallShield (in fact, this is crap too: an installer that doesnt work without installing some proprietary extensions first is crap)!

    Just create an *.MSI, or use the SetupAPI. Both exist since the last millenium.

    OTOH: if your "product" is as "good" as its installer, its perfect that it fails during installation. Your customers will appreciate that they can use a better product from one of your competitors then.

  49. Stefan Kanthak says:

    > This is why there are still so many computers running Windows XP today.

    Nope.

    This is why Microsoft jumps through loops and can't get rid of most of the quirks they put into Windows in the last 20 years.

    Raymond just wrote about one if them!

  50. Stefan Kanthak says:

    > You tell a company to dump the program that is central to running their business. See how far you get. -Raymond

    Isn't this exactly what Microsoft tells their customers who are still running Windows XP?

    | Enterprise software is in many ways quite similar to crappy XP games: They're crappy, they're designed for XP, nobody has the source code. -Raymond

    [And look how far we're getting. -Raymond]
  51. Nico says:

    @Alegr1:

    > LONGLONG time.

    Haha! That certainly deserves a star :)

  52. Stefan Kanthak says:

    > And look how far we're getting. -Raymond

    Yes, it's sad, really.

    Just to pick up one point: in Windows 8.1 the user account(s) created during setup still have administrative rights.

    It's time to get into your time machine and fix at least the worst decisions that were made during the introduction of NT and later.

    Yes, reality bites (back).

  53. alegr1 says:

    >Just to pick up one point: in Windows 8.1 the user account(s) created during setup still have administrative rights.

    The single biggest reason for Windows having extremely poor security reputation.

  54. voo says:

    @Stefan Kanthak: ok you have one chance to convince me as in user why I should upgrade to Windows 9 if it breaks several of perfectly fine working applications that I either couldn't replace or that would cost lots of money to by anew.

    Hint: "it makes life easier for developers" or "but it's already broken you just don't notice" will not interest me even a teensy bit – no really if you can't name a real concrete advantage for "me" I won't care at all.

    After this thought experiment you'll probably understand MS's position a bit better.. And if you actually come up with good reasons that the average user/manager will understand I guess you just made a fortune.

  55. immibis says:

    @voo: the real concrete advantage is that people will stop telling you to upgrade to Windows 9 :)

  56. Stefan Kanthak says:

    > And if you actually come up with good reasons that the average user/manager will understand I guess you just made a fortune.

    That's SOOO simple: unsupported software is … you guess it … UNSUPPORTED.

    Without support, non-trivial software begins to "rot": newly discovered bugs wont be fixed. If such a nice bug allows an adversary to crash the unsupported software you use or execute his own code you (and perhaps all your precious data) are lost (or stolen). If a bug allows elevation of privilege you and all your colleagues who use your system(s)/network are lost. Your and their precious data too can get lost or stolen!

    Ask your manager how he covers his ass^W^W^Wmitigates this risk!

    Ask him whether he will fire you for using unsupported software that enabled an attacker to gain access to your computer or your companies network and steal your companies assets!

    Ask your companies lawyer too what can/will happen after a breach when customer/confidential data gets into the wrong hands.

  57. Stefan Kanthak says:

    > "but it's already broken you just don't notice" will not interest me even a teensy bit.

    Ignorance is bliss.

    Broken software (like the typical enterprise crap that refuses to run without administrative rights) is even worse than unsupported software: its bugs and security holes are well-known, and there is NO protection against tampering with all your precious data on your system(s) or your network!

    Privilege separation is well-known for at least half a century. Software that does not support it is defective … take a look into european law, for example.

  58. voo says:

    @Stefan Kanthak: So your solution to getting people to update is to.. wait until their current OS looses support and then rely on them updating. Will that work? As we see with XP.. well somewhat. But fun fact did you know that extended support for MS' OSes is about 10 years? (Win 7 ends extended support in January 2020 and was released in 2009)

    So basically you're banking on the idea that MS is fine selling everyone a new OS every decade instead of every two years.. I think it's a fair assumption to make that MS may not be too happy with your solution.

  59. Joker_vD says:

    "That's SOOO simple: unsupported software is … you guess it … UNSUPPORTED."

    Exactly. Their main application is unsupported. And there is no replacement. But it still works, without any additional money needed, while re-writing it from scratch, repeating the testing cycle, re-deploying and re-training the users would cost money—if it would be possible at all.

  60. Anonymous Coward says:

    The thing is, since we're talking about .Net, it is actually quite possible to feed the old buggy behaviour with short names to legacy applications, while by default using the correct long name only behaviour for new software. .Net has all the plumbing in place for that.

  61. Engywuck says:

    "If such a nice bug allows an adversary to crash the unsupported software you use or execute his own code you (and perhaps all your precious data) are lost (or stolen)."

    Real-life counter'arguments': "but we aren't so big that anyone would want to steal from us/crash our operations", "the computer is only used in a production environment, not on the internet" (true – until the software company 'needs' direct access for updates/troubleshooting or a service technician adds his infected notebook directly into the (properly VLANed) line).

    Only solution: get *written* information to your superiors and (preferably) written replys that they know of the problem and don't want you to solve it. Then at least when the manure hits the rotary device it spreads to them, too.

  62. Rick C says:

    @alegr1 but I can't convince my bosses to buy software to replace something that actually works, as long as 32-bit Windows is still available at all, first because of the expense, and second, because as I said, I'd also have to rewrite our installer builder to work with any new program.

  63. Rick C says:

    @Stefan Kanthak: "That's SOOO simple: unsupported software is … you guess it … UNSUPPORTED."

    All the reasons in your post below are irrelevant to me.  My software is updated regularly.  You can think of it as a Java application for purposes of this conversation, although it's not, but it does run in a VM like Java applications do, and it does work with current versions of the VM software.

    It's been installed thousands of times since 1999 or so, and nobody's ever had problems with the installer other than complaints about things like it having Windows 3-style common file dialogs.  Personally I'd love to replace XXX Installer with NSIS, but I can't convince my bosses in doing something that has no perceived benefit to the end user.

  64. Gechurch says:

    @Stefan Kanthak  

    "That's SOOO simple: unsupported software is … you guess it … UNSUPPORTED."

    We're talking about programs that were written years ago, where the developer has long-since left, and in many cases the old source code is gone. The threat of living with unsupported software isn't new to these people… they've been living with that reality for years.

    There's a good way of validating your opinion. When your conclusion differ so wildly from everyone else's, you should seriously start to consider the possibility that you're wrong. And when you've given the topic 5 minutes thought based off a blog post, whereas all the people that disagree with you have spent years living with this problem you should just give up and recognise that the problem isn't as 'simple' as you like to make it. And that your 'solution' of throwing away the software that runs your company because it's crappy, or spending hundreds of thousands of dollars (or more) and months and months (or years) rewriting it possibly isn't the wonderful solution you propose. If it was, everyone would be doing it.

    Of course though, it's better for the pride to continue to think everyone else is an idiot and you're the only one awesome enough to see the truth.

    "Ignorance is bliss".

  65. Rick C says:

    @Stefan Kanthak, those are some uncalled-for attacks.  First, XXX installer is perfectly cromulent, if aging.  We just can't install *it* on a 64-bit OS.  Second, "just use the Setup API" again means a major rewrite of an existing program for minor benefit, and finally, our application works perfectly fine as well–it's just installed with an ancient tool.

  66. Marc K says:

    One of the shocking revelations I became aware of in my career is that software quality is often inverse to price.  I used to think that software that cost $2000 per user would be of the best quality because all that money should allow the vendor to hire enough of the best people to really iron things out.  Then I ended up in a position having to support said software…  Where the money goes?  I have no idea…

  67. Stefan Kanthak says:

    > My software is updated regularly.

    Which means that it is supported. It's the installer that is broken.

    JFTR: stay away from NSIS or other 3rd party tools! Use the native tools/APIs that are shipped with the target platform.

  68. Stefan Kanthak says:

    > they've been living with that reality for years.

    The dinosaurs also lived for years … until their extinction!

    [Dinosaurs lasted over 150 million years. I don't think any corporation will beat that. -Raymond]

Comments are closed.