Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Supporting dynlib for dynamic loading #26

Open
NotoriousRebel opened this issue Aug 28, 2020 · 1 comment
Open

Feature Request: Supporting dynlib for dynamic loading #26

NotoriousRebel opened this issue Aug 28, 2020 · 1 comment

Comments

@NotoriousRebel
Copy link

Hello, I was wondering how hard it would be to support the dynlib pragma. I do a fair amount of development and that involves using the Windows API my favorite package is winim. For example with something such as OpenProcess we can see it is utilizing the dynlib pragma for dynamic loading via LoadLibraryA and GetProcAddress. If I wanted to use this with nlvm would the easiest way be to import dynlib instead and call loadlib and getsymaddr to invoke OpenProcess that way? I could copy kernel32.dll over to my setup with nlvm. However, that is not too feasible as there may be differences between the current Windows version I am using then running it on something such as Windows 7 or Windows 8.

P.S. This is an awesome project and is really useful for something I am working on.

@NotoriousRebel NotoriousRebel changed the title Feature Request: dynlib with dynamic loading Feature Request: Supporting dynlib with dynamic loading Aug 28, 2020
@NotoriousRebel NotoriousRebel changed the title Feature Request: Supporting dynlib with dynamic loading Feature Request: Supporting dynlib for dynamic loading Aug 28, 2020
@arnetheduck
Copy link
Owner

I'm not too sure, it's been a while since I did windows development so I don't quite remember how libraries are imported there - in general, nlvm probably doesn't work on windows, but on the other hand, the work to get there is probably very minor - windows generally uses a different integer size model so some minor adjustments might be needed here and there.

On unix, there's really very little advantage using dynlib and loading the symbols dynamically the way nim does it - you expose yourself to more hard-to-diagnose ABI issues and related tooling (debuggers etc) works worse. I imagine the situation is the same on windows, though I don't quite remember if linking there requires a .lib file for the dll or if the linker can do without it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants