Gus What?!

As noted here, you need to make sure your system clock is fairly accurate when using the Open AIM SDK 1.6.7 in a client. This will be fixed in the next release.

Incidentally, the APIs we use for signon are clientLogin and startOSCARSession which are documented in the OSCAR protocol specifications.

A number of you are trying out the recently released AIM SDK 1.6.7. I thought it would be a good idea to answer some of the early questions. So here they are in my usual Q&A style…

Q: What SDK files do I need to run an Open AIM client or bot?
A: You need to copy some of the DLL files from the dist\release folder into your application’s folder. You can omit the jg*.dll files if you don’t need to support talk (aka voice) sessions with legacy AIM clients like AOL 9.x and AIM 5.9. You can also omit the sipxtapi.dll if you don’t need to support the newer SIP based Audio/Video sessions in AIM 6.x. You only need the accjwrap.dll and the accjwrap.jar files if your bot or client is written in Java. All other DLLs are required.

Q: What are all these new DLLs for?
A: We added support for SSL based encryption to Open AIM clients, which is based on NSS and NSPR from Mozilla. We also updated the audio/video stacks for full multimedia support in Open AIM.

Q: How do I enable SSL based encryption in my bot or client?
A: You can enable this via the boolean preference named “aimcc.connect.secure”. The default is false.

Q: What does SSL based encryption protect?
A: This encrypts all regular IM traffic between the client and the AIM host. It will not encrypt direct IMs, picture sharing sessions, A/V sessions, file transfers, buddy art retrievals and uploads, or alerts. Note: for end to end security your buddy also needs to be running a client that uses SSL encryption, like AIM 6.5.9.1.

If I did not answer your question, feel free to ask in a comment or post it in one of the forums.

With AOL’s recent announcement on Open AIM 2.0 now live and getting lots of great attention, I thought I should write a quick post on it. This is truly exciting news. We are dramatically expanding our community when we open things up like this. So with that, I want to say “Welcome” to all the great developers out there. Here is this incredible AIM network that you can now use and build on.

I have actually been a part of the AIM core team for a number of months now, so I am available to help answer questions on Open AIM. I can now claim to have written code in imapp.dll, acccore.dll, coolcoreXX.dll, and xprtX.dll. Lastly, this guy sits next to me.

There are more great things to come.

Have you ever wondered why tab and other navigation keys don’t work in some of the modeless dialog windows created by plugins? The reason for this is because Windows requires applications to call IsDialogMessage() for the currently active modeless window in order to translate the keyboard messages into dialog navigation commands.

This is relatively easy to implement in a standalone application since the code is all compiled and built together. However, in a plugin world you have to create an API to support this since it requires the cooperation between the hosting application, that owns the message pump, and the plugins, that know which modeless window is currently active.

The Open AIM SDK added support for registering the active dialog back in version 1.3 via a property called IAccPluginInfoProp_Windows. This property accepts an array of UINTs that are the window references. In the Windows environment you only have to provide a one-element array with the window handle of the currently active modeless dialog window or an empty array.

Open AIM clients need to listen for changes to IAccPluginInfoProp_Windows and keep track of the currently active dialog window in any plugin. On every window message, Open AIM clients should call IsDialogMessage() if it has at least one active modeless dialog window registered. If the message is handled, then the client is done otherwise the client can continue on with its own processing of the message. If all plugins are working correctly, there should only be one active modeless dialog window at a time even if there is more than one open.

I created a handy little class that you can use to make this easy to manage in your plugins. Here is a part of the header (Download the full source here):

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class COpenAIMPluginWindowReg
{
public:
    // Call this once from the first instance of your plugin and
    // a second time, with a null pointer, when the last instance is shutdown.
    static void SetPluginInfoPtr(IAccPluginInfo *pPluginInfo);
 
    // Call this from WM_ACTIVATE
    static void OnActivate(HWND hWnd, WPARAM wParam);
 
private:
    static CComPtr<IAccPluginInfo>  s_spPluginInfo;
 
};

As you can see, this class has just two static methods and thus very simply to use. You call COpenAIMPluginWindowReg::SetPluginInfoPtr(pPluginInfo); from the first instance of your plugin. I typically call this from the IAccPlugin::Init() method and keep track if the number of instances of my plugin that are running. You must also call COpenAIMPluginWindowReg::SetPluginInfoPtr(NULL); when the last instance of your plugin is shutdown.

Then, in every modeless dialog window you create, add a handler for the WM_ACTIVATE message and call:

    COpenAIMPluginWindowReg::OnActivate(hWnd, wParam);

The OnActivate static method takes care of maintaining the IAccPluginInfoProp_Windows property for your plugin as the window is activated and deactivated.

I have released this source under an MIT style license. See the source files for more information. Again you can download the full source here.

Questions? Comments?

Hello again. I am back. Today I am starting a new series of posts on Open AIM. For this first post, I will start by introducing a handy little function similar to the one I wrote for my plug-ins that makes it easy to register commands that your plug-in will handle.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// The following code is public domain. Written by Gus Verdun
static void RegisterPluginCommand(IAccPluginInfo * pluginInfo, 
                                               int id, UINT flags, 
                                               LPCWSTR pCommand)
{
    CComPtr <IAccCommand> spCommand;
    pluginInfo->AddCommand(id, &spCommand);
    if (spCommand)
    {
        CComBSTR str(pCommand);
        put_Text(spCommand, str);
        put_Flags(spCommand, (AccCommandFlags)flags);
    }
}

I normally call this function from the IAccPlugin::Init method, but you can call it at any time you want to add a command. The first parameter is the IAccPluginInfo interface pointer that is passed to you on the Init() call. The second parameter is the command identifier that is assigned by you and handled in your plugin’s IAccCommandTarget methods. The third parameter, flags, are the AccCommandFlags that let you indicate where you want this command to appear in the UI. Finally, the fourth parameter is the actual text that will be displayed in the client’s UI.

Here is a simple example to define a command that will show only in the plug-in settings page.

RegisterPluginCommand(pPluginInfo, -1, 
     AccCommandFlags_PreferencesUi, 
     OLESTR("Settings...") );

For localization purposes, you can easily change this function to load the command string from a resource. I will leave that as an exercise for you to try.

Hope this helps. Comments? Questions?

From the how to support custom app development department. AOL recently launched a new web site dedicated to the showcasing of custom apps that are built from the Open AIM SDK and web APIs.

This site, called AIM Gallery, can be accessed at gallery.aim.com. It should quickly become the best place to find and share mashups, AIM Bots, AIM Custom Clients, AIM Plugins, and AIM Whimsicals. See the web site if you don’t know what these are.

The site lets you search, browse, download, rate and comment on these apps. You can also upload your own creations.

Please visit the AIM Gallery today and be sure to let us know what you think about it. Thanks.

The other day I was working on the CoreWitness plug-in in order to prepare it for use with the latest AIM SDK, version 1.3.0. I quickly ran into the issue of what to do when it’s loaded in a client running a previous version of AIMcc.

The first clue came when I ran the client to debug some of the new CoreWitness code. The release notes in AIMcc indicated that a new property, called AccSessionProp_Pause, was added to IAccSession. I started my test run the way I always do by running AIM 6.1, but that client is using the older AIMcc 1.2.4.

Here was what I saw when looking at that property from the CoreWitness trace:

{Unknown} = {Empty}
hr=E_INVALIDARG 0x80070057 (2147942487U) (-2147024809L)


“{Unknown}” is shown because “AccSessionProp_Pause” is not in the typelib of the older AIMcc version that loaded the plug-in. The encouraging news is you get E_INVALIDARG.

Reading this property in AIMcc 1.3.0 shows:

AccSessionProp_Pause = {Empty}
hr=E_INVALIDARG 0x80070057 (2147942487U) (-2147024809L)


Wait, they both return E_INVALIDARG? This must be a write only property. OK, so this won’t work for this property. I could try to set the AccSessionProp_Pause to false, but that might have some unwanted effects. Another thing I could do is inspect the typelib to see if it knows about AccSessionProp_Pause, but I will save that as a last resort. Are there any other new readable properties?

The release notes mentioned another new property; this one is in the IAccPluginInfo interface called AccPluginInfoProp_Windows. Lets, see what it looks like from CoreWitness in AIMcc 1.2.4 and then in 1.3.0:

{Unknown} = {Empty}
hr=E_INVALIDARG 0x80070057 (2147942487U) (-2147024809L)


and

AccPluginInfoProp_Windows = {Empty}


BINGO, that’s exactly what what we need. We can simply adjust our logic based on the support of the AccPluginInfoProp_Windows property. In CoreWitness, I use this method to filter out what data I show and add more command actions when running under AIMcc 1.3.0 since this version lets me specify where these menu items go in the UI.