Jump to content
Sign in to follow this  


Recommended Posts

I was thinking about plugins again today and maybe trying something less advanced than the last attempt.

First the limitations:

- Would have to be compiled with a copy of VectorVariant and Variant which in turn demands that all plugins are written in a version of c++ that can compile them (Visual C, MinGW/Devc). Acceptable in my opinion. (The alternative would be to have a DllCall style function which would have to support all the different types that a variant can currently have but this would make it difficult to have optional parameters and that is currently very easy with the VectorVariant class)

- The plugin functions would only take the usual internal function declaration of a VectorVariant (for params) and a Variant (for result) and an extra parameter for @error. This means that most simple functions could be added as plugins but the plugin would not have access to the usual script/global variables. This means that only simple wrapper functions can be made but that is like most of the AutoIt internal functions anyway. Acceptable?

Compilcated stuff like the GUI could in theory be made into a plugin but with additional startup/closedown code required in autoit3.exe (the current GUI is actually already a standalone class that doesn't talk to the main autoit code except through a few functions) - but whether the gui should be seperated out is a different argument.

The way it would work:

- New directive called #plugin mydll.dll - which simply does a LoadLibrary()

- The plugin would export a function like "GetFunctions" that simply returns a delimited string containing all the function names that the plugin supports (there is probably a way to automatically get a list of exported functions but I don't know how and it might be less overhead in autoit3.exe this way)

- Patch the function calling code so that if a requested function is not built-in or a UDF then check the list of plugin functions if a match is found do a GetProcAddress and call the function (Or we could make it so that plugin functions have to start with a certain character so that the lexer can immediately tell the difference and not waste time). AutoIt and the plugin would have to use the same function parameter spec so I think I could just enforce the c++ way of passing params with a WINAPI style definition.

For compiled scripts I could make it so that all #plugin definitions are automatically FileInstalled/Deleted in the temp directory while the script is executed. My extraction code supports extracting a file directly to a memory buffer but I don't know if there is a way I can then get it into LoadLibrary without making it into a file first.

The compilation thing is the tricky bit so it would probably be initally coded so you have to have the dll already present in the path and then when it was accepted as a "useful" feature I could do the tricky compile stuff.

Edited by Jon

Share this post

Link to post
Share on other sites

If we could get real structures as variables in autoit from a dllcall, then all plugin stuff would not be needed. Am I correct?

Who else would I be?

Share this post

Link to post
Share on other sites

I was thinking of some sort of CopyMemory for structures, where you figure out length of the structure and then bitshift to get the info... I really don't know what I am describing as it is beyond me, but my imagination would like to believe it is possible...



Wow, manual bitshifting sounds like too much hard work for a lazy ass like myself.

Perhaps we can define structs as AutoIT arrays with the type description as the first element and the value as the second element. For fixed length strings, we can append the length to the str type description.

A new type will need to be added to DllCall, perhaps called "struct", which is actually an AutoIT array.

So a Windows struct like _WIN32_FIND_DATA

struct _WIN32_FIND_DATA {  
DWORD dwFileAttributes;  
FILETIME ftCreationTime;  
FILETIME ftLastAccessTime;  
FILETIME ftLastWriteTime;  
DWORD nFileSizeHigh;  
DWORD nFileSizeLow;  
DWORD dwReserved0;  
DWORD dwReserved1;  
TCHAR cFileName[MAX_PATH];  
TCHAR cAlternateFileName[14];

Could be defined in AutoIT as:

FindDataArray[0] = "long"
FindDataArray[1] = dwFileAttributes value

FindDataArray[2] = "struct"
FindDataArray[3] = ftCreationTime value

FindDataArray[4] = "struct"
FindDataArray[5] = ftLastAccessTime value

FindDataArray[6] = "struct"
FindDataArray[7] = ftLastWriteTime value

FindDataArray[8] = "long"
FindDataArray[9] = nFileSizeHigh value

FindDataArray[10] = "long"
FindDataArray[11] = nFileSizeLow value

FindDataArray[12] = "long"
FindDataArray[13] = dwReserved0 value

FindDataArray[14] = "long"
FindDataArray[15] = dwReserved1 value

FindDataArray[16] = "str255"
FindDataArray[17] = cFileName value

FindDataArray[16] = "str14"
FindDataArray[17] = cAlternateFileName value

ftCreationTime example:

ftCreationTime[0] = "long"
ftCreationTime[1] = dwLowDateTime value

ftCreationTime[2] = "long"
ftCreationTime[3] = dwHighDateTime value

Just an idea, feel free to shoot it down... :)

BTW, adding plugins to extend AutoIT sounds like a great idea. Looking for to using it.

Edited by pacman

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...