Forums Feature Suggestions Suggestions for mIRC dll interface

Can mIRC provide some methods that can be called by the routines in a dll? mIRC already has a LOADINFO structure, we can simply extend it and add several function pointers, like:

typedef struct {

DWORD mVersion;
HWND mHwnd;
BOOL mKeep;

// GetVar("%myvar")
// returns the value of global variable %myvar
char* (*GetVar)(char *varname);

// SetVar("%myvar","123")
// is equivalent to script line: set %myvar 123
void (*SetVar)(char *varname, char *varvalue);

// GetBinVar("&mybvar")
// returns a byte array contains the value of
// the binary variable &mybvar
char* (*GetBinVar)(char *bvarname);

// SetBinVar("&mybvar", "\x41\x42\x43")
// is equivalent to script line: bset &mybvar 1 41 42 43
void (*SetBinVar)(char *bvarname, char *bvarvalue);

// Eval("wow $+ $calc(12 + 2 * 4)");
// returns "wow20"
char* (*Eval)(char *expression);

// Execute("echo $colour(info) -s This is a test.");
// will display the text "This is a test." in status window.
void (*Execute)(char *command);

// RawSend("3", "PRIVMSG #mIRC UHM...")
// will send the raw text "PRIVMSG #mIRC UHM..." to socket
// of that the connection id ($cid) is equal to "3"
// By using this method, we can send multiply spaces (ASCII 32)
// to chat server.
void (*RawSend)(char *cid, char *rawmessage);

} LOADINFO;

Also, can mIRC add more return code to indicate the error info during dll routines process?

0 means that mIRC should /halt processing

1 means that mIRC should continue processing

2 means that it has filled the data variable with a command which it wants mIRC to perform, and has filled parms with the parameters to use, if any, when performing the command.

3 means that the DLL has filled the data variable with the result that $dll() as an identifier should return.

Maybe...

4 means that an user defined error occurs during the DLL execution, error info has been filled into the data variable.

After a /dll or $dll call, you can examine $dllerr to get the error info text, or no error occurs, $dllerr returns $null.

Well for pretty much most of what your asking for is already there. You can use the mapped files object to perform any command or use any identifier (or variable) that a script can.

I would like to see several exported functions but really all you need is mIRC's instance you can use GetProcAddress from there to get them no need to pass pointers to the fn's themselves.

As for the return 4 i really see nothing advantageous here. You can already fill data with something like "ERROR it did not work". or "OK It did work". If a scripter isnt checking the results adding a new return value wont help much anyway and for those who do check values it isnt needed.

OH, how can I archive this? can you give me some examples, Thanks in advance.

sure first look into CreateFileMapping. Theres a couple of concerns

1. the name must be mIRC
2. the size must be 1024 or larger.

youll recieve a handle use that handle in a call to MapViewOfFile. this will return a pointer you can use as a char array (LPCSTR).

fill that pointer with whatever "script" code you want mIRC to do and send the message to mIRC. the message will vary depending on if the text is an identifier or a command (the actual values for the messages are in the help file under SendMessage).

In the case of an identifier mIRC will fill the pointer with whatever is returned for your dll to examine. The following code was ripped from an sdk of mine (only the relavent portions)

//the message identifiers
#define WM_EVALUATE ((WM_USER) + 201)
#define WM_MCOMMAND ((WM_USER) + 200)

//the handle and data pointer
HANDLE hFileMap;
LPSTR mData;

//typically place this in the LoadDll or DllMain functions
hFileMap = CreateFileMapping(INVALID_HANDLE_VALUE,0,PAGE_READWRITE,0,
0x4000,"mIRC");
mData = (LPSTR)MapViewOfFile(hFileMap,FILE_MAP_ALL_ACCESS,0,0,0);

//now fill some info for mirc to do. in this case an identifier
wsprintf(mData,"$window(*,0)");

//tell mIRC to evaluate this for us. mwnd is mIRCS main window handle
SendMessage(mwnd,WM_EVALUATE,0,0);

//get the total window count. mData holds whatever was returned by mIRC
int nWndCount = atoi(mData);

//this time make mIRC perform a command
wsprintf(mData,"/echo -a hello me");
SendMessage(mwnd,WM_MCOMMAND,0,0);

//continue using mData as long as you want.

//in your DllMain functions DLL_PROCESS_DETACH case statement or in the UnloadDll function use this to clean up
UnmapViewOfFile(mData);
CloseHandle(hFileMap);

Its very easy to see how you can implement callbacks. your dll remains loaded and can send and recieve info with mIRC at anytime not just during a /dll call. You could even send a /signal if you want just remember that signals do not return values so its a one way comm only.

Note i havent shown any error checking in the code above but im sure youll be able to get it up and running

Thanks Narusegawa_Naru.

I've done my mIRC extension DLL. It makes mIRC support active scripting now, also it makes mIRC support database through ADO interface.

ALMOST all of those can be done using the existing SendMessage stuff - I don't see a practical way of retrieving the contents of a binvar using this method (aside from evaluating $bvar(&binvar,A-B) for various values of A and B and then parsing the strings to extract the values).

I would still like to know why mIRC has to use mapped files - is there something I'm not aware of that prevents just sending the LPSTR as the LPARAM for the SendMessage? (maybe something special about the Windows message queue that messes up that sort of thing)

in most cases passing the argument in the SendMessage Call would work. One such advantage of the mapped file is its a system global object wich means it can work interprocess. A dll is loaded into mIRC's address space but an application isnt. A mapped file is shared among all dll's and/or processes using all instances of mIRC running.