Apparently, the programmers have a good passion for alcohol and a certain taste for puns. WINE, which is a recursive acronym that stands for WINE Is Not an Emulator, is a known compatibility layer between UNIX-like operating systems (such as Linux , BSD , OSX , etc.) that allows you to use Windows programs and CIDER. At the moment there is not a logo, but we suspect you know what it will be.
But what is a compatibility layer, and why should I use it? It is, in effect, a layer that mediates between the guest operating system and the application you want to run. Basically, the layer intercepts system calls and libraries application, the call becomes compatible with the host system and forwards them to the latter.
Think of it as a simultaneous translator: if we want to talk with a person who speaks, for example, but do not know the Chinese language, we can hire a person that allows us to continue to speak Italian and at the same time to be able to talk to the other person. Clearly, the translator needs some time to translate everything in the proper manner, then you have a small loss of time. The same also happens in the software (and the loss of time is called overhead).
Cider gets in the way and acts like a translator that translates calls "language iOS" in "language Android" allowing applications to run. This is clearly an oversimplification and perhaps not formally correct, but it helps to make the idea.
The Columbia students were able to create a system that reduces the overhead to a minimum and allows both to maintain compatibility with applications for Android is to run applications for iOS. Here's what they have done:
We present Cider , an architecture compatibility between operating systems that can run applications compiled for different mobile ecosystems, iOS or Android, together on the same smartphone or tablet. Cider improves the local operating system, Android, is a device with personas [ identity ] specific to each thread handled by the kernel that mimic the application binary interface to an external operating system, iOS, allowing it to perform external binaries unmodified.
This is accomplished using a new combination of techniques including binary compatibility two new mechanisms: adaptation of the code at compile time and diplomatic functions. The adaptation of the code at compile time allows you to reuse source code that exists on the local kernel, reducing implementation effort required to support multiple binary interfaces to run local applications and external.
The functions of diplomatic leverage personas for each thread and allow external applications to use local libraries to access proprietary interfaces for software and hardware. We have created a prototype of Cider and shown to cause a modest performance overhead and runs with Android and iOS applications without modification on a Google Nexus tablet running the latest version of Android.
Each thread has its own identity that, according to what we can understand from the documentation, can be managed individually to get the best possible configuration.
Clearly it is a prototype that will be refined and improved before it can be actually used. Among other things, we do not work a lot of interfaces such as camera, Bluetooth, and GPS; this causes crashes in applications if they have not been programmed to do without these elements.
The six students will continue to develop Cider. This means that in a few months we could have, potentially, a framework of the most functional and practical to run iOS apps on Android.