Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Kullenen_Ask

Any programmer think to make a winpe builder?

Recommended Posts

About features when used the Embedded SIM manager it resolves the dependencies. We can use them first of all. But if you talk about file base dependencies i can suppy them also with procmon. All should be teamwork. All will be resolved after the project started. I think early for to talk about such things in this phaze.

In my mind it should be 3rd. levels of core.

*Classes key

*Shell

*Services

I think now services will be default and seperate from features. User could be not selected the winbio but it will be default and working under base wim. He should select winbio from features part to really use it. With working all services base wim not bigger than 170mb. Just the current idea of me. Also can be vlite style and selectable. For the selected service it is not more than a few files and registry. But when selectable also it's dependent services adds on the subject if there is.

So we can not always start from perfect. We should start from somewhere and have improvement. First need to walk, after try to run. Aim should be just try to keep difference between walk and run small.

Most difficult part is Classes key. It is big over 10mb and language dependent. To suply language independent part and to suply different language addons is not seems effective. Probably it will work as what other builders process it.

Edited by Kullenen_Ask

Share this post


Link to post
Share on other sites

I think early for to talk about such things in this phaze.

Well, no. :(

IMHO most of the problems with existing builders is that they started (mostly) without a "plan" and were adapted/changed n times (or were NOT changed where needed), and this exactly because there was not a "model" of the elements and not much thinking of how to put elements together BEFORE actually starting putting them together.

jaclaz

Share this post


Link to post
Share on other sites

I do not want anybody to develop a new scripting language. It can use just reg files,inf files (as BartPE) and copy file list. And a nice gui.

Kape builder as gui looks like very nice and as expected, just need to be improved of that with more options and customization. Maybe we should ask for author to make it open source.

OK. That's clearer. The term "plugin" might be more appropriate. But it's still not for any old noob to come along, write out a few scripts/plugins and have customized versions MediaPlayer, IE9, MMC, explorer and .NET up and running in a PE in half an hour.

Some ideas... The proposed program has a set of directories and a prescribed format for the plugin files. The files are placed in the directories. When the program starts, it enumerates all the valid plugins in the directories and presents the user with a checklist. When an item is checked, its dependencies are automatically checked also. When the "Build" button is pressed, the program parses the plugin files into one big .reg file and one big file-copy list. Then it mounts a wim image (rw), loads the registry hives, runs the big .reg file, copies the files in the big file-copy list, unmounts (commits) the wim image and makes an .iso for CD and/or "flat" structure for UFD. There are scores of other options that could be considered - relating to the PE generally and to the plugins specifically. Where do they all fit in? Each item in the checklist could have it's own configuration window - say a pop-up dialog of radio-buttons, textboxes, etc that would adjust the standard plugin variables.

KAPE looks to have solid mechanics for handling wim files. It's not a bad template in that regard. It's lacking the plugin capability though. PEBuilder's plugin method plus winbuilder's configuration interfaces could provide inspiration and ideas.

It all might seem very familiar, but I think if it is well thought-out, it could be a major improvement on what's already out there.

Share this post


Link to post
Share on other sites

Some ideas... The proposed program has a set of directories and a prescribed format for the plugin files. The files are placed in the directories. When the program starts, it enumerates all the valid plugins in the directories and presents the user with a checklist. When an item is checked, its dependencies are automatically checked also.

Don't want to seem too "captain obvious", but till now you have described the interface of *any* installer, including that of .msi files or common NSIS ones.

In this respect NSIS could be a very good "scripting engine".

When the "Build" button is pressed, the program parses the plugin files into one big .reg file and one big file-copy list. Then it mounts a wim image (rw), loads the registry hives, runs the big .reg file, copies the files in the big file-copy list, unmounts (commits) the wim image and makes an .iso for CD and/or "flat" structure for UFD.

That's perfectly fine and presents not much of a problem.

There are scores of other options that could be considered - relating to the PE generally and to the plugins specifically. Where do they all fit in? Each item in the checklist could have it's own configuration window - say a pop-up dialog of radio-buttons, textboxes, etc that would adjust the standard plugin variables.

That is one of the problems, the other being, still, HOW to manage the "interconnectedness of all things". :unsure:

KAPE looks to have solid mechanics for handling wim files. It's not a bad template in that regard. It's lacking the plugin capability though. PEBuilder's plugin method plus winbuilder's configuration interfaces could provide inspiration and ideas.

But is the theme making a rounder wheel or on inventing a new kind of wheel (which incidentally runs smoother)?

It all might seem very familiar, but I think if it is well thought-out, it could be a major improvement on what's already out there.

Yes, but these would be improvement to the same "paradigm", I had the impression that Kullenen_Ask was pursuing a "new" one.

I will add to my previous notes that - no matter how the actual plugin is built or the code executed of whatever - the thing that I find extremely frustrating and "wrong" is EXACTLY the current paradigm.

The current one (pebuilder) is:

  1. tick (or untick) a number of checkboxes/radioboxes (possibly add some other settings)
  2. build
  3. if failed try to rebuild changing the checkboxes/radioboxes you set or unset previously

and (winbuilder)

  1. navigate/expand a tree
  2. tick (or untick) a number of checkboxes/radioboxes (possibly add some other settings)
  3. build (this consists mainly in watching senseless information across your screen and a blue progress bar)
  4. if failed try to rebuild changing the checkboxes/radioboxes you set or unset previously

This is not in any way different from the "installer paradigm", with the difference that the "installer" has a small, finite number of possibilities, is by far "narrower" in scope and it is (normally) duly tested in the few possible configurations.

We all know how many BartPE plugins or winbuilder .scripts are written by people that though good willing :) have often no idea (or a very little one) on how respectively a plugin or a .script should be written and how it should be tested.

Since the actual engine has no (or very few) provisions for error checking BEFORE build time, the result is the current "click/build/fail/click somethnig else/build fail/loop" situation.

As you might remember I tried to point out this problem since the very early times of winbuilder, but the paradigm has not changed and was on the other hand aggravated by the known syntax changes problems.

jaclaz

Edited by jaclaz

Share this post


Link to post
Share on other sites

The main problem of building a winpe is the user should not have a BSOD after he/she built his/her winpe. The user probably can resolve the problems source if he/she can boot but can not get a feature to work. Main reasons of BSOD's are service errors. To give all services in a main script/add on/extension will solve the main problem i guess. I added theese packages.

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Application-UX.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-AppSupport-ComBase.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-AppSupport-ComPlus.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-AV-Core.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-DeviceFoundation.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-DIMS.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-DirectoryServices-AD.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-DriverFoundation.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Font-Western-Required.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-FS-Core.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Graphics-Platform.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-IE-Core.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-IE-Explorer.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-IE-Foundation.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-61883.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-acpipmi.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-adp94xx.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-adpahci.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-adpu320.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-amdsata.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-amdsbs.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-arc.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-arcsas.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-avc.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-bth.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-bthmtpenum.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-bthpan.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-bthprint.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-bthspp.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-circlass.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-compositebus.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-digitalmediadevice.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-djsvs.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-dot4.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-dot4prt.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-ehstorcertdrv.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-ehstorpwddrv.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-elxstor.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-gameport.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-hcw85cir.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-hdaudio.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-hdaudss.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-hidbth.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-hidir.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-hidirkbd.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-hpsamd.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-iastorv.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-iirsp.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-image.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-iscsi.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-ks.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-kscaptur.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-ksfilter.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-lsi_fc.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-lsi_sas.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-lsi_sas2.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-lsi_scsi.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-mdmbtmdm.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-mdmgen.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-mdmgl006.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-mdmgl010.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-mdmgsm.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-mdmirmdm.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-mdmwhql0.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-megasas.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-megasr.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-mf.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-msclmd.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-msdri.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-msdv.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-multiprt.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-net1k32.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-net1q32.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-net1y32.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-net8187bv32.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-net8187se86.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netbc6.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netbvbdx.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netbxndx.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netgb6.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netimm.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netirda.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netk57x.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netl160x.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netl1c86.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netl1e86.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netl260x.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netmyk01.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netnvmx.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netr28.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netr28u.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netr73.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-nettun.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netvfx86.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netvg62.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netvwifibus.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netw5v32.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-netxe32.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-nfrd960.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-nvraid.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-pcmcia.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-qd3x86.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-ql2300.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-ql40xx.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-rawsilo.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-rndiscmp.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-scrawpdo.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-sdbus.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-sensorsalsdriver.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-sffdisk.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-sisraid2.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-sisraid4.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-stexstor.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-sti.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-tape.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-tdibth.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-tpm.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-transfercable.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-tsprint.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-ts_generic.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-ts_wpdmtp.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-umpass.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-usbvideo.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-vhdmp.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-vsmraid.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-v_mscdsc.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wave.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wceisvista.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wdmaudio.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wdma_usb.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-windowssideshowenhanceddriver.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-winusb.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wnetvsc.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wpdcomp.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wpdfs.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wpdmtp.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wpdmtphw.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-ws3cap.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wsdprint.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wsdscdrv.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wstorflt.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wstorvsc.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wudfusbcciddriver.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wvmbus.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wvmbushid.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wvmbusvideo.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-INF-wvmic.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Installers-MSI.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Interface-Explorer.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Lpk-Setup.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Media-Support.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-MediaPlayer.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-NetFx20.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-NetFx20Client.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Networking-Base.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Networking-Bluetooth.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Networking-Devices.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Networking-EAP.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Networking-Foundation.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Networking-IAS.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Networking-NASC.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Networking-QoS.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Networking-RAS.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Networking-Services.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Peer-To-Peer-Networking.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Photos-Viewer.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-PowerManagement.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-PremiumCodecs-DOLBY-AC3-AudioEncoder.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-PremiumCodecs-MPEG2-Decoder.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-PremiumCodecs-MPEG2-Encoder.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-PremiumCodecs-MPEG2andDolbyDecoder.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-PremiumCodecs-MPEG3.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-PremiumCodecs-MPEG4.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-PremiumCodecs-WMV.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Role-Authorization.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-RPC.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Security-Base.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Security-Credentials.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Security-EFS.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Security-SecureStartUp.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Security-TPM.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-SensorAndLocation.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Shell-Accessories.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Shell-Core.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Shell-Foundation.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Sync.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-SystemControlPanel.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-SystemManagement-AdminTools.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-SystemManagement-MMC.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-SystemManagement-WMI.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-TapiClient.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-TerminalServicesClient.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-usb.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-VSS-Foundation.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-VSS-Service.cab

Dism /image:C:\a /Add-Package /PackagePath:C:\s\WinEmb-Wireless.cab

And result registry hives is 11,7 MB and compressed 1,60 MB in size also with the "Classes" keys language independent. It will only take 4 seconds to add them into the build. There is approximately 7000 files. If we think apporximately 3000 files exist in base winpe winpe builder should copy 3000 files (All are my approximate numbers with my experiences). It will probably take 1 minute to copy all of them (i do not know how much it will take). As we want a componentisezed structure we will not want to give all registry whole but we will seperate them and give as it is but the size probably will be same. I do not think the language dependent part will be big in size probably very very little. My friend ludovici used same keys and he said he can boot with same keys {They are optained without adding a language pack to the build} (i do not know detailed info, he has some explorer crashes (probably because most of language dependent classes missing, it can be only reason such crashes in my side if it works) but it is a big success)

I do not think any wrong scripting will cause BSOD or errors in system as Jaclaz complains a lot. They are just softwares that installs some registry entries in software registry and a bunch of files adds into programs folder. If there is BSOD or errors it is because the wrong scripting about microsoft system features and probably about the system hive services part of that feature.

Edited by Kullenen_Ask

Share this post


Link to post
Share on other sites

Some ideas... The proposed program has a set of directories and a prescribed format for the plugin files. The files are placed in the directories. When the program starts, it enumerates all the valid plugins in the directories and presents the user with a checklist. When an item is checked, its dependencies are automatically checked also.

Don't want to seem too "captain obvious", but till now you have described the interface of *any* installer, including that of .msi files or common NSIS ones.

In this respect NSIS could be a very good "scripting engine".

Do try to keep up with the progress of the thread, jaclaz. I specifically sought clarification of the term "scripting". Subsequently, the notion of a "scripting engine" was removed from the agenda (for the time being). We're now talking about "plugins" which is a very familiar theme.

winbuilder runs each of it's scripts as individual processes - like a bunch of little wheels rolling one-by-one. I don't know about PEBuilder. My idea is for the program to assemble all the spokes into one giant wheel THEN start rolling.

Share this post


Link to post
Share on other sites

winbuilder runs each of it's scripts as individual processes - like a bunch of little wheels rolling one-by-one. I don't know about PEBuilder. My idea is for the program to assemble all the spokes into one giant wheel THEN start rolling.

My idea also little wheels preferably. One big giant wheel will make fault locating very difficult. Will make it dependent for the inventor. On person should do all. But little wheels more customizable and easy for different people to make small plugins.

I do not want anypart of it to be dependent to anybody for it to live long life. Thats why i always say "open source"

Edited by Kullenen_Ask

Share this post


Link to post
Share on other sites

winbuilder runs each of it's scripts as individual processes - like a bunch of little wheels rolling one-by-one. I don't know about PEBuilder. My idea is for the program to assemble all the spokes into one giant wheel THEN start rolling.

My idea also little wheels preferably. One big giant wheel will make fault locating very difficult. Will make it dependent for the inventor. On person should do all. But little wheels more customizable and easy for different people to make small plugins.

Each plugin is one handcrafted spoke in the wheel. The program assembles the spokes. More than that, the big wheel could optimize the build process.

Say plugin1 wants x.dll, and plugin2 wants the same. Why run each little wheel, duplicating file-copying.

Same with registry settings. You can easily identify conflicts if everything is compiled, and why repeatedly load and inload hives?

Share this post


Link to post
Share on other sites

Do try to keep up with the progress of the thread, jaclaz. I specifically sought clarification of the term "scripting". Subsequently, the notion of a "scripting engine" was removed from the agenda (for the time being). We're now talking about "plugins" which is a very familiar theme.

winbuilder runs each of it's scripts as individual processes - like a bunch of little wheels rolling one-by-one. I don't know about PEBuilder. My idea is for the program to assemble all the spokes into one giant wheel THEN start rolling.

Well, you could also actually READ what I wrote.

I was talking of the interface or if you prefer of the way the whatever (as an example a scripting engine) would interact with the user.

You can call it any name you want, but still it will be a scripting engine of some kind, as long as you give to it some "fixed" instructions (contents of the plugin), a number of "varaible" instructions" (the settings) and after you press a button to "build".

The plug-ins (actually the instructions i them), in PEbuilder as well as in winbuilder, are processed sequentially.

If I get it right, you have not such a different idea from mine, combine all the separate plugins in a whole "fat" plugin, to be later run "monolitically".

Whether this is called a scripting engine or "mickey mouse" is not at all relevant IMHO.

So, the idea (mine at least) is to run a pre-processor of some kind capable to resolve dependencies and duplicates BEFORE actually starting DISM or movingextracting/copying files and to assemble a monolithic "set of instructions" for the build.

@Kullenen Ask

May I ask what is "Embedded SIM manager"?

Does it have another name? The one I found some reference about is part of 7 Compact to manage SIM's (cellular phone thingies). :unsure:

jaclaz

Share this post


Link to post
Share on other sites

I see :thumbup , thank you.

Windows SIM or Windows System Image Manager, not SIM manager, which is this one: http://msdn.microsoft.com/en-us/library/ee498248.aspx

The good MS guys have a quirk to give confusing names. :whistle:

Judging from this:

http://www.windows-noob.com/forums/index.php?/topic/575-what-is-windows-sim-and-how-can-i-use-it/

It is not entirely unlike the old XP embedded thingy.

jaclaz

Share this post


Link to post
Share on other sites
The aim of the topic is to search and find such a programmer.

How can I help?

I've already started working on the 2.0 version of WinBuilder. The platform is based on Remedium that is both free and open source, you find the ground works at http://winbuilder.googlecode.com

If you look on the current winbuilder, most boot disk projects running with this builder are free and open for anyone to change but the biggest problem is keeping developers improving the existent projects instead of simply creating new ones as rabbits. I guess it is far more rewarding to have a feeling of authorship than joining something started by someone else, albeit I'd prefer to see people cooperating to create one or two strong projects.

My focus on this moment is to ensure the independence from Windows API to natively construct registry hives and WIM files without resort to MS code, in the process this allows removing the need for administrative permissions or installation of drivers to run the builder.

This is what we are doing. For the first time since 2006 we will also reintroduce the concept of a default boot disk project shipped with WinBuilder. As you might know, winbuilder.exe is a free engine and boot disk projects are developed/published by anyone interested. But I am not happy with the current results and will also provide a project for users to try out as default.

I am here to listen for suggestions or ideas you have to make things better. Better yet, if someone wants to join and help with coding/testing then I'd surely appreciate that.

:)

Share this post


Link to post
Share on other sites

... but the biggest problem is keeping developers improving the existent projects ...

hmm funny, the guy who kicked the best developers out of the boot-land forum, calls himself also Nuno Brito.

My focus on this moment is to ensure the independence from Windows API to natively construct registry hives and WIM files without resort to MS code, in the process this allows removing the need for administrative permissions or installation of drivers to run the builder.

Your focus is not what any script developer cares about. I would highly recommend to focus on reliability, speed, simplicity AND a clear script syntax.

Share this post


Link to post
Share on other sites

I am here to listen for suggestions or ideas you have to make things better. Better yet, if someone wants to join and help with coding/testing then I'd surely appreciate that.

Of course all of us here for suggestions and ideas. But i am a little confused about all of this stuff. When i look all people says their solutions is different and a new builder, but when a look as a normal user, all uses same gui and same scripts. Somebody should try to explain me what is the difference between Gena, Nuno's http://winbuilder.googlecode.com and Psc nativeEx or others like that. In my side all are same. Only we can say "rabbit" word for theese winbuilder variants and get rid of them. Projects as MakePE3 can not be a rabbit in here.

I said a few times that i want to get rid of the API's (i think you call the script systax like that) I do not have problem with the winbuilder GUI. If you can take the project that you gave the link and get it work with scripts as for example this


[TargetDirectories]
a="Windows\System32"
a1="Windows\System32\en-US"
b="Windows"
b1="Windows\en-US"

[CopyFiles]
zipfldr.dll=a
zipfldr.dll.mui=a1
explorer.exe=b
explorer.exe.mui=b1

[CopyWinSXSFolder]
x86_microsoft.vc80.crt*.*

[CopyWinSXSManifests]
x86_microsoft.vc80*.manifest

[CopyWinSXSFileMaps]
$$_system32_21f9a9c4a2f8b514.cdf-ms

[RegAdd]
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE_00\Microsoft\DirectPlay]
"Compat1"=dword:00000001

i will not be against to use winbuilder or any of the variants. Just i want is the builder to copy the files under [CopyFiles] to the folders [TargetDirectories] and merge the registry stuff under [RegAdd] to a mounted software.hiv. It should be very easy to code a such program when compared with complex syntax and API's of winbuilder. Everbody easly edit and create scripts.

Edited by Kullenen_Ask

Share this post


Link to post
Share on other sites
hmm funny, the guy who kicked the best developers out of the boot-land forum, calls himself also Nuno Brito.

I was the guy called upon to stop a silly fight between senior developers, some of them my close friends for several years. I suspended two members temporarily until the rage settled down after repeated complaints from community members. I indeed am the "guy who kicked the best developers out of the boot-land forum" because they often treat other developers like this: http://goo.gl/8Zimw

Your focus is not what any script developer cares about. I would highly recommend to focus on reliability, speed, simplicity AND a clear script syntax.

You are welcome to step inside the development group and help with what you think it is necessary to improve. :)

Somebody should try to explain me what is the difference between Gena, Nuno's http://winbuilder.googlecode.com and Psc nativeEx or others like that. In my side all are same.

It is like this:

WinBuilder is an engine. It is composed of a single file that is "WinBuilder.exe". You can imagine (to some extent) that it is like AutoIt for building Windows since the only thing that winbuilder does is following the instructions of whatever is written on the scripts. Per se, WinBuilder does not produce boot disks, it is simply an engine or script interpreter if you wish to be more accurate.

Gena and NativeEx are Windows PE projects. They build a boot disk and the scripts on both projects that create these boot disks use WinBuilder (as well as many other Windows PE projects over the years did).

I hope this helps to understand things a little bit better.

:)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...