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

[MiNT] Shared Libraries



Hi,

in an attempt to make some usage of the work that I invested last year to
implement MagiC-6 style Shared Libraries under plain TOS -- see

	http://www.muenster.de/~reschke/soft_e.html#slbload

-- I am releasing a new version my Mupfel tool collection which actually
uses
this shared library mechanism:

	http://www.muenster.de/~reschke/soft_e.html#mupftool

Shared libraries have been discussed here before, and I sure agree that what
MagiC 6 implements is not completely satisfactory, but:

	i) it's there and it works and
	ii) it doesn't require special compiler features.

In my sample application, I have moved big parts of the Pure C standard
library and some of my own code into the shared library, using stubs and
callbacks to care about the common problems like "malloc()" or "errno". With
Pure C, where there is no source available for the standard libraries, this
is basically all that can be done, and I think the result was worth it
(average executable size reduction of 50%).

I would assume that much more could be achieved with a special version of
the
MiNT libs -- for example, two different versions could be made based on a
compile time switch, where only one of them would have the full code needed
for plain TOS compatibility (like Dopendir() emulation for opendir() and so
on). I would think that part of the lacking acceptance of the MiNT lib under
Pure C users is caused by the significant size increase of binaries -- this
could also be fixed by using a shared library... not speaking of easier
maintenance of existing executables by simple SLB updates.

The (standard C) source for the SLB loader for MetaDOS is available from the
aforementioned URL; the archive also contains manual pages and sample
libraries. I currently don't have the necessary time and setup to bring
Slbload() to MiNT, but I doubt that it would be much work -- mechanisms for
multiple owners of memory blocks incl. reference counters are already in
place.

I hope I have generated some interest,

Julian
--
Julian Reschke
MedicalData Service GmbH (http://www.medicaldataservice.de)