[sugar] Wine Activity and DOS Console

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Short:
I have made a DOS Console activity based on Wine.  You can download it from
http://dev.laptop.org/~bemasc/DOSConsole-1.xo

In order for it to run, you must first add 'org.winehq.WineConsole' to the
list of RAINBOW_CONSTANT_UID activities in
/usr/lib/python2.5/site-packages/sugar/activity/activityfactory.py

It doesn't play well with others, and is generally not useful at this
time.  The goal is to provide a simple system for turning any Windows
program into a Sugar activity.

Long:
This activity includes a complete copy of Wine 0.9.59 (latest version),
with a goodly amount of shell-script magic to make the installation work
without root privileges.  My intent is to provide a framework with which
anyone can transform a Windows application into an activity with Wine.
Each such activity will run in its own private virtual windows machine,
with sandboxing provided by Bitfrost.  Wine is much better than you
probably remember, and can now run IE 6, MS Office 2003, MS Visual Studio,
and a host of other windows-centric software.  My hope is that OLPC will
soon be able to say that we can run most Windows software, but with better
security, better power management, and better mesh networking.  That is
not to say that I encourage writing Windows-based software to run on the
XO; indeed, I am among the most anti-legacy developers around here.

There is currently no integration with the Journal or Datastore.  The
activity instead maintains its own disk state using the
$SUGAR_ACTIVITY_ROOT/data/ directory.  From a UI standpoint, I do not
think this is unreasonable.  There are many simple windows-based
educational activities that are essentially stateless, and therefore will
work especially well in this model.  Windows-based applications also tend
to store state in a variety of places, such as the registry, which makes
encapsulating state quite difficult.  However, olpcfs may eventually
provide some datastore integration, by regarding the entire virtual disk
as a datastore entry.

This system requires that every wine-based activity must carry around a
complete copy of Wine, about 12 MB.  I hope that users will not have many
such activities installed anyway, since their user experience will
inevitably be subpar.

Bugs:
Due to the way Wine interacts with the UNIX uid system, Wine must be
launched as the same uid every time.  It may be possible to fix Wine to
remove this dependency.  Until that is fixed, DOSConsole (and any other
activity derived from it) must run with RAINBOW_CONSTANT_UID.

Due to a poor interaction with the window manager, Wine's window has
unnecessary decorations, and appears in front of the frame rather than
behind it.  This makes it impossible to use any other activity until after
the wine-based activity is closed.  Changes to the next version of Wine
may improve this situation, as may the next round of changes to Sugar's
window management.

Because DOSConsole is not python-based, it does not connect properly with
the current activity launcher mechanism.  Thus, its entry in the activity
list will blink for several minutes, then disappear, regardless of whether
DOSConsole is running.  The same would be true of any activity derived
from DOSConsole.

I have not attempted any localization, but it should be possible.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH/9t8UJT6e6HFtqQRAu2XAKCIWfhJbW/CpFr4RvyBJxrK+kHbKQCeMMXe
Frim/G8jp7OkUNC0aNjYWxQ=
=bi/1
-----END PGP SIGNATURE-----