História de como o .NET 4.5 foi instalado no ReactOS

Pode ser uma história de Natal com um final feliz, mas não é bem assim.

Na véspera de Natal de 2018, notei um instalador do .NET 4.0 na lista de aplicativos testados para o ReactOS e fiquei agradavelmente surpreso por ter sido instalado com sucesso e os aplicativos iniciados. Mas como o 4.0 não é relevante há muito tempo, fui visitado por uma ideia maluca - o que acontecerá se eu tentar instalar a versão 4.5?

O instalador declarou imediatamente que a versão do sistema operacional não é adequada. O lançamento no modo de compatibilidade também foi determinado por ele e se recusou a instalar. Tudo terminou antes de começar ...

Sim, agora vou mudar a versão e ela funcionará!

O ReactOS está sendo desenvolvido como um análogo do Windows 2003 e relata a versão como 5.2. A instalação requer pelo menos 6,0, mas então decidi que era melhor apontar imediatamente para o Windows 7 e comecei a procurar como alterar a versão para 6.1. No código, de acordo com a versão / MajorVersion / MinorVersion, havia vários locais em todo o sistema, mesmo onde você não esperava. Substituindo todos os pares de 5.2 a 6.1, o resultado foi zero - mesmo o instalador do SO não foi iniciado. Mais pesquisas levaram ao freeldr e ntldr na inicialização - em 4 locais, foi necessário substituir _WIN32_WINNT_WS03 por _WIN32_WINNT_WIN7. O sistema operacional está instalado e nos diz que isso é 6.1. Tudo bem ?! Não. Por alguma razão, nada é realmente instalado com essa substituição - nem o VirtualBox Guest Additions, nem o Firefox, nem o .NET 4.0 e até o Explorer passam por uma vez. Ok, então você precisa criar um ISO com tudo o que precisa e conectá-lo à máquina virtual. Glória aos bytes, a unidade ainda está funcionando e o instalador inicia novamente. Viva! Até começa, mas reclama da falta de alguns componentes do SO:



O primeiro é um serviço de atualização automática, o segundo é um Instalador Confiável. Não temos nada parecido - realmente, por que no ReactOS existem atualizações do Windows e o Trusted Installer não pode ser por definição, porque apareceu junto com o Windows 7. Havia também uma linha no log que estava faltando algum wusa.exe. Ok, crie os stubs para wusa.exe e wuauserv.dll para o serviço de atualização PR 355 . O Trusted Installer copiou apenas 32 bits do Windows 7, juntamente com as chaves do Registro. Agora, o instalador determina a disponibilidade de tudo o que é necessário e resta apenas firmar o contrato com uma gota de sangue.

O processo de verificação de arquivo foi bem-sucedido e a instalação é iniciada. Imediatamente, recebemos a mensagem de que a função LCMapStringEx no módulo kernel32 está ausente.



Ok, estou procurando uma função no código e, você ficará surpreso, ela existe, mas por algum motivo não é adicionada à lista de exportação (arquivos de especificação ao lado de CMakeLists.txt na raiz de cada DLL). Crie / instale / execute e novamente um erro semelhante. Bem, o script é conhecido. Após repetir esse procedimento de 5 a 10 vezes, o instalador clicou no Google que o sistema operacional possui um modo de instalação autônoma. Para fazer isso, ative UnattendSetupEnabled = yes no arquivo boot \ bootdata \ bootcd \ unattend.inf. Passeio de trenó super! Eles estão indo tão rápido que você não tem tempo para tomar chá - por dois minutos toda a instalação.


Como o ReactOS foi escrito como 2003, ninguém suporta o código do 6.0+. Esses locais são cobertos pelas condições #if _WIN32_WINNT> = 0x600 ou mesmo #if 0 e precisam ser trazidos para a forma de trabalho. Adicione a função ausente (embora seu código seja @ $ & ^%!) Para exportar (SleepConditionVariableCS requer RtlSleepConditionVariableCS) ou desbloquear estruturas / campos em algum lugar nos cabeçalhos do SDK. Uma muleta ainda mais estranha com ntdll, kernel32 e advapi32 - por algum motivo, complementos para eles foram criados na forma de ntdll_vista, kernel32_vista e advapi32_vista, cada um com um máximo de 10 a 15 procedimentos, enquanto o kernel32 possui dois arquivos vista.c. Swan, câncer e lúcio, de outra forma, tomaram essas decisões. Agora também não há certeza - ao colocar o PR no github, pede-se para transferir o código para uma * _vista lib, o segundo escreve que é suficiente fechar a exportação com a condição -version = 0x600 + no arquivo spec. O mais surpreendente aqui é que todas essas funções são uma nova API e podem coexistir pacificamente com o código principal. Não está claro por que cercar esse jardim.

Essas tentativas continuaram por alguns meses, mas no final tudo se baseou no fato de o instalador travar no meio do processo, nem xingando nem caindo.

Ser, não parecer

No verão, decidi voltar para a concha. Ainda assim, tanto tempo foi gasto e o resultado é zero. Dessa vez, decidi fazer tudo de maneira diferente - já que, ao alterar a versão relatada de 5.2 para 6.1, tudo funciona aleatoriamente, é necessário alterar a versão de uma direção completamente diferente - tente criar o ReactOS completamente no modo NT6.

Para fazer isso, na raiz CMakeLists.txt, substitua as seguintes condições 0x502 por 0x600. Sim, não há tempo para gordura, pelo menos 6,0 para obter resultados.

# Version Options add_definitions(-DWINVER=0x502 -D_WIN32_IE=0x600 -D_WIN32_WINNT=0x502 -D_WIN32_WINDOWS=0x502 -D_SETUPAPI_VER=0x502) 

As expectativas de sucesso desse empreendimento eram inicialmente mais ou menos, embora a idéia como um todo fosse verdadeira.
A essência do problema é que, no kernel NT6, muitas funções alteraram as assinaturas, as estruturas de dados diferem na composição e ordem dos campos.

 #if (_WIN32_WINNT >= 0x600) NTSTATUS RxConstructSrvCall( _In_ PRX_CONTEXT RxContext, _In_ PIRP Irp, _In_ PSRV_CALL SrvCall, _Out_ PLOCK_HOLDING_STATE LockHoldingState); #else NTSTATUS RxConstructSrvCall( _In_ PRX_CONTEXT RxContext, _In_ PSRV_CALL SrvCall, _Out_ PLOCK_HOLDING_STATE LockHoldingState); #endif 

Erros de compilação choveram como cornucópia, a mais simples das quais nos arquivos CMake de algumas dlls WINVER e _WIN32_WINNT foram explicitamente reatribuídas a outros valores, por exemplo, 0x602. Ao mesmo tempo, o ReactOS está cheio de dlls, nas quais o WINVER agora é redefinido de 0x502 para 0x600. Houve alguns erros reais # 356 # 359 # 747 # 814 # 815 .

Durou o mesmo mês ou dois e, como resultado, a imagem se reuniu com todas as muletas, mas o instalador não mostrou nenhum sinal de vida. Ativado um pouco mais fusível se foi

Lógica não é ferro

Um novo Natal está chegando e o .NET 4.5 está assombrando. Novamente, volto à primeira opção, todas as edições são repetidas, mas com algumas alterações. Se antes, em vez de perder funções (para as quais não há código no sistema operacional), fiz apenas stubs, mas agora decidi procurá-las no código do Wine e, eis que estavam lá. Transfira, adapte para o ReactOS, para o próximo número 1045 . Em algum lugar, em vez de um esboço, você pode escrever um código real :) # 1046 . O instalador trabalhou mais vigorosamente com essas edições e até terminou "com êxito", mas, diferentemente do instalador, o .NET 4.0 não ofereceu a reinicialização após a instalação - escrevi que todo o mesmo software para a nova geração do sistema operacional e não há necessidade de reinicializar todas as vezes ( ha ha, santa ingenuidade). Quando tentei iniciar o aplicativo helloWorld, nada aconteceu na tela; no gerenciador de tarefas também não tive tempo de perceber nenhuma atividade.


Um pouco mais tarde, decidi me aprofundar nos recursos do instalador, onde encontrei o texto das mensagens de erro e o HERE SURPRISE - todas as restrições são indicadas no arquivo ParameterInfo.xml! Foi o suficiente para comentar sobre a condição de StopBlockers IsInOSCompatibilityMode e tudo começa sem problemas. Eu removo as edições que alteram a versão do sistema operacional de 5.2 para 6.0, ative o modo de compatibilidade do Vista no atalho para a instalação (para que ele não espere que o Trusted Installer exista) e adicionando mais algumas funções que o instalador encerrou com "êxito". No entanto, se você instalar primeiro o 4.0 e depois executar o instalador 4.5, o processo já foi concluído com uma solicitação de reinicialização! Vitória! Não. Eu disse que este é um conto sem um final feliz. Quando você tenta iniciar o HelloWorld, o resultado é um pouco diferente, mas não muito - o processo consome 11 a 12 MB de memória e, após 20 segundos de interrupção, termina. Iniciar no modo de compatibilidade não ajuda (afinal, o CLR-runtime é iniciado em cada processo separadamente, e não um ambiente de todo o sistema que começa com o SO com OS versão 5.2).
No log, vemos chamadas para determinar a versão:



Foi adicionado um hack ao RtlVerifyVersionInfo que, se a versão 6. * for solicitada, substitua a versão do sistema operacional pela 6.0. As linhas marcadas pela seta desapareceram, mas o resultado é o mesmo.

Não é um final feliz.

Conclusão

Talvez haja muito pouco para o sucesso e você, inspirado nesta história, esteja pronto para pegar a bandeira e terminar o que começou baixando o código ReactOS e compilando-o? Não é tão rápido. Em quase todos os PRs, as alterações feitas quando são apresentadas são discutidas primeiro, mas depois ficam suspensas sem atenção dos principais desenvolvedores de SO.

Para repetir o exposto acima, é necessário rolar o PR na ramificação principal usando os links no texto, desbloquear o pacote de funções nos arquivos de especificação (substitua a versão na condição -version por 0x500 +) e várias condições de 0x600 nos cabeçalhos

Não há tempo para montar, venha aqui para construir!

Se você seguir o desenvolvimento do ReactOS e tentar instalar um aplicativo novo, provavelmente encontrará o fato de que algumas funções estão ausentes ou que um PR interessante / útil trava sem parar. Também estou familiarizado com isso e, portanto, decidi compilar regularmente o conjunto do SO com as peças e os PRs ausentes (quero manter o cronograma semanalmente ou a cada duas semanas). Experimente esta montagem, talvez seja útil! Escreva se você encontrar outra função ausente - é altamente provável que ela já esteja no código do ReactOS ou no Wine. Ainda não existe um driver USB.

Faça o download aqui

Feliz Ano Novo e estável ReactOS!

PS Atualização importante! Um aplicativo de console simples, construído em 4.0 ou 4.5, que lista pastas / arquivos em um disco, funciona bem. Portanto, o cant está em algum lugar com WinForms e WPF (pendurado como exemplo de WinForms), e nem todos os CLRs.
Durante a instalação 4.5, notei que os processos ngen.exe com o argumento removem System.Windows.Forms ou System.Dynamic, etc. Parece excluir excluído, mas não registrou novos assemblies normalmente

PPS SUPER atualização importante! O instalador 4.5 no processo remove alguns assemblies do GAC, mas em algum lugar ele falha e não tem tempo para copiar novos (\ Microsoft.NET \ assembly \ GAC_MSIL). Como resultado, dos 115 assemblies, restam 73. Se você copiar os assemblies System, System.Drawing, System.Windows.Forms and Accessibility lá, um aplicativo WinForms simples será iniciado!

PPPS Acabou um ótimo momento - se você copiar o mscoree.dll da 4.0 no system32, o instalador 4.5 não funcionará completamente, mas após a reinicialização do console, os aplicativos win-form serão iniciados.