Re: [Oslib-devel] Outsourcing the extender?

[Peter W. <pet...@ly...>]

Somewhere on the net is a document "Why Replyto-munging is harmful". From
that document I conclude that my way of thinking ("I reply to the list") is
definitely wrong! Because ReplyToAll is an official "protocol". (Probably SF
will enforce that policy and hence change list settings unasked.)
--------------------

When I had all this hassle, wondering if my mail went through anyway (I use
old Netscape 4 Messenger on Linux), I rethought about it. Now I think I'm
going to write a completely new, DPMI based loader. Then I can see if
there's a more powerful solution for the between-modes interface. If it
works as I imagine, it will be both simple and powerful.

Now my reccomendations for OSLib modularization would go into a rather
different direction:
- Move all from ll, libcons and libm to one of the three lib levels.
- Put all xlib functionality in x0.o.
- Either a) give a i386 subdir to all libs or b) use no i386 subdir at all.
(a) would mean a widely used mechanism, good for portability.
(b) would mean: "OSLib can never be ported because the booting mechanisms
are too different on other architectures. So let's write pure i386 code!"
Both soultions seem good to me, but not an inconsitent i386 port as it seems
now to me.

Probably these suggestions sound again much better in my ears than in yours,
knowing the OSLib code better than me.

---------------------------
Having already brought in the design and aim question above, I think the
open question from kl/oq.txt is somehow related to that issue.

The application writers have other methods at hand for doing low level
stuff; and OS designers try to put a control layer between the application
code and the hardware.

On the other hand, besides from OSLib the kernel writer has nearly no free
kernel library that takes the assembler burden off him.

Conclusion: I personally think, that OSLib should be optimized for kernel
developers, not for application developers. 

Kind regards
Peter Wiehe