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


Reply via email to