use SDK + DLL for Progress the progress for the smv.exe (console) is not realy useful (compare with the GUI progress -> looks more like a freece than a progress) a progress just slow down the command execution
I will look and try to use the DLL with PowerShell. My progress bar now is the file size from smv.exe lv and then the file size already written. That's how I get the progress these days.
use oune of this Spoiler Code: typedef BOOL(DFSCALLBACK * tSetExtractPosCallBack) (dfuLong32 dwPos, dfvoidp dfpAdditionnalInfo, dfvoidp dfUserPtr); /***********************************************************************************************/ int SVFAPI ApplyMonofilePatchEx2(const char* base,int base_only_dir, const char*patch,const char*dest, ERROR_MOMENT *perr_moment, int* perrinfo,char* errBufTxt,int errBufSize,dfuLong32 dfExtractingMethod, tSetExtractPosCallBack pSetExtractPosCallBack,dfvoidp dfUserPtr, dfuLong32 dwMinProgress,dfuLong32 dwMaxProgress); int SVFAPI ApplyMonofilePatchMemoryEx2(const char* base,int base_only_dir, const void*patch_buffer,size_t patch_size, const char*dest, ERROR_MOMENT *perr_moment, int* perrinfo,char* errBufTxt,int errBufSize,dfuLong32 dfExtractingMethod, tSetExtractPosCallBack pSetExtractPosCallBack,dfvoidp dfUserPtr, dfuLong32 dwMinProgress,dfuLong32 dwMaxProgress); /***********************************************************************************************/ int SVFAPI ApplyMultiFilePatchEx3(const char* base, int base_only_dir, const char*patch, const char*dest, int onlyMonoFileBase, ERROR_MOMENT *perr_moment, int* perrinfo, char* errBufTxt, int errBufSize, dfuLong32 dfExtractingMethod, dfuLong32 dfBaseVersionSpecified,dfuLong32 dfVersionSpecified, tSetExtractPosCallBack pSetExtractPosCallBack, dfvoidp dfUserPtr, dfuLong32 dwMinProgress, dfuLong32 dwMaxProgress); int SVFAPI ApplyMultiFilePatchMemoryEx3(const char* base, int base_only_dir, const void*patch_buffer, size_t patch_size, const char*dest, int onlyMonoFileBase, ERROR_MOMENT *perr_moment, int* perrinfo, char* errBufTxt, int errBufSize, dfuLong32 dfExtractingMethod, dfuLong32 dfBaseVersionSpecified, dfuLong32 dfVersionSpecified, tSetExtractPosCallBack pSetExtractPosCallBack, dfvoidp dfUserPtr, dfuLong32 dwMinProgress, dfuLong32 dwMaxProgress); they have CallBack (tSetExtractPosCallBack + dfvoidp dfUserPtr (in case you want more user-infos) usual set dfvoidp dfUserPtr = NULL tSetExtractPosCallBack pSetExtractPosCallBack,dfvoidp dfUserPtr, but you must fist create (register) the CallBack function and then apply the pointer to the to the SVFAPI you must also set dfuLong32 dwMinProgress,dfuLong32 dwMaxProgress if you have problems send me PM (dont discuss this here - just blow up the Tread)
If you want uses the DLL, you can email me or contact on skype, google hangout or other channel Note : I'm surprised people uses 32 bits version. I suppose this is more for linux than windows (we can reuse very old computer to create good linux 32 bits servers).
My first shareware, WinImage was used by a lot of people to copy 1.7 MB 'DMF' Windows 95 floppy My other software SmartVersion is used to store Microsoft ISO here SmartVersion can also be useful for storing difference between Virtual Machine. Two Windows 10 (same edition) virtual machine, or two Linux (same distribution) Virtual Machine share a lot of thing. So create a svf between two VM (inclusing VM from different virtualized) can be useful. Create a patch between two 20 GB file can take time. We need SSD, a lot of memory, and uses high -nbhashbits value (27 by example) and probably -minalign (by example 16 or 256)
[-minalign #] : select the minimal alignement of data. Default 1 useful for virtual machine : if minalign 16 is selected, we expect location of a block in old and new version are aligned on 16 bytes bondiaries creating patch can be faster but there is risk bigger patch if we don't detect a block to copy on a virtual machine image, we can imagine block are often aligned on clister size, so minalign 256 can be tested do you understand ? is more for paches from big source / taged like a vm file (eg 50GB)
no realy, but this can be also intested for win10 iso's (coc big wim files) must be tested. iso's are aligned at sector size (2048byte) -> 8, 16, 32, 64, 128, 256, 1024 must be tested the result depend on the contens of the iso EDIT: see https://forums.mydigitallife.net/threads/smartversion-tools-scripts.79415/page-13#post-1599052
-minalign give very bad result on Microsoft ISO : Wim are not aligned. But I had two vhdx : two virtual Machine of Windows 10 edition 2004 (in fast, two older edition, upgraded to 2004, then cleanmgr under administrative mode, then sdelete -z to clean all unused file and old version) test under win10 on a 32 GB memory system source VHDX size is 21 GB target VHDX size is 17 GB (less software installed) First, I used buildpatch with smv buildpatch patch128.svf source.vhdx target.vhdx -compressratio 128 -minalign 256 -nbhashbits 27 It generate a 1.7 GB svf file. compressratio 128 generate svf with chuck compressed using LZ4 (you can also use 160, uncompressed, but I prefer 128 which uses very very fast LZ4) It take only 5 minutes ! Without -minalign and -nbhashbits you need far more time I can then convert to a 1.3 GB Svf in 90 seconds (zstd 179) or 1.2 GV in 10 minutes (zstd 192): smv m patch128.svf patch179.svf -recompress -compressratio 179 smv m patch128.svf patch192.svf -recompress -compressratio 192 These two conversion/recompress read only patch128.svf and don't need the original vhdx. I think storing a lot of Windows 10 virtual machine with different configuration, different virtualizer with only 1 or 2 GB svf file can be useful
feedback from G Vollant so this only speed up the patch creation a little bit but more memory used tested 24 and 28 = in most case exact the same svf created
I don't think it's the same, the other guide started from only svf files and instructed how to create consumer/business isos, this one starts from a svf file and a iso.