[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [MiNT] MiNTLib 0.51



> > Speaking of other solutions: it seems to me that all this could
> be avoided
> > if we had MagiC style shared libraries under MiNT, and if MiNT
> lib would be
> > implemented as shared library.
>
> Nope, see below.
>
> > In which case "open()" would just be a proxy, and you would
> dynamically link
> > either mintlib.slb or a ZLIB-enabled replacement...
>
> And how do you want to get the address of the "real" open function?  You
> either need syscall() or some other way to access the internal library
> implementation.  See the sources for the zlibc, even for shared libs you
> still need some mechanism like this.
>
> The problem is that the reference to "open" would get resolved within the
> shared library and so you need another name for the library function.

a) You could habe a zlib-enhanced version of libc which would have zlib
directly built in. This would be a compatible replacement of a libc.slb, and
users could decide during setup which one to install.

b) It also might be possible to hook zlib.slb "between" the program and the
original "libc.slb", I'll have to check how this could be done...