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'm looking at developing a biomonitoring application, the setup to consist of a 24 bit ADC with an Atmel AVR microcontroller sending data via Bluetooth to the mobile phone for display. I don't have a large budget so am looking for freeware or something a lot cheaper than Visual Studio to develop the application to run under WM5/6. It has to be compiled due to the amount of processing needed.
I prefer to write in C/C++ . Pascal would be a 2nd choice then anything else except Basic.
For Windows development I use Borland C++ Builder and have used Delphi. On the embedded side I use Codevision AVR C compiler.
I'd appreciate recommendations for development software. TIA.
I got this C compiler to work a while ago (managed to recompile a few of my desktop PC SDL projects to ppc):
http://sourceforge.net/projects/wince-xcompile
[EDIT]
Sorry, ceGCC is what i was using, not xcompile:
http://cegcc.sourceforge.net/
[/EDIT]
It's free, but it's for linux (if you don't have linux, that might be a good reason to give it a try ). Also, the problem is that it doesn't have an IDE of its own, and no graphical interface editor.
There's also pgcc, allowing you to compile applications directly on your pocketPC, but i wasn't able to make it compile any GUI application, only console ones (but i didn't really spend much time trying). There's a working link and a short info on how to use it here:
http://www.aximsite.com/boards/business-development/135816-pocket-c.html#post1187340 (sorry for linking to other forum, but i didn't want to post someone's tutorial as mine).
Anyway, i'd love to hear about any other free alternatives as well
you could try embedded visual c++.
it is free but you can not debug on devices powered wm5 or higher. you will need the ppc 2003 sdk and win xp prof or 2000.
I am interested in dabbling a little in programming for my Kaiser. I have programming experience, mainly php / mysql, though I have done some C and lots of scripting in my time. My biggest project so far though was an open source google maps mod to put on your website - thousands of lines of php / js code, mysql backend and AJAX tieing it together, some graphics routines etc, so I am no drooling n00b when it comes to coding.
How easy is it to develop basic stuff in WM?
I have access to MSDN, so I can get Visual Studio (2005 for sure, maybe later versions), so I think I have access to the apps I would need. I just ordered some books to help me along, but was wondering if I would likely face a steep learning curve.
All the stuff I want to do is today screen plugins - was thinking of having a bash at writing my own quick contacts plugin - *very* basic - just a vertically scrolling list of names over a transparent PNG button with maybe photos from the address book - I want it to be able to scroll by vertical gesture within an ultimatelaunch tab - is this likely to be quite easy and quite a good "first app" to program?
I was also looking at writing a lite repacement for phoneweaver as the only feature I use is to turn on BT when it detects power but no activesync (ie auto turn on BlueTooth when I am in the car and the device is cradled) - maybe a hack to force the keyboard backlight on in the same situation.
I have bought:
Microsoft® Visual C#® 2005 Step by Step (Microsoft)
Microsoft® Mobile Development Handbook [Paperback] by A. Wigley; Daniel... (Microsoft)
Comments / suggestions?
I would also be very interested in a thread or good reference on how to start to program app for mobile gadgets. Actually i'm a Delphi coder, and i would like to implement some applications on WM platform, but when i search over internet there's plenty of information, but no usefull information with "real-life" recomendations.
depend on the platform and language one wish to use really
there is c#.net, vb.net c++.net
c++ miniMFC, c++ PureWin32 sdk
oldVB
...
here are some other posts asking pretty much the same thing from the forum
http://forum.xda-developers.com/showthread.php?t=225405&highlight=programming
http://forum.xda-developers.com/showthread.php?t=237932&highlight=programming
http://forum.xda-developers.com/showthread.php?t=241670&highlight=programming
http://forum.xda-developers.com/showthread.php?t=245426&highlight=programming
http://forum.xda-developers.com/showthread.php?t=228043&highlight=programming
http://forum.xda-developers.com/showthread.php?t=317913&highlight=programming
http://forum.xda-developers.com/showthread.php?t=302548&highlight=programming
http://forum.xda-developers.com/showthread.php?t=327164&highlight=programming
http://forum.xda-developers.com/showthread.php?t=305926&highlight=programming
http://forum.xda-developers.com/showthread.php?t=336251&highlight=programming
http://forum.xda-developers.com/showthread.php?t=226412&highlight=programming
codeguru.com got examples of various windows mobile programs too today items and such
about delphi i dont know if anybody got some info i would say borlands site
Thanks rud. I was aware of various other posts, but my question was more of a "How steep is the learning curve?" rather than "How do you do it?".
There was also an element of "How do you do it?" insofar as there seem to be better or worse ways of going about various kinds of app (eg today apps with gesture support) which I am finding a bit of a minefield, but I feel that the new post was valid because I am giving an indication of my experience level and what I am trying to acheive - none of the posts you listed cover the combination of stuff I am trying to do. Reqs like pulling from outlook db and allowing gesture scrolling in a today plugin, I dunno, I may waste ages with C#, for example, only to realise it is a breeze with C++... I also note that a google search for wm programming gesture scroll today screen currently ranks this very thread #5. By tomorrow that'll be a googlewhack then.
Yes, there are various posts about how to get started, but I think maybe a sticky would be in order with a bit of info on the various paths - the vb/c++/c# options are quite bewildering - stuff like
levenum said:
Your question is mainly a matter of personal preference.
Here is my opinion on C++ vs. C#:
C++ advantages:
- Native code is faster than .NET
- Easier access to Win32 APIs
- Ability to write system components like keyboards and today plugins.
C# advantages:
- Saves on coding time
- Allows use of many .NET CF components to quickly accomplish complex tasks.
Please note that I am bias. I hate .NET and want nothing to o with it. Specially on mobile devices that do not have the processing power to spare for the .NET overhead.
Click to expand...
Click to collapse
is really useful, maybe if it were expanded upon, info such as for this route you need visual studio, etc, etc it would make a really good sticky for the dev section.
evilc said:
I am interested in dabbling a little in programming for my Kaiser. I have programming experience, mainly php / mysql, though I have done some C and lots of scripting in my time. My biggest project so far though was an open source google maps mod to put on your website - thousands of lines of php / js code, mysql backend and AJAX tieing it together, some graphics routines etc, so I am no drooling n00b when it comes to coding.
How easy is it to develop basic stuff in WM?
I have access to MSDN, so I can get Visual Studio (2005 for sure, maybe later versions), so I think I have access to the apps I would need. I just ordered some books to help me along, but was wondering if I would likely face a steep learning curve.
All the stuff I want to do is today screen plugins - was thinking of having a bash at writing my own quick contacts plugin - *very* basic - just a vertically scrolling list of names over a transparent PNG button with maybe photos from the address book - I want it to be able to scroll by vertical gesture within an ultimatelaunch tab - is this likely to be quite easy and quite a good "first app" to program?
I was also looking at writing a lite repacement for phoneweaver as the only feature I use is to turn on BT when it detects power but no activesync (ie auto turn on BlueTooth when I am in the car and the device is cradled) - maybe a hack to force the keyboard backlight on in the same situation.
I have bought:
Microsoft® Visual C#® 2005 Step by Step (Microsoft)
Microsoft® Mobile Development Handbook [Paperback] by A. Wigley; Daniel... (Microsoft)
Comments / suggestions?
Click to expand...
Click to collapse
Hey!
Congrats on getting your hands on with Windows Mobile...
The easiest way is to download Visual Studio 2005(2008 You have it on MSDN) - and create a new application with it.
It's sooo easy if you know your object oriented programming, as long as you want to create ordinary "office" applications... But if you want to do more advanced things(like creating a today-plugin) you need to go over to c++(even though you can download a .net home-plugin-container which acts like a "loader" for your plugin written in c++) - and also, if you want to create good GUIs, I think you are better off with c++... But then again, I think you need a bit more effort in learning c++ then using c#...
Hope this helps...
Still slogging my way thru this...
I got hold of an MSDN disc, first off I installed visual studio 6 - bad move.
Had to uninstall before trying to install VS 2005, now I think it has screwed something up, every time I try and create a "Smart Device Win32" project, I get a "Project creation failed" error. I may have to re-GHOST my OS to get rid of it
So much time just finding out what apps I need and what options to choose to start a project...
I found http://channel9.msdn.com/wiki/default.aspx/MobileDeveloper.HomePage which seems helpful
Thanks for responses!
Evilc, you link of msdn is excellent point, many thanks!
I have also just started programming in C++ ..i dnt have any knowledge of any type of codes..i learned every thing frm MSDN libraries ( i have many many of them caz i have VS 2006 VS 2005 and VS 2008 )..i recommend you to work with C++ because it uses less system resources and is fast..hope this helps..check out my Kitchen coded in C++ ( link in signature )
Yeah, I think C++ is definately more what I am looking for from what I have learned thus far.
Re-Ghosted OS - totally fresh XP SP2, installed Visual Studio 2005, still the same error. GRRR!
Visual C++ --> Smart Device --> Win32 Smart Device Project == "Project Creation Failed"
Other Languages --> Visual C# --> Smart Device --> Windows CE 5.0 --> Device Application == Project created OK.
Some posts I have found on the net say it is an IE7 issue, I may try uninstalling that or flashing back to an OS image with IE6 only, but this is really winding me up and taking a *lot* of my time...
I uninstalled IE7 and the problem went away. Woohoo!!
starting programming windows mobile
hello
1. see my web site.
2. see my book recommendations, especially the 'programming windows ce' by douglas boling. It has an example for many things and a today sample too. Most is based on visual c++ 3.0/4.0. Embedded Visual C 4 can be loaded free of charge at ms.
regards
josef
Nice site, thanks.
The windows mobile 6 sdk actually has a today screen sample, along with samples of most of the things I need to do.
neofix said:
It's sooo easy if you know your object oriented programming, as long as you want to create ordinary "office" applications... But if you want to do more advanced things(like creating a today-plugin) you need to go over to c++(even though you can download a .net home-plugin-container which acts like a "loader" for your plugin written in c++) - and also, if you want to create good GUIs, I think you are better off with c++... But then again, I think you need a bit more effort in learning c++ then using c#...
Hope this helps...
Click to expand...
Click to collapse
Are we using the same language?? Cos this (C++ Win32 for Mobile Devices) is by far and above the most difficult programming language to get into that I have ever tried. Yes, worse than ASM.
Trying to code an app that prints "Hello World" has taken me over 5 hours with no success yet - most languages I have a go at it's 5 minutes.
From http://msdn2.microsoft.com/en-us/library/ms901121.aspx :
Code:
int DrawText(
HDC hDC,
LPCTSTR lpString,
int nCount,
LPRECT lpRect,
UNIT uFormat
);
It gives a brief description of what the parameters are, but absolutely no examples and no explanation of what all the parameters do or how to initialize them, so even browsing an example is no use to me.
u can simply try
MessageBox::Show(" your message ");
ather90 said:
u can simply try
MessageBox::Show(" your message ");
Click to expand...
Click to collapse
Isn't that .NET ?
I thought the consensus was that Native Win32 or whatever it is called was the better way to go?
This is part of the problem. I cannot even work out what to put in a search engine to pull out info on the right "flavour" of C and for the pocketpc. It's *so* bewildering.
Hello evilc.
First I noticed you have some trouble with VS 2005. It probably won't be easy now, but if you ever get to format your machine again don't install it (unless you absolutely need some other features).
For C / C++ programming for WM device I strongly recommend eVC 4 as it is much lighter and responds quicker. (It's a free download as well)
Second, though you can program for WM in C# and VB .NET which are both .NET Object based languages and are probably much closer in form to PHP and Java then C, you can not write system components such as today plugins in those languages.
You need native code so C / C++ is the only way to go.
(Actually, there is a trick to combine C# and C++ DLLs to create a today plugin where C# will do the main stuff, but its pretty complicated)
What you need is to learn basic Win32 programming and using the windows API. They are almost identical for Windows Mobile and Desktop windows versions so any book on Win32 should teach you the basics.
(Personally I started with MS book on MFC and studio 6 but I would not recommend it)
Finally:
I would gladly explain the parameters of DrawText but I am not quite clear on how much familiarity you have with the Win32 mechanics, since the languages you are used to obscure them unlike C which gives you extra power but also makes you work much harder to get anything done.
Do you know how to handle messages, and how windows manages all abjects using handles? Any familiarity with GDI?
If not, it will be pretty difficult to explain.
levenum said:
Hello evilc.
Click to expand...
Click to collapse
Hello! <waves>
First I noticed you have some trouble with VS 2005. It probably won't be easy now, but if you ever get to format your machine again don't install it (unless you absolutely need some other features).
Click to expand...
Click to collapse
I tracked down the problem when I got home and installed on my desktop. When doing it on the laptop, whilst installing SP1 for studio 2005, I had hit "Not Now" to a reboot request and it had said installation failed. When I installed SP1 on my desktop and said "Yes" to the reboot request, the problem went away, so I guess it was fixed in SP1 but the installer is a bit picky.
For C / C++ programming for WM device I strongly recommend eVC 4 as it is much lighter and responds quicker. (It's a free download as well)
Click to expand...
Click to collapse
Wish I had that advice before as I wasted a day messing around with an MSDN CD, trying to work out what to install and what not. So does the eVC 4 download include an IDE? If not, what do you use?
Second, though you can program for WM in C# and VB .NET which are both .NET Object based languages and are probably much closer in form to PHP and Java then C, you can not write system components such as today plugins in those languages.
You need native code so C / C++ is the only way to go.
(Actually, there is a trick to combine C# and C++ DLLs to create a today plugin where C# will do the main stuff, but its pretty complicated)
Click to expand...
Click to collapse
You don't have to tell me twice to avoid the bloatware ****e
What you need is to learn basic Win32 programming and using the windows API. They are almost identical for Windows Mobile and Desktop windows versions so any book on Win32 should teach you the basics.
(Personally I started with MS book on MFC and studio 6 but I would not recommend it)
Finally:
I would gladly explain the parameters of DrawText but I am not quite clear on how much familiarity you have with the Win32 mechanics, since the languages you are used to obscure them unlike C which gives you extra power but also makes you work much harder to get anything done.
Do you know how to handle messages, and how windows manages all abjects using handles? Any familiarity with GDI?
If not, it will be pretty difficult to explain.
Click to expand...
Click to collapse
No GDI Experience. I take it this would be the library of choice for drawing the screen of a today screen app? Stuff like the HTC Home clock or the new Face Contacts - they would likely use Native C++ and GDI? Doesnt strike me as something you would do with a form.
Also, anyone got the skinny on vertically scrolling by click-and-drag inside a today screen app? Just a case of enabling a parameter? Has to be coded manually? Best way to do it smoothly? If you have seen the Conduits Pocket Player 3.x browse list - how it "eases in" and "eases out" at the ends of the list, has inertia so you can "flick" down the list, the alphabetical bar instead of the regular scroll bar - is that all coded manually or is there an api or something that can help?
Thanks for the help!
I just noticed your apps in your sig - checked out LVM time - noticed there was source - wooohoo! I generally pick these things up by example.
All that code just for a (configurable) clock on one line - wow. Great though, a really good example of a today app - minimal enough in functions so it is easier to suss how it all slots together, but full featured enough (implimented example of an options screen - yay!) to show how to do various things.
And Gnu as well! Nice, this will be the basis of my first test project too I think - at least now I have a framework to test out what I want to do and how to go about it without having to work out how to code the basis of the application.
I thank you from the bottom of my heart sir.
I tried to build it in VS2005, but I got a
fatal error C1083: Cannot open include file: 'todaycmn.h': No such file or directory
A quick google search showed todaycmn.h was part of the SDK, I found the file, dropped it into the headers section of the project, but no joy. I will probs just try eVC.
Oh, and having developed a today plugin, maybe you can answer this one:
As far as I can tell so far, debugging isn't very easy with a today app - something to do with the fact that the dll is not releasable? Is this an issue I will come up against? I hope its not a case of "reinstalling" the app each time you want to test... I was thinking maybe along the lines of have it as a normal app for debugging, then make it a today plugin when you want to build to use it?
I dunno, probably trying to run before I can walk, my books shoulda been here today, oh well. Sorry for all the questions...
@evilc:
Are you using standard Win32 or MFC?
You may want to try using MFC since you get the flexibility of native development but with some nice class libraries that make your life easier.
As for click and drag behavior, that is usually implemented by handling the WM_LBUTTONDOWN, WM_LBUTTONUP and WM_MOUSEMOVE.
When you get wm_lbuttondown you set a flag that says the user is dragging. You use wm_mousemove to update the stylus position as long as this flag is set, then you unset it on wm_lbuttonup.
That's the basic idea anyway. Someone made a post about gesture recognition in this forum a few weeks ago with sample code. You should see if you can find that.
Managed Today Screen plugins
See:
http://msdn2.microsoft.com/en-us/library/ms839442.aspx
for some background on the concept.
And:
http://www.christec.co.nz/blog/archives/279
Outlines what I think is a very ingenius technique for managed today screen plugins.
For those of you that want an easy way to make a today screen app in c#. Chris did all the C++ work for you.
Also I forgot to mention that the SDK samples cover all most every application type you can think of. Most of the good ones are Win32 though.
Also, keep in mind that you can use P/Invoke from your C# apps to call native APIs. So don't let people tell you you need to use C++ just because you can access more api's. I will say that you should use C++ for games, or other apps that require high speed or advanced GUI's (it is VERY hard to do interesting gui techniques with C# and interop, trust me).
And finally, I would highly recommend using the most recent version of visual studio you can get (especially if you're using vista), unless your machine can't handle a newer version. I say so because visual studio gets more and more powerful as an editor with each new iteration and I personally can't go back after I get used to the new features they introduce. And the new versions are almost necessary if you're going to do .net development.
Hello all,
I'm now the proud owner of an android phone (htc desire) and as a hobbiest programmer i'm of course intrested in making (free) apps for it. I come from a linux based devices background (like gp2x, wiz, dingoo a320) etc. So i'm used to the gcc toolchains and libs and I read a bit around about android programming. Am i correct in saying that is not possible to just use a gcc toolchain for programming android apps since android uses some sort of java virtual machine ?
Or is this possible after all, just like one woud make apps for linux based devices. I think the Answer will be NO but i still ask since i wasn't certain and did not find that much information about it.
Suppose it is not possible, my only option for porting linux based games / apps would be to use the NDK and split up the main functions of a game and make a shared lib out of it, which could be called using JNI from java right ?
But i have a question if this is the case...
I can't really imagine that all phone manufactures use the same hardware in their phone or even the same architecture, so suppose i would use the NDK to create a shared lib with basic functions of a game i wish to port, wouldn't this lib need to be build for the specific architecture of a certain phone and thus could only work on that phone ? or are all android phones arm based ?
So you could say my question basically comes down to this :
Will Using the ndk and apps created with it, be less compatible then a java only app for all the droid phones out there ?
thanks
hmm seems i can answer my own questions now, i hadn't looked at the official ndk site itselve yet and did not know it would have all the info i needed.
So using gcc toolchains only does not work,
android uses a (modified ?)java virtual machine called dalvik
de libraries do have to be build for a specific architecture, and all droid's (phones) do seem to run on arm, but in the future the x86 architecture will be supported as well.
HOWEVER,
one can target ARMv5TE or ARMv7-A (and in the future x86) and include the needed libs (per architecture) in the apk file, the droid system will do the rest by checking if a lib for the specific architecture is availible or not.
also it's worth to note that ARMv5TE libs should work on any arm based droid phone, BUT without hardware fpu support. Since all the (linux based) devices i programmed for had no hardware fpu either and weren't as near as powerfull as my desire is, i don't think using software floating point would be a problem for my needs and if it i do need it i can always use fixed point math.
Just thought i should write a small excerpt of that page here, since there might be other people looking for it eventually
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.