3 replies to this topic

[misty]

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

[Wonko the Sane]

A very good post, IMNSHO .

It also nicely provides a good reason for why Wonko (the Sane) is called "the Sane"

 

The only missing part is WHICH EXACT "dd" version you used/tested. (being it an example, it would be nice if it would be as accurate as possible).

I am inclined to presume the "dd for windows" by John Newbigin:

http://www.chrysocome.net/dd

 but it would be nice if you could confirm this assumption.

 

OT , for other versions/flavours of dd (running in windows), see here:

http://reboot.pro/to...uest-for-ddexe/

 

Still OT, notwithstanding that, the state of the art for "dd-like" programs under windows remains the DSFOK toolkit (just for the record):

http://members.ozema...eezip/freeware/

http://members.ozema...eware/dsfok.zip

 

Still for the record, and FYHI (your historical interest), the "generic idea/philosophy" has been pointed out to the good Winbuilder .script developers, who - more or less - completely ignored it , since what, 2006! 

Earliest reference is I believe here:

http://z3.invisionfr...hp?showtopic=80

And the idea was re-proposed from time to time (a few examples):

http://reboot.pro/to...sta/#entry18025

http://reboot.pro/to...cratch/?p=24278

 

If you prefer, the "Rules of the game" were born for the specific XPCLI project only because at least in that small, limited in scope project, to which BTW none of the "main" developers were interested in (exception made to post how unneeded and futile it was), I could "suggest" them rules to the (at the time) new kid wanting to play with me.

 

I am happy that you liked them so much as to try to re-propose them to the "general public" of developers, and hope that this time this proposal may have some actual followers, but I wouldn't be too much surprised if this won't happen .

 

Wonko

 

[pscEx]

I remind an intention here, which I'm telling since I started to work in the Winbuilder / ??? / reboot.pro forum.

Here the first mentioning:

 

The script does not run in nativeEX.
I get a blue (XP) or grey (W2003) background screen and some hourglass cursors, but the explorer never appears.
The trial to build a cmd version leads to an endless reboot.

BTW: The same is with the original FBWF script.

The reason may be that nativeEX always delivers only the files to the target which are really used.
E.G. WinSxS is not delivered as a package, but file by file where needed.
So maybe that something is missing which in the LiveXP project is in the predefined BartPE hives or in the global C&E.

A script fulfilling the nativeEx standard has to be self-supporting.

Peter

 

You may search for "self supporting" by pscEx, and will find about 10 or more posts.

 

"Self supporting" hits exactly misty's intention. And I hope that I use(d) this procedere in all my projects.

 

Unfortunatelly there have been some developers which preferred to publish a "fast acceptable project" against a "well structured" project.

 

Most of them are not longer active here. So, there is a little chance, that Jaclaz's / Wonko's / misty's / my ideas anywhen will become reality.

Peter

[misty]

...The only missing part is WHICH EXACT "dd" version you used/tested. (being it an example, it would be nice if it would be as accurate as possible)... I am inclined to presume the "dd for windows" by John Newbigin... but it would be nice if you could confirm this assumption.

@Wonko
You are presumptious, but correct - "dd for windows" version 0.5 by John Newbigin.

Thanks as always for the links. I have used the dsfok and some of the other dd versions referrenced - the John Newbigin port is my own preferred option.

I am happy that you liked them so much as to try to re-propose them to the "general public" of developers, and hope that this time this proposal may have some actual followers, but I wouldn't be too much surprised if this won't happen .

Trust me, I'm not holding my breath!
 

....So, there is a little chance, that Jaclaz's / Wonko's / misty's / my ideas anywhen will become reality.

@pscEX
That would be nice. It would make adapting or reusing scripts across projects far easier.

@everyone
Now it's confession time. I realised after adding my first post that I really should practice what I preach as I completely forgot that several of the applications in MistyPE rely on "Browse for Folders" (see here) - I'll add the dependencies for this (ExplorerFrame.dll and some registry entries) for the next version of the project so that it can be installed if missing.

BTW, has anyone managed a bloat free way of getting Browse for Folders working in WinPE 2.* - something lite that doesn't require an Explorer shell?

Regards,

Misty