How do I call DLL functions from Crystal on Windows?

kojix2 · August 14, 2023, 2:32am

Hi

Calling functions from shared libraries on Linux and MacOS are easy.
I want to do the same on Windows. Can you show me how?

If you have links to helpful websites, that would be awesome.

erdian718 · August 14, 2023, 5:47am

I successfully called sqlite3.dll functions on Windows, maybe for you as a reference:

First, create sqlite3.lib from sqlite3.def:

lib /DEF:sqlite3.def /OUT:sqlite3.lib /MACHINE:x64

Second, put sqlite3.lib to Crystal/lib and put sqlite3.dll to your_app/bin.

Now, we can call sqlite3.dll functions by Link annotation.

kojix2 · August 15, 2023, 11:54am

I see.
I did indeed need the .lib file as well as the .dll file.
Thank you.

kojix2 · August 19, 2023, 12:10am

Is there any way to get it to work using environment variables instead of copying the lib files directly?
I have tried a little and it did not work.

github.com/crystal-lang/crystal

Overriding the default dynamic library lookup path

opened 10:18AM - 22 May 23 UTC

closed 08:58AM - 05 Jun 23 UTC

HertzDevil

kind:feature topic:compiler topic:stdlib:runtime

`crystal run` and the macro `run` create a temporary executable in Crystal's cac…he directory. On Windows, programs typically do not install their DLLs into a system-wide directory, instead placing them in the same directory as the executable itself. Therefore, assuming Crystal follows this convention, if Crystal is not in `%PATH%`, this temporary executable cannot locate the DLLs; even if Crystal is present in `%PATH%`, it might be preceded by other directories. The [default DLL search order](https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#search-order-for-unpackaged-apps) does not provide an easy way to intercept the search paths. With delayed loading, however, we can call `LoadLibrary` multiple times until one of them returns a valid handle, for example: ```crystal # NOTE: can't use stdlib or the c runtime here private def strlen(str) len = 0 while str.value != 0 len &+= 1 str += 1 end len end private def strcat(*args : *T) forall T buflen = 1 {% for i in 0...T.size %} %len{i} = strlen(args[{{ i }}]) buflen &+= %len{i} {% end %} buf = LibC.HeapAlloc(LibC.GetProcessHeap, LibC::HEAP_ZERO_MEMORY, buflen).as(UInt8*) ptr = buf {% for i in 0...T.size %} src = args[{{ i }}] while src.value != 0 ptr.value = src.value ptr += 1 src += 1 end {% end %} buf end private def load_library(dll) my_path = strcat("C:\\foo\\bar".to_unsafe, "\\".to_unsafe, dll) begin LibC.LoadLibraryExA(my_path, nil, LibC::LOAD_WITH_ALTERED_SEARCH_PATH) || LibC.LoadLibraryExA(dll, nil, 0) ensure LibC.HeapFree(LibC.GetProcessHeap, 0, my_path) end end fun __delayLoadHelper2(pidd : LibC::ImgDelayDescr*, ppfnIATEntry : LibC::FARPROC*) : LibC::FARPROC # ... if !hmod unless hmod = load_library(dli.szDll) # ... end end # ... end ``` where `C:\foo\bar` is our Crystal installation path, or some other arbitrary directory. From here we could make it configurable: ```crystal private def load_library(dll) {% if (paths = env("CRYSTAL_LIBRARY_RPATH")) && !paths.empty? %} {% for path, i in paths.split(";") %} my_path = strcat({{ path + "\\" }}.to_unsafe, dll) hmod = LibC.LoadLibraryExA(my_path, nil, 0x8) LibC.HeapFree(LibC.GetProcessHeap, 0, my_path) return hmod if hmod {% end %} {% end %} LibC.LoadLibraryExA(dll, nil, 0) end ``` Then `set CRYSTAL_LIBRARY_RPATH=C:\foo\bar` would set, at build time, the extra directory(ies) that would be searched first for dynamic libraries before the default order. If the name rings a bell, this is exactly the ELF `RPATH` attribute: (`RPATH` overrides `LD_LIBRARY_PATH`, `RUNPATH` doesn't and is less universally supported) ```crystal {% if (paths = env("CRYSTAL_LIBRARY_RPATH")) && !paths.empty? %} @[Link(ldflags: "-Wl,-rpath,#{paths}")] lib LibCrystalMain end {% end %} ``` This in turn suggests our custom implementation of `CRYSTAL_LIBRARY_RPATH` on Windows should be able to expand `$ORIGIN`. This is usually unnecessary because the executable's directory is already the first one with the default order, but it could technically allow things like `$ORIGIN\dll` so that the DLLs do not pollute `%PATH%` even if the executable itself is added. Naturally, a Crystal interpreter built with a custom `CRYSTAL_LIBRARY_RPATH` should be able to load libraries under `CRYSTAL_LIBRARY_RPATH` as well. This means `Crystal::Loader` should replicate this functionality too; on Unix, by adding those directories to `.default_search_paths`, and on MSVC, explicitly via `#open_library` similar to the delay load helper. Finally, displaying `CRYSTAL_LIBRARY_RPATH` in `crystal env` might be a good idea.

github.com/crystal-lang/crystal

Support `CRYSTAL_LIBRARY_RPATH` for adding dynamic library lookup paths

crystal-lang:master ← HertzDevil:feature/crystal-library-rpath

opened 01:27PM - 24 May 23 UTC

HertzDevil

+311 -23

Resolves #13490, except for the interpreter part. The `CRYSTAL_LIBRARY_RPATH`… environment variable can be used to pass a list of directories used by built programs to locate their dynamic libraries at run time. `$ORIGIN` and `${ORIGIN}` are expanded into the program's absolute path, and this PR adds a custom implementation for this on Windows, only available if the delay-load helper is present (i.e. `-Dno_win32_delay_load` is not used). Linux's loader also expands `$LIB` and `$PLATFORM`, although [this is not guaranteed](https://android.googlesource.com/platform/bionic/+/master/linker/linker_soinfo.cpp#250). The compiler will automatically add its _own_ RPATH to anything that needs to be compiled and run immediately as a child process. For Windows, this means as long as the compiler can find its own DLLs, `crystal run -Dpreview_dll` / `eval` / `spec` or any macro `run` inside `crystal build -Dpreview_dll` will always be able to locate the same DLLs distributed along the compiler itself, even if the compiler is not in `%PATH%`. In principle, if the compiler itself is dynamically linked with a `CRYSTAL_LIBRARY_RPATH` containing `$ORIGIN`, then the DLLs do not even have to share the same directory as the compiler. For most Unix-like systems, this automatically passes `-Wl,-rpath,...` to the linker. It seems linkers disagree on whether that option affects RPATH or RUNPATH. macOS is excluded because it handles library lookup differently. The compiler automatically generates the `Crystal::LIBRARY_RPATH` constant; when a Crystal source is run, this constant will reflect the contents of both the environment variable and the compiler itself, as described above. The standard library also defines it explicitly in case a compiler without this PR tries to use it.

Topic		Replies	Views
How to call external libs on windows preview? Help & Support	2	362	January 12, 2022
Compiling Crystal shared libary on Windows Help & Support	6	576	May 23, 2023
Loading .so files at runtime Help & Support	2	389	December 30, 2021
Upgrade SQLite3 binding version? Help & Support	6	514	November 26, 2021
Running plugins or other code Community	1	519	June 28, 2021

How do I call DLL functions from Crystal on Windows?

Related Topics