Reply
 
Thread Tools Display Modes
  #1  
Old 07-20-2016, 11:50 AM
dstarfire dstarfire is offline
Member
 
Join Date: Oct 2009
Location: Tacoma, WA; USA
Posts: 1,245
How difficult is it to update a program from within that program?

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?
Advertisements  
  #2  
Old 07-20-2016, 12:01 PM
leahcim leahcim is offline
Member
 
Join Date: Dec 2010
Location: Boulder, CO
Posts: 3,483
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.
  #3  
Old 07-20-2016, 03:35 PM
ftg ftg is online now
Guest
 
Join Date: Feb 2001
Location: Not the PNW :-(
Posts: 15,690
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.
  #4  
Old 07-20-2016, 03:56 PM
gnoitall gnoitall is offline
Guest
 
Join Date: Jul 2009
Posts: 4,991
Quote:
Originally Posted by ftg View Post
Note that the best Windows installation programs are commercial.
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.
  #5  
Old 07-20-2016, 07:49 PM
Kedikat Kedikat is offline
Guest
 
Join Date: Aug 2014
Posts: 348
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.

Last edited by Kedikat; 07-20-2016 at 07:51 PM.
  #6  
Old 07-20-2016, 08:05 PM
Jragon Jragon is offline
Guest
 
Join Date: Mar 2007
Location: Miskatonic University
Posts: 10,257
Quote:
Originally Posted by Kedikat View Post
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.

Last edited by Jragon; 07-20-2016 at 08:07 PM.
  #7  
Old 07-20-2016, 09:54 PM
Reply Reply is offline
Guest
 
Join Date: Jul 2003
Location: Chicago
Posts: 8,239
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...
  #8  
Old 07-20-2016, 10:00 PM
Jragon Jragon is offline
Guest
 
Join Date: Mar 2007
Location: Miskatonic University
Posts: 10,257
Quote:
Originally Posted by Reply View Post
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.).
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.
  #9  
Old 07-20-2016, 10:29 PM
TriPolar TriPolar is online now
Guest
 
Join Date: Oct 2007
Location: rhode island
Posts: 36,984
Quote:
Originally Posted by Reply View Post
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.
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.

Last edited by TriPolar; 07-20-2016 at 10:30 PM.
  #10  
Old 07-20-2016, 10:40 PM
Reply Reply is offline
Guest
 
Join Date: Jul 2003
Location: Chicago
Posts: 8,239
Quote:
Originally Posted by TriPolar View Post
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.?
  #11  
Old 07-20-2016, 10:56 PM
TriPolar TriPolar is online now
Guest
 
Join Date: Oct 2007
Location: rhode island
Posts: 36,984
Quote:
Originally Posted by Reply View Post
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.
  #12  
Old 07-20-2016, 11:03 PM
Reply Reply is offline
Guest
 
Join Date: Jul 2003
Location: Chicago
Posts: 8,239
Quote:
Originally Posted by TriPolar View Post
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!
  #13  
Old 07-20-2016, 11:21 PM
TriPolar TriPolar is online now
Guest
 
Join Date: Oct 2007
Location: rhode island
Posts: 36,984
Quote:
Originally Posted by Reply View Post
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.
  #14  
Old 07-21-2016, 08:30 AM
ftg ftg is online now
Guest
 
Join Date: Feb 2001
Location: Not the PNW :-(
Posts: 15,690
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.
  #15  
Old 07-21-2016, 08:33 AM
leahcim leahcim is offline
Member
 
Join Date: Dec 2010
Location: Boulder, CO
Posts: 3,483
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.
  #16  
Old 07-21-2016, 08:40 AM
andrewm andrewm is offline
Guest
 
Join Date: Apr 2010
Posts: 429
Quote:
Originally Posted by ftg View Post
Windows Installer has been around since the Win95 era. But, like most MS software, isn't all that well liked.
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.
  #17  
Old 07-21-2016, 12:23 PM
Baron Greenback Baron Greenback is offline
Member
 
Join Date: Jul 2006
Location: Scotland
Posts: 10,566
Quote:
Originally Posted by TriPolar View Post
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.
This takes me back to my mainframe days. Stuff just worked, y'know?
  #18  
Old 07-21-2016, 12:33 PM
septimus septimus is offline
Guest
 
Join Date: Dec 2009
Location: The Land of Smiles
Posts: 14,418
Quote:
Originally Posted by TriPolar View Post
You can really update a program while it's running.
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.
  #19  
Old 07-22-2016, 11:33 AM
ftg ftg is online now
Guest
 
Join Date: Feb 2001
Location: Not the PNW :-(
Posts: 15,690
Quote:
Originally Posted by andrewm View Post
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 is not how I read the OP. It is quite relevant, IMO.
  #20  
Old 07-22-2016, 11:47 AM
TriPolar TriPolar is online now
Guest
 
Join Date: Oct 2007
Location: rhode island
Posts: 36,984
Quote:
Originally Posted by ftg View Post
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.
  #21  
Old 07-22-2016, 11:48 AM
leahcim leahcim is offline
Member
 
Join Date: Dec 2010
Location: Boulder, CO
Posts: 3,483
There is a whole security issue, too. Updating an application means connecting to the internet, downloading a verifying an executable or a patch, and running that executable with permissions to install software. That is vastly beyond the permissions that most applications would need otherwise. Do you really trust every single program on your computer to have that kind of power?

That's why installers/updaters like apt and Google Play are a better model for updating then having each program update itself. A small number of trusted programs get the "god permissions" instead of every program.
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 04:26 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

Send questions for Cecil Adams to: cecil@chicagoreader.com

Send comments about this website to: webmaster@straightdope.com

Terms of Use / Privacy Policy

Advertise on the Straight Dope!
(Your direct line to thousands of the smartest, hippest people on the planet, plus a few total dipsticks.)

Publishers - interested in subscribing to the Straight Dope?
Write to: sdsubscriptions@chicagoreader.com.

Copyright 2017 Sun-Times Media, LLC.

 
Copyright © 2017