I'm playing with DXE a bit, and got it working nearly straight away.

Unloading is not supported by the standard DXEloading unit, but can be easily added, and I will do that next.

Unfortunately, it will break the interface of the current DXELOAD unit.

I uploaded a extremely simple demo with everything needed to demonstrate DXE except a working 1.0.4 Go32V2 release to

http://www.stack.nl/~marcov/dxedemo.zip

Archive: dxedemo.zip
Length Method Size Ratio Date Time CRC-32 Name -------- ------ ------- ----- ---- ---- ------ ---- 223 Defl:N 123 45% 07-20-01 11:38 b23d4456 ADD.PP 136 Defl:N 115 15% 07-20-01 12:16 b4e5e883 adddemo.pp 83 Defl:N 61 27% 07-20-01 12:17 fa40e4f7 CREATE.BAT 151 Defl:N 110 27% 08-25-99 05:45 57f4c0c7 dxe.ld 87552 Defl:N 49084 44% 01-04-00 14:35 d6e7f05f dxegen.exe -------- ------- --- ------- 88145 49493 44% 5 files

add.pp is the unit to be converted to DXE. It contains one function that adds two numbers.
adddemo.pp is the demo that loads add.dxe
create.bat generates the .DXE. Simply unpack the zip, and run this batchfile, and then the generated adddemo.exe
dxe.ld needed linker script
dxegen.exe DJGPP DXE generator tool.

--------------------------------------------------------------------

Some points about DXE:

- The code loaded has to be totally self contained, and a unit. You cannot call any RTL procedures directly from the DXE, you can also not call DXE directly from the mainprogram. However the mainprogramma can pass you pointers to e.g. GETMEM and FREEMEM so that you can allocate/deallocate memory. Don't forget that a lot of actions (string manipulation, exceptions using int64 etc implicitely call RTL procedures)
One can in theory link the needed RTL functionality in the DXE.

- One can only pass ONE pointer from the DXE to the main program on load. Nothing more. I'm studying on a system to enhance this at the moment. For the experimentors: Let this pointer point to a structure or function that can return more pointers to structures and functions. Via parameters to such functions, you can load global variables in the DXE with needed RTL functions.

Great job, it works!!
Anyway I found that Stack checking must be turned off, otherwise DXEGEN cannot process STACKCHECK symbol in .o file...

Regards, Pavel Kanzelsberger

At 13:54 20/07/01 , vous avez écrit:

Great job, it works!! Anyway I found that Stack checking must be turned off, otherwise DXEGEN cannot process STACKCHECK symbol in .o file...

For the same reason you would need to disable Range check, as this also uses a system help procedure.

Great job, it works!! Anyway I found that Stack checking must be turned off, otherwise DXEGEN cannot process STACKCHECK symbol in .o file...

It is the same problem as mentioned in the prev. msg. Internal procedures fail. A workaround could be:

What do you want to use DXE for? What kind of code do you want to put in the DXE?

---------------------------------------------------------- Untested:

Use this in your DXE code:

type ThandleerrorProc = procedure (Errno:longint);
var remotestkbottom : ^longint;
    remotehandleerror : THandleErrorProc;

procedure int_stackcheck(stack_size:longint);[public,alias:'FPC_STACKCHECK']; {
called when trying to get local stack if the compiler directive $S is set this function must preserve esi !!!! because esi is set by the calling proc for methods it must preserve all registers !!

With a 2048 byte safe area used to write to StdIo without crossing the stack boundary
}
begin
asm
pushl %eax
pushl %ebx
movl stack_size,%ebx
addl $2048,%ebx
movl %esp,%eax
subl %ebx,%eax
movl remotestkbottom,%ebx
movl (%ebx),%ebx
cmpl %eax,%ebx
jae .L__short_on_stack
popl %ebx
popl %eax
leave
ret $4
.L__short_on_stack:
{ can be usefull for error recovery !! }
popl %ebx
popl %eax
RemoteHandleError(202)

  end['EAX','EBX'];

end;

-----------------------
And then your main program should

have

var
   stkbottom : longint;external name '__stkbottom';

and via DXE calls you should set

remotestkbottom to @stkbottom;
remotehandleerro to @handleerror;

Okies, thanks for the usefull information!

I need DXEs for DOS version Pixel32 (http://pixel32.box.sk), this should be first DOS application supporting plugins :))

Regards, Pavel Kanzelsberger

Okies, thanks for the usefull information! I need DXEs for DOS version Pixel32 (http://pixel32.box.sk), this should be first DOS application supporting plugins :))

How does your (desired?) pluginterface look like?

I'm playing with DXE a bit, and got it working nearly straight away.

Rather interesting for me as well, thanks!
However, I have several questions

Some points about DXE: - The code loaded has to be totally self contained, and a unit.

Does this mean that:
(a) it can't be linked with other DXE's
(b) it can't be linked with ANY other code (i.e. no "USES") ?

You cannot call any RTL procedures directly from the DXE, you can also not

This means 'no SYSTEM unit', I suppose...

call DXE directly from the mainprogram. However the mainprogramma can

Pardon? I can't understand this, adddemo.pp has a direct call to the DXE...

writeln('5+6 =',addfunc(dxe_load('add.dxe'))(5,6));

How is this passed?

Two more related to this, about dxe_load, when I call it, the DXE is loaded, then executed, then it disappears from memory?

If the answer is (or can be) NO, if I start two procedures of the same DXE unit, are they sharing these global variables? Or are different instances of the DXE unit loaded in memory, so that these variables are newly created for every instance?
If yes, is it possible somehow for the DXE to keep in memory some variables that can be shared by everybody? By everybody I mean: (a) all the procedures of the DXE
(b) the main program that calls the DXE
(c) every program that is 'EXEC()'-ed from the main program?

And a final one, I have seen this in your BAT program: dxegen add.dxe _ADD$$_ADDNUM$LONGINT$LONGINT add.o

do you have to declare every function? If so, where can I read about the data identifiers (e.g. LONGINT) that are used in this declaration?

Thanks in advance,

Aitor

___________________________________________________________________ Consigue tu e-mail gratuito TERRA.ES
Haz clic en http://www.terra.es/correo/

Kanzelsberger Pavel wrote

Okies, thanks for the usefull information! I need DXEs for DOS version Pixel32 (http://pixel32.box.sk), this should be first DOS application supporting plugins :))

Sorry to dull your moment of glory ;), but it is not the first. At least (Open) Cubic Player originally from Cubic Team had a somekind DLL-based plugin system. I don't know much about it, but it worked OK.

OpenCP is not developed anymore (it was maintained by KB aka Tammo Hinrichs, but it has been in zombie state for some time), but the sources are available under GPL.

http://www.cubic.org/player/

=- ccr/TNSP^pWp
] | http://www.tnsp.org/
] Show me your "realtime raytracer in Java"
] and I'll show you my CBM 8032, 2 MHz!

> I'm playing with DXE a bit, and got it working nearly straight away. Rather interesting for me as well, thanks! However, I have several questions

No problem.

Only via the mainprogram (passing pointers around via the mainprogram)

(b) it can't be linked with ANY other code (i.e. no "USES") ?

Not yet. I'm still studying for a way to do this runtime, and for that I have to fully understand the COFF format. This won't happen overnight.

> You cannot > call any RTL procedures directly from the DXE, you can also not This means 'no SYSTEM unit', I suppose...

Not direct. Only by loading them into DXE global variables just after initialisation. Pretty much like the STACKCHECK example.

> call DXE > directly from the mainprogram. However the mainprogramma can Pardon? I can't understand this, adddemo.pp has a direct call to the DXE...

I stated it not really clear:

You can call directly, but there is no direct binding.

writeln('5+6 =',addfunc(dxe_load('add.dxe'))(5,6));

This isn't entirely direct, since mainprogram routine "dxe_load" returns a pointer, which is typecasted to type "addfunc", and indirectly executed as a procedure variable.

As return value from the dxe_load procedure above.

This could be a pointer to an array of pointers to a lot of procedures though.

Or a procedure that somehow gets pointers from the mainprogram to the DXE via parameters.

No. Unloading is not yet possible, but not hard to implement. In the future it can be removed from memory, but that will require an explicit call.

IOW you can load an DXE, make as much calls as you want, and kill it.

If the DXE allocates heap (via het mainprogram), it will be allocated even if the DXE unloads.

If the answer is (or can be) NO, if I start two procedures of the same DXE unit, are they sharing these global variables?

Yes, and units in the DXE can call eachother normally, and do all the normal stuff. In fact you are loading a kind of second exe.

Or are different instances of the DXE unit loaded in memory, so that these variables are newly created for every instance?

No. The DXE also doesn't create anything. It can't contain startup code.

Exec() is a differnet memory space. The main program can access DXE variables, but doesn't know where they are. The DXE has to provide the mainprogram with pointers to the variables.

You can use -a and see the names in the .s file.

However at the moment the DXEGEN program is still a C program. I converted it to Pascal (still have to test it), but probably we can slip in some more sensible way of doing this.

.DXE's also have the disadvantage that they need some memory to initialise (and relocate).

It's too difficult to describe it completely, but basics are here:

Host loads plugin and calls entry procedure in plugin (DXE), sends pointer to structure containing a lot of variables and adresses to procedures...

Plugin will use these procedures and variables from host program, that's all ...

Regards, Pavel Kanzelsberger

Hehe yepz, I know about that player, I mean first image editor for DOS, I have never heard about DOS image editor with effect and import/export plugins... :-))

Regards, Pavel Kanzelsberger

Kanzelsberger Pavel wrote

Hehe yepz, I know about that player, I mean first image editor for DOS, I have never heard about DOS image editor with effect and import/export plugins... :-))

Now that you mention ... ;) There is this program called VGAPaint386 (a Deluxe Paint II clone by Avery Lee, best known for his Virtual Dub video editing software) that had somekind of plugin system. The

VGAPaint386 is also a long dead project, but also available under GNU GPL :) (Don't know where from, but I have the package if someone wants it)

I don't know if you meant a drawing program with "image editor", but oh well :)

=- ccr/TNSP^pWp
] | http://www.tnsp.org/
] Show me your "realtime raytracer in Java"
] and I'll show you my CBM 8032, 2 MHz!

Seems fit for DXE :-)

Wow really? Can you please upload it to web somewhere so I can check it? With image editor I don't mean that old classic pixel by pixel drawing programs like Grafx2, but something like Photoshop with layers, effect plugins, import/export plugins etc. :)

Regards, Pavel Kanzelsberger

Yepz :))

Kanzelsberger Pavel wrote

Wow really? Can you please upload it to web somewhere so I can check it? With image editor I don't mean that old classic pixel by pixel drawing programs like Grafx2, but something like Photoshop with layers, effect plugins, import/export plugins etc. :)

Well, VGAPaint is quite like Grafx2, but with more like DP2-style interface. So not like Photoshit ;)

I'll try to remember to put it online somewhere as soon as a remember. I will post a link here when I do.

=- ccr/TNSP^pWp
] | http://www.tnsp.org/
] Show me your "realtime raytracer in Java"
] and I'll show you my CBM 8032, 2 MHz!

Thanks :)
Yes, Photoshit, that's why I started to develop my own :)

Regards, Pavel Kanzelsberger