It should also be pretty quick, because that's not the whole lab. And then explain some of the technical challenges and explain what remains to be known, which will be a lot longer. There's a pretty big list of things to do.

So the first goal is obviously to run Windows binaries on Intel Android devices, Windows binaries being built for Intel CPUs. So we need an Intel CPU in the device. That's basically exactly what we do on Linux and Mac.

The other possibility is to use wine to port Windows source code to create native Android binaries with packages. This, of course, opens the possibility to also port devices. The tricky part is you need the source code

for the entire application, which most vendors don't have the source for the old applications. Most Windows apps always use some kind of dull party DLL, and then you get into the CPU compatibility problem again. And then the last goal is, of course,

to run the Windows binaries on ARM devices, which is an interesting challenge. Of course, since most Android devices are using ARM, this is what's going to make the project really useful. So what is working today, we've added support

for the ionic C library. So Android is using a Linux kernel, so that part is obviously working already fine. But the C library is different, so we have to port wine to the C library. It's mostly adding configure checks and replacing functions that are missing and stuff like that.

So that was fairly easy. That's all in the wine tree now. So if you get the wine source, you can build for Intel Android or ARM Android simply with the configure online.

You have to install the Android NDK, of course, and then you can build an Android version of wine. Of course, what you get if you do this is that it's a version of wine that lets you run command line applications, which

is not all that interesting. And also, if you try this configure, you will get a huge list of warnings about missing libraries, because there is a ton of libraries. A number of libraries that wine is using, we try to keep it down to a minimum,

but we still need a number of external dependencies. And these are, of course, not provided with the Android NDK. So if you actually want a version of wine that is useful, you then need to cross-compile a number of other libraries, which most of the time

is also just a matter of doing configure, that's dash, dash host, and build the library. But some of them are more tricky. This is, of course, not really a wine issue, so it's not something we can really do anything about.

But if you want to build a full package, that's one of the problems we have. You need to build a lot more than just wine. And the last thing that is working today is a basic graphics driver that I've put together that is not in the wine tree at the moment.

It's basically on my disk, and that's all. And this driver is using wine in desktop mode, so that's the mode where everything is inside a single window, and you have the windows, window management, so windows decorations,

stuff like that. So this is not supposed to be the final driver. I'm hoping to do a driver that integrates much better with the Android OS, that doesn't look too much like windows. But at least it lets you see that the applications are working,

and make sure that it behaves reasonably. So at this point, I'm going to try to show it. So this is Android for Intel running in VirtualBox.

On the Mac, I don't have an actual Intel device here, so it's still native Intel CP. It is a bit slow, but that's because of VirtualBox.

Android itself is a bit slow. So as you can see, you get wine application on your Android task manager. Now, that's one of the things we are trying to address,

is that you don't really want wine here, you want your applications. So if you install Office, you want Word and Excel icons on the Android task manager.

But right now, all you get is wine, and then start wine, and hopefully get some. So I've made it start at the common prompt. So this is the standard wine desktop

that you get on Linux if you enable desktop mode. And the icons are the desktop launchers. So if you put link files in the desktop directory, you get the icons. It's the same as on Linux. And so it works just fine.

I can start PowerPoint. Hopefully there's no feedback when you click the icons, so it's a bit tricky to know if it really started or not. Yes.

So this is PowerPoint on Android. I'm cheating a bit here because I have

an actual hardware keyboard and hardware mouse, which makes everything easier to use. This one, an actual tablet, it can get kind of tricky to click on the icons. And I mean, you have to use your finger, and your finger is probably big like that.

In this case, PowerPoint is actually totally good at scaling up the interface. So I tell PowerPoint that it's on a high DPI screen, and it scales everything up. So you can actually use it with your finger. It's more or less usable.

One problem you have is, for instance, if you try to exit PowerPoint, the exit option is somewhere here. Because it's scaled up, then there's no way it can fit everything on the screen. So that's one of the things we need to address,

sort of some kind of panning or zooming, unzooming of the interface, so that you can use a desktop application on a small device. But apart from that, you can do...

What we have up there is the software keyboard account. So if you click that, you get the Android software keyboard, which of course is eating up the screen. I also had some hacks that try to pop up the keyboard

when the application is showing the blinking correct automatically, but that doesn't quite work at the moment. So there is this icon that you can use to show and hide the software keyboard. And for some reason, the keyboard doesn't work right,

but that's not one spot, that's Android. It should go all the way here. And if I click on P, it actually presses I, because I don't know why it's scaling this way. But it happens the same way in native Android apps,

so it's not like that. And then you can hide the keyboard again to see what you're doing.

That's it for PowerPoint. And then again, as you see, this is desktop mode, so you get Windows decoration, you get Win95 style graphics.

It's purely Windows, it's not very integrated. So again, the goal would be to make this the Android dialog, native Android, as far as possible.

Basically all that's working, switch tasks. Again, what you see if you go to the task manager is you see just one. What you would really prefer is to have PowerPoint,

Word, and so on, in the Android task manager, and be able to switch applications with this one. But for the moment, you have to go back to Wine, and then inside Wine, you switch to a different application.

And if you quit, then it's, oh, it's still working. Sometimes you quit, then it doesn't come back. This time it did, so that's good. So going back, this is what is working.

So some of the problems with, I've had to achieve that, and I will have to achieve a lot more. First is Java, of course. Android applications are written in Java.

And there are actually fairly good mechanisms in Java to call native code, and for native code to call back into Java. So this is actually fairly well thought out. One of the issue with Android specifically

is that most of the Android APIs, especially window management and so on, can only be called on the main Java thread. So you can call Java methods from the native app, but it doesn't really help because you're not on the right thread. So you still need some messaging mechanism

to make Java calls. Which leads us to the issue of the process architecture, because if you're running in Java, of course you need a Java process with a Java virtual machine. And that doesn't really suit itself

to running Windows binaries, which really want to be in their own separate process. So the next slide will explain more about the process architecture. There is the issue, of course, of the missing libraries. So this is the list of libraries that I've had to cross-compile

to be able to run Microsoft Office. Already a fair bit, and there are more than you need. If you want a full wine version, there are even more than that. Most of these were actually fairly easy. Samba is probably the worst cross-compiling.

And that's Samba 3, Samba 4 is hopeless. They're very good to cross-compile. The other issue, of course, is lack of keyboard and mouse. So you don't really see the issue

because I had keyboard and mouse. You can use the software, Android keyboard, of course, for entering text. That just works. But if you want to run some games, for instance, that want special keys or that wants to use the keys as control instead of text input,

then we need some sort of mechanism for that. Probably a virtual PC keyboard where you can enter more than just text where you have function keys, where you have that sort of thing. And the mouse, of course, is also the problem that you need a very precise pointer

for many Windows apps, especially Windows apps that don't scale up the interface, don't scale up all the buttons. Because then you get very small buttons and we need some way, for instance,

to zoom a specific part of the interface. I was considering maybe when you touch a button, it would zoom up and then you can touch the actual place that you meant, something like that. So that's all in the air for now.

High DPI screens, obviously, that's the main problem. Most tablets have a very high resolution but a very small screen. So we need a way to pan and zoom. But you will have that now in the desktop. Yes, it's getting more common also on the desktop, yes.

And there are ways in Windows to use high DPI's and modern applications handle that correctly. But of course, the old ones don't. PowerPoint was a very good example of an app that's done right. Because Microsoft is kind of hard to do that.

Many other apps don't, I'll show one later on. So yeah, we need a way to do that. It's a bit tricky because the zoom, you cannot do a clean zoom like you do when you're using a web browser when you zoom

and it re-renders the webpage in a higher resolution. With the Windows app, of course, all we can do is blow up the pixels. So it's not going to look very, very nice. That's basically the best we can do. As far as OpenGL, there's only OpenGL ES on Android devices.

Which is, of course, not something we support at the moment. So we need to be able to do direct 3D on top of OpenGL ES and not just OpenGL. And if you want to run OpenGL games,

then we need OpenGL on top of OpenGL ES. So that's an interesting challenge. And of course, at the moment, there's no way at all that we can do OpenGL. Because what I'm doing with the desktop mode, graphics driver, is that it's basically a display surface

that I'm copying the bits into from the different applications. So there are actually several copies of the window bits into the desktop and then from the desktop into Android. And of course, with OpenGL, you cannot copy the bits three times

across different processes. So at the moment, there is absolutely zero OpenGL. So I don't know when we'll have it. And then, there are a number of restrictions when you want to distribute Android packages.

You need to sign the packages, for instance. And that's a problem if we want, like I mentioned, to have the Windows applications on the task manager. Right now, you have a wine icon, so that's a wine package, to actually really want this PowerPoint world and so on.

And to be able to have that on the task manager, they basically need to be Android packages, which ideally, when you install an application, you would generate the package to make it appear on the task manager screen, but you cannot generate the package because it needs to be signed.

So there are ways around that, but it's kind of tricky to make it look like a Windows app is actually an Android package. And if you want to distribute the packages,

for instance, in the Google Play Store, then there are also size limitations. Packages can be only 50 megs in size. And once you put all the wine in the package, it's basically over 50 megs. It's kind of tricky. What you have to do is to create a separate package

that you download separately from the main package and install the wine library somewhere else. And I don't know, so for now, I just upload the package to USB, so there are no size limitations. That's going to be addressed.

So a little bit about the architecture, how this is all working. So in Android, normally you have Java process. So this is the main process that's running the Java VM. And you have all the Android Java classes running inside that process.

And you don't actually have much control over the process layout in Java. So you cannot, for instance, tell Java, create me a new process. So what I'm doing is the wine activity, so this is a Java class that's basically an activity.

An activity is an Android application. And the wine activity would load the Windows wine libraries inside the Java process. So in this case, it would be explorer.exe because that's the desktop process.

It's the one that's doing all the desktop. Of course, I'm showing the explorer here, but it also loads NTD and add kernel, and everything. Everything. So these get loaded inside the Java process. But when you want to start a new wine process,

then you cannot do that from Java because it would all be still inside the same process. So what I do is fork and exec the wine process, which is then a purely Unix process. There's no Java, it's basically a Linux process.

And that makes things a bit trickier because from the wine processes, you want to display something on the screen. There's no way of doing that because you would have to make Java calls. But you cannot make Java calls from a process that is not inside the Java process.

So we actually, at the moment, actually everything going to the wine server. And for displaying Windows, I use shared memory and everything else is using basically Win32 messages and stuff like that, going to the wine server, which is also a separate Unix process.

The advantage of doing it this way is that we have main wine processes here. We control the address space layout. We can use the wine preloader to set up the address space. We can signal handlers. We can do everything we do on Linux.

Basically, it's a standard Linux process. I tried at some point to make every process into a Java process so that we can do Java calls from any wine process, but it's very difficult. There is no way you can get control

over the Java process. You cannot pass file descriptors. You cannot set environment variables, et cetera. So this is the architecture I'm setting up. What remains to be done now is, of course,

the user driver, so that's all the, basically all the window management, all the things having to do with the clipboard, with mouse and keyboard. It's really a big task. It's at least as big as the Mac driver

that we did for the last release. And this was probably, it took a year, basically, to do the Mac drivers. So I expect the Android driver is going to take at least as much time. And that's mainly what I'm working on now. We're doing the window management

to integrate more into the Android desktop, get rid of the desktop mode, make, basically, every Windows app into a full screen Android app, use Android pop-ups for the pop-up dialogs and stuff like that.

We need, of course, to do Eric 3D and OpenGL on top of OpenGL ES. That's also a fairly big task. We need sound support. There are sound APIs that are usable from native code on Android.

It's based on OpenSL, I think. Which is kind of like OpenCL, only different. I have no idea how hard that's going to be, but that's going to be Andrew's problem. May not be that hard.

It's not that different from Linux. Then I need to figure out how to make all of these built from the wine tree, which is going to be interesting because there is Java code. And it's, of course, I can put the graphics driver

in the wine tree, but the graphics driver is not going to do anything useful unless it can call Java. And the Java code needs to be in the wine tree, but you really cannot build Java simply from May 5. You have all sorts of, all the big infrastructure for Java is in Java.

And I don't know how it's all going to be able to be integrated and I'm going to make it possible for people to just run Make and get an Android package. So that would be interesting.

The last thing we need is to do more integration. Like I mentioned, having apps show up in the task manager. Maybe, for instance, mind type associations. So if you receive a Word document in your Android email client, you can click and it opens in Word on your Android device, things like that.

That's also kind of tricky because, once again, many of these things need to be part of the Android package, which is basically, you specify at compile time and you build the package and you sign the package and you distribute that. So you cannot, after the fact, tell Android that,

yeah, by the way, this package also handles Word document once you install Word. You have to specify that at compile time. So I don't know how that's going to work.

And of course, the last thing is the QEMU support so that we can run Intel binaries on ARM devices. And I've been actually playing with that and it's working reasonably well. There are some bugs in QEMU, unfortunately,

which I was hoping QEMU people that we can blame. No, they probably shouldn't. You should have asked first and then said. Well, I went to a few talks yesterday trying to find QEMU people without success.

Yeah, so the way I'm doing QEMU. Here's the architecture with QEMU. So normally what you do with QEMU is you simply run the whole of WAN under QEMU and then in theory, everything works just fine. You get WAN x86 and you run that under QEMU

and it works. The thing is on Android, you cannot do that because parts of WAN are running inside the Java process. And on an ARM device, you cannot get an x86 Java VM and run the Java process under QEMU.

So what I'm actually doing is that I'm using native ARM binaries for all of the WAN parts. So I explore the TXC and of course, and TDLM and 32, kernel32 and so on are all built for ARM. And so this is all native ARM code.

This is all native ARM code. This is all native code. And only at the point where we try to run an x86 binary, then I will launch the QEMU process and run this specific binary inside the QEMU process.

So the advantage here is that of course, you get much better performance because everything apart from the WAN binary is running natively. The WAN server in particular is running natively so you get full speed there. All the window management is running natively. You get the full speed here.

So basically, you have only one small, or not so small, depending on what you run. At this point, it's only solitaire because that's the only thing that doesn't trigger a QEMU bugs. So it's very small. But it actually runs surprisingly well.

When I tried this, I was expecting that it would be totally unusable. And it's actually usable. And with zeroping, we can fix the QEMU bugs and get Microsoft Office working so that we can assess the performance with the real ARM. It really looks like we can do something with that.

Of course, the drawback with this approach is that because all of these are native binaries, you basically need two full versions of one. You have the ARM version one for all these processes, and you have the x86 version one for this process.

So it makes the package twice as big, which was already a problem with only one version. But it's working. And I actually have a device here that nobody is going to be able to see because it's very small.

But I have a screenshot of the device. I still bought the device, so you can see I'm not cheating. Nobody sees it.

I got an ARM. Solitare on an ARM.

So you can come here after the talk and see that it's for real. And this actually demonstrates also some of the problems we have with the scaling. Of course, here I'm reporting high DPI's,

so all the interface elements that are done by WINE are scaled up. But, for instance, the score here is done by Solitare, and it's not scaled up because Solitare doesn't expect high DPI screens. Or, for instance, the icon over there is pretty much unreachable.

I mean, if you have to touch that with a finger, there's no way you can click this icon. So that's the sort of issue we have. This is an especially high DPI device. The difference is pretty obvious.

Actually, you can read the text here because it's blown up. On the device, it's actually pretty hard to read, even for me at this distance. Right, so that's what I'm hoping to do.

Once we fix the QEMU bugs, we should be able to basically run everything the exact same way as we did on Intel devices. Of course, there are a number of issues with that. If we go back to the architecture design, because we now have ARM processes

and Intel processes running with the same WINE server. The WINE server is meant to support that. I mean, support for multiple architectures but there are issues, for instance, in the registry. With the Windows registry, you have CPU information.

So do you put ARM CPU information or Intel CPU information in the registry? That's the sort of issues that we need to solve. Basically, to have kind of a transparent view of the registry, depending on which process is querying it, you return the Intel version or the ARM version.

Stuff like that. Well, just like on x86. Yeah, it's kind of the same mechanism as 32 and 64 bit. Except there are no Windows mechanism for that, so we need to invent them. So you can do it better than Microsoft. Yes, shouldn't be too hard.

So that's it for this presentation. Some question, I'm actually going to ask the first question because I know everybody is going to ask that. Actually, since I did the demo,

the initial demo last year, I've been getting made about once a week from people. When can I get a WINE library? So you have to be a little patient. At the moment, it's basically all on my disk and it's not really in a state that I can give to someone and maybe do something useful for anybody else.

I will be trying to release patches as I go. Everything that's related to the graphics driver has been merged. I'm hoping also to merge the QEMU stuff because that's relatively straightforward.

The graphics driver is going to take a while before it's available. And also at this point, I don't really need anybody to test the code and find problems. It's not how to find problems, it can make mess up.

So that's all I had. Are there other questions? That on Linux on ARM then, does that, the version part will be useful for that? Sure, sure. That's the idea. I can merge that part and it can be used on any platform.

Yes. Doesn't Windows RT have a mechanism to run Intel binaries on Windows RT yet? It does not. Windows RT is basically dead. Yeah, one thing you could do is to run Windows ARM binaries on ARM devices. Well, they don't even officially let you run those.

They don't even let you run the Microsoft ones that ship with it. Yeah, you cannot get ARM binaries to run. And even if you could, I mean, there are like 100 times more Android apps than WinRT apps, so there's probably nothing you need.

So that's why the focus is on desktop apps. And additionally, all the, as far as I know, the WinRT and also Windows Phone APIs are pretty much unsupported in line at the moment. Yes, yes. You can run a Windows Phone command line application if you happen to be in such an exit.

That works, but. Actually, there are people that are also making patches to get those APIs and then you can run Windows Phone. Yes, that was me. Oh, okay. You're amazing. Do you know how complicated fix? Yeah, just a small matter of code.

Talk about a use case where you use the phone as a desktop device, so you put it somewhere and then it gives you a school choice keyword and makes it a normal monitor. So you open your mind application once you have it set up.

Sure, you can do that. I mean, if you have a hardware keyboard and mouse and big screen, we'll take advantage of it. So yeah, yeah, good boy. I mean, you want both. We don't want to be limited to that case. But yeah, it definitely works. Yeah, and I think it tries to do this kind of.

Yeah, yeah, exactly. And it's actually the way most likely you want to use it. You can put PowerPoint on your phone, but it's only really usable once you plug your phone into a big screen. Yeah, that would work.

Storage requirements are there too, I'm sorry. Sorry, that is trivial, but yeah, Office is pretty big. Initially, the VirtualBox session I had had the 256 megabytes of RAM and that was not enough for Office.

So I had to go up into one gig of RAM in VirtualBox so that would be pretty much the same on an actual device. But most devices that can have RAM are, yes, yes.

That's a one gig VirtualBox. So this space is actually, again, depends on the application. I mean, one is about 50 megs. It's, I don't know, 100 megs. One is extracted. But then if you install Office, it's a couple of gigs. So you need that space on a device.

Yeah, you can run PowerPoint. No, you don't. You need space for Windows. We don't need space for Windows. You can also just support iOS?

No. I mean, it's completely different. And it could be done in theory, but Apple is never going to let you in the App Store, so nobody's going to be able to get your code.

Sure, in theory, someone could do an iOS driver, yeah. And what do you need, a rooted device to run this? No, no. Okay. I use rooted devices for debugging. That's a lot easier, but no, you... At the moment, it's a bit tricky

because I have not tried to run the installers. So I install basically the app on PC and then copy the files over. And for that, you need root permissions so that you can modify the files inside the application. But ultimately, you run the installer on the device and then everything uses the app permissions

and you don't need root. Is the plan for OpenGL to also do remote procedure calls like you do it for basic Windows at the moment?

Do you see any other option? No, the plan would be to get access to the OpenGL surface. And of course, direct it back. Let's say you are on an ARM device and running an x86 binary. Where you're going, the x86 is in shell, right?

That's harder, that's harder. What I basically had in mind is with the command string for deeper D, would it make sense to design it in such a way that what's currently the thread that executes everything could be a separate process? Because we have had remote procedure calls

in binary 3D at some point. So that could be used for deeper D stuff. Well, yeah, resource updates need some kind of way but streaming and the Monday itself is not an issue. Yeah, but I mean, really, you don't really need to go through the other process

except for getting access to the surface. I'm sure that then you can do everything natively except of course, in the x86 case. Thank you very much.