Database Info

JIT in Dalvik JVM

Hello,
Do you know that it is possible to enable JIT in Dalvik JVM?
http://groups.google.com/group/0xlab-devel/browse_thread/thread/1edef26f4e5b7427
According to the Dalvik developers it is possible to backport JIT to the Donut tree and gain ...1.74x in performance!!! It would be awesome if someone could spend some time and create a ROM with that patches applied.
Anyone?
Karol

I think you misread somewhere.
It is a *new feature* they are *adding in*. The current JIT in AOSP/master is in development (i.e. incomplete). You can play with it if you want, but you should consider this to be a future new feature that will be added to official builds.

Well, I though that this is xda developers forum, place where even experimental Android features are welcome (vide extra memory hack and others...
And while English is not my native language I doubt that I have misread it. The current master tree ALREADY contains JIT implementation PLUS there are patches which allow using it in the Donut tree. So even though it is experimental it is worth checking out because it apparently it can be compiled and tested...
I would do this by myself, but since a week or so I am unable to update my donut tree, I am getting "fatal: The remote end hung up unexpectedly" messages

The current master branch in AOSP is eclair. If you use repo to sync the AOSP source, then build, the branch it pulls out (according to the output from envsetup and the lunch menu I receive) is eclair (2.0). I doubt that the donut branch has the code for the Dalvik JIT.
It *may* be possible to backport it to donut (1.6), but why when 2.0 is running on the Dream except for some AV/codec issues without problem?

Let me quote developers behind JIT in Dalvik....
NOTE: the results were measured in Donut based environment. That is,
there are some changes for Eclair backport to Donut without replacing
the libcutils and bionic, which were modified a lot in Eclair.
If you would like to introduce Eclair's Dalvik VM in Donut based
products (especially for 3rd-party components compatibility), feel
free to apply the attached patches and rebuild Android.
Here are the instructions:
# cd android-donut
# mv dalvik dalvik-orig
# . build/envsetup.sh
# git clone git://android.git.kernel.org/platform/dalvik.git
# cd dalvik
# git apply dalvik-eclair-backport.patch
# mm
# cd ../frameworks/base
# git apply frameworks-base-eclair-backport.patch
# mm -B
# cd ../../
(Do copy out~system to your target.)
Click to expand...
Click to collapse
This is from the link I pasted in my first message...
And why? Well, because there will be no full Eclair build for G1 until HTC releases some closed source components which currently doesn't work with the Eclair kernel. So this is still worth trying out, I doubt that those components will be released in near future...

karolbe said:
Let me quote developers behind JIT in Dalvik....
This is from the link I pasted in my first message...
And why? Well, because there will be no full Eclair build for G1 until HTC releases some closed source components which currently doesn't work with the Eclair kernel. So this is still worth trying out, I doubt that those components will be released in near future...
Click to expand...
Click to collapse
Ah, I stand corrected. It looks like it is indeed workable to get 1.6 with a JIT Dalvik. However, once HTC (or Qualcomm) releases the needed A/V drivers, 2.0 will be fully functional on the Dream. But, this might be nice in the interim.

Is that just the Eclair Dalvik version, or is it also the JIT-enabled Eclair Dalvik?
There /is/ a difference between the two.

I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so

Yeah, I tried it out, and the phone seemed to be less responsive. When I tried to install an app the phone rebooted, and now it seems to be booting to a certain point and then shutting down again. Nice progress though.

cyanogen said:
I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so
Click to expand...
Click to collapse
Memory Hog.
That's what I was afraid off, that a JIT would hog memory. And if there's 1 thing that my G1 is really short of, it's memory. RAM for running applications. So no please no more memory hoggging on my G1! ;-)
I'm afraid that memory hogging is kind of unavoidable for a JIT.
Just my 2ct.
--Tim

Anyone tried this with the memhack and CompCache running?
EDIT: Running it myself now. Can't see any lagginess; everything seems to be running quite snappily. Going full-time with it now.

I haven't done any java stuff for a while, so I might be off. Anyways, since this is a vm library change, I assume it runs in mixed mode (dynamnically compiles the java byte code when needed), which may cause performance issues. Is there a way for us to pre-compile all the java code in the apps with jit? and have the apps run natively without the dalvik vm at all? This would be the most desirable. I think the biggest weakness in android is the dalvik vm. It is a huge memory hog. If we can use jit to compile the apps into native instructions then theoretically we shouldn't need the vm to run at all.
If this jit is run in mixed mode, if it is done correctly it should still help. You should see performance increases on the second time you run the app.

If this jit is run in mixed mode, if it is done correctly it should still help. You should see performance increases on the second time you run the app.
Click to expand...
Click to collapse
Umm... that's just not how JIT interpreters work.
Seriously -- JIT compilers don't change the core data of the application at all; they just translate bytecode into machinecode within the runtime environment in order to speed up the execution of frequently-encountered "strings" of code within the application as they are encountered.
Seriously: try this link [ http://psyco.sourceforge.net/doc.html#how-does-it-work ] to get a better understanding of why what you just suggested displays a bit of ignorance regarding the topic-at-hand.

A bit of ignorance is a compliment. Like I said I have not done any java work for a long time. What I don't understand about jit the way it is done, is why not go all the way and generate the native code similar to the odex files, and just by pass the vm all together. If they are going to the trouble of compiling byte code into native instructions anyway.. why not just do it once and get it over with instead of compiling it over again and again... for short running tasks like most apps on android, it may very well be a perf hinderance.
IConrad01 said:
Umm... that's just not how JIT interpreters work.
Seriously -- JIT compilers don't change the core data of the application at all; they just translate bytecode into machinecode within the runtime environment in order to speed up the execution of frequently-encountered "strings" of code within the application as they are encountered.
Seriously: try this link [ http://psyco.sourceforge.net/doc.html#how-does-it-work ] to get a better understanding of why what you just suggested displays a bit of ignorance regarding the topic-at-hand.
Click to expand...
Click to collapse

why not just do it once and get it over with instead of compiling it over again and again... for short running tasks like most apps on android, it may very well be a perf hinderance.
Click to expand...
Click to collapse
Well, I can think of a few reasons.
1) High-level programming languages are just plain easier to write for. Python, for example, uses an interpreter (VM) as well -- though you can compile it once and be done with it. High-level languages, as such, typically don't compile well because of the lack of "symmetry" that you get between higher-level languages and actual machine code. (Remember, my friend, the The Story of Mel )
2) JIT compilation in interpreters get you //near// compiled performance from non-compiled code. In other words; you write the program to the VM once. The VM then gets compiled one time for each platform, (Remember; despite being essentially the same hardware the Dream is somehow two different boards each of which would require a separate compile... :/) and this will only get worse over time. Now, the programmer doesn't have to specifically call up devices based on the platform but rather on the VM. He doesn't have to re-compile for each CPU/integrated-board circuit. You don't have to store, for example, one version of an app for Dreams/MT3G's, one for Heroes, one for Droids... and down the road, one for the MIPS chips, etc... Saves massively on storage considerations for centralized distribution repositories like the Market itself is.
3) VMs can be functionally isolated, preventing most forms of malicious program code escalation. Sandboxing programs is far easier when those programs are running in their own VMs. Each program/task is initiated within its own VM, which makes initialization and garbage-cleanup rather simple. For such an open-to-communications platform as a mobile phone, that can only be a good thing. Natively compiled code typically doesn't play so well with such sandboxing.
Those are just the thoughts off of the top of my head. I feel it important to note that IANAP.

I'm trying the libdvm.so cyanogen posted on my 32A magic (288MB of RAM) and so far it's all working well, and it seems much faster

Using 4.2.5 on 32A Magic with 4.2.4 Radix Kernel with New JIT Based libjvm.so
Everything Works Well and Never had any Force Close but is that 4.2.4 Kernel from Radix actually uses JIT.
@cyanogen 32A have 288 MB ram i can test JIT based Dalvim if you want me to test it

Ok, I integrated this lib with Cyan 4.2.5. Running comp-cache and Ram hack, 16GB class 2 SD.
Initial impression (based on 20 minutes of playing);
No change in OS speed. No crashes yet. Apps (especially game emulators) have a noticeable increase in speed. I have no technical information to back up my claims, nor do I have the possibility of an ABX comparison. Sorry.

Thanks for the explanation, I buy #3 as far as security is concerned, we all know those virus taking advantage of overflow instructions in windows. But As for #2 I don't mean to have developers compile the byte compile to native, but have the vm on our phone compile it on first run and save the native instructions in file similar to how it generates the dex files on first run. This way it'll not have to recompile every time it runs. I just wish there is a way to avoid the dalvik-vm.
I irks me how much memory the dalvik-vm hogs up. A simple battery widget takes 12-16mb of memory.. It has a few pics and bytecode that simply goes to the system driver go get a number. I mean the whole ext3 filesystem driver uses less memory. Same with those widgets for task killing, they take up well over 10 mbs, which kind of defeats the whole purpose. I could write a simple tiny script that uses kill and do the same job without taking up 10m+ in the background.
We all here complain about our hardware, but I feel like these are more of software problems. anyways, that's just my rant... i hope the memory issues in vm gets better in later release.
IConrad01 said:
Well, I can think of a few reasons.
1) High-level programming languages are just plain easier to write for. Python, for example, uses an interpreter (VM) as well -- though you can compile it once and be done with it. High-level languages, as such, typically don't compile well because of the lack of "symmetry" that you get between higher-level languages and actual machine code. (Remember, my friend, the The Story of Mel )
2) JIT compilation in interpreters get you //near// compiled performance from non-compiled code. In other words; you write the program to the VM once. The VM then gets compiled one time for each platform, (Remember; despite being essentially the same hardware the Dream is somehow two different boards each of which would require a separate compile... :/) and this will only get worse over time. Now, the programmer doesn't have to specifically call up devices based on the platform but rather on the VM. He doesn't have to re-compile for each CPU/integrated-board circuit. You don't have to store, for example, one version of an app for Dreams/MT3G's, one for Heroes, one for Droids... and down the road, one for the MIPS chips, etc... Saves massively on storage considerations for centralized distribution repositories like the Market itself is.
3) VMs can be functionally isolated, preventing most forms of malicious program code escalation. Sandboxing programs is far easier when those programs are running in their own VMs. Each program/task is initiated within its own VM, which makes initialization and garbage-cleanup rather simple. For such an open-to-communications platform as a mobile phone, that can only be a good thing. Natively compiled code typically doesn't play so well with such sandboxing.
Those are just the thoughts off of the top of my head. I feel it important to note that IANAP.
Click to expand...
Click to collapse

cyanogen said:
I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so
Click to expand...
Click to collapse
Could anyone upload that again? The link is dead.

(update) dalvik turbo

http://www.myriadgroup.com/Media-Centre/News/Myriad-Group-and-MIPS-Technologies-Accelerate-Android-Application-Performance-up-to-5x.aspx
Availability
An evaluation version of the optimized VM will be available free-of-charge through the Android on MIPS community at www.mipsandroid.org as of August 1, 2010. For information on commercia distribution, contact Myriad Group.........

G1 ist actually not MIPS-Based device...

nsa666 said:
G1 ist actually not MIPS-Based device...
Click to expand...
Click to collapse
you sure?????????????????????

chrisgto4 said:
you sure?????????????????????
Click to expand...
Click to collapse
Positive. HTC DREAM is an ARM chip.
ARM != MIPS.
http://en.wikipedia.org/wiki/ARM_architecture
http://en.wikipedia.org/wiki/MIPS_architecture
They are basically competing architectures, entirely incompatible with each other.

And who wants to bet that its just JIT? Seems that the speedup they claim is practically the same as the JIT speedups claimed for android 2.2.
Also note: This organization is apparently NOT contributing anything back to AOSP -- they're just LEECHES! I suggest NOT SUPPORTING THEM AT ALL, even by testing their trash!

lbcoder said:
And who wants to bet that its just JIT? Seems that the speedup they claim is practically the same as the JIT speedups claimed for android 2.2.
Also note: This organization is apparently NOT contributing anything back to AOSP -- they're just LEECHES! I suggest NOT SUPPORTING THEM AT ALL, even by testing their trash!
Click to expand...
Click to collapse
Yeah, looks like a solicitation for distributors/investors. I would say this does not belong in Development, rather Android Software.

hmmmmmmmm. one more. question. what about the sapphire they have it running on in the demo video????
Sent from my Htcclay's SuperBad 3G using the XDA mobile application powered by Tapatalk

This was announced a while back before word of Google's JIT implementation. My guess is they want any press they can at this point, cause they're screwed after Froyo.
http://www.engadget.com/2010/02/17/myriad-dalvik-turbo-hands-on-android-apps-just-got-fast/

Myriad DalvikTurbo Binary Release for MIPS Android
Copyright 2011 Myriad Group AG. All Rights Reserved.
Last updated 2011-08-01
1 Introduction
1.1 DalvikTurbo
DalvikTurbo is Myriad's Dynamic Adaptive Compiler that dynamically selects
methods that are being executed frequently and compiles them. It is optimised
for simplicity and speed of compilation. Future invokes of the method will use
the compiled version and so benefit from the optimisations that the compiler
performs.
DalvikTurbo replaces the Google JIT in the Dalvik VM and is supplied as a fully
compatible replacement libdvm.so library.

The product overview says it supports ARM and MIPS devices :
Dalvik Turbo is a drop-in alternative for the original
Virtual Machine, offering a seamless replacement
that integrates directly into Android. Dalvik Turbo
supports the full range of ARM based processors
and MIPS Architectures.
Click to expand...
Click to collapse

Opkg on Android (or, make your own app store)

I posted in a different thread because it had similar content, but I figured I'd stop hijacking someone else's thread.
This is quite rough at the moment, but I have compiled a statically-linked version of Opkg for armv5tel-compatible devices, which I believe includes most Android phones. So far, I have successfully installed packages from files and from repositories, and I'm still evaluating the possibility of using Opkg to maintain all sorts of things on the phone.
Opkg is a package manager not unlike Debian's dpkg/apt system. With this tool, we could easily install software from third-party repositories and keep it up-to-date. For now, there are some barriers against deploying Opkg on phones. Firstly, there are almost no Opkg packages for Android phones (though I do have some in my personal repository). Secondly, there is no GUI, and everyone loves shiny graphics. But I think these problems can be overcome, since Opkg is a pretty awesome little tool.
I posted this for a couple of reasons (other than to promote the use of Opkg on Android). So far, I know it works with HTC Dream and HTC Hero on CyanogenMod, but I'd like to know how it works on other types of phones if possible. I'd also like ideas and suggestions. Are there any Android developers or end-users out there who are interested in trying Opkg?
Anyhow, here're the links: [more info] [how to make a package] [how to make a repository] [downloads]
If you want to build it yourself, go ahead and knock yourself out ;p
Thanks for your time!

Hey, great to see im not the only person who had this idea. Thanks you for the links. I will try that on my Tattoo and play around with it.

I'm glad to see that you've figured out what was wrong, and I hope you managed to get it working! Nevertheless, someone asked how to configure the preferred architectures, so here's my /cache/etc/opkg/arch.conf file:
Code:
arch all 1
arch any 6
arch noarch 11
arch arm 16
arch armel 21
arch apk 26
arch apkmdpi 31
Now, a hdpi device might have:
Code:
arch all 1
arch any 6
arch noarch 11
arch arm 16
arch armel 21
arch apk 26
arch apkmdpi 31
arch apkhdpi 36
Of course, these architecture names should be standardized. And while we're at it, we should also come up with sensible paths for configuration files and such; I don't imagine sticking everything in /cache would be a good long-term solution.

Yes its working fine.
I would prefer to put the config under /data/local/etc/opkg it should be save there.
There is allready a tmp folder. So tmp goes like this: /data/local/tmp and for usr: /data/local/usr/opkg
Sections for apk-apps:
Code:
vendor/google
vendor/htc
vendor/acer
vendor/...
But we could also adapt the debian sections, so we havent to figure out this, and its already its well documented.
EDIT2:
According to the open moko wiki, there is only a feed.conf for the repository and a arch.conf for the architecture...
http://wiki.openmoko.org/wiki/Opkg/Documentation#configuration_files

I like your idea and would like to try this, but right now I have a Garmin Asus M10 which is on Win 6.5, I would like to install android on this. I understand that A10 has android and it is compatible with M10. Any help in getting an android ROM would be appricitated. Once I have the android loaded I would love to use Opkg.
Regards,
Rajesh

search for a10 update in google. its there. i think u can get rom from there.

Why so few Android apps compiled for MIPS?

This is something that is driving me crazy, shouldt be MIPS Android SDK and NDK be compatible with any source maded for the ARM version?
First thing i noticed with this Ainol Novo 7 Basic was that, the small amount of compatible apps, none of the better apps are compatible.
No: Netflix, Skype, Android Terminal Emulator, MX video Player, Chainfire3D, any mame32/nes emu, a working barcode reader, connectbot, adosbox/qemu, opera or any other browser. and the list goes on.
I wonder why, i trought devs will want the larger amount of users as posible.
For the record, i just got Android Terminal Emulator working in my Novo 7 Basic, i had to:
1) Download Term source code
2) Download MIPS Android SDK, NDK, Apache ANT, Eclipse with ADL, cgywin (to compile NDK libs)
3) Import Term project to eclipse
4) change the target build to android-12
5) change Aplication.mk to "APP_ABI := mips mips-r2"
6) build ndk-libs for the app
7) build the project with eclipse
And i know nothing about programing for android, just c/c++

Best guess that anyone will probably give you is that the majority of devices out there running Android are ARM based, but as that changes, the number and quality of available apps should improve.
There is a HUGE obstacle to overcome however. Not many people are going to buy a device today based on what might run on it months from now, especially when there are devices out there that will run it now, and many of those that do purchase a MIPS based device consider it a mistake and end up returning it.

It is not possible to offer two different version on the market and i don't think it is possible to restrict the apps to a specific architecture.
Are the number of MIPS devices really rising? The android market doesn't really seem to be ready for that. It would mean even more app versions devs would have to consider.
Which apps work and which don't?
Maybe those using native code, compiled with NDK don't work, as those routines are compiled specificly for ARM.
Don't take my word for it though, just some thoughts.

its not possible to get 2 different versions on the market.

Rumor has it that the problem is frequently a development oversight and that it's related to omitting some important MIPS related files from the package build.
I imagine that it can also be related to poor programming practices and also programming for optimized code.
~~ Sent from my Velocity Micro Cruz PT701/T105 via Tapatalk ~~

As far as I know, Market supports device specific apk's nowadays, which would make it possible to have an mips apk...
http://developer.android.com/guide/market/publishing/multiple-apks.html
Altough the proccess is not trivial, it is not that difficult either, just minor changes to the manifest and filter the apk for Native Platform...
Also, it would be possible to compile it for all devices that the current NDK supports, by using the latest revision of NDK (as of November 2011):
http://developer.android.com/sdk/ndk/index.html#overview
You just need to add:
APP_ABI := all
Click to expand...
Click to collapse
to the makefile and it should now be compatible with all processor architectures that NDK supports....
So, now there are means to easily support different processor architectures, but, don't expect quick adoption of it, as, unfortunately, this depends entirely upon developer will to change some of its project settings and/or publishing way (it is entirely possible, now, to have a single apk for all platforms)...
Unfortunately, right now, and I would dare to say, in the next 6 - 8 Months, I would not expect this to change much... Altough the official NDK has support for multiple devices, it still doesn't incorporate the MIPS abi, which is not official, and thus, it is not possible to declare that an APK for a native MIPS device as well...
Hopefully MIPS devices will grab a nice piece of the Android devices and then "force" Google to officially support those devices. I believe that it is possible to grab the latest unoficial NDK and use it with APP_ABI all and publish it to the Market, but, as of today, is mostly something recent and that few (if any) developers support (remember, this possibility came with November's NDK, I'm not even sure if MIPs NDK is already up to date with Google's November NDK), so, I would dare to say, MIPS devices are not in a good position right now (even x86 devices, which have official support, are not...).

I have a MIPS based tablet named "MIDI Japan MD-785IP" that is quite nice but is making me sad with the lack of some softwares and in special, lack of ROMs to it. Apparently I am the only person in the internet that have one

shivansps said:
This is something that is driving me crazy, shouldt be MIPS Android SDK and NDK be compatible with any source maded for the ARM version?
...
For the record, i just got Android Terminal Emulator working in my Novo 7 Basic, i had to:
...
Click to expand...
Click to collapse
Hello,
Have you shared that MIPS compatible Android Terminal Emulator?
Thank you

Sure... and here is connectbot too.
Ive attemped to recompile adosbox too but the source code and makefiles are just a big mess and no documentation provided.
And that is another problem, poor documentation in open source projects.
BTW, Market has to have some way to know if a app is for arm or mips, since market on basic only shows up compatible apps.
Also, its no enoght to just incluide the "mips" folder along with "armabi" with all mips compiled .so files inside the libs folder? because is that all what it takes, unless the app is using binaries.
And im agree that google has most of the fault for not incluiding mips supprt in his NDK, the mips one can compile for both.

I wonder what will happen when intel medfield will came out...

I am in an even worse position - I bought 2 NOVO7Paladins - one for the g/f. I had to get one for myself, because I know I will be 1st line support
So, I have a MIPS cpu (with reduced software availability) and also ICS which further reduces app compatibility.
Apps which I consider essential (Samba server, VNC Server, Angry Birds Seasons....) are not available, so l'm currently installing eclipse, JDK, SDK, NDK on a linux box to try to rebuild stuff - it has been many years since I last had to get my hands dirty with code.
I know I have a steep learning curve ahead, but I'm sure it will be many months before there is a significant increase in app availability. I understand though, that if developers have written native code for ARM, they won't be in a hurry to port that to a minority cpu. It is way easier for new apps to be built with different architectures in mind.
Thanks Shivansps, I had been looking for a terminal - I had given up and was trying to get telnet working - a last restort. It was either that or carry a laptop around with me to use ADB
Now, all I need is to get the MIPS ABI to appear in Eclipse AVD setup... (oh, and learn how to code for android )

i dont use Eclipse or SDK myselft any longer, what i do is just recompile shared libs with mips NDK and include the new "mips" folder intro the libs folder of the original .apk file, then re-sign the apk with one click signer.

MapsWithMe for MIPS and x86
maersi said:
I am in an even worse position - I bought 2 NOVO7Paladins - one for the g/f. I had to get one for myself, because I know I will be 1st line support
Click to expand...
Click to collapse
Hi! Do you still have MIPS android device?
Would you please test MapsWithMe on it? It's offline world maps based on OpenStreetMap.
We've built apk for mips and x86 architectures but doesn't have any devices to check if it works.
Apk is available here: dl.dropbox.com/u/24013616/MapsWithMe-203-mips-x86-120502.apk
Cheers,
Alex Zolotarev
MapsWithMe Team

AlexanderZolotarev said:
Hi! Do you still have MIPS android device?
Would you please test MapsWithMe on it? It's offline world maps based on OpenStreetMap.
We've built apk for mips and x86 architectures but doesn't have any devices to check if it works.
Apk is available here: dl.dropbox.com/u/24013616/MapsWithMe-203-mips-x86-120502.apk
Cheers,
Alex Zolotarev
MapsWithMe Team
Click to expand...
Click to collapse
Yes, I still have a mips tablet, but it hasn't gps. Do you want me to check it?
Enviado desde mi ThL W8 usando Tapatalk 2

App requests?

I know this is a potentially dangerous post, but I'm looking for suggestions for things to port. I make no promises that I'll be willing/able to port any suggested software.
Some ground rules before you hit 'reply'
1) Don't ask for Chrome. I won't port it. Period.
2) The source code must be available and not have any _obvious_ specific ties to non-open source code. Eg: some proprietary or closed source library which it depends on.
3) Code must be in C or C++ (I can deal with porting some assembly if needed)
4) Project must be of a _reasonable_ size for 1 person. Honestly, I do this on my own and in my spare time. Some apps can be just massively overwhelming to port. That being sad, sometimes the big ones are also easy.... so use your own judgement here.
5) Tell me why you want it ported. Whats your "use case".
6) Drivers aren't out of the question, but they generally take significantly more work.
Feel free to +1 others suggestions.
Ok.. <puts on protective gear>.. fire away!
Cheers!

Thanks for all your awesome work.
While this isn't an app, I think that the kexec kernel-mode driver idea that was tossed around earlier would be waay more useful than an individual app. Every time it was brought up somebody said "Oh, that won't be much work." And then nobody did anything :-/
So, I'm hugely grateful for the time you put in here, but I think I'd be even huger-ly grateful-er if you opened the door to other OSs.
Sent from my SCH-I535 using xda app-developers app

What would be good is:
http://ekiga.org/download-ekiga-binaries-or-source-code
But I'm pretty sure it uses some libraries not avail

I wish XNA could run on Windows RT. It'd be funny to see Terraria and Magicka on Windows RT...
Firefox would be nice, but without a Thumb-2 JITter, it's not worth it.

Would be nice to have InSSIDer. I use it a lot on my laptop, rather leave it at home.
https://github.com/metageek-llc/inSSIDer-2

Myriachan said:
I wish XNA could run on Windows RT. It'd be funny to see Terraria and Magicka on Windows RT...
Firefox would be nice, but without a Thumb-2 JITter, it's not worth it.
Click to expand...
Click to collapse
I would say to take a look at monogame. It can actually build microsoft store apps including ARM support, so coercing it into functioning on the windows desktop may be possible. Otherwise it might end up being a rule 4 :/
There are hacks out there to run terraria on MonoGame instead of XNA, most of them pretty complete but sometimes have the odd graphical glitch. A full source port to MonoGame would be far more reliable, and actually very simple, but sadly its closed source (although not obfuscated).
One of the supposedly more reliable ones: http://www.terrariaonline.com/threads/wip-monogame-terraria-terraria-for-linux.72997/
Isn't rule one covered by rule four?

SixSixSevenSeven said:
Isn't rule one covered by rule four?
Click to expand...
Click to collapse
No.
People can have bad judgement.. so I'm making an explicit point about Chrome.

Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one

Just found one. TCPMP, this player worked great during the PocketPC/Windows Mobile era. It moved from open source to a commercial different version which is closed source but I believe the link below has the source.
http://www.hpcfactor.com/downloads/tcpmp/
This would bring about a player that supports MKV playback.

lambstone said:
Just found one. TCPMP, this player worked great during the PocketPC/Windows Mobile era. It moved from open source to a commercial different version which is closed source but I believe the link below has the source.
http://www.hpcfactor.com/downloads/tcpmp/
This would bring about a player that supports MKV playback.
Click to expand...
Click to collapse
There is no source code downloadable from that site. All the links are non-existent. Please post the source code if you have it.
Cheers!

bfosterjr said:
There is no source code downloadable from that site. All the links are non-existent. Please post the source code if you have it.
Cheers!
Click to expand...
Click to collapse
Does this help http://code.google.com/p/tcpmp-revive/source/browse/#svn/trunk

mr djé said:
Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=2101891

mr djé said:
Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one
Click to expand...
Click to collapse
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.

bigsnack said:
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.
Click to expand...
Click to collapse
Safari is not open source so cannot be ported.
Chrome is a rule 4 - or in other words is too much effort for 1 man to do in a reasonable time frame.
Firefox is also a rule 4, plus its a ***** to get it to compile properly under microsoft tools apparently, plus its javascript engine is raw ARMv7 JIT whereas windows RT bugs with that and would require a THUMB2 JIT. Chrome also would have javascript issues, although in chrome you can have an interpreted javascript engine I think which would just be hideously slow in comparison.
Opera - Closed source.
The list goes on unfortunately. Browsers are complex creatures. Most will come under rule 4 though.

bigsnack said:
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.
Click to expand...
Click to collapse
What the hell are you doing to get all these crashes? I have yet to have IE crash on 8 or 8.1 on RT in desktop or metro.

My only suggestion would be a gui SFTP client. This is probably the one utility I am currently missing on my Surface RT (I use ssh to remote into Linux systems both for work and personal use, point #5). To clarify, I do use the psftp client in the putty suit, and that works well enough, just takes a bit more time and effort than something like winscp. I can continue to use this if an gui alternative is not feasible.
I recall someone requesting winscp at some point in the past, so I searched around this forum and I did find a couple of people that took a stab at it, but with no results, and I haven't found a clear explanation on what the hang up was. Looking at the readme winscp appears to be written in c++ at least (point #3):
To build WinSCP you need:
- Embarcadero C++ Builder XE2 Professional.
- Copy MFC source code from Borland C++ Builder 6 Professional and
build its Unicode version (see readme_mfc.txt).
- nasm from http://www.nasm.us/
- To build 64-bit version of drag&drop shell extension, you need
Windows Platform SDK:
http://msdn.microsoft.com/en-us/windows/bb980924
Click to expand...
Click to collapse
I am unsure if the aforementioned Windows Platform SDK is available for Windows RT, or if it is even needed since Windows RT is not 64-bit.
Is nasm the problem? It looks to be an x86/x64 assembler... which of course wouldn't work on ARM... unless I just don't get what an assembler is...
Not being much of a coder I also don't know if one can import a Borland C++ project into Visual Studio, so maybe that is also a problem too.
So I guess I'm not sure on a lot of the points on the ground rules list...

domboy said:
My only suggestion would be a gui SFTP client. This is probably the one utility I am currently missing on my Surface RT (I use ssh to remote into Linux systems both for work and personal use, point #5). To clarify, I do use the psftp client in the putty suit, and that works well enough, just takes a bit more time and effort than something like winscp. I can continue to use this if an gui alternative is not feasible.
I recall someone requesting winscp at some point in the past, so I searched around this forum and I did find a couple of people that took a stab at it, but with no results, and I haven't found a clear explanation on what the hang up was. Looking at the readme winscp appears to be written in c++ at least (point #3):
I am unsure if the aforementioned Windows Platform SDK is available for Windows RT, or if it is even needed since Windows RT is not 64-bit.
Is nasm the problem? It looks to be an x86/x64 assembler... which of course wouldn't work on ARM... unless I just don't get what an assembler is...
Not being much of a coder I also don't know if one can import a Borland C++ project into Visual Studio, so maybe that is also a problem too.
So I guess I'm not sure on a lot of the points on the ground rules list...
Click to expand...
Click to collapse
Borland C++ is an alternative set of 3rd part C++ tools. Would take a bit of work to get a borland project to compile it under microsoft tools.
Nasm is an x86/x64 assembler yes. Assembly language is pretty much the lowest level of programming possible before writing in raw hex or binary. It is *HIGHLY* CPU dependent. Specifically the set of commands available in assembly is the plain text form of the exact instruction set the CPU has available which for x86 is different from ARM. The fact that nasm is required means that the project will have assembly in it, therefore an RT port will not be undertaken (one of the rules in the OP).
Sorry man, its proprietary tools and parts of it are unportable anyway. Doesnt mean another SFTP client can't be ported, just this one.

Here's my wishlist. I've poked at some of them, but I don't really have time to finish any of them.
WinPCap - Iirc, the biggest issue was that it was written targeting an older version of NDIS. The usecase would be to provide network support for BOCHS.
QEmu - There's a build of QEmu that builds on MSVC called WinQEmu, but it's dynarec recompiles to x86 only. I believe the official QEmu repo doesn't support MSVC, and I don't know if it can recompile to THUMB-2.
A good IRC client - X-Chat and mIRC run poorly under the emulator, and the few .net clients I've tried are meh. X-Chat has too many GCC-specific requirements, and mIRC isn't open source, I just want a good IRC client.
An X Server - I've been unable to find an X server that builds with MSVC, or anything short of Cygwin for that matter, but I'd love to have one.

Calibre is a good eBook manager I think this is the correct source code https://code.launchpad.net/calibre
I'm not good with this source code stuff so if its to much you dont need to make a port but if you can it would be appreciated thanks
Sent from my SGH-M919 using Tapatalk 4

cx1 said:
What the hell are you doing to get all these crashes? I have yet to have IE crash on 8 or 8.1 on RT in desktop or metro.
Click to expand...
Click to collapse
Browsing news sites and/or using Spotify.