#3213 NORM Untriag: Running WINE on the XO

Zarro Boogs per Child bugtracker at laptop.org
Thu Sep 6 05:49:32 EDT 2007


#3213: Running WINE on the XO
-------------------------+--------------------------------------------------
 Reporter:  ssb22        |       Owner:  jg       
     Type:  enhancement  |      Status:  new      
 Priority:  normal       |   Milestone:  Untriaged
Component:  distro       |     Version:           
 Keywords:               |    Verified:  0        
-------------------------+--------------------------------------------------
 Why: Although ideally all XO
 applications will be Sugar-based,
 some ministries of education may
 want to run existing Windows-based
 educational software such as
 encyclopedia CD-ROMs etc (if
 suitably licensed), and since the
 XO does have the capability to run
 WINE, this might as well be
 documented.

 If the application is large then a
 USB key will likely by needed,
 unless it is acceptable for it to
 take up a large fraction of the
 XO's internal disk at the cost of
 other material.  This, together
 with licensing considerations, may
 lead to situations where the app
 is kept in the school library but
 can be borrowed by individual
 children as necessary.  Not ideal
 but better than nothing.

 I already had an application
 working under wine version 20050310
 (this is not the most recent
 version of wine, but as wine is
 alpha it is often the case that an
 application that works under one
 version may not work under a later
 one, so once an application is
 working it's probably a good idea
 to keep the version of wine that it
 works under).  When compiling wine,
 I had configured it to output into
 a custom directory so I had its
 bin/ lib/ and share/ files in one
 place, and after that I could move
 this directory to any path I wanted
 as long as I set the environment
 variables WINEBIN, WINELIB and
 WINEDLLPATH to point into its bin/,
 lib/ and lib/wine/ directories
 respectively, add its lib/ to
 LD_LIBRARY_PATH and add its bin/ to
 PATH.  I could therefore have a
 Wine installation that could run
 from any location as long as a
 script set the right environment
 variables first; hence it can run
 from a mounted Flash key if
 necessary (it checks $0 and
 $(pwd) to work out where it's
 running from).  Another
 significant Wine directory is the home
 directory (it looks there for .wine
 which usually contains its config
 and the contents of the emulated
 DOS drives) and I could make this
 more portable by getting the script
 to also set HOME to another
 directory on the Flash key or
 wherever before invoking wine
 (however, before doing this it also
 has to set XAUTHORITY if it's not already
 set, otherwise wine may try to
 look in the alternate home
 directory for the .Xauthority
 file).

 I tried running my app on the XO
 and it worked, except that I had to
 drag the developer console out of
 the way and then the wine
 windows were partly obscured by the
 sugar frame (and could not be moved
 or resized) and tooltips in Windows
 apps don't work.  I could work around
 these problems by temporarily
 exitting matchbox to run the wine app, i.e.

 matchbox-remote -exit
 twm & export TwmPid=$!
 .. # run wine app
 kill $TwmPid
 matchbox-window-manager -use-titlebar no -theme olpc -kbdconfig /u
 sr/share/sugar/shell/kbdconfig &

 This needs to be done from a
 script, because when matchbox exits
 it is not guaranteed that the shell
 window will be the one that's left
 with the focus.  It helps if there
 is a .twmrc in /home/olpc that
 allows windows to appear on the
 screen without first needing to be
 positioned (as pre-positioning a
 window can be awkward for
 beginners) and possibly increases
 the font size too.  An example
 .twmrc is at
 http://people.pwf.cam.ac.uk/ssb22/setup/_twmrc.txt
 but on the OLPC there's no button 2
 (and shift/control clicking is
 awkward) so it's best to modify
 that twmrc to set Button1 (in the
 title bar section) to
 f.move rather than having Button1
 do f.raiselower and Button2 do
 f.move.

 Problems with the above: Any Sugar
 applications to be run concurrently
 with the Windows application must
 be started in advance; TWM is very
 different from Sugar; if large
 print is needed in Windows
 applications then it seems it has
 to be arranged for within the
 application (which restricts your
 choice of apps and things get
 difficult for menus and dialog
 boxes - in the version of Wine
 I'm using, it's not possible at
 all to change the size of text in
 the menus and dialogs, but I
 believe this has been improved in
 later versions that I haven't yet
 set up); function keys don't seem to
 work in the Windows app (although
 they do when running on the same
 wine version on another machine);
 occasionally matchbox fails to
 restart after the windows app has
 exitted (due to failure to access
 the root window, apparently) and it
 becomes necessary to restart Sugar with
 Alt-Control-Backspace hence losing
 all unsaved data; the mouse cursor
 is too small in the Windows app;
 bringing up a menu or drop-down box
 in the Windows app works OK if you
 hold down the mouse button while
 moving the pointer to the item you
 want to select, but if instead you
 just click once to bring up the
 menu (or drop-down box) and then
 try to move toward the item you
 want to select so as to click
 again, then the menu or drop-down
 box will disappear as soon as you
 move the mouse (this bug does not
 appear to be present when the same
 version of Wine is run on a
 desktop, and I don't really
 understand what's going on,
 although it's easily worked around
 by keeping the button held down and
 it is possible that it won't
 manifest itself in more recent
 versions of Wine anyway).

-- 
Ticket URL: <https://dev.laptop.org/ticket/3213>
One Laptop Per Child <http://laptop.org/>



More information about the Bugs mailing list