Does any one out there know how to edit the .exe files so that I can turn them into VGA (96dpi) for the Uni?
I have tried with the Camera and WLanMgr modules and neither of them seem to work so I don't know what I am doing wrong.
I have tried PE Explorer, XN Resource Editor and Resource Hacker but none of them seem to work. Is there any sort of builtin checksum or protection.
Thanks in advance,
Pug
I think Visual Studio is the best resource editor for this job.
However, examine Azhad's work on fixed VGA apps, he did great work.
From memory, you have to create a new resource dll and sign it. But I'm not sure, I got for less direct routes personally.
V
pug said:
Does any one out there know how to edit the .exe files so that I can turn them into VGA (96dpi) for the Uni?
I have tried with the Camera and WLanMgr modules and neither of them seem to work so I don't know what I am doing wrong.
I have tried PE Explorer, XN Resource Editor and Resource Hacker but none of them seem to work. Is there any sort of builtin checksum or protection.
Thanks in advance,
Pug
Click to expand...
Click to collapse
I am using Tweaks2k2 always, the VGA hack is built in there. You just have to browse for the .exe file and click a button to apply "VGA brute force".
pug said:
Does any one out there know how to edit the .exe files so that I can turn them into VGA (96dpi) for the Uni?
I have tried with the Camera and WLanMgr modules and neither of them seem to work so I don't know what I am doing wrong.
I have tried PE Explorer, XN Resource Editor and Resource Hacker but none of them seem to work. Is there any sort of builtin checksum or protection.
Thanks in advance,
Pug
Click to expand...
Click to collapse
DPI aware applications just check in the registry which DPI is used.
QVGA Pocket Pc, 176 x 220 Smartphone & 240x240 Pocket PC have a resolution of 96 dpi.
VGA Pocket Pc & 480x480 Pocket Pc have a resolution of 192 dpi.
QVGA Smartphone has a resolution of 131 dpi.
This info can be found in MSDN (Windows Mobile Version 5.0 SDK, High DPI Display)
Windows Mobile Version 5.0 SDK, User Interface layout:
UI elements whose positions and sizes are specified in pixel coordinates that assume 96-DPI will be incorrect in high DPI. In general, all UI elements should be laid out using scaled positions and sizes, or relative to controls, fonts, or system metrics.
The GetDeviceCaps Windows CE-based function can be used to obtain a display's DPI by passing in either LOGPIXELSX or LOGPIXELSY as the second parameter. The CrosswordSample demonstrates how you can define SCALEX and SCALEY macros to apply a scaling factor based on information from GetDeviceCaps.
You can continue to work in pixels but remove assumptions about the DPI by:
Using the SCALEX and SCALEY macros to scale 96-DPI pixel coordinates, or using the metrics returned by GetSystemMetrics.
Expressing sizes or positions relative to other controls.
Expressing sizes or positions relative to a font.
Dialog boxes already use font sizes to determine their layout, so typically they need no special modification to work on high-DPI devices.
Here is an example of positioning a window with DPI awareness, where x, y, dx, and dy are pixel coordinates in 96-DPI:
SetWindowPos(hwnd, NULL, SCALEX(x), SCALEY, SCALEX(dx), SCALEY(dy), SWP_NOZORDER);
If you choose to scale 96-DPI pixel metrics, be aware of rounding problems when using integers. For example, SCALEX(a + b) may not equal (SCALEX(a) + SCALEX(b)) because of rounding issues.
For drawing lines or images and icons, the same should be applied.
So even if you change the size of the resources, the application will try to find and scale the image with the dpi found in the registry.
The dpi values are stored under:
HKLM/System/GWE/Display
Cheers,
.Fred
Thanks for the info guys,
Just read it so will shoot off and have a look at all the info and see which works best for me.
Once again, thanks.
Pug
Battery
I'm 200% sure the battery is gone, b'coz i faced the same problem with my Dopod 900. Strange, it was just 4 months old and the battery just gone.
I replaced it by warranty, but I was privately told there was a problem in some deliveris with battery
Related
Quite a long while since I've started a thread. Here goes.
Have you ever tried skinning (as in creating skin) an application that requires you to have bits and pieces of graphics to form a bigger graphics. And, you are thinking, instead of pieces of graphics, it maybe easier for you to 'skin' the big graphics and then slice the pieces out. But it is PAIN to slice these graphics from a big chunk. For example, I've tried to skin the Eten dialer skin (more information here) and having to cut the pieces out of the 'bigger picture' is just not easy. Consider that I can do a quick job photoshopping the skins, slicing up the thing is SERIOUSLY PAINFUL.
So, now I introduce you to the GRAPHIC SLICER 3000. Ok, just graphic slicer. Written in Java (sorry for being a Java program, I know many of you hate it, but it is much faster for me to work with Java). This program reads an XML file, for coordinates to slice up chunks of graphics from a larger graphics. Once you have the XML configuration file done, you can happily just skin the big picture and slice as many times as you want. So, now you can leave the slicing for while you go onto bigger things, like 'skinning'!
Attached are two ZIP files.
GraphicSlicer.zip (12.4 KB)
- the Java class files
- a Windows executable BAT file
- short documents on the usage
BlackGlass_Blue.zip (1.32 MB)
- the guinea pig I used to test the software, works of http://www.paulya.com/
- you need this if you want to try a Quick Start on the software
- it has the original files as well as the files that I made to try to the slicing
- it is recommended that you download this file as all the graphics are marked with red borders, such that you can clearly see which parts goes where. If you are a Eten skin skinner, this will EASE the process A LOT.
Let me know if it doesn't work.. and also let me know if it works. I want to know if (if any) many is using relatively good Java (1.4) enabled PCs.
Limitation:
- XML configured
- no GUI
- read write BMP files only
--------------------------------------------------------------------
UPDATES:
22th January'07: GUI is tougher than I though. Won't be out soon especially the software doesn't seems to be much in demand. Rush me if you want GUI
20th January'07: GUI version will be out soon. Attached figure illustrating the advantages of GraphicSlicer in skinning.
Themes Browser
I have uploaded a Windows Mobile Theme Browser which will maybe useful to skinners and allows to see your themes collection easily, without using a huge and more complicated program as ThemeGenCE.
Download : BrowseThemeCE
Here is the help :
BrowseThemeCE.exe (Version 1.0)
- Choose English version by clicking on the flag.
At run, a new subfolder, BTExtractImg, in the same folder as the program.
A ListBox is filled with all Themes (Extension ‘.TSK’) found in the program folder.
Search folder may be changed by clicking on the Folder Selection button in the Toolbar.
By clicking on a theme in the ListBox, all Themes’ elements are extracted in BTExtractImg.
In this subfolder there are the 1 to 4 images of the theme, rebuilt INF file, built XML file and an INI file more synthetic and easier to understand.
Images are shown on the form (with theme specifications and the Hint shows image type - JPG, BMP, - and resolution). A click on images gives a real preview.
Evaluation of dominant hue in images by clicking on the « colors » button in the Toolbar.
Others theme specifications are shown on the form and may be seen in the 3 memos INF, XML and INI.
This program accepts « Drag and Drop » of a theme on the form. It also accepts option « Open with… ».
WVGA format
Thank you BenThon for this “friendly” program, now it’ s fast open the tsk files and to show what is inside.
I'm trying to create a skin like xperia pda (for my phone) so I dumped the tsk file (WVGA) from xperia rom ... but BrowseThemeCe can’t show this format (and also ThemeGenCe).
Any chance, in the future, for this?
I have done it but not yet released ! But I have a problem for WVGA and WQVGA, but maybe you can help me ?
Ihave adapt also ThemeGenCE for these 2 formats but I do not know if these files are valid. It works as CAB in the Microsoft emulator but not well !!! I have no pocketpc with these format to test this :
For WQVGA
stwater_240_400.gif
stwater_400_240.gif
tdywater_240_400.gif
tdywater_400_240.gif
For WVGA
stwater_480_800.gif
stwater_800_480.gif
tdywater_480_800.gif
tdywater_800_480.gif
I dumped the tsk file (WVGA) from xperia rom
Click to expand...
Click to collapse
I will be pleased to have this TSK, if you can give it to me.
Waiting for your help, friendly,
Benoît
tsk files
I have not got a WVGA pocketpc, I am sorry, i can not test it!
(I would like only porting the xperia skin to qvga!)
I attached a folder, I hope can help!
Thanks for the TSK ! New ThemeGenCE Beta version (maybe released soon if it works) can do these themes now ! Are you sure they work on a WVGA PDA ?
The only difference I found with my own themes for this format is the folder of installation.
In the theme you sent me you have (which have specific keys) :
[CEStrings]
Appname = "XPERIA Silver"
InstallDir = "%CE1%\%AppName%" ; (\Program Files\XPERIA Silver)
[CEStrings]
Appname = "XPERIA Black"
InstallDir = "%CE1%\%AppName%" ; (\Program Files\XPERIA Black)
but in ThemeGenCE I still put the InstallDir in \Windows like this :
[CEStrings]
Appname = "Rubics"
InstallDir = "%CE2%" ; (\Windows)
That is maybe the reason why my themes built with my beta version of ThemeGenCE did not work in Microsoft Emulator (and maybe on PDA ?)
This evening I will release a new version of BrowseThemeCE which can read such themes.
And maybe soon, if I have Beta Testers for themes for WVGA and WQVGA themes, a new release for ThemeGenCE...
uhery said:
I attached a folder, I hope can help!
Click to expand...
Click to collapse
Could you say me where you have found these themes ?
Thanks.
BenThon said:
Could you say me where you have found these themes ?
Thanks.
Click to expand...
Click to collapse
I tried to find the xperia graphic files so I dumped this rom:
http://forum.xda-developers.com/showthread.php?t=407148.
I found the tsk files but, in the pc where I’m working, wincecabmanager is not installed ... so ...I tried your program and ...it did not work!
but…just for the moment ... I hope!
That is all! Bye!
A new version (version 1.1) is now available for the program BrowseThemeCE .
This version directly shows Standard Colors defined in the Theme and possibly Specific Colors : small icon beside color items.
Besides, and waiting for validation, this version allows WVGA and WQVGA theme exploration defined with specific files such as :
For WQVGA
stwater_240_400.gif
stwater_400_240.gif
tdywater_240_400.gif
tdywater_400_240.gif
For WVGA
stwater_480_800.gif
stwater_800_480.gif
tdywater_480_800.gif
tdywater_800_480.gif
Such themes would have been found in ROM, notably in XPERIA ...
A new version of ThemeGenCE already exists for such themes, but it requires Beta Testers validation.
uhery said:
I tried to find the xperia graphic files so I dumped this rom:
http://forum.xda-developers.com/showthread.php?t=407148.
I found the tsk files but, in the pc where I’m working, wincecabmanager is not installed ... so ...I tried your program and ...it did not work!
but…just for the moment ... I hope!
That is all! Bye!
Click to expand...
Click to collapse
Is it an official ROM ?
I hope your program also support sqvga (square screen) 320 x 320 and 240 x 240 for older ppc phones.
By the way, themeGenCE works for square screen, and I have generated a few themes using that.
Last but not least, thanks for developing the software. Wonderful I must say.
g00ndu said:
I hope your program also support sqvga (square screen) 320 x 320 and 240 x 240 for older ppc phones.
By the way, ThemeGenCE works for square screen, and I have generated a few themes using that.
Last but not least, thanks for developing the software. Wonderful I must say.
Click to expand...
Click to collapse
ThemeGenCE in the published version already make square screen (predefined 240x240 in options) because you can define in Options the size you want for images !
But, for now, DPI can only be set to 48, 96 and 192 with this version ! With the beta I have in my bag, I have added 128 and 131 ! regards articles on MSDN :
Windows Mobile 6 Standard SDK
Windows Mobile 6 Standard (176x220 pixels - 96 dpi)
Windows Mobile 6 Standard Landscape QVGA (240x320 pixels - 131 dpi)
Windows Mobile 6 Standard QVGA (320x240 pixels - 131 dpi)
Windows Mobile 6 Professional SDK
Windows Mobile 6 Classic (240x320 pixels - 96 dpi)
Windows Mobile 6 Professional (240x320 pixels - 96 dpi)
Windows Mobile 6 Professional Square (240x240 pixels - 96 dpi)
Windows Mobile 6 Professional Square QVGA (320x320 pixels - 128 dpi)
Windows Mobile 6 Professional Square VGA (480x480 pixels - 192 dpi)
Windows Mobile 6 Professional VGA (480x640 pixels - 192 dpi)
Windows Mobile 6.1 Standard
DPI: 131 - Resolution: 320 x 320 pixels
DPI: 131 - Resolution: 400 x 240 pixels
DPI: 131 - Resolution: 440 x 240 pixels
Windows Mobile 6.1 Professional
DPI: 96 - Resolution: 240 x 400 pixels
DPI: 192 - Resolution 480 x 800 pixels
____________________________________________________
But for my problem :
uhery said:
I tried to find the xperia graphic files so I dumped this rom:
http://forum.xda-developers.com/showthread.php?t=407148.
Click to expand...
Click to collapse
Is it an OFFICIAL ROM ?
Is there anybody who can help me with WVGA and WQVGA themes ?
Thanks a lot for your efforts!
I don’t know if could help you … I don’t know if that rom is an official rom (I’m not a programmer)!
… but I found other things about tsk inside that rom … anyway… I attach the files ... otherwise they came to nothing!
I only hope it could help!
bye!
Thanks !
I ask for more help in this thread : "With a Little Help from My Friends"... New Themes (WM6.1)
And I comment the file SEUS_TSKAllowedReg.CAB
Hi..All,
I was developed windows mobile 6.1 Application.. I Installed it on Windows mobile 6.5.. That device is little bit longer(HTC).
But, Application work half of the device remaining part is shown an white..? I dont know why it occurs..
That correspoding emulator is 480*800 WVGA Emulator it was too large..
how can I solve the problem.. Its very urgent..
Eagerly waiting for the reply
Thanks in advance,
Bell
This can be one of the biggest bugbears of writing Windows Mobile applications. You write an app for one platform, your own perhaps. As good a choice as any, but when you run it on another device, it is all over the road.
It is a total pain in the butt, but do not assume anything.
Question 1. Is the device in landscape or portrait mode. How do you know?
Question 2. Are the dimensions of any of your screen objects hard coded into the program. If the answer is yes, it may be time for a rethink.
Answer 1: Use GetClientRect() [C++] or the Form.ClientRectangle property [.NET] to find the actual size of the window. This can determine a portrait, square, or landscape layout, dependant on the values. Remember that this can change during the time the app is running, so trap it in the WM_PAINT message [C++ Win32], ::OnPaint() event [C++ MFC], or Form1_Paint() event [.NET].
Answer 2: Use the values of those returned by Answer 1 to size your screen objects to fit, and also to centre the things on the form. Not hard coded but dynamically changed to fit. This may involve a serious rewrite of your app, but it will then work across all machines.
The real pain appears with bitmap or raster drawn objects which can look a bit crappy if resized. In this case another, simpler, approach may be much better.
GNU Boy CE is a GameBoy/GameBoy Color emulator for the Windows CE platform developed. As a result, this is the first and only emulator I have been able to run on my Omnia 2 for these consoles that have fully working sound with frame skipping set to 0. Believe it or not, this aging application already supports a touch screen based virtual controller.
Here is the link (where you will also find the source code for the newest version:
http://gnuboyce.berlios.de/
The only problem is that this application has not seen an update in about 7 years. So, the source code is assuming your screen size is tiny. The native resolution for the GameBoy games is 160 pixels wide. The emulator does have a x1.5 stretch in it which pushes that to 220 pixels. It would be nice to replace the 1.5 times stretch with a 2.5 times stretch (400 pixels wide and ideal for a WVGA resolution screen.)
From what I can tell the following files appear to deal with the screen output:
lcd.c
lcd.h
lcdc.c
The truth is that I am only a novice programmer. So honestly, I am only guessing at this. I am hoping someone would be so kind as to make the revision to the application and make a new CAB since everything else about it is ideal. It uses next to no system resources on a WM device and allows for true sound.
Thank-you ever so much to anyone who takes the effort. By all means, feel free to take this program further if you like because I imagine that with this simple change that this will quickly become the most sought after GameBoy/GameBoy Color emulator for WM devices.
This website has some more recent sources (another mod).
In there are also sources for other emus however they don't have direct draw display nor onscreen buttons. If anyone could add those feature it'd be really cool (maybe using PocketSnes source at least for the onscreen controls).
The source for that application is definitely newer. Unfortunately, no touch screen controls (I have an Omnia II which has no buttons to play the game with.) Same problem with this update as the last. The emulator needs to be updated to have a 2.5x stretch instead of a 1.5x stretch to take advantage of the resolution.
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.