4 ms·

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 /

by RajT88 3y ago

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.

didntcheck 3y ago
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.
cobertos 3y ago
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
- tmpX7dMeXU 3y ago
  That’s entirely why. A massive caveat.
- ianburrell 3y ago
  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.
  - cobertos 3y ago
    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
tkahnoski 3y ago
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).
- Traubenfuchs 3y ago
  > 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)?
  - tkahnoski 3y ago
    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.
dale_glass 3y ago
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.
wslh 3y ago
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 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.
- RajT88 3y ago
  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.
  - wslh 3y ago
    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.
    - RajT88 3y ago
      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.
dataflow 3y ago
I never even understood the motivation everyone seems to have had to shun the standard installers available to them. Why was that?
- RajT88 3y ago
  When InstallShield was founded in 1987 all companies were making their own installers. https://en.m.wikipedia.org/wiki/InstallShield https://en.m.wikipedia.org/wiki/InstallShield MSFT released MSI 1.0 in 1999. https://en.m.wikipedia.org/wiki/Windows_Installer 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.
booi 3y ago
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.
- RajT88 3y ago
  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.
  - Qwertious 3y ago
    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.
  - eviks 3y ago
    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
    - deleted 3y ago
      [deleted]
imperialdrive 3y ago
Very curious to hear more about the installer engine built in Powershell. thnx
- RajT88 3y ago
  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!
throwaway2037 3y ago
Do you have any opinion about "Nullsoft Scriptable Install System" (NSIS)? Ref: https://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System https://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_Sy... I was always very impressed by it.
tzs 3y ago
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.
- bemmu 3y ago
  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.

by RajT88 3y ago

didntcheck 3y ago

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.

cobertos 3y ago

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

tmpX7dMeXU 3y ago
That’s entirely why. A massive caveat.
ianburrell 3y ago
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.
- cobertos 3y ago
  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

tkahnoski 3y ago

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).

Traubenfuchs 3y ago
> 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)?
- tkahnoski 3y ago
  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.

dale_glass 3y ago

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.

wslh 3y ago

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 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.

RajT88 3y ago
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.
- wslh 3y ago
  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.
  - RajT88 3y ago
    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.

dataflow 3y ago

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

RajT88 3y ago
When InstallShield was founded in 1987 all companies were making their own installers. https://en.m.wikipedia.org/wiki/InstallShield https://en.m.wikipedia.org/wiki/InstallShield MSFT released MSI 1.0 in 1999. https://en.m.wikipedia.org/wiki/Windows_Installer 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.

booi 3y ago

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.

RajT88 3y ago
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.
- Qwertious 3y ago
  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.
- eviks 3y ago
  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
  - deleted 3y ago
    [deleted]

imperialdrive 3y ago

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

RajT88 3y ago
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!

throwaway2037 3y ago

Do you have any opinion about "Nullsoft Scriptable Install System" (NSIS)? Ref: https://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System https://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_Sy... I was always very impressed by it.

tzs 3y ago

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.

bemmu 3y ago
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.