Windows Imaging API and DllCall

[Ixel]

Has anyone out there tried to use DllCall with wimgapi.dll -- the Windows Imaging API that comes with Windows AIK? I'm having trouble getting a few of the functions to work (i.e. WimApplyImage, WIMCaptureImage). Below is what I have so far. This code will create the file but not do any capture.

Const $WIM_Flag_Verify = 0x00000002
Const $WIM_Flag_Index = 0x00000004
Const $WIM_Flag_No_Apply = 0x00000008
Const $WIM_Generic_Read = 0x80000000
Const $WIM_Generic_Write = 0x40000000
Const $WIM_Open_Existing = 0x00000003
Const $WIM_Flag_Share_Write = 0x00000040
Const $WIM_Flag_FileInfo = 0x00000080
Const $WIM_Compress_None = 0x00000000
Const $WIM_Create_New = 0x00000001
Const $WIM_Create_Always = 0x00000002

wimgapi = DllOpen("C:\Program Files\Windows AIK\Tools\x86\wimgapi.dll")
$create = DllCall ($wimgapi, "int", "WIMCreateFile", "wstr", "C:\winre_x86\boot1.wim", "int", $WIM_Generic_Write, "int", $WIM_Create_Always, "int", $WIM_Flag_Share_Write, "int", $WIM_Compress_None)
DllClose($wimgapi)

$wimgapi = DllOpen("C:\Program Files\Windows AIK\Tools\x86\wimgapi.dll")
$capture = DllCall($wimgapi, "int", "WIMCaptureImage", "ptr", $create, "wstr", "C:\winre_x86\mount2", "int", $WIM_Flag_Verify)
DllClose($wimgapi)

Here's some API info:

WIMCreateFile

C++

HANDLE

WINAPI

WIMCreateFile(

IN LPWSTR lpszWimPath,

IN DWORD dwDesiredAccess,

IN DWORD dwCreationDisposition,

IN DWORD dwFlagsAndAttributes,

IN DWORD dwCompressionType,

OUT LPDWORD lpdwCreationResult

);

WimCaptureImage

C++

HANDLE

WINAPI

WIMCaptureImage(

IN HANDLE hWim,

IN LPWSTR lpszPath,

IN DWORD dwCaptureFlags

);

Edited March 8, 2007 by Ixel

[PaulIA]

Has anyone out there tried to use DllCall with wimgapi.dll -- the Windows Imaging API that comes with Windows AIK? I'm having trouble getting a few of the functions to work (i.e. WimApplyImage, WIMCaptureImage). Below is what I have so far. This code will create the file but not do any capture.

Const $WIM_Flag_Verify = 0x00000002
Const $WIM_Flag_Index = 0x00000004
Const $WIM_Flag_No_Apply = 0x00000008
Const $WIM_Generic_Read = 0x80000000
Const $WIM_Generic_Write = 0x40000000
Const $WIM_Open_Existing = 0x00000003
Const $WIM_Flag_Share_Write = 0x00000040
Const $WIM_Flag_FileInfo = 0x00000080
Const $WIM_Compress_None = 0x00000000
Const $WIM_Create_New = 0x00000001
Const $WIM_Create_Always = 0x00000002

wimgapi = DllOpen("C:\Program Files\Windows AIK\Tools\x86\wimgapi.dll")
$create = DllCall ($wimgapi, "int", "WIMCreateFile", "wstr", "C:\winre_x86\boot1.wim", "int", $WIM_Generic_Write, "int", $WIM_Create_Always, "int", $WIM_Flag_Share_Write, "int", $WIM_Compress_None)
DllClose($wimgapi)

$wimgapi = DllOpen("C:\Program Files\Windows AIK\Tools\x86\wimgapi.dll")
$capture = DllCall($wimgapi, "int", "WinCaptureImage", "ptr", $create, "wstr", "C:\winre_x86\mount2", "int", $WIM_Flag_Verify)
DllClose($wimgapi)

Here's some API info:

WIMCreateFile

C++

HANDLE

WINAPI

WIMCreateFile(

IN LPWSTR lpszWimPath,

IN DWORD dwDesiredAccess,

IN DWORD dwCreationDisposition,

IN DWORD dwFlagsAndAttributes,

IN DWORD dwCompressionType,

OUT LPDWORD lpdwCreationResult

);

WimCaptureImage

C++

HANDLE

WINAPI

WIMCaptureImage(

IN HANDLE hWim,

IN LPWSTR lpszPath,

IN DWORD dwCaptureFlags

);

I haven't used the DLL that you are refering to, but I see a couple of problems in your example:

1. The prototype definition for WIMCreateFile has 6 parameters but your implementation only passes 5. You are not passing a pointer to a DWORD for lpdwCreationResult.

2. In your implementation for WimCaptureImage, you spelled the function name wrong. You have "WinCaptureImage" instead of "WimCaptureImage" as in your prototype.

3. I find it odd the the developers of the DLL would mix prefix case. In the first example, you have "WIMCreateFile" and in the second example (assuming you correct your spelling error), you have "WimCaptureImage". I may be wrong on this, but I believe that DLL function names are case sensitive.

4. In your implementation of WimCaptureImage, you are passing $create as the handle. Assuming that WIMCreateFile returns a handle, you should be passing $create[0]. Remember that DLL call returns an array with position 0 as the result and the rest of the array consisting of the call fields.

5. This is just preference, but in writing Auto3Lib, I discovered there is very little difference in using DLLOpen/DLLClose and just passing the DLL name in DLLCall. So small in fact, it wasn't worth writing the open/close lines for 1,000+ API calls.

That should get you a little farther down the road...

[Danny35d]

I haven't tried yet, but this is a link for FeReNGi script.

[Ixel]

I'm one of those people who if they work long enough on something, they start making stupid mistakes (the misspelling pointed out by PaulIA is a perfect example). I now have the code working with the understanding that one of the parameters in the DllCall had to call a handle that was stored as an element in an array. Thanks, guys, for chiming in on this.

[Björn Kaiser]

I know this is pushing dead threads, but I'am wanting to know if anyone has got something together with wimgapi.dll. Otherwise I fear I have to learn DllStruct so that I can build a UDF for wimgapi.dll by myself.

EDIT:

I'm building on it myself now, so far capture and apply seem to work. Next on my todo-list is setting it up with callback support, which should not be a big problem, thanks to piccaso.

here is what i got together so far, wimgapi.au3 contains the function definitions and the path to wimgapi.dll (not to mention its very far from being documented completely). I'm open for any ideas on enhancing it, especially when it comes to error catching (I'm not programming around worst case scenarios most of the time).

imagex.zip

--

links:

#384128

http://www.msfn.org/board/index.php?showto...st&p=669384

Edited August 6, 2007 by Björn Kaiser

[Björn Kaiser]

got an update, tried to get the documentation in the wimgapi.au3 on the level of the AutoIt3 default includes.

Callback function works, but only for capture, trying to use the callback function for applying an image will result in the program locking up. Seems we are not alone on that, here is the eventual reason of this trouble (quoted from https://forums.microsoft.com/msdn/showpost....6&pageid=1)

I had a response from Microsoft which explains the thinking :

"The only difference between capture and apply regarding WIM_MSG_PROGRESS is that with capture the message is sent from the main thread (the WIMGAPI thread) while during apply the message is sent from a different thread that was spawned off from the WIMGAPI main thread.

At one time we implemented multi-threaded restore (2 threads per CPU). This has since been turned off but we kept the progress on a different thread than the main thread restoring files and directories in order to easily turn on this scenario again at a later date."

I'm not sure this fully explains why the IDE locks up though?

Maybe I just need more coffee...

Anyone got some bright ideas so I can have a callback function for the apply process?

wimgapi.002.zip

[piccaso]

ximage/wmigaip comes with vista, right?

so i cant help you much here (unless there is a way to install it on xp)

but if you post the prototype for the callback function you want (i guess you allready have the sdk) i'll

translate it for you...

[Björn Kaiser]

ximage/wmigaip comes with vista, right?

so i cant help you much here (unless there is a way to install it on xp)

but if you post the prototype for the callback function you want (i guess you allready have the sdk) i'll

translate it for you...

i dont have the SDK. I just have the DLL and the wimgapi.h that was posted on MSFN.org, see one of the earlier posts for the link. My problem is not to create and register a callback, but that it works with capture mode only, not when I apply the image. I only get 2 messages in that case and then autoit freezes.

btw: the wimgapi.dll can be found in the WAIK, 900 MB download and compatible with XP as is the dll. wimgapi.h I have only found in that post on MSFN. And since I dont know how that header file is licensed I would be probably doing something dumb if I reposted it.

[piccaso]

hmmm.... I think i know a solution to this problem.

I'm currently writing a dllcall equivalent which does the same thing like dllcall but in a seperate thread.

Primarily intended to be used with libcurl but in this case it could help here to.

When WIMApplyImage is called this way it would return immediately and 'single threaded' autoit would be ready for incoming calls.

we'll see

[piccaso]

Ok that didn't work out...

WIMApplyImage doesn't like to be called from another thread than the thread that created the wmi & image handles.

it just crashes while trying to read the contents of a null pointer

Another idea would be to put the callback stub in a critical section...