Win10PE SE - Contributions to Package Release

Hi HeyJoe,

Hopefully I didn't put an overload on You.

Not at all. You give perfect feedbacks. 

I will respond all on my next free time, today a busy day, the world can wait for a little more. 

Hi HeyJoe,

I update following on all servers related to your reply 2 :

\Build\"2 - Shell & Config" Plugin
\Components\"Ms Viewer" Plugin
\Components\"PENetwork" Plugin
\Components\"PPPoE (ADSL, Phone)" Plugin
\Components\"PowerShell" Plugin
\Components\Tweaks\"Tweak Mouse" Plugin
\Finals\"PrePost" Plugin
\Finals\"PostConfig" Plugin
\VirtualTest\"VirtualBox Virtualization" Plugin


Some short notes knowing you will check all changes.   
Finals\"PrePost" Plugin
Finals\"PostConfig" Plugin
Long story to short this will fix your report with "CMD Adds" Plugin and all similar Plugin cases.

Components\"PowerShell"
+ DINI_SM_CM_F_CheckBox Default True now
+ I do not know why you prefer xcopy, following you I also use Call,XCopy ...

*
I believe I catch you again. 
Also, If I miss one of your reports let me know.

*
I am ready to update packages, I am waiting for the next.   

Hi Lancelot,

...
+ I do not know why you prefer xcopy, following you I also use Call,XCopy ...

I love using xcopy (and other) since Good Old BartPE by Bart Lagerweij

I hope all these posts will be a nice head start to HeyJoe.

Thx. Let's see.

I do. I will be again away in short time.... These days only reason I keep around is HeyJoe.

+

Waiting for your next on the other topic, I hope you have free Saturday time. 

Regrettably no free time.

See You.

Hi HeyJoe,

...
+ I do not know why you prefer xcopy, following you I also use Call,XCopy ...

I love using xcopy (and other) since Good Old BartPE by Bart Lagerweij

Me too, that is the reason I made Call,Xcopy 
+
Untill I met Galapo, I was using BartPE by Bart Lagerweij along with SherpyaXPE 
I was learning to create and boot with BartPE.img which today become .vhd boot and easier. 

*
I update
\Components\"CMD Adds" Plugin
with history notes (not inside 2021.03.28 package) (for now at HistoryNotes05=)
Also
\Build\"2 - Shell & Config" Plugin
updated (inside 2021.03.28 package)

*

Regrettably no free time.

I understand you. 

It is always a slow developing process with low free time,
 keep coming around even slowly. 
  I am always turtle speed, last few years very slow turtle speed, current days slore is supersonic 

See You

Hi Lancelot,

Hmm, what does that mean:

I believe I catch you again...
...

1.: meant fun ?
2.: Try harder !
I belive 1st one, Am I right ? 

-------------------------------------------------------------------------
Recent update "Win10PE_SE_2021-03-28.zip" - big thx for it.
What a time investment every time ! --> collecting, commenting, inserting, copying, ..., zipping, put on server(s) ... etc.
Wow ! 
-------------------------------------------------------------------------

I recently did a comparison of latest WinPE_SE_2021-03-19.zip with plugin files below My %ProjectDir%
to find changes I made in the past.

Now changed to  ... Win10PE_SE_2021-03-28.zip ...

...
Also, If I miss one of your reports let me know.

Yes I think. So let's get back to "http://theoven.org/index.php?topic=3351.msg39955#msg39955".

Reminding: My source is v.1809 x86 - I prefer to build with BuildClass=2


--> See %BaseDir%\Projects\Win10PESE\Images.script --> Now We have Version=093 Date=2021.03.24

Made more clarification and added some new things/thoughts

Code: [Select]

[Main]
...
History_JH001=J.H. 2021-Mar-25 - While using BuildClass=2 ... --> Hey Lancelot, changes made in v.091 up to v.093 do NOT fix wrong index if selected BuilClassis = 2 :( --> It is a must to get right index: See lines below line saying: "// See History_JH001 ..."
History_JH002=J.H. 2021-Mar-30 - Win10 doesn't have "Service Packs"

[Process]

// 1st: replaced org. lines 267 to 269
If,ExistDir,%ProjectTemp%\WimInfo,ShellExecute,Hide,cmd.exe,"/C rd /s /q #$q%ProjectTemp%\WimInfo#$q"
If,ExistDir,%ProjectTemp%\WimInfo,Call,DirDelete,%ProjectTemp%\WimInfo
DirMake,%ProjectTemp%\WimInfo

// by:

// See History_JH001 - why not keep WimInfo.exe's output file WimInfoInstall.ini ?
// If,ExistDir,%ProjectTemp%\WimInfo,ShellExecute,Hide,cmd.exe,"/C rd /s /q #$q%ProjectTemp%\WimInfo#$q"
// If,ExistDir,%ProjectTemp%\WimInfo,Call,DirDelete,%ProjectTemp%\WimInfo
Call,DirMake,%ProjectTemp%\WimInfo


// 2nd: I inserted between org. lines 459/460 saying:
//If,%ti%,Equal,-,Set,%tb%,%ti%
End
// and org. line 461/462 saying:
Set,%pCheck_ExtractWimFolder%,True,Permanent
If,%tb%,Equal,-,Set,%tb%,""

// the following (hopefully these are self-explanatory) lines:
// ----------------------------------------------------------------------
// See History_JH001
Call,DirMake,%ProjectTemp%\WimInfo
Run,%ScriptFile%,WimInfoInstall
Set,%ti%,%SourceDir%\sources\install_wim\%WIMIndex%
// @ Lancelot: The following Set commands are involved in the naming of global variable "RegistryCache" with value (in My case) e.g.: "%BaseDir%\Workbench\%ProjectName%\Cache\Windows 10 Pro_Professional_10.0.17763.1_x86_de-DE"
// and it is written to Section [IniVariables] of "%BaseDir%\Projects\%ProjectName%\script.project"
// Maybe You think it's not that important: Delete this comment line(s) if You like.
// But consider: this way We have equal results for both BuildClass 2 + 3 which would (bonus) avoid cache new writing in case You want quickly change/test BuildClasses.
// By the way, as already written before: At PESE runtime We only have the enterprise version anyway :)
If,Not,ExistVar,%ProductNameVar%,Set,%ProductNameVar%,%NameVar%
Else,If,Not,%ProductNameVar%,Equal,%NameVar%,Set,%ProductNameVar%,%NameVar%
// ----------------------------------------------------------------------


// 3rd: replaced org. line 621 saying:
If,ExistRegKey,HKLM,"Tmp_Software\Microsoft\Windows NT\CurrentVersion",ProductName,RegRead,HKLM,"Tmp_Software\Microsoft\Windows NT\CurrentVersion",ProductName,%ProductNameVar%
// by:

// See History_JH001
If,Not,ExistVar,%ProductNameVar%,Begin
If,ExistRegKey,HKLM,"Tmp_Software\Microsoft\Windows NT\CurrentVersion",ProductName,RegRead,HKLM,"Tmp_Software\Microsoft\Windows NT\CurrentVersion",ProductName,%ProductNameVar%
End


// 4th: replaced org. lines 667 and 668 saying:
Set,%OSServicePack%,SP%SPLevelVar%
IniWrite,%ProjectDir%\script.project,IniVariables,OSServicePack,SP%SPLevelVar%
// by:

// See History_JH002
// Win10 does not have Service Pack's
If,%OS%,Equal,Win10,Set,%OSServicePack%,
Else,Set,%OSServicePack%,SP%SPLevelVar%
IniWrite,%ProjectDir%\script.project,IniVariables,OSServicePack,%OSServicePack%

More to come soon.
See You.

Hi HeyJoe,

Hmm, what does that mean:

I believe I catch you again...
...

1.: meant fun ?
2.: Try harder !
I belive 1st one, Am I right ? 

Dealing with public is mostly not fun
even recent examples:
self sabotaged plugins without replying how why http://theoven.org/index.php?topic=3356.0
wrong reports without informing how http://theoven.org/index.php?topic=3353.0
and without reply success http://theoven.org/index.php?topic=3325.0
and also Post-Gamers , PM-Gamers, and a set of clever-idiots ......
--> that is the reason many developers do not create forums. 

It is quite fun to get good feedback 

btw, If you get some pms as soon as you start to post around, let me know (you can also pm if you like)


*

-------------------------------------------------------------------------
Recent update "Win10PE_SE_2021-03-28.zip" - big thx for it.
What a time investment every time ! --> collecting, commenting, inserting, copying, ..., zipping, put on server(s) ... etc.
Wow ! 
-------------------------------------------------------------------------

Thanks for the nice words.
 What you wrote is the way we believe how development should go. 
   and how we do since 10 years 

The amount of work to make all wheels turn nicely was quite a lot .... now all smooth 

We can quickly have another zipping on the server after all finished. 

Better split replies, see you on next reply ...

Hi HeyJoe

About "Images Configuration" , probably I misunderstood things due to English Language barrier.
Before making any edit on plugin better clear things (I will comment service pack later)

Reminding: My source is v.1809 x86 - I prefer to build with BuildClass=2

I am testing with Win10_1809_German_x32 ( 1809 v10.0.17763.1 x86 de-DE ) with BuildClass=2 

I extract Win10PE_SE_2021-03-28.zip to a new folder, change BuildClass to 2, Select Source and BigBluePlay

I get the following with Index 5 :



Do you have the same ?

As far as I know, Index 5 is the right index ?

@ Lancelot,

Dealing with public is mostly not fun
even recent examples:
...

I completely feel the same.

It is quite fun to get good feedback 

That's the way I like it.

Better split replies, see you on next reply ...

@ Lancelot,

About "%BaseDir%\Projects\Win10PESE\Images.script"

As far as I know, Index 5 is the right index ?

Yes, it is.


See Reply #24: The 2nd comment in codebox starting with line: "// 2nd: I inserted between org. lines 459/460 saying:"
gives Us: See (selfmade) blue arrow in pic "BuilClass2.png"

See you on next reply ...

@ Lancelot,

Btw, BuildClass=3 is OK, except gui entry saying: Service Pack : SP0
Because most likely M$ won't deliver so called SP's for Win10 anymore, We can correct it this way (cosmetics ?):

Code: [Select]

// 4th: replaced org. lines 667 and 668 saying:
Set,%OSServicePack%,SP%SPLevelVar%
IniWrite,%ProjectDir%\script.project,IniVariables,OSServicePack,SP%SPLevelVar%
// by:
If,%OS%,Equal,Win10,Set,%OSServicePack%,
Else,Set,%OSServicePack%,SP%SPLevelVar%
IniWrite,%ProjectDir%\script.project,IniVariables,OSServicePack,%OSServicePack%

See (selfmade & nice looking ) blue arrow in pic "BuilClass3.png"


Have a nice time. See You.


Edit: Both pics still show v.93 but already all things included I posted.
        Btw, I like them if not hidden while checking ... checking ...

Hi HeyJoe,

See Reply #24: The 2nd comment in codebox starting with line: "// 2nd: I inserted between org. lines 459/460 saying:"
gives Us: See (selfmade) blue arrow in pic "BuilClass2.png"

I already replied that:

Hi HeyJoe,

Yes index 5 with Win10_1809_German_x32.iso
As you already figure out
 BuildClass3 get ProductName info from wim file
 BuildClass2 get ProductName info from registry
  and with Win10_1809_German_x32.iso ProductName info (index 5) mismatch.

I believe BuildClass2 should follow the registry following its install.wim independent nature.
So I leave it as it is since the index is auto-detect correct with 5 which is the important part. 

Let's see that a bonus feature to catch when there is such a case.   

I add History Notes about that.   

Further, I will come with a midway solution   

*

Btw, BuildClass=3 is OK, except gui entry saying: Service Pack : SP0
Because most likely M$ won't deliver so called SP's for Win10 anymore, We can correct it this way (cosmetics ?):

GUI entry is correct, SP0 means no service pack. 

Writing SP0 to ui means a check made and result with SP0, writing nothing to ui may mean code failure.
To avoid mismatch,
I will change BuildClass2 to write SP0 to ui when registry entry not exist.

There is nothing called SP0 by M$ , it practically means no service pack. 


*

More to come soon.

@ Lancelot,

Regarding BuildClass=2 :

Further, I will come with a midway solution

Please consider:
Your nameless pic in reply #26 http://theoven.org/index.php?topic=3351.msg40077#msg40077
shows: "Install.wim:5 - Windows 10 Enterprise

My pic "BuildClass2.png" in reply #28 http://theoven.org/index.php?topic=3351.msg40081#msg40081
shows: "Install.wim:5 - Windows 10 Pro

As I wrote in reply #24 http://theoven.org/index.php?topic=3351.msg40073#msg40073

see codebox there:
(
// 2nd: I inserted between org. lines 459/460 saying:
...
// @ Lancelot: The following Set commands are involved in the naming of global variable "RegistryCache"
     with value (in My case) e.g.: "%BaseDir%\Workbench\%ProjectName%\Cache\Windows 10 Pro_Professional_10.0.17763.1_x86_de-DE"
)

   with value (in Your case) e.g.: "%BaseDir%\Workbench\%ProjectName%\Cache\Windows 10 Enterprise_Professional_10.0.17763.1_x86_de-DE

That is: without ...
)
// 2nd: I inserted between org. lines 459/460 saying:
...
If,Not,ExistVar,%ProductNameVar%,Set,%ProductNameVar%,%NameVar%
Else,If,Not,%ProductNameVar%,Equal,%NameVar%,Set,%ProductNameVar%,%NameVar%
// ----------------------------------------------------------------------
)
... We would have differend path names for the same files between BuildClass 2 +3  --> Not good

This is meant new thought I posted here:

Made more clarification and added some new things/thoughts

About SP...

I will change BuildClass2 to write SP0 to ui when registry entry not exist.

Sorry, No. I don't think it's worth the effort.
Where there is nothing, nothing has to be written.

edit Begin
See codebox reply #24:
If,%OS%,Equal,Win10,Set,%OSServicePack%,
Else,Set,%OSServicePack%,SP%SPLevelVar%
IniWrite,%ProjectDir%\script.project,IniVariables,OSServicePack,%OSServicePack%
edit End


Happy Easter in pandemic times, wherever possible.

See You.

Hi HeyJoe,

I just updated "Images Configuration" Plugin, v95 v96  on server. 

*
Changes should be easy for you to figure out after a simple compare, Here shortly:

See Reply #24: The 2nd comment in codebox starting with line: "// 2nd: I inserted between org. lines 459/460 saying:"
gives Us: See (selfmade) blue arrow in pic "BuilClass2.png"

I already replied that:

I believe BuildClass2 should follow the registry following its install.wim independent nature.

install.wim independent nature. --> means there maybe no install.wim condition, that is the reason I can not use your codes directly...

*

// But consider: this way We have equal results for both BuildClass 2 + 3 which would (bonus) avoid cache new writing in case You want quickly change/test BuildClasses.

Thanks, I never noticed that before (or my memory says there maybe a long time ago... ) ( since I never test with a sources like Win10_1809_German_x32.iso ... )

I also consider that with the other way around. 

*

Sorry, No. I don't think it's worth the effort.
Where there is nothing, nothing has to be written.

ok 
now if source is SP0 , nothing on ui 


**
Shortly, the solution I put is a kind of midway solution that will fit your requests.

with BuildClass 2 and BuildClass 3 on plugin UI you will see:

BuildClass 2 :

Install.wim : 5 Registry: Windows 10 Enterprise
Install.wim : 5 WimInfo: Windows 10 Pro
Version : 10.0.17763.1
Architecture : x86
Language : de-DE


BuildClass 3:

Install.wim : 5 WimInfo: Windows 10 Pro
Version : 10.0.17763.1
Architecture : x86
Language : de-DE


So there is no mismatch  and no sp info since source do not have service pack  and same registry cache used 

and Bonus to BuildClass2 which gives extra info about source showing Registry info and wiminfo mismatches (on most cases matches). 

I hope midway kind solutions are satisfactory enough, if so waiting for the next. 

+
I just updated "Images Configuration" Plugin, v96 on server. 

Hi Lancelot,

Sorry, there was an unfortunate misunderstanding caused by Me.

--> plugin "%ProjectDir%\Images.script" Version=096 Date=2021.04.03
    [Interface] >> WIMImageInfo_SpLevel=
    [Main] >> History094=Lancelot

...
Sorry, No. I don't think it's worth the effort.
Where there is nothing, nothing has to be written.

Please do not get this wrong.
I do not mean really "nothing" but writing (in case We use Win10 build source) either "Service Pack : blanks" or somthing like "Service Pack : not available"
or "... : N/A" - as You like.

This looks better (imo) for both BuildClasses 2 + 3, while using any build sources.
+ please do not hide - else it looks a kind of "emptiness" where there is no really need


Otherwise the other changes made for %RegistryCache% ... (same pathname for both BuildClasses 2 + 3 ) work as expected,
with the exception of
 >> [Interface] >> pCheck_ExtractWimFolder_AutoD=AutoDetect,1,3,10,181,84,18,True
when in BuildClass=2 mode.
Further comments on this in the next reply.


Have a good time.
See You.

Hi HeyJoe,

small quick comment:

>it looks  kind of "emptiness"
writing "Service Pack : not available" also sounds not right. --> It makes people thing "hmm I can make it available"--> cause wrong logic.

give me another idea to write to remove the "emptiness" feeling

"Service Pack : blablabla" ???????????

only a quick comment. 

Hi Lancelot,

"Service Pack : blablabla" ???????????

Maybe (M$ and others use this sometime for cases like this):
N/A ---> Not applicable

+


About moved "...\Tweaks\1-Wallpaper.Script" to "...\Components\1-Wallpaper.Script" in recent "Win10PE_SE_2021-03-28.zip"
to benefit from Your great working "Plugincache" mechanism 

There are 4 old refs to fix in "...\Components\WallPaper_Login.Script": See lines #65 #66 #68 #71

See You.

Thanks HeyJoe,

"WallPaper Login" v3 on server

+
Some info :
> to benefit from Your great working "Plugincache" mechanism

some details about Wallpaper plugin History022 :

Main reason is, After Wallpaper plugin there should be tweak plugins available to personalize settings related with Wallpaper plugin. It was the opposite before.

at .\Tweaks\ position Wallpaper plugin was overwriting personalized settings, now earlier at Components problem solved.

Adding it to "Plugincache" was only a nice bonus. 

+
About Service Pack ...... as you know I follow you as far as I can figure out. 

I feel changing ui position will fit your concerns.

I mean empty ui showing :

Version :
Service Pack :
Architecture :
Language :

to ---->

Version :
Architecture :
Language :
Service Pack :

This way when there is no Service pack, ServiePack ui invisible will not create emptiness feeling. 

What you think ?

Hi Lancelot,

"WallPaper Login" v3 on server

Thx, just downloaded.

+

...
Main reason is, ...

At least the right logical action avoiding overwriting personalized settings
Btw, I never noticed such "...overwriting personalized settings..." because (sorry) I don't use
  %ProjectDir%\Components\WallPaper_Login.Script
  and tweak-plugins located in:
  %ProjectDir%\Components\Core
  %ProjectDir%\Components\Tweaks
  %ProjectDir%\Components\Tweaks CMD
  %ProjectDir%\Components\Tweaks Explorer
Shortly the story behind it: Since BartPE 2.x (or earlier, can't exactly remember) I have been collecting most of My personalized settings in My so called
"Custom Part xx.script"'s which are updated from time to time or as necessary.

+

About ..."great working Plugincache mechanism"...
I would like to share the following unfortunate (to Me) story.

See reply #282 http://theoven.org/index.php?topic=1639.msg39891#msg39891 and replies downwards concerning:

Hi Noel,
...
BTW: How did You manage (in admin session) that the explorer remembers the setting changes?
Ex.: After changing the icon view (or other things) and reloading the panel, the icon view was not lost unlike in my PESE!
...

and especially:

Still, PE not saving folder settings after boot is the main "issue" ...

Explanation:

See posts around link http://theoven.org/index.php?topic=1639.msg40047#msg40047 You Noel and Me...

I still have to mention that of course the admin mode (selected by %ProjectDir%\Finals\9-Administrator.Script) is always meant
 - not the system mode itself at all.

While testing a couple of days ago Build Class 2 vs. 3 with different build sources v.1809

(
 - not finished now regarding BuildClass=2 along with pCheck_ExtractWimFolder_AutoD=AutoDetect,1,3,10,181,84,18,True
 - see plugin "%ProjectDir%\Images.script" and My Reply #34 above
)

I noticed that explorer behaves sometimes right sometimes not --> regarding the saving of changes made on folder settings and such stuff.
 - right --> My folder %GlobalTemplates% was small (just standard)
 - not right --> My folder %GlobalTemplates% was large (I maen really large content)

I wondered why The Chief PluginCache ("%ProjectDir%\Build\1-5 PluginCache_Basic.Script") kept recreating another cache
each time I exchanged (as a test) mentioned folders, even though I didn't see any real reason.
While browsing the relevant plugin(s) I noticed that the driver "fbwf.sys" was being checked by version it has and then was made MD5
caused  by %ProjectDir%\Build\2-Config.script >> [Interface] >> Custom_fbwf_CheckBox="Use Provided fbwf.sys",1,3,161,173,137,18,True
(
Perhaps We switch it off by default ? What do You think ?
)

Now (like a bolt out of the blue) I started to remember, that in ~2018 (or so) I was allowed (because of free access to TheOven that time) to download
drivers "fbwf.sys" x86/x64 from Win8 Embedded v.2.0.99.0 and put it to "%GlobalTemplates%\ProvideFile_FBWF"

Giving link about that matter: See before and after "http://TheOven.org/index.php?topic=2613.msg28655#msg28655" if interested.

Somehow I forgot that I have theese drivers on board.
Renamed folder "%GlobalTemplates%\ProvideFile_FBWF", run another build where now it uses org. win10 File based Write Filter driver.
That is: let's say mentioned "issue" finaly solved

Lancelot, Do You see, what else "great working Plugincache mechanism" can reveal ?
(To My reminder: I mustn't forget to tell Noel.)

Edit: Done. http://theoven.org/index.php?topic=1639.msg40154#msg40154

+

This way when there is no Service pack, ServiePack ui invisible will not create emptiness feeling. 

What you think ?

Hoping "emptiness feeling" on plugin UI goes away. Let's try.

See You.

Hi HeyJoe,

replying shortly shortly :

Starting with an easy one on my side being lazy 

This way when there is no Service pack, ServiePack ui invisible will not create emptiness feeling. 

What you think ?

Hoping "emptiness feeling" on plugin UI goes away. Let's try.

See You.

Build\"Images Configuration" v97 on servers. Let's see how you feel now. 

See you on next replies ....