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

Quake III and OpenGL

Hey there!
I'm wondering if OpenGL games, like Quake III, can be ported just like they did for Android with Kwaak3.
Does WinPho7 support OpenGL ES in addition to DX9c?
Best Regards Mr.Sir (Gustaf)

I googled around and it appears that XNA will be the only choice besides silverlight for app/game development. So if you can somehow port an OpenGL came to XNA, then yes.

Mr.Sir said:
Hey there!
I'm wondering if OpenGL games, like Quake III, can be ported just like they did for Android with Kwaak3.
Does WinPho7 support OpenGL ES in addition to DX9c?
Best Regards Mr.Sir (Gustaf)
Click to expand...
Click to collapse
Nope. It's only what you will find in XNA. There are several samples people have posted for porting on xbox 360; same code will work on the phone with VERY little changes.

So, seriously guys, no native support? I mean, when i was working at NDrive they had everything written in C++ with interfaces for each device. I doubt that any sane company will rewrite its software completly just to compete in a niche...
Even in .NET CF you COULD do some PInvokes which kinda allowed you to attempt to run a managed version of OpenGL (.NET sucked and still sucks for serious game development, obviously) which was slow as hell, but at least it was there.
So please, native support!

ei05035 said:
.NET sucked and still sucks for serious game development, obviously) which was slow as hell, but at least it was there.
Click to expand...
Click to collapse
That's why it is entitled with XNA

Yup Buddy but its gud because you have to code only one time and then you can able to convert it for using on other platforms..

And by several platforms you say M$ based ones. I mean, most companies (i can give you the example of NDrive as I was there for a while) would rather code in C++ and create interfaces for specific platforms. No native code support kills it. I don't see companies renaming extensions to .cs, enabling unsafe code (pointers, etc) and giving it a good dose of whisfull thinking.
Oh and when I meant that XNA sucked for serious gaming i meant really. AAA games don't rely on that. They rely on GPU manufacters SDKs and on the good ol' DirectX SDK. This is if they don't have some housemade engine (like Crytek) similar to Shiva3D or Unity (but custom tailored).
I mean, seriously. In .NET CF 3.5, give it a go, try to natively rotate an image and resize it without manually processing the bitmap information to do so (and at the expense of CPU usage). I had to rely on DxSprites and OpenGL when I needed.
XNA is, as it was already mentioned, game-wise, a game-loop oriented tool with a few PInvokes to DirectX...

ei05035 said:
And by several platforms you say M$ based ones. I mean, most companies (i can give you the example of NDrive as I was there for a while) would rather code in C++ and create interfaces for specific platforms. No native code support kills it. I don't see companies renaming extensions to .cs, enabling unsafe code (pointers, etc) and giving it a good dose of whisfull thinking.
Oh and when I meant that XNA sucked for serious gaming i meant really. AAA games don't rely on that. They rely on GPU manufacters SDKs and on the good ol' DirectX SDK. This is if they don't have some housemade engine (like Crytek) similar to Shiva3D or Unity (but custom tailored).
I mean, seriously. In .NET CF 3.5, give it a go, try to natively rotate an image and resize it without manually processing the bitmap information to do so (and at the expense of CPU usage). I had to rely on DxSprites and OpenGL when I needed.
XNA is, as it was already mentioned, game-wise, a game-loop oriented tool with a few PInvokes to DirectX...
Click to expand...
Click to collapse
If you are so gung-ho, you could write wrappers in C++, compile the DLL and pinvoke your calls.

tyrannus said:
If you are so gung-ho, you could write wrappers in C++, compile the DLL and pinvoke your calls.
Click to expand...
Click to collapse
Exactly! Honestly for me it is the way to go. It's not that i don't like C# or .NET, quite the contrary. I'm just sorry that they lack the portability some projects require. And for me, WP7 not having native code support is a real buzz kill. What do you think?

It does have native code support but you need Microsoft's permission to get the SDK. I'm pretty sure game companies will have it if they want to make use of the GPU as much as possible.

Thoughts on Unlocking custom GPU programs...

Hey,
Currently I've been working on a game for the Windows Phone but a couple things have really irritated me during porting, one of which is they don't allow custom GPU programs...which is very stupid considering there basiceffect class is completely useless.
The Windows Phone has some awesome hardware and it sucks that its being restricted by the dev team.
So right now I'm looking at microsoft.xna.framework.graphics in reflector(the GAC version not the reference version). The effect class itself is NOT marked as security critical, but the constructor is(because it requires compiled GPU bytecode to be passed down), so the logical why would be to load it via the contentmanager, but the damn thing spits out("You are unable to compile custom effects for winphone7).
My question is does anyone know where that error is actually located?
It looks like XNA is using a custom content importer to import some kind of template called "BasicEffectReader" , and "BuiltInEffectReader" . I don't know if I'm allowed to post reflected code on here, but if you open up BasicEffectReader.cs youll find that it creates a "cloned effect" from the BuiltInEffectReader.
My other questions are, is the bytecode for Windows Phone 7 different from the 360/Windows(I'd assume so), and if so is XNA actually compiling bytecode on the fly, is it using a template for basiceffect?
If it is requires its own bytecode, what kind of methods do you guys think would be feasible to be able to create custom effects? The graphics card on the phone should follow the DX9 specs, unless its a 9.5 hybrid like the 360.
EDIT3:
Alright it looks like if you compile it on another platform, strip out the contentmanager stuff at the start of the file, it will load(passes all the header checks) but it fails because UnsafeNativeMethods.Effect.GetGlobal(graphicsDevice).CreateEffect(pEffectCode, ((uint) effectCode.Length) - num2, graphicsDevice.pComPtr, out effect_desc); returns a invalid handle...

Very surprised they don't let you use custom GPU shader programs.

Yeah I know :/ anyway I kind of got a custom program loaded, but I'm not sure about the OpCodes, so I don't know how to customize it yet.
_effect = new Effect(device, Code);
static byte[] Code = new byte[] {
0xcf, 11, 240, 0xbc, 12, 0, 0, 0, 0, 0, 0, 0, 1, 9, 0xff, 0xfe,
0x62, 0x61, 0x73, 0x69
};
Click to expand...
Click to collapse
First Int(4 bytes) are the XNA header magic number,
Next Int(4bytes) byte offset to the code(from start of the buffer).
(Offset 12) - 1, 9, 0xff, 0xfe - FX Magic Number dx9 i believe.
Next 4 bytes are the IDENTIFIER for the effect. basi <-- basiceffect, skin <-- skinable effect etc.
Click to expand...
Click to collapse
Also what version of Direct3D is the phone running? Is it a 10/11 hybrid? cause in XNAFrameworkCore.dll it references D3D11CreateDeviceAndSwapChain and it also references CreateDXGIFactory1

Has anyone got PInvoke to work? The only way to get access to the HLSL compiler for the phone is through non-exposed API's in XnaFrameworkCore.dll.
When it creates the effect it looks for the unique four byte effect iden to create the shader internally(D3D_Effect_CreateHandle in XnaFrameworkCore.dll). So to get access to the HLSL compiler and compile our own effects it looks like we have to call some of the non-exported API's from the DLL. Which shouldn't be a problem if someone has found out how to get PInvoke to work( Not the COM dll hack but actually calling PInvoke. ).
EDIT
For anyone thats interested here are the different ID's(remember the hex is actually in reverse order):
.text:1003DF68 mov eax, [ebp+var_4]
.text:1003DF6B cmp eax, 69727073h
.text:1003DF70 jz loc_1003E086
.text:1003DF76 cmp eax, 69736162h
.text:1003DF7B jz loc_1003E05F
.text:1003DF81 cmp eax, 6C617564h
.text:1003DF86 jz loc_1003E038
.text:1003DF8C cmp eax, 6D766E65h
.text:1003DF91 jz short loc_1003E009
.text:1003DF93 cmp eax, 6E696B73h
.text:1003DF98 jz short loc_1003DFD7
.text:1003DF9A cmp eax, 74736574h
.text:1003DF9F jnz loc_1003E0B5
Click to expand...
Click to collapse

crozzbreed23 said:
Has anyone got PInvoke to work? The only way to get access to the HLSL compiler for the phone is through non-exposed API's in XnaFrameworkCore.dll.
Click to expand...
Click to collapse
A number of us have tried to do it, but have failed. The correct path is probably '\Windows\X.dll.' I haven't tried that yet. It's probably worth mentioning that even if you do get it working, Microsoft has sworn to reject any app that uses PInvoke.

I know the app would be rejected, I only want to build a portfolio project that I can take with me to a job interview.
Even though a lot of the HLSL code is in XnaFrameworkCore.dll, there is a d3dcompiler dll(which is compiled against D3D10). I know this is probably something that has been answered before, but is there a method for opening up the WM ARM dll's in IDA?
My thinking is this, we can launch executables but to get access to the OS dll's we have to build valid OS libraries. I wanted to try the COM dll method, but I don't have the phone yet and the emulator obviously won't load COM dll's.
If we can get as far as calling LoadLibrary than we can call:
D3D11CreateDeviceAndSwapChain
and
CreateFactory1
Click to expand...
Click to collapse
Than ASSUMING D3DCompiler.dll works(its not referenced in the XNAFrameworkCore except for loading in the HLSL sig), we can load custom GPU programs(that are HLSL based not effect based which is just fine...) as well as exposing more of the Direct3D API.
The only reason why I want all the graphics API's is so I don't have to create a portfolio project with baked lightmaps with bumpmapping built in. Its such a shame that the GPU on the phone is going to waste because they designed a very restrictive effect interface :/.

Its a pain but it has been but there are lots of reason why they are doing that. for one when the chassis requirements where released the minimum requirement is that the gpu had to do opengl. xna is built for direct x and hence the problem, some stuff had to be ported to opengl for it to work properly, the problem wiht this is that the new chips now have directx gpus with them, and i am not sure but i believe none of the wp7 phones that have been released has any of the directx acceleration. Becuase of this and compatibility with the later phones (atleast up to next year) some stuff had to go, custom shaders for one. But i believe if you work close with microsoft they actually give you the the ability to create custom shader. I have not played much with xna for windows phone, just on xbox so i am not to sure what i can do and not do. But your post was enlightening and i will go back to it after i finish my few apps.

Yeah your right. I just read up that they are using the ADRENO 200 GPU(http://developer.qualcomm.com/dev/gpu/processors), which supports opengl es, and "Direct3D Mobile" whatever that means. But that still doesn't explain why they didn't allow custom GPU programs because everything is still being compiled down to bytecode. If the GPU can do per-pixel lighting it is more than capable of bump mapping that reacts to lighting which is why I really want to see if I can maybe extend one of the .net effect classes, but I still haven't figured out if that would mess with any of the internal core functions.
But as I did with the XNA 360 code, I got access to the UnsafeNativeMethod classes inside the framework dll that expose all the native interfaces to the core. So basically I just skip passed all the XNA init code. The only thing that creates a problem with on the phone is that they use a "messaging service" to communicate with the framework, they build a byte[] array in the .NET code and pass it to the framework which parses it and does whatever it needs to do. On the phone, pointers aren't allowed, but I might just be able to use reflection to get the messaging code.
Also I thought of something, sense the GPU supports OpenGL ES and I know that someone has been able to create a window(the FS example on Chris's site), I wonder if we create a COM dll and link against the OpenGL ES library that we can just use OpenGL rather than the "non finished" d3d api? I would try that myself but I'm not going to be able to get the phone for a couple weeks and I havent found a way to get COM dll's to work in the emulator :/

Yeah your right. I just read up that they are using the ADRENO 200 GPU(http://developer.qualcomm.com/dev/gpu/processors), which supports opengl es, and "Direct3D Mobile" whatever that means. But that still doesn't explain why they didn't allow custom GPU programs because everything is still being compiled down to bytecode. If the GPU can do per-pixel lighting it is more than capable of bump mapping that reacts to lighting which is why I really want to see if I can maybe extend one of the .net effect classes, but I still haven't figured out if that would mess with any of the internal core functions.
But as I did with the XNA 360 code, I got access to the UnsafeNativeMethod classes inside the framework dll that expose all the native interfaces to the core. So basically I just skip passed all the XNA init code. The only thing that creates a problem with on the phone is that they use a "messaging service" to communicate with the framework, they build a byte[] array in the .NET code and pass it to the framework which parses it and does whatever it needs to do. On the phone, pointers aren't allowed, but I might just be able to use reflection to get the messaging code.
Also I thought of something, sense the GPU supports OpenGL ES and I know that someone has been able to create a window(the FS example on Chris's site), I wonder if we create a COM dll and link against the OpenGL ES library that we can just use OpenGL rather than the "non finished" d3d api? I would try that myself but I'm not going to be able to get the phone for a couple weeks and I havent found a way to get COM dll's to work in the emulator :/

You can pretty much give up on that one, the COM dlls for the phone are ARM assembly, but the emulator runs on x86. Not likely to work.

[Q] What is the Mysterious UIX framework Used by WP7?

Hi guys.
Does anyone know something about the mysterious framework used by the WP7 UI!
it seem this is Microsoft Iris UI Framework but no one has ever heard of before.
only thing i have found is some dll in my zune folder on my computer.(attached uix zune.rar)
UIXrender.dll
UIX.dll
UIXcontrol.ll
UIX.renderapi.dll
UIXsup.ll
i have also attach an UIX (uib!) from the device tiles extract from dll
this is the last files we need to learn how to edit for completly rewrite the UI i think.
guys if you have some dev skill please look token file, see if we can edit it.

My best guess is that this is the replacement for GDI+ / DirectX. It is used for display rendering in 2D and 3D and used by Silverlight and XNA. Native apps (exe-files, not dll's that are run by Taskhost) that use the display invoke UIXMobile.RunApplication. This will launch xaml that is compiled to native c++ and then compiled to arm. I'm not 100% of this, but I've seen hints that support this theory while reversing some apps.

I wrote a blurb about it in March of 2010 http://www.withinwindows.com/2010/03/17/what-the-heck-is-microsoft-iris-here-are-my-notes-thus-far/ Might be a useful read, although it's not exactly in the context of Windows Phone (not much has changed).

UIX is the framework also used by the Zune Player...

AFAIK, Iris/UIX is the entire User Interface framework used by WP7 native applications.
It uses an XAML-like (XML) based markup language, but is native code rather than .Net.
All the in built applications are native, and use Iris. The .Net based WP7 libraries are emulating the look and feel of the native code.

Visual Studio Async CTP (Version 3)

Hi!
Recently I found very interesting C# language extensions called Async CTP. This Visual Studio 2010 update (compatible with WP7 Mango API 7.1 & 7.1.1) make asynchronous operations much easier and source code much more readable!
I have no practical experience (sorry, just installed and finished reading white paper) but it looks very promising and cool.
Links:
Visual Studio Async CTP (Version 3): http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9983
Whitepaper: Asynchrony in .NET: http://www.microsoft.com/download/en/details.aspx?id=14058
C# Language Specification for Asynchronous Functions: http://www.microsoft.com/download/en/details.aspx?id=23753
Enjoy!

The new async stuff is great. It makes a lot of stuff easier. It comes with extension methods for things like httpwebrequest but if there isn't an extension method for something you want to be async you can use the TaskCompletionSource. I do this with ctp3 and RestSharp in my app, it works great.
I think this stuff is in 4.5 or if you're using vs2011. If you do any metro stuff you'll see lots of async. Cool and powerfull.