• Me (unregistered)

    testing the unpublished articles now!

  • P (unregistered)

    The GNU developers surely needs these testers since they absolutely cannot make their installers install to any paths with whitespaces or other characters in them. Their "solution" is, "just default to root path, users aren't gonna try to change it to Program Files anyway".

  • Little Bobby Tables (unregistered)

    So TRWTF is that newly-hired tester didn't test everything properly, and learned a lesson which he could take forward?

  • Anonymouse (unregistered)

    Encountered similar problem once. We had hired a junior developer, given him a clean checkout of the code our flagship application from the repository, but he could not launch it from the very beginning, i.e. while compiling in Visual Studio went flawlessly, he could start neither in debug mode nor otherwise. A bunch of weird errors happened and the debugger could not go to wherever the errors came from because they were system level. For two days we tried to find the issue, until i found out this guy had saved the whole solution on his desktop. No one had noticed because he always had already opened VS when someone sat down with him to help. And no one had even suspected that a developer, junior or not, would come up with the idea to save a huge solution of over 8 GB of code on his desktop. BTW the actual reason is, the system DLLs .NET uses are saved in some folder very deep in Windows folder, where every other folder on the same machine has access rights except the desktop. So any project on desktop cannot use any method from the system namespace. I don't know why but it seems Microsoft deliberately did this. We just did not know because no one in the company had ever tried to run a solution including projects on the desktop before.

  • (nodebb) in reply to Little Bobby Tables

    To be fair, "installing to the desktop" doesn't seem like something you'd think of as a tester, until first encountered in the wild. Installing to "C:\This\Folder\Structure\Makes\No\Sense"? Check. Installing to "C:\Users\me\Desktop"? Pretty weird, plus why would it behave differently from the first case?

    I'd honestly be more interested though into why installing to the desktop can cause a BSOD. Endless loop when trying to resolve the link, because "PATHEXT" starts with ".LNK"? Still not BSOD Material.

    I can see how installing everything into the same folder might cause programs to override each other's DLLs, which may cause a BSOD, but even then I don't see how the creation of an .LNK file would make a difference.

  • Decius (unregistered)

    BSOD on trying to create the shortcut, and also on installing to the user's documents folder, makes me think that the installer is abusing the filesystem and somehow managed to generate a self-referential link and then try to write to its referent.

  • Foo AKA Fooo (unregistered)

    Crashing the OS when writing to an unusual place? Wow, but I guess Microsoft apologists will still claim that Windows is all great and secure and it's all the user's fault, right?

    Even if it's a security measure as Anonymouse said (and a very poor one, if moving the executable is all it takes to circumvent it), crashing the OS is not what you do on a security violation, or you've handed the bad guys the key to DOS (in the evil sense, I mean the attack sense, not the other evil sense).

  • RLB (unregistered) in reply to Foo AKA Fooo

    You're assuming that it was Windows which caused the crash. It could just as well have been the broken installer which cannot handle not being allowed to access sister directories, and tries to do something crash-worthy.

  • Sole Purpose of VIsit (unregistered) in reply to Foo AKA Fooo

    I'm not sure what a "Microsoft apologist" might be, but I know a straw man argument when I see one. And that there is a straw man argument.

    It's implicit in the OP that the vendor found the installation bug (whatever it might have been) and fixed it. And that's pretty much all we know about the bug itself (although I'm guessing it has to do with Window's "special directories"). It's also semi-explicit that the crash/BSoD is atypical for installations to a WIndows 2000 desktop, because it's "corporate policy" to install to the desktop (a WTF in itself). So, no, it's not the user's fault. Nobody would claim it's the user's fault. The proximate cause is the vendor's installation program. And security issues in Windows 2000? Maybe, although I'd rather have a DOS which requires you to be on the right side of the airtight hatchway than an actual security violation.

    Not that Windows 2000 was the most secure of systems, as anybody who remembers the Summer of Worms (or whatever that was called) will attest.

  • Anonymous Coward (unregistered) in reply to RLB

    A crash in an application should just result in the application dying; I didn't think it was possible for an application to cause a BSOD—that those come from crashes in the kernel (so either Windows API calls or in device drivers)

  • (nodebb) in reply to kbauer

    With Windows 2000 it was "C:\Documents and Settings" not "C:\Users", so maybe the problem was paths with spaces?

  • (nodebb)

    Me, I do my laundry on my desk.

  • NULLPTR (unregistered) in reply to Me

    #include <wtf.h>

    wtf("WTF on how that comment got there");

  • Non-Apologist (unregistered) in reply to RLB

    A BSOD is a kernel crash. In particular on NT-derived systems like Windows 2000 this must mean that there was a bug in the kernel or driver. User-mode code, such as that running in an installer, cannot cause a BSOD. It's the code in the system itself that triggers that kernel panic. So even if the program did something stupid, it should only ever result in that program crashing, and not the entire system. Anything else is a system bug.

  • (nodebb) in reply to Non-Apologist

    Unless the program included a driver, of course. Then all bets are off.

  • I can be a robot if you want me to be (unregistered)

    Solution: informed user that installing with non-standard settings was not supported, and to contact the sale department if modification was required.

  • (nodebb)

    TRWTF is anyone who uses the Desktop for anything. Yeah, I know, flamebait for all those folks who think they gotta have 15 folders and 35 documents on their desktop, but really: put all your "gotta see it right away" items into a C:/$USER/QuickGrab folder, pop open a Windows Explorer window, and you've got the same thing but now you can see the entire file names, you can sort by type, name, mod. date, etc. AND you don't have to deal with some icons on the "Desktop" being in your personal desktop folder, some in "Shared Desktop" folder, some in some Admin-controlled Desktop folder.

    And also learn to pin your "favorites" to their associated Apps in the TaskBar.

  • (nodebb) in reply to P

    The GNU developers surely needs these testers since they absolutely cannot make their installers install to any paths with whitespaces or other characters in them. Their "solution" is, "just default to root path, users aren't gonna try to change it to Program Files anyway".

    Just one of many reasons why Linux, which I have been using since kernel 1.0.9, is still broken

  • Anonmouse (unregistered)

    As I first started reading this, I was wondering if the user was literally trying to shove a CD ROM disk into his wooden desk...

  • Grasping for straws (unregistered)

    Blake seems like the type of guy who would not merely chuckle to himself.

  • LCrawford (unregistered)

    | TRWTF is anyone who uses the Desktop for anything. Yeah, I know, flamebait for all those folks who think they gotta have 15 folders and 35 documents on their desktop,

    This - I counted 110 Internet web site shortcuts on a friend's desktop, supposedly to make them easy to "find" . Good luck on that when they are routinely re-shuffled.

  • Ann on a Mouse (unregistered) in reply to Bananafish

    To be fair, I recall finding a very, very long page in which the author proved conclusively that there is no way to write a shell script for the POSIX shell which will correctly handle all possible paths. Every method has a loophole, so there’s no point in trying to perfect an installer script which permits custom install locations. (Of course, you can reduce the number of possible error cases to things which aren’t as common and obvious as spaces, but since Linux is an OS for hobbyists anyway, why bother?)

  • Programmer Robot 10C-32 (unregistered)

    I had a user who did the exact same thing, but to make the matter worse, she immediately deleted those 'messy temporary files' (ie, the program) that popped up on her desktop during the install.

  • sizer99 (google)

    Always remember: There is nothing so ridiculous and misguided that an Enterprise won't make it corporate policy.

    I wonder if anyone's installed stuff to %TEMP% and what that does after a disk cleanup. If not it's only because %TEMP% is not obviously accessible like Desktop is.

  • (nodebb)

    I like the programs that put stuff in %TEMP% and reboot the system and then try to execute what was in there. We had a number of machines that had been set up with %TEMP% pointing to a ram disk. The installer was not happy.

  • Foo AKA Fooo (unregistered) in reply to Ann on a Mouse

    What an argument! Well, you know, I recall finding a very, very, very long page in which the author proved conclusively that Windows is crap. -- Link or it didn't happen.

    Anyway, without further qualification the statement ("there is no way to write a shell script for the POSIX shell which will correctly handle all possible paths") is definitely wrong. The following (will which probably get messed up when posted here) is a trivial POSIX shell script, but handles all possible paths:

    #!/bin/sh cat "$1"

    There are indeed certain shell constructs that are hard to get right (though it isn't clear that a simple installer would need them at all), but as stated the above won't hold.

    But of course, your last statement disqualifies you from ... really anything. I guess the majority of the world's mobile devices and all of the top 500 supercomputers are just hobbyist projects?

    Also, as the FSF likes to point out, but here it's really relevant, GNU != Linux. Linux (the kernel) has no problem with spaces etc. in file names. The bugs here, as mentioned, are in some of the GNU programs (whether they run on Linux, Windows or elsewhere).

  • Zero (unregistered)

    As for corporate policies: a policy of past in our place (replaced by better ones now) was to set encryption to ON on the "Documents" folder. But no part of the policy said anything like "you should save everything under Documents" or "you should save all confidential material under Documents". I do not like the special status that windows gives to some folders like Documents, so I use a different hierarchy. So the policy was meaningless. And policy enforcers would actually come and check whether the Documents folder looks "green" i.e. encrypted, but as expected, not check any other places.

  • Wonkothesane (unregistered) in reply to cellocgw

    How about instead of your c:\user\quickgrab we use c:\user\desktop

    Which puts things on the desktop and can ALSO be opened in explorer to see full file names and be sorted etc.

    Best of both worlds?!

  • Jan (unregistered) in reply to Sole Purpose of VIsit

    I love how Raymond Chen and other Kool-Aid drinkers call it "airtight hatchway". Except for all the air leaks that somehow keep suffocating the astronauts.

  • Cynics united (unregistered) in reply to Bananafish

    Come now, surely that's GNU/Linux; this puts the fault where it belongs.

  • Cynics united (unregistered) in reply to Ann on a Mouse

    Os for hobbyists? Ah, that's why there is an "Enterprise" in RHEL, and why basically all coud services builds on Linux, or basically all supercomputing builds on Linux, or ... well, you get the picture, I should hope.

  • Erwin (unregistered) in reply to sizer99

    An alternative approach is to have %TEMP% pointing to your desktop folder.

  • Jaloopa (unregistered) in reply to Cynics united

    Ah, that's why there is an "Enterprise" in RHEL

    And the Peoples Democratic Republic of Korea is a democracy. It's in the name so it must be true

    basically all supercomputing builds on Linux

    Naming a computer after a comic book? Sounds exactly the sort of thing a hobbyist would do

  • (nodebb) in reply to P

    A large portion of my work involves using a particular program. This program, which is for Windows only, does not allow spaces in the installation path. If you change it from the default to the proper location under Program Files, the installer gives you an error message complaining about the spaces and will not let you proceed.

    The really annoying thing is that earlier versions of the same application used to install quite happily into Program Files. But I think this was probably more an OS thing than an application thing - the root cause of the issue, I suspect, is that it writes workspace files (which update in every session, storing things like which items you currently have open and how you have them laid out) underneath its own directory instead of putting them in AppData where they belong. I guess once the OS started cracking down on this sort of behaviour they decided to "fix" it by not allowing the application to be installed in Program Files, rather than by simply saving user data in the user data folder.

  • (nodebb) in reply to irontoby

    With Windows 2000 it was "C:\Documents and Settings" not "C:\Users", so maybe the problem was paths with spaces?

    More likely to be a nested subdirectory falling afoul of path length limits. "Documents and Settings" always took a nice chunk out of that, and by the time you add the user name, the program vendor name, and the program name, you're getting quite a long string even before you get to the subdirectories (and what self-respecting program doesn't have at least five levels of nested subdirectories in its program folder?)

  • (nodebb)

    I know, three comments in a row is terribly gauche. But I just wanted to add: I find something strangely (or perhaps horrifically) appealing in the idea that the end customer's IT insisted on having the application itself installed into a folder on the desktop, because they don't trust shortcuts, but also insisted on having a desktop shortcut created for it. Because the best way to find something that's on the desktop is to have another thing on the desktop pointing to it. (To be fair, the actual executable might not be easy to find from the application folder. But then, that's why normal people stick the application folders away in Program Files and just expose the shortcuts to the user.)

    For added consistency, I'd arrange all the applications in a grid pattern, with alternating columns of shortcuts and the corresponding application folders, so every shortcut is next to its application folder. Makes it easy to see if you've missed any!

  • dan (unregistered) in reply to Anonymouse

    What version of VS was that? My desktop generally ends up being used as a temp location and I've ran VS 2017 .net solutions from there before. (ALmost certainly some older ones too; but not sure exactly what I did years ago.)

  • eric bloedow (unregistered) in reply to Anonmouse

    reminds me of several old stories where someone jammed a CD into a floppy drive, and vice-versa...

  • (nodebb) in reply to Scarlet_Manuka

    More likely to be a nested subdirectory falling afoul of path length limits.

    <wideeyedinnocent> But the Windows path length limit is 32767 characters... </wideyedinnocent>

  • (nodebb) in reply to Foo AKA Fooo

    "Wow, but I guess Microsoft apologists will still claim that Windows is all great and secure and it's all the user's fault, right?" I'm no great fan of Microsoft, but let's be fair. The fact that it is possible to write a program that fails when run on a certain OS is hardly proof that there are major problems with that OS. Please tell me what OS you use in which it is impossible to write a program that gives errors.

  • Pedantic (unregistered) in reply to Foo AKA Fooo

    Will it handle the relative path "--help"?

  • jgh (unregistered) in reply to thosrtanner

    I once used a system that had %TEMP%=C:\DOS And then installed something that cleaned up after itself by wiping %TEMP%.....

  • jgh (unregistered) in reply to Steve_The_Cynic

    I remember having to write work-arounds for Windows XP having a path length limit of 63 characters. The OP is writing about Win 2000.

  • Anonymous (unregistered)

    The "security policy" makes things more insecure. If you want to lock a system down, users must not be able to run programs from locations they can write to or vice-versa. But then it is a story from the early noughties, when security on Windows PCs was generally absymal.

    It's why in 2019 I find programs that insist on writing to their install folders, running from AppData, or other such nonsense to be very annoying. They're manageable if they have proper digital signatures at least, but still annoying.

    Oh, as for "To be fair, I recall finding a very, very long page in which the author proved conclusively that there is no way to write a shell script for the POSIX shell which will correctly handle all possible paths"

    That's because POSIX allows stupid stuff in filenames. Like newlines.

  • Anon (unregistered)

    I'm just glad Windows 10 is the last Windows ever. That way my programs will always work as they do now, and never have to be rebuilt.

  • eric bloedow (unregistered)

    reminds me of several old stories where someone tried to "clean up" their disk drive by moving Windows files into a new folder...

Leave a comment on “Once Bitten, Twice Tested”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article