User setup for Windows

Announced last release, the user setup package for Windows is now available on stable. Installing the user setup does not require Administrator privileges as the location will be under your user Local AppData (LOCALAPPDATA) folder. User setup also provides a smoother background update experience.

Download User Setup

If you are a current user of the system-wide Windows setup, you will be prompted to install user setup, which we recommend using from now on. Don't worry, all your settings and extensions will be kept during the transition. During installation, you will also be prompted to uninstall the system-wide setup.

Reference: https://code.visualstudio.com/updates/v1_26#_user-setup-for-windows

What you're really asking is:

How does an installer work?

A bit of background.

In the Before Times, man did not have such things as "installers." Software was run directly off of floppy disks (and none of that rigid 3.5" crap, I'm talking disks that flopped), like God intended.

Then came the first home computers with persistent hard drives. For the first time, it made sense to copy a program off a disk and have it stick around.

But programs still worked the way "portable" applications do today: you copied them as-is and ran them as-is.

Then operating systems began to get more complicated.

Windows introduced this notion of a registry: a central location where program and operating system configuration could be stored. Software authors began using this registry. Its arcane architecture and user-hostile editing utility (the infamous regedit.exe) made it the perfect place to store shareware information -- how many days you have left on your trial, for example.

This happened around the same time that programs began to be too large to fit -- uncompressed -- on a single floppy disk. A way was needed to split a program onto multiple disks. Since it wasn't very user-friendly to require the user to have e.g. a ZIP extractor installed (remember, this was before ubiquitous Internet), Windows programs began to be shipped with installers. You can think of these as basically portable versions of WinZIP whose sole purpose was to reassemble and extract a compressed file.

These days, installers serve a number of other purposes:

• providing a convenient user interface
• prompting the user to accept a click-through end-user license agreement (EULA)
• prompting the user for CD keys (though this is being phased out for many systems in favor of digital distribution)
• asking the user to register their software

and so on. They may also serve as DRM vehicles, validating CDs and decrypting data to prevent villainous individuals (yarr) from brrreakin' ye olde DMCA.

At their heart, they aren't any more complex than in the Windows 95 days -- a glorified unzip program.

Sidenote: Where does the installer get 5GB of data from 200MB of archives if not the Internet?

That's high, though there are plenty of ways you could get that compression ratio. Imagine a complex game whose world is defined in verbose XML -- that's readily compressible. You could even get that back in the old WinZIP days.

If you have the choice of both; the installer typically just means that you get a nicer UI to choose the setup directory and some installation options, rather than having to use a seperate unzip utility and selectively remove the parts you don't want/need. Also, in the case of Windows programs an installer may also add entries to the registry (user selected options, key validation, other random stuff) which you won't get with a zip.

As Journeyman Greek said in his post, zip package is better for standalone 'installs' where you want portability and don't want to be tied down to a particular machine. This is because .zip naturally won't make any changes to registry, so unless they give you a .reg file to click on (very unlikely) it means that the entire directory is self-contained including any local .ini files.

Personally I prefer downloading the installer in general; because I get any customization options and it will setup any registry entries automatically as well.

I would assume the user setup will install for the local user only, without the need for administrator privileges, whereas the none user setup will install for all users on the system, however it will require administrator privileges.

The .msi uses the Microsoft Windows Installer format which is included with Windows itself, you can install VSCodium as a local user or for all users, the latter of which requires administrator privileges. The Microsoft Windows Installer format theoretically is better for compatibility with past and future versions of Windows however it can limit what the developer can do during the installation process. For VSCodium it won't make a difference which installer you choose to use because as far as I'm aware the installation of VSCodium doesn't require anything terribly unique.

For simplicities sake, you can think of .msi files as installation files that provide Windows the information to install and manage a piece of software, whereas executables can be just that, executable files that could do anything, they're not limited to software installation however some do provide a delivery of self managed software installation.

Basically a user install doesn't require admin rights. This means if you want to use VSCode on your work computer you don't need to get IT to install it.

It should still show up in the start menu. Assuming you selected the option in the installer it should have a shortcut somewhere in

%appdata%\Microsoft\Windows\Start Menu\Programs`

Finally Microsoft does provide a system install version that sounds like what you are looking for. It's located on the download page: https://code.visualstudio.com/Download

The installer is typically there to make things easier for the end user. It does some combination of the following:

• Unzipping
• Creation of directories
• Installation of required runtimes (redistributable like: .Net, Visual C++, Direct x)
• Registration with the OS (for later clean uninstall)
• Display beautiful, beautiful screenshots to prepare the player for your game while it works.
• Offering the user the chance to register their game
• Downloading updates for the assets or patches for the game
• Add icons to the start menu or the desktop
• Set correct permissions for various game directories (temp folder, save directory, etc.)
• Just install it already, allow the user to mindlessly click next and get to playing the game!

Both versions of blender have the same functionality, features, plugins, etc.

The main difference is that the Zip file does not get installed in the system as a program, meaning that the executable files are not in the programs folder, the application does not appear on the start menu, or as part of the programs menu. Also the operating system will not associate .blend files to open with blender automatically.

The zip file can be extracted to any folder you want, and the contained blender.exe program can be run from there. It can even be executed from an external drive, so that it can also be run on computers where the user has no access to modifying the operating system (in schools, public computers, your parent's computer, etc).

The zip file allows you to use different versions of the program, whereas the installed version will use only the latest one installed.

The files used on the zip file don't need to be uninstalled from the system, you can simply delete the containing folder.

To uninstall the .msi file you need to use the OS uninstall tools.

There are several reasons why programs come as installers rather than standalone executables:

File Size Concerns

• Programs with many, large dependencies can bundle Web-based installers that download the dependencies and place them in a common location, so that they can be shared by multiple programs. For example, DirectX is a very large library. If every single program on your system that depends on DirectX just bundled the entire DirectX runtime with it, it would consume a good bit of space. This may not seem to matter in the age of 4 TB hard disks, but consider that SSDs are quite a lot smaller in capacity, and they're coming into common use on ultrabooks, some with as little as 64 GB of storage. And of course there are many other shared libraries aside from DirectX.

• Programs that are both very large and continuously updated are best distributed as a collection of many small files, along with a launcher or updater program that checks the Internet for an update, and if any update exists, only download the required changes. If all large programs were shipped as a single monolithic executable, it is very likely that the patch process would require re-downloading the entire executable, as patching the running executable file on disk is near impossible due to file locks. Also, because the updater needs to know where its files are, it often stores that directory path in a well-known location in the registry.

User Convenience Concerns

• Installers for very large programs, such as Visual Studio and Microsoft Office, allow the user to de-select the installation of certain features, if the user knows they will never need them. This has 3 potential benefits: it reduces disk space consumption; it can reduce download time and bandwidth consumption if the installer is a web downloader; and it can reduce "clutter" and "bloat" on the user's machine, fewer start menu / desktop shortcuts, fewer startup programs, etc.

• Installers for complicated programs often come with configuration options that the user can set up using a user-friendly graphical interface as part of the installer. See for example the MySQL or SQL Server installers, which can take you through the entire process of getting your database server up and running before you even click "Finish" on the installer.

• Installers can prompt the user for required information, such as license keys, which only need to be entered once. This can simplify the design of the program itself, and reduce the number of things it has to do and check for when it starts up. This also results in the user having confidence that, once the program is successfully installed, it should "just work" -- there are no more "gotchas" within the program that may hold them up from using it.

Compatibility Concerns

• Some programs conflict with other programs. This is a simple and unfortunate fact of software engineering. Before installing a program that has known conflicts with other programs, it is often helpful to first check the system to see whether an incompatible program is installed. The user can then be alerted if so. For example, there is a very dangerous incompatibility potential in older versions of VMware and VirtualBox, that resulted in a Blue Screen of Death, because one program would try to use a special virtualization processor instruction after it was already reserved for user by the other product. If you were to simply provide the end product to the user without an installer, you would have to check for the presence of incompatible products at every start of your program, which could slow down the startup of the program.

• Programs may have dependencies on other system components that can only be installed at a system-wide level, not at a per-user level. In order to install these special system components, administrative privileges are usually required, and an installer usually has to be run.

Elevated privileges and special services

• Some programs depend on changes to the operating system for their functionality, and these changes can't easily be implemented without some kind of installer to take care of them with administrative privileges. For instance, programs that install drivers or kernel modules, such as Wireshark, can't simply be run, because you absolutely have to ship the kernel-mode components in separate files. In the absolute best case, you would still have to have the user manually unzip an archive, and then run some kind of installer for the device driver. Services are another example of something that requires administrative privileges to install. Installer software is particularly good at obtaining admin rights in an elegant way, without requiring that the main program itself request admin rights every time it runs (this would be an unnecessary security exposure in many cases).

Having given all these reasons for why installers are useful, here are a few observations from the other side:

• Many programs, even those that are only available for download as an installer that requires admin privileges, can be forcibly "unpacked" from their installers and run directly without installing them. Other programs, especially open source ones, are repackaged into self-contained executables by PortableApps. It is noteworthy that some programs, when unpacked from their installer, will have reduced functionality, exhibit errors, or other problems.

• On operating systems other than Windows, it is almost always possible to simply download (or compile) programs and run them as a regular user, without obtaining root. There are a few exceptions with respect to packages that are a core part of the operating system, but for most user applications, you can run it in your home directory without installing it system-wide using the package manager. Windows is a bit of a special case in that most desktop programs on Windows have an installer, and can usually not be installed any other way.

• Even on non-Windows platforms, programs that need the ability to load a kernel module come with some sort of installer, which compiles the kernel module and installs it in the right directory. You can also expect to see an installer in the event that the program is a daemon that will be started using a system service script, e.g. in /etc/init.d. This type of "shrinkwrapped binary" is a less common distribution method on GNU/Linux, but most Linux distributions still provide most software in the form of installable packages, each of which requires root access (admin access) to install.

Conclusions

You asked why we need installers. The short answer is that we don't -- not strictly speaking, anyway. There are vanishingly few examples of applications that cannot, in principle, be bundled into a single self-contained executable with no resources, no installer, etc. Even something as complicated as VMware Workstation could automatically obtain admin privileges, write the hypervisor kernel module out to a file on disk, and install it dynamically on program startup, and ship all of its resources (images, sounds, etc.) bundled inside the data section of the executable.

Using an installer or not is a choice that software producers have to make. There are advantages and disadvantages to using an installer. Many vendors choose to distribute their software both as an installer, and as a standalone binary, or at least as a ZIP file that can simply be unpacked and run. For software that does not absolutely require an installer, this is a very pragmatic way to go, and makes everyone happy. Usually, software that does not ship in any other form than with an installer is software that requires administrative privileges to install some component of itself, since the installer is the most elegant way to obtain the needed privileges.

Personally, I find installers very annoying in my day to day work, because sometimes I want to run a program when I don't have administrative rights on the computer I'm using. I have quite a bit of experience manually unpacking installers to extract the program files within, and then getting those files to run correctly. However, on my personal PC at home where I always have administrative access, I find installers beneficial and convenient, because most installers give me useful options, like whether to create a desktop shortcut, that I would have had to do manually instead without it.

What you're really asking is:

How does an installer work?

A bit of background.

In the Before Times, man did not have such things as "installers." Software was run directly off of floppy disks (and none of that rigid 3.5" crap, I'm talking disks that flopped), like God intended.

Then came the first home computers with persistent hard drives. For the first time, it made sense to copy a program off a disk and have it stick around.

But programs still worked the way "portable" applications do today: you copied them as-is and ran them as-is.

Then operating systems began to get more complicated.

Windows introduced this notion of a registry: a central location where program and operating system configuration could be stored. Software authors began using this registry. Its arcane architecture and user-hostile editing utility (the infamous regedit.exe) made it the perfect place to store shareware information -- how many days you have left on your trial, for example.

This happened around the same time that programs began to be too large to fit -- uncompressed -- on a single floppy disk. A way was needed to split a program onto multiple disks. Since it wasn't very user-friendly to require the user to have e.g. a ZIP extractor installed (remember, this was before ubiquitous Internet), Windows programs began to be shipped with installers. You can think of these as basically portable versions of WinZIP whose sole purpose was to reassemble and extract a compressed file.

These days, installers serve a number of other purposes:

• providing a convenient user interface
• prompting the user to accept a click-through end-user license agreement (EULA)
• prompting the user for CD keys (though this is being phased out for many systems in favor of digital distribution)
• asking the user to register their software

and so on. They may also serve as DRM vehicles, validating CDs and decrypting data to prevent villainous individuals (yarr) from brrreakin' ye olde DMCA.

At their heart, they aren't any more complex than in the Windows 95 days -- a glorified unzip program.

Sidenote: Where does the installer get 5GB of data from 200MB of archives if not the Internet?

That's high, though there are plenty of ways you could get that compression ratio. Imagine a complex game whose world is defined in verbose XML -- that's readily compressible. You could even get that back in the old WinZIP days.