Hacker News Reader

Comment by RajT88 | Hacker News Reader

I worked for InstallShield for a while, and had customers routinely say, "I could build a better installer in a weekend than InstallScript / Windows Installer / Whatever". I always just sort of rolled my eyes, due to the complexity I was aware of across the (many) features of any given installation engine.

It's a long story as to why, but I actually ended up building an installer engine in Powershell some years later. I can now officially say all those people are morons, and you definitely should not in this day and age be rolling your own installer engine.

View on HN

With all due respect, I was involved in advanced Windows projects and always thought that InstallShield was s** and beyond its complexity it has an advantage because of business reasons more than technical ones: https://en.wikipedia.org/wiki/InstallShield

Microsoft promoted it strongly, and mysteriously they never come up with a decent installation support, even for basic desktop apps.

Answering the topic here: it is the business more than the product. With exceptions, as usual.

InstallShield was the only game in town at first. So it was amazing from that perspective.

Windows installer came along and was a lot better. The InstallScript engine carried with it a lot of legacy tech-startup technical debt.

Fun fact: InstallShield became a general purpose packaging tool at some point which spit out *.msi packages (and had a bunch of extensions to Windows Installer engine via custom actions). So it was pretty awesome from that perspective.

In this day and age Windows Installer itself has a lot of legacy design cruft from the era it was designed for - the late 90's.

So you're not wrong, but based on the era InstallShield was more or less crappy depending.

I would like to add that was incredible that MSI were the installation standard and Visual Studio, which is the core of MS development, couldn't generate them! Yes, you can generate vanilla MSIs but are almost never what you want except for trivial installations.

Sorry, but I want to add one more thing: the upgrade logic of MSIs is completely wrong, you need a lot of tricks to do an upgrade.

Upgrades were not that bad if you had a document in one place that explained how they worked (MSFT did not have this concentration of documentation - they are not the best at knowledge management).

Patches though... Fuck. I think I could still produce a document that explains everything you need to know about patching but it is a lot more complicated than regular upgrades.

At the same time, my career has moved to Cloud stuff now. Is my life better? Definitely not.

I've written some installers using Installshield and later the WiX toolset, and the typical application developer has no appreciation on how difficult it is. "Just copy over the binaries, it's not hard."

Well, when your customer is an enterprise who wants to deploy your product hands-off onto five thousand machines, and expects a clean uninstall when they want it removed later - yes, it's that hard. Writing installers really is it's own sub-speciality in software development.

raises hand Similar only we created a Java Swing GUI since it was multiplatform.... So you'd install the JRE (it's multi-platform right?), then you'd install Postgres (what?) then run our installer to put code where it needed to go and configure the database and application settings.

The testing cycle was the biggest pain, this was right as VirtualBox had become a thing so at least starting with a fresh system was slightly easier. (The entire company had 4 engineers + some researchers).

I think I was two years post-college as were most of my other colleagues... I'm fairly certain that product never made it out of initial trial (I left the company before it finished).

> then you'd install Postgres

That sounds horrible. Why didn't you use file based HSQLDB or H2 (or any other pure java sql DB)?

The install of postgres was relatively trivial, it did however raise many licensing questions and I don't think we even had a lawyer on retainer to talk through it. This also made it weird because of license reasons, we couldn't actually download and agree to the license because that would be our company 'selling postgres' as part of the package so we needed the client to do that step.

I can't remember exactly why HSQL/H2 wasn't used but I think it had to do with fault tolerance and redundancy and what we could do with postgres replication was preferred over what we would have otherwise used SQLite for.

Do you have any opinion about "Nullsoft Scriptable Install System" (NSIS)? Ref: https://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_Sy...

I was always very impressed by it.

That depends a lot on the customer's need, no?

If the application is a single .exe or something that works fine when you unzip a .zip wherever, then the installer functionality needed is almost trivial.

My limited experience is that most complexity in installers comes from the system not helping making it comfortable. Like something not having a simple to use version number, but having to check for 5 registry keys instead, or some such.

Writing a general install engine like that is indeed hard. If that’s what people claimed they could do in a weekend more than an eye roll would be justified, such as hails of laughter. Such a reaction would be justified even if they said they could do it in a month or two.

However, if someone just claimed they could write a better installer for one specific program of theirs only that was better for that one specific program than an installer built with one of those general engines, that is not so unreasonable except for the in a weekend part.

I once worked for a DOS and Windows utility software company that wrote an installer for each product, and I was usually the guy that ended up doing the installer and it wasn’t difficult. If however they had decided to try to make an installer engine product for other companies to use I would have worked hard to not get assigned to that project.

I worked for a company that was making windows software when I was 17, and writing an installer for one of their apps was given to me as a small project.

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

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.

You forgot "not deleting C:/Program Files/" - like Sierra Utilities (un)installer.

https://groups.google.com/g/alt.games.half-life/c/15MUk17ppH...

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

Oh the signing stuff... so "useful" for tracking info and pseudo-drm.

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.

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.

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

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.

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.

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/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?

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.

And yet for some reason pretty much all the software I install on my mac is literally "drag and drop into applications"?

Or homebrew which is really just dependency management + standardized directories for files which is what it should be. Installshield was a solution for an entirely artificial problem.

There are many tradeoffs the major OS's made over the years.

There is a reason Mac had such tiny market share for so long, especially among enterprises. Installation was among pros and cons, but I would advise you to come off your high horse and understand the rest of it. Some reasons technical, some not. For a long time enterprises shunned Mac for extremely pragmatic reasons.

I've never had a Mac and have no particular experience with it, what are the extremely pragmatic reasons? I know there are a few like HFS+ only allowing one file to be read at a time under-the-hood, but I doubt minor performance issues are the key reason for enterprise choices.

These is as generic a response as the article itself, and is just as unhelpful since any of the two extremes fit: it could very well be that those tradeoffs were mostly bad decisions, or it could also be the only proper way to do it, and Mac's easy way is still wrong

Why use an installer at all in this day and age? A lot can be customized in the browser nowadays before download. Or tweaked after download/execution. Or use a build script (if technical audience). Or just isn't needed.

I think the last installer I used was probably the Linux Mint/Ubuntu live CD installer?, But other than that I don't think I've seen an installer for a couple years. Albeit I'm in the Linux ecosystem now so maybe that's why

That’s entirely why. A massive caveat.

Are you talking about OS installer? Cause this is application installer. You likely used an installer today but didn't notice it.

The model on Windows is that you ran installer program that installed the application. Installers had to do a lot more stuff than drop the application in the right place like change registry entries or write files in other place. InstallShield wrote the installation engine and build tool.

Windows moved to model of .msi packages with .exe wrapped. InstallShield turned into an .msi build tool. Macos has .pkg installer for things that can install .app. Linux has .dpkg or .rpm. All of them have the installer pre-installed.

I'm just talking about an installer in general, a wizard handling user customization and environment specific casing. Seems like the only place you might want something like that in the modern age would be an OS installer. Except I'm less familiar with the Windows ecosystem nowadays

I never even understood the motivation everyone seems to have had to shun the standard installers available to them. Why was that?

When InstallShield was founded in 1987 all companies were making their own installers.

https://en.m.wikipedia.org/wiki/InstallShield

MSFT released MSI 1.0 in 1999.

https://en.m.wikipedia.org/wiki/Windows_Installer

Post 2008 or so, there was a very good question of why anyone would use anything other than *.msi on windows. But most Installshield users by then were building those packages with InstallShield by then.

These days, lightweight apps and dev tools are still preferred to use *.msi or *.exe based formats instead of windows store apps. Partly because it is quick and dirty to do so, and cheap using things like WIX and NSIS. But InstallShield still has a legacy base among less sophisticated users; it is easier than WIX and more robust than NSIS and the like.

Windows Store package formats are superior in most ways.

Very curious to hear more about the installer engine built in Powershell. thnx

It used an *.xml file to store all the things which needed to happen to setup the system. File copies, registry entries, installing dependencies of various types, running scripts, configure windows features, IIS sites and directories and app pools and what-have-you, some other misc. stuff I forget now. Also would restart the computer if a restart return code was received, and would provision a user it would set up for auto-logon to resume install progress after the restart.

Each type of entry in the config file had a module which knew:

- How to check if the entry was already done and in a good state

- How to uninstall cleanly the thing (not actually needed; this was for system imaging)

- Usage of variables that would dynamically configure the system

- Variables also could conditionalize what gets installed

At the end of the day it was somewhere between a true installer engine and Powershell DSC (DSC would come about a few years later). This installer is probably no longer in use, as you can imagine more robust ways of solving this need exist now.

It was a heck of a lot of fun to build and watch it working though!

Reply on news.ycombinator.com