[MiNT] Mintlib 55 (old mail)

["Konrad M. Kokoszkiewicz" <draco@obta.uw.edu.pl>]

Hello,

this was supposed to be sent before vacations, however, i didn't have
time... sorry for the delay, Guido.

Hi,

> > Sorry, my mistake: I meant S_IFSOCK... and also sys/types.h seems to
> 
> S_IFSOCK was introduced only this month, it didn't vanish, it's new
> altogether.  Anyway, the same cure helps, use -D_BSD_SOURCE.

The file (sys/stat.h) is dated 5 May (4317 bytes) and it definitely
doesn't define S_IFSOCK anywhere. But okay, I didn't look for an upgrade
recently.
 
> > define ushort and ulong, but doesn't define uchar, which is a bit
> 
> ushort and ulong are only in sys/types.h for backwards compatibility.  Is
> there any sys/types.h that also defines uchar?  Why don't you simply use
> "unsigned char"?  

Because, which is easy to notice, the 'unsigned char' is 13 characters to
type, while 'uchar' is only 5. And I can't understand why I have to
separately #define uchar in each program, while ushort and ulong are
defined by the library. This seems inconsequent.
 
> But for compatibility you should provide your own macros anyway, like
> 
> #include <mintbind.h>
> #ifndef Slbopen
> # define Slbopen(foo, bar, baz) trap_such_and_such(opcode, ...)
> #endif

The original mintbind.h didn't provide an appropriate 'trap_such_and_such'
for Slbopen().

> > > The reason for that annoying size problem is simple to find and hard to
> > > solve.  The startup code contains a lot of library references and drags a
> > > lot of seemingly unused modules into the link.  In "normal" applications
> > 
> > Well, I can't imagine why the startup code, which basically has to shrink
> > the mem and parse the commandline, and this is rather simple task, has to
> > use a lot of library references and finally become 40k in size.
> 
> You forgot a lot of things like establishing a new stack, repairing
> ill-designed command lines, checking for being called as an accessory,
> fixing up the environment, ...  Theses tasks are all very Atari specific.

Nope, I didn't forget that. Actually, establishing a new stack is a very
simple task (few instructions) and is done iunctim with a call to
Mshrink(). The same for checking for being called as accessory (this must
be checked before shrinking the memory, because accessories don't want
their memory to be shrunk). Even counting tasks like repairing wrong
command lines (who said I want to support an OS which can't even construct
a command line?) and fixing up the environment (??) you still hasn't
convinced me that all this needs 40 kilobytes. I would say at most 8k (too
big anyways) is needed here. You know, the 40k startup code is even longer
than some operating systems.

I can imagine a startup module (I can send it on request) which does most
of the 'Atari specific' initializations you mention in something like 300
bytes of code. 
 
> But crt0.o is really harmless regarding size.  The first candidate to omit
> would be crtinit.o.  To do this, you have to provide your own function
> _crtinit().  But crtinit.o is also relatively cheap.  To gain something
> you will have to provide your own version of _main() thus preventing
> main.o being dragged into the link.  But you have to be very careful with
> that.  A tiny little mistake can prevent things from working.  If you are
> lucky you will have only link-time errors to fix (possibly unresolved
> references) but most of the time your software will simply not work
> because the library hasn't been properly initialized (happy debugging).

If I don't want to use library functions, this is not a problem. I only
wonder, what unresolved references (and why) the linker can complain on,
when (if) I omit the entire lib.
 
> > because it emulates MiNT features on TOS and MagiC. My question is, why a
> 
> The effect is probably not that dramatical but still significant and of
> course a nuisance.  I follow two strategies in parallel here: I try to
> concentrate the critical stuff and I (will) try to embed emulations for
> old systems into "#ifndef FOR_MINT_ONLY" or some other preprocessor macro.  
> You will not find that in the current version, right now I rather try to
> organize the code in a way that makes it easy to do that in the future.

That sounds ok. I would really appreciate such a 'MiNT version of MiNT
library'.
 
> I personally don't care whether MiNTLib linked binaries run under Magic or
> not.  But there are a lot of people out there that will stone me as soon
> as I drop TOS/Magic compatibility as a main goal of the MiNTLib.

Perhaps there are also some people out there, who would put flowers on
your grave, after you had been stoned, for the same reason. ;)
 
> > And even if tossers and magicers would use mint library for something, I
> > still don't uderstand why my init (which is resident in the memory all the
> > time the system is up) has to contain code that emulates
> > e.g. vfork() under TOS...
> 
> Patch your init daemon to use a modified version of vfork() that does not
> emulate the call.  Or convince TOS/Magic users that they shouldn't cry
> when their binaries crash or exit when Pvfork() is not available (there
> are also other programs that use vfork).

You didn't understand. The suggestion was, that programs which are
resident in the memory (init, syslogd) or often present in the memory,
sometimes in more than one copy (getty, shells), should be linked with a
version of the library which does not contain emulations. This way,
perhaps, MiNT would become usable again on a 4MB machine. I also think,
that linking entire /bin this way would make MiNT distributions much more
compact.

I think, if such a MiNT lib version would be available, I could even
forgive the 40k-long startup code :-))
 
> Really, Konrad, I understand you and I try my best to avoid the nuisances
> you complain about.  But the MiNTLib (like every libc) is really complex
> and I may overlook things and sometimes you simply have to surrender when
> you have to decide between small but buggy and huge but correct
> code.  Sure, the old printf was somewhat smaller than the new one.  Same
> for stdio in general.  But a lot of stuff either didn't work at all
> because of that or it worked unreliably or uncorrectly.  What should I
> do in these cases? Accept the bugs and ignore bug reports?

Well, no. I appreciate the existence of the MiNT Lib in general, and your
work on it in particular. It really makes easy to write a quick program.
But something else is to have a possibility of taking an advantage of
something, and something else is to be forced to take the advantage any
time, you see.

You wrote a lot about how the library works and that a lot of
initializations must be done in case someone will use a function. Wouldn't
it be better that a first call to a function performs its initialization?
This would save something, I guess, if one does not use the function in
question, no?
 
Gtx,

--
Konrad M.Kokoszkiewicz
mail: draco@atari.org
http://draco.atari.org

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospolstwa, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.