Modular Apps Philosophy for WinPE

This topic relates to WinPE 2.*\3.*\4\5 - but can be easily adapted for other systems.

Just for the record, this is not really my idea - it's based on a concept/philosophy suggested by Wonko (the Sane) - but please don't let that put you off.

 The method I will try to detail below is essentially based on using the smallest possible core (or base if you prefer) from which to develop a working program script. Using a small core as a test platform enables a better understanding of the dependancies needed for individual applications.

Basically if you use a project with a large core set of files, something that includes an Explorer shell for example, and develop an application script based on that project, then it might not work in something that uses a smaller core - a WAIK or ADK build. In my personally opinion the WAIK/ADK should be seen as a core from which to develop all WinPE scripts - If you can get an application working in the WAIK then it's probably going to work with every project that uses the same codebase.

Wonko's original post (in Dietmar's XPSP1 with full commandline and NTFS below 10 MB - here) related to using a modular approach for adding programs to a normal type of Windows XP based system - not a Preinstallation Environment (PE). It can be applied equally well to a PE based system. Below are the relevant parts of the post that started this...

...finding the way to have most "basic" parts of a Windows XP working (which involves dependecies and Registry settings set-up in "modular" packages or directories - I can expand on this approach I have devised/used).....

....The Rules of the game are simple (actually only two):

1.starting from a "bare minimum" base (that can be in any case "expanded" in case of need, i.e. this "bare minimum" is "negotiable") you add one app (and one only) and all it's depencies in a separate folder, including (if needed) .reg files and regsvr32 commands.

2.Only in EXCEPTIONAL cases you add anything to \System32\ (and you document this addition by adding a \system32\ subfolder to your app folder containng the .dll/whatever that needs to be aded to \System32\

Each single app (it's folder) should be able to be added by itself to the build and work. This way we create (initially) a large number of duplicates, but we know for sure the exact dependencies of each and every app/tool, and we can later replace these duplicates with "hard links" (to reduce the size).

Although I have attempted to use this concept myself in the projects I have developed, I'm actually starting this topic because I'm still shocked (but very pleased) to have found that it's possible to run Disk Management (diskmgmt.msc) using this method. That's actually running diskmgmt.msc without adding a single file to the \Windows\System32 directory - from a USB drive, on a running system, after WinPE has booted!

This was tested using WinPE 3.1, 4.0 and 5.0 - modifying boot.wim from Windows installation media (a DVD image). The only file added to the System32 directory was an edited winpeshl.ini - used to start the bblean shell. If it's possible to run diskmgmt.msc in this way then think of the other posibilities!

My intention is not to promote MistyPE, however I am going to use this project to explain the method I'm advocating. MistyPE has an option not to add Programs to boot.wim. The Programs are added to individual directories and are completely self contained - all .dll files and other dependencies not already included in the WAIK are added to the Program directories and registry settings are added to a batch file copied to the root of the Programs folder. Running this batch file (Registry.entries.cmd) after WinPE has booted will add all paths and context menu settings (e.g. file associations) to the running PE. It is likely that the Programs folder created in MistyPE can be used in other PE based projects - running the included programs as portable type applications.

I have not had any difficulties getting Programs to start by adding the required dependencies to the directory containing the application instead of System32. dd (for Windows) is a very good example. I have found three dependencies for this program -

• apphelp.dll
• ntvdm.exe
• wow32.dll

Adding these files to \Programs\dd allowed me to run the program. Whilst it is possible to add these files directly to system32 this, in my opinion, creates unnecessarily complications. Also consider that every file added to System32 can make it difficult to accurately trace dependencies for other applications. The added bonus is also a far more portable application.

Also consider that it's possible to source the three files listed above from Windows XP to allow dd.exe to run on all of the versions of WinPE that I have tested. In recent tests I noticed that the programs with wow32.dll and ntvdm.exe dependencies do not function when Windows 6.3.9431 codebase (Windows 8.1 - WinPE 5.0) is used - this includes dd and DriveImageXML. Adding the Windows XP version of these dependencies to \Programs\dd does not impact on the Operating System or any other applications.

This method only works if we know all file and registry dependencies - hence using the WAIK or ADK as a base from which to develop scripts.

Regards,

Misty