Jump to content


Photo

PluginPlugins announcement


  • Please log in to reply
8 replies to this topic

Poll: PluginPlugins announcement (9 member(s) have cast votes)

Which blackbox version's plugins do you miss the most?

  1. 32bit plugins on 64bit blackbox (6 votes [54.55%])

    Percentage of vote: 54.55%

  2. xoblite (1 votes [9.09%])

    Percentage of vote: 9.09%

  3. bbClean (1 votes [9.09%])

    Percentage of vote: 9.09%

  4. bb4win (2 votes [18.18%])

    Percentage of vote: 18.18%

  5. bbclean-xZero (old build) (0 votes [0.00%])

    Percentage of vote: 0.00%

  6. LiteStep (you dirty bastard :D) (1 votes [9.09%])

    Percentage of vote: 9.09%

  7. Scripting languages (Lua, python) (0 votes [0.00%])

    Percentage of vote: 0.00%

  8. other (post your choice :)) (0 votes [0.00%])

    Percentage of vote: 0.00%

Vote Guests cannot vote

#1 diabol

diabol

    Lazyass

  • Moderators
  • 235 posts

Posted 08 February 2014 - 08:23 PM

Announcing an upcoming feature: Pluginloaders

 

Background:

Over the years blackbox has seen a lot of different branches and most of them have added or taken away features in the blackbox API, rendering them incompatible.

Much effort has been put into the more recent branches to bend the API so it is compatible with most of them, but this has limitations and comes at a hefty price.

 

The problem:

While having a feature-rich and stable API makes it easy to develop new plugins, it makes the core inflexible, as we can only add to the API, but cannot change all the historical baggage we have accumulated (currently the api exports 95 functions and supports a few hundred messages, not even counting bro@ms).

Also with the current approach we cannot load 32bit plugins in a 64bit blackbox.

 

The solution:

Pluginloader plugins!

Pluginloader plugins are plugins which bind to blackbox' internal API and expose a stable API to plugins.

With this approach we can change the internal API as we see fit and still load existing plugins.

 

This will lay the groundwork for supporting all plugins that have ever been developed for any branch of blackbox, 32bit and 64bit.

Also a Pluginloader is not restricted to load a dll, it could just as well load a Lua or python script and with additional work it could even load Litestep plugins.

 

How it is going to work:

Currently the PluginManager maintains a list of plugins which it has loaded from plugins.rc.

To load a plugin, it simply loads the dll hit-and-miss.

 

Instead, in the future it will only load the PluginLoaders directly.

Once the PluginLoaders are loaded, it hands the other plugins one by one to the PluginLoaders, which one by one try to load the plugin, until one succeeds.

For the config files, nothing changes, except for an optional field which indicates the API a plugin uses.

Also the current API version is supported by an internal Pluginloader, so you don't need an extra plugin to load plugins :)

 

However, no matter how sophisticated the process is, I will still have to write the API adapters and I let you decide in which order I should implement them :D

Attached Files


  • pitkon and rlv like this

#2 pitkon

pitkon

    Administrator

  • Head Administrator
  • 1,204 posts
  • LocationAthens & Nafplio, Greece

Posted 09 February 2014 - 09:46 AM

Announcing an upcoming feature: Pluginloaders

 

Background:

Over the years blackbox has seen a lot of different branches and most of them have added or taken away features in the blackbox API, rendering them incompatible.

Much effort has been put into the more recent branches to bend the API so it is compatible with most of them, but this has limitations and comes at a hefty price.

 

The problem:

While having a feature-rich and stable API makes it easy to develop new plugins, it makes the core inflexible, as we can only add to the API, but cannot change all the historical baggage we have accumulated (currently the api exports 95 functions and supports a few hundred messages, not even counting bro@ms).

Also with the current approach we cannot load 32bit plugins in a 64bit blackbox.

 

The solution:

Pluginloader plugins!

Pluginloader plugins are plugins which bind to blackbox' internal API and expose a stable API to plugins.

With this approach we can change the internal API as we see fit and still load existing plugins.

 

This will lay the groundwork for supporting all plugins that have ever been developed for any branch of blackbox, 32bit and 64bit.

Also a Pluginloader is not restricted to load a dll, it could just as well load a Lua or python script and with additional work it could even load Litestep plugins.

 

How it is going to work:

Currently the PluginManager maintains a list of plugins which it has loaded from plugins.rc.

To load a plugin, it simply loads the dll hit-and-miss.

 

Instead, in the future it will only load the PluginLoaders directly.

Once the PluginLoaders are loaded, it hands the other plugins one by one to the PluginLoaders, which one by one try to load the plugin, until one succeeds.

For the config files, nothing changes, except for an optional field which indicates the API a plugin uses.

Also the current API version is supported by an internal Pluginloader, so you don't need an extra plugin to load plugins :)

 

However, no matter how sophisticated the process is, I will still have to write the API adapters and I let you decide in which order I should implement them :D

That's amazing news, diabol. I remember, or at least I try to, a similar plugin developed about 10 years ago by someone else... Darn, I can't really recall... I think I may have to look it up in my archives...



#3 Mew

Mew

    Member

  • Members
  • PipPip
  • 20 posts

Posted 10 February 2014 - 05:29 AM

Nice! I wonder how useful this will be!



#4 XZero450

XZero450

    VIP

  • VIP Member
  • 27 posts
  • LocationCentral Wisconsin

Posted 26 February 2014 - 01:46 AM

diabol, what about treating the loaders as an extension of the core, in other words plugins that can have plugins?

 

By that I mean there is hierarchical structure like:

 

Core - plugins.rc

-> plugin A

-> plugin B

-> Loader for x86 API - plugins.rc

-> x86 plugin A

-> x86 plugin B

-> Loader for xoblite APi - plugins.rc

-> xoblite's sole plugin

 

And so on.. The future Core API would still be flexible as long as the following loader's were updated. You then wouldn't have to specify an order to try them in or anything like that, it would entirely be up to the end user configuration.

 

Perhaps I'm oversimplifying this, at which point.. Do what I said and not what's easiest? lol


  • pitkon likes this

#5 diabol

diabol

    Lazyass

  • Moderators
  • 235 posts

Posted 26 February 2014 - 08:58 AM

diabol, what about treating the loaders as an extension of the core, in other words plugins that can have plugins?   By that I mean there is hierarchical structure like:   Core - plugins.rc

-> plugin A

-> plugin B

-> Loader for x86 API - plugins.rc

-> x86 plugin A

-> x86 plugin B

-> Loader for xoblite APi - plugins.rc

-> xoblite's sole plugin

 

And so on.. The future Core API would still be flexible as long as the following loader's were updated. You then wouldn't have to specify an order to try them in or anything like that, it would entirely be up to the end user configuration.   Perhaps I'm oversimplifying this, at which point.. Do what I said and not what's easiest? lol

 

  That's exactly the structure I'm going for :) However, the core doesn't load plugins by itself anymore, it only loads pluginloaders and forwards plugins to these.   It looks kind of like this (the pluginloaders don't exist yet, tho the 32bit loader is half done) Blackbox.exe -> Core Pluginloader (internal, loads whatever plugins the current api supports)   -> PluginA.dll   -> PluginB.dll -> Wow64Adapter (loads 32bit plugins. uses api redirection to bridge the 64bit/32bit gap)   -> PluginHost32.exe   -> Core Pluginloader (loads whatever 32bit plugins the current api supports)     -> PluginC.dll (some 32bit plugin)     -> PluginD.dll   -> XobliteLoader32.dll (loads xoblite 32bit plugins) -> PluginE.dll -> LuaPluginLoader.dll -> PluginF.lua -> XobliteLoader.dll -> PluginG.dll   This builds quite a complex hierarchy, but fits surprisingly well into bb's current plugin system.   Here's what happens when a plugin is loaded (via plugins.rc or bro@m):   Plugin load 1) The pluginmanager tries to load the plugin as a dll for examination. 1.1) If loading it as dll fails, go to step 4   2) The dll image is sanity checked and probed for the pluginloader signature functions. 2.1) If the signature is not found or incomplete, go to step 4   3) The plugin is determined to be a pluginloader, loaded and registered as such. 3.1) done.   4) The plugin is determined not to be a pluginloader.   5) Check if the plugin is marked to be loaded by a certain pluginloader A. 5.1) If not, go to step 7   6) If pluginloader A is present, try to load the plugin with pluginloader A. 6.1) on success, done.   7) Try for each pluginloader if it can load the plugin. 7.1) If one succeeds, done.   8) Loading has failed, report a cumulative error message from all pluginloaders.  

Design choices

Internally bb maintains a list of entries for every line in plugins.rc

This also extends to pluginloaders, so they also show up in the enable/disable menu (beside the core loader) and in the 'about plugins' dialog.

plugin-specific information (such as the addresses of the plugin's functions) has been moved to a support structure which can be freely defined by the pluginloader.

For a pluginloader entry, that support structure is a pointer to the pluginloader itself :)

 

I have considered the idea of writing plugins which implement the pluginloader concept, so that i wouldn't have to touch bb's PluginManager, but that would have meant that plugins managed by a pluginloader could not be loaded via the plugins menu or plugins.rc, etc.

Making pluginloaders first-class citizens and plugins second-class lifts that restriction and makes both integrate nicely. To the outside, it looks like nothing ever changed and the usage is the same - on the inside, there's a great opportunity to clean up the interfaces and api :)

Plugins.rc I've built the loader mechanism the way I did because I love low-level dll introspection (PluginManager.cpp line 372 fuck yeah, that's hot!) and because it requires no changes to existing plugins.rc files.

Pluginloaders are specified exactly the same way as plugins: a line with the name of the dll in it, optionally ! disabled or @ slitted (tho that is silly :)

 

The differences:

The restriction of plugins having to be *.dll is dropped as pluginloaders might load scripts or other voodoo and use different file extensions. Plugin lines can add loader hints, which affect the way they are loaded and are passed to the loader:

 

bbKeys32.dll   (wow64, xoblite) -- specifies plugin bbKeys32.dll should be loaded with the 32bit loader and the loader argument 'xoblite'

bbCalendar.dll (xoblite, bblean1.17.1) -- specifies plugin bbCalendar.dll should preferably be loaded with either xoblite or bblean1.17.1 api

 

The format itself is not final and in fact not implemented yet, but it will be something simple like this.

Notes: Currently there is no mechanism for a pluginloader to load another pluginloader (except for the 32bit pluginhost, but that's a whole different can of worms). I might add that if it becomes neccessary, but atm I think it would only overcomplicate things.

 

With the way it currently works, the plugins are load order dependant.

I think loading pluginloaders before plugins when executing the plugins.rc might prevent some menu stupidity:

- user adds PluginA.xoblite.dll via menu, plugin fails to load

- user adds XobliteLoader.dll via menu

- user enables PluginA.xoblite.dll, plugin loads

- reboot and PluginA.xoblite.dll fails to load, because in plugins.rc it is before XobliteLoader.dll

 

In the current moj build, the pluginloader mechanism is already live, but because i didn't test it previously it's buggy for anything but the core pluginloader.

It's fixed now and will ship with rc4 or 5 (whenever the 32bit loader is at least half done).



#6 diabol

diabol

    Lazyass

  • Moderators
  • 235 posts

Posted 01 March 2014 - 10:12 PM

Update

The 64/32bit boundary has just been broken through :)

32bit Plugins which only depend on GetUnderExplorer and GetBBWnd can now be loaded in 64bit BB :D

I still have to implement the actual loading code and there are no plugins that minimal, but the night is still young.

So far it's about 1500 lines of code, tendency growing


  • pitkon likes this

#7 pitkon

pitkon

    Administrator

  • Head Administrator
  • 1,204 posts
  • LocationAthens & Nafplio, Greece

Posted 02 March 2014 - 07:38 AM

That's great news! However, I believe the whole topic should be moved elsewhere. This is a Polls section, after all. Maybe under Developers' Niche?



#8 diabol

diabol

    Lazyass

  • Moderators
  • 235 posts

Posted 02 March 2014 - 08:29 AM

Look at the top, this is a poll :D



#9 pitkon

pitkon

    Administrator

  • Head Administrator
  • 1,204 posts
  • LocationAthens & Nafplio, Greece

Posted 02 March 2014 - 10:00 AM

Look at the top, this is a poll :D

I know this is supposed to be a poll, but polls don't have later date descriptions and updates. Besides, you have to do justice to your efforts. I don't think many will find your news buried under polls :)






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users