Out of interest, what are some of the pitfalls or hidden requirements that people rolling their own didn't anticipate?
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.
https://groups.google.com/g/alt.games.half-life/c/15MUk17ppH...
* 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?!
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.
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.
Turns out many players still had floppies. Whoops.
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?
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.
* 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
* Logging
* Status tracking (except for really large files things get weird...)
* Aborting/Cancelling installSo - 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.