WimUtil - Reborn! Now with 20% more fiber.

Hi all!

WimUtil 3.0 is ready for testing.

this is a major overhaul. A big thank you to Nikzzz for allowing me to wreck havoc on his program! :)

New

• improved GUI
• extract wim info to xml or .ini
• extract file option - AIK3 only
• x64 bit support
• better error handling and extensive logging
• ability to specify a custom wimgapi.dll to use

syntax help is available by starting the program without cmd line parms.

Removed

• Install/Uninstall options for wimfltr.sys have been removed to make this program compliant with MS Licensing

Debug Info
Wimutil returns the following exit codes:
;           0   - Success
;           1   - Syntax Error: The command was used incorrectly, e.g., with the wrong number of arguments, a bad flag, a bad syntax in a parameter, or whatever.
;           2   - File Not Found
;           3   - Path Not Found
;           251 - WIMCapture error
;           252 - WIMCreateFile error
;           253 - Mount Error
;           254 - UnMount Error
;           255 - Stopped by User Request.

debug logging is saved to %Temp%\Wimutil.log
errors are logged in the format: Description ( [Function Return Code], [@Error], [@extended] )
Function Returns vary based on the function and my return a handle, generally if the function returns nonzero it was successful

@Error usually refers to the following values:
;                                  0 - No DLLCall error.
;                1 - Unable to use the DLL file
;                2 - Unknown "return type"
;                3 - "function" not found in the DLL file
;               4 - Bad number of parameters.

@extended usually returns GetLastError()
values can be found here: http://msdn.microsoft.com/en-us/library/ms681381%28v=vs.85%29.aspx




the core API has been released here

happy testing!

Homes32

Known Issues

• capture gui freezes if you click anywhere during a capture. - this is an autoit issue. a possible workaround is being tested.
• /Info will cause a hard crash at random I don't know how to fix this or what specifically is causing it. - http://theoven.org//index.php?topic=101.msg1775#msg1775
• ????

Version History

Code: [Select]

3.2.0 (09/19/2011) - Homes32
- GetInfo now outputs XML as UTF16 - Thanks to JFX for suggesting.
- Fixed random crash with /info switch. - Thanks JFX

v3.1.3 (6/29/2011) - Homes32
- Fixed a bug where /Boot would never set the iBootFlag to 1
- Added timestamps to log for: capture, getattributes, getxmlinfo

v3.1.2 (05/02/2011) - Homes32
- Rewrote WriteLog()
- Added workaround for mounting with wimgapi.dll 6.0 Read-Only (http://theoven.org//index.php?topic=101.msg1648#msg1648)
- Fixed a bug where loading wimgapi.dll failed if config file exists but api key was not present.
- Minor code cleanups.

v3.1.1 (04/15/2011) - Homes32
- Fixed required # cmd line args for capture
- Changed search order for wimgapi.dll. Program will 1st look for wimutil.ini, if not specified then in @scriptDir, if not exist then look in @SystemDir.
- Extract syntax change. requires a directory path to extract instead of a directory and file name path. the old method is no longer supported. if you want to rename the file after extraction do so manually.
- Extract will now create the destination directory if it does not exist.
- WimUtil.ini now accepts paths relative to @ScriptDir
- Commands are now prefixed with /
- Some tweaks to [Info] section in .ini output.

v3.1.0 (04/08/2011) - Homes32
- Fixed mount path was not created if it didn't exist
- Only check for driver if mount/unmount
- Better error checking for wimgapi.dll and proper driver
- wimutil will look for Wimgapi.dll in @ScriptDir ; value in Wimutil.ini overrides all. you can use @SystemDir in wimutil.ini to specify use wimgapi.dll on local system.
- check wimgapi.dll version and warn if feature not available. (ex. extract/cleanup)
- if no compression option is specified capture uses /xpress compression by default
- added cleanup operation: wimutil.exe Cleanup
- added remount operation: wimutil.exe remount
- description for image capture is no longer mandatory.

Older versions are archived here

Hi Homes32,

Good news, thank you very much to you and Nikzzzz 


I did some performance tests yesterday with WimUtil7 (my modified version to use win7 wimgapi.dll and wimmount.sys), imagex (6.1.7600), dism and 7z.zip.
- Mount - Unmount with imagex.exe :   2mn46        (second test 3mn01)
- Mount - Unmount with Wimutil7.exe : 3mn18        (second test  3mn31)
- Mount - Unmount with Dism.exe :       3mn20        (second test 3mn50)
- Unzip - RemoveDir with 7z.exe :       17mn40
few seconds with Vista waik imagex.

There are many functions in addition, if you succeeded to decrease the duration, Great, to test tomorow

What about wimfltr.sys/wimmount.sys required for mount/unmount, and wingapi version 6.0.6001 or 6.1.7600. ?

First test with it, the interface is very nice, about (Rubik's cube icon), progressbar  .

Personally, I preferred the "/" for / mount / unmount ... to be like imagex.

I have a message box Mount Error: (0,0,0) if image_path don't exist. I create it, it's OK.

Another message with unmount "UnMount Error: (0,0,0)", classic for me with wimmount driver, if I open the explorer on the mounted folder, even if I go out explorer before unmount the image.
I delete the folder and it's OK (Dism /Get-MountedWimInfo : no image mounted...)

otherwise it's very good, I continue testing tomorrow

 
 WimUtil.log.txt (1.31 kB - downloaded 405 times.)

What about wimfltr.sys/wimmount.sys required for mount/unmount, and wingapi version 6.0.6001 or 6.1.7600. ?

you can use either one or switch between the 2 using wimutil.ini to set the path to the dll.
keep in mind that the extract option only works with wimgapi 6.1x

I don't have any checks in place at the moment to check if there are conflicts using wimmount.sys with wimfltr.sys running. it can be added in the future if it is found necessary.

I have a message box Mount Error: (0,0,0) if image_path don't exist. I create it, it's OK.

looks like you found a bug. Its suppose to create the mount point if it doesn't exist.
* update * fixed in next update (I was passing the wrong var to DirCreate  )

Another message with unmount "UnMount Error: (0,0,0)", classic for me with wimmount driver, if I open the explorer on the mounted folder, even if I go out explorer before unmount the image.
I delete the folder and it's OK (Dism /Get-MountedWimInfo : no image mounted...)

I think I remember seeing something like this with wimount.sys I'll have to do some testing.

Hi,

I have tested mount, unmount, info, that's fine  I do not know now if I use wiminfo or wimUtil 

I still have the issue with unmount and explorer whatever the tool used WimUtil, Imagex or Dism
It works fine if I close any explorer.

The image could not be fully unmounted.
The following files or folders could not be deleted. Please close all applications that have these files in use before trying to unmount again:

with imagex /logfile
 [6496] [ INFO ] ImageUnmarshallHandle: Reconstituting wim at E:\Windows\Win7Ultimate32\sources\install.wim.
[6496] DeleteAndRestoreDirectory:(161): The directory could not be completely unmounted.  This is usually due to applications that still have files opened within the mount directory.  Close these files and unmount again to complete the unmount process.
[6496] RestoreMountDirectory:(222): The directory could not be completely unmounted.  This is usually due to applications that still have files opened within the mount directory.  Close these files and unmount again to complete the unmount process.
[6496] WIMUnmountImageHandle:(1240): The directory could not be completely unmounted.  This is usually due to applications that still have files opened within the mount directory.  Close these files and unmount again to complete the unmount process.
[5532] [ INFO ] ImageUnmarshallHandle: Reconstituting wim at E:\Windows\Win7Ultimate32\sources\install.wim.

It seems related to the driver wimmount I do not have that issue with imagex 6.0 and wimfltr .

If I look at google, I'm not the only one having this trouble.
An idea, to bypass this issue, if after unmount the size of mounted folder is 0 then after remove directory then recrete it, twe can consider the result as OK.


No surprises on the time to mount/Unmount (here without AV), imagex remains the fastest (not redistributable)
- imagex.exe :   2mn01
- Wimutil7.exe : 2mn18
- Dism.exe :     2mn32
Good Wimfltr with Win7 SP0 

The progressbar remains static for me ?

you can use either one or switch between the 2 using wimutil.ini to set the path to the dll.
keep in mind that the extract option only works with wimgapi 6.1x

I don't have any checks in place at the moment to check if there are conflicts using wimmount.sys with wimfltr.sys running. it can be added in the future if it is found necessary.

By default WimUtil will look for wimgapi.dll in your system dir. (ie. Windows\System32)
you can overide this behavior by specifing the path to wimgapi.dll in an ini file.

WimUtil.ini
[WimUtil]
wimgapi.dll=x86\wimgapi.dll

About wimgapi, I think that it is good to the test the version 6.0 or 6.1 (blue screen).
It's good for wimutil.ini, It is necessary to put what for ScriptDir ?, personnaly, I would preferred to use wimgapi.dll from ScriptDir at first if exists and version OK (in ini with WB maybe).

To recover wimmount.inf, wimmount.sys, wimserv.exe and wimgapi.dll from source win7 DVD. Is x86 versions works on a x64 HostOS ?

 

I still have the issue with unmount and explorer whatever the tool used WimUtil, Imagex or Dism
It works fine if I close any explorer.

I can't reliably reproduce this. one time I had an issue and I ran dism /Cleanup-wim and haven't seen the problem since.

The progressbar remains static for me ?

thats a threading issue with wimgapi.dll :(
I'm testing a workaround that should correct it and the capture freeze, buts its low priority.

To recover wimmount.inf, wimmount.sys, wimserv.exe and wimgapi.dll from source win7 DVD. Is x86 versions works on a x64 HostOS ?

x86 works on x64 HostOS but you must use a 32bit wimgapi.dll (dllcall uses different int types for 32/64)
personally i made a winbuilder script that extracts the needed files with 7zip.

I still have the issue with unmount and explorer whatever the tool used WimUtil, Imagex or Dism
It works fine if I close any explorer.

I can't reliably reproduce this. one time I had an issue and I ran dism /Cleanup-wim and haven't seen the problem since.

I have every time as soon as explorer is open on my x64 Hostos (With or Without AV),
Which causes an error message at the end. To see google I'm not the only !!!

What about the idea, If the folder is empty after unmount then delete/re-creation and no error.


Yes, the progressbar is a low priority, just a feedback.

x86 works on x64 HostOS but you must use a 32bit wimgapi.dll (dllcall uses different int types for 32/64)
personally i made a winbuilder script that extracts the needed files with 7zip.

Good if x86 works on x64 hostOS   . in the other way on a x86 HostOS and x64 source, we must extract the files from SysWOW64.
I was also thinking to do this script but if you've already and want to share it.

Hi homes32,

great work indeed, congradulations 
I feel my dream of not using any service (wimfltr , wimmount etc) to build a pe2/3 coming true slowly. 
Thanks a lot.

I will join test team when I get home (tonight or at most tomorrow)
See you than.

@Chrisr

I had written history16 notes at config.script which maybe useful.

Code: [Select]

History16=Lancelot there are 2 different mount 'issues'.
History16=1) you can not mount previously mounted folder --> solution: remove folder and create again (how to reproduce: I can not remember now but I guess latest imagex/wimmount was causing this......)
History16=2) target mount folder already being used but does not seem to exists -- can not be mounted --> solution: create base folder(s) than use imagex unmount (how to reproduce: 1) mount to C:\1\2\BootWimSrc C:\1\2\InstallWimSrc 2) use rd /s /q C:\1\2 --> you get a shadow mount now --> you can not mount/unmount now ;) --> solution create C:\1\2 folder --> imagex unmount C:\1\2\BootWimSrc & C:\1\2\InstallWimSrc ;) )
History16=Info: unmount fix way (shortly): 1) check if mounted (target..cmd.exe) 1b) create mount base* folder(s) with cmd 1c) successfull unmount 2) delete folder(s) 3) make folder(s) ==> clear all the mess to remount same folder(s) :>:>:> (Happy ending untill next imagex ;))

See you. 

I have every time as soon as explorer is open on my x64 Hostos (With or Without AV),
Which causes an error message at the end. To see google I'm not the only !!!

What about the idea, If the folder is empty after unmount then delete/re-creation and no error.

I figured out how to reproduce.

Good if x86 works on x64 hostOS   . in the other way on a x86 HostOS we must extract the files from SysWOW64.
I was also thinking to do this script but if you've already and want to share it.

I wrote it for the CAPI we should discuss Image integration, but in the other thread.

Code: [Select]

[ExtractWim]
// ExtractWim,WimFile,WimIndex,Target,[File]
// #1=WimFile, #2=Index #3=Target, #4=File
If,#4,Equal,"",Run,%API%,ExtractWim_All,#1,#2,#3,#4,#5,#6,#7,#8,#9
Else,Run,%API%,ExtractWim_One,#1,#2,#3,#4,#5,#6,#7,#8,#9

[ExtractWim_All]
// #1=WimFile, #2=Index #3=Target
Echo,"Extracting all files from [#1 - Index: #2] to [#3]... (This may take awhile)"
If,ExistFile,%Tools%\%SysType%\7z.exe,ShellExecute,Hide,%Tools%\%SysType%\7z.exe,"x -y #$q#1#$q -i!#2\*.* -o#$q#3#$q"
Else,ShellExecute,Open,%Tools%\7z.exe,"x -y #$q#1#$q -i!#2\ -o#$q#3#$q"

[ExtractWim_One]
// #1=WimFile, #2=Index #3=Target, #4=File
Echo,"Extracting #4 from [#1 - Index: #2] to [#3]..."
If,ExistFile,%Tools%\%SysType%\7z.exe,ShellExecute,Hide,%Tools%\%SysType%\7z.exe,"e -y #$q#1#$q -i!#2\#4 -o#$q#3#$q"
Else,ShellExecute,Hide,%Tools%\7z.exe,"e -y #$q#1#$q -i!#2\#4 -o#$q#3#$q"
StrFormat,FILENAME,#4,%FileName%
If,ExistFile,#3\#4,Echo,"Extraction FAILED for [%FileName%] : %ExitCode% :(",Warn
If,ExistFile,#3\#4,Message,"Extractiont FAILED for [%FileName%] : %ExitCode% :(",ERROR
If,Not,ExistFile,#3\#4,Echo,"Extraction Successful :)"

Hi,

Thanks for the code and thanks for the history

I figured out how to reproduce.

Here's how I get it every time on my win7 x64 Hostos.
- I mount an image with wimutil, imagex, or dism.
- I open explorer (or already open) until the mounted folder,  not necessary get into it, just see.
- Unmount the image, and then each time I have the messagebox

- The folder is empty if I delete it, I have no more images mounted (dism /Get-MountedWimInfo)

The problem, I see in Win7Pe Se or other projects is the MessageBox that would block building (even with /hide parameter). Which will provide questions ...
According to my tests no problem to delete/recreate the folder if the folder is empty.

The problem is not in Wimutil, it is the same thing with imagex or dism. It is linked to wimgapi(6.1)/wimmount.sys.

No other problem for me for mount/unmout, great tools  , more tests later on other functions .

great work indeed, congradulations 
I feel my dream of not using any service (wimfltr , wimmount etc) to build a pe2/3 coming true slowly. 

Yes, YES

Hi homes32,

I left todays dessert to last :) but failed 

here is my test routine:
D:\1\boot.wim --> from w7sp0
D:\1\ExtractTest --> empty folder
D:\1\FilesInside --> lots of files in it

I do not have wimmount.sys installed on my hostos (xpx64), I create WimUtil.ini files on wimutil.exe x86/x64 folder
[WimUtil]
wimgapi.dll=x64\wimgapi.dll

[WimUtil]
wimgapi.dll=x86\wimgapi.dll

and put
wimgapi.dll x64 v6.1.7000.0 md5: 5284A40BD0C912FFF38B765D0641475B
wimgapi.dll x64 v6.1.7000.0 md5: 59532C3E1C35BD9F6716C8C7AC0DDB95
to relevant folders. (files from KB3AIK_EN.iso)

"WimUtil.exe x86" always gives "No drivers could be found." error, and never works.
"WimUtil.exe x64" do not give such error,

further tests with "WimUtil.exe x64"

WimUtil.exe Info "D:\1\boot.wim" D:\1\bootinfo.ini /ini
==> give "progress" screen, but no bootinfo.ini

WimUtil.exe Extract "D:\1\boot.wim" 2 D:\1\ExtractTest
==> give "Syntax Error: Not enough arguments."

WimUtil.exe Capture "D:\1\FilesInside" D:\1\Test.wim "Test"
==> give "Syntax Error: Not enough arguments."

just a note: Nikzzzz wimpack x86 working nicely to pack files to wim with wimgapi.dll 6.0.6001.18000 here on x64 for years now.

probably I am missing something , I feel I will eat my dessert later.


See you. 

The problem is not in Wimutil, it is the same thing with imagex or dism. It is linked to wimgapi(6.1)/wimmount.sys.

I think it is an issue with mimmount.sys - I realize more and more how crappy this driver is. seems that file handles get locked by explorer when the folder is open and then wimmount thinks you are still using the files/folder and invalidates the image as being in use or having corrupted files and don't release the handles....usually dism /cleanup-wim works to release them after the explorer windows is closed.
why MS decided to scrap a perfectly good filesystem overlay for a sparse filesystem I will never understand. :(

"WimUtil.exe x86" always gives "No drivers could be found." error, and never works.
"WimUtil.exe x64" do not give such error,

check for driver files is currently on program startup. I could move them to be checked on mount/unmout only.
to solve this issue.

WimUtil.exe Extract "D:\1\boot.wim" 2 D:\1\ExtractTest
==> give "Syntax Error: Not enough arguments."

wimutil.exe extract D:\1\boot.wim 2 windows\somefile.dll D:\1\ExtractTest\somefile.dll
you are missing the file to extract. the documentation is a bit off.  fixed.
I haven't tried to extract the entire image with this command. I think the api command was only meant for individual files, but i could be wrong.
its something to look into. it would be very nice to extract the entire image.

WimUtil.exe Capture "D:\1\FilesInside" D:\1\Test.wim "Test"
==> give "Syntax Error: Not enough arguments."

WimUtil.exe Capture "D:\1\FilesInside" D:\1\Test.wim "Test" "my test wim"
the description is mandatory at the moment. also I have the wrong argument count being check for, (6 instead of 5) so you will need to use a compression flag for testing until i get a new test version released. (new version will have /xpress by default if no compression option supplied)

Hi Homes32,

check for driver files is currently on program startup.

I intentionally did not add (in fact fully uninstalled) any driver (wimmount.sys - wimfltr.sys) on my hostos,
to test WimUtil capabilities (capture - extract ..... ) with only using wimgapi.dll.
with other words, My Goal is to get WimUtil work except mount-unmount.

more precisely, WimUtil work to capture with only wimgapi.dll is my priority.

WimUtil.exe Capture "D:\1\FilesInside" D:\1\Test.wim "Test" "my test wim"

Syntax Error: Not enough arguments.

**
it would be nice to add wimgapi.dll to WimUtil.exe as WimUtil feature on next version, without requiring WimUtil.ini , and priority to wimgapi.dll if exists on wimutil.exe folder,
this way it would be easier to test wimgapi.dll versions and easier script writing......

Further, I decide to test GImageX to capture:
Both x86-x64 GImagex work fine here with only adding x86-x64 wimgapi.dll to its folder.

making speed test to compare (numbers after 2nd capture to avoid windows cache misresult), with 840MB "D:\1\FilesInside\" result test.wim 132MB
x64 --> 2m10s
x86 -->  2m49s
to me both good enough, since in practice numbers varies, you never know why x86 faster than x64 time to time..... 

Waiting for new version  . See you. 

Hi Homes32,

..... why MS decided to scrap a perfectly good filesystem overlay for a sparse filesystem I will never understand. :(

Yes I do not understand also, wimfltr worked so well


I have continue testing WimUtil with success for all options

Here's my feedback for future improvements.

it would be nice to add wimgapi.dll to WimUtil.exe as WimUtil feature on next version, without requiring WimUtil.ini , and priority to wimgapi.dll if exists on wimutil.exe folder,
this way it would be easier to test wimgapi.dll versions and easier script writing......

Yes, I think also and, No need to write wimutil.ini
     [WimUtil]
     wimgapi.dll=wimgapi.dll

Is it possible to have the flags capture, extract, info, mount, unmount like other flags with "/"
and like imagex, it would be easier for understanding and for scripts writing.

WimUtil info, forbid the file wimutil.ini (conflict then)
If flags /ini placed before the out_file, it creates a file ini to root drives.
 

WimUtil launched from a batch(or others) gives an error if the batch is not in the current folder.
     error loading library: (-1,2, wimgapi.dll)
     the file could not be found.

WimUtil.exe Extract "D:\1\boot.wim" 2 D:\1\ExtractTest
==> give "Syntax Error: Not enough arguments."

Yes, you should add /xpress for now.
WimUtil.exe Capture "D:\1\FilesInside" D:\1\Test.wim "Test" "my test wim" /xpress

the description is mandatory at the moment. also I have the wrong argument count being check for, (6 instead of 5) so you will need to use a compression flag for testing until i get a new test version released. (new version will have /xpress by default if no compression option supplied)

Yes for the optional description and, maybe, take the image_name if not sent, and Yes also for /xpress as default value (optional)

WimUtil.exe Capture (source = 4 Mo) with /lzx processing files is OK and after nothing.

WimUtil.exe extract
Is it possible to make the filename in destination_path not mandatory, just the folder path (it would be, in this case, identical to the filename image)
domage that we can not retrieve the entire image or a folder !


Good continuation and see you soon for the tests of the next version



ps: Here is an example of batch to test WimUtil, to use with the following folder structure :
choice root folder eg E:\WimUtil
   --- 1
   -------- mount
   --- SourceDir (I put in install.wim or other files)
   --- Wim       (I put in install.wim or other files image)
   --- x64       (x64 files: imagex, wimgapi.dll, WimUtil.exe, WimUtil.ini)
   --- x86       (x84 files: imagex, wimgapi.dll, WimUtil.exe, WimUtil.ini)
   TestWimTools.cmd
   ResultTestxxx.txt

 WimUtil.7z (901.47 kB - downloaded 304 times.)

new version is up for testing. changlong and download in 1st post.

wimutil will now only look for drivers if the operation requires them. (mount/unmount/etc.)

WimUtil.exe extract
Is it possible to make the filename in destination_path not mandatory, just the folder path (it would be, in this case, identical to the filename image)
domage that we can not retrieve the entire image or a folder !

not possible.
extract option can only extract a single file. its the only way MS designed the command to work. I added the ability to "apply" (aka extract all) so you can extract the entire image to a folder. you should use the /hide option on apply if it freezes with the GUI. apparently ms implemented multi-threading into this command on newer wimgapi.dll and it causes autoit to have a stroke dealing with the progress callbacks. 

Yes, I think also and, No need to write wimutil.ini
     [WimUtil]
     wimgapi.dll=wimgapi.dll

changed. wimutil will 1st look in the current dir for wimgapi.dll UNLESS wimutil.ini specifies a path.

Is it possible to have the flags capture, extract, info, mount, unmount like other flags with "/"
and like imagex, it would be easier for understanding and for scripts writing.

its possible. the current implementation is leftover from Nikzzzz
does anyone else have a comment on how the command line should be structured?
should I switch to using /mount and /MountDir: syntax like dism???

happy testing!
Homes32

Hi Homes32,

Thank you very much for the update and the new features   .

WimUtil.exe extract
Is it possible to make the filename in destination_path not mandatory, just the folder path (it would be, in this case, identical to the filename image)

what I meant, is to make the filename Optional in desination_path (just the filename) and in this case, use the filename of the image_path.  This is not a priority.

WimUtil.exe Extract install.wim 1 windows\system32\wimgapi.dll %Tools%\%OSArch%
     Input becomes (with some au3 code)
WimUtil.exe Extract install.wim 1 windows\system32\wimgapi.dll %Tools%\%OSArch%\wimgapi.dll


I have a problem on the extraction with (log attached : Error Failed to extract from image. Make sure your path exist (0,0,0))
E:\WimUtil\x64\WimUtil.exe extract  E:\WimUtil\Wim\Test.wim 1 Driverx64\wimgapi.dll E:\WimUtil\extract\wimgapi.dll
The same command line with version 3.0.0 works well.

changed. wimutil will 1st look in the current dir for wimgapi.dll UNLESS wimutil.ini specifies a path.

I think there is a misunderstanding about wimgapi.dll,
The idea is to use the one of the current folder if exists and otherwise to use the one from @SystemDir (do not remove it please). Unless the path to wimgapi.dll is indicated in  wimutil.ini

does anyone else have a comment on how the command line should be structured?
should I switch to using /mount and /MountDir: syntax like dism???

Personally, I do not like the syntax for dism (too complicated), I prefer the one of imagex.
It seems well to harmonize all flags /hide, /ini, /boot, ... and therefore have /mount, /unmount, /capture, ... which are flags for me.
It's just cosmetic and just my opinion but I think good for wimutil.


I'm in weekend with family, before a holiday week and I have difficulties to advance on my developments.
Have a nice weekend  .
Chris

 WimUtil.log.txt (0.69 kB - downloaded 352 times.)

Hi Homes32,

Fantastic 
I can easly capture now without any service 

*
I hope you find the workaround for the "stroke" issue, from my experience I can clearly say, same "stroke" issue also happens on c, c++, delphi... written utilities when not workarounded..... so far I can also reproduce by changing wimutil windows (ctrl+tab), if i do not change the window, stroke gui seem not hapening.


*
minor thing
WimUtil.exe Capture "D:\1\FilesInside" D:\1\Test.wim "Test" /xpress
works
WimUtil.exe Capture "D:\1\FilesInside" D:\1\Test.wim "Test"
not
;).

**
Thanks again for the hard work.   

Hi homes32,

I finished developments (at last awaiting for amendment and validation) of Win7PE SE for use also with Win7 SP1 as source CD and of course WimUtil.
See topics Win7PE SE things.


Several trials successfully (Win7 x86/x64 SP1) using WimUtil and the new package
I have, by cons, some problems with Wimfltr and Wimgapi6.0 (Mount Error: (0,0,2).
 WimUtil.log.txt (2.19 kB - downloaded 634 times.)

Thank you for this beautiful work and thank you for continuing improvements of this great tools    

 

New version ready!

WimUtil.exe extract
Is it possible to make the filename in destination_path not mandatory, just the folder path (it would be, in this case, identical to the filename image)

what I meant, is to make the filename Optional in desination_path (just the filename) and in this case, use the filename of the image_path.  This is not a priority.

ok I understand. done.

I have a problem on the extraction with (log attached : Error Failed to extract from image. Make sure your path exist (0,0,0))
E:\WimUtil\x64\WimUtil.exe extract  E:\WimUtil\Wim\Test.wim 1 Driverx64\wimgapi.dll E:\WimUtil\extract\wimgapi.dll
The same command line with version 3.0.0 works well.

this should be fixed now

I think there is a misunderstanding about wimgapi.dll,
The idea is to use the one of the current folder if exists and otherwise to use the one from @SystemDir (do not remove it please). Unless the path to wimgapi.dll is indicated in  wimutil.ini

changed.

It seems well to harmonize all flags /hide, /ini, /boot, ... and therefore have /mount, /unmount, /capture, ... which are flags for me.
It's just cosmetic and just my opinion but I think good for wimutil.

changed.

minor thing
WimUtil.exe Capture "D:\1\FilesInside" D:\1\Test.wim "Test" /xpress
works
WimUtil.exe Capture "D:\1\FilesInside" D:\1\Test.wim "Test"
not
;).

oops. fixed!  :)

Several trials successfully (Win7 x86/x64 SP1) using WimUtil and the new package
I have, by cons, some problems with Wimfltr and Wimgapi6.0 (Mount Error: (0,0,2).

_WIM_MountImage (0,0,2) means that the wimgapi.dll mount command set ERROR_FILE_NOT_FOUND (0x2)

I finished developments (at last awaiting for amendment and validation) of Win7PE SE for use also with Win7 SP1 as source CD and of course WimUtil.
See topics Win7PE SE things.

I should have some time this weekend to start looking. Have a good vacation!

New version ready!

- Fixed required # cmd line args for capture
- Changed search order for wimgapi.dll. Program will 1st look for wimutil.ini, if not specified then in @scriptDir, if not exist then look in @SystemDir.
- Extract syntax change. requires a directory path to extract instead of a directory and file name path. the old method is no longer supported. if you want to rename the file after extraction do so manually.
- Extract will now create the destination directory if it does not exist.
- WimUtil.ini now accepts paths relative to @ScriptDir
- Commands are now prefixed with /
- Some tweaks to [Info] section in .ini output.

GREAT, thank you very much for these improvements 

Tested :
- the search order for wimgapi
- the extract syntax (without the filename in directory path)
- Commands prefixed with /
- mount - unmount with wimgapi 6.1
- capture without the optionnal parameter /xpress
- capture with flags /lzx (max compression)
All this works well   
 


I still have the same problem with wimgapi 6.0 and wimfltr.
I do not understand the reason of ERROR_FILE_NOT_FOUND (0x2)

wimfltr is installed on my win7x64 hostOS and I have, in the same folder, imagex.exe, wimgapi.dll (6.0) and WimUtil
The same command line with imagex works
E:\WimUtil\x64\WimUtil.exe /mount E:\WimUtil\Wim\Test.wim 1 E:\WimUtil\1\Mount     (Mount Error: (0,0,2)
E:\WimUtil\x64\imagex.exe /mount E:\WimUtil\Wim\Test.wim 1 E:\WimUtil\1\Mount      (work)

I finished developments (at last awaiting for amendment and validation) of Win7PE SE for use also with Win7 SP1 as source CD and of course WimUtil.

I will update in accordance with the flags / (see Win7PE SE things).

See you