WinPE: Creare app
Windows PE (WinPE) è concesso in licenza ai produttori di apparecchiature originali (OEMs) per creare utilità di distribuzione e ripristino personalizzate. Questo argomento fornisce linee guida per gli OEM per sviluppare app di distribuzione e ripristino eseguite in Windows PE.
Nota Windows PE non è un sistema operativo per utilizzo generico. Può non essere usato per scopi diversi dalla distribuzione e dal ripristino. Non deve essere usato come thin client o come sistema operativo incorporato.
Estensibilità
La maggior parte delle app di Windows PE sono app della shell a funzione fissa che forniscono un'interfaccia utente personalizzata. Due esempi sono l'app di installazione di Windows e l'ambiente di ripristino di Windows (Re di Windows).
Se è accettabile visualizzare un prompt dei comandi, modificare Startnet.cmd: questo è il modo più pratico per avviare automaticamente un'app. Vedere WinPE: Montaggio e personalizzazione.
Per ignorare la riga di comando e avviare la riga di comando, usare Winpeshl.exe, Wpeinit.exe, wpeutil.exe e wpeutil.dll.
Winpeshl.exe, Wpeinit.exe, wpeutil.exe e wpeutil.dll
Per impostazione predefinita, Winpeshl.exe è il primo processo eseguito quando Windows PE viene avviato. Questo valore viene specificato dal valore del Registro di sistema seguente di tipo REG_SZ.
HKEY_LOCAL_MACHINE
System
Setup
CmdLine
Winpeshl.exe cerca un file denominato Winpeshl.ini. Se il file non esiste, Winpeshl.exe avvia un processo di Cmd.exe che esegue lo script Startnet.cmd. Se Winpeshl.ini esiste e contiene app da avviare, queste app vengono eseguite anziché Cmd.exe.
Wpeinit.exe installa i dispositivi Plug and Play (PnP), avviando lo stack di rete e elaborando le impostazioni Unattend.xml all'avvio di Windows PE. Per altre informazioni, vedere Wpeinit e Startnet.cmd: Uso di script di avvio WinPE.
La rete può essere avviata in qualsiasi momento eseguendo Wpeinit.exe per l'esecuzione quando Windows PE viene avviato o eseguendo il comando Wpeutil Command-Line Options .
Le app della shell personalizzate possono chiamare direttamente in Wpeutil.dll con le funzioni LoadLibrary e GetProcAddress .
Ognuna delle funzioni esportate da Wpeutil.dll ha la stessa firma della funzione di WinMain, come illustrato nell'esempio di codice seguente.
int InitializeNetworkingW(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow
);
L'esempio di codice seguente illustra come inizializzare la rete.
#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;}
Per un elenco completo delle esportazioni di Wpeutil.dll, vedere Opzioni di Wpeutil Command-Line.
Impostazioni del progetto di Visual Studio
Alcune impostazioni di progetto di base di Visual Studio possono essere diverse dalle impostazioni predefinite create dalla Creazione guidata progetto di Visual Studio. Assicurarsi di configurare le impostazioni di compilazione del progetto per produrre app e DLL compatibili con Windows PE, come indicato di seguito:
È necessario sviluppare app Windows PE con codice C o C++ nativo che non usa MFC o ATL. Pertanto, se si usa la Procedura guidata progetto di Visual Studio, scegliere un progetto Win32 e assicurarsi che non siano controllate né MFC né ATL.
Impostare le opzioni del progetto per collegare le librerie di runtime C/C++ statiche, non la versione .dll di Msvcrt.dll.
Aprire le proprietà del progetto e impostare Proprietà di configurazione \ C/C++ RunTime Library su debug con thread multi thread o su più thread, non una delle versioni .dll. Se non si esegue questo passaggio, l'app potrebbe non essere eseguita in Windows PE.
Se si prevede di ospitare l'app nella versione a 64 bit di Windows PE, impostare le opzioni di compilazione del progetto per compilare tutti i file binari con il compilatore x64 in Visual Studio.
Se si prevede di ospitare l'app nella versione a 32 bit di Windows PE, impostare le opzioni di progetto da compilare con il compilatore x86.
Assicurarsi che il progetto non disponga dell'opzione /clr: compilatore. Questa opzione produce codice C++ gestito, che non verrà eseguito in Windows PE.
Avviso L'app può usare file di .dll personalizzati scritti o concessi in licenza da una terza parte. Aggiungere questi file .dll all'app per Windows PE. Tuttavia, non usare Msvcrt.dll e non includere file windows aggiuntivi .dll che non fanno parte di Windows PE.
Informazioni di riferimento sulla compatibilità API
Windows PE è un sistema operativo leggero e bootstrap basato su un subset di componenti dal sistema operativo Windows. È progettato per ospitare le app di distribuzione e ripristino. Di conseguenza, contiene molti file binari di Windows necessari per ospitare le API più importanti per queste classi di app. A causa delle dimensioni e di altri vincoli di progettazione, non tutti i file binari windows sono presenti in Windows PE e pertanto non tutte le API di Windows sono presenti o utilizzabili.
API supportate in Windows PE
Le API seguenti sono supportate in Windows PE:
Se un'API si comporta come avviene nel sistema operativo Windows completo e come documentato nel sistema operativo Windows SDK per Windows, verrà considerato supportato e può essere usato dalle app, a meno che non venga specificato in altro modo. Poiché Windows PE si basa su componenti di Windows, contiene un sottoinsieme significativo delle API Di Windows pubblicate in Windows SDK per il sistema operativo Windows. I parametri, le convenzioni di chiamata e i comportamenti di queste API supportate saranno uguali o quasi uguali al sistema operativo Windows completo, a meno che non siano interessati dall'ambiente Windows PE univoco. Le app che usano solo queste API devono essere portabili tra il sistema operativo Windows completo e Windows PE.
In alcuni casi, un subset dei valori dei parametri possibili sarà utilizzabile in Windows PE. Ciò può essere dovuto a condizioni univoche per l'ambiente di runtime, ad esempio in esecuzione su un supporto di sola lettura, non avere accesso allo stato persistente o ad altre limitazioni di progettazione. In questo caso, l'API potrebbe non essere supportata, ma può comunque essere usata per eseguire un'attività specifica se non esiste alcuna altra alternativa.
In generale, se un'API funziona erroneamente o meno in Windows PE, non è supportata e non deve essere usata, anche se si trova in un file binario incluso in Windows PE. L'API potrebbe non riuscire perché Windows PE è un subset del sistema operativo Windows o a causa delle considerazioni sulla progettazione di runtime univoche per Windows PE. Tali errori non vengono considerati bug in Windows PE.
Poiché molti componenti di Windows non sono presenti in Windows PE, molte API non sono disponibili. Potrebbero essere completamente mancanti perché il file binario di Windows in cui risiedono non è presente. In alternativa, possono essere presenti solo parzialmente perché anche se il file binario di Windows in cui risiedono è presente, uno o più file binari che dipendono non sono. Inoltre, alcune API presenti in Windows PE non funzionano correttamente e si comportano in modo diverso rispetto a quelle eseguite in Windows. Queste API non sono supportate e non devono essere usate perché il comportamento in Windows PE non è definito.
A volte, potrebbe non esserci un'API appropriata per eseguire un'attività specifica. Per trovare una soluzione alternativa, è necessaria una logica di app diversa, una progettazione di algoritmi diversa o una ridefinizione del problema sottostante.