FFI and absolute path to dll
Locked
 
|
Hello,
I'm using Pharo 8 64bit on Windows 10 64bit. I am trying to access a 32bit dll via a relative path. I'm desperate. I've been reading the document (http://books.pharo.org/booklet-uffi/pdf/2020-02-12-uFFI-V1.0.1) all the time up and down but I can't find an example of absolute path and Windows. If e.g. my.dll file would be stored here. C:\Program Files (x86)\GALEP5\my.dll then what should the method win32ModuleName return? Another question came to me while reading the document. It is actually important to know whether the DLL was generated as cdecl or stdcall? The dll i try to call use stdcall. I would be very happy if someone helps me. I can no longer see the message "External module not found" :-) Thanks a lot! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Re: FFI and absolute path to dll
Administrator
|
On Tue, May 12, 2020, 12:05 ASAM <[hidden email]> wrote: Hello, Generally, a 64-bit program will only load a 64-bit DLL. It may be possible, but it will likely be far easier to use the 32-bit Pharo implementation.
|
|
|
In reply to this post by ASAM
At some point in the history of Win 7, MS changed the rules for file
lookup
Standard Search Order for Desktop ApplicationsAt some point, MS enabled safe DLL search mode as default. It is now part of the Windows security barrier, and I dare not change it. A program I had scheduled to start every day stopped working when I moved the program to a new computer with a new edition of Windows. I'm hoping the creator of the program will fix the problem. In the mean time, I have to remember to start the program manually every morning. This applies to Win7 and Win 10. Hope this helps even if it doesn't solve the problem. --Trygve On 12.05.2020 21:04, ASAM wrote:
Hello, I'm using Pharo 8 64bit on Windows 10 64bit. I am trying to access a 32bit dll via a relative path. I'm desperate. I've been reading the document (http://books.pharo.org/booklet-uffi/pdf/2020-02-12-uFFI-V1.0.1) all the time up and down but I can't find an example of absolute path and Windows. If e.g. my.dll file would be stored here. C:\Program Files (x86)\GALEP5\my.dll then what should the method win32ModuleName return? Another question came to me while reading the document. It is actually important to know whether the DLL was generated as cdecl or stdcall? The dll i try to call use stdcall. I would be very happy if someone helps me. I can no longer see the message "External module not found" :-) Thanks a lot! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html --
The essence of object orientation is
that objects collaborate to achieve a
goal. |
Re: FFI and absolute path to dll
|
|
I use this with VLC win32LibraryName ((OSEnvironment current at: 'Path' ifAbsent: [ '' ]) substrings: ';'), {'C:\Program Files\VideoLAN\VLC'} do: [ :path | | libraryPath | libraryPath := path asFileReference / 'libvlc.dll'. libraryPath exists ifTrue: [ ^ libraryPath fullName ] ]. self error: 'Cannot locate vlc library. Please check if it installed on your system' Le mar. 12 mai 2020 à 22:17, Trygve Reenskaug <[hidden email]> a écrit :
|
|
|
Thanks for the tips. It really helped me a lot.
The dll is now loaded (I chose the 64-bit version of the dll). I am currently working on value mashalling and I want to create an ENUM class subclass from FFIEnumeration. Inside http://books.pharo.org/booklet-uffi/pdf/2020-02-12-uFFI-V1.0.1 i read chapter 4.4 Enumerations. I tried the example. For me, however, only new class variables are created after "ExampleEnumeration initialize". Is that okay? or a bug? In Doc..."You will see that the enumeration class gets redefined as follows creating and initializing a class variable for each of its elements." but i can't see the initializing. Do I have a mistake in thinking? Thanks for your help and time. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
|
On Sun, 17 May 2020 at 20:54, ASAM <[hidden email]> wrote: Thanks for the tips. It really helped me a lot. The class-side #initialization method only gets called when the class is created e.g. when first loaded into a fresh image. It doesn't get re-run just because you edit the method, because the class is already initialized. By analogy, evaluating ``x := MyObject new`` invokes the instance-side initialize when the object is created. Subsequently editing MyObject >> #initialize wont change any values in the existing object in `x`. Remember "classes are objects too". cheers -ben |
Re: FFI and absolute path to dll
|
|
> On 18 May 2020, at 19:12, Ben Coman <[hidden email]> wrote: > > The class-side #initialization method only gets called when the class is created e.g. when first loaded into a fresh image. Almost: it gets to run whenever the method is loaded and is new or different. If the method is loaded again and its source code is the same, it does not run. |
|
|
Oh. Thank you for your answers. Now that you say it, I remember it. I dealt
with Pharo 2 years ago. And now I come back to load and execute a DLL with Pharo. Does anyone have a more detailed example of FFIOpaqueObjectis object than in the book (http://books.pharo.org/booklet-uffi/pdf/2020-02-12-uFFI-V1.0.1) ? I don't really understand it yet. I want to call a DLL whose API has 33 functions, 41 structures and 15 enums. I would like to do it right and I have to understand everything first so that I can then decide how to implement it. Thank you for your help -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
|
Can you specify the API? cheers -ben On Tue, 19 May 2020 at 05:02, ASAM <[hidden email]> wrote: Oh. Thank you for your answers. Now that you say it, I remember it. I dealt |
|
|
Of course there is a documentation for the API.
It is even an ISO standard. And if I can do that, I would also like to make it available on GitHub. That's why it should be good. It is the ISO 22900-2 D-PDU-API. I can also attach the header file. However, the PDF is provided with a watermark. So please google. The API is provided by different manufacturers. The process is roughly the following, for Windows systems read a resitre key that says where the root.xml is. On Linux the pdu_api_root.xml is under /etc. In the root.xml you can find where the individual suppliers have installed their dll. With the absolute path you can now load the dll. Under Linux it would be a so-file which I have never seen live. I would say 95% use it only under windos. Thanks for help. ISO22900_2.h <http://forum.world.st/file/t372350/ISO22900_2.h> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
|
On Tue, 19 May 2020 at 23:09, ASAM <[hidden email]> wrote: Of course there is a documentation for the API. Cool. I have an example using FFIOpaqueObject here... cheers -ben |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |