Plugin Load Question

[Paralysis]

I noticed that the plugin_info_t structure has pointers to a couple important strings (such as Trillian's directory where I can store config information). Can I save the pointers or is the location transient?

If I may make a request for the docs, could the following information be thoroughly documented:
1. Pointer semantics (such as mentioned above)
2. Valid parameter values (such as NULL for pointers)
3. Meaning of return types
4. Calling convention (I presume Trillian uses cdecl?)

Trillian rocks.

-Para

[Azhrarn]

I don't see why the pointer would change (or be delete()'d), as the type of information isn't really something that is variable. You may just want to save the info locally for later reference.

What i'm wondering is if those pointers are static copies for plugins to refer to, or the same memory locations Trillian uses. If they are the same, you could probably pull some interesting tricks (like redefining the skin directory). The only problem is that likely Trillian already cached any info it needed before the plugins get access. Worth playing with though.

One example of something that would be nice is if Trillian loaded the plugins before it loaded the skin directory files. Then you could have the plugin immediatly redefine the skin directory to a plugin defined skin. But I have a feeling if a plugin tried that, some nasty things may happen. ;)

[Paralysis]

As I have a feeling that, if the pointers DO turn out to be variable, my plugin will likewise be in a heap of trouble...!

And yeah, it would make sense for them to be constant, but you never know. Still, I wish the documentation was more complete.

-Para

[TrillHunter]

The sample plugin would tend to suggest that the pointers are transient, and you need to make your own copy of the string if you want to use it later. Even if the pointer is non-transient, and is shared to all plugins, I'm sure Trillian doesn't share its own copy of the string with you, so the best you could do is make all plugins that load after you think that those directories are something that they aren't (this is easily testable... just create a plugin that modifies the string, load it up, then load another plugin that prints the string in a MessageBox).

As far as plugin load-time vs. skin load-time, the skin loads first.

[Azhrarn]

Yeah, that's pretty much what I figured. I just remember seeing some comments about messing with other loaded plugins in som eof the API docs, so thought (hoped?) there might be a possibility. :)

I've got something in the works right now, after I finish trying to figure out some more details about all the API functions to my satisfaction. I'm hoping to make a plugin to load another plugin, basically as a debugging tool that can load any other trillian plugin and log all the communication between Trillian and the secondary loaded plugin. Eventual features would be selective API filtering/blocking on known functions, but mainly a way to see what exactly a given plugin is doing.

It may also be a good way to do some sort of plugin "firewalling", to keep an eye on an untrusted plugin for suspicious activity, and turning off suspicious functions (like alias or broadcast for plugins that shouldn't be messing with your output).

But, I need to finish making a C++ class first, and like I said, I need to more fully understand the specifics of how dlls work (I've never worked with DLLs or windows specific programs before) before I get this stuff working. It should be a nice learning experience. ;)

[Paralysis]

That sounds really cool. I'm highly interested. I've done a good amount of DLL work, and you're welcome to e-mail me directly with any questions.

The plugin I'm working on is sort've a port of an old program that I never finished. There is an online chat system I've used for the past 5 years that is -similar- to IRC, but the protocol is much different. (The original application was for playing IPX games over the Internet.) Anyway, I can query the system and see if any of my friends are online. I never finished the GUI because that isn't the fun part of the project. I figure I'll just make a Trillian plugin for it.

Speaking of which... I love Trillian!

-Para

[TrillHunter]

Originally posted by Azhrarn
I'm hoping to make a plugin to load another pluginGrr.. that was one of my ideas. :P But I would've been doing it for different (probably less meaningful) reasons. Anyway, from what you're trying to do, it sounds like you'd be better off writing it all in C instead of C++.

[doctorDev]

Originally posted by TrillHunter
<snip>

uhh... hey trillhunter, you can get a nice member tag, IF you are using trilly pro legally. :)

[TrillHunter]

Originally posted by doctorDev
uhh... hey trillhunter, you can get a nice member tag, IF you are using trilly pro legally. :) Thanks, never noticed that before.

BTW, since you were obviously questioning whether I have a legal copy of Trillian Pro, I do have one, because I donated back when I first started using Trillian (before Pro) -- it's the first program that I've paid for that I didn't have to. And to tell you the truth, if I hadn't donated before, and was now required to pay $25 for Trillian Pro, I would've stuck with plain old Trillian and I wouldn't be here right now, helping out all the other plugin developers. Part of the reason is that there seems (in my mind) to be a big difference between the $15 I donated and the $25 that they're charging, for just a chat program (albeit a good one). The other part of the reason is that it only buys you a year's worth of free upgrades. If they continue to charge $25 every year to renew your membership, after a few years of renewals you'll end up paying just as much for your chat program as you would for a new OS.

[doctorDev]

Originally posted by TrillHunter
Thanks, never noticed that before.


cool !!! :D keep up the good work.

[Paralysis]

There isn't really much difference between C and C++. C++ is just C with classes, better type checking, better syntax (in some cases), and bastard syntax (in other cases). The original C++ compilers translated C++ programs into C. The caveat, of course, is C++ name mangling when dealing with exported and imported symbols.

I bought Trillian Pro as well, but I would have donated even if there was no incentive. I've resisted moving to Trillian for over a year, but I finally decided to try it out, and I've been pleased thus far.

I disagree like you with the annual subscription license, but most people won't donate unless they see a good reason to. Software does cost money to develop... would be nice if the world ran on donations... but that's why communism failed.

My two cents on a completely off-topic comment.

-Para

[TrillHunter]

Originally posted by Paralysis
There isn't really much difference between C and C++. C++ is just C with classes, better type checking, better syntax (in some cases), and bastard syntax (in other cases). The original C++ compilers translated C++ programs into C. The caveat, of course, is C++ name mangling when dealing with exported and imported symbols.What I was basically meaning is that the features he'd be using in C++ to get the job done are mostly the features that are there for backwards compatibility with C, such as callback functions and structs. Most of his code for this plugin is going to need to be this type of code. Anyway, it doesn't matter. It's not going to hurt to use C++ in this plugin, you just won't be able to take advantage of it as much as you would in other plugins.

[Azhrarn]

Yeah, in some of my more boring classes, I have been going over printouts of the API and docs and code. Trying to figure out how to best put the functions into one library.

Right now, I'm thinking almost all the struct definitions and such can be encapsulated inside a class. Along with the callbacks to send data(unless... the namespace issues get in the way). The part that is still up in the air are the main parsers to process incoming events. I'm thinking right now the best way is to enumerate the events for easy access, but can't really see a way to put the majority inside a library. Most of the actual "handling" and sifting of the callbacks would still have to be processed manually in the main program, unless I am missing some little trick to pass off most of the API specific parsing.

Hrmm.. the more I read that, the less sense it makes to me. It's kinda hard to articulate what I'm thinking when I'm not quite sure myself. :)

[Paralysis]

Yeah, it doesn't make a lot of sense to me. It seems too complex.

All you should -need- to do is specially process the load event from Trillian to load your target plugin (how will you determine which you are debugging? will you support multiple instances? how will you select which plugin to debug?), send a load event to that plugin, and return the return value. Everything else is just pass-through with filtering. The fact that Trillian sends an event by name rather than a function per event makes this *easy*. (Otherwise you would have to release a plugin per release of the SDK or figure out a way to dynamically export functions to Trillian -- not easy and requires a lot of hacking.)

You shouldn't need to encapsulate anything here. The data is interpreted based on what type of event you have. IMO the easiest way to do this is to have the front-end register filters, and the filter just specifies an event, a comparison type (<=, <, ==, !=, >=, >), and a variable-length pointer to memory to compare it to. (Note that if the length of the memory block < sizeof(int), you can save a lot of overhead by loading an int from both places, masking, subtracting, and checking the comparison.) This should liberate you from EVER having to update the code. All you need to do is provide some sort of structure definition to the UI, and then the user can select which field they want to filter.

Again, keep us updated. Your idea sounds really cool.

-Para

[Azhrarn]

Oops, sorry for the additional confusion. I was talking about two different things at once. My last post was about a general Trillian C++ header file, to make it more OO oriented. Not really about the plugin loading another plugin. ;)

As far as making a plugin load another, that should hopefully be fairly easy. All it would really do is transparently echo any communication between the loaded plugin to and from trillian. With possibly some user defined filtering applied.

The filtering itself should be pretty simple like you said, due to the fact that all the events are just passed as strings and pointers to structs. Hmm... this plugin may actually be easier then writing a decent generalized class. :)

[Azhrarn]

As far as loading multiple instances, I don't think I will do that for a bit. It may turn out to be easy enough to just make a tree entry in the plugin listing so I can easily display multiple loaded plugins. Otherwise, the listing of events and such will be a bit unmanageable. Also, as it is mainly a debugging tool, one plugin loaded at a time should be good.

But we'll see how it goes. ;)

[Paralysis]

I'd agree...one is enough...more would be nice, but not necessary, and laziness is good!