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
