MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?

( See at the end of this first post for the files to download)

Why is it so hard to write a tutorial to add the Desktop  "explorer " in WinPE?

Like many beginners, I want to understand how one can modify a Winpe10 (boot.wim) and adapt it to its needs or the desire.
And mainly adds native Windows desktop (explorer.exe).

Understanding requires to investigate in the heart of Winpe with tools like "procmon, procexp", etc. And above all it requires a method of investigation.
But for me, it is not easy to describe a method of investigation.
Also, not really knowing to describe a method, I have recorded information which seems to me essential to start the investigation on a given point.

During the investigation and the collection, should introduce changes into the boot.wim file to validate assumptions.
Then put in place a tool to reproduce the generation of this inhospitable Winpe.

But the investigation does not necessarily the good result the first time. Should be many changes to achieve a result.
And of many flashbacks and multiple injections.

I quickly realized that needed a simple and modifiable tool quickly.
In the end, the rudimentary tool will contain all of the identified changed data.

In addition, I adopt the following principles:
-This tool will only use the programs available in the host Win10 system or the ADK.
-It requires the installation of the ADK and the "mount" of the Win10Entreprise Evaluation version to download install.wim file.

Regarding the essential information, I grouped them into a pdf file.. They are necessarily incomplete.

I try to translate them into English with bing translator. So ...

Concerning the script injection, it is written in powershell. I have added a simplistic GUI. To look pretty.
This script is not an end, it is a way, an assistance, a help...

The part "Traitement" of the script will always be evolving as it allows to memorize the discoveries.

The initial script contains what I have implemented so far thanks in part to WinPeSe.

The development difficulties and my poor knowledge of Powershell made me lose sight of the rigor necessary to write well-structured and readable scripts. So my scripts aren't "pretty."

It is quite clear that my purpose is different from that of Win10PeSe.
My goal is to understand how it is possible to produce a WinPeSe. Not to product WinPeSE.

The minimum information to know:
-modify BCD with bcdedit.exe.
-use DISM to Mount/unmount an image (boot.wim for example)
-load/unload a hive with regedit
-modify the ACLs for a key in a hive with regedit
-write a small script in powershell
-create a vhd with PS or  diskmgr.msc or diskpart
-generate a BCD to start a VM with a 'flat' winpe


version V2 (2016.02.05...) too old: automatic language detection added
version V3 (2016-02-18-microWinpeBuilder.7z) : connect/deconnect Wifi in PS, ***** get WOW64 with a PS script ! ******  and correct many bugs !!!
version V4 (2016-02-24-microWinpeBuilder.7z) : Gui in English (translate with bing.translator), wow64 even whith software from winpe, messagebox in the foreground
version V5  (2016-02-29-microWinpeBuilder.7z) : Gui with 'form resizing', scripts PS to modify fbwf.sys for scratchSpace greater than 512 Mo
version V6  (2016-04-23-microWinpeBuilder.7z) : session administrator, BITS, WinRm, a piece of IE
-----------the end for build 10586-------
version V7 ( V7-build14393-MicroWinpeBuilder_V7.7z ) : first work for adaptation to build 14393, explorer OK, session adm nearly OK, but many NOK...
version V8 (2016-10-07-microWinpeBuilder-14393.7z) : many bug in script traitements.ps1,  explorer, session adm, Wow64, modif themecpl, mstsc = ok; wmp and other ...=NOK
version V8 (2016-10-31-microWinpeBuilder-14393.7z) : first try for printer over the LAN
version V9 (2016-11-04-microWinpeBuilder-14393.7z) : printer USB ( adm and system) and network ( adm )
version V10 (2016-11-30-microWinpeBuilder-14393.7z) : printer PDF/XPS automatically started
version V11 (2016-12-14-microWinpeBuilder-14393.7z) : add mciSendString for play audio file, WMP can read MP3  (pb adm and vhd see post 79)
version V12 (2017-02-05-microWinpeBuilder-14393.7z) : session ADM and a better IE64 for ADM only ( download ok, HS : qwant.com , F12...)
version V13 (2017-02-09-microWinpeBuilder-14393.7z) : better IE64 for ADM with f12 (network trace ok)
-------end build 14393, begin V1709
version V14 (2017-11-15-microWinpeBuilder-V1709.7z) :
version V16 (2018-03-16-microWinpeBuilder-16299.7z) : MSTSC to and from winpe, MSRA in session ADM, IC for hyperV
version V17 (2018-03-16-microWinpeBuilder-16299.7z) : WMP is OK ( the WMP 64 bits needs WMP 32 to bo OK ! )
-------end build V1709,  begin V1809
version V19 (V19-MicroWinpeBuilder-1809-en-ScriptConstruction.7z) : Eject USB, more about Printers, WPD-MTP(smartphone in winpe)
version V20 (V20-MicroWinpeBuilder-1809-en-ScriptConstruction.7z) : Many corrections, A little optimization
-------end build V1809,  begin V1903
version V22 (V22-MicroWinpeBuilder-1903-fr-ScriptConstruction.7z)
version V23 (V23-MicroWinpeBuilder-1903-1909-ScriptConstruction.7z) : adapt 1909, using full drivers hive (replace V23 because bug in wifi/drivers hive)
-------end build 1909, begin 20h2
version V26 (V26-MicroWinpeBuilder-20H2-fr-ScriptConstruction.7z) :  : adapt 20h2, better support Scaner
Version V26-63-MicroWinpeBuilder-20H2-fr-ScriptConstruction.7z : a few corrections, VirtualBox in Winpe
Version V26-64-MicroWinpeBuilder-20H2-fr-ScriptConstruction.7z : a few corrections

PDF V2 translate in English with bing/translator
PDF V2.1 45pages in french 45 pages in English, corrections, etc.
PDF V2.2 update for Mstsc with NLA
PDF V2.3: how to add WireShark and Win10Pcap in winpe after it starts. Orca or 7Z? you can choice !
PDF V2.4: modify themecpl.dll to modify wallpaper ( and color task bar ) : not too complex
PDF V2.5: printer USB ans network
PDF V2.6: printer PDF and XPS, scanner
PDF V2.7: note for mciSendString
PDF V2.8: add "winpe in a VHD" ( simple and yet... ) : pb adm and vhd see  "Reply #105"
PDF V2.9: update vhd and session adm ( correct some translations )
PDF V3   : update for session ADM ans IE64 ok for Adm
PDF V3.1 : corrections and clarifications
PDF V3.6 : mstsc with NLA for V1703, Procmon at boot ( all boot activity !)
PDF V3.7 : update for mstsc...
PDF V3.8 : update for WMP...
PDF V4.0 : update v1809, Eject USB, printers, WDP/MTP
PDF V4.2 : Many corrections
PDF V5.0 : 2 files, one for Fr, one for EN - Many corrections

New Method Investigation = FULL-FLAT : a full win10 installation  in a vhd, then a modification in hives to get a winpe -  see "reply #146"
          new version with some changes

I have Very quickly read your tutorial, it's quite pretty full, Congratulation   
Well, it is French 
I would look further, when I find some free time. There is a really interesting work behind   

It may lack a little guide to try your powershell script or my first diagonally read was too fast.
1 ) ADK CopyPE.cmd
Then, MicroWinpeBuilder_V1.Ps1, traitement.ps1 ?

I have to go, real life 
I hope others will look to MicroWinPEbuilder to try, test and help to improve 

noelBlanc, thanks you for your contribution!
I have downloaded your 7z pack, and using Google translate and my very limited French language skills, I'm having a great time trying to understand the PDF! 
The PDF looks very well written and organised, so it's actually kind of fun to slowly "crawl" through it.

Like ChrisR, I would also like some more hints on the exact method of using the .cmd and .ps

Once again, very nice work and I hope you will continue supporting this!

Thank you for your encouragement ChrisR Atari800xl

I kinda rushed to transmit the scripts. It is certain that they contain errors, including strings "fr - fr", which are remained.
I put emphasis on the Pdf and the explanations to investigate in winpe.
The script is only an aid. And I had tried to document its functioning and its interactions with copype.cmd in GUI tabs.
But it is true that must already be at launch.

It has three files:
-MicroWinpeBuilder_V1.Ps1: it is a graphical interface which offers tabs and a 'launch' button
   There are two main tabs: input and configuration
   Input: to fill in the three basic informations
      -the base directory:
         It is the one that will receive the result of copype.cmd. But it can also use an existing tree and produced by a manually launched copype.cmd
      -the directory containing the ADK: an automatic search in the registry key provides the path resulting from its installation
      -the reference win10 directory: a directory containing "install.wim" unzipped (e.g. with DISM/mount-wim...)
   Configuration: two options
      -use REG. EXE or the API of the C3 for loading/unloading of the hives. At the beginning I had too many errors.
         I have a long time to find the impact of GC (garbage collector) on the "runspace" PS (resources not released)
      -choose between the software hive taken into 'install.wim' (in full) or winpe (the 'partial' word is somewhat ambiguous)
         I couldn't find how to display the wallpaper and I tried one and other opportunities. In addition it demonstrates
         the purpose of the script: modify to understand.

-treatment. Ps1: it is activated when you click on the 'launch' button
Initially, I wanted to do full of menus to offer plenty of choice but I made simple: an automatic succession of three steps.
   + If the root directory does not contain the file "media\sources\boot.wim" then the lance copype.cmd script
   + If the root directory does not contain "media\sources\boot.wim.AvecPaquetsDeBase.export" then it launches the "DISM / Add – Package":
   It is long because the script installs all of the packages available in the ADK (modification if needed in the script)
   and then creation of the 'end of this stage' indicator: copy of bootm.wim with another name
   + the next step is always achieved: it is the injection of the modif in the boot.wim file containing the packages (and renamed) to not crush

-the ProductOptions.txt file that contains the information that I know not find elsewhere

To start:
-Open a console PS as 'administrator'
-type in the path of MicroWinpeBuilder_V1.Ps1
-the console is then hidden and a few seconds more later (depending on processor speed) the GUI will be displayed
I left the button "exit" and the "system" menu at the top right (it is a script and the user knows what it does)

Log: the contents of the console is written to the file 'racine\lastlog.txt' when processing is complete.
"A debug mode" rudimentary to search for PS errors:
Type "racine\MicroWinpeBuilder_V1.Ps1 - debug true":
the GUI is not launched in a runspace
the "hideConsole" function is deactivated
PS errors are displayed in the console PS

Be it that I try a translation with bing?

I dare not ask how JFX found the missing driver for dwm 10586 but I wish I knew. Your methdes of investigation are more effective than mine.

@Atari800xl : perhaps i can help you to translate pdf or ps... and speak about content
Thanks again.

--------
Merci pour vos encouragement ChrisR Atari800xl

Je me suis un peu précipité pour transmettre les scripts. Il est certain qu'ils contiennent des erreurs, notamment des chaînes "fr-fr" qui sont restées.
J'ai mis l'accent sur le Pdf et les explications pour investiguer dans winpe.
Le script n'est qu'une aide. Et j'avais essayé de documenter son fonctionnement et ses interactions avec copype.cmd dans les onglets de l'interface graphique.
Mais c'est vrai qu'il faut déjà arriver à le lancer.

Il a trois fichiers :
- MicroWinpeBuilder_V1.Ps1 : c'est l'interface graphique qui propose des onglets et un bouton "lancement"
   Il y a deux onglets principaux : saisie et configuration
   Saisie : pour renseigner les trois information de base
      - le répertoire de base :
         c'est celui qui recevra le résultat de copype.cmd. Mais on peut aussi utiliser une arborescence déjà existante et produite par un copype.cmd lancé manuellement
      - le répertoire contenant l'ADK : une recherche automatique dans la clé du registre propose le chemin résultant de son installation
      - le répertoire de la référence win10 : un répertoire contenant "install.wim" décompressé ( par exemple avec DISM /mount-wim... )
   Configuration : deux options
      - utiliser REG.EXE ou les API du C3 pour chargement/déchargement des ruches. Au début j'avais trop d'erreurs.
         J'ai mis longtemps pour trouver l'impact du [GC] ( garbage collector ) sur les "runspace" de PS ( ressources non libérées )
      - opter entre la ruche software prise dans 'install.wim' ( en totalité ) ou celle de winpe ( le mot 'partielle' est un peu ambigu )
         je ne trouvais comment faire afficher le fond d'écran et j'ai tenté l'un et l'autre des possibilités. De plus cela illustre
         le but du script : modifier pour comprendre.
- traitement.PS1 : il est activé lorsque l'on clique sur le bouton "lancement"
   Au début, je voulais faire plein de menus pour proposer plein de choix mais j'ai fait simple : un enchaînement automatique de trois étapes.
   + si le répertoire racine ne contient pas le fichier "media\sources\boot.wim" alors le script lance copype.cmd
   + si le répertoire racine ne contient pas "media\sources\boot.wim.AvecPaquetsDeBase.export" alors on lance les "DISM /Add-Package" :
      c'est long car le script installe tous les paquets disponibles dans l'ADK ( modification si besoin dans le script )
      puis création de l'indicateur 'fin de cette étape' : copie de bootm.wim avec un autre nom
   + l'étape suivante est toujours réalisée : c'est l'injection des modif dans le fichier boot.wim contenant les paquets ( et renommé pour ne pas l'écraser )
- le fichier ProductOptions.txt qui contient l'information que je ne sais pas trouver ailleurs

Pour le lancer :
   - ouvrir une console PS en tant que 'administrateur'
   - taper le chemin de MicroWinpeBuilder_V1.Ps1
   - la console est alors masquée et quelques secondes plus tard ( selon la rapidité du processeur ) l'interface graphique s'affiche
   J'ai laissé le bouton "exit" et le menu "system" en haut à droite ( c'est un script et l'utilisateur sait ce qu'il fait )

Log : le contenu de la console est écrit dans le fichier 'racine\lastlog.txt' lorsque le traitement est terminé.
Un mode "debug" rudimentaire pour chercher les erreurs PS :
   taper "racine\MicroWinpeBuilder_V1.Ps1 -debug true" :
      l'ihm n'est pas lancé dans un runspace
      la fonction "hideConsole" est neutralisée
      les erreurs de PS s'affichent dans la console PS

Faut il que je tente une traduction avec bing?

Je n'ose pas demander comment JFX a trouvé le pilote manquant pour dwm 10586 mais je voudrais bien savoir. Vos méthdes d'investigation sont plus efficace que la mienne.
Encore merci.

Looks very good so far 
Sadly I don't have much free time these days.

I dare not ask how JFX found the missing driver for dwm 10586 but I wish I knew. Your methdes of investigation are more effective than mine.

Well, I would not really call my methods effective.
Since the usual ways did not work on dwm, I used a complete Windows 10 an started removing services and files.

In HKLM\SYSTEM\Setup
SystemSetupInProgress, SetupType and CmdLine can be used to disable user logon and instead launch a program as nt authority\system.

Thank you JFX

I had never thought to do so.
It takes a lot of rigor to strip Windows and avoid the false trails


Ps : i uploaded twice the same link by error. Is it possible to delete one?

i uploaded twice the same link by error. Is it possible to delete one?

Done. With 11 posts, you should able to modify a previous post now, I believe 

Image boot.wim created and started successfully 
Using install.wim x64 fr-FR extracted folder.
At the first attempt, it did the whole process but failed at the end on Dism /Unmount-Wim (it sometimes happens with Explorer open).
I deleted and re-create the mount folder, then I closed explore before restarting and bing, SUCCESS 
For WiFi, PENetwork would be good. Also a start menu like SIB++ would be a bonus.



If you want to integrate packages, following language ($Langue), you can probably write something like this (au3 here)

Code: [Select]

$UILanguages = RegEnumKey($HKLM & "\src_System\ControlSet001\Control\MUI\UILanguages", 1)
IniWrite($inifile, 'Languages', 'UILanguages', $UILanguages)
$LCID = RegRead($HKLM & "\src_System\ControlSet001\Control\MUI\UILanguages\" & $UILanguages, "LCID")
IniWrite($inifile, 'Languages', 'LCID', $LCID)

[Languages]
UILanguages=fr-FR
LCID=1036  (0x40c)

Thank you ChrisR. I'm glad it's work for you. I was a little affraid.

One thing more : when Dism Unmount failed, have you seen a messagebox behind the GUI ? It said "close explorer" and it retry unmount /discard. The boot.wim is created even if unmount failed.  On my Pc, it work so.
I don't know how to put the messagebox in the foreground. All msgbox are behind. I shall search ...

For autodetection language ( if i understand well that you say ), it's a good idea. It's better than a choice because GUI in script is too long to write. I put in a next version.
And correct the 3 references to "fr-fr" in the script.

Sib++ is  usefull but not 'technical', i prefere 'speak" about Wow64 ( more near MS technologie, i have the error 'sxs in not goog' ) and about the call to syswow64\dllhost  in a full 64bits version. I began to find it in 2012 (http://reboot.pro/topic/17870-winpe4-et-explorer-pour-débutant-comme-moi/)

Encore merci pour avoir fait le test. Ce n'est pas simple de comprendre et d'utiliser les 'bouts de machins mal ficelés' faits par un autre.

(i try without translator)

I received the message, indeed "Close explorer...Retry unmount /discard"
As the MessageBox is long enough, no worry to see it but it would be better in front if you find how.
If error on the first Unmount / Commit, you could possibly test the mount folder size.
and if 0, considered as good and delete and recreate the mount folder and maybe dism /Cleanup-Wim.

I believe that you are not so far for the multilanguage support, if you retrieve the language from Install.wim registry.
$Langue ="xx-xx",  $srcPaquetsLangue    = join-path $sourceFichiersWinpe "\amd64\WinPE_OCs\$Langue"
It should be good then for language pack (if not en-US) and other localized packages.
and you can also use it to copy .mui file (if exist \$Langue\File.mui > Copy else if exist \en-US\File.mui > Copy)
It should allow other install.wim language source and have more feedback then.

Dans le tuto, tu as écrit:

Cela reste possible car la ruche software de install.wim contient déjà des « X : », ce qui est très bizarre.
Aurais je modifié ce fichier lors de mes manipulations ?

Oui, tu as du modifier la ruche software, par défaut elle est avec C: (ou D:) et il doit être modifié en X: pour PE

A+

@ChrisR : Merci pour le test, la lecture, et les conseils pour le langage et le test unmount. Pour les mui, je teste et copie systématiquement les fichiers des 2 langues, en-us et aussi %langue ='autre' (un tableau envoyé dans le pipeline de PS ). Pourquoi les 2? ceinture et bretelle. Pendant la mise au point, on fait des tests et le code reste.
 
For language, test the size of mount, i'll modify the script saturday .

For a long time I asked myself the question about the presence of the X: in the ISO file.
Tonight I took the time to do the audit of the units contained in the freshly downloaded ISO file.

My test:

I download (it is long) from https://www.microsoft.com/fr-fr/evalcenter/evaluate-windows-10-enterprise?i=1
Read in the HTML page:
<a href="http://care.dlservice.microsoft.com/dl/download/8/5/C/85CA9FB3-CC7F-44FD-A352-EF960FC181AD/10586.0.151029-1700.TH2_RELEASE_CLIENTENTERPRISEEVAL_OEMRET_X64FRE_FR-FR.ISO"> <input class="btn greenbtn" type="button" value="telecharger"></a>

I mount the ISO file.

I open...\sources\install.wim with 7Z.

I extract the software hive in c:\temp

I load this hive in hkey_users with the name "z_software"

I sailed with hkey_users\z_software\Microsoft\windows\currentversion

And I read: ProgramFilesDir = X:\Program Files

I sailed hkey_users\z_software\Microsoft\windows Nt\currentversion

And I read: SystemRoot = X:\WINDOWS

I'm amazed. X: !!! not C: !!!

Is this a mistake on my part?

It would be nice if someone had the time to do this (long) test and attempt to provide an answer.

I just checked, you are right, I had not seen, in 10586 it is X: in most keys but it remains C: in RTM 10240 and in Enterprise 2015 LTSB.

hello,

Version 2 : Added automatic detection of language from the ISO file or the directory for reference.

Thank you ChrisR for the help about language.

It will be not enough for non-French uses script. Should I translate in English the text of the script tabs.
But no one claims this translation, or pdf also. It is that this is not very useful. It is true that it is a game to me also...

If someone can try with another language...

Concerning what I call the surprise COM64-32 that can highlight year launching desk.cpl for example, the 'system' event log in Winpe reports of an error at the launch of c:\windows\syswow64\dllhost.dll. I regret not to have an IDA 64 version. I will try out Windbg now that I have a new idea.
The "security" event log is almost empty. It seems no longer evolve after startup.

I'm not sure to have enough time on my side to help further, to test... PESE is already too much, currently
Also, I have no Powershell knowledge to help on, but your program seem already well advanced and commented (in french ).
I leaves room for others with more free time, to test or go further, in your all-in-one design.

@ChrisR, Merci pour tout ce que tu as fait pour moi. Je t'en suis infiniment reconnaissant. J'avais un peu peur de paraître ridicule. Tu m'as rassuré.
@Atari800XL, may i help you? ( 6502 versus 8080 ? a dilemma in my youth )

Several people have downloaded the 7z file containing a pdf and PS scripts.
I was hoping to have some returns.

Please, tell me what you were hoping to find in these files.

Would you like to:
-an English translation of the pdf?
-an English translation of the text of the scripts?

Version 2 allows automatic detection of the language of the 'ISO' reference as proposed by ChrisR.
But I do not know to remove version 1.

Do not hesitate, give me your opinion, even negative with some comments as ' needed English, pdf useful/useless, script works/does not work '...

The development of scripts (error with reg load/unload) made me abandoned the structure organized for ' build ' each of the components as well as WinPeSe doest it  in these scripts. This will be useful if I body script by creating a file by component as the sections of the WinPeSe scripts?

translated by bing....

NoelBlanc, that final paragraph was translated very badly, I have no idea what that was about... ("Body script by creating a file by component"?)

About your other questions: I'm looking forward to reading the full PDF, also trying the scripts, I just didn't have time for it this weekend, sorry.
I really like the way you describe the whole process, the French language is just a bit of a problem for me, maybe we can work together on the English translation. But in that case, it would be best if I try the scripts first, so I know what's going on.
I think it would be best if I try it on an en-US version (event though I'm Dutch myself).
Please don't abandon your project, it's very informative and I like to learn more in-depth stuff about PE creation and modification. Thanks!

Hello Atari800xl. Thank you for your encouragement and interest that you wear to the documentation.
No worries if you don't have time available at this time. This can wait.

Note: version 1 scripts contained only the version fr-fr of winpe. I do not know how to delete the first post 7Z and replace it with version 2.

For the translation (and the increase in information), your help will be invaluable as I am unable to write in English.
You will be the 'head/Director' for this.

About the 'last paragraph':

in the current script, injection of a component, for example, like Wi-Fi requires various categories like "files to copy, to copy keys, keys to add (this is not the same thing as 'the key to copy'), the drivers to load ', etc."
These actions are scattered throughout the script. They are not easily identifiable.
I did not want that the script is accompanied by a multitude of small files. 3 files, this is already much in my opinion. I would like to avoid the presence of the 'productOption.txt' file.

This is not very educational because it will be difficult for someone else to introduce a new component: it is precisely the purpose of this script.
It seems to me important to integrate all these actions/data "correctly" in the script, in a class of object, for example.
But it will be a little long.

To explain why I had put aside a good structure of the data (the data are intermingled and spaghetti):
I lost a lot of time with:
-the conflict of access to the hives with Dism I met early in the development of the script
(- handles non-released by powershell: I put long before finding a parade on internet with [GC]:...)

Well, when I said "work together", I was thinking of more people than just you and me 

For now, please continue your very interesting project, I will follow it even when it is in French!!
You have a very clear and "informative" writing style, so I'm sure that I will be able to follow, with a little help from Google Translate, and maybe additional questions in this thread.
I think a translation will always be a bit "out of date" compared to your originals, so that might pose extra problems and inconsistencies.

 

I must admit I am even dumber than I had feared 

Seriously: When I wanted to test your scripts yesterday, I had sort of forgotten all the steps for a "normal" PE: 64bit host OS necessary, MS ADK necessary (big download), copype.cmd only runs from the ADK prompt, etc. etc. As I said, I forgot how "strict" and "unflexable" this is.
Good thing the PESE projects are so much easier: HostOS can be "anything", no big extra downloads, etc.

I am still very impressed with your excellent Powershell scripting abilities, so I do hope you will continue this projects, but I'm afraid I might have been a bit too enthousiastic. Too bad I don't have a lot of time at the moment either...

the script copype.cmd is started automatically by the PS script. We just need adk is installed on the PC. The injection of the packets is also automatic.
Downloading and installing the adk are the only actions that the user must perform.

It must also mount the install.wim file from the iso in a reference directory.
And it's true we need a pc under win10 (regardless of the build).

No problem if you do not have the necessary time.

In the next version 3, I use a PS script to establish WIFI connection with the C # API. There is an example  in c# on the codeplex site.

I'm on holiday but it rains again and again. I will try to investigate in order to add Wow64 in microWinpebuilder.