WinPE: Criar aplicativos
O Windows PE (WinPE) é licenciado para fabricantes de equipamentos originais (OEMs) para criar utilitários personalizados de implantação e recuperação. Este tópico fornece diretrizes para que os OEMs desenvolvam aplicativos de implantação e recuperação executados no Windows PE.
Nota O Windows PE não é um sistema operacional de uso geral. Ele não pode ser usado para nenhuma outra finalidade além de implantação e recuperação. Ele não deve ser usado como um cliente fino ou um sistema operacional incorporado.
Extensibilidade
A maioria dos aplicativos do Windows PE são aplicativos de shell de funções fixas que fornecem sua própria GUI. Dois exemplos são o aplicativo de Instalação do Windows e o Ambiente de Recuperação do Windows (Windows RE).
Se for aceitável mostrar um prompt de comando, modifique Startnet.cmd – essa é a maneira mais conveniente de iniciar automaticamente um aplicativo. Consulte WinPE: Montar e Personalizar.
Para que seu aplicativo ignore a linha de comando e comece na GUI, use Winpeshl.exe, Wpeinit.exe, wpeutil.exe e wpeutil.dll.
Winpeshl.exe, Wpeinit.exe, wpeutil.exe e wpeutil.dll
Por padrão, Winpeshl.exe é o primeiro processo executado quando o Windows PE é inicializado. Isso é especificado pelo seguinte valor do registro do tipo REG_SZ.
HKEY_LOCAL_MACHINE
System
Setup
CmdLine
Winpeshl.exe pesquisa um arquivo chamado Winpeshl.ini. Se o arquivo não existir, Winpeshl.exe iniciará um processo de Cmd.exe que executa o script Startnet.cmd. Se Winpeshl.ini existir e contiver aplicativos a serem iniciados, esses aplicativos serão executados em vez de Cmd.exe.
Wpeinit.exe instala dispositivos PnP (Plug and Play), iniciando a pilha de rede e processando Unattend.xml configurações quando o Windows PE é iniciado. Para obter mais informações, confira Wpeinit e Startnet.cmd: usando scripts de inicialização do WinPE.
A rede pode ser iniciada a qualquer momento executando o permitindo que Wpeinit.exe sejam executados quando o Windows PE é iniciado ou executando o comando Wpeutil Command-Line Options .
Aplicativos de shell personalizados podem chamar diretamente para Wpeutil.dll com as funções LoadLibrary e GetProcAddress .
Cada uma das funções exportadas por Wpeutil.dll tem a mesma assinatura de função que a Função WinMain, conforme ilustrado no exemplo de código a seguir.
int InitializeNetworkingW(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow
);
O exemplo de código a seguir ilustra como inicializar a rede.
#include <windows.h>
#include <tchar.h>
#include <stdio.h>
typedef int (*WpeutilFunction)(
HINSTANCE hInst,
HINSTANCE hPrev,
LPTSTR lpszCmdLine,
int nCmdShow
);
int __cdecl _tmain( int argc, TCHAR *argv[] )
{
HMODULE hWpeutil = NULL;
WpeutilFunction InitializeNetwork = NULL;
int result = 0;
TCHAR szCmdLine[] = _T("");
hWpeutil = LoadLibrary( _T("wpeutil") );
if( NULL == hWpeutil )
{
_tprintf( _T("Unable to load wpeutil.dll \ n") );
return GetLastError();
}
InitializeNetwork = (WpeutilFunction)GetProcAddress(
hWpeutil,
"InitializeNetworkW"
);
if( NULL == InitializeNetwork )
{
FreeLibrary( hWpeutil );
return GetLastError();
}
result = InitializeNetwork( NULL, NULL, szCmdLine, SW_SHOW );
if( ERROR_SUCCESS == result )
{
_tprintf( _T("Network initialized. \ n") );
}
else
{
_tprintf( _T("Initialize failed: 0x%08x"), result );
}
FreeLibrary( hWpeutil );
return result;}
Para obter uma lista completa de exportações de Wpeutil.dll, consulte Opções de Command-Line do Wpeutil.
Configurações de projeto do Visual Studio
Algumas configurações básicas de projeto do Visual Studio podem ser diferentes dos padrões criados pelo Assistente de Projeto do Visual Studio. Verifique se você definiu as configurações de build do projeto para produzir aplicativos e DLLs compatíveis com o Windows PE, da seguinte maneira:
Você deve desenvolver aplicativos do Windows PE com código C ou C++ nativo que não usa MFC ou ATL. Portanto, se você usar o Assistente de Projeto do Visual Studio, escolha um projeto Win32 e verifique se nem o MFC nem a ATL estão marcados.
Defina as opções do projeto para vincular às bibliotecas de runtime estáticas do C/C++, não à versão .dll do Msvcrt.dll.
Abra as propriedades do projeto e defina Propriedades de Configuração \ Biblioteca de RunTime do C/C++ para depuração multi-threaded ou multi-threaded, não uma das versões .dll. Se você não executar esta etapa, seu aplicativo poderá não ser executado no Windows PE.
Se você planeja hospedar seu aplicativo na versão de 64 bits do Windows PE, defina as opções de build do projeto para compilar todos os binários com o compilador x64 no Visual Studio.
Se você planeja hospedar seu aplicativo na versão de 32 bits do Windows PE, defina as opções de projeto para compilar com o compilador x86.
Verifique se o projeto não tem a opção do compilador /clr: definida. Essa opção produz código C++ gerenciado, que não será executado no Windows PE.
Aviso Seu aplicativo pode usar arquivos .dll personalizados que você escreve ou licencia de terceiros. Adicione esses arquivos .dll ao seu aplicativo para Windows PE. No entanto, não use Msvcrt.dll e não inclua arquivos adicionais do Windows .dll que não fazem parte do Windows PE.
Referência de compatibilidade de API
O Windows PE é um sistema operacional leve e inicializado com base em um subconjunto de componentes do sistema operacional Windows. Ele foi projetado para hospedar aplicativos de implantação e recuperação. Dessa forma, ele contém muitos binários do Windows necessários para hospedar as APIs que são mais importantes para essas classes de aplicativo. Devido ao tamanho e a outras restrições de design, nem todos os binários do Windows estão presentes no Windows PE e, portanto, nem todas as APIs do Windows estão presentes ou utilizáveis.
APIs com suporte no Windows PE
As seguintes APIs têm suporte no Windows PE:
Se uma API se comportar da mesma forma que no sistema operacional Windows completo e conforme documentado no sistema operacional Windows SDK para Windows, ela será considerada compatível e poderá ser usada por aplicativos, a menos que seja observado de outra forma. Como o Windows PE é baseado em componentes do Windows, ele contém um subconjunto significativo de APIs do Windows publicadas no SDK do Windows para sistema operacional Windows. Os parâmetros, convenções de chamada e comportamentos dessas APIs com suporte serão os mesmos ou quase os mesmos do sistema operacional Windows completo, a menos que sejam afetados pelo ambiente exclusivo do Windows PE. Os aplicativos que usam apenas essas APIs devem ser portáteis entre o sistema operacional Windows completo e o Windows PE.
Em alguns casos, um subconjunto dos valores de parâmetro possíveis será utilizável no Windows PE. Isso pode ser devido a condições exclusivas para o ambiente de runtime, como executar em um meio somente leitura, não ter acesso ao estado persistente ou outras limitações de design. Nesse caso, a API pode não ter suporte, mas ainda pode ser usada para realizar uma tarefa específica se não houver outra alternativa.
Em geral, se uma API funcionar incorretamente ou não no Windows PE, ela não terá suporte e não deverá ser usada, mesmo que resida em um binário incluído no Windows PE. A API pode estar falhando porque o Windows PE é um subconjunto do sistema operacional Windows ou devido às considerações de design de runtime exclusivas para o Windows PE. Essas falhas não são consideradas bugs no Windows PE.
Como muitos componentes do Windows não estão presentes no Windows PE, muitas APIs não estão disponíveis. Eles podem estar completamente ausentes porque o binário do Windows no qual residem não está presente. Como alternativa, eles podem estar apenas parcialmente presentes porque, embora o binário do Windows no qual residem esteja presente, um ou mais binários dos quais dependem não estão. Além disso, algumas APIs presentes no Windows PE não funcionam corretamente e se comportam de forma diferente do que no Windows. Essas APIs não têm suporte e não devem ser usadas, pois seu comportamento no Windows PE é indefinido.
Às vezes, pode não haver uma API adequada para realizar uma tarefa específica. Para encontrar uma solução alternativa, você precisaria de lógica de aplicativo diferente, design de algoritmo diferente ou redefinição do problema subjacente.