24

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?

Léon Pelletier
  • 107
  • 7
Nico
  • 429
  • 5
  • 12
  • 2
    Windows *doesn't* handle version dependencies. Most version installers do. If you're not already familiar with it, check out InnoSetup: http://www.jrsoftware.org/isinfo.php – paulsm4 Mar 23 '14 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. – GalacticCowboy Mar 24 '14 at 16:56
  • 3
    How does Windows handle program dependencies? Badly, in my experience. – rlms Mar 24 '14 at 22:35

5 Answers5

40

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

http://blogs.technet.com/b/windowsserver/archive/2014/04/03/windows-management-framework-v5-preview.aspx

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.

Ryan Ries
  • 55,481
  • 10
  • 142
  • 199
  • 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. – Filipe YaBa Polido Mar 23 '14 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 '14 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: http://blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx – Ryan Ries Apr 12 '14 at 15:36
30

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.

Peter Mortensen
  • 2,318
  • 5
  • 23
  • 24
Filipe YaBa Polido
  • 506
  • 5
  • 16
  • 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 '14 at 18:55
  • Forgot to say, no, you can use then program, but you have to figure out which DLL or framework it needs. – Filipe YaBa Polido Mar 23 '14 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 '14 at 01: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 '14 at 13:18
  • I should note that if you static-link your program, it will work out of the box. Since most programs only use a few runtime functions, it will also be faster and smaller. – Navin Mar 25 '14 at 00:38
  • @Navin, I would doubt the smaller claim because the runtime is almost certainly already in memory due to another application. – Joey Mar 25 '14 at 05:56
  • 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. – Filipe YaBa Polido Mar 25 '14 at 09:29
  • @Joey I meant that the installer has to include the runtime dlls, which will make the package larger. (or worse yet, expect the user to do it themselves) – Navin Mar 25 '14 at 20:15
9

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.

Goldfish Sandwich
  • 201
  • 2
  • 6
6

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.

AllenSanborn
  • 161
  • 2
  • 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. – Goldfish Sandwich Mar 25 '14 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. – AllenSanborn Mar 25 '14 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. – AllenSanborn Mar 25 '14 at 20:28
0

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.

Jeff
  • 1