5 ms·

Out of interest, what are some of the pitfalls or hidden requirements that people rolling their own didn't anticipate?

RajT88 3y ago
Maintaining state for uninstall is a big one which comes to mind. Reference counting (which could sort of be rolled into the above item), to make sure you're not removing something someone else is using, if you install stuff to a shared location. Silent installation. Yes, this is an afterthought for a lot of devs, but a lot of techs expect it for rolling out software. Extensibility / Customization at install time. Also ties into the previous one (how to configure the install with no UI running). Resume-after-reboot functionality, to update files which may have been locked. Publishing accurate information into Add/Remove Programs (or "Programs and Features" as they call it these days). Handling elevation in cases where the user isn't Admin (or post Vista - the installer is launched under the non-admin token). "Repair" functionality, which requires maintaining the currently installed state and configuration. Support for packing up and deploying redistributables (maybe even download support). You start adding all that stuff up, and you realize - you can't bang that out in a weekend. It's a LOT of work actually.
- bombcar 3y ago
  You forgot "not deleting C:/Program Files/" - like Sierra Utilities (un)installer. https://groups.google.com/g/alt.games.half-life/c/15MUk17ppHM https://groups.google.com/g/alt.games.half-life/c/15MUk17ppH...
- JamesLeonis 3y ago
  How could you forget the greatest effort of them all: The Third Party Partner?! * How would we install all these toolbars? * How would we change them in flight based on characteristics we can get from elevated permissions during install time? * How can we bundle adware with the installer so it works without an internet connection? * How can we subvert the Microsoft Store signing algorithm to add arbitrary unsigned payloads at the end of the executable? * How can we run unsanboxed internet-connected javascript with elevated administration privileges and direct access to Windows API? [0] * INCOHERENT QUESTIONS ABOUT METRICS?! [0]: https://en.wikipedia.org/wiki/HTML_Application https://en.wikipedia.org/wiki/HTML_Application
  - KptMarchewa 3y ago
    Oh the signing stuff... so "useful" for tracking info and pseudo-drm.
- dale_glass 3y ago
  Ooh, I'm just going to jump on this chance, because I wondered for ages: What is "repair" for? What exactly does it do, and what's the intended use case? I rarely do much on Windows these days, but my impression was that the age of random applications dumping DLL and OCX files into system32 was fortunately long over, so programs stepping over each other should be almost nonexistent at this point.
  - chiph 3y ago
    It's basically a reinstall where the user's configuration and preferences are preserved. As to why - perhaps a file got corrupted (rare, these days). But often what happens is another program overwrites a shared file to one that is incompatible with your application. Or the user watches a video that tells them about this secret hack that makes your computer run faster... Story time regarding DLL naming from the old days - Windows 95 would only keep one copy of a DLL in memory (the days when having 8mb of RAM was amazing). We had developed an application that worked perfectly, except on this one salesman's laptop - where it would only work occasionally. What I found was they had installed "Tiger Woods Golf" on their machine and it had a DLL with the exact same name as ours. If the salesman played the game before running our application, Windows said "Oh, I already have that DLL. No need to load it again." and our app would blow up.
tkahnoski 3y ago
Vague memory from 10+ years ago: * Getting real deep with detecting OS/instruction set and edge cases * Constantly validating permissions on every directory and file * Constantly verifying checksums on everything put in place * Concurrency controls to make sure the user didn't launch the installer twice, or the system wasn't live running when being reinstalled. * Dependency verification was it's own rats nest of problems * Uninstalling Easier problems: * Logging * Status tracking (except for really large files things get weird...) * Aborting/Cancelling install
- RajT88 3y ago
  Logging is easier - but deceptively so! Most problems have hidden depth, and logging is certainly a great example. So - do you want to log variables for debugging purposes once installers get to a certain level of complexity? Great. Now you're logging people's usernames and passwords, and you have to add some functionality to not do that.
someone7x 3y ago
One time I discovered the hard way why you need to exclude A: and B: drives when scanning for disks for a new installation; our demo disc would hang on any computer old enough to have a floppy drive. Turns out many players still had floppies. Whoops.
- MarkSweep 3y ago
  The "correct" fix is to call SetThreadErrorMode(SEM_FAILCRITICALERRORS, &oldmode) before doing I/O to prevent a dialog from hanging your app. https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-setthreaderrormode https://learn.microsoft.com/en-us/windows/win32/api/errhandl... I only put "correct" in scare quotes because it is kinda lame that this is still required. When was the last time anyone was happy that they got an "Abort, Retry or Cancel" dialog?
- tzs 3y ago
  I’m guessing this was either after the early 2000s or your software was not available in Japan. In the ‘80s and ‘90s one of the most popular PCs in Japan was the NEC PC-9800 series. These were x86 machines but were not IBM PC compatible. MS-DOS and Windows supported them, but didn’t hide all the differences from IBM PC compatibles from apps. In particular, the boot drive was A: so a system with two hard drives and a floppy would usually have A: and B: be hard drives and C: be floppy. That really confused a lot installers that assumed hard drives always started at C: and that A: and B: were always floppies if they existed.

Maintaining state for uninstall is a big one which comes to mind. Reference counting (which could sort of be rolled into the above item), to make sure you're not removing something someone else is using, if you install stuff to a shared location. Silent installation. Yes, this is an afterthought for a lot of devs, but a lot of techs expect it for rolling out software. Extensibility / Customization at install time. Also ties into the previous one (how to configure the install with no UI running). Resume-after-reboot functionality, to update files which may have been locked. Publishing accurate information into Add/Remove Programs (or "Programs and Features" as they call it these days). Handling elevation in cases where the user isn't Admin (or post Vista - the installer is launched under the non-admin token). "Repair" functionality, which requires maintaining the currently installed state and configuration. Support for packing up and deploying redistributables (maybe even download support). You start adding all that stuff up, and you realize - you can't bang that out in a weekend. It's a LOT of work actually.

bombcar 3y ago
You forgot "not deleting C:/Program Files/" - like Sierra Utilities (un)installer. https://groups.google.com/g/alt.games.half-life/c/15MUk17ppHM https://groups.google.com/g/alt.games.half-life/c/15MUk17ppH...
JamesLeonis 3y ago
How could you forget the greatest effort of them all: The Third Party Partner?! * How would we install all these toolbars? * How would we change them in flight based on characteristics we can get from elevated permissions during install time? * How can we bundle adware with the installer so it works without an internet connection? * How can we subvert the Microsoft Store signing algorithm to add arbitrary unsigned payloads at the end of the executable? * How can we run unsanboxed internet-connected javascript with elevated administration privileges and direct access to Windows API? [0] * INCOHERENT QUESTIONS ABOUT METRICS?! [0]: https://en.wikipedia.org/wiki/HTML_Application https://en.wikipedia.org/wiki/HTML_Application
- KptMarchewa 3y ago
  Oh the signing stuff... so "useful" for tracking info and pseudo-drm.
dale_glass 3y ago
Ooh, I'm just going to jump on this chance, because I wondered for ages: What is "repair" for? What exactly does it do, and what's the intended use case? I rarely do much on Windows these days, but my impression was that the age of random applications dumping DLL and OCX files into system32 was fortunately long over, so programs stepping over each other should be almost nonexistent at this point.
- chiph 3y ago
  It's basically a reinstall where the user's configuration and preferences are preserved. As to why - perhaps a file got corrupted (rare, these days). But often what happens is another program overwrites a shared file to one that is incompatible with your application. Or the user watches a video that tells them about this secret hack that makes your computer run faster... Story time regarding DLL naming from the old days - Windows 95 would only keep one copy of a DLL in memory (the days when having 8mb of RAM was amazing). We had developed an application that worked perfectly, except on this one salesman's laptop - where it would only work occasionally. What I found was they had installed "Tiger Woods Golf" on their machine and it had a DLL with the exact same name as ours. If the salesman played the game before running our application, Windows said "Oh, I already have that DLL. No need to load it again." and our app would blow up.

tkahnoski 3y ago

Vague memory from 10+ years ago: * Getting real deep with detecting OS/instruction set and edge cases * Constantly validating permissions on every directory and file * Constantly verifying checksums on everything put in place * Concurrency controls to make sure the user didn't launch the installer twice, or the system wasn't live running when being reinstalled. * Dependency verification was it's own rats nest of problems * Uninstalling Easier problems: * Logging * Status tracking (except for really large files things get weird...) * Aborting/Cancelling install

RajT88 3y ago
Logging is easier - but deceptively so! Most problems have hidden depth, and logging is certainly a great example. So - do you want to log variables for debugging purposes once installers get to a certain level of complexity? Great. Now you're logging people's usernames and passwords, and you have to add some functionality to not do that.

someone7x 3y ago

One time I discovered the hard way why you need to exclude A: and B: drives when scanning for disks for a new installation; our demo disc would hang on any computer old enough to have a floppy drive. Turns out many players still had floppies. Whoops.

MarkSweep 3y ago
The "correct" fix is to call SetThreadErrorMode(SEM_FAILCRITICALERRORS, &oldmode) before doing I/O to prevent a dialog from hanging your app. https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-setthreaderrormode https://learn.microsoft.com/en-us/windows/win32/api/errhandl... I only put "correct" in scare quotes because it is kinda lame that this is still required. When was the last time anyone was happy that they got an "Abort, Retry or Cancel" dialog?
tzs 3y ago
I’m guessing this was either after the early 2000s or your software was not available in Japan. In the ‘80s and ‘90s one of the most popular PCs in Japan was the NEC PC-9800 series. These were x86 machines but were not IBM PC compatible. MS-DOS and Windows supported them, but didn’t hide all the differences from IBM PC compatibles from apps. In particular, the boot drive was A: so a system with two hard drives and a floppy would usually have A: and B: be hard drives and C: be floppy. That really confused a lot installers that assumed hard drives always started at C: and that A: and B: were always floppies if they existed.