LoadLibraryA Incbin

BlitzMax Forums/BlitzMax Programming/LoadLibraryA Incbin

Hezkore(Posted 2016) [#1]
I'm using LoadLibraryA to load a DLL.
I can include the DLL in the executable with Incbin, but loading it with LoadLibraryA doesn't seem to work.
For now I've done so that if the DLL isn't found in the application directory it writes it (via incbin) and then I load it normally with LoadLibraryA.
But that's really not optimal and I'd like to load it via incbin instead.
Is that possible?


Brucey(Posted 2016) [#2]
You don't like DLLs in your application dir?


Hezkore(Posted 2016) [#3]
I certainly do not Brucey, I certainly do not.
Plus, writing it like that isn't a good idea, appdata folder is the only safe place to write to on Windows.


grable(Posted 2016) [#4]
You would have to basically write your own version of LoadLibrary, parsing the dll headers and all that.
Thankfully someone else has already done so: https://github.com/fancycode/MemoryModule


Hezkore(Posted 2016) [#5]
Heh, funny how it describes exactly my issue.
Sadly I don't know anything about CPP, so I have no idea how to use it.
Thanks for the find though!


grable(Posted 2016) [#6]
Its just C, with a similar api to LoadLibrary and friends.
Import the C file and define the functions you need in an extern block.

EDIT: Something like this
Import "MemoryModule.c"

Extern "C"
	Type TMemoryModule
	EndType
	
	Function MemoryLoadLibrary:TMemoryModule( p:Byte ptr, sz:Int)
	Function MemoryGetProcAddress:Byte Ptr( m:TMemoryModule, name$z)
	Function MemoryFreeLibrary( m:TMemoryModule)
EndExtern

Function IncBinLoadLibrary:TMemoryModule( url:String)
	Return MemoryLoadLibrary( IncBinPtr(url), IncBinLen(url))
EndFunction



Hezkore(Posted 2016) [#7]
Thanks for helping grable, but I just get a bunch of errors I don't understand.


dw817(Posted 2016) [#8]
Hekzore, could you please post the code you are using (in toto) to load your DLL. Maybe I can figure it out.


grable(Posted 2016) [#9]
Maybe he doesnt have mingw?

I had to tweak it a little bit for it to load dlls made with blitzmax, but other then that it should compile without errors.
Took me a while as i had forgotten to add -m32 to makelib in bmk after switching over to 64 bit version of gcc ;)

Heres a precompiled module with test binaries: grb.memorymodule.7z
Extract it to your mod dir and check the test dir.


Hezkore(Posted 2016) [#10]
@grable
Hmm I do have MinGW.
I've compiled a few other modules without any issues.
I am however using vanilla BMX, not NG... if that has anything to do with it.
Thanks for the precompiled module, I'll give it a go later and report back!

@dw817
It's for the Scintilla example found here - https://code.google.com/archive/p/scintillabmx/downloads


dw817(Posted 2016) [#11]
Hi Hekzore:

Not to be a swift person or anything, but the download I have from the link you gave includes the source-code to the DLL library. You don't need the DLL. You can just copy the source to your own program and use it this way. Right ?


Hezkore(Posted 2016) [#12]
If you can get that working dw817, that would be awesome.
Cause all I know is that when I download that 2010 version and run the example, the DLL has to be in the same folder or the scintilla text area doesn't show up.


dw817(Posted 2016) [#13]
Before I can do that, I think I will need someone to explain to me how to convert an *.bmx to a *.dll.

With that knowledge, I should be able to reverse engineer and decipher how to make it just a function in your code, Hekzore.


kfprimm(Posted 2016) [#14]
http://lmgtfy.com/?q=Blitzmax+build+dll

Here you are.


dw817(Posted 2016) [#15]
Kfprimm, I want to hear the answer from a current active member in this thread. You did think of that, right ? And please don't post links that are not within the frame of BlitzMAX's own URLs unless they are download links.

I have no idea where that link goes and I don't plan to click it.


kfprimm(Posted 2016) [#16]
https://www.google.com/search?q=blitzmax+build+dll

https://www.google.com/search?q=lmgtfy.com

Google is a very useful tool for many inquiries. Particularly when you're looking for programming help. You can even use it to checkout strange looking URLs.


dw817(Posted 2016) [#17]
You are still using something in your link called Imgtfy, Kfprimm. Sounds like a virus site to me. If you want to point to a link inside "\blitzbasic.com\" I will certainly look at it then.


kfprimm(Posted 2016) [#18]
Look, I think you're (intentionally) being a bit ridiculous about the links. Those are clearly two Google links.

You have been filling the forums with posts asking questions that have been answered many times over already. Of course, that isn't necessarily a wrong thing to do. Often, existing resources may be too specific or too vague and everyone process information differently.

However, your attitude/approach is clearly different. You don't say, "Hey guys, I found XYZ post, but I don't quite understand this bit...".

Rather, you say, "Everybody, show me how to do this!" and then you repeatedly expect people to provide you with complete, functional programs in lieu of (perfectly reasonable) code snippets.

So, again, here is a link that will provide you with a nice list of potential resources. I've even humored you and included a filter in the search to show only blitzbasic.com pages.

https://www.google.com/#q=site:blitzbasic.com+build+dll+blitzmax

If you can't 'trust' a google search link, then I don't know what to tell you.


dw817(Posted 2016) [#19]
No, this link looks alright. I will check it out. I appreciate your help on this information, Kfprimm.

And no, usually I don't say "I don't understand" because then I get answers that are over my head. And I mean that in an intellectual way. There's quite a bit about programming you guys do that I don't understand.

And even with source examples, it's still difficult to understand. :)

However, sometimes I do post a few things that you guys find of interest - so, we're both learning. :)


col(Posted 2016) [#20]
Hi Hezkore,

Chiming in late and I've not read all of the posts...


For now I've done so that if the DLL isn't found in the application directory it writes it (via incbin) and then I load it normally with LoadLibraryA.


Can I ask why you don't just distribute the dll with your app? Its easy to put it in the same folder as your application during installation, leave it there and then load it during runtime. Having the dll kept inside your app folder is going to save you a whole ton of headache as you then already have an existing working solution. The whole of the windows OS is made of thousands of dlls, but I guess you have a reason and I'm curious as to why you don't like that approach?

I do see a little contradiction in your request.
The purpose of a dll file is that it is an external ( external from the main exe ) library file containing all of the cool library functions and features. A dll is designed so to be loaded/unloaded at runtime from a file system. They are called 'Dynamically Link Library' so that they can be 'dynamically' loaded and unloaded at anytime during code execution. The main reason projects use them is that dll files can contain self contained specific functionality to do a task, and if there is a bug found then just the dll needs to be updated as opposed to a whole new .exe being compiled and distributed.

I guess you could argue that if you have to issue a new dll file then why not just issue a new .exe? Another reason for using a dll is to allow it to be used by lots of different programs. If your app is using your own custom dll that you made that no one is going to use then I'd question why are you using a dll at all? Dlls are there to have a single file that offers specific functionality, and for it be used by possibly 10s, 100s or even 1000s of different programs. Imagine if there wasn't some kind of dll system, then all programs would 'copy/paste' the functions into their main code, so what? you may ask... Well now imagine then that a bug is found in a function... now EVERY single program that uses that code needs to recompiled and redistributed with a fixed version of the function.
Using a dll means that the main exe doesn't need to be recompiled at all and only the dll needs to swapped out for the newer version for all of those programs to have the bug fixed, and there's no need for anyone to recompile anything else, just simply swap out the dll and voila - the bug is gone from potentially hundreds of programs, including programs that you may have installed that are using your dll and written by someone else.

Anyway,
It sounds like what you want to do is not to take advantage of the purposes for a dll and go the route of including code directly into your main app. While there's absolutely nothing wrong with that, weeeellll... you do lose the advantage described above. So if you want to then this can be done just as easily and there are separate library files that allow you to do exactly that. These library files are called 'static link library' files, due to them being statically linked and included in the final executable during compilation. There is no way that you 'unload' or swap a statically linked library in the same way as a dll can be. So if there is an updated static link library that comes out then you'll need to recompile like I said before.

As BlitzMax uses gcc as a part of its compilation toolset then you'll need a gcc compatible 'lib<libraryname>.a' 'static link library' archive file. If you have that then you can link that library directly into your BlitzMax code using the 'Import' command and then use the Extern / EndExtern to expose those cool functions that you need.
Or.... or if the author of the dll has been kind enough to open source it then it *may* be possible to include the source directly. This may be unlikely and greatly depends on the source code itself, how it was written, the language it was written in, what compilers it was written to be compatible with etc. This would be considered as a last resort. Hopefully there is going to be an already existing solution. As a VERY last resort, and providing the source is available and providing the source license allows it, then you *may* be possible to port it BlitzMax - as I say though... an extremely last resort.

EDIT]So to help with finding a robust solution... first off, what is the name of the dll in question? Sometimes the author of the dll already has the lib.a file already available? But at this time we don't know the name of the dll?[/EDIT]
I see it's the scintilla dll that you want to use, and the .lib file is available from their website.

I'd advise you to stay away from any 'tricks' which involve loading the dll into virtual memory, and then trying to hack away with learning the pe format, brrr definitely no thanks, especially if there are compatible files available. Well actually I'd probably do that just for the fun of it ;-) , but... if there's an easier simple way to do something then I'd advise to do that first - you do have an existing working solution - just it seems not to be your preference.


Hezkore(Posted 2016) [#21]
The application I'm making is a very tiny app (Quake 3 Shader Editor)
I just don't want it to be anything more than a single EXE file.
I know what a DLL is and all, but I'm not that good with C or C++.
I'm using the example that comes with the Scintilla import and that one uses a DLL, and as I said above, I'm not that good with anything else than BMax so it's not like I'll be able to manually wrap things differently from the scintilla source or figure out which version of scintilla the example uses and grab the correct files from the scintilla website and fix it myself.
So I'm pretty much stuck with the DLL the example uses.
The module grable posted does work, it allows me to incbin the DLL and then load it.
That's what I'll use until anyone can help me some other way. :)