Josh DuBois
Hello!
This is Josh DuBois, CrossOver product manager at CodeWeavers.
For the past few years I've spent a lot of time working on our (still relatively) new Android version of CrossOver. Of course the core of CrossOver is Wine, which just had it's 3.0 release in January. Along with the Wine 3.0 release, Wine has begun hosting pre-built packages of Wine on Android, available for download from www.winehq.org.
Despite all my time with CrossOver on Android, I have never once used "vanilla" Wine on Android before. Today that will change.
It is a Saturday at 10:30 a.m. I'm sitting in the lobby of the Minneapolis Institute of Art with my Google Pixelbook. I'm lucky to have this place down the street from my house, and luckier still that they have fast internet, decent coffee, great pastries and excellent beer.
I've got a cappuccino and a computer and a chocolate chip cookie. I'm going to see what these Android Wine packages are all about.
Let's get started.
First step - easy! Download was simple & fast.
Next step - problem. I clicked on the .apk in my Downloads folder and I got this helpful message: "Turn on Chrome OS Developer Mode to install apps from sources other than the Play Store."
Right.
Android isn't a totally walled garden, but a side-load on a Chromebook requires turning off some security features. I've done that plenty of times during my life as a CrossOver developer. It takes a little while and I think I will probably end up needing to wipe the hard drive on this Pixelbook to get there, but that's OK.
Just for kicks, I'll search the Play Store to see whether someone is actually signing these packages and publishing them on Google Play.
Er, Nope. A search on Google Play for 'wine' gives a lot of apps which, unsurprisingly, seem to be about fermented grapes. Searching for 'winehq wine' gives me a paid app which claims it will search the winehq app db (I'm not sure why a person would pay even the asking price of $0.99 for an app like that).
I guess it's time to put my Chromebook in developer mode.
This won't take too long, but will take some time. Maybe I'll wander a little bit.
Ok, that wasn't too bad. I finished my coffee and searched Google for instructions to switch to devloper mode; pressed some magic keys; let my machine reboot a couple of times, wandered around and saw some nice things in the museum, and sat back down with another snack. One important detail when transitioning to Developer Mode: I clicked the 'Enable debugging features' link when I did that. I've forgotten now what is not available if you don't do this, but I'm pretty sure the ability to sudo or get a root shell in the Android container requires it. So any aspiring Android Wine hacker will want to do it.
The transition to Developer Mode did wipe my hard drive, so I had to re-download the wine package. This time, when I clicked on it, instead of telling me to switch to developer mode it just told me I needed to change my security settings. I clicked 'OK' and that took me to the settings page, where I flipped the switch to allow side-loaded packages. That gave me one more security warning, and I clicked 'OK' again.
Now I can try installing a third time. I click on the .apk and I get an offer to install. I accept that offer and after a progress spinny and some notes about what permission I must grant Wine, I finally have success! My Chromebook tells me Wine is installed.
Now for my first launch.
Umm, it's a little weird. I get a Window with a Windows-style desktop. The screen is small. Most of it is taken up by a 'Wine Command Prompt' window. Looks like there are a couple of less-than-ideal things. The screen size of Wine's Android window on the Pixelbook is quite a bit smaller than I'd want, and the text in both the Start Menu and the command shell is too small for comfort. The command prompt window title looks good.
I use the Chrome OS window decorations to increase the size of my window and I get a warning saying it will re-start my app and that Wine may not behave well. I go ahead, and now Wine is fullscreen. The size of the Start Menu text has changed and looks great. The text in the command prompt is still too small, and the Wine desktop now obscures my entire Chrome OS desktop, but overall this is much better.
I wonder what to do next. My Start Menu has a 'Run' command and a couple of other entries, and I can launch Wine's builtins (winecfg, notepad) from my command prompt. I'd like to install a more interesting Windows application.
Installing Office 2010
For the next step I head upstairs into the galleries for a change of scene. I wander into the ancient Roman area and find a nice sculpture of a drunken Dionysus sprawled across a donkey. Sounds appropriate for my adventure with Wine. There's a nice couch next to it, and it's quiet here. I sit down and try to install Microsoft Office 2010.
I have an installer for Office on my usb stick. It's a single .exe, so I figure it will be easy to use. I insert the stick in my chromebook and click on it. I get a helpful message: "This file is designed for a PC using Windows software. This is not compatible with your device which runs Chrome OS." Fair enough. Next trick.
I use my Wine command prompt to open a file explorer (by typing 'explorer'). Not obvious where my usb stick might be. I open some various drives, including z: and something labeled '/'. Both are empty. I browse to 'My Computer' and 'My Documents'. Nada.
Because I've been doing this for a long time with CrossOver, I know the problem is that Wine has a z:\ drive pointing at the Unix root, but can't actually read that directory to list the contents. I also know that if I cd to the Download folder, I'll have permission to see what's there. So back to my command prompt, I can cd z:\sdcard\Downloads (I just know that's the right path from experience - there's no hint to point me that way). From there a dir gives me a reasonable listing. I use the Chrome file browser to copy my Office executable there. Now I can launch it by just typing the .exe filename in the command prompt.
For a while, things look good. The installer starts right up. I can enter a product key and it shows me a EULA and guides me through the start of the install. Soon, however, I get a sad window. Office tells me an error has occurred during setup and that's it: install over.
I know the Office 2010 installer in Wine has suffered from failures in Windows 7 style environments - winehq bug 38838 for the curious - and I suspect this is what's bitten me. I figure I should try again with a Windows XP prefix. I'd like to wipe my prefix away and start again fresh. No obvious way to do that from within Wine, but I can use the Android settings to just delete all the local data without totally uninstalling the app, so I do that.
Next, I launch Wine again and it configures itself and creates an empty prefix. This time I launch winecfg from the command prompt and change the prefix type to Windows XP before I re-launch the Office installer from my Downloads folder. After a short while I hit an error that looks just the same as before.
Now I remember that some applications have failed at times due to being run out of the Downloads folder on Chromebooks. This has happened because the Downloads folder is mounted noexec, and it seems to cause problems when Windows expects to mmap things with certain permissions. I have a recollection that the Office installer can fail this way. I wipe my local data; start Wine again; and change the prefix type again. This time I use the command prompt to copy the installer from the Downloads folder to the root of the c: drive before I run it. Sadly, I get the same failure.
I know other wine bugs exist which impact the installer for Office 2010. Changing to Windows XP should have worked around the one I had in mind - winehq bug 38838. However, a look in the winehq app db says that Wine 3.0 also suffers from a second failure with Office 2010 installers: winehq bug 44222. Maybe this is my problem. Luckily, this was fixed just recently in the last development release, wine 3.2. For that, I uninstall wine completely and re-download a .apk package Wine development release, 3.2.
I have a brief problem getting this release to run. I think what happens is that I use the Chrome OS window decorations to close wine, and it kills the explorer process but not the other processes running in the wine prefix. The result is that I have no more wine window, but a click on the Wine icon in the Chrome OS dock just flashes quickly and doesn't display any new window. Usually this seems to happen only once, and a second attempt to run after using that Chrome OS Window 'close' button works, but I've gotten into some pathological state where I just can't start wine at all.
Now I'm going to try to see what is happening behind the scenes. I'd like to see what is running to look for a hint about why Wine is immediately exiting when I click its icon in my Chrome OS dock.
To do this I want to open a shell and look at the Unix process list. Thankfully, I remembered to enable debugging features when I switched the Chromebook to developer mode earlier in the morning, so this should be possible.
I can get a very basic shell pressing by <ctrl>+<alt>+t. That's an odd thing called a 'crosh' shell. From there I type 'shell' to open a better, more normal bash shell. From there, I try /usr/sbin/android-sh to get a shell in the Chromebook's Android environment. Now I'm prompted for a root password due to the sudo. I enter the root password I set during the transition to Developer Mode this morning. I get a password failure. After a few more attempts I'm still getting failures even though I'm confident I've entered the password correctly.
I remember from experience that I must switch to a different virtual terminal by holding down <ctrl>+<alt>+"f2," where in my case "f2" is the third key from the left on the top row of my laptop's keyboard, and is labelled with a circular arrow on my Chromebook. That key combo takes me to a text-based console with a 'localhost login:' prompt and an invitation to run 'chromeos-setdevpasswd' to change the chronos user password on my Chromebook. I log in as 'root' using the root password I set during my transition to developer mode. Then I run the chromeos-setdevpasswd command and give the same password (just to avoid confusion). Then I switch back to my main console (where the Chrome OS gui session is) with <ctrl>+<alt>+"f1," where "f1" is the second-from-the-left top-most key on my keyboard (labelled on this Chromebook with a left-pointing arrow). Now my sudo password is accepted.
At the end of that, I get a root shell that looks like it's inside the Android container. Instead of a Chrome OS looking filesystem, I see paths like /data/data/..., so it's Android-ish. I do a 'ps' and discover there's a wineserver running plus a lot of wineconsole instances. Probably one wineconsole for every time I clicked on the Wine icon and saw the screen flash but no Wine desktop appear.
A naive user would probably have no choice but to reboot at this point. I'd like to avoid a reboot, so I kill each of the wineconsole instances from the command-line and shortly thereafter the wineserver exits. Next time I click the Wine icon in the Chrome OS launcher I get a new, working Wine desktop, as expected.
Now I have Wine 3.2 which ought to fix winehq bug 44222 and also winehq bug 38838. This means that not only will Office 2010 install, it should even do it in the default Windows 7 environment, so I can skip a step and not change to Windows XP with winecfg. I still copy the installer to the c: drive just to avoid any possible issues with noexec, and try to run the installer again.
No dice.
Same error.
At this point, it may be time to take a log to look for hints about what's going on.
Trying to do some debugging
It seems like another challenge is in store, so it's time to change location again. I walk through a nice area of Japanese watercolors and look at some of my favorites there: large murals of mountain scenes and a panel of frolicking snow monkeys. Downstairs from that is a nice rotunda with comfy chairs. There is what I believe to be a children's Dakota language course happening here, and a pre-verbal toddler (apparently bored with the language classes) keeps coming to stare at my computer. An older relative eventually lets me know she is hoping to play a video game. There's not a good way to explain to her that Wine on Android doesn't have d3d support yet.
I don't know how to take debug logs with Wine on Android. CrossOver has a GUI option to generate debug logs and also allows the user to put a file called 'winedebug' - with the contents as a Wine debug string - in the Downloads folder. I can't find any documented way to take debug logs with Wine on Android, but looking at the source (in dlls/wineandroid.drv/WineActivity.java),
String winedebug = readFileString( new File( prefix, "winedebug" ));
if (winedebug == null) winedebug = readFileString( new File( getFilesDir(), "winedebug" ));
if (winedebug != null)
{
File log = new File( getFilesDir(), "log" );
env.put( "WINEDEBUG", winedebug );
env.put( "WINEDEBUGLOG", log.toString() );
Log.i( LOGTAG, "logging to " + log.toString() );
log.delete();
}
it seems similar to CrossOver. I should be able to put a file called 'winedebug' in either the based 'files' directory of the Wine application's Android sandbox, or in the prefix. In either case, I should get debug traces in a file called 'log' in the same location. Sounds great.
Getting that file there in a readable way is tricky on a Chromebook. I'm deliberately naive here, trying to create the file with my root shell from the android-sh command. This doesn't work at first: I put the file there but no log. Next I try changing both permissions and doing a chown / chgrp to make it look just like the other files in the directory from a permissions point of view. It still appears that Wine can't read it: file is there but there are no logs.
I know that running the android-sh program will cause files I create to suffer from this problem. I also know that if I do 'run-as org.winehq.wine' (the package name of the Wine program), then I'll get a shell where I can create files which Wine can actually read. I delete the winedebug file I created as root and use 'run-as' to get a new shell as the right user. I re-create the winedebug file and now I can get logs when I run wine.
I re-run the Office installer and generate a log. I start with a grep for "err" and up pops something ominous: Wine wants ntlm_auth, but can't find it.
Again, I know from experience that this may be critical for Office and I now suspect this is my blocker error. Looking in the wine package I see it hasn't bundled any programs or libraries outside of Wine itself, so things may be a bit crippled in general. Compiling ntlm_auth for Android is going to be too hard for a day at the museum (I don't have my development machine, even if I wanted to try). It's getting late, and I really hope to get Office running.
I plan to cheat.
CrossOver ships with several nice-to-haves bundled, and ntlm_auth is one of them. I use the Play Store to install CrossOver and navigate to /data/data/com.codeweavers.cxoffice/files/x86/bin. I copy our cxntlm_auth to the downloads folder and re-name it to the normal ntlm_auth name. So far, so good.
Remembering the problem with permissions and the 'winedebug' file earlier, I try the 'run-as' command to switch to the right user so Wine can read things. Using that shell, I try to copy ntlm_auth from the Downloads folder into the Wine sandbox. But I can't.
The shell I get from the 'run-as' command can't see the Downloads folder, which is the only place I could think to copy the file where I'd hope to have access to it. I can't use my root shell because of the permissions problem I saw with the 'winedebug' file.
I honestly don't know precisely what is happening here (trickery related to the way Chrome OS implements the Android container + strange use of Linux namespaces + the Chrome OS chroot + magic dust, I guess). It may be user-error on my part, and that there's a different mechanism where I could see Downloads. If so, I don't know what it is.
I know that if I run Wine then I can see the Downloads folder from the Command Prompt (at z:\sdcard\download). From there, I can copy the file to c: using Wine's copy command. Next, I can switch back to my run-as shell and copy it from inside the prefix out to a directory where it's in the path and Wine will find it (for the record, that's /data/data/org.winehq.wine/files/x86/bin). I do that, and I'm sure to give it execute permission.
I try installing Office again.
Success!
The Office installer says things went well. In my Start menu I now have a 'Programs' menu with entries for Microsoft Word, Excel, etc. I launch Word, and it works!
Word has a few problems. It suffers badly from a mouse bug we've been struggling with, which is that when I click on the 'fonts' menu it just briefly flashes and immediately disappears. There's still no good way to save a file and find it from the Chrome OS file browser. But it's installed, and it runs.
I've spent a long time with Wine today. It's close to closing time for the museum. I head back to the cafe for a beer.
Winetricks - a diversion for a different afternoon
I didn't really come here to install Office. I came here to run winetricks.
Sadly, that's not looking likely for today. I hadn't quite expected it to take so long to get Word installed. I have a few minutes left. I can give winetricks a try to at least see what the first errors are.
I begin by downloading winetricks. I go through the usual shenganigans to copy the winetricks script into the Wine application sandbox and change permissions. The shell on Android isn't in the usual spot (it's /system/bin/sh instead of /bin/sh), so I run winetricks as 'sh winetricks' instead of just invoking it. Right away it dies with some problems creating a temp dir and a complaint about a missing SHA256sum utility.
I try to edit winetricks a bit to see if I can just get it to ignore the fact that it can't verify sha sums. Notepad is the only editor I have to use, which is tedious. I still seem to have some problems with paths of some kind: it's trying to make temporary directories and failing, and also can't find the wineserver even though I think I've set the WINEPREFIX to the correct location. But now my beer is done and the museum is closing. Using winetricks would be interesting, and should be possible, but it will have to wait for another day.
Thinking back on the day, it's been fun to try plain Wine on Android for the first time. I figured an install of Office would just be the first step today, but doing that took a long time and wasn't trivial. CrossOver's goal is to be an easier-to-use version of Wine, and I'm happy to reflect that CrossOver has solutions for many of the stumbling blocks I encountered using Wine on Android. It makes me think there is a good opportunity to make Wine's Android package a bit easier to use also. It's definitely cool that I was able to run Office. It was critical that I had a pre-made Wine on Android package of the very most recent Wine development release at my fingertips from the Wine website.
Since I've come it's started snowing. There's a wonderful blizzard outside filling the sidewalks with snow. It's time to go home and shovel.
About Josh DuBois
Josh DuBois is an engineer and product manager for CrossOver.