c compiler for arm pocketpc (XDA) ? - Windows Mobile Software Development

Hi,
I'm thinking about porting an app over to the XDA...
the source is written in C... anyone know of a good compiler for the strongarm processor?

easiest is to just use microsoft's free compiler 'embedded vc 3.0' ( for ppc2002) or evc4.0 for ppc2003.
you also need the ppc2002 sdk or the ppc2003 sdk
you can also use gcc, but it is rather difficult to build a working cross compiler. I use gcc for the time critical parts of my application, since it does a much better job at optimizing code.

Hi... here's what I was thinking of porting...
although after a discussion with a few of them (seen in the link) I'm not sure how viable it would be now.
I did post your links on the discussion
thanks anyways
http://exult.sourceforge.net/forum/read.php?f=1&i=16397&t=16397

you may be able to circumvent the problem that msevc doesn't fully
support exceptions ( runtime typeinformation is what is missing actually )
by using gcc for the bulk of you code.
maybe you would have to implement crt0.o your self.

Related

Programming ... Whats Best???

Hi!
I'm a Programmer for Visial Basic and Delphi...
I'm not sure whitch system is the best 4 programming the XDA?
AppForge or what?
Thanx
Stevie
Each have their advantages. I would go with Embedded C++ every time, but then, I'm that kind of guy. I like lean code.
On the other hand... If you don't want to learn C++, give Embedded VB a try.
Programming
Hi!
Thanx, but U mean Visual C++ 6.0 ??? Is there anything other what I need with C++ like Appforge 4 VB? Or do I need nothing more?
Stevie
No.. I mean Embedded C++. It is available for free from microsoft
http://msdn.microsoft.com/downloads...=/msdn-files/027/001/963/msdncompositedoc.xml
>I'm not sure whitch system is the best 4 programming the XDA?
>AppForge or what?
I guess it depends on your definition of "best".
I do C++, but actually prefer Visual Basic for most
applications due to the development speed for GUI-based
stuff.
I've downloaded eMbedded Visual Basic and eMbedded C++ from
Microsoft. One problem: EVB apparently does *not* yet
support the XDA architecture (StrongARM).
The SmartPhone SDK from MS *does* support StrongARM (not
*specifically the XDA* that I can tell) but only provides the SDK
for eMbedded C++ (not EVB).
I EMAILed the MobileVB folk and they said:
1) They don't support SmartPhones.
2) They don't have any support for SMS handling.
At this point I guess I'll go to EVC++ unless I can find other
tool(sets) to use.
What *I* would like to see is script support ALA PERL or PYTHON.
Is there anyone out there that knows of a beastie like this?
Or, even better (for me) would be LINUX on the XDA (I've
been using Familiar distro on the iPAQ, and it is great .. can
do GPRS/GPS from a LINUX-based platform (C/C++/JAVA/PERL/PYTHON/whatever).
Charlie
You keep mentioning Smartphone here, and the Smartphone SDK. The XDA does not support the Smartphone SDK, as it is not a Smartphone - it runs Pocket PC 2002 Phone Edition - something completely different.
So please, don't spend several hours downloading the Smartphone SDK to find it's not the right one. Download the Pocket PC 2002 SDK. I have developed several apps for the XDA using this already.
What *I* would like to see is script support ALA PERL or PYTHON.
Is there anyone out there that knows of a beastie like this?
Click to expand...
Click to collapse
There is a PocketPC Python, you have to use the win32api to GUI work, and installation can be a little painful depending on what you need. It does run and is stable though. Check out http://www.murkworks.com/Research/Python/PythonCE/PythonCEWiki/FrontPage[/quote]
Hi guys
I downloaded eMbedded Visual Tools 3.0 from Microsoft, but during installation, I was asked for the Product ID #
Any help ? :?:
I'd like to throw in another suggestion: the .Net Compact Framework. If you're a Delphi programmer (as are we - I used to be on TeamB for Delphi), you'll take to it straight away. After all, .Net and C# was designed by the same Anders Hejlsberg that designed Delphi. C# is very like Object Pascal with a C/Java syntax, but with even more goodies.
We've been using the Compact Framework beta for several months and it is quite simply superb. It was just launched officially on April 26th as part of Visual Studio.Net 2003. However, you don't need to buy Visual Studio - just download the .Net 1.1 SDK from Microsoft - it's free.
It's just a subset of the full .Net Framework, but if you need to do something that's not supported directly in the Framework classes, you can easily call API functions - or even write some code in embedded VC++ and call that. The managed environment is just great.
MikeS.
When prompted for the CD Key, please enter TRT7H-KD36T-FRH8D-6QH8P-VFJHQ
Khang Le
[email protected]
Khang Le, thanks

Delphi and WM5

I was looking for an answer for few months, and i'm confused right now...
Question is, would it be possible to develop an application for WM5 using Delphi, if so, which version of delphi i need, what kind of additions and any important info for me...
It looks like an easy topic but after going through many forums and so, i don't really know an answer, some people claim it's not possible, some talk about some foggy solutions... i just need a clear answer and i believe some of you guys know it... please share
latest delphi would prob support .net2 using compactframework for wm2005
i'm trying to get delphi8 or 2005, just wasn's sure it makes any sense. woult delphi itself do it, or any additional software is needed?
1 of 2 platforms need to be supported by delphy for it to work
1 is arm cpu
other is .net compact framework
no other way for delphi to make bins which works on a pocketpc
finally I'm getting somewhere so delphi CAN support arm directly;] how do i make sure of it? is it a matter of delphi itself or come plugins for a compiler, etc...? thanks, I already feel more confident about it
Current versions of Delphi (BDS2006 or Turbo Delphi) can produce native code only for 32 bits x86 CPUs, so it does not natively support ARM CPU.
On the other hand it has (limited) support for .NET Compact Framerwork 1.x so it can be used to develop applications that runs on Windows Mobiles.
Next release will add (better) support for NET Compact Framerwork 2.
This is an application I developed using BDS2006:
http://forum.xda-developers.com/showthread.php?t=275577
More information:
http://bdn.borland.com/article/33507
http://bdn.borland.com/article/33798
oruam57 said:
Current versions of Delphi (BDS2006 or Turbo Delphi) can produce native code only for 32 bits x86 CPUs, so it does not natively support ARM CPU.
On the other hand it has (limited) support for .NET Compact Framerwork 1.x so it can be used to develop applications that runs on Windows Mobiles.
Next release will add (better) support for NET Compact Framerwork 2.
This is an application I developed using BDS2006:
http://forum.xda-developers.com/showthread.php?t=275577
More information:
http://bdn.borland.com/article/33507
http://bdn.borland.com/article/33798
Click to expand...
Click to collapse
Ok, so i menaged to get myself delphi 2005 and i try to create my first hello world app for ppc. what do i need? I go for Delphi .NET projects > Windows forms application, is it correct? when i compile, it will run on wizard, but create error message. Could you point me to some guide for guys like me? thanks...

App idea, need help starting. :)

Since there isn't a SAPI that's accessible for windows mobile developers, I was disappointed. I just got a Samsung Omnia and I'm quite enthralled by it. I want to write an application that does speech recognition and text to speech.
eSpeak is a program easily ported. It's been done and comes with a how-to guide for compiling for windows mobile 6.x. As far as text to speech goes, then, I'm not too worried (it will be fun developing a voice.)
I got pocketsphinx to compile. The project settings says it was compiled for an x86 machine. Do I have to compile it for the ARM architecture, or do I just need to compile the final application for the ARM architecture, with the pocketsphinx dll somehow baked into the end result?
Also, I was wondering if anyone could point me to a beginner level tutorial for developing applications on windows mobile. I'm brand spanking new to developing on mobile devices, and while the language specific stuff is old hat, there's lots of transitional stuff I need to learn. Any links are appreciated. I'd like to not brick my Omnia by doing something silly, so I'll be developing strictly on my desktop until I'm satisfied with the safety of whatever it is I'm developing.
Thanks, awesome community here!
Hey there JR. As far as WinMo development, here's a list of the basic tools you need:
1. Visual Studio 2008 Professional SP1 + patches (or VS 2010 which is in beta now)
2. Windows Mobile 6 Professional and Standard Software Development Kits Refresh (device and cellular emulators, some samples, download from msdn.microsoft.com)
3. Windows Mobile 6.5 Developer Tool Kit (6.5 emulator images, gestures API etc - also at msdn.microsoft.com)
Assuming you will be writing managed code, the most widely used language is C#.
As far as books, unfortunately WInMo is not getting much love these days (hopefully this will change with WinMo 7) so there's little new but the best book out there IMO is "Microsoft Mobile Development Handbook" by Andy Wigley (2007).
The good news is that there's a plethora of on-line material, easily accessible from the aggregate Search screen in Visual Studio. Sites like codeguru.com, social.msdn.microsoft.com/Forums/en-US/windowsmobiledev, www.c-sharpcorner.com, www.codeproject.com, 4guysfromrolla.com etc are your best friends!
I hope this gets you started! Best of luck with the project.
JRowe47 said:
Since there isn't a SAPI that's accessible for windows mobile developers, I was disappointed. I just got a Samsung Omnia and I'm quite enthralled by it. I want to write an application that does speech recognition and text to speech.
eSpeak is a program easily ported. It's been done and comes with a how-to guide for compiling for windows mobile 6.x. As far as text to speech goes, then, I'm not too worried (it will be fun developing a voice.)
I got pocketsphinx to compile. The project settings says it was compiled for an x86 machine. Do I have to compile it for the ARM architecture, or do I just need to compile the final application for the ARM architecture, with the pocketsphinx dll somehow baked into the end result?
Also, I was wondering if anyone could point me to a beginner level tutorial for developing applications on windows mobile. I'm brand spanking new to developing on mobile devices, and while the language specific stuff is old hat, there's lots of transitional stuff I need to learn. Any links are appreciated. I'd like to not brick my Omnia by doing something silly, so I'll be developing strictly on my desktop until I'm satisfied with the safety of whatever it is I'm developing.
Thanks, awesome community here!
Click to expand...
Click to collapse
Writing in C#.NET Compact -- you have no worries for 'safety', unless you literally do a File.Delete("/Windows/blah");, you should be okay ;P
But yes, It is based off of the big .NET Framework. So if you can do .NET, you can do .NETCF.
acidhax said:
if you can do .NET, you can do .NETCF.
Click to expand...
Click to collapse
I don't agree. In .NET you usually do not need to worry about performance, you usually get away just fine by using a simple approach at the cost of a small bit of performance. On .NET CF you certainly need all the performance you can get. Also, the .NET Compact Framework is heavily stripped down and for a lot of tasks you need to find an alternative, innovative solution.

Android NDK hits Release 3, brings OpenGL ES 2.0 access to devs

http://android-developers.blogspot.com/2010/03/android-ndk-r3.html
Posted by David Turner on 08 March 2010 at 11:25 AM
The third release of the Android Native Development Kit (NDK) is now available for download from the Android developer site.
It can be used to target devices running Android 1.5 and higher. In addition to a few bug fixes and improvements, this release includes the following new features:
Toolchain improvement
The toolchain binaries have been refreshed for this release with GCC 4.4.0, which should generate slightly more compact and efficient machine code than the previous one (4.2.1).
Note that the GCC 4.4.0 C++ frontend is more pedantic, and may refuse to compile certain rare and invalid template declarations that were accepted by 4.2.1. To alleviate the problem, this NDK still provides the 4.2.1 binaries, which can optionally be used to build your machine code.
OpenGL ES 2.0 support
Applications targeting Android 2.0 (API level 5) or higher can now directly access OpenGL ES 2.0 features. This brings the ability to control graphics rendering through vertex and fragment shader programs, using the GLSL shading language.
A new trivial sample, named "hello-gl2", demonstrates how to render a simple triangle using both shader types.
Name simplification
This NDK release is just called "r3", for "Revision 3", to indicate that it is not limited to a specific Android platform/API level. Some developers thought that the previous release's name (1.6_r1) was confusing and indicated that it could only be used to target Android 1.6, which was not true.
Enjoy!
So what does this mean? can we get all these bugs fixed i.e. 3d wallpaper and other open gl es 2 stuff?
Sorry im noob
ermacwins said:
So what does this mean? can we get all these bugs fixed i.e. 3d wallpaper and other open gl es 2 stuff?
Click to expand...
Click to collapse
Most Android applications are java applications that are interpreted by the Dalvik VM. The NDK allows you to create partially native code applications, so in theory can be much faster, though it does carry with it other issues such as limited access to Android APIs (see here for more details)
Essentially the OpenGL ES support in the NDK should allow for faster 3D applications, which for the most part is going to be games.
Regards,
Dave
can this be used to make live wallpapers to work on hero?
Downloading .. will test on aHero 0.5 ..
I hope this thing fixes our Hero
is it opengl that makes the iphone UI so fluid?
MaXo64 said:
Downloading .. will test on aHero 0.5 ..
I hope this thing fixes our Hero
Click to expand...
Click to collapse
your the man, please keep us updated on this thread and the other
MaXo64 said:
Downloading .. will test on aHero 0.5 ..
I hope this thing fixes our Hero
Click to expand...
Click to collapse
Not quite sure what you are expecting it to fix? It allows you to create applications (in conjuction with the SDK) that can include some native code elements rather than being 100% interpreted java.
Regards,
Dave
foxmeister said:
Not quite sure what you are expecting it to fix? It allows you to create applications (in conjuction with the SDK) that can include some native code elements rather than being 100% interpreted java.
Regards,
Dave
Click to expand...
Click to collapse
just downloaded the NDK .. BTW, the binaries and libraries are included and compiled for different architectures
now just reading the documentation to figure out which one is for "armeabi" or ARM5 .. which is compatible with the Hero..
I'll keep you updated..
Last I checked, the SoC in the Hero isn't capable of OpenGL ES 2.0.
There isn't much to see there other than for devs who want to make 3D accelerated apps for Snapdragon or OMAP3 chips.

Progress on rooting WP7

I'd like to extend my gratitude to RustyGrom and others (if there are any) for the work on unlocking the developer builds of WP7, but I was wondering what where we are in relation to 'rooting' WP7 so we can run our own unsigned binaries and possibly even getting the stock Windows CE shell and software running on WP7 instead of the Metro UI.
I've heard unconfirmed and uncorroborated rumours of Microsoft's plans to allow native development eventually, but my friends who work at Microsoft really give me the impression that the Managed-only rule is here to stay, in which case it will be up to people like us to get it working.
My initial thoughts are that the hardware HTC and other mfgs produce will have a firmware flash function, so it's just (in my naive mind) a matter of dumping the ROM, making the right changes, and re-flashing the device, assuming there isn't a requirement the new ROM image is signed by Microsoft or the OEM.
Windows CE wasn't built with a hypervisor in mind (unlike the PS3) so I'm curious as to how the sandbox is implemented, and how an attack could be forged against the platform. If we get something working on the emulator would it work on the physical devices?
IIRC policies are requested by xml configuration files located in a .xap.
I haven't yet looked deeply into this, but I would assume it works similarly to CE5.x/WM6.x: that is, if the .xml requests a higher security level than the norm (say, SECLEVEL_EXEC_NATIVE_CODE for example), the .xap deployment system would check the .xap certificate against the internal certificate store. If a match is found to the right security level (Root at first, later OEM, probably never User), the application is allowed to install, if not, the installation is denied.
So, elevating privledges to execute native code should be easy to do with filesystem level access, we inject our own certificate to the root certificate store, sign the .xap with that certificate, and deploy away.
NOTE: This is an educated assumption, i've not actually examined the restriction system in depth yet.
Sortof. You could use those "Interop" methods and go native. It worked for me with a lot of tough luck.
The word windows and "Rooting" should never ever be used together. The term rooting obviously is being grossly misused.
Root is the user in linux that is given full and complete access to all system resources.
tyrannus said:
Sortof. You could use those "Interop" methods and go native. It worked for me with a lot of tough luck.
Click to expand...
Click to collapse
P/Invoke and Interop don't work on WinPho because the functionality required is disabled in the sandbox environment, or possibly not even present in the version of the CLR they're using.
Look, it's W3bbo!
Tom Servo said:
Look, it's W3bbo!
Click to expand...
Click to collapse
Wtflol. Hey Toiletbrush, haven't seen you around for a while. Didn't you get banned from C9 or something?
(I'm still active on SA btw, just under a different username)
Naw, I was on an Anti-MS binge for three years until few weeks ago. Took Oracle screwing up OpenSolaris. That and I wanted a Windows Phone. Kinda useless without Windows.
Mod edit: Please watch your language
For the main:V can't run wp7 on our HD2
I am thinking of the other way around, getting xaml and xap to run on wm6, the hd2 is quite capable of running them. Wp7 runs cf3.7 and we can start from there. Maybe we need to identify the required assemblies and copy them. Defiantly it won't be fully supported, launchers will not work for example but it might be a good shot.
I'm not a core coder or hacker, but when it comes to logic I'm optimistic, it might be possible.
I would love to see silverlight running on wm.
You are really optimistic.
WP7 is compiled against armv7, where WM is compiled against armv4i...
ARM v7 has nothing to do with .net assemblies, that us why we need .net cf to run apps built using .net
Now the question is, is the .net cf responsible for running xap packages or is it another framework (like on pc, you need sl runtime)
Afak, it is the cf.
Please correct me if I'm wrong.
I read every post and understood nothing. You guys are on another level with your tech jargon. Lol.
Sent from Android HD2 using XDA app
anaadoul said:
ARM v7 has nothing to do with .net assemblies, that us why we need .net cf to run apps built using .net
Now the question is, is the .net cf responsible for running xap packages or is it another framework (like on pc, you need sl runtime)
Afak, it is the cf.
Please correct me if I'm wrong.
Click to expand...
Click to collapse
The JIT compiler (or what is used in CF version) that loads assemblies is compiled against armv7 and these assemblies can't be run on our compiler.
OndraSter said:
The JIT compiler (or what is used in CF version) that loads assemblies is compiled against armv7 and these assemblies can't be run on our compiler.
Click to expand...
Click to collapse
Assemblies are not compiled against a platform or a CPU Architecture, they are compiled against a .NET Framework version to an IL.
The JIT is the different one, it is a native code so it is compiled to V7 in Windows Phone 7, but we have it already (JIT) compiled against ArmV4 (as in .net cf)
anaadoul said:
Assemblies are not compiled against a platform or a CPU Architecture, they are compiled against a .NET Framework version to an IL.
The JIT is the different one, it is a native code so it is compiled to V7 in Windows Phone 7, but we have it already (JIT) compiled against ArmV4 (as in .net cf)
Click to expand...
Click to collapse
Unlike Java, the IL that .NET compiles is actually CPU specific. This is why you can specify the CPU type when compiling a (desktop) .NET application (either x86, x64 or Itanium).
XAP files on Windows Phone 7 run on top of a modified version of Silverlight. Silverlight has its own runtime engine, and does not reference the .NET libraries at all (they just happen to share namespaces and classes to make coding easier). To get WP7 applications to run on WM6.5 you would need to recompile Silverlight.
TehPenguin said:
Unlike Java, the IL that .NET compiles is actually CPU specific. This is why you can specify the CPU type when compiling a (desktop) .NET application (either x86, x64 or Itanium).
Click to expand...
Click to collapse
Not true. The MSIL itself is CPU-independent. The reason you can chose to specify the architecture when compiling is for .NET Applications that depend on external native-code libraries. Obviously, in those cases, the default "Any CPU" option just causes a nightmare, as the framework then chooses the architecture of the JIT compiler, meaning different dependencies for different machines. Selecting an architecture inserts data telling the JIT compiler what architecture it must use.
That said, what you go on to say about Silverlight is true. Silverlight does not depend on the .NET Framework on the desktop, or the .NET Compact Framework on CE or WP7 (though the compiler for Silverlight does require the .NET Framework). Strictly speaking, the only thing they share in common is the CLR, the libraries are all recreated and re-engineered for their specific purpose. The Libraries share the names simply to enable software developers to re-use as much desktop code as possible.
(Note: I think this is all correct, though I'll be the first to admit that I am much more experienced with Desktop .NET than the mobile equivalent).
Silverlight on WP7 will undoubtedly have native dependencies too, just like the .NET Framework and the .NET Compact Framework (both make extensive use of existing Windows APIs, of course).
Therefore, it'd take a Moonlight-style project (The Mono equivalent of Silverlight, enabling Silverlight applications to run on Linux) in order to bring Silverlight to Windows Mobile classic.
hounsell said:
Not true. The MSIL itself is CPU-independent. The reason you can chose to specify the architecture when compiling is for .NET Applications that depend on external native-code libraries. Obviously, in those cases, the default "Any CPU" option just causes a nightmare, as the framework then chooses the architecture of the JIT compiler, meaning different dependencies for different machines. Selecting an architecture inserts data telling the JIT compiler what architecture it must use.
That said, what you go on to say about Silverlight is true. Silverlight does not depend on the .NET Framework on the desktop, or the .NET Compact Framework on CE or WP7 (though the compiler for Silverlight does require the .NET Framework). Strictly speaking, the only thing they share in common is the CLR, the libraries are all recreated and re-engineered for their specific purpose. The Libraries share the names simply to enable software developers to re-use as much desktop code as possible.
(Note: I think this is all correct, though I'll be the first to admit that I am much more experienced with Desktop .NET than the mobile equivalent).
Silverlight on WP7 will undoubtedly have native dependencies too, just like the .NET Framework and the .NET Compact Framework (both make extensive use of existing Windows APIs, of course).
Therefore, it'd take a Moonlight-style project (The Mono equivalent of Silverlight, enabling Silverlight applications to run on Linux) in order to bring Silverlight to Windows Mobile classic.
Click to expand...
Click to collapse
If silverlight doesn't need the .net cf then
1) why is it included in wp7 (.net cf 3.7)
2) how can we use compiled assemblies (.net) inside silverlight?
Sent from my HTC HD2 using XDA App
anaadoul said:
If silverlight doesn't need the .net cf then
1) why is it included in wp7 (.net cf 3.7)
2) how can we use compiled assemblies (.net) inside silverlight?
Sent from my HTC HD2 using XDA App
Click to expand...
Click to collapse
1) XNA uses the .NET framework
2) The assemblies must target the Silverlight runtime, as such any assembly compiled for the .NET runtime will not work
anaadoul said:
1) why is it included in wp7 (.net cf 3.7)
Click to expand...
Click to collapse
I don't know, maybe because a lot of the base system's written in not-Silverlight managed code?

Categories

Resources