Related
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
Given Andy Lees quote about WP7: "It's a very sort of advanced platform that really works across PC, phone, and console," it seems likely he's talking about Silverlight 4, especially given the boost in features that it's getting for version 4. I find this to be a very suitable platform for what they're trying to do. You can't beat multi-platform & RIA support - dev once, run on all. What do you think?
Still very propretiary
chribruu said:
Still very propretiary
Click to expand...
Click to collapse
So what? All current phones only support native applications that are created with a proprietary SDK. The big exception is Java which is executed in a VM, but these applications cannot use the full potential of each platform, because they must aim for the lowest common denominator. So without modifications, no native application will run on all platforms.
chribruu said:
Still very propretiary
Click to expand...
Click to collapse
It's not any different than the current situation really. How many people write WM code in anything other than Visual Studio?
Basically a different set of GUI libraries on .Net 3.5.
Hope they'll make SL4 available on WM6.5, too. That way it would be a much better platform choice.
You're all right. I replied without really thinking my post trough. :/
The only thing bad with SL (and flash) is if/when they become web "standards".
Just disregard that post
Sorry for the OT.
from the little i have read/seen. it seems like this will prob be the case..
Silverlight will be one of the dev platforms, along with C++ with a XAML UI.
in this video
"Behind the Design of Windows phone 7" on youtube (i could not post the link)
1:25 - 1:29
you can see the ide for wp7.
it looks like blend. that would definitely mean xaml for ui.
pensoffsky said:
in this video
"Behind the Design of Windows phone 7" on youtube (i could not post the link)
1:25 - 1:29
you can see the ide for wp7.
it looks like blend. that would definitely mean xaml for ui.
Click to expand...
Click to collapse
And as I said, C++ with a XAML UI...
XNA C#, no dubt for the games.
It's available for the Zune HD, I guess it will follow on to WP7
But maby not for the UI?? any thoughts?
From XNA.com :
XNA Game Studio 3.1 Zune Extensions, to support Zune HD, adds the following functionality to the product:
The ability to target and develop for the Zune HD media player.
The addition of new Touch APIs to the XNA Framework for use on the Zune HD.
The addition of new Accelerometer APIs to the XNA Framework for use on the Zune HD.
Click to expand...
Click to collapse
I don't really believe, that they'll be using an unmanaged language for the application developement itself (other than drivers of course).
I think it would be most likely to be using C#, perhaps more in the way of how most android apps use java, e.g. it's precompiled on deployment.
What I really hope for is that, there is no longer the limitation of 32 mb per process.
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
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?
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.