Related
Hi folks
Recenty I got the Windows XP Embedded kit, and I was really satisfied and surprised with the performance of the directly built system on an old machine like a P1 @ 200 MHz with 64 MB of RAM, without a hard disk.
The main goal would be to run truly win32 apps on mobile devices, to give better functionality and compatibility.
Yet the builder supports x86 architecture only, but cannot be a big problem to port it to ARM pocessors.
What might be difficult are these things:
-Getting win32 drivers for built-in devices (ex. integrated SDIO/USB WLAN, BT adapter, touchscreen, and sound devices, and apps for them!)
-Saving user data on turning off (Ebmedded systems are designed for a workstation, like a cash register: prebuilt apps, and nothing more comfort ) like WM200x
If anybody has any suggestion are to get a warm welcome
bye
Yet the builder supports x86 architecture only, but cannot be a big problem to port it to ARM pocessors.
Click to expand...
Click to collapse
Are you kidding me?
This would mean reverse engineering and recompiling every binary in the OS.
Do you have any idea how many hours something like that would take?
yup, you're right, but in theory it's possibe. I've seen a running DOS on a Microchip micro-controller, or for example the Atmel STK 1000 is Linux based, also seen an mPlayer app operational on the demo board at the college.
as you see, i'm not an experienced programmer, but i'm not afraid to ask
Yeah, the basic low-level binaries must be recompiled, and once it's ok, it might be usable with regular win32 apps, until you run an old DOS app, wich directly access the hardware.
A few years ago i was able to port Z80 software to 8086, and it wasn't easy.
I don't really know these things, just want to see opinions, possibilities, and suggestions.
exe files are binarys which are instructions directly for the cpu
it's not parsed by the operating system
so compiling the os is not enough every application needs to be recompiled too
The programs you mentioned have source available in one way or another (since DOS is very old there are clones, like freeDOS).
If you have the full source for an app and the right compiler, porting it to another CPU is feasible.
But, this is not the case with embedded XP. Getting the full source is impossible which means most of the system will have to be rewritten from scratch.
Just look at the Wine project to see what it takes, and they "have it easy" - they are just trying to simulate the APIs not change processor architecture. (Lets make it clear - ARM instruction set is very different from x86).
And as Rudegar said it will not let you run any program that has not been specially compiled for ARM CPU.
I know it sounds like we are trying to kill you idea here but its nothing personal, unfortunately it just isn't feasible. We would all like to be able to run desktop apps on our devices, but simply having embedded XP on them would not accomplish that. Also while many old DOS apps can be run using various emulators like pocketDOS, almost all Win32 apps take more resources than our little gadgets can offer.
I am fairly sure though that in 5 -10 years that problem will be fixed.
<_< man hours or not, reveng'ing this will have a bigger impact than just winDOS Mobile devices. Desktops have a use for this, definitely (because the Vista-Only crap is starting to hit the market). Too bad they don't provide assembly in programming classes anymore, obviously because they don't want anyone else to reverse engineer anything and spoil their foisting fun. <_<
In any case, IIRC XP Embedded is missing the install/uninstall engine, so you can't customize it after it's flashed onto the board. This isn't quite a good start - XPLite or 98Lite are better for reverse engineering from scratch (but they're too powerful for mobile devices).
The other alternative is porting ReactOS, which is a reimplementation of W2K. Those guys are "having a lot of fun" getting things to work, tho. <_<
Maybye Windows CE6 yes, but Windows XP Embedded no, because they must run at 686-AT/X platform IMB. Sorry of my English
linux would be a path
with most linux programs you can compile them yourself
using good old
./configure
make
make install
of cause gui programs could have issues displaying correct
on such a small screen
You MIGHT be able to pull it off by installing a minimal (very!) WinMo firmware and then have it autorun Bochs, which is known to be able to run the PC version of XP.. A customised, thinned-down XPe image should run fine under Bochs.
--W5i2
I think here is the right place to ask
Do u know/is there any C/C++ IDE that can actually run on WM?
I do not mean writing apps for WM. I mean writing, compiling (and y not debugging) programms directly on the PDA.
And generally is there such an IDE for any other programming language?
thx in advance
there is some for c# .net
and pocketVI support some c not to compile to native code or a real IDe though
I don't even think the pocket pc is powerful enough (yet) to handle the task of compiling software (unless you get a real os on there like linux).
I dont know if this is what you are looking for, but you can try Basic4PPC
I've tried it and I love'd it!
Rudegar said:
there is some for c# .net
and pocketVI support some c not to compile to native code or a real IDe though
Click to expand...
Click to collapse
yes i've seen that! i guess u r talking about http://www.geocities.com/hrowson/wm5_software/index.htm
just wondering if there are similar IDEs for other langs, like C, C++
Steven855 said:
I don't even think the pocket pc is powerful enough (yet) to handle the task of compiling software (unless you get a real os on there like linux).
Click to expand...
Click to collapse
hm.. i do not think that compiling is such an intensive task.. Well if u have like 5000 lines on ur windows mobile sure will take long..
But generally testing smal progs etc would be fine i think
Compiling is not something that came out with along with the fast CPUs!
What is more, the HD has a pretty fast CPU (i think!). Still remember that my first desktop PC's CPU was around 500MHz (!)
fredamexis said:
I dont know if this is what you are looking for, but you can try Basic4PPC
I've tried it and I love'd it!
Click to expand...
Click to collapse
u can use it to write progs directly @ ur PDA? (withour PC)
thx i will check it anyway!
See this thread: http://forum.xda-developers.com/showthread.php?t=445396
The following will compile (I've tried them) on the phone:
PocketGCC (FREEWARE)
Pocket C# Combo (Everything you need to compile and write apps for WM-- FREEWARE)
However, they do have limitations.
I'm completely positive FPC can be made to run on ARM. I'd say the chances of getting Lazarus (*the* FPC IDE) to run on WM are 30% out-of-the-box, and 70% after a day of hacking
The real question is... WHYYYY!?!?!?!?!?! would you want to?
LiKBeAsT said:
hm.. i do not think that compiling is such an intensive task.. Well if u have like 5000 lines on ur windows mobile sure will take long..
But generally testing smal progs etc would be fine i think
Click to expand...
Click to collapse
Dude seriously, compiling is a very CPU intensive task. 5000 lines? That is exactly one nothing in code terms.
Compiling is not something that came out with along with the fast CPUs!
What is more, the HD has a pretty fast CPU (i think!). Still remember that my first desktop PC's CPU was around 500MHz (!)
Click to expand...
Click to collapse
Oh please. My first desktop PC's CPU was 4.77mhz (with a turbo switch to 8!) and I'm considered a newbie in that area. While 500mhz is not necessarily slow, HTC hasn't produced a fast device in over two years. The HD is a horribly slow device.
Just a guess, but I'd say that the HD should still be fine for compiling. No floating point operations and no graphics.
Limitations to compilation probably memory size and memory speed, more than anything else? This will be a particular problem for C++, especially if you're doing anything more than minimal templating.
And putting Linux on it won't suddenly make it much better at compiling things - very little of this will be reliant on the OS subsystem.
ajige said:
See this thread: http://forum.xda-developers.com/showthread.php?t=445396
The following will compile (I've tried them) on the phone:
PocketGCC (FREEWARE)
Pocket C# Combo (Everything you need to compile and write apps for WM-- FREEWARE)
However, they do have limitations.
Click to expand...
Click to collapse
yea checked that out but it also had many other stuff and i wasn't sure about what i was asking
Chainfire said:
I'm completely positive FPC can be made to run on ARM. I'd say the chances of getting Lazarus (*the* FPC IDE) to run on WM are 30% out-of-the-box, and 70% after a day of hacking
The real question is... WHYYYY!?!?!?!?!?! would you want to?
Click to expand...
Click to collapse
erm.. i guess for fun, testing small progs and keep in touch with the lang when away from PC
Chainfire said:
Dude seriously, compiling is a very CPU intensive task. 5000 lines? That is exactly one nothing in code terms.
Oh please. My first desktop PC's CPU was 4.77mhz (with a turbo switch to 8!) and I'm considered a newbie in that area. While 500mhz is not necessarily slow, HTC hasn't produced a fast device in over two years. The HD is a horribly slow device.
Click to expand...
Click to collapse
Well, obviously i ammuch more younger (going to 20!) So my first PC was turbo-machine
Anyway! i guess nobody is going to use PPC IDE for that big progs and of course yes. they will take hours to compile (i guess)
Fast is a bit subjective i think.. What do u mean horribly slow? in terms of CPU, response time etc?
Thx everyone for the input!
PPC is pretty fast. You feel it is slow just because it has too many bad designed apps slow it down (must have while(1000) {Sleep(1000)} inside! no joking, I did see it sometimes!) and it has lack of good graphic driver (or chipset) so your TF3D has to use software to simulate semi-transparent effects and support z-order by allocating large buffer and repeatedly copy them.
Try pocketdos (or bochs emulator), you can run a windows 3.1 on ppc.
Then you can use TC, or old version of VC++/VB/Delphi etc on windows 3.1/dos
Considering emulator running on a real machine usually ~100 times slower than virtual machine, and ARM processor is a RISC chipset usually faster than CISC, your PPC is much faster than a Pentium even some Pentium III computer.
You may not understand how RISC faster than CISC. a function call in x86 cpu usually like
PUSH param1
PUSH Param2
Call function1 ( which push IP and stack again)
and more PUSH inside the function1.
it involves a lot of memory operations. memory is out of CPU so it is low.
A function call in ARM cpu usually like
MOV R0, param1
MOV R1, param2
BL function1 (which set return address in a register)
It doesn't use memory at all. everything is done within processor.
Pentium and after that solve this bottle neck by adding cache. But your code may not in cache when switching context. RISC is naturally faster.
ARM in general can be fast. However in MSM7K devices it usually isn't. All floating point operations for example are done in software, not hardware - this is why a lot of stuff is slow (try for example a Samsung chipset based on ARM, they are much faster for a lot of things). Hardware floating point is an absolute must for any multimedia related thing, and can affect any multiplication or division (and similar) where your compiler does not know at design time whether it will be an integer operation or not.
Furthermore, TF3D is actually one of the few things on these devices that actually does use hardware graphics acceleration.
Even then, while I do agree that RISC in general can be faster than CISC , no compiler worth its salt will use a stack-based calling convention (at least for non-exported functions) unless explicitly specified to do so. Register based function calling exactly like you give for your ARM example is quite normal on x86 as well.
And yes, my old and rusty 500mhz Pentium laptop literally ran circles around any MSM7K.
As far as I known compiler or IDE almost doesn't need float pointer operations at all.
386SX or 486SX works well and fast with old version of VB and VC.
That was an example for why MSM7K was slow. Even if it isn't applicable to compiling, it's still a slow-ass chip
Meme IDE
you could try this...its not c# or c++ but very similar
Build with a drag and drop editor. Develop complex functions using the unique MemeScript. A language created to make elements simple and cohesive on any platform.
It is currently in beta release and at the moment you can develop for Android and WM. IOS will be included in the full release and Blackberry further down the line.
OH and its FREE
find out more or download and play with it at www.memeapps.com
joememe said:
you could try this...its not c# or c++ but very similar
Build with a drag and drop editor. Develop complex functions using the unique MemeScript. A language created to make elements simple and cohesive on any platform.
It is currently in beta release and at the moment you can develop for Android and WM. IOS will be included in the full release and Blackberry further down the line.
OH and its FREE
find out more or download and play with it at www.memeapps.com
http://www.memeapps.com/
Click to expand...
Click to collapse
it is worth to try after the running download. Thank's for the hint.
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
- No native support for x86 apps on ARM, nor ARM apps on x86. Only .NET apps would work in both worlds.
But it is possible to create an emulator similar to DosBox that would run native x86 programs on WoA and, for example, I'm currently working in this direction.
- Though existing C++ apps can be recompiled for ARM from sources, it is not a 100% working solution. Current VS11 contains a rather limited set of ARM libraries - no DirectX libs earlier than 11, no import libraries for NtDll.Dll and similar DLLs.
I don't have access to any WoA builds, so I can't check whether these features are completely removed from ARM, or those LIBs are just not present in current VS11 build. But at least now we can compile test apps for ARM and analyze the code (though we don't have where to execute them yet).
- Native WoA programs use THUMB2 instruction set (ARMv7 and above). Though ARM instruction set would be supported too.
- According to "Microsoft Portable Executable and Common Object File Format Specification v8.2" WoA machine type in PE files would be 0x1c4, and some new relocations types are added (for example IMAGE_REL_BASED_ARM_MOV32T = 7). IDA understands such EXE files, though complains on relocs.
- SEH is implemented in a different way than on x86 (similar to x64, google for RtlAddFunctionTable to get the idea).
- WoA is more secure by default. For example TPM can be rarely found on x86, but it would be required on ARM.
- Most of existing drivers are source-code compatible with ARM (of cause if not using x86-specific stuff). But ARM would never allow to load unsigned drivers (unlike x86 Win7/8).
- As platform is completely new - all ARM drivers would be added to windows update site to simplify our life. Some obsolete hardware like 1394 is not implemented at all, so there would not be so many drivers for ARM llike for x86.
- All binaries would be the same for all SoC providers.
- No "native" ARM VisualStudio - developer tools are x86 only.
WoA requirements from different sources:
- 10.1” display with 1366x768 min resolution (though smaller screens may be supported with reduced functionality)
- Volume Control, Windows, Rotation, Lock power buttons
- Dual core CPU with hardware accelerated GPU
- at least 1 Gb RAM
- min 16 Gb fixed storage
- 100mW idle power in standby
- there are rumors that there would be standart "Phone call API" ("Apollo" UI)
Does anyone have access to ARM WDK? It would definitely contain a complete set of import libraries and would provide lots of info on WoA internals in headers/documentation. Seems that Windows 8 WDK on MSDN does not have ARM tools
so your bottom line says: no w8 on arm (ever)?
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
The UEFI requirement is expected, and I doubt will be that much of a hurdle. UEFI is all open, and it should be pretty trivial to chainload a UEFI-compatible environment on top of the existing firmwares, provided that nvidia doesn't provide us with an implementation to start with, which I suspect they'll do.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two. A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Everything I could find relating to the TPM says that it's optional, but will be automatically utilized if available.
The rest is pretty inconsequental, at least to what I think most people here are interested in.
nvidia started a windows 8 development program for ARM (Clickey here), but I haven't seen anything else from it, has anyone else gotten anything?
mamaich said:
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
Click to expand...
Click to collapse
Actually they said it would continue to support BIOS for older devices.
See: Current machines dual-booting Windows 7 and Linux should be able to upgrade to Windows 8 without wiping out the Linux install. As Microsoft notes in the Building Windows 8 blog, “We will continue to support the legacy BIOS interface.” However, machines using UEFI instead of BIOS “will have significantly richer capabilities” including faster boot times and greater security. (from Arstechnica)
That's for x86. ARM was said to require UEFI. Besides, there is no real bios on Android tablets, at least not a common platform.
netham45 said:
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
Click to expand...
Click to collapse
I've got it in one of the "windows-on-arm" non-public documents dated the first half of this year. While UEFI,ACPI,TPM are an option for x86, they are required for ARM hosts.
So no custom WM8 bootloaders, drivers, patched kernel on ARM hosts (like "windows activators" do) until sign keys would be leaked or some backdoors would be found. Of cause this is good as this would make rootkit creation more difficult, and require device drivers signed by MS (so we'd get more stable OS) but I really don't think that this "protection" would last more than 1-2 months after WoA would be released.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two.
Click to expand...
Click to collapse
I'm already working on such tool. It emulates x86 instruction set with dosbox or bochs CPU emulation library (I'm using both of them for debugging purposes, while working on my own one that would be much more simple->faster), translates x86 WinAPI to "native" host WinAPI + emulates API that is not present or differently implemented on WoA. It is designed to be truly cross-platform, so just a recompilation + creating several thunks/stubs would be necessary when I'll get my hands to an ARM host running windows8.
Of cause programs that use heavy anti-debugging, self-modifying code, undocumented features and SEH tricks would not work. Currently it is rather far from being finished (I have to implement&debug WinAPI and COM thunks that cannot be automatically generated) but old games like "heroes of might and magic" are already working fine in a test environment.
A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Click to expand...
Click to collapse
Of cause I'm talking about "ultimate" VS11, as express is designed to target mostly .NET (though ARM compiler is present there too).
And WDK that it published on MSDN does not allow creation of ARM drivers. I'm currently in a process of renewing my company's MSDN subscription, so I can't prove that myself, but I've read that on OSR forums.
I am waiting to hack my iPad and put win8 on it
I would hope touchpad would be the next viable option. Hp could still make more and just dump W8 on it. Thanks all of you for working this thread. I will be reading your progress as it unfolds. Good Luck devs and if I can find anything you will be the first to know.
Sent from my mwp6985 / Trophy using XDA Windows Phone 7 App
Some information on Win8 "Apollo" is available. Apollo - is a name for a new "windows phone" OS from MS.
- Apollo is based on the same "desktop" code as Windows 8. No Windows CE at last!
- Apollo would provide the same user experience as old Windows Phone 7.x - Metro UI, People hub, builtin office apps, etc. Seems that software compatibility with WinPhone 7.x apps would be preserved, but this is just my own guess.
- All applications on Apollo are required to be signed, similar to Windows Phone 7.
- Device drivers can be written only by IHVs, MS and OEMs, not by ISVs. This would be a problem for antivirus vendors or tools like daemon-tools.
- There would be a "built-in" eMMC card with OS and vendor partitions, and maximum one SD card. eMMC supports NTFS, SD-card supports only FAT/exFAT.
Build-in eMMC would have C:\ drive letter, SD-card would be D:\ if present.
eMMC contains several partitions. Some of them would be made readonly during boot.
- Near Field Communication is built in.
- The same list of sensors as in WP7 Mango is supported.
- There would be BSOD like in a desktop OS
- Unproven, but it seems that only .NET ("Splash UI framework" and "Silverlight") APIs would be available to independent developers. So no native code again.
- Seems that x86 architecture is supported for Apollo too.
HTC HD2 might not be the fastest running device out there but it is undoubtedly the most popular Hardware platform vis-a-vis the no of OSes (Winmo,WP7,Android,meamo/meego(partially) and several desktop linux distros) supported. The basic aim of using one OS or the other is to optimize the utilization of system resources or in other words, to get maximum performance/usability from the given hardware in this case the HD2.Now to find the best performing custom ROM (why do we still call it a ROM, its not read only anymore )we can resort to certain benchmarks and tests to come up with the best performing ROM of a certain platform. But If I were to find out based on a certain basic parameters what is the OS that best utilises my HD2 (or any other phone for that matter) sadly I'd be at a loss. To my mind a good way of getting there would be a cross platform benchmark which could test all the platforms based on some basic parameters (suggested below) and give out the result, as to which OS performs the best on a given phone. I suggested HD2 because it can test most of the platforms supported by XDA (and I happen to own one)
Parameters
call connection delay
call Audio quality
SMS/MMS sending/recieving efficiency
UI fps
WIFI reception/connection reliability
camera/camcorder result and performance
audio/ video playback quality
RAW CPU/GPU performance
battery life for a diverse set of tasks
(the list might need expansion but these I think are the basics)
Now a seasoned dev can approach the problem in any way possible but here are my suggestions for a means to get there.
1. One option would be to base this benchmark/tests on a cross platform emulator which works on a wide variety of OSes.
2. Java is said to be platform independent so in theory it can be used.
3. Make all the tests to run in the Browser.
Another advantage of this would be that devs would know the limits of a particular hardware and can develop accordingly. As an example, when devs found out that the HD2 can capture 720p video on WP7 they started porting this ability to android as well.
Need expert and non expert opinion on the practicality of this.
s8isfi said:
HTC HD2 might not be the fastest running device out there but it is undoubtedly the most popular Hardware platform vis-a-vis the no of OSes (Winmo,WP7,Android,meamo/meego(partially) and several desktop linux distros) supported. The basic aim of using one OS or the other is to optimize the utilization of system resources or in other words, to get maximum performance/usability from the given hardware in this case the HD2.Now to find the best performing custom ROM (why do we still call it a ROM, its not read only anymore )we can resort to certain benchmarks and tests to come up with the best performing ROM of a certain platform. But If I were to find out based on a certain basic parameters what is the OS that best utilises my HD2 (or any other phone for that matter) sadly I'd be at a loss. To my mind a good way of getting there would be a cross platform benchmark which could test all the platforms based on some basic parameters (suggested below) and give out the result, as to which OS performs the best on a given phone. I suggested HD2 because it can test most of the platforms supported by XDA (and I happen to own one)
Parameters
call connection delay
call Audio quality
SMS/MMS sending/recieving efficiency
UI fps
WIFI reception/connection reliability
camera/camcorder result and performance
audio/ video playback quality
RAW CPU/GPU performance
battery life for a diverse set of tasks
(the list might need expansion but these I think are the basics)
Now a seasoned dev can approach the problem in any way possible but here are my suggestions for a means to get there.
1. One option would be to base this benchmark/tests on a cross platform emulator which works on a wide variety of OSes.
2. Java is said to be platform independent so in theory it can be used.
3. Make all the tests to run in the Browser.
Another advantage of this would be that devs would know the limits of a particular hardware and can develop accordingly. As an example, when devs found out that the HD2 can capture 720p video on WP7 they started porting this ability to android as well.
Need expert and non expert opinion on the practicality of this.
Click to expand...
Click to collapse
This idea has quite a few major flaws,
1) All platforms are designed a certain way (atleast in embedded systems where resources are scarce) and hence even though one platform might outperform the other, it might not have the features necessary or required by the user, ie. I "LOVE" WP7, the UI is fluid and the design is awesome, it works wonderfully however it being a recent addition to the market means that there aren't many apps and also due to the restrictive nature of wp which forces me to either dualboot or stay with android, Dualbooting has it's own flaws as battery is still very bad in sd android and WP7 so that leaves me no choice but to either go to WM6.5 or Android since the Linux Distros aren't targeted for a phone, even though they might work, there are flaws such as having to open terminal and executing scripts for smallest of the work like switching bluetooth on/off, and absence of audio even after ALSA modules for evo based msm kernel were out.
2) Raw performance means nothing, you aren't going to crunch numbers or perform scientific calculations on your phone, it doesn't matter if it's of no use, what you should be looking for instead is "Productivity"
3) Windows Mobile was an awesome platform with countless apps and functionality but it was just too old for the market, ie. Look at the difference in UI of WP7/Android to WM6.5
4) Java is NOT platform independent, it is just ported to enough places that the code you write will work on most of the machines, ie. Try executing java code on windows phone, also it is not the same libraries of java used through out, microsoft uses their inhouse developed java version while android interprets java code into dalvik byte code before execution, Linux favors opensource libraries which are known to be much slower than the ones provided by Sun. Neither is the browser same in all, you also have choice of browsers in platforms themselves and all of them are generally specialized for different tasks such as firefox for android can run html5 code and is said to be the most compliant browser but is way slower than the stock one or the Dolphin HD where as the stock browser or Dolphin are incapable of CSS3 transitions and most of the html5 content.
*you cannot measure "fps" in UI, everything is not rendered the way you are thinking it is, try switching on forced screen refresh through development tools on an android phone and see, most of the time you'll notice that most of the parts on the screen remain static and it's only the new components that are blit over the older parts in framebuffer.
There are a few more flaws but since i'm running out of time, ill stop here.
As for me, nand android (cyanogenmod nightlies) are the best, Doesn't lag in normal use, enough eye candy, good enough battery life and is quite stable and soon with the new DSP code we will have 720p recording on Android too.
Thanks for the detailed reply. What I understand is that there is way too much diversification for a the same code to run.
HI, I saw some apps on play store and WP market. I found that many apps on WP are smaller in size as compared to the same app on Android.
Examples:
Official Twitter app: By Twitter
Android : 6 MB
WP : 2 MB
Facebook app:
Android (official) : 13 MB
WP ( by Microsoft) : 4 MB
LinkedIn app (Official)
Android : 5MB
WP : < 1 MB
NY Times (Official)
Android : 2.3 MB
WP : 1 MB
Whatsapp : By Whatsapp
Android : 8 MB
WP : < 1 MB
Foursquare (Official)
Android: 10MB
WP: 5 MB
Angry Birds Star Wars
Android: 38 MB
WP : 20 MB
Angry Birds Space
Android : 36 MB
WP : 15 MB
Anyone viewing this thread, please post apps sizes if you also find same thing for any other app.
So, how do will explain this small app sizes on WP compared to Android.
Is WP OS more CODE efficient than Android
Does this efficiency contribute to smoothness of apps. Please share your thoughts.
As a developer, I can say for certain several things
1) Yes, the OS is way, way more "code efficient" than Android
2) The code is downloaded and compiled only once. I will not get into details as to why this is happening, but on Android, as far as I am aware, JIT occurs everytime you run the application.
Also, Visual Studio is able to create far smaller binaries when compared to Eclipse.
Bytecode(android+eclipse) tends to produce really large "binaries" while the IL(WP+VS) tends to create very effective "binaries".
My game, which contains around 100 graphical assets only eats around 5.53 MB of space. So yes, C#/C++/VB handle assets and binary size better than Java.
There's been some talk lately about porting Android to use C# instead of Java. Some tests were done as far as performance is concerned. Really interesting results
http://www.cnx-software.com/2012/05...-massive-performance-improvement-over-dalvik/
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
Then there is also the problem of hardware variety. Windows Phone basically runs on the same chipsets and only has a few supported resolutions, whereas on Android, there are great many chipsets, each with their own sets of hardware assets and many possible resolutions. Developers need to write more code to make sure their apps work fine on as many phones as possible.
mcosmin222 said:
As a developer, I can say for certain several things
1) Yes, the OS is way, way more "code efficient" than Android
2) The code is downloaded and compiled only once. I will not get into details as to why this is happening, but on Android, as far as I am aware, JIT occurs everytime you run the application.
Also, Visual Studio is able to create far smaller binaries when compared to Eclipse.
Bytecode(android+eclipse) tends to produce really large "binaries" while the IL(WP+VS) tends to create very effective "binaries".
My game, which contains around 100 graphical assets only eats around 5.53 MB of space. So yes, C#/C++/VB handle assets and binary size better than Java.
There's been some talk lately about porting Android to use C# instead of Java. Some tests were done as far as performance is concerned. Really interesting results
http://www.cnx-software.com/2012/05...-massive-performance-improvement-over-dalvik/
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
Then there is also the problem of hardware variety. Windows Phone basically runs on the same chipsets and only has a few supported resolutions, whereas on Android, there are great many chipsets, each with their own sets of hardware assets and many possible resolutions. Developers need to write more code to make sure their apps work fine on as many phones as possible.
Click to expand...
Click to collapse
Oh boy. Where to start.
Firstly, the WP OS is not more efficient than Android. Android consists of Java in the form of the Davlik virtual machine running on linux. In no way is this less efficient than C# running on the WP8 virtual machine on the NT kernel.
Bytecode is not Android + eclipse. Eclipse is an IDE, like visual studio. Bytecode is the compiled output from the Java compiler in the form of .class files. You can use any IDE (or none) to develop Android applications.
The size of a binary bears very little relation to it's efficiency. It all depends on the environment it runs under. For example, a single API call may, in one environment, relate to, say, 20 calls into some framework that is bundled with the app - therefore making the binary bigger. In another environment the single call may result in a single call into a function provided by the virtual machine. The end result is that roughly the same amount of code is executed. Also, part of the reason why Android binaries are larger is because they contained a cached version of the app for quicker startup.
Besides code, a binary may contain other artefacts, like graphic files or different resolutions, which will make the binary bigger.
The idea of using C# on android is absurd. C# is not supported on Linux (by Microsoft). There is, however, the mono open source version of C# (always guaranteed to be out of date) but the android libraries provided by Google are written in Java and there is no way they will use a proprietary language, like C#, as it will require the use of Microsoft technologies to run and that means they will have to pay Microsoft a license fee.
Why on earth would the leader in smartphone abandon their existing technologies to adopt one that will require a complete redevelopment of Android and, in addition, pay a license fee to Microsoft? Answer == they won't. Ever.
Dr.Paul said:
Oh boy. Where to start.
Firstly, the WP OS is not more efficient than Android. Android consists of Java in the form of the Davlik virtual machine running on linux. In no way is this less efficient than C# running on the WP8 virtual machine on the NT kernel.
Bytecode is not Android + eclipse. Eclipse is an IDE, like visual studio. Bytecode is the compiled output from the Java compiler in the form of .class files. You can use any IDE (or none) to develop Android applications.
The size of a binary bears very little relation to it's efficiency. It all depends on the environment it runs under. For example, a single API call may, in one environment, relate to, say, 20 calls into some framework that is bundled with the app - therefore making the binary bigger. In another environment the single call may result in a single call into a function provided by the virtual machine. The end result is that roughly the same amount of code is executed. Also, part of the reason why Android binaries are larger is because they contained a cached version of the app for quicker startup.
Besides code, a binary may contain other artefacts, like graphic files or different resolutions, which will make the binary bigger.
The idea of using C# on android is absurd. C# is not supported on Linux (by Microsoft). There is, however, the mono open source version of C# (always guaranteed to be out of date) but the android libraries provided by Google are written in Java and there is no way they will use a proprietary language, like C#, as it will require the use of Microsoft technologies to run and that means they will have to pay Microsoft a license fee.
Why on earth would the leader in smartphone abandon their existing technologies to adopt one that will require a complete redevelopment of Android and, in addition, pay a license fee to Microsoft? Answer == they won't. Ever.
Click to expand...
Click to collapse
Uhh...
Where do I start?
I know bytecode is NOT android+eclipse, I only mentioned the IDE and System, just as IL si not visual studio.
The size of the binary is influenced by how good the compiler is. Although it is not the only the only thing to take into consideration, the compiler does have a role in this.
C# on Linux/Android/Mac/iOS IS supported by Microsoft under the community promise license, so everybody can port C# and .NET to any system as long as they don't use this on windows, WITHOUT having to pay Microsoft anything... I suggest you get some documentation on what Mono and Dalvik are.
C# is just as open source as C on any platform apart from Windows.
As a matter of fact, porting Android to C# would benefit the platform greatly, as google has some issues with Oracle regarding the usage of Dalvik and Java on Android.
Oh, did I mention android has to code MORE due to variety of code...hmm...
No. You cannot judge the efficency of the compiler based on the resultant code size unless you are comparing like for like. You cannot compare two languages running on two different platforms like this and come to the conclusion that because the bytecode is smaller it must be more efficient.
I expect you are too young to remember the CISC vs. RISC debate some 20 or so years ago. RISC processors generated far more instructions than a CISC processors to perform the same operation, and hence had far larger binaries. However, RISC machines were far faster. So the complete opposite of what you are saying.
Different compilers may well generate different size binary files if one were to compare compilers compiling the same language. But again this does not mean the code in the smaller file will run quicker. Indeed it may actually run slower.
Code size is no indicator of efficiency.
As far as c sharp is concerned, only the language is free to use. None of the frameworks are. And Microsoft do not provide a c sharp compiler on any system besides windows.
There is not a chance in hell that Google will adopt it. If they were to change from java they will either use one of the languages they have developed or develop something new
I used the appropriate quotation marks when writing "code efficient", as it is a very broad term and comparisons over who is code efficient and who is not.
The way I understand it, a code efficient system is a system that has very high performance, such as windows phone, not that it has anything to do with size of binaries, but the OP asked if WP is a "code efficient" system, so i answered xD
.Net framework is also free to reverse engineer. You still have to pay for compilers however.
Interesting sidebit: in internal Google E-Mails that got published during the Oracle vs. Google trial over Java it was actually mentioned that using C# instead of Java would have been an option due to the fact that there are less licensing hassles attached to it's core library (which actually is standardized with ECMA) as compared to Java. They decided not to go that route as it would have taken a year to adapt Android and instead risk getting sued by Sun (which was later acquired by Oracle). So: yes, C# would have been just as good an option. Using something like Google Go wouldn't have simply because there was no developer community and it's a lot easier to get people working on your platform if they don't have to learn a new language first.
That aside: most likely the binary size isn't all that much relevant for how big the downloaded files are. And I won't even go into the fact that some of those Apps aren't written in Java on Android but use the NDK (at least Facebook and the Angry Birds games do on Android, most likeley the later do it on WP8 too).
So in the end it's most likely down to the embedded Audio and Graphics resources. As was already mentioned Android devices have to support a lot more resolutions which makes it likely that LowRes graphics are included as well to not tax slower devices with high-res graphics for no reason (given that you won't see the difference on LowRes displays). Another reason for this with regular Apps is that WP takes a chromeless-design-approach so you rarely have graphics included that serve as UI chrome.
Another reason might be that Microsoft put quite some effort into driving home the point that resources should not be included or used in a higher resolution than what they are intended to be displayed at. The reason was that it might have led to troubles with the memory-constrained Tango-devices which only have 256 MB of RAM. At least for high-profile developers that work together with Microsoft it's likely that those optimized their Apps for it.
Lastly and also already mentioned: third party libraries. Historically Microsoft has always packed a lot of functionality directly into it's system frameworks. So it's entirely possible that WP devs use third party libraries less often. Case in point: database functionality: many Android Apps use SQLite and include their own binaries for it. WP provides SQLServer CE which can simply be used by any App that needs it. This might change though as for W8/WP8-cross platform Apps Microsoft themselves suggest including SQLite given that there is no SQL CE Support for WinRT-Apps.
And for the finishing lines something on compilers and code size. Intels C++ compilers regularly produce bigger binaries because of optimization techniques like loop unrolling, etc. They also normally outperform competing compilers in performance benchmarks. But it's not that easy if you look not at a single App's performance but at the whole system. Having an App take up more memory means that other Apps will have to be terminated sooner to avoid an out-of-memory scenario and it is more taxing on the memory controller, which depending on the chipset used might lead to additional performance problems down the road (the Nvidia Tegra 3 is said to be severely limited by its memory controller). But especially with Managed Code like C# or Java the code size of the IL does not really mean too much in that regard as the code is compiled anyway before being executed. So the memory actually taken up during execution is a lot different from what gets downloaded.
A more interesting comparison though would be wether the WP8 compiled XAPs are smaller than their WP7 counterparts, given that WP8 does precompile the IL in the cloud. Might be interesting to see which of those is smaller.
Just did some comparisons on size of binaries between 7.5 and 8
1) XAP compiled for 7.5 is 5.53 MB
2) XAP compiled for 8 is 5.76 MB
Seems the 8 version is actually bigger, although not by much.
I love this thread!
Sent from my RaZr on MIUI.
I know about the comparison between Android and Windows Phone 8 from users who have made the switch.