Install under any other name…



  • So far, so good, right. It should print Hello, World (or whatever)!, and it does. Ok, so lets rename it...

    Um, first this:

    and then:

    :wtf: is going on here‽

    And it gets better:

    the same screenshot of UAC

    So it's not build_exe (from py2exe) doing something different depending on the name. Something really looks at the name at runtime! :wtf: :wtf: :wtf:



  • Does "py2exe" sign the resulting app?



  • This is an old Windows compatibility feature where any executable that contains "install" or "setup" in the exe name will be run as Administrator because no old installer had a manifest and installing would fail badly otherwise.


  • Grade A Premium Asshole

    @Bulb said:

    Something really looks at the name at runtime! :wtf: :wtf: :wtf:

    Yep. Windows does a substring search of the filename of every .exe you run. If that name contains "setup" or "install" (or -presumably- the localized versions of the same), it assumes that this is an installer and does all that UAC elevation prompt (and subsequent "install success detection and/or survey about the same" bullshit.

    It made sense back when it was introduced. It's probably time to retire it now. :smile:

    Raymond Chen (http://blogs.msdn.com/b/oldnewthing) blogged about this ages ago. I'd link to the post, but I can't be arsed to search for it. :stuck_out_tongue:

    Edit: :hanzo:'d, dammit.



  • Okay, so I've only recently started using Windows and getting my head around how it does stuff - but doesn't this completely and utterly destroy the point of UAC?

    (Yes, a bit like piping wget to a root shell, which is at least equally asinine)



  • No, because it doesn't bypass UAC. Any executable can request elevation via embedded manifest or API calls - changing the filename and running it is the same thing from the perspective of the user.



  • And by the way, if you changed your build script to run "mt.exe" as post build step to include manifest file saying you want to "RunAsInvoker", it should be okay.



  • @gordonjcp said:

    but doesn't this completely and utterly destroy the point of UAC?

    No, because the UAC is still there. All it does is that it preemptively tries to elevate the privileges, because it thinks the executable is going to need them. But it still asks the user if its OK.


  • Discourse touched me in a no-no place

    @bugmenot said:

    I'd link to the post, but I can't be arsed to search for it.

    Given that the cost of a false positive is huge and the cost of a false negative is zero, you can see that the math says to use a conservative heuristic. The heuristic is that a program named setup.exe will be treated as an installation program, and nothing else.
    ­
    Windows was under no obligation to auto-detect installation programs. Indeed, according to the strict interpretation of operating system design, it shouldn't do this. If the user says to run this program at the current privilege level, then you darned well better run the program with the current privilege level. The treatment of programs named setup.exe is really just a compatibility hack, a courtesy to make your life a little bit easier.


  • Discourse touched me in a no-no place

    To clarify something, as Raymond's quote says, the program has to be called "setup.exe". My company's application is distributed as a pair of installers named setup.exe and setupocx.exe. The latter is used in certain specialized instances, and is NOT auto-elevated: programs with "setup" as part of the name don't have that happen.



  • So it's different when install is in the name, as in the first post? :wtf:


  • Discourse touched me in a no-no place

    @LB_ said:

    So it's different when install is in the name, as in the first post?

    Dunno. I can test.



  • @PJH said:

    according to the strict interpretation of operating system design, it shouldn't do this

    Another bad design choice from Microsoft, and they know it.

    Color me surprised :facepalm:



  • Doesn't everybody know that malware always comes packaged in an executable called install.exe or setup.exe?



  • It should be "both". I remember reading that in Raymond's another post.


  • BINNED

    Don't you ever get bored of attacking a company you have nothing to do with at every turn?



  • @TimeBandit said:

    Another bad design choice from Microsoft, and they know it.

    Yes it's shocking that sometimes you get a prompt that you'd get anyway. SHOCKING.



  • @TimeBandit said:

    Another bad design choice from Microsoft, and they know it.

    Yes, shocking a company cares about backwards compatibility (to a fault) because of asshole programmers (often featured here).



  • @bugmenot said:

    Yep. Windows does a substring search of the filename of every .exe you run. If that name contains "setup" or "install" (or -presumably- the localized versions of the same), it assumes that this is an installer and does all that UAC elevation prompt (and subsequent "install success detection and/or survey about the same" bullshit.

    It made sense back when it was introduced. It's probably time to retire it now. :smile:

    Raymond Chen (http://blogs.msdn.com/b/oldnewthing) blogged about this ages ago. I'd link to the post, but I can't be arsed to search for it. :stuck_out_tongue:


    You may be referring to [URL=http://blogs.msdn.com/b/oldnewthing/archive/2010/07/26/10042389.aspx]this article[/URL]. And yes, this sounds like stupid BS.

    If an app needs admin access, let it explicitly request it. I don't want the OS making assumptions based on the file name. Maybe I want to install it privately (e.g. somewhere under my home directory) and it doesn't require administrative access. Why should I need to go through UAC (and possibly have to type in an admin password) simply because of the filename?

    @cheong said:

    And by the way, if you changed your build script to run "mt.exe" as post build step to include manifest file saying you want to "RunAsInvoker", it should be okay.

    I'd like to think so, but according to comments in the "old new thing" article, the filename (or strings scraped from inside the application's resources) appears to override the manifest. Unless your manifest has some new magic to disable the "program compatibility assistant" which always thinks it knows better than the application developer.

    See also:

    • [URL=http://blogs.msdn.com/b/cjacks/archive/2009/06/18/pca-changes-for-windows-7-how-to-tell-us-you-are-not-an-installer-take-2-because-we-changed-the-rules-on-you.aspx]PCA Changes for Windows 7: How To Tell Us You are Not an Installer, Take 2 (because we changed the rules on you)[/URL]
    • [URL=https://msdn.microsoft.com/en-us/library/dd371711%28VS.85%29.aspx]Application Manifest[/URL]

    @Bulb said:

    ... UAC is still there. All it does is that it preemptively tries to elevate the privileges, because it thinks the executable is going to need them. But it still asks the user if its OK.

    Except that if the user doesn't click the button to approve the elevation (or doesn't know the admin password), the application will fail, even though it doesn't actually need elevated privileges in order to run.



  • No, what is shocking is getting a different behavior because of the fuckin filename !

    Windows is full of stupid hack like this.



  • @TimeBandit said:

    Windows is full of stupid hack like this.

    Which are all there because idiot programmers refused to follow the rules, and the users of said programs all (loudly) blamed MS. MS is in a no-win situation.


  • BINNED

    Option 1: Windows N+1 comes out, nice clean API, no hacks. Shitty application v1.4 beta 5 relied on undocumented shit that has been changed, and now crashes out with an error. Users of shitty application tell their friends "don't upgrade Windows, the new one can't even run Shitty Application. Microsoft are such hacks, they don't even test their operating systems."

    Option 2: Windows N + 1 comes out, with shims and application compatibility hacks all over its (closed source) codebase. The undocumented behaviour that Shitty Application depended on has either been documented and won't change, or shitty application's shitty usage of it is detected and worked around. Users can run their existing applications and Linux weenies complain about purity or some shit. Since they hate successful software companies anyway, nobody listens to them. Actual users are happy.

    If you were a Windows product manager, which would you choose?



  • @Jaloopa said:

    If you were a Windows product manager, which would you choose?

    I would choose option 3 : Contact Shitty application v1.4 beta 5 programmer and ask him to fix that shit.

    @Jaloopa said:

    Since they hate successful software companies anyway

    Hating dumb design decision is not the same as hating successful companies.
    Not all successful software companies make dumb implementations.



  • @TimeBandit said:

    I would choose option 3 : Contact Shitty application v1.4 beta 5 programmer and ask him to fix that shit

    Shitty application v1.4 beta 5 programmer refuses to update his code, tells users not to upgrade to Windows N+1. Everybody loses.


  • BINNED

    @TimeBandit said:

    Contact Shitty application v1.4 beta 5 programmer and ask him to fix that shit

    He lost the source code in a fire several years ago and doesn't accept that he should fix his software just because you "broke" it

    Or his company went under years ago and shitty application is now unmaintained. Thousands of customers rely on it and have no real alternative.

    Or it has been updated, but the new version costs more money than the users want to spend. Why should they upgrade just because Windows won't run it any more?

    Or there is an upgrade available but shitty application has no web updater and no way of signalling to users that there is a new version which fixes the bug.

    Any of these result in Windows looking bad and users not updating



  • I thought that article sounded familiar, so I clicked it and the very first comment is mesome totally random person that definitely wasn't me complaining about XFiresome gaming IM program abusing manifest elevation.



  • @bugmenot said:

    Yep. Windows does a substring search of the filename of every .exe you run. If that name contains "setup" or "install" (or -presumably- the localized versions of the same), it assumes that this is an installer and does all that UAC elevation prompt (and subsequent "install success detection and/or survey about the same" bullshit.

    My clean-installed French Windows 7 Pro(1) looks in Explorer like it has a directory called "C:\Utilisateurs" which contains the user profile directories.

    It doesn't. It has a directory called "C:\Users" that Explorer maps to the French version.

    This sort of handwaving avoids issues where ("commercially important"(2) perhaps) applications assume things about what the "Program Files" directory is called, things that are, with this mapping, true, but without it were false. On German systems in the 95/98/NT4 era, it had a different name. These days, the real name is the same on all languages.

    Microsoft are the masters of backward and sideways compatibility. Anyone who thinks they want to get into this sort of stuff should study what Microsoft has done.

    (1) Originally it was a freshly installed Win7. Then it became a well-used 7. Then it became Win10.

    (2) This is a reference to the explanation in a book about Win95 of why the 16-bit GetVersion() call returns different version numbers depending on which program calls it.

    Win95 was version 4.0. If you ran a 16-bit program that was marked "for 3.X" in its NE header, it would report version 3.95. Why? Because in a lazy-arsed program that tests the return of GetVersion() carelessly, 4.0 is less than 3.10. OK, that in and of itself is Microsoft's fault, because GetVersion returns (minorVersion << 8)|majorVersion, so Windows 3.10 returns 0x0A03. Win95, by that scheme, would return 0x0004, which is, indeed, less than 0x0A03. So they returned 3.95, which is 0x5F03, which is more than 0x0A03.

    The book said that "commercially important" applications made this mistake, without identifying them.



  • @Steve_The_Cynic said:

    Win95 was version 4.0. If you ran a 16-bit program that was marked "for 3.X" in its NE header, it would report version 3.95. Why? Because in a lazy-arsed program that tests the return of GetVersion() carelessly, 4.0 is less than 3.10. OK, that in and of itself is Microsoft's fault, because GetVersion returns (minorVersion << 8)|majorVersion, so Windows 3.10 returns 0x0A03. Win95, by that scheme, would return 0x0004, which is, indeed, less than 0x0A03. So they returned 3.95, which is 0x5F03, which is more than 0x0A03.

    Fun fact, there is a similar reasoning for why Windows 7, 8, and 8.1 reported themselves as 6.1, 6.2, and 6.3. Raymond Chen talked about it on his blog as well, but the gist of it was that some programmers were doing something like this to detect Windows XP:

    if (majorVersion >= 5 && minorVersion >= 1)
    

    ...which fails for 6.0, 7.0, 8.0, etc...

    Windows 10 betas originally reported as 6.4, but finally changed to reporting as 10.0.



  • @Steve_The_Cynic said:

    GetVersion returns (minorVersion << 8)|majorVersion

    Holy crap, that is dumb.

    From the documentation:

    many existing applications err when examining the packed DWORD value returned by GetVersion, transposing the major and minor version numbers.

    No shit.


  • Discourse touched me in a no-no place

    @Steve_The_Cynic said:

    French

    @Steve_The_Cynic said:

    what the "Program Files" directory is called,

    What is the Académie française's current take on what it should be called? And what about the actual Windows directory?



  • @David_C said:

    Doesn't everybody know that malware always comes packaged in an executable called install.exe or setup.exe?

    AnnaKournikova.jpg.vbs



  • @FrostCat said:

    To clarify something, as Raymond's quote says, the program has to be called "setup.exe". My company's application is distributed as a pair of installers named setup.exe and setupocx.exe. The latter is used in certain specialized instances, and is NOT auto-elevated: programs with "setup" as part of the name don't have that happen.

    I did not test the case without _, so it might be that is is “setup” as a “word” for some definition of word.

    @David_C said:

    You may be referring to this article. And yes, this sounds like stupid BS.

    I generally agree with it. It's just that some of the hacks have unfortunate side-effects.

    @David_C said:

    Except that if the user doesn't click the button to approve the elevation (or doesn't know the admin password), the application will fail, even though it doesn't actually need elevated privileges in order to run.

    In this case it would have been better heuristics to elevate privilegies if the application actually tries to write a directory, that is only writeable by administrator and perhaps a few other things that installers typically do. That would seem to be a more reliable approach (along with a better message like “The application seems to be trying to install something. Administrator privilegies are needed for that. [It is installer, Ok]/[Cancel]”.

    @powerlord said:

    if (majorVersion >= 5 && minorVersion >= 1)

    Yup, fixed the same kind of error in compiler version check in our codebase recently.



  • @Bulb said:

    In this case it would have been better heuristics to elevate privilegies if the application actually tries to write a directory, that is only writeable by administrator and perhaps a few other things that installers typically do.

    Or have a dialog say something like "This program may need escalated privilege to continue" with a "continue with normal permissions" option.


  • I survived the hour long Uno hand

    Wasn't there a different kind of installer heuristic that said "We detect this may not have installed properly, do you want to rerun it as administrator?"



  • You mean this?

    AFAIK, that's more for compatibility problems that Windows detects when the installer runs, whether or not UAC elevation was involved.


  • I survived the hour long Uno hand

    Ah yeah, that's the one. I associated the shield next to the super-vague text ("recommended settings") with elevation.



  • @TimeBandit said:

    I would choose option 3 : Contact Shitty application v1.4 beta 5 programmer and ask him to fix that shit.

    HAAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA



  • @ChaosTheEternal said:

    You mean this?

    Yes, that comes up at the end, because well, Windows guessed wrong that it is an installer, so they don't see it would have installed anything. And the text is, yes, totally bogus.



  • @Steve_The_Cynic said:

    ... The book said that "commercially important" applications made this mistake, without identifying them.

    The problem with this degree of backward compatibility is that developers stop caring about standards and published APIs. They release whatever lousy hacks they want, secure in the knowledge that Microsoft will never change the undocumented and broken behavior they depend on.

    Apple, on the other hand (at least in the early days of the Mac) would routinely release OS updates that broke or removed undocumented structures and function calls. Developers screamed a lot, but after a few years, they learned to stop writing code that depends on undocumented stuff.

    The Linux world does the same thing, especially in the kernel and in the system C/C++ libraries.

    In many respects, Microsoft's decisions way back in the Win3.x days have created the problems we all have to deal with in the Win7/8/10 days.

    @Bulb said:

    In this case it would have been better heuristics to elevate privilegies if the application actually tries to write a directory, that is only writeable by administrator and perhaps a few other things that installers typically do. That would seem to be a more reliable approach (along with a better message like “The application seems to be trying to install something. Administrator privilegies are needed for that. [It is installer, Ok]/[Cancel]”.

    As I wrote in the other part of my message, we're not talking about an installer, but a generic application that Windows decided to treat as an installer solely because it scraped the word "install" from the filename or a string resource somewhere.

    If it really is an installer, then it should request privilege escalation on its own and not expect the OS to magically figure it out.

    @ChaosTheEternal said:

    AFAIK, that's more for compatibility problems that Windows detects when the installer runs, whether or not UAC elevation was involved.

    As I understand it, that "might not have installed correctly" appears whenever an application that Windows thinks is an installer terminates without creating/modifying a row in the add/remove programs list of applications. If it's not really an installer, or if it deliberately doesn't put anything in the uninstall list (whether or not this is a good thing is a separate discussion), you get this message anyway.



  • If the .exe has a manifest that says it most definitely, certainly does not need admin, then it doesn't give you a UAC elevation prompt, even if the file is named setup.exe.

    It only guesses if the .exe doesn't have a manifest.



  • @anotherusername said:

    If the .exe has a manifest that says it most definitely, certainly does not need admin, then it doesn't give you a UAC elevation prompt, even if the file is named setup.exe.

    It only guesses if the .exe doesn't have a manifest.

    [URL=http://blogs.msdn.com/b/cjacks/archive/2009/06/18/pca-changes-for-windows-7-how-to-tell-us-you-are-not-an-installer-take-2-because-we-changed-the-rules-on-you.aspx]If only it was that simple[/URL].



  • @gordonjcp said:

    Okay, so I've only recently started using Windows and getting my head around how it does stuff - but doesn't this completely and utterly destroy the point of UAC?

    ... how?

    It does make it slightly more annoying if you want to run a program with "setup" in the name that shouldn't bring up a UAC prompt, but. That's pretty edge-case-y.

    @gordonjcp said:

    (Yes, a bit like piping wget to a root shell, which is at least equally asinine)

    It's absolutely nothing like that.



  • So they do this magical detection to make certain that old broken app will install without changes.

    Then they create a way to tell Windows "No, you dumb fuck, I am not an installer"

    Then they break it, so the old app needs to be changed AGAIN.

    What was the point of the magical detection again ?



  • @TimeBandit said:

    Another bad design choice from Microsoft, and they know it.

    That blog post spells out exactly why this is a good design choice.



  • @TimeBandit said:

    No, what is shocking is getting a different behavior because of the fuckin filename !

    THE USER IS IN FUCKING CHARGE YOU OPEN SOURCE DUMBSHIT.

    The user wants to run the Setup.exe file. Elevation is the only way for that file to run successfully. Due to historical reasons and moron developers, frequently the Setup.exe file does not include the correct manifest.

    The behavior here matches the user intention. That is the point.

    WHENEVER you are evaluating the behavior of a program, you must think "WHAT DOES THE USER EXPECT TO HAPPEN?" That should DOMINATE your discussion. That is the ONLY thing that matters.



  • @TimeBandit said:

    I would choose option 3 : Contact Shitty application v1.4 beta 5 programmer and ask him to fix that shit.

    As Raymond frequently points out, much of the time the company that made Shitty Application v1.4 beta 5 is out-of-business and the source code is lost entirely.

    That doesn't mean Windows users won't want to run Shitty Application v1.4 beta 5.



  • @David_C said:

    In many respects, Microsoft's decisions way back in the Win3.x days have created the problems we all have to deal with in the Win7/8/10 days.

    On the other hand, they still have 90% market share in desktops.



  • @TimeBandit said:

    So they do this magical detection to make certain that old broken app will install without changes.

    Then they create a way to tell Windows "No, you dumb fuck, I am not an installer"

    Then they break it, so the old app needs to be changed AGAIN.

    What was the point of the magical detection again ?

    The goal is to make sure a badly built Installer runs correctly. That means the prompt has to show up and they have to click yes.

    Users are used to annoying prompts and have a certain tolerance for clicking yes blindly, so in the rare case that someone makes a file named setup that is not in fact an installer, and didn't actually need elevation, asking for it anyway doesn't break the app. Annoying the developers is less of a concern than annoying users.

    Honestly, the easier solution is to not call your not-an-installer setup.exe or install.exe.



  • @blakeyrat said:

    THE USER IS IN FUCKING CHARGE YOU OPEN SOURCE DUMBSHIT

    @blakeyrat said:

    The user wants to run the Setup.exe file. Elevation is the only way for that file to run successfully.

    And right-click -> Run As Administrator is too hard ?



  • @Kian said:

    asking for it anyway doesn't break the app.

    And if the user click "No", what happen ?


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.