Nicely done, thanks... Now let's clear redundant manifests in DEDUP_v8-1_b9600 pack ) BTW: In version v1-1 the support of following syntax will be nice: Code: sxsexpand_v1-1.exe *.* C:\Decomp Hmmm, right manifests for dedup packages (from redundant ones)... )) Code: amd64_microsoft-windows-d..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_cs-cz_5b4a4754601fab7d.manifest amd64_microsoft-windows-d..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_cs-cz_83b2cc96058f25ea.manifest amd64_microsoft-windows-d..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_en-us_9ea092b0471a07db.manifest amd64_microsoft-windows-d..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_en-us_c70917f1ec898248.manifest amd64_microsoft-windows-f..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_cs-cz_5778fc6c4e1c06ce.manifest amd64_microsoft-windows-f..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_cs-cz_e9b6849ac5087dc1.manifest amd64_microsoft-windows-f..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_en-us_2d0ccff6ac02da1f.manifest amd64_microsoft-windows-f..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_en-us_9acf47c83516632c.manifest amd64_microsoft-windows-v..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_cs-cz_0a172836a9e722ea.manifest amd64_microsoft-windows-v..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_en-us_4d6d739290e17f48.manifest
Wildcards not permitted. Far too much work, quite frankly. It was hard enough doing it in my package extraction script. If you're absolutely insistent, FORFILES is your friend, and way more powerful than wildcards. Bonus airy-fairy notion: I wonder if Windows would take exception to you decompressing the entirety of %SystemRoot%\WinSxS?
I meant running Windows with it's entire SxS repository decompressed, that is, completely undoing the 'improvement' Microsoft made in Windows NT 6.3. Must... resist... urge to... start Windows PE... and... do it...
working as it promise on Windows 8.1 For fun, i test it on "compressed" binary by KB2821895 on windows 8 and got you your first exception Code: Exception EInOutError in module SxSExpand.EXE at 0000A558 I/O error 103.
Ohh, definitely need to look into that. I thought I made the I/O routines absolutely bomb-proof. Bonus request for information: Any possibility of attaching the offending file? It would make my life much easier.
Good job Bubbs, now don't forget, you promised to find me that winpe-srt.cab. I bet it's on the system reserved partition in the recovery folder, via the winre.wim image #1. Here are the manifests I see for SRT on x86.
it looks like it will crash if the source file is not a compressed file, can you detect that and exist gracefully ? Code: Exception EInOutError in module SxSExpand.EXE at 0000A558. I/O error 103. Code: ntoskrnl.exe!KiCpuId+0xb6 ntoskrnl.exe!KeWaitForMutexObject+0x138b ntoskrnl.exe!KeWaitForMultipleObjects+0x25d ntoskrnl.exe!ObWaitForMultipleObjects+0x297 ntoskrnl.exe!MmCommitSessionMappedView+0xb6a ntoskrnl.exe!KeSaveStateForHibernate+0x2a33 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x536 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x9e wow64.dll!Wow64SystemServiceEx+0x26a wow64.dll!Wow64LdrpInitialize+0x435 ntdll.dll!LdrGetKnownDllSectionHandle+0x1b5 ntdll.dll!RtlUniform+0x182 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!ZwWaitForMultipleObjects+0xc KERNEL32.DLL!WerpLaunchAeDebug+0x170a KERNEL32.DLL!WerpLaunchAeDebug+0x18b4 KERNEL32.DLL!BasepReportFault+0x19 ntdll.dll!RtlAllocateHeap+0xbc SxSExpand.EXE+0x3f34 ntdll.dll!RtlRaiseStatus+0x86 ntdll.dll!KiUserExceptionDispatcher+0xf SxSExpand.EXE+0xa558 KERNEL32.DLL!BaseThreadInitThunk+0xe ntdll.dll!RtlInitializeExceptionChain+0x85 ntdll.dll!RtlInitializeExceptionChain+0x58
That fooled me at first, then someone reminded me those are just the language packs, (en-us, en-gb, etc) and that the actual winpe-srt.cab is not available in the "WinPE_OCs" parent folder with all the other .cabs.
Yep, thanks for that. As NaiveUser pointed out, it crashes on anything that isn't actually a SxS BDC file. I've fixed up the offending code - you can tell I'm sleep deprived: half the I/O functions were outside the exception handler - and now it will exit gracefully, and will even try to decompress files that lack the SxS BDC header, but appear to be BDC files. Which brings me, in a roundabout way, to a revelation: that winload.exe you sent me is not a SxS BDC file. It's not even a 'delta-less' BDC file. Even if it didn't crash, my tool wouldn't have been able to decompress it for you. It's only 60KB, yet the header says it will produce a >1MB file. It's clearly expecting a source file to 'delta' off of. Sorry. I promised you no such thing, sir. However, I will (when I wake up) be generating my own WinPE-SRT packages for WinPE 5.0, and I'll be more than happy to offer them to anyone willing to take them. Yep, you only get a real WinPE-SRT package if you back a truckfull of money up to Steve Ballmer, and licence the OEM Preinstallation Kit - which the AIK/ADK is a cut-down version of. But anyway, OP update shortly with new, less-buggy version.
Successfully extracted WinPE-SRT feature pack from winre.wim all hail for the precious tool Spoiler note about microsoft-windows-w..oc-srt-registrykeys_31bf3856ad364e35_6.3.9600.16384_none_0c13da62af650cca.manifest although its name and description is related to SRT package, but it's not connected or a part of it directly i saw no refference for it in any of the manifests, and i add it to the .cab, but when testing integration it's not gets integrated with SRT pack.
Code: SxSExpand input-file output-file output-file can be a folder path input-file must be on the same partition as SxSExpand