[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] WCOWORK operating mode



On Thu, 2005-07-14 at 21:55 +0200, Peter Slegg wrote:
> 1. if a key app that I currently use doesn't work

This one is rough as its almost always the fault of the application.  I
used to hate GFA Basic because older versions of it seemed to blatantly
ignore the rules, and the users of it generally hadn't read any of the
OS documentation - so if it worked on their 520ST, they didn't care much
about anything else.

For example, making AES calls before appl_init() is called seems to be
common.  Its always been documented that appl_init() be the first AES
call you make, but since it worked on older AES systems, people did it
anyways.  Its surprising how many badly written applications there are,
but from what I've seen, MiNT/XaAES does try to recognize some of these
and provide work-arounds.  As these problems with specific apps are
reported, more work-arounds for those apps will likely be implemented.

The second issue is memory protection.  Without memory protection an
application that uses memory it doesn't own will still operate, even if
it clobbers memory it doesn't own, which can make the system instable,
especially in a multitasking environment.  Normally, when an application
tries to access memory outside its address space, it is killed.  I'm
wondering if instead of killing the application, if more applications
would run if we instead mapped a page of blank RAM to the address that
the application tried to access.  This would be bad for new apps since
catching these errors would be more difficult.

I would say that we could implement considerably looser rules and
restrictions for all old apps, and use the stricter ones for MiNT-domain
applications or applications with a "this is a clean app" flag set in
the header.  

As for workarounds, if an AES call is done before appl_init(), run
appl_init() for the program before calling the new function and cache
the application id in case the program eventually calls appl_init() like
it should have.  Not sure if MiNT/XaAES does something like this now by
default or only certain applications.

>  2. there are currently more old apps than there are likely to be
> new ones and a new aes only supports a few old ones

A revival isn't likely, however, there is a better chance of it once
things are cleaned up.  Keeping compatibility with older apps makes that
difficult.

> I don't know if the cut&paste clipboard is an aes thing but it
> would be nice if it's use was more widespread.

Its a newer addition and relatively unsupported, and I agree that there
should be better clipboard support.

> Lastly, I know it's not aes but I'd also like to to see USB
> support somewhere in the OS.

So very few systems have the hardware required, and this basically means
creating a hot-plug system with USB drivers and all the USB device
drivers.  Its a large undertaking and I wouldn't expect anyone do this
any time soon.  I agree it would be nice though.

> Sorry if I am a bit off topic.

I don't think so at all.  Its important to know where the users stand on
what they want to see from the OS.