Plugins and Program Extentions

BlitzMax Forums/BlitzMax Programming/Plugins and Program Extentions

CASO	(Posted 2009) [#1]

This is a somewhat conceptual problem, but I post it here because it is in regards to BlitzMax specifically.

I want to write a program that has X amount of features. Then, at a later date, i release a PLUGIN that can be called from the main program and adds Y amount of more features. I would need to pass information (numbers, paths, image data....) in between the main program and the plugins. Ideally, the main program and the plugins would both be written in BlitzMax.

What would be the best way to do this?

ImaginaryHuman

(Posted 2009) [#2]

My approach is to create (or use) a script language and to then write most of your application `in script`, running in your script interpretation/compilation engine. Then when it comes to extending it you can just write other scripts and run them. Then you don't need to worry about trying to get little pieces of executable code to run or to work with each other - although you could do that with processes, excecuting an app, and inter-process communication.

My philosophy on plugins is really that from the start, an application should be designed to be as open as possible so that the idea of a `plugin` is obsolete - ie the whole application is in a state of modifiability, and you don't just get to add on features in a specific little menu option, but application-wide. Creating most of your user interface and processing and stuff from scripts would let you make the application maleable like that.

CASO	(Posted 2009) [#3]

How exactly does this "inter-process communication work"?

Secondly, how could a script implement features that weren't already thought up when the script interpreter was written?

Gabriel

(Posted 2009) [#4]

I'm an enormous fan of scripting, but this seems entirely the wrong place for it, both for the reason you gave and for reasons of speed and security. I believe BlitzMax can now write DLL's and that's the way I would do this. Have a standard interface which each DLL needs to comply to. For exampe, every plugin would need an Init function which takes certain parameters and returns an object or whatever. Every plugin needs a Shutdown function, and that doesn't take any parameters (or maybe it does, just an example.)

Now it's obviously going to vary depending on exactly what you want the plugins to do, but that's essentially how I would do it. You can do everything with functions the DLL must implement or you could perhaps have a set of function pointers which are passed to the DLL in the Init function, thus giving the DLL the ability to call functions in your main program, which might be responsible for passing images, or whatever.

Basically, anything which is always going to be required by every plugin should be set out in the enforced structure of the DLL, and things which the plugin may or may not wish to use could be done via function pointers.

Then just put all plugins in a certain folder, and have your program search for all the DLL's in that folder, then dynamically link to the requisite functions in each DLL. If the program detects that one or more required functions is missing or invalid, it writes out to a log that the plugin is invalid and moves on to the next plugin.

kfprimm

(Posted 2009) [#5]

Here's a quick and simple example of what Gabriel is talking about. Drop all these files into the same directory and run,

bmk makelib brightenplugin.bmx
bmk makelib grayscaleplugin.bmx

to build the plugins.

Only tested on Windows but it should work fine on the other two.

plugintest.bmx


Strict

Local plugins:TPlugin[]=TPlugin.LoadFromDir(".\")
For Local plugin:TPlugin=EachIn plugins
	Print "Loaded '"+plugin.GetName$()+"' from "+StripDir(plugin.GetFile())
Next
If plugins.length=0 Notify "Sorry, no plugins could be loaded!"

Graphics 320*2,260,0
SeedRnd MilliSecs()

SetViewport 0,0,320,240
For Local i=0 To 99
	SetColor Rand(100,255),Rand(100,255),Rand(100,255)
	DrawRect Rand(0,319),Rand(0,239),Rand(0,50),Rand(0,50)
Next
SetViewport 0,0,320*2,260

Local original:TPixmap=GrabPixmap(0,0,320,240)

Local originalimage:TImage=LoadImage(original)
Local copyimage:TImage

Local currentplugin
SetColor 255,255,255
Repeat
	If KeyHit(KEY_ENTER)
		currentplugin:+1
		If currentplugin>plugins.length-1 currentplugin=0
		Local copy:TPixmap=CopyPixmap(original)
		plugins[currentplugin].Execute(copy)
		copyimage=LoadImage(copy)		
	End If

	Cls
	DrawImage originalimage,0,0
	If copyimage
		DrawImage copyimage,320,0
		DrawText "Current plugin: "+plugins[currentplugin].GetName(),0,GraphicsHeight()-TextHeight("|")
	EndIf
	Flip
Until KeyDown(KEY_ESCAPE) Or AppTerminate()


?Win32
Const PLATFORM_DL_EXT$ = "dll"
?MacOS
Const PLATFORM_DL_EXT$ = "dylib"
?Linux
Const PLATFORM_DL_EXT$ = "so"
?
Type TPlugin
	Field _name$,_file$,lib
	Field _getnameptr:Byte Ptr
	Field _executeptr:Byte Ptr
	
	Function Load:TPlugin(dll$)
		Local plugin:TPlugin=New TPlugin
		plugin._file=dll
		?Win32
		plugin.lib=LoadLibraryA(dll)
		?Not Win32
		plugin.lib=dlopen(dll,1) 
		?

		If plugin.lib=0 Return Null
		?Win32
		plugin._executeptr=GetProcAddress(plugin.lib,"Plugin_Execute")
		plugin._getnameptr=GetProcAddress(plugin.lib,"Plugin_GetName")
		?Not Win32
		plugin._executeptr=dlsym(plugin.lib,"Plugin_Execute")
		plugin._getnameptr=dlsym(plugin.lib,"Plugin_GetName")
		?	
			
		If plugin._executeptr=Null Or plugin._getnameptr=Null Return Null
		Return plugin
	End Function
	
	Function LoadFromDir:TPlugin[](dir$)
		Local plugins:TPlugin[]
		For Local file$=EachIn LoadDir(dir)			
			If FileType(file)<>FILETYPE_FILE Or ExtractExt(file)<>PLATFORM_DL_EXT Continue
			plugins=plugins[..plugins.length+1]
			plugins[plugins.length-1]=Load(file)
		Next
		Return plugins
	End Function
	
	Method Execute(pixmap:TPixmap Var)
		Local executefunc:TPixmap(pixmap:TPixmap Var)=_executeptr
		executefunc(pixmap)
	End Method
	
	Method GetFile$()
		Return _file
	End Method
	
	Method GetName$()
		If _name=""
			Local getnamefunc$()=_getnameptr
			_name=getnamefunc()
		EndIf
		Return _name
	End Method
End Type

brightenplugin.bmx


Strict

Framework BRL.Pixmap

Function Plugin_GetName$()
	Return "Brighten"
End Function

Function Plugin_Execute(pixmap:TPixmap Var)
	pixmap=ConvertPixmap(pixmap,PF_RGB888)
	For Local y=0 To pixmap.height-1
		For Local x=0 To pixmap.width-1
			Local pixel:Byte Ptr=pixmap.PixelPtr(x,y)
			pixel[0]:+100
			pixel[1]:+100
			pixel[2]:+100
		Next
	Next
End Function

grayscaleplugin.bmx


Strict

Framework BRL.Pixmap

Function Plugin_GetName$()
	Return "Grayscale"
End Function

Function Plugin_Execute(pixmap:TPixmap Var)
	pixmap=ConvertPixmap(pixmap,PF_RGB888)
	For Local y=0 To pixmap.height-1
		For Local x=0 To pixmap.width-1
			Local pixel:Byte Ptr=pixmap.PixelPtr(x,y)
			Local gray=(pixel[0]+pixel[1]+pixel[2])/3
			pixel[0]=gray
			pixel[1]=gray
			pixel[2]=gray
		Next
	Next
End Function

grayscaleplugin.def AND brightenplugin.def

EXPORTS
Plugin_Execute=bb_Plugin_Execute
Plugin_GetName=bb_Plugin_GetName

buildplugins.bat

"C:\Program Files\BlitzMax\bin\bmk.exe" makelib brightenplugin.bmx
"C:\Program Files\BlitzMax\bin\bmk.exe" makelib grayscaleplugin.bmx

CASO	(Posted 2009) [#6]

I am running a Mac and I got "Compile Error: Identifier 'dlopen' not found".
However I do see what you seem to be suggesting.

Also what do I do with:

bmk makelib brightenplugin.bmx
bmk makelib grayscaleplugin.bmx

I'll test on windows in the morning....

kfprimm

(Posted 2009) [#7]

Sorry, those two lines should be run from the command line/terminal in order to build the plugins.

Use this, (I've added it to my original post as well)
buildplugins.bat

"C:\Program Files\BlitzMax\bin\bmk.exe" makelib brightenplugin.bmx
"C:\Program Files\BlitzMax\bin\bmk.exe" makelib grayscaleplugin.bmx

You may need to modify the path for the BlitzMax installation.

As for the Mac issue. Sorry, I don't have one availible for testing. However, upon a quick Google search, it appears that dlopen/dlsym/etc has been removed in newer versions of Mac OS X.
Hopefully, someone else around here can be of help.

ImaginaryHuman

(Posted 2009) [#8]

I say no to dll's, they're not cross-platform and for someone to create one requires more know-how than being able to write something in an easy-to-understand script language.

The thing is you have to make your script language feature-filled enough and with enough sort of `programming` features so that it can actually be useful for creating previously unthought-of routines. Obviously it shouldn't just be a bunch of function calls, you need stuff like loops and branches and tests and such ... take javascript for example.

kfprimm

(Posted 2009) [#9]

BlitzMax can build dynamic libraries for each platform so that's not an issue.

plash

(Posted 2009) [#10]

A linked-library will also likely be faster than any scripted language (even if not by much).

Brucey

(Posted 2009) [#11]

I am running a Mac

Well, if you get it working, please let me know :-)

CASO	(Posted 2009) [#12]

I did some more looking around and it looks like BMAx is capable of making dll files but not dylibs (Putting cross-platform out the window).

Correct me if I'm wrong.

kfprimm

(Posted 2009) [#13]

After looking around, it appears you're right. makelib seems to only be supported on Windows. Could a Linux user confirm that?

Brucey

(Posted 2009) [#14]

Win32 only. I don't think there's every been any intention of it being otherwise.

plash

(Posted 2009) [#15]

Bummer :(

CASO	(Posted 2009) [#16]

Is there any other way to get two exes/apps to "talk to each other"?

Brucey

(Posted 2009) [#17]

Several

TCP
UDP
Interprocess Communication

CASO	(Posted 2009) [#18]

I think someone already talked about "Interprocess Communication". What is that?

grable

(Posted 2009) [#19]

I think someone already talked about "Interprocess Communication". What is that?

The first paragraphs here explain it pretty well http://msdn.microsoft.com/en-us/library/aa365574%28VS.85%29.aspx
although for windows, the same holds true for linux and mac just with different primitives.

CASO	(Posted 2009) [#20]

Correct me if I'm wrong, but you are saying that Interprocess Communications are provided by the operating system, not the applications themselves?

ImaginaryHuman

(Posted 2009) [#21]

Inter-process just means that you have two `processes` running in parallel, like two applications, and somehow they are communicating with each other by some means. That could be that you send messages over the network with TCP, or using the inter-process API provided by the operating system. Most/all operating systems have a library of functions you can use to `send and receive messages` to/from applications - it's faster than using TCP networking stuff. But to use it you do have to access the o/s's API.

CASO	(Posted 2009) [#22]

Well that path doesn't sound very friendly.

One last question, is it possible for one program to "call" another program, similar to I think it is called createProcess in blitzplus. In a nutshell it calls another program and grabs it's output.

Brucey

(Posted 2009) [#23]

One interesting thing I came up with today is a TSharedBank, which is a TBank that can be shared between different running processes (applications), as part of my BaH.Interprocess module.

It acts much like a static bank, the difference being the data can be shared between the processes.

Local bank:TBank = CreateSharedBank("mybank", 1000)

bank.PokeInt(0, 55)

' etc

Fun fun :-)

CASO	(Posted 2009) [#24]

So this is part of yet another wonderful Brucey mod?

degac

(Posted 2009) [#25]

I found http://www.blitzbasic.com/Community/posts.php?topic=65705#734079 , no multi-platform, but it should work.

Brucey

(Posted 2009) [#26]

So this is part of yet another wonderful Brucey mod?

Well, I wouldn't say it's wonderful, but it is cross-platform, which is always useful for those of us that don't use Windows.

CASO	(Posted 2009) [#27]

Interestingly enough, I downloaded all of your modules though svn a month ago because it seems like BMax just isn't complete without them. And there it was. Interprocess.mod. I'll check it out.