Hi, thanks for your quick reply. I found the culprint while writing this email :-)
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/��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.��
I'm running Pharo from PharoLauncher directly on Win10, without cygwin/mingw. For DLL I use Visual Studio 2019. I was not sure whether the pointer survives from one FFI call to another, or how Pharo loads/unloads DLLs - but it works as expected.
Thanks again and best wishes,
Tomaz
------ Original Message ------
Sent: 11. 09. 2019 10:29:34
Subject: Re: [Pharo-users] uFFI ExternalAddress challenges
Hi Thomas,��
Can you share more about the definition of your��CallMethod function in C?
From the uFFI point of view the binding looks ok���
How are you opening Pharo? From the command line or the pharo launcher?
Are you on cygwin/mingw?��One other possibility (since you���re playing with C libraries) is to launch Pharo inside a gdb/lldb so you can check the reason behind the error when it crashes.
Keep us posted,