I am a beginner in computer programming with C/C++. I have previous experience in programming for the web. There is some confusion that I am having with the software development process in desktop applications.

Web applications are easy to upgrade because it is basically a bunch of source files, but I have a question about desktop applications. The major thing I notice about desktop applications is that they are released in different versions. This requires the user to go through the uninstall/re-install process in order to obtain a newer version of the software.

In C/C++ software for various platforms, how would a programmer implement an "upgrade" option that would allow a user to update an already installed application without having to go back to a website. How hard is it to upgrade an executable file on platforms like Windows and Linux. I understand that the process may be different for different platforms.

Say, for example, I have a desktop application (version 1) that the user has already downloaded and installed onto their own PC. After a while, I make some changes to the software and make improvements that the user would want applied to their software. The user has made customizations to the software, but would like to upgrade to version 2 without having to re-customize their application all over again. Originally, I thought that an "upgrade" feature would replace certain parts of an executable file, but is that really what you would have to do?

My main question is: How exactly would someone go about accomplishing this "upgrade" process? Is it possible?

closed as too broad by Michael Durrant, user40980, gnat, Ampt, Kilian Foth Sep 15 '14 at 10:07

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I like the question but ovting to close as too broad - the question is how do you do manage versions in software development and there are just too many answers to that, the best being "it depends". – Michael Durrant Sep 13 '14 at 22:22
  • @MichaelDurrant: I think the question is pretty answerable. – Doc Brown Sep 13 '14 at 22:25
  • Desktop applications are delivered as compiled executables. So you want to have some installation process in your build. For free software on Linux coded in C++, their Makefile often has an install target. You'll learn a lot by building some free software from their source code. – Basile Starynkevitch Sep 14 '14 at 9:17
  • What kind of desktop application coded in C++ are you thinking of? – Basile Starynkevitch Sep 14 '14 at 9:33
  • Why do you believe that web applications are easy to upgrade? Many major Web corporations (Google, Facebook, Tweeter, LinkedIn, ...) have entire teams devoted to upgrade these! – Basile Starynkevitch Sep 14 '14 at 10:20

Upgrading software which is packaged is complex and is best done with a software installation tool. This is a classic case of build vs. buy. You couldn't build something yourself that does the job of InstallShield, for example.

Upgrading software which has been customized is a very tricky proposition. In general this is next to impossible to do in an automated way.

If you knew in advance that some kinds of customization needed to be supported, you could architect your application to have features that are modular in nature. Perhaps a plugin architecture or some method of table driven logic configuration. In this kind of scenario you can automate the replacement of your application's core without disturbing the modules or data stores that contain the customizations.

This type of customization must necessarily be limited in nature. Some kinds of changes that you might eventually want to make to your core application are bound to break even the most carefully planned and isolated user configurations/customizations.

If you build package software and also perform customizations on that software, then you are sooner or later going to have to either branch your code and let some customers live with the old version or you're going to have to reapply some customizations. Just ask anybody who has bought a major ERP like SAP.

  • Say, for example I take your advice and design the software in a modular way. I develop a "core application" that allows the user to install "modules" that will complement the "core application". I develop a core application that the user can customize. The modules exchanges data with the user, which is saved to the cloud, and then the results are presented on the core application. How difficult would you think it would be to upgrade the modules independently of the "core application"? – Jacob Perkins Sep 13 '14 at 22:36
  • 1
    @user3672098 - It all comes down to how many variations or bases for flexibility you can pre-conceive and plan for. It may be possible to have a stable core or to define an inter-module interface which doesn't need to know too much about what it's passing in and out of the core, but sooner or later you're going to come to a breaking change. This is a case of reducing, not eliminating the need for reapplying customizations. In the real world, a lot of organizations who have customized software live with it for a long time and upgrading becomes a huge project. – Joel Brown Sep 13 '14 at 22:43

You are probably using customized in a wrong way. The desktop application (coded in C++, and distributed as a packaged binary executable) has not been customized, but user configured.

Customizing a desktop application means that some developer (internal to -or subcontractor of- the company where that application is used) has gotten, studied, and improved the desktop application's source code. This is uncommon and very costly.

You should ensure that the user configuration (e.g. preferences) are compatible from one version to the next (perhaps by having a functionality to transform that configuration).

Some (rare) applications indeed can be "customized" thru plugins (on Linux the application would dlopen(3) some shared object at runtime, during startup). If your application can have plugins, the plugins need to be written by a professional programmer (not by the random user), and you should have carefully designed and documented a good plugin interface. If you change that interface old plugins won't work with newer versions of your software.

Other applications embed a scripting language interpreter (like e.g. Lua or Guile). This is a very strong design decision and you should decide that before even starting coding your application.

Upgrading a software while it is still running is a research subject (and is never done for desktop applications). Read about persistence, continuation, calll stack, software package...

Notably on Linux, study the source code of some free software applications. It will teach you a lot.

Not the answer you're looking for? Browse other questions tagged or ask your own question.