SRL Archive - Development

This is outdated as far as I now know

I just wanted to put the source code of example plugins for Lape here :).

FreePascal:

library simpasplug;

{$mode objfpc}{$H+}

uses
  Classes, SysUtils, lptypes;
  
{$R *.res}

procedure a(Params : PParamArray; Result : Pointer);
begin
  PLongInt(Result)^ := 42;
end;

function GetFunctionCount(): Integer; stdcall; export;
begin
  Result := 1;
end;

function GetFunctionInfo(x: Integer; var ProcAddr: Pointer; var ProcDef: PChar): Integer; stdcall; export;
begin   
  case x of
    0: begin
        ProcAddr := @a;
        StrPCopy(ProcDef, 'function a(): integer;');
      end;
    else
      x := -1;
  end;
  Result := x;
end;

exports GetFunctionCount;
exports GetFunctionInfo;

initialization
end.

This Pascal plugin uses the lptypes unit which is in lape (lptypes = lape types). So you'll have to add it to your project if you want to compile the above plugin. If you don't want to add the type, you can declare your own types. TParamArray = array[word] of Pointer, PParamArray = ^TParamArray, and PLongInt should already be defined. If not, PLongInt = ^LongInt.

C:

#include <string.h>

static void __fastcall a(void **params, void *result) {  
  *(int *)(result) = 42; 
}

static int __stdcall GetFuncCount(void) {
  return 1;
}

static int __stdcall GetFuncInfo(int x, void **addr, char **def) {
  switch (x) {
    case 0:
      *addr = (void *)&a;
      strcpy(*def, "function a(): integer;");
      break;
    default:
      x = -1;
  }
  return x;
}

int GetFunctionCount(void) __attribute__((alias("GetFuncCount@0")));
int GetFunctionInfo(int x, void **addr, char **def) __attribute__((alias("GetFuncInfo@12")));

I don't really know C, I just used the example plugin provided by Dgby and converted it to the way Lape uses it. I did have one problem though, Lape didn't like the __stdcall calling convention and Niels suggested I use __fastcall and that worked :).

Lape passes a pointer to an array of pointers for the parameters and a pointer to the result for the result.

Therefore, to access a parameter, you must first cast it as a pointer of the type you're expecting, dereference the params pointer, and then dereference the casted pointer.

Use highlight tags. I believe it's

and

. That would make it so much more readable ;). But nice to see the plugins for lape. Lape is getting real.

From: masterBB
Use highlight tags. I believe it's

and

. That would make it so much more readable ;). But nice to see the plugins for lape. Lape is getting real.

Right. I even wrote a functional SQLite plugin :).

Just so we're clear on everything here, the only part that is lape specific is the function definition string. This function loading mechanism was used by SCAR and I implemented it in SIMBA so we wouldn't have to change all the plugins. Lape should be assuming stdcall because fastcall is not standardized between compilers, but stdcall is.

E: It may be necessary to append "stdcall;" to the function definition passed to lape, which shouldn't affect PS (PS assumes stdcall, idk why lape would EVER assume fastcall). Then all plugins will work with no modification

E2: Sex point out that lape can't actually do native calls and has a set argument style. This is unacceptable — if lape is open source someone should port the PS stdcall routine into it.

From: BenLand100
Just so we're clear on everything here, the only part that is lape specific is the function definition string. This function loading mechanism was used by SCAR and I implemented it in SIMBA so we wouldn't have to change all the plugins. Lape should be assuming stdcall because fastcall is not standardized between compilers, but stdcall is.

If you mean standardized as in, it works only on 32 bit machines, then yes. But it is by no means a call for all platforms. It doesn't exist in x86_64 (which I previously told you) and it also doesn't work on ARM. One of the things that makes lape stable and cross platform is the fact that it relies on FPC / other compilers to generate the actually asm for doing the system calls, with an extra wrapper as drawback. (Wrappers which we already had in PS too).

From: BenLand100

E: It may be necessary to append "stdcall;" to the function definition passed to lape, which shouldn't affect PS (PS assumes stdcall, idk why lape would EVER assume fastcall). Then all plugins will work with no modification

E2: Sex point out that lape can't actually do native calls and has a set argument style. This is unacceptable — if lape is open source someone should port the PS stdcall routine into it.

Lape is open source and you're free to give it a shot, but I suspect nothing but trouble. You could just write wrappers for it. (Or someone else could, it's not too hard)

Maybe, in time, I could wrap libffi, so people can create their own wrappers in a script. Perhaps with some help functions from the compiler to make it even easier. But, as Wizzup stated, I want to stay away from platform specific code as much as possible. For Pascal Script it has created nothing but trouble. I believe it is one of the major reasons why PS doesn't work on anything but Windows x86.

Anyway, this is very cool, Sex! A SQLite plugin sounds awesome :)