RE: [MiNT] XaAES / GEM memory issues

[Noah silva <nsilva@sparcy.atariuniverse.com>]

On Tue, 9 Jan 2001 Jo-Even.Skarstein@vital.no wrote:

> > -----Original Message-----
> > From:	Martin-Éric Racine [SMTP:q-funk@pp.fishpool.fi]
> > Sent:	Tuesday, January 09, 2001 2:48 PM
> > To:	MiNT List
> > Subject:	RE: [MiNT] XaAES / GEM memory issues
> > 
> > > There's no reason *not* to implement basic GUI-stuff in the
> > > kernel, 
> > 
> > That shows you clearly do not understand the principle of what a
> > kernel is in the composition of an OS.
> > 
> Really? Could you elaborate please?

I think there is no such strict definition of kernal!  It's just a
different Idea to include the VDI or not.  GEM was shipped on the Atari
with AES running and pretty much intermingled with the system.  The Mac OS
is even more so (there are no text mode error messages, etc).  I can name
a number of PDA systems, etc. that have a GUI at a very low level.  If you
can have CD-rom drivers, etc. as part of the kernal (or a module), the GUI
stuff is not so far fetched.  What's more, mint is hardly a microkernal.
(though maybe it should run overtop of one, that would open some
possibilities).

 
> > > Besides, "basic GUI stuff" already exists in the TOS roms; there
> > is no need to reinvent the wheel.
> > 
> You obviously didn't get my point: I'm not suggesting a complete GUI inside
> the kernel, but that some basic elements common to most GUIs should be
> offered as a service by the kernel. This would allow almost any GUI to be
> implemented on top of the kernel, and even use different GUIs simultanously.

That, and We should get away from the TOS roms.  MiNT is not really an
"operating system" as long as it depends on the ROMs.  (and none of the
rom stuff is reentrant, afaik).  It would be nice to see a mint usable on
at least other 68k machines, including new atari clones, without having to
fake out the rom from 1986.

> 
> It could also run as an ordinary server in user space, but this wouldn't be
> nearly as efficient. In other operating systems this would make more sense,
> in some cases even file systems and hardware drivers runs outside the kernel
> too. But while this may be possible with MiNT, it wouldn't be particularly
> efficient. MiNT is not designed to work like this, this is why MiNT-Net, all
> filesystems, device drivers and actually every possible service offered by
> the program "mint.prg" and it's various add-ons (currently XDDs and XFS's,
> in the future it can be a lot more if Frank implements the kernel module
> interface he has been talking about) runs inside the kernel.

I tend to agree here.  I noticed something.  Windows programs look like
this:

begin
 if init_windows then
  begin
   main_loop;
   shutdown_windows
  end
 else
  writeln('This program needs windows to run!');
end.

Hmm, somehow OS/2 programs give a similar message about needing the
presentation manager.  X programs give a "cannot open display" message.
Mac programs have no such else at the end, and neither do GEM programs for
atari.  Try to run most of them without the AES, and they just exit with
no error.  (well, my GEM programs actually print a message).  Why? because
GEM is -always- expected to be loaded.  To me, that shows that it is as
much a part of our OS as GEMDOS.

 > 
> It seems like you equal "kernel" with "DOS" - a very narrow definition if
> you ask me...
> 
> The AES/VDI in TOS is not suitable for reuse for many reason:
> 
> 1. It has no defined API besides the traps which are unusable for the
> purpose I suggested.
> 2. It's not multitasking friendly, as it use busy waiting in numerous
> places.
> 3. It's not MP friendly.
> 4. It's not expandable.
> 5. It's outdated, and because of (4) it always will be.
> 6. It can't be modified because of copyright issues.

Well, a number of clones use modified TOS roms.
> etc...
> 
> You get the point. Otherwise you wouldn't be using N.AES today.
> 
> Jo Even Skarstein
> 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> 
> This email with attachments is solely for the use of the individual or
> entity to whom it is addressed. Please also be aware that
> Vital Insurance/DnB Group cannot accept any payment orders or other
> legally binding correspondance with customers as a part of an email.
> 
> This email message has been virus checked by the virus programs used
> in the Vital Insurance/DnB Group.
> 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> 
>