First there was emulation. You create a virtual PC, boot Windows into it, and run your program there. It works, but it's slow. You're emulating an entire processor, which is never fast. And you need to buy a Windows license (if you want to be legal.)
Then there were cross-compilation libraries. You take your Windows sources and compile them against the library to get an app for another platform. These work well, but they're only useful to someone with access to the source code (like the original developer.)
Then there were library-server systems, like WINE. No processor emulation (so you need an Intel-based computer), just OS emulation. You run a server that loads the app, links it up against appropriate libraries, and then runs it. This works, but you need that server, and all the associated libraries, in order to run your application.
And now there's Alky. If I understand their web site correctly, Alky reads your Windows app and generates a native app from it. In other words, it treats a Windows app as source code, which it proceeds to recompile into whatever your own operating system requires. When it's done, you have a native app, and can throw away the original.
This isn't the first time this has been done. Java systems do this in order to get good performance (since interpreting bytecode is slow.) The difference is that Java systems use a just-in-time compiler. They compile the app into native code on an as-needed basis, but they don't keep the results of the compilation. If you quit and re-load the application, it has to re-compile the app.
I have yet to try out Alky, but if it works as promised, this could be a really big thing. Of course, many of us said that about emulators (like Wabi) and WINE, so I could be wrong.
No comments:
Post a Comment