[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] patch:MiNT:KM_FREE
--------------------------------------------------
From: "Paul Wratt" <paul.wratt@gmail.com>
Sent: Tuesday, December 15, 2009 10:17 AM
To: "mint" <mint@lists.fishpool.fi>
Subject: Re: [MiNT] patch:MiNT:KM_FREE
instant per app themes (without the work, well in theory.) running
I can assure you that this is *much* easier to implement in a single AES
than trying to run several AES's concurrently ;-) You imply that you want to
run several instanses of AES on the same physical workstation - how do you
want to synchronize them? You'll need a common window stack and desktop. And
if you want apps running under AES A to know about/talk to apps running
under AES B, you also need a common message system and common application
handling. Sounds complicated to me!
I have already experimented with multiple desktops, it is possible,
but I did not test the practical side of it, yet...
It works just fine with one AES, but there can only be one AV-server. Even
with multipe AES instances, there can only be one AV-server if you want apps
to talk to each other (assuming that you've arranged some sort of messaging
between the AES instances).
different AES would make it even more visually distinctive..
It will not work with current apps. Let's say you have two instances of the
AES. You want to run papyrus under AES A, and Tempus under AES B. Both
starts their AES session by calling appl_init(). Both will put the necessary
info in the global AES variables, and then both will call the same TRAP with
the same opcode. How do you know which AES handles which call? How do you
distinguish them? There must be some syncronization between the AES
instances, which I think will be much harder than just having one AES that
handles "themes" per application.
It may be useful later on for VNC and remote desktop "assistance" and
VDI/AES streaming over TCP/IP (or UDP), as one "AES/desktop" can
remain untouched..
You mean to be able to log on to your Atari and start an AES session that's
independent from the one using the physical workstation? That's doable - as
long as the trap-problem can be solved (and this would be very, very
tricky!). In this case there is no communication between the apps running
under the different AES instances, and they don't share the same physical
workstation either. Basically you "just" need a VDI device driver that works
over a network. And again - you need to figure out the trap-problem.
It could solve the problem of multiple user logons
with different AES and desktop settings (for systems that can handle
it and use it). It would be a good "proof of concept" test at least,
This is only an issue if you need to have multiple users logged on at the
same time (see above).
Anyway, I think this is pretty far fetched and a bit out of scope. There are
lots of more useful things that needs to be solved first. Basically, I think
that more programming efforts must be put into creating applications. A
pretty, customizable OS is nice, but new and better applications are even
nicer :-)
Jo Even
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4689 (20091215) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com