> El 11 sept 2019, a las 11:07, Tomaž Turk <tomaz.t...@ef.uni-lj.si> escribió: > > Hi, thanks for your quick reply.
no problem ;) > I found the culprint while writing this email :-) Cool! > > Generally, what I'm trying to do is to make a very basic package to create > and communicate with COM components on Windows, mostly as an exercise :-) I > found this library: http://disphelper.sourceforge.net/ > <http://disphelper.sourceforge.net/> as a great start, so you don't have to > fiddle with OLE/COM headaches. > > The problematic function in C is defined as: > > __declspec(dllexport) void CallMethod(void* myObj) { > ... > } > > It takes a pointer to a COM object, which was previously returned by > > __declspec(dllexport) void* CreateObject(char* szProgId) { > ... > IDispatch * myObj = NULL > ... > return &myObj; > } > > So, CreateObject() creates COM object and returns a pointer to it, > CallMethod() takes this pointer and tries to communicate with it. > > My error was in returning a pointer to a pointer ... since IDispatch * myObj > = NULL was actually hidden in a macro and I missed its true definition, huh. Yes, looking at the code above it seems strange returning the &myObj, being myObj a local variable. Because that means that you would be returning a pointer to the stack, from a frame that already returned... > > I was not sure whether the pointer survives from one FFI call to another Well, the pointer survives, the area of memory pointed by that pointer will be recycled with subsequent calls in general. > , or how Pharo loads/unloads DLLs - but it works as expected. In general Pharo will load the library on usage, so you don’t have to care about it. I’m sure the library is not unloaded, unless it is done explicitly (you can check VirtualMachine >> unloadModule:) > > Thanks again and best wishes, > Tomaz Cheers!
