Re: [MiNT] Re[3]: usage of wind_calc()

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Wed, 2005-07-13 at 21:11 +0000, Odd Skancke wrote:
>  Or maybe discuss how to best implement WCOWORK in both AES's? Up to now
> the only thing I've heard is that because of a library, WCOWORK is no
> good. And up to now the design of this library sounds horrific. To me it
> sounds like the design is so bad its very hard to support new things
> like WCOWORK.

I have a vision on how this sort of thing should work.  If anyone is
interested email me privately as its quite a long topic and quite
different from the direction the industry as a whole is moving to.

>  Perhaps not visible to the end user, but then again, Windows does not
> provide anything important over Linux either, if this is your point of
> view. But we both know that Linux is a better design.

Hmm .. bad example.  Windows has better load times and a unified GUI.
When you look at how much memory a typical Gnome system uses (more than
XP) and the relatively poor multimedia efficiency, its unclear which is
a better user experience.  How fast does MS-Word load compared to
OpenOffice?  I can tell you that the number bugs in MS-Word may be
outrageous, but OpenOffice has more to the point where some documents
are downright frustrating to create on top of the outrageous load times.

On the kernel end, file structure, and library design (.so vs .dll) then
yes, Linux is a better design.

>  Together with XaAES, MiNT actually offers very good memory protection,
> not perfect, but very good. There are still problems with some (if not
> all) VDI's, and once that is implemented in a decent way, at least we
> have a secure Memory Protection scheme. I did a lot of work on just
> that. The wdialog extentions even works without being too big a security
> holes. Its designs like that we just have to avoid.

Memory protection needs to be more transparent.  The idea that you have
to turn on or off various flags for every application and for various
"protocols" to work is just silly.  A real virtual address space needs
to be the next step, and after that, we can fix fork.  Virtual memory
and things of that sort may be nice but aren't as necessary for most
Atari apps that use relatively little memory anyway.

Speaking of VDI - a real driver API would be nice too - something
forward thinking that doesn't leave out the possibility of OpenGL.

-- Evan