Something I’ve been curious of, over the years, is how plugins work. As far as I can understand, they don’t run in the main thread, but rather have their own thread or, perhaps, their own process? Do they run as a paired “application” of sorts? I recognize them as easily portable, but why not just use a module? I’m hoping to really understand them so I know when’s best to use them.
As exhaustive as someone is willing to go, how do they work? 
Some old informations:
An old link from realsoftwareblog: http://www.realsoftwareblog.com/2011/02/how-real-studio-gives-you-more-power.html
Thanks, John. I’m familiar with how the plugins API works, and have perused a few plugins. They make sense. But my question isn’t really “What can one do with a plugin”, as much as “How do they work?” The example in the blog could have been written just as easily in Xojo using declares, so why did he go with a plugin?
I’m hoping for the nitty gritty. 
Plugins are used to offer things you can’t do with the language or you need things needing some kind of timing or speed you can only reach knowing your machine code for example. Imagine I create a new interface, a helmet that reads your thoughts and can type the chars or move the mouse pointer. Probably I’ll write a C++ library for people to use my new device. Well, you saw my device, liked, and want to use it with your Xojo Apps. You’ll need to write a plugin and link with my libraries to call my API. That’s a classical approach of “Why we need plugins for Xojo”.
When you say “X thing could be done with declares” you probably is thinking about OS-X, don’t you? If such thing solves your problem ok, but couldn’t solve other users problems. Different OS’s have different approaches for some tasks and some couldn’t be reached by “declares”. But you can write specific code in C++ to accomplish that task, or emulate it under an OS that does not offer such functionality, plus hiding and packing all that complexity from the user. You make your code for OSX, Windows and Linux, make your plugin, and that “task” now works out of the box for your users on all available platforms with native speed of that OS.
[quote=18702:@Jason Adams]Something I’ve been curious of, over the years, is how plugins work. As far as I can understand, they don’t run in the main thread, but rather have their own thread or, perhaps, their own process? Do they run as a paired “application” of sorts? I recognize them as easily portable, but why not just use a module? I’m hoping to really understand them so I know when’s best to use them.
As exhaustive as someone is willing to go, how do they work? :)[/quote]
No not their own thread
They are really not fundamentally differnt than any code you could write in Xojo in general terms.
However, since they are written in C/C++/Objective-C they could actually create a preemptive thread as long as they are VERY careful about how they do so (as any callbacks into Xojo framework could be quite risky since the framework is not thread safe)
They could create a Xojo thread & function that way as well.
And they are no more or less portable than any other code - again since they are written in C/C++/Objective-C they can be as portable as the author makes them.
Thanks, Norman! So am I understanding you correctly that the sole advantage of plugins is the ability to use preemptive threads? Anything other than this is pure preference?
A plugin can link to static library and especially to C++ code which you can’t do with declares.
They can do preemptive threads and do some things more efficient than you could code it in Xojo.
Also on Mac OS X they can use blocks functions.
No
As Christian indicated there are some language features in Objective-C, C++ that have no counterpart in Xojo.
If all you have is a static library you need a plugin since you cannot access a static library using declares.
However there’s a lot you can do with declares that doesn’t require a plugin (check out MacOSLib and Windows Functionality Suites)
Gotcha, thanks to you both. I’m familiar with the WFS, declares, and the like.
Plugins have just been this element of Xojo (or, previously, RB) that I’ve used (such as MBS), but never could wrap my mind around the real advantages thereof that is, why MBS is a collection of plugins instead of native code. But this makes sense now, thanks for the explanation. It’s especially useful to know plugins are the means for accessing a static library.
Thanks!
[quote=18742:@Jason Adams]Gotcha, thanks to you both. I’m familiar with the WFS, declares, and the like.
Plugins have just been this element of Xojo (or, previously, RB) that I’ve used (such as MBS), but never could wrap my mind around the real advantages thereof that is, why MBS is a collection of plugins instead of native code. But this makes sense now, thanks for the explanation. It’s especially useful to know plugins are the means for accessing a static library.
[/quote]
I’m sure theres code in plugins that could be done with declares so it’s a toss up as to whether you want to use a declare or a plugin for that.
But there are some portions that simply cannot be done in declares - they require an Objective-C block, or they need to subclass something in AppKit or something else that can’t be done in Xojo code.
So there are choices.
I use plugins when I have no choice - the TextInputCanvas in Xojo is a great example.
We HAD to write that plugin to tie into the text input system on OS X and make it work properly.
There’s no choice. If you want to be a proper text input client you have to use that plugin. FTC does & it works very well with the OS X text input system.