(sorry as this topic became extinct some time ago, I am having troubles
with my ISP and outgoing mail)
No problem at all.
Show quoted text 9 lines
> > (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.
Ok! Keep up the good job and let us know!
It's a pitty that one can't design some UNITs that interface with the
DXE, in order to "hide" so many pointers going here and there...
One can try to wrap it.
In addition, this will make the whole thing a lot easier, I suppose.
Perhaps if this support is added, the RTL can then be used...
That still doesn't solve calling from main to DXE, only the other way around.
Show quoted text 19 lines
> > > 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.
> >
> > Two more related to this, about dxe_load, when I call it, the
> DXE is
> > loaded, then executed, then it disappears from memory?
>
> 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.
Can it be "exitted" using DOS interrupt for it? Is that what you mean
by "explicit call"?
No. But you need to really do
Uses DXE;
var handle : dxehandle;
thepointer : pointer;
begin
handle:=loaddxe('my.dxe');
ThePointer:=GetDXESymbol(Handle,0); {Now always 0}
[do your thing, cast thepointer to procedure type and call it]
Unload(handle);
end.
The DXE unit (that supports unloading) is on
http://www.stack.nl/~marcov/dxe.pp
I also ported the dxegen util to Pascal. The source is in CVS in the fpc/utils/dxegen directory.
And if I run a program that calls DXEs, and the program dies, will the
DXE die as well?
Then the DXE will be unloaded. The DXE is on the heap, and can be unloaded as long as there isn't a handler or so pointer into the DXE.
Hooking interrupts in DXE code is not smart :-)
Show quoted text 5 lines
> .DXE's also have the disadvantage that they need some memory to
> initialise(and relocate).
32 bit programs tend to eat few of the convenctional memory anyway...
A new one: Can I use DJGPP's DXE's from a FPK program, and conversely?
At the moment, yes, but watch your calling conventions, just like usual when interfacing with C.
In the future I'll have to stuff more info into the DXE, and it will become incompatible. But that "incompatible" stuff will be implementable in DJGPP too.
I'll change the magic if that happens, so that it won't cause accidents.
