LoadLibrary() remplacement

Started by
14 comments, last by Yann L 15 years, 4 months ago
Why not compile the obj files into dlls, and load them using LoadLibrary? Is there too much overhead (how much are we talking about?), or is there some other problem?
Advertisement
Quote:Original post by mzeo77
Why not compile the obj files into dlls, and load them using LoadLibrary? Is there too much overhead (how much are we talking about?), or is there some other problem?


Like I previously said, I want to port my engine onto consoles. Let's take the Nintendo DS for example: there is no LoadLibrary()-like functions and since there's not much memory (4 MB), I want to optimize memory utilization by loading only what is necessary. By doing this on Windows, I can learn how I can implement a LoadLibrary()-like function on consoles.
Quote:Original post by Deathscythe_HC
By doing this on Windows, I can learn how I can implement a LoadLibrary()-like function on consoles.

That won't help you very much then, I'm afraid. Loading and mapping executable code is going to be completely different on every platform. It's already a totally different thing on Windows versus Linux, and yet both systems use the same hardware (CPU, MMU, etc). I don't know much about the DS, but I somehow doubt it uses virtual address translation, page faults, rebasing, PE headers, etc.

There is hardly a more platform specific thing than executable code loading.
Quote:Original post by Yann L
That won't help you very much then, I'm afraid. Loading and mapping executable code is going to be completely different on every platform. It's already a totally different thing on Windows versus Linux, and yet both systems use the same hardware (CPU, MMU, etc). I don't know much about the DS, but I somehow doubt it uses virtual address translation, page faults, rebasing, PE headers, etc.

There is hardly a more platform specific thing than executable code loading.


On the DS, it will be easier to implement this functionality because there is no virtual memory: you have to manage yourself the memory because the DS OS offers a basic memory management API. And ARM asm is way easier than x86...

And when compiling the AI for the DS, the file will not be in COFF/PE format, it will be an ELF *.o file. But still, relocations will need to be resolved and the different code sections will need to be loaded in the same fashion.
hate to tell you this but i think scripting is your best bet.
For the over head thats a bit pushing it. You can do a small scripting engine to take care of this and sense you know its memory dependant might as well add all the code to minimize this.

Like Yann said there is not a simple solution that works with all here. It makes sense cause other than the platforms software differences you might have hardware differences too.

The way i see it is that you want dynamic loading on every platform but scripting is better suited for this
Bring more Pain
Quote:Original post by Deathscythe_HC
On the DS, it will be easier to implement this functionality because there is no virtual memory: you have to manage yourself the memory because the DS OS offers a basic memory management API. And ARM asm is way easier than x86...

As I suspected, it is entirely different from Windows. When mapping executable code into a process under Windows, you'll have to deal with tons of stuff that doesn't even exist on the DS. And on other platforms, it's different yet again.

Honestly, I don't really see where you are trying to go with this. If you need dynamic linking on the DS, well, then implement it on the DS. If you're under Windows, then use the facilities that are already available to you - ie. use LoadLibrary. It really doesn't make any sense to reimplement an already available feature, when your goal is to eventually do it on an entirely different platform anyway. You'll just be wasting your time.

And you should definitely also consider scripting.

This topic is closed to new replies.

Advertisement