Re: [MiNT] LDG vs. SLB vs. custom OVL-thingies

[Paul Wratt <paul.wratt@gmail.com>]

On Tue, Feb 2, 2010 at 3:30 PM, OL <o.l@lutece.net> wrote:
> Peter Persson a écrit :
>>
>> Hi,
>>
>> What are the pro's and cons of LDGs, SLBs and custom overlays (as used by
>> Highwire, CAB, aICQ and others).
>>
>> My personal impressions:
>>  - SLB's are supported by the OS (MagiC, FreeMiNT and TOS w. BetaDOS) -
>> yet noone seems to want to use them nowadays.
>>  - LDG's are not supported by the OS (in fact it seems most apps that use
>> them will crash if memory protection is enabled??)
>>
>
> LDG work in protected mode except official ldg.prg that is not perfectly
> compatible with memory protected (I have a version working somewhere on my
> old computer I have to find it)
>
> LDG have self include documentation if programmer think to use it. LDG are
> simple software and can be launch as simple software if need, this usefull
> for debug and tests by programmers.
>
> LDG softwares can run anywhere even if nothing is installed even on TOS 1.x
>
>>  - Custom OVLs - I have some personal experience with them since writing
>> the GIFOVL to AtarICQ. It seems to work, but it makes me feel dirty inside.
>>
>> So, are people using LDGs in favour of SLB? If this is the case, would it
>> be beneficial to have support for this in the OS?
>> And the LDG + memory protection issue - why is this?
>>
>
> For this job there is alway's a good reason to add to system, this is memory
> management, simple application have no sure way to lock a memory bloc if a
> software allocate a memory bloc and crash there is no way to forbid
> destruction by the system, even Mint SHM not lock memory (I don't remember
> if Mint share the memory or do a copy, I think it share it).
> This is a real big problem to share memory to be able lock we should do a
> server, if it crash or kill all applications using libs will crash.
>
> Regards
>
> Olivier
>>
>> best regards
>>
>> -- PeP
>>
instead of the server, what about the memory protection used by old
ICL mainframes. It is very simple, and if app crashes, OS does not

The server idea means more overhead, something which is a current
problem for low spec machine.

We need a low spec solution, but done in such a way that a server
could also be implemented as a replacement, or for use avarage+ spec
machines

when this round of kernel updates is complete (do we have point
release date yet??? it is getting urgent) then, with the new mint web
site as the spearhead, all things kernel need to be "layouted on
paper", the kernel modules especially need expanding to function
properly

The KM should be used by more os plugins, even to the point of cutting
chunks of the kernel of into KM's. The VMM should be a KM, and the
garbage collector also, that they can be updated or changed or even
left out as the situation requires..

There is not one answer, there is always a better way to do things,
but history in general should tell you not to abandon stuff just
because it is not being used or no one know how to use it

LDG is the most up to date of shared library types, SLB is the most
mature, OVL are somewhere in between (and unless they have a common
API) used for specific tasks for specific applications.

The documentation for all these just needs to be consolidated and made
available in at least one (if not 2 or more) central locations, as LDG
currently is

even though they are technically completely different, combined with
the now lost -mbasrel, a solid kernel based shared library system
would be a breeze to construct (on paper first), if you could get side
by side comparisions, and explanations for different approaches, even
non techies could put it together..

I have tried to push the point across about centralized documentation,
interlinked to common reference material. I do not mean all docs need
to be on on server, they just happen to be atm, which helps, but
centralized in a web sort of way

there should be three of more places around the net to get ALL the
requirements for project development, you should not have to run
around for six months not know who to get what from where, which is
the case, especially if your are new to the platform.

I am talk a generic level of project documentations, interlinked docs
and libs, also available for offline use (so they need to be available
in one place somewhere, even in a ZIP)

The Generic part is that all the shared libraries mentioned here are
documented for the MiNT kernel development, which also has other
kernel and GNU/posix stuff

Then there is MiNT the OS, which is everything apps wise for for mint
(as the current CVS shows), which does not need Kernel specific stuff,
except in kernel system calls, but does need the LDG/SLB/OVL stuff
also

To see the reality of this, in updating the HighWire web site, I am
trying to iuntroduce exactly the above concept, but the generic part
is Web Broswer related, which cover an area greater than Kernel and OS
apps put together, simply because of its multitude of uses, protocols,
and implimentation. It too needs LDG/SLB/OVL, and it will cover
Draconis, Links, all TCP/IP stacks, and engine ports

The next one, related to both MiNT OS apps and Web Browser at a
generic level, but still seperate, as the Graphics one, covering
nfjpg.prg, dspjpeg,  Smurf, Rembrant, and the plethora of open source
graphics convertor and apps, all of which need LDG/SLB/OVL stuff also,
as well as linux/gnu/win image libraries, etc

There is currently no open source Resource creators, anoth whole
field, one that is in sore need of expansion due to the nature of
modern dev repos, plus and enhancement to AES (and XaAES), to that has
to cover AES & VDI stuff as well as LDG/SLB/OVL stuff

Then there are the ones no one has got to yet, filesystem drivers,
especially Fuse (and similar), which allow a FS to be created and
accessible for just about anything you can think of, including the
mising or lacking parts used to deal with kernel/posix details

I hope that people can see a pattern here, full documentation for
developers, required libraries, all available on one web server per
generic project targets, even if it is actually multiple sites (like
Windom + LDG).

The things that are the same DO need to be available per server, as I
have seen an inordinate amount of links on still viable project sites,
let down because the require libraries are a dead link (???)

I am not talking about huge projects here, just consolidating the
information around central points, that cover a specific area, in such
a way that if everything turned pear shaped tomorrow on the current
server (or access to it), both and new devs, as well as "paper devs",
could start up with everything they need to get up to speed, and
current devs could keep going as if it were a pothole, as opposed to a
roadblock

More is better, but only if you can find it, use it, fix it. _one_ is
not the answer, because every one of us has different needs, likes and
ways of doing stuff, this is the one thing all Atarians share, so why
not let 20 different people doing 20 different projects taking 20
different approaches, get around the same table

Paul