Check Target System Files

It would probably be faster and easier not to add mui and mun files in the AddFiles sections and not to do it in macros either
And only do it at the end of the build before capturing boot.wim
It would be a big change, what do you think about it ?

Require_FileQ is back, one way or another idea is same. 

1 single line so end user no need to think about mui or mun files. Which seems you miss through a year.

time is naturally same on my side here, ~12 seconds with full mui and mun files.   

and no need bulk syntax on your side which does not exists on my side anyway..

circle development......

Thanks for the feedback, it confirms that it is quite fast, even with the full mui and mun files.
It also helps to avoid forgetting resources file when done by hand

I don't really miss, but it's a good addition
I added its call in "Create ISO" before capturing boot.wim

Small comments about the display

Code: [Select]

[Win10XPE_AddFiles]
; cdosys.dll.mui   (Orphan Resources Files) - cdosys.dll does not exit in winre.wim but it exists in install.wim
; clfs.sys.mui   (Orphan Resources Files) - clfs.sys is in drivers folder
; dxgkrnl.sys.mui   (Orphan Resources Files) - dxgkrnl.sys is in drivers folder
; dxgmms2.sys.mui   (Orphan Resources Files) - dxgmms2.sys is in drivers folder
; mpsdrv.sys.mui   (Orphan Resources Files) - mpsdrv.sys is in drivers folder
; psmodulediscoveryprovider.mfl   (Orphan Resources Files) - same in winre.wim or install.wim
; Windows.CloudStore.dll.mui   (Orphan Resources Files) - it is done intentionally, the mui is required for Pintool but not the dll
; wcncsvc.dll.mui   (Orphan Resources Files) - wcncsvc.dll does not exit in SysWOW64\en-US\ same in winre.wim or install.wim

There is also: \Windows\SystemResources\Taskmgr.exe.mun  added bur it is not necessary with the old boot.wim task manager

In CheckSysFiles.exe I will probably exclude anomalies for drivers, if finished by ".sys.mui"
And When time allows, I'll add maybe an ini file with an exclusion list

It would probably be faster and easier not to add mui and mun files in the AddFiles sections and not to do it in macros either
And only do it at the end of the build before capturing boot.wim
It would be a big change, what do you think about it ?

I have prepared 2 similar packages, the base with few plugins, to test the time saving
In the 2nd, I removed All the extraction of mui and mun files, in the list files and in AddFiles sections.

That sounds pretty good, 20% faster here 

Win10XPE_2019-03-21.7z (17.4 Mb)             Project time: 10 minutes, 52 seconds
Win10XPE_2019-03-21_NoMui.7z (17.4 Mb)  Project time:   8 minutes, 38 seconds

I'll remove the test packages tomorrow or the day after 
Do you have about the same gain ?

Edit: not really the same conditions, the durations are ~fixed

First Run - Non MUI
Project time: 4 minutes, 24 seconds and 85 milliseconds

First Run - Std
Project time: 4 minutes, 15 seconds and 273 milliseconds

Edit::

Second Run - Non MUI
Project time: 2 minutes, 58 seconds and 545 milliseconds

Second Run - Std
Project time: 2 minutes, 59 seconds and 234 milliseconds

Thanks for the feedback, it confirms that it is quite fast, even with the full mui and mun files.
It also helps to avoid forgetting resources file when done by hand

There is yet again a misconception about speed,
Current WimBuilderUI builds at 146 seconds. (First run )
slore reply 89 http://theoven.org/index.php?topic=2390.msg32420#msg32420

WimBuilderUI.v20190320 updated(with PECMD, StartIsBack,WinXShell,PENetwork)

If there is a speed race, slore will always win, the previous (induction) or new method (deduction) does not matter.
induction: adding mun mui files during build
deduction: adding mun mui files at the end of the build

Deduction Advantages Disadvantages you wrote on your previous post
- Advantages - better speed
- some special cases occur as you wrote at "Small comments about the display"

WimBuilderUI will build faster in the future and there will be more accurate comparison in the future...
 It is not surprise, me at WimBuilder Topic since the first day,
Lancelot Reply 1 2018-01-26, 13:37:37 »
http://theoven.org/index.php?topic=2390.msg25730#msg25730
  Passing time with slore hard work proves I am right again. 
    I only hope slore do not get some pms with misguiding to wrong directions in future like all others or with other reasons.... , time will show.

*
Personally, I am after optimum speed, I like the luxury. 
Probably Ferrari 288 GTO first car go over 300km/h , better than using ThrustSSC even today.

I don't really miss, but it's a good addition

Admitting requires time. 

When I wrote winbuilder is slow ~10 years ago, I got reactions similar to teik, dazza
  and deaf developers ( with tons of misconceptions post games )
   Time proved I am right again.
     Such things only cause Waste time .......

I added its call in "Create ISO" before capturing boot.wim

We all Naturally follow slore.
Lancelot reply 88 2019-03-03, 13:12:24
http://theoven.org/index.php?topic=2390.msg31988#msg31988

but for today, I may add a mandatory plugin before post-config for that goal following your path. 
or directly inside postconfig...

btw, to avoid misconception, my speed test result (~12 seconds full mun and mui) is with Win10PESE by adding ALL mun and mui files following system32 with a beta plugin (not "Check Target System Files") .
 Same result on current topic.
  It will be less after adding only additional files (I guess similar result on current topic ~1 second)
   speed results will be naturally close. 

More Testing Results for XPE -

28 Apps > Non-Mui

Code: [Select]

Build Core Version[2] ( )  57.950 seconds
 Mouse Keys Version[2] ( )  0.578 seconds
 NonVisual Desktop Access Version[4] ( )  5.569 seconds
 BurnDataCD Version[4] ( )  1.109 seconds
 ImgBurn Version[2] ( )  0.469 seconds
 IsoBurner Version[4] ( )  0.406 seconds
 WinX DVD Copy Pro Version[1] ( )  2.750 seconds
 Common Components Version[1] ( )  2.502 seconds
 DirectX Version[1] ( )  5.011 seconds
 HotSwap! Version[1] ( )  0.609 seconds
 MS Windows Media Player Version[3] ( )  5.297 seconds
 WinCalc Version[1] ( )  and1.000 seconds
 7-Zip Version[4] ( )  4.132 seconds
 AOMEI Partition Assistant Version[3] ( )  12.250 seconds
 Macrium Reflect Free Version[8] ( )  3.674 seconds
 MiniTool Partition Wizard 11 Version[1] ( )  6.969 seconds
 MPC-BE Version[1] ( )  3.533 seconds
 Mozilla Firefox ESR Version[2] ( )  4.284 seconds
 FastStone Capture Version[1] ( )  1.204 seconds
 Sumatra PDF Version[2] ( )  1.458 seconds
 RegShot2 Version[1] ( )  0.250 seconds
 McAfee Stinger Version[1] ( )  2.953 seconds
 Norton Power Eraser Version[1] ( )  1.766 seconds
 Windows Login Unlocker Version[4] ( )  0.250 seconds
 Process Monitor Version[1] ( )  0.766 seconds
 ServiWin Version[1] ( )  0.219 seconds
 Desktop Personalization Version[3] ( )  2.546 seconds
 Create ISO Version[2] ( )  18.049 seconds

 28 scripts processed.
 Project time: 2 minutes, 27 seconds and 745 milliseconds

[Win10XPE_AddFiles]
; cdosys.dll.mui   (Orphan Resources Files)
; clfs.sys.mui   (Orphan Resources Files)
; dxgkrnl.sys.mui   (Orphan Resources Files)
; dxgmms2.sys.mui   (Orphan Resources Files)
; mpsdrv.sys.mui   (Orphan Resources Files)
; psmodulediscoveryprovider.mfl   (Orphan Resources Files)
; Windows.CloudStore.dll.mui   (Orphan Resources Files)
; wcncsvc.dll.mui   (Orphan Resources Files)

28 Apps > Std-Mui

Code: [Select]

Build Core Version[2] ( )  67.395 seconds
 Mouse Keys Version[2] ( )  0.672 seconds
 NonVisual Desktop Access Version[4] ( )  5.595 seconds
 BurnDataCD Version[4] ( )  1.344 seconds
 ImgBurn Version[2] ( )  0.485 seconds
 IsoBurner Version[4] ( )  0.390 seconds
 WinX DVD Copy Pro Version[1] ( )  2.722 seconds
 Common Components Version[1] ( )  2.579 seconds
 DirectX Version[1] ( )  4.705 seconds
 HotSwap! Version[1] ( )  0.687 seconds
 MS Windows Media Player Version[3] ( )  6.094 seconds
 WinCalc Version[1] ( )  0.937 seconds
 7-Zip Version[4] ( )  3.733 seconds
 AOMEI Partition Assistant Version[3] ( )  12.127 seconds
 Macrium Reflect Free Version[8] ( )  3.375 seconds
 MiniTool Partition Wizard 11 Version[1] ( )  7.328 seconds
 MPC-BE Version[1] ( )  3.320 seconds
 Mozilla Firefox ESR Version[2] ( )  4.414 seconds
 FastStone Capture Version[1] ( )  1.203 seconds
 Sumatra PDF Version[2] ( )  1.364 seconds
 RegShot2 Version[1] ( )  0.252 seconds
 McAfee Stinger Version[1] ( )  3.469 seconds
 Norton Power Eraser Version[1] ( )  1.860 seconds
 Windows Login Unlocker Version[4] ( )  0.218 seconds
 Process Monitor Version[1] ( )  0.567 seconds
 ServiWin Version[1] ( )  0.187 seconds
 Desktop Personalization Version[3] ( )  2.349 seconds
 Create ISO Version[2] ( )  15.906 seconds

 28 scripts processed.
 Project time: 2 minutes, 35 seconds and 482 milliseconds

[Win10XPE_AddFiles]
; cdosys.dll.mui   (Orphan Resources Files)
; clfs.sys.mui   (Orphan Resources Files)
; dxgkrnl.sys.mui   (Orphan Resources Files)
; dxgmms2.sys.mui   (Orphan Resources Files)
; mpsdrv.sys.mui   (Orphan Resources Files)
; msimsg.dll.mui   (Orphan Resources Files)
; psmodulediscoveryprovider.mfl   (Orphan Resources Files)
; Windows.CloudStore.dll.mui   (Orphan Resources Files)
\Windows\System32\en-US\D3DSCache.dll.mui
\Windows\System32\en-US\imagesp1.dll.mui
\Windows\System32\en-US\joy.cpl.mui
; rtutils.dll.mui   (Orphan Resources Files)
; wcncsvc.dll.mui   (Orphan Resources Files)
\Windows\SysWOW64\en-US\joy.cpl.mui
\Windows\SysWOW64\en-US\poqexec.exe.mui

PS:
I Installed a Stage IV Performance Kit On My 2017 Harley Davidson CVO Limited Motorcycle - Performance Went From 74HP to 126Hp - It Is Still A Harley Davidson Motorcycle...
 

PS:
I Installed a Stage IV Performance Kit On My 2017 Harley Davidson CVO Limited Motorcycle - Performance Went From 74HP to 126Hp - It Is Still A Harley Davidson Motorcycle...
 

Sadly not the case here anyway. Still mixing apple with banana.

Let me know when you get Ferrari 288 GTO same speed with ThrustSSC 

or since you like Motorcycle :
Let me know when your Harley Davidson Motorcycle have the close speed to Ack Attack https://en.0wikipedia.org/wiki/Ack_Attack

 

Just Glad To Get The Extra Performance...

Just Glad To Get The Extra Performance...

At last, we have a point to agree. 

 

Just Testing and Trying To Fine Tune in Hopes To Get A Little Extra Speed and Performance ..

Just a tip, you can build much much more faster by not using plugins or xpeplugins but custom folder .... etc. etc...

I am away from such thing,
 I always like my luxuries,
  I like to get faster with luxuries I like, with your example:
    " Stage IV Performance Kit On 2017 Harley Davidson CVO Limited Motorcycle "
      not The Fastest.... 

Nope, Not the fastest.. But Comfortable For Two Up Riding and Has More HP Then Most V-Twin Touring Bikes..

Nope, Not the fastest.. But Comfortable For Two Up Riding and Has More HP Then Most V-Twin Touring Bikes..

I already agree on my previous post.

Keep an eye around, you will see a lot HP the way you write on Plugin world.
With some more luxirary and probably speed. 

Good side of current topic on my side,
With Require_FileQ equilavant adjustments,
It will be easier for converters (people who convert)
Eg. Oscar XPE2PESE converter (XPEPlugin to Plugin converter)
http://theoven.org/index.php?topic=2751.0
---》 luxirary    eg. End user have less trouble with file requirement, better Harley Davidson 


...

End user have less trouble with file requirement, better Harley Davidson

I Noticed Your Tuning Improvements Already.. It Just Takes Time, Testing and Feedback From Others..

.. It Just Takes Time, Testing and Feedback From Others..

Good you are Learning 
Previous eg. Ms media player

Ps.
Just to clear I have not tune converters.
 And not added BuildCore 3 support publicly yet.
  I follow my personal vision of perfection, which takes time.
   It would be much more easy to have speed features without perfection 3 or 4 months ago.
 
Anyway too much of topic  ..

Testing Feedback Build Core

Code: [Select]

; cdosys.dll.mui   (Orphan Resources Files)

Missing Explorer_AddFiles ->  Windows\System32\cdosys.dll
Did Not Find *.dll.mui Extraction

**************
; msimsg.dll.mui   (Orphan Resources Files)

Missing Explorer_AddFiles ->  Windows\System32\msimsg.dll
Did Not Find *.dll.mui Extraction - Fixed If MSI Selected

**************
; clfs.sys.mui   (Orphan Resources Files)
; dxgkrnl.sys.mui   (Orphan Resources Files)
; dxgmms2.sys.mui   (Orphan Resources Files)
; mpsdrv.sys.mui   (Orphan Resources Files)

Run SystemCheck For Missing *.sys.mui ->  System32/Drivers\*

**************
; psmodulediscoveryprovider.mfl   (Orphan Resources Files)
; Windows.CloudStore.dll.mui   (Orphan Resources Files)

Write SystemCheck Exception ->  psmodulediscoveryprovider.mfl
Write SystemCheck Exception ->  Windows.CloudStore.dll.mui  <- Required For Pintool..

Note: If,ExistFile,Windows.CloudStore.dll,FileDeleteQ <- Because File Causes Win10XPE Unusable..

The time difference is marginal between App Extraction vs PostConfig Extraction
With Slight Time Advantages Using PostConfig Extraction and Better For User Development

I see no need to change ways - But as a Final PostConfig SystemCheck is great...

Thanks for the postcard already well drawn
With a Harley and a Ferrari, I didn't get a chance to drive.
I am waiting for much more feedback to learn how to drive these racing machine

Thanks for your tests and results James, really fast building, you have a racing PC 
Not much difference for you, a little more here but it evolves all the time. 
In principle, it should be a little better but not much more

But it's easier for writing, I will continue on the Non-Mui base shared yesterday

But it's easier for writing, I will continue on the Non-Mui base shared yesterday

 

I have added some exceptions in CheckSysFiles.script for now

I'll see for an exclusion file in checkSysfiles.exe.
I already have an optimized procedure to check strings with WildCards. For now, ".sys.mui" for mui Drivers is hard coded.

For those who want to test with 19H1 (VMware is not compatible for now, VirtualBox or hyperV are) 
Win10XPE_2019-03-23.7z (17.4 Mb)

With latest changes, it remains a beta and I'll take it off a little later.

For those who want to test with 19H1 (VMware is not compatible for now, VirtualBox or hyperV are) 

Thank you for the update!

Both the x86 and x64 19H1 tests went great and I was able to open every program I tried, see desktop.

Switch to Admin mode never did switch and left me with a black screen and a cursor with an hourglass when I tested it on the x64 build. As a test, 17763 gave the same bad results with the new code so that may say something.

Good stuff!