The startup's app "player" brings hundreds of thousands of Android apps to the Windows 8 environment.
Read more at source:
BlueStacks brings a boatload of Android apps to the Surface Pro | Crave - CNET
Here we go folks another lost argument for Surface haters, maybe next we'll see IOS Apps on there as well, I can see Tim Cook lining up to get them on there.
Hi there
most of these are basically "Craplets" -- in any case what's problem -- you can already run various versions of Android on Windows 8 (or Windows 7 - or even XP for that matter) as a VM - and run loads of these "craplets" with or without touch facilities too.
What's so earth shattering about this announcement -- Surface PRO runs WINDOWS 8 -- simple - end of -- so what's the earth shattering event here.
In any case tiny apps can easily be ported to another OS by those people who seem to enjoy writing code -- the Visual studio (even the FREE version - not the MSDN one) would contain all the facilities you need whether you want to do it in Java, VB or C++.
This would have all the libraries and API calls so you'd just need to change the appropriate API calls from the Linux version (That's all android is - just another Linux - ) to the Windows API's for GUI interactions (Screens, touch / keyboard / mouse I/O) while the actual application source code would be essentially the same whether on Windows ot Linux --especially if written in something like JAVA.
Once you've stripped off the OS dependendent bits (the GUI) that's the advantage of using a "Meta code" as the source would be the same for any platform. You just run the Meta code into the relevant "Interpreter" or "Compiler" for the target system.
These days using Interpreted code would probably be easier as modern hardware is well able to afford the overhead of Interpreted versus Compiled code - and it's easier to test and debug anyway.
I haven't done development work for "Donkeys Years" but can't really see that porting a load of Android stuff to Windows would really be a humungous task.
(It's much harder the OTHER way around since there's stuff in Windows not easily "replicatable" in Linux).
For those who don't understand the concept of Meta code -- it's a relatively simple concept.
For example the old FORTRAN language -- was a mathematical way of programming -- for example a you would say
x = sqrt(y) + tan(z). You'd input y and z and the computer would give you X.
Now the old computer (8080 - Windows 3.11 days) had a base Intel assembler language (somewhat similar to the CPU instruction set).
So what your original Fortran would do would be first to convert the Fortran statement I've listed ( x = sqrt(y) + tan(z) ) into a whole set of ASSEMBLER source statements -- there are well defined functions for example how to calculate the square root and the values of the Tangents of deg / radians ).
This Assembler source code would then be input into the system assembler to generate the machine code to execute the program --essentially a two pass process. - These days compiler writing isn't done like that but it gives you an idea of how a "Meta Language" works since that Fortran statement could also be run on say another different type of computer (in those days you had another processor 6802 with a different machine set). So all you'd need is for the SAME Fortran source Meta language to produce the 6802 Assembly code rather than the 8080 code and then run it through ITS assembler.
Quite a simple concept actually -- principle is still used today by some of the largest corporations on the planet -- SAP for example has a business language called ABAP which is simply an Interpreted Meta language which allows ABAP development of SAP software to be handled on a large number of different machines and Host OS'es.
Cheers
jimbo