dynamic libraries

First, "dynamic library" alone is not the right term, it should be "dynamically linked library"...

Dynamically linked libraries... hmm... this would only serve (the catch is below) large applications in which different libraries only used if certain conditions become true.... say a media player, instead of 6-8MB single binary we can have a small binary and a set of libraries with different sizes... also big games (currently we don't have any) can make use of it...

One another great future about dynamic libraries is they provide applications a plugin mechanism, curently we don't have such a mechanism. If ever implemented, this would be a killer feature...

But, yeah like everything on wii, we don't have an operating system. DLLs take the linking job from build process and put it onto the loader's (Operating system) responsibility... To do this loader should have a resident process... and currently we don't have any resident process while a homebrew application is executing... Yes, there is ios (or say mini) but I doubt it would suit the job...

Of course there are possibly lots of details about it regarding the toolchain and such... Possibly not too easy to implement in general...

As daniel_c_w noted, it can be implemented solely on a specific program, in it's simple form all the program should do is load a relocatable binary and arrange the parts in the main program that acceses it with the actual entrypoints from the loaded binary's metadata.

Quote
I.R.on
But, yeah like everything on wii, we don't have an operating system. DLLs take the linking job from build process and put it onto the loader's (Operating system) responsibility... To do this loader should have a resident process...

On Windows there are 2 ways:
-loading the libray at startup
-loading it at runtime

At startup: the loader load (duh :-) ) the .exe file and all required DLLs into memory and adjusts the jump pointers to point at the DLL functions.
Every linker should work, because the code that is patched by the loader comes in precompiled librarys (.lib)

Basicly this is the same as patching a programm.
A patch format for the HBC has been discussed, if I remeber correctly

I fail to see why a loader has to resident



At runtime: a program uses the Windows API functions (which are of course linked at startup) LoadLibrary and GetProcAddress to recieve a pointer to a afunction

Ok, so it is possible to load library at startup (it's what i need :)) if i've enough symbols in the package i want to load.
I know that the .elf contains these symbols, but does the .dol contain these symbols?

I will try to create a sample plugin application, i hope i will succeed :)

Thank you to all of you.



Edited 1 time(s). Last edit at 07/03/2009 10:04PM by arasium.

There is one other major use for loadtime loading, sharing common libraries. We got plenty of those.

Yes, but we link them staticly anyways.
The only good would be, that some patches in the librarys will also retroactively work in application, that were not recompiled.
On the other hand, we could create our own DLL hell :-)

As I.R.on said (well, wrote):

Quote

One another great future about dynamic libraries is they provide applications a plugin mechanism, curently we don't have such a mechanism. If ever implemented, this would be a killer feature...

Quote
daniel_c_w
I fail to see why a loader has to resident



At runtime: a program uses the Windows API functions (which are of course linked at startup) LoadLibrary and GetProcAddress to recieve a pointer to a afunction

Well you gave the answer actually, program calles the windows API functions, which should be under a separate process's address space (maybe not)... but to make it standard and configurable across all applications (like configuring the path&device for shared libraries) this functionality should not be statically linked into the application itself.

All this of course related to loading the libraries at runtime... loading at startup will not have all the benefits... the only real benefit will be as henke_37 pointed out, sharing & updating common libraries...

Quote
I.R.on
Well you gave the answer actually, program calles the windows API functions, which should be under a separate process's address space (maybe not)

Definitly not. All functions you can call have a working adress in the applications virtual adress space.

But that is under Windows / x86.

On the Wii, memory is adressed directly, and so far all applications can assume, they have the whole Wii (sans IOS) for themself.

Anyway, the ability to load librarys at runtime needs to be part of the application itself (staticly)

Quote
I.R.on
(like configuring the path&device for shared libraries) this functionality should not be statically linked into the application itself

That are design choices, that still have to be made... :-D

Wanna start a draft?