WimBuilder2 - New Builder with Re:WIN10XPE project(~20H2 Supported)

start mshta.exe with /wait option will fix it.

WimBuilder.cmd has two line.

if no option here call without start, or you will get console and WimBuilder UI.

wait only for --close-ui ? or any option? or need a new --wait option?

Hi Slore,

*

WimBuilder.cmd has two lines.

I change 2 lines (Line 91 and Line 95) the way you wrote with:

Code: [Select]

Start /Wait mshta "%~dp0WimBuilder_UI.hta" %*

*

wait only for --close-ui ? or any option? or need a new --wait option?

Hard to respond ... Only sharing an idea, up to you how hard to implement or not :

I believe /wait behavior should be default behavior when parameters used (= any option) since it is default (expected) behaviour with most tools on an os. (eg. xcopy.exe , livesystempro.exe ...)

With other way what I mean:
WimBuilder.cmd --build --make-iso --close-ui
should do things with /Wait
I feel
"--nowait" option be better if you prefer adding a parameter for such behavior to provide maximum flexibility.

eg.

WimBuilder.cmd --build --make-iso --close-ui
-->
work with "Start /Wait mshta "%~dp0WimBuilder_UI.hta" %*" lines (Line 91 and Line 95)

WimBuilder.cmd --build --make-iso --close-ui --nowait
-->
work with ""Start mshta "%~dp0WimBuilder_UI.hta" %*" lines (Line 91 and Line 95)

WimBuilder.cmd
(without parameters)
-->
work with ""Start mshta "%~dp0WimBuilder_UI.hta" %*" lines (Line 91 and Line 95)


++
Personally, I will not use --nowait ,
 but maybe someone will find such an option useful I can not think now
   and maybe it is easier or looks better for you to add --nowait option.
     up to you.

++
Summary:

wait only for --close-ui ? or any option? or need a new --wait option?

"any option" or --nowait option

What do you think?

Well, batch is easy to modify. Is not it? 

I will make it to wait if any option is given.
if someone ask me a --nowait option, then I add it. (Just 8 lines(3 if condition), If I deal with options again, I maybe add it conveniently)

Thanks for the test and feedback.
 

I will make a break on this week or next week. Updated version will be later.
But I stil have time to check any feedback and idea.

 

*
Only a cosmetic idea,

I prepare a small step by step pictures for new users
http://lancelot.theoven.org/TheOvenAttach/WimBuilderSlore_Default_Build_Step_By_Step_20191111.zip

Feel free to use anywhere you like. (copy to your \Slore\ folder if you decide to use    )

I notice something about the logical order at least on UI

I feel:
At left there is
"Getting Started"
"Project"

I believe it should be reverse order -->
"Project"
"Getting Started"

and "Getting Started" better renamed with "Select Source" -->
"Project"
"Select Source"

Logic should be, First select project and later select source. (at least on UI side)
so selecting another project (eg. in future Win11XPE) requires to select another source with correct logical order.

*
In fact, source and other project info should be saved at eg. .\Projects\WIN10XPE\config.js or similar (eg. .\Configs\WIN10XPE\config.js)
 Current WimBuilder config file contains both project settings (eg. $wb_src_folder= ) and builder settings  (eg. $width=1200; ) inside same .js file.
   As long as you provide 1 project via WimBuilder, there will be no trouble from end user. 
    Such work (split config file without practical benefit today) probably will take a lot boring time,
     So Only keep a memo, one day when you have another project (eg. Win11PE) with wimbuilder, split config file. (ps: we do that way....)

Simply:
 Source folder and relevant adjustment(s) is project setting, not builder setting if the builder is not only for 1 project. (eg. Bart's PE Builder (pebuilder) is only for nt5pe )
   Intentional adjustment with hidden agenda OR Instinctive Common mistake (on Wimbuilder case)

    I can write more about this subject providing real-life examples that create trouble(s) from history sharing experience if you ask. 



**
Summary:
+ Small adjustment with UI would be more logical, up to you.
+ Keep "split config" memo for far future.

only sharing something I notice, nothing critical at all with 1 project. 

ps: Edit on previous post.  fixed and added some more lines.

Hi Slore,

here is a bug report :

I use "WimBuilder.cmd --build --make-iso --close-ui" to test builds,

After _process.cmd screen which closes itself,
Normally another cmd window pop up (I guess cscript), which as far as I can notice add text to WimBuilderUI with info like:

Code: [Select]

Final image is .... bytes
....
make boot iso successfully
....

eg. WimBuilder2_Step_G.png
after that WimBuilderUI screen close. 

Very frequently this step fails (text not written to WimBuilderUI) and give  pop up error:
http://lancelot.theoven.org/TheOvenAttach/2019-11-12_094327.png
---> Screen Shot after _process.bat finish build successfully but later with failure to write info to WimBuilderUI

+
This is not a reproducible bug, very random, sometimes very rare sometimes annoyingly very frequently ....

ps: AV disabled, path is D:\T est\WimbuilderSlore\WimBuilder.cmd

Hi, Lancelot


**
Summary:

+ Small adjustment with UI would be more logical, up to you.

WimBuilder2 is a Wim "Editor", first you select the wim file, and next here are some projects for you to custom.
like:
* build a base PE (WIN10XPE)
* build a custom PE (WIN10XPE_NET)  <--- for now, can use preset instead of project
* create RAMOS (RAMOS)
* Slim install.wim to make a slim Windows 10 (WIN10LITE)
* Custom install.wim to add/remove applications/components/tweaks/...    (WIN10CUSTOM)
* split wim
* ...

Build PE is just one regular way to modify the wim file.

WIN10XPE's project is also can build Windows 8 PE, but not good in explore.exe (seems need win7's one), so I don't rename to be WINXPE(support 7,8,8.1,10,11?)

As that mean, I perfer to keep the menu order for now.


+ Keep "split config" memo for far future.

You are right, It should be split.
Actually, you can config them in Projects\WIN10XPE\_Asserts_\config.js, split by yourself.
Get Started's parameters are must in WimBuilder2\config.js, because Projects' config.js is loaded later as design.
(that is why I use js direct as the config file than json or ini file, they are direct codes, can overwite variables auto.)

When another projects need that , I will deal with the configure.

As the command line is supported.

WimBuilder.cmd --source-folder I:\ --preset full

can init the options for UI.

Hi slore,

*
better write this definition to first topic post http://theoven.org/index.php?topic=2390.0

WimBuilder2 is a Wim "Editor", first you select the wim file, and next here are some projects for you to custom.

to somewhere eg. top :

Here is WimBuilder2 - a New Builder base on hta/vbs/js/bat SCRIPTS, and everyone can see the all codes and improve it.

WimBuilder2 is a Wim "Editor", first you select the wim file, and next here are some projects for you to custom.

maybe rest to somewhere at the bottom of first topic post

With WimBuilder2 Wim "Editor" you can do things like:
* build a base PE (WIN10XPE)
* build a custom PE (WIN10XPE_NET)  <--- for now, can use preset instead of project
* create RAMOS (RAMOS)
* Slim install.wim to make a slim Windows 10 (WIN10LITE)
* Custom install.wim to add/remove applications/components/tweaks/...    (WIN10CUSTOM)
* split wim
* ...

Build PE is just one regular way to modify the wim file.

*

WIN10XPE's project is also can build Windows 8 PE, but not good in explore.exe (seems need win7's one), so I don't rename to be WINXPE(support 7,8,8.1,10,11?)

Try Win7PE  It will be easier BUT on SE case we use same plugin for Win8 , 8.1 , 10 but different plugin for Win7 on many project special cases,
 so maybe another project idea if you have hobby time, where also you can practice multi-project design with WimBuilder2 .
  or you find more confortable to have Win10XPE support 7 in addition to 10
   or you have no such interest at all. 

I do not have such a request, only sharing an idea that came to my mind after you comment on Win8 .....

*

As that mean, I perfer to keep the menu order for now.
....
+ Keep "split config" memo for far future.
....
When another projects need that , I will deal with the configure.

I only share ideas I notice.
 last ~10 years I first spend time to get plugins modular (%100) and later spend time to get project design modular (%90)
  Today I can use plugins with WimBuilder and other projects without spending any time
   But rest %10 even looks easy (most codes ready and I use at home) require me spend at least a month to have publicly available.
    That is the reason I share my relevant experience when I notice related things. 

*
Yes I know "Patch Preset" 

I can have more support with inside things, but busy time of the year I have no free time,
 I only come and go and quickly use and things, thanks again for parameter support, I hope I will have a quite fun time at the end of the summer with WimBuilder.

Hi slore,

*
small cosmetic weblink things I notice:
+
At left "Project"
at right click "DETAILS"
there is "TechBench ..." link, when I click that it opens with IE instead of default browser.
eg.
cmd window with

Code: [Select]

start https://tb.rg-adguard.net/public.php

here opens webpage with Firefox, but with WimBuilder opens with IE
+
At left "About"
all 3 links do not open any webpage. 

*
I hope you figure out Reply 185 bug which to me important http://theoven.org/index.php?topic=2390.msg35249#msg35249
 Rest is sharing ideas and small things I notice. 

I hope you figure out Reply 185 bug which to me important http://theoven.org/index.php?topic=2390.msg35249#msg35249

  I split post to reply, but forget to reply   


Build(cmd) button start cmd.exe and wait in hta(page_build.js), make sure you can't click the button again, but when buiding, if you click others pages/buttons,
may show that windows, YES/NO both fine.

If you don't click anything, maybe

After Build(cmd), the  make-iso button click too quickly, cause that error.
Maybe I need to use timer(delay call) to start make-iso.
(An flash cmd is _MakeISO.bat)

Would you to try --build-with-log --make-iso?

Or --build --make-iso --close-ui, then you make iso by yourself.

Maybe pass the WB_ROOT, WB_PROJECT, you can call bin\_MakeISO.bat directly. (maybe needs more _Factory_\WIN10XPE\build\)

I never see it. I will try it later.

about the link, I just use <a herf=""> in hta, so Microsoft start URL with IE.
I can write onclick="open_url()" to start with cmd.exe /c start URL.

After Build(cmd), the  make-iso button clicks too quickly, cause that error.

Maybe that is the case.

I make a single test build now, but it works now.
I will further use :
WimBuilder.cmd --build-with-log --make-iso --close-ui

maybe I can catch it later with luck. (I was known as "Bug Cather" in very past  )

+
I remember we have similar trouble with iso creation but with mkisof (and some others but continue example with mkisof)
 after iso created, checking the size of iso was causing failure time to time (rarely but reported by end users not me, I was not able to reproduce at that times )
  I figure out, after mkisof line, mkisof exit but still working,
   For a stable workaround, I copy mkisof.exe to temp folder and run it with parameter at temp,
      after finish I delete (or rename - ren ) mkisof.exe at temp,
        If exist mkisof.exe delete again --> If not exist mkisof.exe continue
            After that workaround, no more report. 

Probably not this case with oscdimg.exe since as you pointed this happens with _MakeBootISO.bat not after ,
 but instead of use timer(delay call) when the problem is an executable exiting too early,
  I like to share the method I use to avoid it.

I believe next post on this case with log and luck will be better to point the reason behind.

Hi Slore,

maybe you can reproduce this one 

1)
first build with:
WimBuilder.cmd --build --make-iso --close-ui
*
During build "Building" screen was on ui, this can be important.
2)
Double click
WimBuilder.cmd
WimBuilder opens with "Building" screen, click "1-build(cmd)"
-->
http://lancelot.theoven.org/TheOvenAttach/2019-11-12_190759.png

3) - Workaround
Click "Customize" on left and again click "Building" on the left, click "1-build(cmd)" , now it works. 

reminding: WimBuilder.cmd
Line 91 and 95
Start /Wait mshta "%~dp0WimBuilder_UI.hta" %*

**
Nothing critical to me, I only noticed this when testing with a reproducible way here. 

Hi Slore,

A button to save "Customize" settings to a preset would be very nice.
eg.
at left "Customize" --> at right of "Browse Button" -> "Save Default Preset" button -----> default.js

For now, I prefer editing default.js with notepad following ui. (backup with default_factory.js  )

Not critical, but something to consider on your side in the future following WimBuilder design.
 A Regular end user would expect opening WimBuilder again with previously customized settings they made....

Hi Slore,

A button to save "Customize" settings to a preset would be very nice.
eg.
at left "Customize" --> at right of "Browse Button" -> "Save Default Preset" button -----> default.js

For now, I prefer editing default.js with notepad following ui. (backup with default_factory.js  )

Not critical, but something to consider on your side in the future following WimBuilder design.
 A Regular end user would expect opening WimBuilder again with previously customized settings they made....

That is on my TODO list. but it is not easy for saving the selection nodes in js code.

change default_factory.js to be custom.js, that will be selected by default.( you can change it to what you like in _asserts_/config.js.

I will continue with using custom.js 

+
at least I have full.js that contains ALL possible settings (FULL settings LIST) I guess ?
 (default.js do not have all eg. "component.snippingtool":false,  --> not exists at default.js)

very boring to check ui with notepad and do customization,
  still working fine here. 
   There are only ~54 settings with js 
    Please consider finishing TODO when settings increase to somewhere 100 

*
an idea for your TO DO : distribution having custom.js which have default.js settings,
 this way 1) a very simple "Save" button that only saves to "custom.js" 2) Distribution custom settings is default  3) in fact closing WimBuilder can autosave following "1)"

**
All fine experience to me with WimBuilder2 

 I deeply know It takes a lot of time to deal with both developing 1) pe build and 2) builder design that fit best to end user ready for public distribution.
      (+ 3) and help file )

  I know most fun is at 1) pe build  but I prefer 2) to have fun and I never could find time for 3) (instead of 3 wrote info to plugins time to time)


See you much much later, back to full real life things. I hope I will not be around anymore for some months.

Thanks for your all work again, I have some very nice times with WimBuilder2 

For source control management, there should not to be same file in git.
(YOU have to keep them always same)

But you are right to about to have a custom.js(because no helpe file for this, less people see config.js)

I will make a simple copy file when I release WimBuilder2.

+
at least I have full.js that contains ALL possible settings (FULL settings LIST) I guess ?
 (default.js do not have all eg. "component.snippingtool":false,  --> not exists at default.js)

You can select every page, then goto build page, all the option will be listed.

In the first design, you can define them in preset, but any patch should be independent.
divide the default option in patch self.

One day, user ABC add a patch with option "MyOption.Hello", and default value be "world".

Here a 3 way for this:

1. set default in runtime(main.bat)
main.html
    "world"
main.bat
    if "x%opt[MyOption.Hello]%"=="x" set opt[MyOption.Hello]=world

Because If people don't select the patch page, the "world" in main.html won't be load,
you needs write it in main.bat.
But people won't know the default value before building.


2. add the default value into preset

default.js
   "MyOption.Hello":"world",
full.js
    "MyOption.Hello":"world",
???.js
    other user's preset ?

In this way, you have to update every preset/*.js.


2019.11.11 make way No.3.


Projects\WIN10XPE\za-Slim\
   en-US.js

set_default_option('slim.mui', true);

set_default_option function is in js\helper_patch.js. if there is no option defined in loaded preset, then set the default value.
main.html will use this, main.bat needn't to check the empty value, and no needs to update every preset,
if some preset needs to change it, write the value in that preset.

In v2019.11.11 already remove some options from default.js.
In preset, you just need defined the options what you want to change, no need them all.

use patch's <locale>.js, here is another function.

WIN10XPE\01-Components\Devices and Printers\
  en-US.js

Code: [Select]

     $patches_opt['_message.wait_for_printers'] = '          Printers will work in 2 minutes later           ';

  zh-CN.js

Code: [Select]

     $patches_opt['_message.wait_for_printers'] = '                   打印机将在2分钟后工作                  ';

Pass different value to main.bat with different locales to PE, not only show it on UI.

This is internal improve for builder, it is hard to descript it in change log.

WimBuilder2 will be more friendly for international user whom's mother language is not English. (YES, that is why my builder is better than others for ME.)

WimBuilder2 will be more friendly for international user whom's mother language is not English. (YES, that is why my builder is better than others for ME.)

Keep in mind, when you have your project popular, there will be lots of language support.
Adding Language support to builder settings will not be trouble since builder ui elements do not change much in passing time
(eg. Things at "Getting Started " and "Project" and "Building" and "Customize" and other things during build do not change much in passing time)
but
Multi-Language support on patches ("Customize") becomes trouble in passing time, requires a lot work OR an open gate work.

eg. - people can get patches and customize them (edit files) only with enu or mother language, ignoring rest 10 languages that were previously written to that patch and provide to public.
--> patch ui may write wrong with a careless input by others .......

   I have good stable design ideas (This is my 2) area  ) (preventing above and other things) but requires a lot work (and may look too complex if I write now, making things simple requires lots of complex work) .....

     For today, I only advise you to be very careful on design, ms hire people to write languages and they update, dealing with the public being the only developer is another thing,
      consider all possibilities and do things step by step considering future development where things can go on that area in mind.
         (-> Such consideration to me "open gate" work where re design mostly not required (or re design mostly not required for a long time) )


only sharing ideas....



*
I understand how you deal with default settings. 
 A luxury I could not have with the lack of design, but workaround with you on proxy topic. 

  With a save button in future, It will be easier to see which setting line required. (well with save button, probably no need to see that line too)
    Maybe without a save button but WimBuilder_UI.hta autosave every setting one click 
     for today when required I need to check relevant patch lines to add setting to custom.js 


*****
to me as a user, instead of your builder "Better than others" what I like or like to comment:
+ parameter support. 
+ very open source with well known syntax and things available on internet (cmd, js etc.) 
+ very standalone (I guess works with simple pe etc.)
+ Self proves without hiding my relevant ideas since years: batch design 
* most important, slore is behind, after Galapo, Saydin77, JFX and ChrisR and later Kare, you are The one of the people I like to follow the pe work. (+BlueLife but not pe)

As written previously, It is nice to be able to use all written plugins with a well written pe by slore via WimBuilder on my side 
 So all looks good to me. 


See you later again, I hope I will not be around anymore for some months.

For source control management, there should not to be same file in git.
(YOU have to keep them always same)

It seems I lost my comment on this on my previous post:

ps: we use hardlink to fix similar trouble with ftp server

an idea with git is adding file name to the top of js
eg.
custom.js

Code: [Select]

// custom
var $patches_opt = {
    "build.source":"light",
...

default.js

Code: [Select]

// default
var $patches_opt = {
    "build.source":"light",
....

.....
just an idea. 

Hi slore,

better respond your post here :

call LinkToDesktop -paramlist "#{@printui.dll,12007}.lnk" "[[X:\%opt[loader.PEMaterial]%\EnablePrintFeature.bat]], '', 'shell32.dll', 16"

WimBuilder2's LinkToDesktop can create shortcut with system dll's string resource, make the name in the language of Windows PE's language.

Good to hear WimBuilder2 can create a shortcut with Windows PE's language.
Remember Filenamechanger.exe at Lancelot Reply 84 http://theoven.org/index.php?topic=2390.msg31988#msg31988
starting with "This reminds me of something for your WimBuilderUI :"

With Filenamechanger method we can enable/disable shortcut names with Windows PE's language or not.
 (see pictures with local cmd shortcut at end of Reply 84 - without desktop.ini at Desktop like WimBuilder2 eg. http://gena.cwcodes.net/chineseHK-large.png )
With LinkToDesktop syntax, there is no such overall flexibility, each patch should have such an option or not.
 That is one of the reasons we did not use that method in the past.

Not critical or important, only sharing experience for your development. 

It is different with desktop.ini or filename manager.

LInkToDesktop load any dll's string resource as the name.

Mostly the PEs kill the Desktop.ini file on Desktop.
So it is hard to use that way to show the name.

LinkToDesktop can combine any string and support mutil-resoures,which is others can't do.

LinkToDesktop "The file name have #{shell32.dll,54321} in #{explorer.exe,65782}.lnk" notepad.exe