Develop Bugs

Language of choice

Just curious..What is everyone's programming language of choice when developing apps for WinMo?
Ive been working (lightly) on a VB program, which is ok, but i feel it isnt as efficient as others might be, and i know efficiency and size is a big issue on mobile devices (obviously)

Depends:
A simple program or one that can be done just using the stuff in the standard system DLLs then I will go for the pain of coding it in WIN32 C++. The resulting application runs like the wind, and can be distributed as a single executable file, no CAB, no installation projects, etc etc.
If I need any web or fancy data functionality, then it is .NET, because it is not worth the hassle of getting all this to work from levels lower down.
Having had lots of previous coding experience in C/C++ then C# is the natural choice, but as far as .NET is concerned, the actual language you code in is irrelevant. It compiles down to IL anyway and the CPU 'JIT' compiles this into its own code before it runs. Hence the performance hit when the program starts and runs.
In .NET, in essence, all you are doing anyway, is creating .NET objects, setting their properties and calling their methods, in order to get them to do what your application requires. A simplistic view, I know, but that's is all there is to it!
The language that you use to do this doesn't really matter, it is just personal preference.

I guess i assumed one language had more efficantcy than another. Like im working with VB atm, and i know it simplifies alot of things to make it easier to use, not sure if it includes all that extra code in the final build or not tho.
I would like to get more pratice with C++ and i have yet to use C# so dono whats different about that.
I would like to eventually start making programs that utilize the .net code and get my programs talking though data on the phone, but im not that advanced yet.
currently im still trying to wrap my head about making a program with a local database. The program im working on currently doesn't store any data, but i would like to to. I would also like (if i get ambitious) to have that program possibly talk to a PC (parent) program and sync with it. But that i think is a ways off.
Also, do the Mobile SDK's look different? The program im working on i started in the 5 SDK, but (obviously) doesnt have Finger friendly IU tools. I haven't looked at the 6/6.5 SDK yet (as id have to start over again i think). Does it have more finger friendly options?

In .NET CF, the finger-friendlinnes and kinetic scrolling and this all isn't available for all controls. Most of them (the classic ones) are, but if you try using scrolling for whole form, it won't work, only scrollbar will. (Probably with some playing with physicsengine and marshalling you might be able to get it working here, too).
In C++, there are numerous examples of this gestures etc directly in SDK, also many other stuff is there.
See, the main difference here is that .NET is fully equipped with stuff to get everything done fast, easy way.
In C++, you must first make this way yourself .

i am using the .net 3.5 framework tho.. Unless you mean C++ vs C#. I thought .net was an expansion on a current language, and not a language on it self (meaning i cant choose to program in .net, its an option to VB, C++ or C#)
I did toy with it, and it appears as tho your right, the forums are the same. IE drop down/combo boxes are not finger friendly. Guess id have to turn it to a button and another form with large radio button options.

C# vs C++ main difference is that C++ is compiled to native code right on first time, which makes it very fast. C# is compiled to MSIL, which is NOT native code yet. When you run c# app, the code is being Just-In-Time (JIT) compiled to native code, which makes it "longer" to load and "slower" to run (usually that makes about 20% of speeddown on classic PCs with very optimalized C++ same code - it probably already is lower, this is a bit older result of testing).
C# has those nice features that it can't get out of its memory etc, the JIT is almost unhackable, so you can't write viruses in it etc.

As far as the SDKs are concerned, there are slight differences from one version to the next but they can be quite difficult to spot.
They can become issues, when code written to run on one platform is run on one several generations away. I have a program that was written in C++ WM2003. Works under all versions of WM until 6.5.3, when the About Dialog box fails to close if the (X) button is pressed. Turns out another value has to be added to the dialogbox flags field to get it to behave properly.
This has been a feature of SDK's from WM 5.0 onwards, but the WM2003 SDK is unaware of it. You have to add it manually to the shell code created by the SDK,
Progress I suppose. The full article is here:
http://forum.xda-developers.com/showthread.php?t=635063

Treo 700xw Verizon Spanish language
Hello fellow .... I'm new to this forum
I have a Treo 700wx and I live in Mexico ...
My Treo is Verizon's company and is currently with the version 1.22 ...
My problem is that it is in English and I need to change the language in Spanish ...
Thank you for your support both the need
Greetings

stephj said:
As far as the SDKs are concerned, there are slight differences from one version to the next but they can be quite difficult to spot.
They can become issues, when code written to run on one platform is run on one several generations away. I have a program that was written in C++ WM2003. Works under all versions of WM until 6.5.3, when the About Dialog box fails to close if the (X) button is pressed. Turns out another value has to be added to the dialogbox flags field to get it to behave properly.
This has been a feature of SDK's from WM 5.0 onwards, but the WM2003 SDK is unaware of it. You have to add it manually to the shell code created by the SDK,
Progress I suppose. The full article is here:
http://forum.xda-developers.com/showthread.php?t=635063
Click to expand...
Click to collapse
I noticed something else odd. When i run the app on my pone, the resolution is off. Now everything looks ok, i just mean that when i run it on my phone, theirs alot of "white dead space" at the bottom. I can only guess this is due to the SDK's catered to phones with smaller screen resolutions (ie Touch Pro) with buttons.. Is their a way for me to switch the resolution to ultilize the full Touch Pro 2 screen size (480x320 i think)?

Funny you should mention that. I replied to a similar post a short while ago. I'm not going to type it all in again, it's here.
http://forum.xda-developers.com/showthread.php?t=637417

What exactly is a CE??

Can't we upgrade it????
I have X1 and from what I read, it has an old CE..whereas the Win7Phone has CE 7 o something, if its software, can't we upgrade or update it????

circleofomega said:
Can't we upgrade it????
I have X1 and from what I read, it has an old CE..whereas the Win7Phone has CE 7 o something, if its software, can't we upgrade or update it????
Click to expand...
Click to collapse
Can't be upgrade as it's completely different kernal.
<<Basic Definition Here>>

CE stands for "Compact Edition" I have a HP Jornada 420 that came out in 1999 and has the first version on it,They change it to Windows Mobile when you could use the phone on it..

spannernick said:
CE stands for "Compact Edition" I have a HP Jornada 420 that came out in 1999 and has the first version on it,They change it to Windows Mobile when you could use the phone on it..
Click to expand...
Click to collapse
actually CE is the main operating system. Windows Mobile is a layer on top of it that includes telephony support and such.

spannernick said:
CE stands for "Compact Edition" I have a HP Jornada 420 that came out in 1999 and has the first version on it,They change it to Windows Mobile when you could use the phone on it..
Click to expand...
Click to collapse
Officially, I don't think CE ever stood for anything until relatively recently when MS decided to rebrand the CE 6.0 kernel "Windows Embedded Compact". MS used to claim it stood for various things like "Compact", "Connected", etc. but they pretty much admit it never meant anything in the beginning.
Also, the Jornada 420 is hardly one of the first CE devices. It is a Palm Size PC that runs CE 2.11 with a color screen for crying out loud! It's at least the 3rd or 4th iteration of hardware designed for the OS. Heck, It isn't even the first release of Pocket PC's predecessor platform, Palm Size PC. Windows CE truly started with the original Handheld PC 1.0 platform back in 1996. Pocket PC and then Windows Mobile is really just another evolution of the original, intentionally crippled Handheld PC spinoff platform known as Palm (Size) PC. It was essentially the Smartphone of its day. Like Smartphone, it began as the intentionally crippled platform for weaker hardware while Handheld PC eventually evolved into a higher end, mini notebook replacement OS with support for USB, high resolutions color screens and faster processors. It is Palm Size PC we have to thank for lacking exit buttons, crippled file/save dialogs and the inability to open a second instance of applications on Windows Mobile. In some ways, my CE 1.0 MobilePro 400 is still feels less crippled and more productive than even the current Windows Mobile 6.5.3 devices. Perfect example: you can open multiple copies of Internet Explorer/Word/Excel/whatever, switch between them and open/save files from any location right out of the box. On the CE 2.0 rom, I can save/open anything to a UNC path over my network. Clearly, MS removing more "advanced" features and intentionally crippling the OS is nothing new when it comes to mainstream, consumer targeted CE platforms. :/ Though, Pocket PC at least retained backwards compatability, multitasking and added Office and IE. I guess Windows Phone 7 Series will just finish up their dream of making the most retardified CE OS possible that Pocket PC/PsPC began all those years ago. At least Vista/7 on the desktop lets you turn retard mode off.

RAMMANN said:
actually CE is the main operating system. Windows Mobile is a layer on top of it that includes telephony support and such.
Click to expand...
Click to collapse
What's with people and their nebulous definitions of things.
"CE" is the name of the kernel that Pocket PC/Windows Mobile/Windows Phone Series/Zune devices use.
A "kernel" is the heart and soul of an operating system. Around it and its APIs everything else is built.
Windows 7, for example, is built ontop of the Windows NT 6.1 kernel.
TFGBD said:
At least Vista/7 on the desktop lets you turn retard mode off.
Click to expand...
Click to collapse
What exactly do you mean by "retard mode" in Vista and 7?
P.S.: If you're referring to User Account Control, it's you who's the retard.
; )

Spike15 said:
What's with people and their nebulous definitions of things.
"CE" is the name of the kernel that Pocket PC/Windows Mobile/Windows Phone Series/Zune devices use.
A "kernel" is the heart and soul of an operating system. Around it and its APIs everything else is built.
Windows 7, for example, is built ontop of the Windows NT 6.1 kernel.
What exactly do you mean by "retard mode" in Vista and 7?
P.S.: If you're referring to User Account Control, it's you who's the retard.
; )
Click to expand...
Click to collapse
Heh. Nah, I wasn't talking about UAC though I guess you can count that. I was mainly thinking of stuff like the ability to show hidden files, hidden menu bars in Vista, admin settings and various other more advanced features that are hidden by default all throughout every version of desktop Windows but still easily disabled/found if power users need them. The CE platforms never got so lucky. Things just get removed for the hell of it to make room for crap in ROM or when they "confuse the user". It sure would be nice if Pocket IE still let you configure half the things it let you back in 1997... I really don't like this trend of removing and simplifying things just because it is a "Mobile" version.

TFGBD said:
Heh. Nah, I wasn't talking about UAC though I guess you can count that.
Click to expand...
Click to collapse
Well UAC has nothing to do with "retard mode", it's actually a very powerful security feature, and turning it off goes against every best practice out-line in the security handbook -- which are written and designed for IT pros.
So unless IT pros are retards...
TFGBD said:
I was mainly thinking of stuff like the ability to show hidden files, hidden menu bars in Vista, admin settings and various other more advanced features that are hidden by default all throughout every version of desktop Windows but still easily disabled/found if power users need them. The CE platforms never got so lucky. Things just get removed for the hell of it to make room for crap in ROM or when they "confuse the user". Though, I still think it would be nice if Pocket IE still let you configure half of the things it let you back in 1997... I really don't like this trend of removing and simplifying things just because it is a "Mobile" version.
Click to expand...
Click to collapse
Yeah I agree with that design.
I appreciate the need to make things "user-friendly", even if that means jack **** to me.
What I don't appreciate is when companies assume that "user-friendly" and "enthusiast-friendly" are mutually exclusive. You just have to hide the enthusiast/power user/pro features in such a way that they're immediately accessible to their target audiences, without confusing or getting in the way of the average user.
I don't understand why Microsoft -- a company that's become the master of this -- has decided to just totally divorce themselves from it in their up-and-coming mobile platform.
The only thing I can think of is that the WP7S team is a bunch of modern tech populist assholes who can't get their heads close enough to being out of their ass to see anything beyond "iPhone" and "cloud computing".

Extracting Native APIs? Possible...maybe.

Okay, so since the unlocked emulator has a file manager and task manager, does that mean it would be possible to extract them and run them on an actual WP7S device? And if that was possible, would it also be possible to extract the Native APIs from these apps? I'm fairly certain that they use Native APIs because ordinary apps can only access their own directory. I'm not very smart with these things, so sorry if it's obviously impossible or something.

It's wince - the native API is always there, where do you want to extract it from? Also some people figured out most WP7 apps from the emulator ROM are written in native as well. it's always here.
But you can't just put file manager on a WP7 device because there's no access for you to put anything on it, except apps from Marketplace you got the picture? even if we could cook our custom ROMs in the future the only thing we could do is throw in our own DLLs, services or background tools on it and customize it a little. I still doubt you'd be able to develop real WP7 style apps like a file manager or registry editor because the GUI is supposed to be written in Silverlight/XNA. And from those frameworks you can't access the native API unless Microsoft would add support for it.
101% dumb phone. If you think about it then WP7 is even WORSE then iphone.

But what if you could use Visual Studio to load it onto the device? If you look around in it, there is an option for that.

Actual devices will have to be unlocked for developement purposes to allow sideloading through Visual Studio and even then I doubt the system would be able to deploy native code. Developer phone means a yearly fee for membership in the MS developer programm.
I don't think that using native APIs from managed code would be impossible in the SDK - carriers, e.g. will be allowed to use it, but for normal applications the Security Context in .Net would prevent the programm from calling them (Code Security Managers are configurably available in Java and .Net from the beginning, so i believe that would be what MS uses to block access).
And of course programs using those wouldn't get on the marketplace.

Oh, too bad then, but thanks for your response anyway!

Fdo35 said:
Okay, so since the unlocked emulator has a file manager and task manager, does that mean it would be possible to extract them and run them on an actual WP7S device? And if that was possible, would it also be possible to extract the Native APIs from these apps? I'm fairly certain that they use Native APIs because ordinary apps can only access their own directory. I'm not very smart with these things, so sorry if it's obviously impossible or something.
Click to expand...
Click to collapse
Okay, the issue here is the lack of a few key DLLs: Windows 7 Series will not offer GDI most likely (I'm downloading the emulator set now, and will confirm this soon) and will lack comctl32.dll and the like, removing these functions. As it's been stated before, like Windows 7 uses the 6.1 NT Kernel, Windows Phone 7 series uses the 6.5 Windows CE kernel, at least, last that I've heard. It would then be both possible to bring Windows Mobile 6.5 DLLs over, but anything that calls GDI will not work. Solution? Make a mock GDI that uses the new render.
This isn't new either, Windows 7 uses WPF more than ever (Which composes most of the games as well as Windows Media Center), which is a 3D accelerated and fancier way to draw to the screen, and Windows 7's GDI subset has been updated to allow hardware acceleration granted the graphics card allows it (It's actually something the video card driver must tell Windows, as MSDN states)

Deploy native code, no. Run it, of course
I'll be investigating the possibility of native code here shortly. Chances are, you will need to set the target to ARMV6, and set the compile type to Native, not Windows. Most developers, if not all, probably have overlooked this.

I would expect that it'll require privileged access to run native code, so you'll need to solve the code signing problem.

ThymeCypher said:
Okay, the issue here is the lack of a few key DLLs: Windows 7 Series will not offer GDI most likely (I'm downloading the emulator set now, and will confirm this soon) and will lack comctl32.dll and the like, removing these functions. As it's been stated before, like Windows 7 uses the 6.1 NT Kernel, Windows Phone 7 series uses the 6.5 Windows CE kernel, at least, last that I've heard. It would then be both possible to bring Windows Mobile 6.5 DLLs over, but anything that calls GDI will not work. Solution? Make a mock GDI that uses the new render.
Click to expand...
Click to collapse
Well, I doubt things like comctl.dll and some other things like GWES will be that big of an issue once Platform Builder 7 is released and we can just generate these components ourselves. Hell, adding back GDI support (if those rumors aren't just lies) may be as easy as replacing the GWES with a less crippled one generated by Platform Builder. Maybe GDI support is still compiled in but just doesn't output directly to the screen using the default graphics driver implementation. That's how the Dreamcast implementation of Windows CE was. To even see apps like IE on the screen, you need to copy the contents of the standard WinCE GDI output to a DirectDraw surface.
What I'm more worried about is the hackability of the hardware/software. I'm really hoping it's not as insanely locked down to the point to being unhackable like every Zune.

do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?

RAMMANN said:
do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?
Click to expand...
Click to collapse
Platformbuilder is for the OS, which is Windows CE. There is still some debate as to what version the emulator is running, leaving alone the possibility that the actual version of the OS may be different at release.
If the CE6R3 camp is right, you can get platform builder for that right now, though you wont have telshell.exe (WP7 replacement for explorer.exe), and the WP7 specific apps. It would be an interesting exercise to see if they could be run on CE6R3. If no one beats me to the punch, I plan on trying this for myself when I am less swamped at work.
If the CE7 camp is right, you will have to wait till MS releases that version to the public. And they WILL release it because there are far too many embedded systems outside of phones that run on CE for them to neglect it.

No, I was talking about the generic Windows CE 7.0 Platform Builder and not the OEM specific OAK for WP7S. Unless MS plans to completely drop their generic Embedded Windows CE offerings, I see no reason why PB 7.0 will not be released and help with hacking WP7S (if it is even based on 7.0). You always needed to be a large ODM and sing an NDA to use a Platform Builder addon/OAK for the MS platforms like Pocket PC. Those almost never leak and I can't imagine this would be much different.

RAMMANN said:
do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?
Click to expand...
Click to collapse
Yes, platform builder was used to build leaked wp7 arm image.
d:\wm700_6176\platform\common\src
\soc\qcom_v1\oal\power\sleep.c
It is from from nk.exe

use dumpbin.exe to get all methods in dll/exe

[Q] Windows Mobile professional apps on standard

Why some apps which are designed for windows mobile professional doesn't work on windows mobile standard?
It shows error: an unexpected error has occurred in ... . In details: at Microsoft.AGL.Common.MISC.HandleAr(PAL_ERROR ar) at ... .
Is it possible to make them work on it?

mat1371 said:
Why some apps which are designed for windows mobile professional doesn't work on windows mobile standard?
Click to expand...
Click to collapse
The error is probably being thrown because some object is not supported under the Standard SDK.
There are several .Net Compact Framework Windows Forms components that cannot be used on a 'Standard' smart phone.
A button to name but one. You cannot click it as there is no touch screen. An alternative method would be to use the menu bar instead so the user can just press the relative real menu button under it.
Other items are Splitters, Tab Controls, UpDown Numeric Spinners, Calendars, Listboxes etc. etc.
It is possible to write a program that can run on either Professional or Standard, and behave accordingly, but it is a lot more work, and must be decided at design time.
It cannot be 'made' to work, short of obtaining the source code and re-engineering it to run under the Standard SDK.

[Q] Tablet / Desktop/Phone app compatiblity

Hello:
This is my first posting here and I'll be getting a Surface RT tablet this thanks giving. I have a iMac 2013 running Windows 8.1 and Visual Studio 2013 Ultimate thru MSDN.
I would like to develop Windows Store desktop/tablet/phone apps (using C#, XAML) or Xojo that should run on Surface RT, Surface Pro, Windows Phone, Windows 8, Windows 7, Vista and XP (supporting both 32 bit and 64 bit). I wanted to know whether the desktop apps I'm developing would run on all of these environments or is it limted to run only on Surface variants. The intent of buying a Surface RT is to take it to college while at the same time test the apps on Surface RT and deploy to the Windows store. I'm confused on the ARM and Intel/AMD cpus and do I need to change anything in Visual Studio 2013 config to target these environments.
Please advise.

ARM vs x86 is simple enough to cover quickly. Computer processors always use a particular "instruction set" to tell them what to do. x86 is one instruction set, ARM is another instruction set, an ARM processor of course uses the ARM instruction set and an x86 processor uses the x86 instruction set.
Computer software is usually compiled from human readable source code into machine code which the processor then executes or they are interpreted where a piece of software which has already been compiled via the previous method then reads your source code and processes the output directly (as they rely on existing software, you cant write an operating system in an interpreted language, they are often referred to as scripting languages instead of programming languages but in terms of application software they are sometimes just as capable if just slightly slower). Then standing write in the middle you get the bytecode languages, you take human readable source code and compile it into bytecode, the bytecode essentially being an instruction set for a processor which doesn't exist in hardware, you then take a piece of software called a virtual machine which takes the bytecode and processes the output, sort of a half way between being fully compiled and fully interpreted.
Java compiles to java bytecode for the java virtual machine, as long as you have a functional java virtual machine you can run your java application on any platform (and java is indeed on most desktop operating systems and on multiple instruction sets). C# and Visual Basic .NET both compile to .NET Bytecode for the .NET virtual machine, again, with a functional .NET virtual machine you can run a C# application on any platform (unfortunately only windows (including RT) has microsofts official .NET virtual machine, but mono is compatible and runs on other platforms too). C or C++ are compiled, compiled languages must be compiled for a particular operating system and instruction set. Python, lua or batch are interpreted, as long as you have a functional interpreter they will run on any platform. One thing to take note of, in theory it is possible to take a particular programming language, lets say a compiled one, and then write an interpreter for it instead of a compiler (and there are indeed C interpreters) or an interpreted language and write a compiler for it (has been done too), but we are ignoring that.
Visual studio will build windows applications in C/C++ or it is the IDE of choice for C# or VB.net on .NET. No surface limitations, with plugins (or considering usage of mono on other operating systems) it can even do extra platforms and languages too (I personally use it for python and have used it for arduino microcontrollers). It supports both ARM and x86 for C/C++, I admit I have not tried C/C++ in visual studio for windows software so I dont know if it simply builds your software 2/3 times or if you need to manually select ARM but the drop down for it is in the build configuration manager either way so you can always take a look in there for yourself, for .NET it says Any CPU (it is possible to tell it to make an x86 or ARM only .NET application, I am yet to come across why with the exception of perhaps optimisations). Windows store apps generally have to be done in Visual studio and officially your only options for store apps are C++, C#, VB.net and Javascript.
Store apps in my opinion are *not* a good introduction to programming. Console applications are far better to start off with. Leaves you with an issue, windows RT cannot run any application except store apps without a digital signature attached to the executable, which is great but we have no way of obtaining those signatures ourselves, only microsoft do. End result is that you can compile your C project for ARM from visual studio or take a .NET application, but you cant run it on the RT (which is an ARM device). Useful huh? Someone wrote a jailbreak which removes this restriction, but its for RT 8.0 only, the 8.1 update breaks it.
Also windows store apps are different from windows phone apps. You wont be able to write an app for both. You would have to write 2 entirely seperate apps. Only windows 8, 8.1, RT and RT 8.1 can run store apps. Only windows phone can run windows phone apps. Officially only windows 8 (including 8.1) and below can run desktop. Your cross platform ambitions are just that, ambitions. For 1 beginner, they are unattainable.
Xojo is for web apps, aka glorified websites.