Como o Windows lida com as dependências do programa?

23

Eu uso o Linux há algum tempo, e sempre me perguntei como o Windows era capaz de lidar com as deficiências de programas como apt-get , aptitude , Pacman , yum e outros gerenciadores de pacotes. Às vezes, meu gerente de pacotes dizia que essa versão dessa biblioteca era necessária para este pacote ou que haveria algum conflito.

Como o Windows lida com tudo isso?

windows package-management

— Nico
fonte

2

O Windows não lida com dependências de versão. A maioria dos instaladores de versões faz. Se você ainda não está familiarizado com isso, consulte InnoSetup: jrsoftware.org/isinfo.php

— paulsm4

4

Provavelmente vale a pena notar que, mesmo nos seus exemplos, não é o Linux em si que gerencia as dependências - é o gerenciador de pacotes.

— GalacticCowboy

3

Como o Windows lida com as dependências do programa? Mal, na minha experiência.

— Rlms

29

Não faz. A menos que falemos do .NET, que solicita a instalação da versão X do framework de acordo com o compilador.

Tudo o resto gera um erro. Com sorte, você consegue missing dll xxxx.dll. Embora, a maioria dos instaladores tenha as bibliotecas necessárias incluídas para executar o software.

— Filipe YaBa Polido
fonte

6

Portanto, cabe ao instalador de cada programa verificar as impedâncias? Portanto, se o instalador for péssimo, talvez você não consiga usar o programa.

— Nico

Esqueci de dizer que não, você pode usar o programa, mas precisa descobrir qual DLL ou estrutura ele precisa.

— Filipe YaBa Polido

9

@Filipe Então, o fato de você precisar instalar o tempo de execução do V C ++ é a razão pela qual você odeia o software .NET? Por padrão, o Windows já possui uma estrutura .NET instalada; portanto, se você direcionar a versão correta, ela funcionará imediatamente. E o fato de você precisar baixar e instalar objetos compartilhados ausentes não se limita a nenhum software / idioma / estrutura em particular por razões óbvias (você também pode ter o mesmo "problema" no * nix).

— Voo

2

@FilipeYaBaPolido: Seu ódio é particularmente equivocado, pois o tempo de execução do VC ++ 2008 é para aplicativos C ++, não para aplicativos .Net. Obviamente, os aplicativos .Net precisam da estrutura .Net e os aplicativos C ++ precisam da estrutura C ++ (tempo de execução), realmente bastante simples. Agora, um pacote de software específico pode conter partes C ++ e .Net, portanto, as duas não são exclusivas.

— MSalters

2

Caras relaxem, eu não odeio .Net ou VC ++. Eu até codifico .Net / C # quando necessário, é uma ferramenta. Mas trabalho com algumas ferramentas diferentes e vejo as diferenças. Desculpe se eu expliquei errado.

— Filipe YaBa Polido

40

Editar 04/04/2014: Hey OP, veja o que foi lançado hoje:

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

Eu só queria expandir um pouco a resposta aceita, porque é um pouco esparsa nos detalhes. A resposta de Filipe não faz menção das estratégias que o Windows realmente faz uso para a resolver problemas ou dependência programa mitigar, como o armazenamento de componentes (WinSxS), o cache de assemblagem global, o sistema MSI, etc. Mas, por outro lado ele é basicamente bem no sinta que é responsabilidade do desenvolvedor incluir qualquer biblioteca personalizada no aplicativo e verificar a existência de dependências antes de confirmar a transação de instalação.

O Windows é menos modular que o Linux, que possui pontos positivos e negativos. Por outro lado, o Windows é mais monolítico, o que significa que comparativamente menos componentes do sistema operacional são removíveis ou opcionais, como no Linux. (Embora o Windows esteja lentamente melhorando sobre isso.)

Mas, no lado positivo, isso significa que os desenvolvedores podem fazer muito mais suposições sobre quais bibliotecas um usuário já terá presente em sua máquina. E várias versões dessas bibliotecas, uma vez instaladas, serão armazenadas lado a lado no armazenamento de componentes, para que você não tenha mais o App1 latindo sobre a necessidade de crapDLL.dll e o App2 latindo sobre a necessidade de uma versão diferente do crapDLL.dll ao mesmo tempo. hora, etc.

— Ryan Ries
fonte

Obrigado Ryan. Sei que devo elaborar minha resposta, mas como o inglês não é minha língua principal, ainda tenho algumas dificuldades para me expressar.

— Filipe YaBa Polido 23/03

Bem descrito. No entanto, eu diria que está ficando significativamente mais modular no lado do servidor - opções sem núcleo / gui, configuração baseada em funções e recursos.

— EricB

Eu li este artigo esta manhã e me lembrou deste post. É um divertido, embora leitura tangencial sobre este tema: blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx

— Ryan Ries

9

No Windows, cabe ao autor do software fornecer versões para suas bibliotecas. O Windows possui alguns recursos para ajudar nisso.

Os serviços Windows Installer e Trusted Installer que interagem com os programas de instalação (.msi). Há também alguma tecnologia de suporte chamada Aplicativos Isolados e Conjuntos Lado a Lado que ajudam a resolver conflitos de versão.

Para aplicativos de estrutura .NET, há o Global Assembly Cache, Strong-Named Assemblies e os principais Manifests.

No Windows 8 e 8.1, há a Windows App Store junto com a Windows Runtime Library (substituição da API do win32).

editar: No centro da maioria dessas tecnologias estão manifestos de montagem, arquivos incorporados que fornecem números de versão, autores, montagens dependentes e suas versões, entre outros dados.

— Sanduíche de peixe dourado
fonte

6

As outras respostas apontaram corretamente que o gerenciamento de pacotes e o SO são idéias separadas, mas não mencionaram uma solução.

O sistema de gerenciamento de pacotes mais semelhante ao apt-get ou yum no Windows seria atualmente o Chocolatey . Ele permite que as pessoas instalem / desinstalem pacotes (scripts msi, exe, powershell) e esses pacotes podem conter informações sobre suas dependências que podem ser resolvidas automaticamente pelo Chocolatey.

O pacote geralmente contém um link para os binários e scripts para gerenciar o processo de instalação. O pacote também pode conter os binários ou outros arquivos necessários (as dependências devem estar em um pacote separado). O Chocolatey também pode usar sistemas externos de gerenciamento de pacotes, como o Web Platform Installer da Microsoft , Ruby Gems, Python e assim por diante.

— AllenSanborn
fonte

Absolutamente! Existem alguns gerenciadores de pacotes de terceiros que também executam no Windows. O único que eu posso citar em primeiro lugar é o NuGet, um gerenciador de pacotes / dependências para desenvolvedores de aplicativos embutido no Visual Studio. Dito isso, acredito que a pergunta estava mais procurando como o sistema operacional lida com pacotes, onde essas soluções são mais direcionadas para como um usuário pode lidar com pacotes.

— Sanduíche de peixe dourado

Desculpe, não incluí algumas informações sobre o Chocolatey. Chocolatey é baseado em Nuget. Nuget e Nuspec são apenas um pacote de 'coisas' e uma especificação de dependências. No caso de uma estrutura de software como .Net (ruby, node, ...), as dependências são geralmente componentes de software (dll, exe, js, ...). Esses são todos os componentes que um aplicativo usa.

— AllenSanborn

No caso de Chocolatey, embora o pacote seja uma aplicação inteira ou uma dependência de aplicativo (estrutura de aplicativo como java, .net, ruby). O pacote Nuget contém scripts do PowerShell (opcionalmente também o instalador) que gerenciarão a instalação do aplicativo e o arquivo Nuspec descreve o aplicativo e quais dependências ele possui, por exemplo, o Powershell depende do .Net. Há também o Boxstarter que concentra um nível mais alto ao descrever a configuração de uma máquina e do que ela depende. Coisas bem legais. O Boxstarter entra no reino do que as pessoas usam para Chef ou Puppet.

— AllenSanborn

0

Pelo que entendi, as únicas dependências tratadas pelo Windows são as bibliotecas específicas da Microsoft. Se você instalar, por exemplo, um programa de código aberto no Windows como o Blender, ele terá as bibliotecas libavcodec e ffmpeg em seus próprios arquivos DLL separados e, se você instalar, digamos, OpenShot, ele instalará sua própria cópia do libavcodec em seu próprio diretório e elas podem ser versões completamente diferentes. Isso pode ser um pesadelo ao desinstalar o software para limpar o lixo deixado para trás, além de ocupar muito mais espaço em disco com redundância de biblioteca.

— Jeff
fonte