Miranda IM

Page 1 of 7 123 ... LastLast
Results 1 to 10 of 68

Thread: Important Plugin Changes For Plugin Authors

  1. #1
    Join Date
    March 2005
    Location
    United States
    Posts
    1,747

    Important Plugin Changes For Plugin Authors

    Starting with v0.7 build 17, Miranda now supports a new plugin api. It is important for plugin devs who are developing their plugins for 0.7 to make these changes. If you are still supporting 0.6.x in your plugins, please be aware these changes will make your plugin incompatible with 0.6.x.

    Starting with v0.8 Build #9, these changes are required for all plugins.

    To use the new api you should change your PlUGININFO struct to the new PLUGININFOEX struct. Here are the details:

    Code:
    typedef struct {
    	int cbSize;
    	char *shortName;
    	DWORD version;
    	char *description;
    	char *author;
    	char *authorEmail;
    	char *copyright;
    	char *homepage;
    	BYTE isTransient;
    	int replacesDefaultModule;
    	MUUID uuid;
    } PLUGININFOEX;
    Notice that this is essentially the same as the previous struct except a new MUUID field. In 0.8, the replacesDefaultModule will be deprecated (and ignored), but you should continue to use this field for now. The MUUID struct consist of the following:

    Code:
    typedef struct _MUUID {
      unsigned long a;
      unsigned short b;
      unsigned short c;
      unsigned char d[8];
    } MUUID;
    To generate this struct, you can use the guidgen.exe program to create it. Select option 3 for the output format so it will create a compatible struct. Here is an example plugin info struct:

    Code:
    PLUGININFOEX pluginInfo =
    {
    	sizeof(PLUGININFOEX),
    	#if defined( _UNICODE )
    	"My Plugin (Unicode)",
    	#else
    	"My Plugin",
    	#endif
    	__VERSION_DWORD,
    	"My description",
    	"Author",
    	"Email",
    	" 2007 Author",
    	"http://miranda-im.org",
    	UNICODE_AWARE,	
    	0,
    	#if defined( _UNICODE )
    	{0xdc39da8b, 0x8385, 0x4cd9, {0xb2, 0x98, 0x80, 0x67, 0x7b, 0x8f, 0xe6, 0xe4}}
    	//{DC39DA8B-8385-4cd9-B298-80677B8FE6E4}
    	#else
    	{0x29aa3a81, 0x3368, 0x4b78, { 0x82, 0xc1, 0xdf, 0xc7, 0x29, 0x6a, 0x58, 0x99 }} 
    	//{29AA3A81-3368-4b78-82C1-DFC7296A5899}
    	#endif
    };
    Note: You should generate a new uuid for unicode and ansi versions. This will be important for linking plugins to the new addons site.

    The next change you should make is to use the new MirandaPluginInfoEx instead of MirandaPluginInfo.

    Code:
    __declspec(dllexport) PLUGININFOEX* MirandaPluginInfoEx(DWORD mirandaVersion)
    {
    	return &pluginInfo;
    }
    The following function is required to be implemented if you are using MirandaPluginInfoEx.

    Code:
    __declspec(dllexport) const MUUID * MirandaPluginInterfaces(void);
    A common implementation will look like this:
    Code:
    static const MUUID interfaces[] = {MIID_CHAT, MIID_SRMM, MIID_LAST};
    __declspec(dllexport) const MUUID * MirandaPluginInterfaces(void)
    {
    	return interfaces;
    }
    In the above example, the plugin declares that it implements 2 interfaces that are already defined in newpluginapi.h. MIID_LAST is always used to denote the end of the list. Every plugin must return atleast one interface (besides MIID_LAST). If their plugin implements an interface that isn't already defined in newpluginapi.h, then they need to create a new UUID to use.

    Note: Protocols are the only plugin that is run simultaneously with the same interface definition.

    In 0.8, these interface changes will allow plugins to implement one or more interfaces. What will happen is if a user activates Scriver, then chat.dll and srmm.dll will automatically be deactivated in the plugin options. Also, no longer are we limited to a finite set of defmod definitions. Plugins such as mtooltip and tipper will implement the same interface so they will work nicely together. No longer does a user have to know which plugins have the same function.

    Using this interface api will allow us to break compatibility with certain apis and not have to worry about plugins causing problems for the user. The core loader will be able to disable any interfaces that are outdated. This will allow us to make bigger api changes and keep Miranda stable at the same time.

    Note: In 0.8, these changes will be required for your plugin to load. So it is important that you make these changes if you want your plugin to be supported.

    Interface changes have not been implemented yet. When they are, I will update this post with the details.

  2. #2
    Join Date
    October 2006
    Posts
    90
    question :-)
    to ensure compatibility with both 0.6- and 0.8+, we just have to implement both MirandaPluginInfo() and MirandaPluginInfoEx(), or 0.8 will complain about something ?

  3. #3
    Join Date
    March 2005
    Location
    United States
    Posts
    1,747
    Quote Originally Posted by dreadnaut View Post
    question :-)
    to ensure compatibility with both 0.6- and 0.8+, we just have to implement both MirandaPluginInfo() and MirandaPluginInfoEx(), or 0.8 will complain about something ?
    It's possible to work in both if you create both MirandaPluginInfo and MirandaPluginInfoEx. But only if MirandaPluginInfo returns a PLUGININFO struct and MirandaPluginInfoEx returns a PLUGININFOEX struct. Keep in mind build 17 isn't strict is how these are loaded but build 18 is. So yeah, you could possibly work in all 3. However, once 0.7 is released, you should remove any references to MirandaPluginInfo and PLUGININFO. They will no longer be required or used.

  4. #4
    Join Date
    January 2006
    Location
    Czech republic
    Posts
    260
    It should be possible to extract Miranda's version from its executable and choose the right interface, shouldn't it?

  5. #5
    Join Date
    October 2006
    Posts
    90
    Quote Originally Posted by rainwater View Post
    Keep in mind build 17 isn't strict is how these are loaded but build 18 is. So yeah, you could possibly work in all 3. However, once 0.7 is released, you should remove any references to MirandaPluginInfo and PLUGININFO. They will no longer be required or used.
    thanks for the info, they will be useful in this transition moment!

    Btw, isn't this going to preclude the use of a huge amount of plugin still working but not developed? what about those for which no source is available and the developer is gone? (hope there is none actually!)

    Was this done to slim down the list? :-p

    @Virtuso
    As far as I have understood, Miranda 7.17+ will just call the -Ex version, if there is also a normal version in the dll, it will not complain, and the plugin will be accepted by the 0.6 serie.
    Last edited by dreadnaut; 6 Mar 2007 at 5:19 PM.

  6. #6
    Join Date
    March 2005
    Location
    United States
    Posts
    1,747
    Quote Originally Posted by Virtuoso View Post
    It should be possible to extract Miranda's version from its executable and choose the right interface, shouldn't it?
    MirnadaPluginInfo is only called in a 0.6 core if you have a MirnadaPluginInfoEx defined as well. 0.6.x will never call MirnadaPluginInfoEx.

  7. #7
    Join Date
    April 2005
    Posts
    1,935
    If you want to support both the new method (MirandaPluginInfoEx) and the old method (MirandaPluginInfo) you might find this define useful. It assumes that your PLUGININFOEX structure is called pluginInfo. It will create a new PLUGININFO structure called oldPluginInfo, copies the necessary data from the new structure and creates the old MiradaPluginInfo exported function.
    To use it just write OLD_MIRANDAPLUGININFO_SUPPORT after your declaration of pluginInfo.
    Code:
    #define OLD_MIRANDAPLUGININFO_SUPPORT PLUGININFO oldPluginInfo = { \
    	sizeof(PLUGININFO), \
    	pluginInfo.shortName, \
    	pluginInfo.version, \
    	pluginInfo.description, \
    	pluginInfo.author, \
    	pluginInfo.authorEmail, \
    	pluginInfo.copyright, \
    	pluginInfo.homepage, \
    	pluginInfo.isTransient, \
    	pluginInfo.replacesDefaultModule \
    }; \
    \
    extern "C" __declspec(dllexport) PLUGININFO *MirandaPluginInfo(DWORD mirandaVersion) \
    { \
    	return &oldPluginInfo; \
    }

  8. #8
    Join Date
    March 2005
    Posts
    8,345
    Quote Originally Posted by dreadnaut View Post
    isn't this going to preclude the use of a huge amount of plugin still working but not developed?
    Looks like it is ...

    And it looks like I might need to say "bye" to TopToolbar :cry:

  9. #9
    Join Date
    January 2006
    Location
    Czech republic
    Posts
    260
    Quote Originally Posted by Tara View Post
    Looks like it is ...

    And it looks like I might need to say "bye" to TopToolbar :cry:
    Seems to strict to me, invalidating all these plugins...

  10. #10
    Join Date
    April 2005
    Posts
    1,935
    They're not necessarily invalidated. A plugin could be deleveloped to bridge the gap between old and new plugin loading mechanisms.

Similar Threads

  1. [plugin request] Alternative Clist-PlugIn
    By nore2 in forum Feature Requests
    Replies: 1
    Last Post: 27 Dec 2007, 3:49 PM
  2. [plugin request] Send Screenshot plugin for 0.7.3
    By Melhesedek in forum Feature Requests
    Replies: 1
    Last Post: 23 Dec 2007, 3:35 PM
  3. Important Question about adding people plugin
    By shishkabab in forum Technical Support
    Replies: 3
    Last Post: 6 Oct 2007, 2:18 AM
  4. Plugin:Request - File Sharing plugin
    By Grimmy in forum Feature Requests
    Replies: 2
    Last Post: 12 Jan 2007, 3:56 AM
  5. help needed: miranda - plugin SK & CZ plugin developers
    By NuSuey in forum Technical Support
    Replies: 4
    Last Post: 5 Nov 2006, 5:47 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •