I have used Linux for quite a while, and I always wondered how Windows was able to handle the programs depedencies like apt-get, aptitude, Pacman, yum and other package managers are able to. Sometimes, my package manager would tell me that this version of that library was needed for this package or that there would be some conflict.

How does Windows handle all of that stuff?

  • 2
    Windows doesn't handle version dependencies. Most version installers do. If you're not already familiar with it, check out InnoSetup: jrsoftware.org/isinfo.php
    – paulsm4
    Mar 23, 2014 at 20:48
  • 4
    It's probably worth noting that even in your examples, it's not Linux per se that is managing the dependencies - it's the package manager. Mar 24, 2014 at 16:56
  • 3
    How does Windows handle program dependencies? Badly, in my experience.
    – rlms
    Mar 24, 2014 at 22:35

5 Answers 5


It doesn't. Unless we're talking about .NET which asks you to install framework version X according with the compiler.

Everything else just throws an error. With luck, you get missing dll xxxx.dll. Although, most installers will have the required libraries included in order to run the software.

  • 6
    So it is up to the installer of each program to check for the depedencies? So if the installer sucks, you may not be able to use the program at all..
    – Nico
    Mar 23, 2014 at 18:55
  • Forgot to say, no, you can use then program, but you have to figure out which DLL or framework it needs. Mar 23, 2014 at 19:00
  • 9
    @Filipe So the fact that you have to install the V C++ runtime is the reason why you hate .NET software? Also Windows by default already has a .NET framework installed, so if you target the right version it will work out of the box. And the fact that you have to download and install missing shared objects really isn't limited to any particular software/language/framework for obvious reasons (you can have the same "problem" in *nix as well).
    – Voo
    Mar 24, 2014 at 1:39
  • 2
    @FilipeYaBaPolido: Your hate is particularly misplaced since the VC++2008 runtime is for C++ applications, not .Net applications. Obviously .Net applications need the .Net framework and C++ applications need the C++ framework(runtime), quite simple really. Now a particular software package may contain both C++ and .Net parts so the two are not exclusive.
    – MSalters
    Mar 24, 2014 at 13:18
  • 2
    Guys relax, I don't hate .Net or VC++. I even code in .Net/C# when needed, it's a tool. But I work with some different tools and see the differences. Sorry if I explained wrong. Mar 25, 2014 at 9:29

Edit 4/4/2014: Hey OP, look at what was just released today:


I just wanted to expand a little on the accepted answer, because it's a little sparse on details. Filipe's answer makes no mention of the strategies that Windows actually does use to resolve or mitigate program dependency issues, like the component store (WinSxS,) the global assembly cache, the MSI system, etc. But on the other hand he's basically right in the sense that it's the developer's responsibility to include any custom libraries with the app, and check for the existence of dependencies before committing to the install transaction.

Windows is less modular than Linux, which has positives and negatives. On the down side, Windows is more monolithic, meaning comparatively fewer components of the operating system are removable or optional like in Linux. (Though Windows is slowly getting better about that.)

But on the up side, that means developers are able to make a lot more assumptions about what libraries a user will already have present on his or her machine. And various versions of those libraries, once installed, will be stored side by side in the component store, so that you no longer have App1 barking about needing crapDLL.dll, and App2 barking about needing a different version of crapDLL.dll at the same time, etc.

  • Thanks Ryan. I know that I should elaborate my answer, but as English is not my primary language I still have some dificulties to express myself. Mar 23, 2014 at 21:45
  • Well described. I would, however, say it's getting significantly more modular on the server side -- core/gui-free options, role and feature based setup.
    – EricB
    Mar 24, 2014 at 19:48
  • I read this article this morning and it reminded me of this post. It's an entertaining, albeit tangential read on this topic: blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx
    – Ryan Ries
    Apr 12, 2014 at 15:36

In Windows it is up to the software author to provide versioning for their libraries. Windows has a few facilities to help with this.

The Windows Installer and the Trusted Installer services which interact with installation programs (.msi). There is also some supporting technology called Isolated Applications and Side-by-Side Assemblies that help sort out versioning conflicts.

For .NET framework applications there is the Global Assembly Cache, Strong-Named Assemblies, and at the core Manifests.

In Windows 8 and 8.1 there is the Windows App Store along with the Windows Runtime Library (win32 API replacement).

edit: At the core of most of these technologies are assembly manifests, embedded files that provide version numbers, authors, dependent assemblies and their versions, amongst other data.


The other answers did correctly point out that package management and OS are separate ideas but didn't mention a solution.

The most similar package management system to apt-get or yum on Windows would currently be Chocolatey. It allows people to install/uninstall packages(msi, exe, powershell scripts, ) and those packages can contain information about their dependencies that can be automatically resolved by Chocolatey.

The package usually contains a link to the binaries and scripts to manage the install process. The package can also contain the binaries or any other required files (dependencies should be in a separate package). Chocolatey can also use external package management systems like Microsoft's Web Platform Installer, Ruby Gems, Python and so on.

  • Absolutely! There are a handful of third-party package managers that also run on Windows. The only one I can name off the top of my head is NuGet, its a package/dependency manager for application developers built right into Visual Studio. That said I believe the question was more looking for how the operating system handles packages, where these solutions are more towards how a user might handle packages. Mar 25, 2014 at 12:05
  • Sorry I didn't include some information about Chocolatey. Chocolatey is based off of Nuget. Nuget and Nuspec are just a package of 'stuff' and a specification of dependencies. In the case of a software framework like .Net (ruby, node, ...) the dependencies are usually software components (dll, exe, js,...). Those are all components that an application uses. Mar 25, 2014 at 20:23
  • In Chocolatey's case though the package is an entire application or application dependency (app framework like java, .net, ruby). The Nuget package contains PowerShell scripts (optionally the installer too) that will manage the installation of the app and the Nuspec file describes the application and what dependencies it has e.g. Powershell depends on .Net. There is also Boxstarter which focus a level higher by describing a machine's configuration and what it depends on. Pretty neat stuff. Boxstarter gets into the realm of what people use Chef or Puppet for. Mar 25, 2014 at 20:28

From what I understand, the only dependencies handled by Windows are Microsoft specific libraries. If you install, as an example, an open source program in Windows like Blender, it will have the libavcodec and the ffmpeg libraries in its own separate dll files, and if you then install say, OpenShot, it will install its own copy of the libavcodec in its own directory, and they can be completely different versions. This can be a nightmare when uninstalling software to clean up the junk left behind, and it also takes up way more disk space with library redundancy.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .