I use several different bits of freeware and I’ve noticed that a lot of them (usually ones with a small dev. base, and/or supporting multiple OS’es) send you to a webpage to download an update. Others (e.g. notepad++) can download and launch the installer/updater themselves (i.e. without launching your web browser).
So, how much more work is the built-in updater?
It is not that hard to check for updates, and then download and execute a new installer, but it is work that the creator of a program may not have much expertise in. If someone is working on freeware, it probably is not that high on the list of priorities.
A lot of platforms (phones, linux distros with package managers) effectively outsource the “updating” feature of programs to external applications that specialize in that (e.g. rpm, apt). Windows is kind of an odd duck in still expecting programs to contain functionality to update themselves.
Windows Installer has been around since the Win95 era. But, like most MS software, isn’t all that well liked.
So, if people use someone’s installer, it’s usually InstallShield or some such. Note that many of these will/may build Windows Installer packages. That tells you what Windows Installer is like. You use another program to generate the packages.
Note that the best Windows installation programs are commercial. You have to reach a certain level of income to make it worthwhile to get a license, learn to use it, and make it a part of your company’s culture.
That’s debatable. I think NSIS is the best for straightforward application installation, and it’s completely open-source. Windows Installer is most suitable for stuff embedded within Windows itself.
It is quite variable.
It depends on how well the original code was written. There are methods for coding which make debugging, updating and actual operating better. Others noted that there are a few different packages to do it. But if you write bad spaghetti code. It is more difficult to code your update as well as install it. Though devices have so much power these days. Bad code and big updates, can still seem to go fast and smooth.
There are programs that can write and modify their own code on the fly.
I don’t think code quality has too much bearing on whether executables can download their own updates. It’s fundamentally an issue of just downloading the new version, and then swapping the files, and deleting your own on exit (or execution of the new one). If you want to be fancy you can build a patch file that’s smaller than an entirely new executable and do that, though in that case you likely need a small executable whose sole purpose is applying the patch and relaunching the executable.
The more difficult part is managing mirrors, verifying checksums, and other little things to ensure you don’t accidentally download a wrong file and otherwise making sure you don’t accidentally replace a working executable with a broken one.
It’s also somewhat easier if you don’t need to modify the executable much and a lot of things are done in a scripting language or in other external files like pictures or 3D models, this is why, e.g., Blizzard games can be run when only partially updated, their updater prioritizes files it absolutely needs to run and downloads art assets on the fly as it needs them.
While self-modifying programs exist, in practice they’re really hard to write due to compiler optimizations mucking with program structure in most languages. If you want to do such a thing you’re usually looking at assembly or some really ugly low-level C. You may have some luck trying to overwrite intermediate bytecode like Java has, but trying to dynamically rewrite your own program in higher-level compiled languages like Haskell, Rust, or Go is probably an exercise in frustration.
You can’t really update a program while it’s still running, so what they have to do is launch a separate updater program, close the main program, update the main program, and then relaunch the main program. And if the updater needs an update, well, the main program (or a third updater) does a similar process. None of that is very hard, though.
And small incremental updates (“delta patches” that only download the difference between v1.09 and v1.10 instead of redownloading the entire v1.10) have been around since the 90s or earlier via rtpatch in the Windows world and rsync in the *NIX world.
Today, the standard practice for the *NIX world is to let package managers handle the updates. For OSX it’s the App Store, for Windows it’s the Windows Store (I think?). They handle all the downloads and patches etc. for you, the same way the Play Store or App Store on your phone does.
The legacy (meaning old, non-best-practice) apps out there still use their ancient update schemes, which are usually just “download the entire program over again from our website or FTP because we’re lazy”. It certainly doesn’t have to be that way, but that’s often the easiest for lazy programmers. Microsoft has improving the update process even before the Windows Store using their ClickOnce technology, but Windows being what it is (super-popular and used across the world), very few programmers followed their best practices and just did their own things, usually the “laziness wins” methods above.
Where efficient updates really matter are big files that are distributed to millions of users, things like MMO games. In those cases, not only do they only update changed files, they will make users send each bits and pieces. User A has 50% of a new file, he’ll send that 50% to user B while user C sends both of them another 25% and users D, E, F each send them another 5%. (That’s how Bittorrent works, too.).
None of this is very hard. There are usually documented, encouraged, best practices for every operating system, or failing that, a bunch of third-party software update and patching solutions that can be integrated into your software. Too many small business and indie programmers just don’t care because by the time you’re updating someone’s software, you already have their money. And bandwidth is cheap as heck unless you have millions of users. With limited development resources, they probably prefer to spend time improving the actual programs rather than the update processes behind them…
Last I checked Blizzard’s updater was literally a modified Bittorrent client. In the old World of Warcraft updater you used to even be able to see and set most typical Bittorrent information (swarm health, peers, max upload/download rates etc) if you dug around in the options, but at a glance the new Battle.net client doesn’t have those menus. Since then, they appear to have grafted a priority system onto it where it grabs more important files first.
Steam, interestingly, doesn’t do this despite the fact that you’d think they’d benefit a lot from it given their userbase.
You can really update a program while it’s running. It’s generally not done to update monolithic executable images because it’s not necessary and it requires carefully planned and controlled structure to do it. It is done frequently to update software that has discreet loosely coupled sub-components. It is also done very easily in systems that interpret an intermediate code as long as you don’t update the interpreter. Even then you could have a transparent transfer of the interpreter control to a new version that doesn’t overwrite the original. Aside from updating intermediate code these techniques are rarely used because the results aren’t worth the extra complexity.
How would you do that? Unload files from disk, load only part of the program into memory, write new updater unpacker thing to another part of the memory, run that, unload the original, write new files, etc.? 
Without ridiculous levels of complexity you will load new code into memory separate from the original code that is running. When it’s completely loaded the old code transfers control to the new code. It doesn’t matter what part of the code that is, the main software functionality, updaters, unpackers, whatever. This gets much easier if the software consists of loosely coupled modules that interact through messaging. I work on high availability systems, we can update massive systems with intermediate code updates without any additional work. We update the loosely coupled modules on the fly with only a small amount of intervention to quiesce running modules or stop interprocess communications. We don’t bother attempting to update the core object module on the fly because it’s just not practical or necessary.
Eeks. That sounds horrendous. I don’t envy your job!
You shouldn’t envy my job, but this area isn’t the biggest headache. Well not entirely by itself, it does turn into a much bigger problem when you add mirroring and fail-overs into the process.
In the Linux universe, doing upgrades while still running is the ideal. In some cases you can even upgrade the kernel without rebooting!
Windows is very, very different. It’s not just the core programs that need updating, but registry entries, things tucked away in various application data directories and on and on.
One particularly worrisome thing is updating a dll. Your new version requires a certain version of a dll that needs to go into the system32 directory or some such. There’s a different version there. It’s currently in use by another program. So you set it up to be replaced at the next reboot. Etc.
But of course the other program needs the other version of the dll and Pure Fun ensues.
Here’s a video showing an update of a live system being done in the 80s. The dudes in polyester suits fix a broken conferencing feature without dropping a normal call. Erlang is specifically set up for that kind of tinkering, whereas programs written for other platforms in other languages are not.
Of course, programs written in JavaScript that run in a web browser update so frequently that we think of the times that they don’t automatically update as a special “caching” case.
It’s also irrelevant to the actual question. It doesn’t handle checking for updates on a remote server or downloading files. Either method (app downloads update package in the background for you, or forces you to go to a website yourself and download an update package) might be using an .msi file as the package method.
This takes me back to my mainframe days. Stuff just worked, y’know? 
I can attest to this. I have successfully installed patches by hand in the device drivers of running Unix kernels … while they were accessing the very disks whose driver I was modifying.
But that was in earlier days, when my hair was all dark-colored and down to my shoulders, and fellow geeks swooned at the derring-do.
This is not how I read the OP. It is quite relevant, IMO.
The OP isn’t clear. It discusses software that initiates it’s own updates and software that requires manual intervention to update. It also brings into the mix the ‘updater’, software that loads and installs the update. Some software is performing that function. The new software must be downloaded from an external source, it may or may not include new updater software. The advantage of providing a new updater is that it’s not limited by the functionality of existing installed software so the methodology can change with each new update. Whether or not the updating process is initiated automatically doesn’t matter though.