Asbjoern Pettersen writes:
> The OS/2 and UNIX code is doing the same !
> The structure PLUG_IN_INFO is a REAL input and should be a parameter
> input to gimp_main(). ex: gimp_main(argc,argv, &PLUG_IN_INFO);
>
> On UNIX they trust/use fork() to input the structure, but my OS/2
> version will work on all system with or without forking.
Sorry, I don't follow you here, I don't see any forking going on. To
my understanding, PLUG_IN_INFO is (on Unix) a (data) entry point
(i.e. a externally visible variable) in the plug-in executable, and
the libgimp shared library references it. The problem with
PLUG_IN_INFO on OS/2 apparently is that it's hard on OS/2 to refer to
exported variables in the executable that has loaded a shared library
from the library.
Although on Win32 you could look up the PLUG_IN_INFO address in the
plug-in executable from the DLL (as long as it is marked for export),
I do it almost like OS/2: I pass the address of PLUG_IN_INFO to a
function in libgimp, that stores it in a place easily accessible to
libgimp. (On OS/2, you store a copy of PLUG_IN_INFO in libgimp, while
on Win32 I only store a pointer.)
I agree with you, the "pass PLUG_IN_INFO address as parameter from the
plug-in to gimp_main in libgimp" approach could well be used for all
platforms, it would clean up the ifdefs in gimp.c and gimp.h quite a
bit.
--tml
