Resources UDF

[pintas]

Hi there.

I'm also trying to dd an exe and a sys file into an autoit script, but i can't.

Can anyone post a simple example in how i can do that?

Thank you and sorry to bother.

[Melba23]

Dreadfull and pintas,

Similar questions have been asked before in this thread and here is an answer (from Post #226):

Question:

Hello, I was simply wondering if there was a way to run an executable this way. So instead of using file install simple use this method to include an executable(or its binary data as a string) and then run the application without ever writing it to a file. I was just wondering if it was possible. And if so, hwo would one go about doing so.

Zedna's response:

NO. It's not possible.

If you want to run something you have included in your compiled file, it would seem that you have to use FileInstall, extract the executable to @TempDir and then delete it when you have finished. I have done that a number of times and it has always worked - as long as you have the necessary permissions, of course.

M23

[pintas]

oh, ok. I missunderstood the concept

Thanks man.

[Dreadfull]

That would be a good solution too, i don't care if it needs a temporary file, all i need is one file to do it all

Is there any example on this ?

Thanks

Edited February 4, 2009 by Dreadfull

[Melba23]

Dreadfull,

Please start your own thread in the General Help and Support forum to discuss this - hijacking Zedna's thread is not the way to go :-)

What you want to do is pretty easy - read the FileInstall and Run entries in the Help file carefully first and try coding a few scripts yourself to see how they work. There will be plenty of people willing to help you if you show that you have made an effort. But be aware that just asking for someone else to provide the code for you will not make you many friends - not that you would do that anyway, I am sure ;-)

M23

[Zedna]

Dreadfull,

Please start your own thread in the General Help and Support forum to discuss this - hijacking Zedna's thread is not the way to go :-)

M23

Thanks M23

You are right.

My thread is now very fat and it's dificult to search something in several hundreds of posts.

I will release new version of my UDF in a few days or next week. I will also add some sumarize about new known limitations/problems into my first post to avoid such repetitive simple questions (use FileInstall to run EXE files etc.).

[wraithdu]

Things to note about the changes -

From MSDN -

If LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE, or LOAD_LIBRARY_AS_IMAGE_RESOURCE is specified for the dwFlags parameter, the loader checks whether the DLL module was already loaded by the process as a normal DLL. If so, this means that it is already mapped into the virtual address space of the calling process. In this case, LoadLibraryEx returns a handle to the DLL and increments the DLL reference count. If the DLL module was not already loaded as a DLL, the system maps the DLL module as a data or image file and not as a DLL. In this case, LoadLibraryEx returns a handle to the data or image mapping, but this mapping is not reference-counted. If LoadLibraryEx is called twice for the same file with LOAD_LIBRARY_AS_DATAFILE , LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE, or LOAD_LIBRARY_AS_IMAGE_RESOURCE specified for the dwFlags parameter, two separate mappings are created for the file.

When the FreeLibrary function is called, if the handle specified in the hModule parameter is a data or image mapping handle, the mapping is destroyed. Otherwise, the handle is treated as a normal DLL handle, and the DLL reference count is decremented.

This has some implications.

1) If multiple resources are being extracted from the same DLL, the DLL is mapped again for EACH CALL, wasting memory. You'll have to add some kind of array to store loaded DLLs and handles, and just return the handle if a DLL is loaded.

2) To a previous question, you cannot call FreeLibrary on the DLL until the memory has been copied, since FreeLibrary will destroy the mapping and make the data pointers invalid (hence the crashing).

3) Another solution to (1) above, is to call FreeLibrary in the function that calls _ResourceGet AFTER the _Mem* function calls, since then it is safe to destory the original mapping.

Edited February 4, 2009 by wraithdu

[trancexx]

I'm extensively using LoadLibraryEx function in my ResHacker wannabe project for displaying images and... actually almost everything. Using LOAD_LIBRARY_AS_IMAGE_RESOURCE|LOAD_LIBRARY_AS_DATAFILE combination.

Peep here if you are interested.

[wraithdu]

You know, now that I think about it more, it would better to make the $DLL parameter be an open HMODULE if the user wants to use a resource DLL. Then you don't have to worry about extra memory management code in your UDF. Include in your documentation that it must be an HMODULE from LoadLibraryEx with the $LOAD_LIBRARY_AS_DATAFILE flag, and that the user must call FreeLibrary() when finished.

Ex -

Func _ResourceGet($ResName, $ResType = 10, $ResLang = 0, $hInstance = -1) ; $RT_RCDATA = 10
    Local Const $IMAGE_BITMAP = 0
    Local $hBitmap, $InfoBlock, $GlobalMemoryBlock, $MemoryPointer, $ResSize
    
    If $hInstance = -1 Then
        $hInstance = _WinAPI_GetModuleHandle(0)
    EndIf
    If $hInstance = 0 Then Return SetError(1, 0, 0)
    .....

Same thing for _ResourcePlaySound().

Edited February 4, 2009 by wraithdu

[wraithdu]

You could also return this from _ResourceGetAsImage()

Return SetError(0, $hData, $hImage)

so the user has the $hData handle to call _MemGlobalFree() themselves when they don't need the image/animated GIF anymore.

[CosmicDan]

You could also return this from _ResourceGetAsImage()

Return SetError(0, $hData, $hImage)

so the user has the $hData handle to call _MemGlobalFree() themselves when they don't need the image/animated GIF anymore.

Does the mean the return value will be the handle to use for $hMem in _MemGlobalFree() ? Sorry if it's a stupid question, this is the "next level" of AutoIt that i'm only new to :| If what I said was correct, that will be very useful then I believe - correct me if i'm wrong, but without this our autoitscript would eat up memory whenever a new graphic/resource is loaded, regardless if it's already been loaded before?

[wraithdu]

See the helpfile for the SetError() function.

$hImage is still the return value so we don't break the UDF, but now the @extended macro is set to $hData for use in the _MemGlobalFree() function.

So yes, currently the _ResourceGetAsImage() function has a memory leak. With this change, the user can free the memory when the image is no longer needed.

[rover]

rover,

Take a well-earned round of applause!!

When I change _ResourceGet() to use _WinAPI_LoadLibraryEx as proposed, the script using Zedna's _ResourceSetImageToCtrl works (once I include Constants.au3) - and my GDI based script using _ResourceGetAsImage continues to work as before.

So for an encore, can you explain why I did not need to change the UDF to make it work using the GDI example? _ResourceGetAsImage still uses _ResourceGet as far as I can see - so why does it work (for me, at least) in that case and not when called as part of _ResourceSetImageToCtrl?

A secondary question if I may - as a neophyte in .dll matters, is there not a problem with omitting the _WinAPI_FreeLibrary to release the .dll? Or does the $LOAD_LIBRARY_AS_DATAFILE parameter remove that requirement?

Sorry for so many questions, but I am really intrigued as to why there was this difference. Thanks in advance if you can shed any more light on this.

M23

P.S. Zedna, best wishes for a speedy recovery.

Melba23, BBoySonik and Zedna

sometimes I get it right

Zedna, hope you feel better soon

Melba23

your first script crashes with _ResourceGetAsImage() and your Melba.dll with an unedited Resource.au3 consistently for me.

diffferent version of resources.au3?

your posted script doesn't load dll for functions other than resource so couldn't be existing handle not closed by FreeLibrary

beats me.

because FreeLibrary() is called before the resource is used, I dont see how it could have ever worked.

handle to module is closed before resource memory is moved by _MemMoveMemory()

I like Wraithdu's comments and suggestions, as it's up to the user to handle and clean up resources, especially if called repeatedly.

cleaning up resources in wrappers after loading is a problem when repaint happens unless memory is copied.

case in point: _GUICtrlStatusBar_SetIcon() wrapper calls DestroyIcon after Sendmessage if not supplied with icon handle for SetIcon message

icons disappear on first repaint - see _GUICtrlStatusBar_SetIcon() helpfile example2

as for BBoySonik's dll, judging by the the manifest of data.dll it looks like it was made using reshacker method

of using existing dll and adding resources. that would explain it failing with LoadLibrary().

AutoIt DllOpen() (LoadLibrary) does not return a useable handle to the dll,

it's a pseudo handle. just like a control ID, an integer incremented by number of DllOpen calls

AutoIt closes all open dll handles on exiting.

MSDN says handles closed with process.

from help file for DllClose()

'Upon termination, AutoIt automatically closes any dlls it opened, but calling DllClose is still a good idea.'

that would include those opened internally by AutoIt, DllCall() and DllOpen()/LoadLibrary()

anyway, enough from me

[Melba23]

Hi all,

A solution to why I could get the GDI-based example script to work and others could not - and another round of applause to rover who put me on the right track.

I was using the 2008-06-25 version of Resources.au3 in that example on my machine - the one that still used:

If $DLL = -1 Then
      $hInstance = DllCall("kernel32.dll", "int", "GetModuleHandleA", "int", 0)
Else
      $hInstance = DllCall("kernel32.dll", "int", "LoadLibrary", "str", $DLL)
EndIf

rather than the the 2008-08-14 and later versions which use:

If $DLL = -1 Then
      $hInstance = _WinAPI_GetModuleHandle("")
Else
      $hInstance = _WinAPI_LoadLibrary($DLL)
EndIf

The reason I have 2 versions is that I had asked Zedna about the _GetResourceAsBytes function code (you can read about it here if you are really interested) and asked if a small change could be made to it. As he was (understandably) unwilling to change it because he had too many dependencies in other scripts which used that code, I made a version for my own Include folder which incorporated the small changes (which only affect _GetResourceAsBytes and _ResourceSaveToFile - _ResourceGet is untouched). Then when I downloaded the newer version, I decided to save it under a different name to prevent confusion (or so I thought!!!).

When I was playing with the various methods for getting the .dlls to display, I had begun by copying the GDI example from the Help file - which, of course, uses "#include <Resources.au3>" and which meant I was using the old version of the UDF in my script.

I have been experimenting today and can say that:

With the old version of the UDF the .dll displays in both the GDI and _ResourceSetImageToCtrl scripts.

The .dll does not display in either script using the later versions of the UDF which, according to Zedna's notes, have the following changes:

- _GDIPlus_Startup() is called once at start of whole include --> no _GDIPlus_Shutdown() is called
- fixed support for animated GIFs in _ResourceGetAsImage() --> removed _MemGlobalFree($hData)
- used simpler UDF syntax (from WinAPI) instead of DllCall() where possible

So that is part of the mystery solved. Zedna, I hope this helps in resolving the new version - perhaps a return to the older syntax?

M23

[Zedna]

@all

Thanks for usefull info.

In a week (or two in the worst case) I will release new version of my UDF.

I'm going to do these changes (and maybe also others):

- use LoadLibraryEx instead of LoadLibrary

- remove FreeLibrary (and some changes related to this)

- change ResourceGetAsBytes and add ResourceGetAsStruct

- some new example(s) for external DLLs

- some new informations in first post about limitations/problems

- ... ?

So stay tuned.

[rover]

Hi all,

A solution to why I could get the GDI-based example script to work and others could not - and another round of applause to rover who put me on the right track.

I was using the 2008-06-25 version of Resources.au3 in that example on my machine

M23

@Melba23

just for your interest I found why it worked in 6-25-08 version

there was an error in _ResourceGet() for the parameter type for module handle in FreeLibrary(), it was str and not hwnd

[Zedna]

In a week (or two in the worst case) I will release new version of my UDF.

Sorry for being late :-(

I was badly ill for more than 6 weeks and now I'm recovering from "emergency" state in which I was switched.

So I will look at it soon...

Edited February 27, 2009 by Zedna

[James]

Scite4AutoIt3:

->Warning: This is an Unicode compiled script and will not run on Win9x/ME.
>Running:ResHacker.exe -add C:\Users\James\Documents\Programming\AutoIt\Cheshire Fire Brigade\Code.exe, C:\Users\James\Documents\Programming\AutoIt\Cheshire Fire Brigade\Code.exe, CheshireFire.bmp, bitmap, TEST_BMP_1, 0
'ResHacker.exe' is not recognized as an internal or external command,
operable program or batch file.
>ResHacker.exe -add C:\Users\James\Documents\Programming\AutoIt\Cheshire Fire Brigade\Code.exe, C:\Users\James\Documents\Programming\AutoIt\Cheshire Fire Brigade\Code.exe, CheshireFire.bmp, bitmap, TEST_BMP_1, 0 Ended   rc:1
>Running:upx.exe --best --compress-resources=0 "C:\Users\James\Documents\Programming\AutoIt\Cheshire Fire Brigade\Code.exe"
'upx.exe' is not recognized as an internal or external command,
operable program or batch file.
>upx.exe --best --compress-resources=0 "C:\Users\James\Documents\Programming\AutoIt\Cheshire Fire Brigade\Code.exe" Ended   rc:1

What do I do now?

Edited March 1, 2009 by JamesBrooks

[Melba23]

JamesBrooks,

I have always found it necessary to have the full path of ResHacker and upx in the _Run_After directive, regardless of where they were located:

#AutoIt3Wrapper_Run_After=M:\Program\ResHacker\ResHacker.exe -add %out%, %out%, 132.bin, rcdata, BIN_132, 0

#AutoIt3Wrapper_Run_After=M:\Program\UPX\upx.exe --best "%out%"

If I used just the name I got the same result as you.

Hope that helps.

M23

[James]

I see! Thanks Melba. Perhaps this should be fixed soon?