Jump to content











Photo
- - - - -

Minimal fileset for installing an ADK Optional Component?


  • Please log in to reply
46 replies to this topic

#1 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 04 January 2018 - 08:58 AM

So wimgapi.dll is (in my opinion anyway) buggy as hell. Mount and Unmount commands can fail and it is consequently unpredictable using this via WinBuilder / PEBakery to build a WinPE.

Using synchronicity's excellent wimlib-imagex :worship: it is possible to mount EXTRACT the contents of a .wim and use DISM to apply/install an ADK Optional Component. This is a relatively slow process due to the need to extract the full contents of the .wim file before running DISM and then rebuilding the .wim.

So how about just extracting a minimal fileset and running DISM - for example just extracting the minimum files required for DISM to run? And then injecting the updates back into the original .wim.

So how about just extracting a minimal fileset and running DISM - for example just extracting the minimum files from the .wim required for DISM to run apply a package to these extracted files? And then injecting the updates back into the original .wim.

Anyone have any experience with this? I've done a quick test with just registry files and DISM failed. The DISM log is not helpful (for me).

:cheers:

Misty


_____________________________________________________________


EDIT
Getting closer by extracting the following files/directories and then running DISM -
\Windows\System32\SSShim.dll
\Windows\System32\config\
\Windows\servicing\
\Windows\System32\Dism\
\Windows\System32\wdscore.dll
 
Deployment Image Servicing and Management tool
Version: 6.3.9600.16384


Error: 161

The directory D:\MistyPE\Projects\Cache\Adk.workspace4\mount\Windows does not appear to be a valid Windows directory.
Ensure that the /WinDir option that is specified is valid. For more information, refer to the help by running DISM.exe /WinDir /?.
And just some of the errors from the DISM log file -
2018-01-04 09:33:49, Info                  DISM   DISM Provider Store: PID=3188 TID=196 Getting the collection of providers from a local provider store type. - CDISMProviderStore::GetProviderCollection
[3188] [0x80070002] FIOReadFileIntoBuffer:(1415): The system cannot find the file specified.
[3188] [0xc142011c] UnmarshallImageHandleFromDirectory:(511)
[3188] [0xc142011c] WIMGetMountedImageHandle:(2568)
_____________________________________________________________

EDIT ON 5th Jan 2018 at 07:42am

I've made this edit to try and clear up some of the ambiguity in my original post. Sorry to all involved so far from post #1 to post #22 for my poor wording which has led to misundertandings. In my defence, I have been up late coding and getting by on an average of about 4-5 hours sleep per night for nealy two weeks. Not helped by an excess of alcohol over the New Year period!

My original goal was -
1] use a full Windows Host OS with an ADK installed (initial tests on 64-bit Windows 8.1 Update Host OS with the ADK for Windows 8.1 installed).
2] use wimlib to extract the minimum files from winpe.wim (.wim is from the ADK already installed on the host OS) that will allow me to complete step 3 (see below).
3] use the full DISM (from the ADK) to apply an Optional Component (aka Package) to the files extracted in step 2].
4] use wimlib to inject any added/modified files created in step 3] back into winpe.wim.

If this is possible then by extracting just a few files instead of the full contents of winpe.wim there will be a significant increase in the speed of the extraction process. The injection process should also be significantly faster than building a new .wim.

DISM appears to check for a number of files in the mounted (or in my case extracted) .wim file and if these files are not found it will error. For example -
...Error: 161

The directory MY.PATH\mount\Windows does not appear to be a valid Windows directory....
And when more files were extracted from winpe.wim some progress was made and DISM was able to recognise the extracted files as a WinPE and started the package installation process (but still resulted in an error) -
...Processing 1 of 1 - Adding package WinPE-WMI-Package~31bf3856ad364e35~amd64~~6.3.9600.16384
An error occurred - WinPE-WMI-Package Error: 0x80070003

Error: 3

The system cannot find the path specified.
The misunderstanding -

Due to the poor wording and ambiguity of my original post the goal was taken to be finding the minimal DISM dependencies required to run DISM to add an Optional Component/package to a (fully?) extracted winpe.wim file. Maybe facilitating the package installation process without the need to install the full ADK.

Erwan.l summarises the confusion in post #19






Indeed there seems to be a confusion (at least i was confused at first) between 2 topics :

#1-which minimal file set is needed on the host to run dism (i focused on that topic while adopting a developper approach : can we come with a "tiny" / minimal / new dism based on dismapi.dll only to do some basics)

#2-which minimal file set in needed in the wim file (or vhd i guess) to be able to run command such as add-package or add-driver


Erwan then goes on to really hit the nail on the head in terms of future development and my new goal -





Actually both topics may be connected : dism.exe is a black box and there may be some un necessary extra steps in there.

A new custom dism.exe could help achieve both goals : less dependency on the host and less logic when mounting/updating a wil/vhd file.


So apologies again for any confusion I caused. But then lets not forget that this has led to more interesting experiments :whistling:

:cheers:

Misty

#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 January 2018 - 11:23 AM

Would a "normal" trace with Dependency Walker help?

Do the .dll's need to be registered?

Which specific Windows version(s) are you experimenting with?

 

:duff:

Wonko



#3 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 04 January 2018 - 12:16 PM

Thinking loud, would it be worth it to come with a more minimalist version of dism implementing only the features you need, possibly with less dependencies ?

I could give a try and provide a version implementing only addpackage or addriver or addfeature a try.

 

Regards,

Erwan



#4 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 04 January 2018 - 12:16 PM

@Wonko

Would a "normal" trace with Dependency Walker help?

Probably!
 

Which specific Windows version(s) are you experimenting with?

Host Operating System is Windows 8.1 Update (6.3.9600).

ADK is for also for Windows 8.1.
 

Do the .dll's need to be registered?

Highly unlikely! When the full contents of boot.wim (unmodified - from ADK for Windows 8.1) are extracted, then DISM runs successfully.

In my experment with minimal paths/files extracted from the same boot.wim, DISM fails. My theory is that something/file that DISM checks is missing in the test environment with minimal extracted files - just not sure what.

Regards,

Misty

P.s. I've attached DISM logs. One from a failed build and the other from the successful build when the full contents of boot.wim was extracted.

Attached File  DISM_logs.zip   15.7KB   0 downloads

#5 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 04 January 2018 - 12:20 PM

Thinking loud, would it be worth it to come with a more minimalist version of dism implementing only the features you need, possibly with less dependencies ?
I could give a try and provide a version implementing only addpackage or addriver or addfeature a try.
 
Regards,
Erwan

I'm using the DISM included in the ADK (for Windows 8.1) download. Any input however would be greatly appreciated - with whichever DISM version you have to hand. I will try again with a full (but empty of files) directory structure to see if that makes a difference.

:cheers:

Misty

#6 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 04 January 2018 - 12:26 PM

I'm using the DISM included in the ADK (for Windows 8.1) download. Any input however would be greatly appreciated - with whichever DISM version you have to hand. I will try again with a full (but empty of files) directory structure to see if that makes a difference.

:cheers:

Misty

 

My idea was to directly use DismAPI.dll as I suspect that dism.exe does a few checks, requires extra dependencies, etc.

If my theory is right, then you would "only" have to fetch dismapi.dll from the right imaging solution (waik, adk, 8.0,8.1,10.0, etc ...) to be able to perform basic task such as adding a package.

I will quickly put up a simple exe and see how it looks.

Might be a red herring but it worth testing.


  • misty likes this

#7 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 04 January 2018 - 12:37 PM

My idea was to directly use DismAPI.dll as I suspect that dism.exe does a few checks, requires extra dependencies, etc.
If my theory is right, then you would "only" have to fetch dismapi.dll from the right imaging solution (waik, adk, 8.0,8.1,10.0, etc ...) to be able to perform basic task such as adding a package.
I will quickly put up a simple exe and see how it looks.
Might be a red herring but it worth testing.

Sounds great. Cheers Erwan

:cheers:

Misty

#8 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 04 January 2018 - 03:20 PM

Sounds great. Cheers Erwan

:cheers:

Misty

 

check PM : i have put a dirty dism GUI using dismapi.dll (found in my system where adk/waik is not installed).

 

with some luck, there may be a way to be able to perform tasks such as adddriver, addpackage, addfeature without having waik/adk installed, which added to the excelent wimlib feature could come handy...


  • Atari800XL and misty like this

#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 January 2018 - 04:57 PM

@Misty

 

Get GetWaikTools:

http://www.msfn.org/...-the-huge-isos/

and check what it downloads, should be for 8.1 (32-bit) :

Waiktoolsnew\Waik_4_1\x86\Dism

27/04/2014  15.45    <DIR>          .
27/04/2014  15.45    <DIR>          ..
21/08/2013  20.17            10.752 api-ms-win-downlevel-advapi32-l1-1-0.dll
21/08/2013  20.14            11.776 api-ms-win-downlevel-advapi32-l1-1-1.dll
21/08/2013  20.15             4.096 api-ms-win-downlevel-advapi32-l2-1-0.dll
21/08/2013  20.14             7.680 api-ms-win-downlevel-advapi32-l2-1-1.dll
21/08/2013  20.14             3.072 api-ms-win-downlevel-advapi32-l3-1-0.dll
21/08/2013  20.14             3.584 api-ms-win-downlevel-advapi32-l4-1-0.dll
21/08/2013  20.14            38.400 api-ms-win-downlevel-kernel32-l1-1-0.dll
21/08/2013  20.14             8.704 api-ms-win-downlevel-kernel32-l2-1-0.dll
21/08/2013  20.13             5.632 api-ms-win-downlevel-ole32-l1-1-0.dll
21/08/2013  20.14             7.168 api-ms-win-downlevel-ole32-l1-1-1.dll
21/08/2013  20.17             9.728 api-ms-win-downlevel-shlwapi-l1-1-0.dll
21/08/2013  20.14            10.752 api-ms-win-downlevel-shlwapi-l1-1-1.dll
21/08/2013  20.14             4.096 api-ms-win-downlevel-user32-l1-1-0.dll
21/08/2013  20.14             3.584 api-ms-win-downlevel-user32-l1-1-1.dll
21/08/2013  20.14             3.072 api-ms-win-downlevel-version-l1-1-0.dll
21/08/2013  21.02           131.688 compatprovider.dll
21/08/2013  21.02           203.880 dism.exe
18/06/2013  04.59            26.327 dism.Format.ps1xml
18/06/2013  04.59             1.761 dism.psd1
18/06/2013  04.59               423 dism.psm1
18/06/2013  04.59            16.726 dism.Types.ps1xml
21/08/2013  21.02           456.296 dismapi.dll
21/08/2013  21.02           297.064 dismcore.dll
21/08/2013  21.02            76.904 dismcoreps.dll
21/08/2013  21.02           191.592 dismprov.dll
21/08/2013  21.03            55.400 folderprovider.dll
21/08/2013  21.03           604.264 imagex.exe
21/08/2013  21.03           147.048 imagingprovider.dll
21/08/2013  21.03           120.432 logprovider.dll
21/08/2013  21.03           124.520 Microsoft.Dism.Powershell.dll
21/08/2013  21.03           210.536 pkgmgr.exe
21/08/2013  21.03           124.520 ssshim.dll
21/08/2013  21.03           439.920 vhdprovider.dll
21/08/2013  21.03           541.296 wimgapi.dll
21/08/2013  21.03            36.464 wimmount.sys
21/08/2013  21.03            32.360 wimmountadksetup.exe
21/08/2013  21.03           403.048 wimprovider.dll
21/08/2013  21.03           435.816 wimserv.exe

and for AMD64:

Waiktoolsnew\Waik_4_1\amd64\Dism

27/04/2014  15.45    <DIR>          .
27/04/2014  15.45    <DIR>          ..
22/08/2013  03.45            10.752 api-ms-win-downlevel-advapi32-l1-1-0.dll
22/08/2013  03.43            11.776 api-ms-win-downlevel-advapi32-l1-1-1.dll
22/08/2013  03.43             4.096 api-ms-win-downlevel-advapi32-l2-1-0.dll
22/08/2013  03.43             7.680 api-ms-win-downlevel-advapi32-l2-1-1.dll
22/08/2013  03.43             3.072 api-ms-win-downlevel-advapi32-l3-1-0.dll
22/08/2013  03.43             3.584 api-ms-win-downlevel-advapi32-l4-1-0.dll
22/08/2013  03.43            38.400 api-ms-win-downlevel-kernel32-l1-1-0.dll
22/08/2013  03.43             8.704 api-ms-win-downlevel-kernel32-l2-1-0.dll
22/08/2013  03.41             5.632 api-ms-win-downlevel-ole32-l1-1-0.dll
22/08/2013  03.43             7.168 api-ms-win-downlevel-ole32-l1-1-1.dll
22/08/2013  03.45             9.728 api-ms-win-downlevel-shlwapi-l1-1-0.dll
22/08/2013  03.43            10.752 api-ms-win-downlevel-shlwapi-l1-1-1.dll
22/08/2013  03.43             4.096 api-ms-win-downlevel-user32-l1-1-0.dll
22/08/2013  03.43             3.584 api-ms-win-downlevel-user32-l1-1-1.dll
22/08/2013  03.43             3.072 api-ms-win-downlevel-version-l1-1-0.dll
22/08/2013  04.17           165.992 compatprovider.dll
22/08/2013  04.17           261.224 dism.exe
18/06/2013  07.24            26.327 dism.Format.ps1xml
18/06/2013  07.24             1.761 dism.psd1
18/06/2013  07.24               423 dism.psm1
18/06/2013  07.24            16.726 dism.Types.ps1xml
22/08/2013  04.17           642.664 dismapi.dll
22/08/2013  04.17           363.112 dismcore.dll
22/08/2013  04.17           165.480 dismcoreps.dll
22/08/2013  04.17           247.400 dismprov.dll
22/08/2013  04.17            64.624 folderprovider.dll
22/08/2013  04.17           711.272 imagex.exe
22/08/2013  04.17           193.640 imagingprovider.dll
22/08/2013  04.17           146.024 logprovider.dll
22/08/2013  04.17           124.008 Microsoft.Dism.Powershell.dll
22/08/2013  04.17           211.560 pkgmgr.exe
22/08/2013  04.17           140.904 ssshim.dll
22/08/2013  04.17           641.128 vhdprovider.dll
22/08/2013  04.17           650.856 wimgapi.dll
22/08/2013  04.17            40.552 wimmount.sys
22/08/2013  04.17            34.408 wimmountadksetup.exe
22/08/2013  04.17           518.248 wimprovider.dll
22/08/2013  04.17           518.256 wimserv.exe

of course most probably some of the files are not needed, but you can try with the whole set above and delete what seems like unuseful until the *whatever* commands you need stop working.

:duff:

Wonko



#10 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 04 January 2018 - 05:38 PM

On a "clean" win7 x64 system, without adk nor waik installed, without dismapi.dll :

 

I used GetWaikTools, and downloaded "dism for win8.1" (ADK_5).

In the x86 sub folder, I was able to call the following dismapi.dll function : initialize, opensession, adddriver, closesession but not the mount/unmount functions.

 

Looks good so far then as Misty is not looking for mount/unmount (task performed by Wimlib).

 

Edit : mount/unmount functions work as well (the destination folder shall not exist before calling mount).



#11 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 04 January 2018 - 05:56 PM

Misty, how do you know which files to extract from the boot.wim, are you saying you only want to extract a subset of the files and "apply" the new packages "onto" these files? Are you saying there's a list of "affected files" in these packages?


Edited by Atari800XL, 04 January 2018 - 05:57 PM.


#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 January 2018 - 06:16 PM

@erwan.l

 

Sure it works :) , the point is (was) if some (many) of those files are not needed for Misty's uses, i.e. the minimal needed fileset.

 

:duff:

Wonko



#13 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 04 January 2018 - 06:23 PM

@erwan.l

 

Sure it works :) , the point is (was) if some (many) of those files are not needed for Misty's uses, i.e. the minimal needed fileset.

 

:duff:

Wonko

 

I am in the process of asserting that you only need dismapi.dll and its dependencies.

I am pretty sure all other files are not needed.

At least this what my custom exe tells me loading dismapi.dll and calling a few functions.

 

VqwZtcV.png

 

h8db2OL.png



#14 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 January 2018 - 08:05 PM

I am in the process of asserting that you only need dismapi.dll and its dependencies.

I am pretty sure all other files are not needed.

At least this what my custom exe tells me loading dismapi.dll and calling a few functions.

 

Good :),

and I am in the process of asserting that once you will have renamed (or deleted if you have the guts for it :whistling: ) the files not listed by your custom.exe and the stupid DISM will work nonetheless (for the whatever set of commands Misty *needs*), then you will have a validated minimal list of files. (which is the expected final result of the experiment)

 

:duff:

Wonko

 

P.S. No, wait, I already asserted that :w00t: :ph34r:



#15 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 04 January 2018 - 08:43 PM

Misty, how do you know which files to extract from the boot.wim....

I don't - not yet anyway. I managed to get a bit further, but am still running into errors.
 

...are you saying you only want to extract a subset of the files and "apply" the new packages "onto" these files?...

Yes - only the smallest number of files possible in order to get DISM to work. DISM appears to check a number of files in the mounted (or extracted) .wim and if these are not present then DISM will fail to apply the package. The advantage of extracting a smaller set of files (if it works) will be less time extracting the files and then injecting them and the newly applied optional component files back into the base .wim via wimlib after the packages are applied.

There should not really be a need for many files to be extracted, however it's difficult to trace them all. My wimlib file list so far, and if any of these are missing then there are various errors -
;files - 
\Users\Default\NTUSER*
\Windows\System32\KernelBase.dll
\Windows\System32\ntdll.dll
\Windows\System32\SSShim.dll
\Windows\System32\wdscore.dll
;full directories -
\Windows\servicing\
\Windows\System32\config\
\Windows\System32\Dism\
\Windows\System32\SMI\
\Windows\WinSxS\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.3.9600.16384_none_fa1dc1539b4180d8\
\Windows\WinSxS\Catalogs\
\Windows\WinSxS\Manifests\
It's still not working, but it's getting closer.

Misty

EDIT
Added DISM log -
Attached File  DISM_logs2.zip   11.35KB   0 downloads

#16 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 04 January 2018 - 08:48 PM

I'm not an expert on this, but doesn't this work like update files in Windows? Do the Optional Package files contain a list of files to be modified? Abbodi1406 seems to be one of the experts on Windows update files, maybe he also knows how these Optional Package files are constructed?

#17 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 04 January 2018 - 09:12 PM

@Misty

Get GetWaikTools:
http://www.msfn.org/...-the-huge-isos/.....

...of course most probably some of the files are not needed, but you can try with the whole set above and delete what seems like unuseful until the *whatever* commands you need stop working.
:duff:
Wonko

@Wonko
You are kind of missing the point of my little experiment. My goal is about tracing which (minimal set of) files need extracting from my WinPE .wim file so that DISM on my Host OS can apply a package (Optional Component) to the extracted WinPE files.

Whilst tracing the required DISM files is a nice distraction, it is not the goal. Or was not the original goal anyway :whistling:

If I can get away with extracting lets say 100MB of files from my .wim file and apply a package to only those files then I can avoid extracting the full contents of my .wim - saving significant time. Hope this makes sense.

Misty

#18 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 04 January 2018 - 09:18 PM

 

@Wonko
You are kind of missing the point


Them's fightin' words :-)

#19 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 04 January 2018 - 09:32 PM

Indeed there seems to  be a confusion (at least i was confused at first) between 2 topics :

 

#1-which minimal file set is needed on the host to run dism (i focused on that topic while adopting a developper approach : can we come with a "tiny" / minimal / new dism based on dismapi.dll only to do some basics)

 

#2-which minimal file set in needed in the wim file (or vhd i guess) to be able to run command such as add-package or add-driver

 

Actually both topics may be connected : dism.exe is a black box and there may be some un necessary extra steps in there.

A new custom dism.exe could help achieve both goals : less dependency on the host and less logic when mounting/updating a wil/vhd file.

 

Regards,

Erwan



#20 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 04 January 2018 - 10:08 PM

Good :),

and I am in the process of asserting that once you will have renamed (or deleted if you have the guts for it :whistling: ) the files not listed by your custom.exe and the stupid DISM will work nonetheless (for the whatever set of commands Misty *needs*), then you will have a validated minimal list of files. (which is the expected final result of the experiment)

 

:duff:

Wonko

 

P.S. No, wait, I already asserted that :w00t: :ph34r:

 

Well, I am not 100% ok with that.

 

Using dism.exe from MS and calling the API (from dismapi.dll) directly may lead to different results : we dont know for sure what extra steps are undertaken in dism.exe.

Also, calling the API directly may lead to more interesting developpement in the future where more tasks can be automated and/or mixed with other tools such as wimlib.

 

Ideally it would be nice to deal with WIM files without any dependency to MS tools.

Wimlib was a major outbreak already and many winpe tools these days are built on that.

Unfortunately we still need dism to perform some extra steps such as adding drivers or packages.

 

But I am deviating from Misty objective there.

I surely dont want to hijack his thread :)



#21 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 04 January 2018 - 10:28 PM

Using dism.exe from MS and calling the API (from dismapi.dll) directly may lead to different results : we dont know for sure what extra steps are undertaken in dism.exe.
Also, calling the API directly may lead to more interesting developpement in the future where more tasks can be automated and/or mixed with other tools such as wimlib.
 
Ideally it would be nice to deal with WIM files without any dependency to MS tools....

:thumbsup:
 

...But I am deviating from Misty objective there.
I surely dont want to hijack his thread :)

Please hijack away - this is getting interesting. And if I don't get any closer to my original goal then the community may get some extra tools out of it anyway. A little Christmas bonus.

:cheers:

#22 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 04 January 2018 - 11:10 PM

Some nice (and very fast) work from Erwan has led to several builds to test.

 

I've successfully added WMI and NetFx packages to a WinPE image mounted in Erwan's new tool. Can't wait to see where this goes.

 

:worship:



#23 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 05 January 2018 - 08:22 AM

My original post has been edited to try and clear up any confusion to anyone new to this discussion. Sorry Wonko in particular as you have educated me on numerous past occasions about the benefits of being more specific about my questions. And for the record I am not being sarcastic!

:cheers:

Misty

#24 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 January 2018 - 09:24 AM

Ok, after MIsty's and erwan.l's clarification, now I understand maybe . :w00t: :ph34r:.

 

Allow me to re-state the points at hand (please bear with me, I am trying to understand).

 

What I understood (and still understand):

1) The nice tool by JFX allows to download the WAIK tools (from various AIK's/WAIK's versions), among them the whole DISM lot

2) once you have used the tool to download the DISM, the DISM works on a system that has never seen the WAIK before

3) hence the files needed to run DISM are EXACTLY those that the tool downloads

4) most probably only a subset of those files are needed to perform the limited chores that are the scope of the test/idea/experiment

 

End of part 1.

 

Now, if I get this right there is part 2 where the attempt is to "service" a set of extracted files.

 

And here I am losing both of you.

 

If I get it right, the whole DISM "servicing" stuff is intended to service a WIndows installation, either "flat" or inside a .wim (or as erwan.l's mentioned a .vhd, that as I see it is only a container for a "flat"), so the new question is which minimal, "fake" Windows installation can be serviced by DISM?

 

If that is the case, I am perplexed as to how the files in the extracted, minimal, "fake Windows installation can be later be inserted/merged to the original .wim :dubbio:

 

I am talking not of the files added by the DISM apply-package, but rather about the related Registry entries, registrations, etc. :unsure:

 

I mean, it is entirely possible that "package 1" *needs* files a, b, c BUT that "package 2" *needs* files a,b, c and d, then, it is possible that in the .wim file d is a hard link to another file, would DISM take care of that?

 

As well, it is possible that some paths are kept, so that the "temporary target" needs to be a mounted RAW image or a .vhd as to recreate the same folder structure as the "real thing".

 

In any case IMHO, the (nice BTW) "external" or "direct" approach by erwan.l, needs anyway to be validated against the results from using the original DISM, i.e. we need first to be able to do that with DISM, and then check if the (faster, better) interface to dismapi.dll works the same.  

 

What I suspect - in other words - is that only *some* packages (the simpler ones) can be applied and re-inserted properly in the .wim, whilst more complex ones will need either more files extracted or some trick/workaround.

I am preoccupied about possible "false positives", i.e. packages that *seem* to have been serviced and reapplied correctly but that on execution (possibly of a specific. particular command/option) fail in the final build, and it is probably a nightmare to fully test the functionalities of the results.

 

Of course as long as the specific packages that are *needed* to be serviced and re-applied are of the simple type the idea/method by erwan.l is very good  :thumbup: .

 

:duff:

Wonko



#25 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 05 January 2018 - 10:58 AM

...Ok, after MIsty's and erwan.l's clarification, now I understand maybe . :w00t: :ph34r:.

:thumbsup: (maybe :whistling:)


.....
3) hence the files needed to run DISM are EXACTLY those that the tool downloads
4) most probably only a subset of those files are needed to perform the limited chores that are the scope of the test/idea/experiment.....

The full DISM fileset downloaded using JFX's getwaiktools are definitly not all required. Although I haven't traced all dependencies yet, with just the .dll files (and associated .mui files) Erwan's tinydism is working.

 

...If I get it right, the whole DISM "servicing" stuff is intended to service a WIndows installation, either "flat" or inside a .wim ....so the new question is which minimal, "fake" Windows installation can be serviced by DISM?

If that is the case, I am perplexed as to how the files in the extracted, minimal, "fake Windows installation can be later be inserted/merged to the original .wim :dubbio:

I am talking not of the files added by the DISM apply-package, but rather about the related Registry entries, registrations, etc. :unsure:

With wimlib-imagex. If the registry files are part of the minimal fileset extracted from the WinPE .wim then any modification made to the registry by DISM will theoritically be present when the file is injected back into the .wim via wimlib. MistyPE uses this approach of extracting, modifying and injecting the registry files and it functions fine.
 

...In any case IMHO, the (nice BTW) "external" or "direct" approach by erwan.l, needs anyway to be validated against the results from using the original DISM, i.e. we need first to be able to do that with DISM, and then check if the (faster, better) interface to dismapi.dll works the same

What I suspect - in other words - is that only *some* packages (the simpler ones) can be applied and re-inserted properly in the .wim, whilst more complex ones will need either more files extracted or some trick/workaround.
I am preoccupied about possible "false positives", i.e. packages that *seem* to have been serviced and reapplied correctly but that on execution (possibly of a specific. particular command/option) fail in the final build, and it is probably a nightmare to fully test the functionalities of the results...

If we are talking about using TinyDISM then it appears to add the packages to a full WinPE correctly. Tested using HTA, WMI and NetFx packages from Windows 8.1 ADK. The full DISM is reporting all packages on the fully extrated .wim files as installed. I tested the new .wim in a VM and it appears to function fine. Notice that I have used the word appears - you are correct that more validation needs to be done. And we are some distance from testing against a subset of extracted WinPE files rather than the fully extracted or mounted contents.

:cheers:

Misty

P.s. I'm supposed to be at work!




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users