Database Users

Curious about WM5 execution, .net, emulation etc

I'm a game programmer by profession, quite knowledgeable about hardware and OSes in general, and somewhat familiar with the .net programming environment. But I can't seem to find the answer to this simple, but very important (given the abominably slow speed of WM5), question:
Do programs running on Windows Mobile devices (WM5 in particular) execute natively on the processor, or do they go through any kind of emulation or JIT compilation?
Related questions: Do all programs on WM run in the .net environment? Or can WM5 execute "native" programs as well?
Are WM .net programs installed as MSIL (non-native) assemblies? When they are executed, do they go through the .net JIT compilation process, thus causing periodic delays, and doubling the amount of precious RAM needed?
And if any "native" programs run on WM5... how "native" are they? Isn't it true that starting with WM 2003 all programs were compiled to run on the ARM processor? And that if your device had a non-ARM processor (say, oh, a TI OMAP), it had to emulate the ARM code, thus running the program at a fraction of native speed?
I can't seem to get an answer to these questions, and it's driving me buggy. I want to know whether one of the reasons WM devices are slower than an 8-bit computer is because of an evil & unnecessary (IMO) processor emulation architecture, or whether it's just due to Microsoft's terrible terrible programming in general.
Cheers

Most of WinMobile applications are "native". I.e. they are executed directly on CPU without any emulation layer. On my device there are no MSIL programs at all.
I don't know how .NET apps are executed, but probaly the process is identical to a "big PC" - something like JIT compilation.
WM5 is slower because it is more secure then older OSes, it has lots os security checks that slowdown things incredibly. It also allows mixing ARM (32-bit) and THUMB (16-bit) code in a program, and 16-bit code is typically slower. And it uses "persistent storage" - this is the main reason if incredible slowdown comparing to WM2003SE.
Regardong TI OMAP. As far as I remember it uses the same ARM/THUMB instruction sets as intel PXA CPUs. It probably does not have intel x-scale instructions, which are rarely used (mostly in games).
I want to know whether one of the reasons WM devices are slower than an 8-bit computer is because of an evil & unnecessary (IMO) processor emulation architecture, or whether it's just due to Microsoft's terrible terrible programming in general.
Click to expand...
Click to collapse
The slowdown is due to the ugly architecture of Windows Mobile OS. This is similar to all OSes made by that company - the newer the OS is, the slower it works.

new sdk with OpenGl ES support

hey. just want to share with you.
http://developer.sonyericsson.com/s...ws/newsfeb09/p_xperia_sdk_opengles_update.jsp
p.s. sorry if posted earlier but i don't find it.

i tried the link you provided but it was broken...
however, what is the implications of this... is it a certificate that allows programs to use OpenGL ES graphics rendering

flext said:
i tried the link you provided but it was broken...
however, what is the implications of this... is it a certificate that allows programs to use OpenGL ES graphics rendering
Click to expand...
Click to collapse
The link is fine.
SDK definition: http://en.wikipedia.org/wiki/Sdk
/edit "It also provides a graphics pipeline that allows free access to graphics hardware acceleration on the Xperia X1 phone through the Xperia Panel interface."

^^thanks... i wonder if this would lead to the unlocking/use of HW acceleration without panels and with games etc, that use OpenGL ES

Render-To-Texture with HTC Diamond 2

Hi everyone,
I have a small technical problem to solve and hopefully someone knows an answer for it. Someone gave me a HTC Diamond 2 (very nice toy I think). I don’t know which hardware is exactly inside the phone but I assume it’s an ATI ImageOn 2300 which fully supports OpenGL ES 1.0 + Extension Pack (that’s what GL_EXTENSION is saying). And all of these extensions are doing fine. As everyone knows HTC is not providing a D3D driver for their phones and all other drivers I have seen are just a wrapper around OpenGL ES. So using D3D is currently not an option.
I have to write an application which requires some render-to-texture functionality in realtime and here my problems are starting to grow.
[1] glCopyTexImage2D:
I recognized that glCopyTexImage2D() is very slow. My framerate is dropping dramatically from >100 frames down to ~20 frames. Somehow this is done in software by the driver and not hardware- accelerated. glCopyTexSubImage2D() is even more slow (down to ~10 frames per second), but both functions are working. I tried to move it into a different thread, but the driver is not supporting shared contexts. Also it’s not supporting two bound contexts at the same time with two different windows and threads. So this can’t be improved or I’m doing something wrong.
[2]PBuffers:
PBuffer are working fine. But PBuffers which can be bound to a texture are not supported by OpenGL ES 1.0. And that’s what happens also on this ATI card.
[3]GL_OES_framebuffer_object:
This was my preferred choice. But framebuffers are not officially supported by the installed OpenGL driver. But the libgles_cm.dll on the HTC is exporting these functions so I tried them and recognized that they are not working correctly. Somehow the vertex pipeline is allowing only triangles in the center of the viewport. All others will be discarded. When I turn it off it renders correct. Using glDrawTexiOES() will be ignored while using framebuffers. I assume that either the current implementation of the framebuffers is just waste of some development guys or the functionality is locked in some way.
[4]D3D:
Normally D3DM is supporting to switch between different rendertargets. But we are all know the D3D problem. I tested some other D3D drivers but they are not usable. Also I can’t imagine how render-to-texture will be implemented in these drivers while it’s not working in OpenGL.
I’m wondering what TouchFlow3D is using internally, whether they are using render-to-texture or not. The only thing I know is that they are using OpenGL ES and some extensions. But Manila.exe is querying the functions of libgles_cm.dll during runtime. So I have to write a few proxy dlls first and need to hook into the system to track what they are doing. And I don’t want to spend time on this.
Does someone knows an alternative to do some render-to-texture on the ATI or knows some secrets of the libgles_cm.dll which I don’t know? There are a lot of private functions inside but can’t find some documentation about it. Also ATI and Qualcomm are not very helpful to me.
Thanks.

Maybe, glReadPixels and then glTexSubImage2D (what probably glCopyTexImage2D is doing)?
(I know that this goes two times over the graphics bus, but you never know...)
What kind of scene (number of triangles, lights, textures) are you rendering with > 100fps?

glReadPixels() + glTexImage2D() is even more slow than glCopyTexImage2D...
Also this can't be parallized. I thought using AHI2DATI.dll instead to do the same thing, but I don't know how to get a surface handle from a OpenGL texture id.
>>>What kind of scene?
A very simple scene yet. Only a few depth sorted + material sorted objects (via VBO) with some textures (backed lighting) on it. Textures are compressed. Currently no lighting, no skinning or other things. While the render thread is waiting for glFinish() to return, a second thread prepares the next frame. Also the rendering thread is not redrawing the entire viewport each time.

The OpenGL texture id is the handle. There's nothing more you can do with it. PBuffers or framebuffer objects are the only way I know for doing performant render to texture in OpenGL.

No...I mean the surface handle of the AHI2DATI library. Here you have access to the raw data of the surface. Somehow the libgles_cm.dll uses these surfaces for it own buffers and/or textures or not?!
But this is not really useful unless someone tells us whats going on inside libgles_cm.dll.
See:http://greengalaxy.wordpress.com/2009/04/18/ati-direct-access-to-hardware/

Hi jeansmsixer, I don't think there is no efficient way to do it. Have you tried eglCopyBuffers?
Aren't all textures stored in system memory? - they surely have to be because the device reports no available video mem.
Even if you get a pointer to the color buffer, it's impossible to wrap the memory in a HBITMAP to select onto a HDC and use GDI fonts for instance. (which is what I need to do).
If you do write the proxy dll like you were suggesting, can you please let me know what TF3D does for fonts? Are they textures or have they somehow mixed 3D with GDI?

Hi jeansmsixer, something else you could try is what is described here:
http://brewforums.qualcomm.com/showthread.php?t=10668
Looking on glbenchmark.com it looks like HTC devices support the extension. You should be able to get a pointer directly to the color buffer (which I presume is in normal system memory) so you could copy off pixels fairly efficiently with your own memcpy(). However, you will need to eglWaitGL() etc to ensure 3d stuff is complete before attempting to access it.
I love the irony of the only helpful information for WM opengl being found on a brew site for symbian. If WM7 is as terrible as the current mess, then I'm moving to iPhone.

A Few questions regarding development for android..

Hello all,
I'm now the proud owner of an android phone (htc desire) and as a hobbiest programmer i'm of course intrested in making (free) apps for it. I come from a linux based devices background (like gp2x, wiz, dingoo a320) etc. So i'm used to the gcc toolchains and libs and I read a bit around about android programming. Am i correct in saying that is not possible to just use a gcc toolchain for programming android apps since android uses some sort of java virtual machine ?
Or is this possible after all, just like one woud make apps for linux based devices. I think the Answer will be NO but i still ask since i wasn't certain and did not find that much information about it.
Suppose it is not possible, my only option for porting linux based games / apps would be to use the NDK and split up the main functions of a game and make a shared lib out of it, which could be called using JNI from java right ?
But i have a question if this is the case...
I can't really imagine that all phone manufactures use the same hardware in their phone or even the same architecture, so suppose i would use the NDK to create a shared lib with basic functions of a game i wish to port, wouldn't this lib need to be build for the specific architecture of a certain phone and thus could only work on that phone ? or are all android phones arm based ?
So you could say my question basically comes down to this :
Will Using the ndk and apps created with it, be less compatible then a java only app for all the droid phones out there ?
thanks

hmm seems i can answer my own questions now, i hadn't looked at the official ndk site itselve yet and did not know it would have all the info i needed.
So using gcc toolchains only does not work,
android uses a (modified ?)java virtual machine called dalvik
de libraries do have to be build for a specific architecture, and all droid's (phones) do seem to run on arm, but in the future the x86 architecture will be supported as well.
HOWEVER,
one can target ARMv5TE or ARMv7-A (and in the future x86) and include the needed libs (per architecture) in the apk file, the droid system will do the rest by checking if a lib for the specific architecture is availible or not.
also it's worth to note that ARMv5TE libs should work on any arm based droid phone, BUT without hardware fpu support. Since all the (linux based) devices i programmed for had no hardware fpu either and weren't as near as powerfull as my desire is, i don't think using software floating point would be a problem for my needs and if it i do need it i can always use fixed point math.
Just thought i should write a small excerpt of that page here, since there might be other people looking for it eventually

[Q] Windows 8 on ARM

As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
- No native support for x86 apps on ARM, nor ARM apps on x86. Only .NET apps would work in both worlds.
But it is possible to create an emulator similar to DosBox that would run native x86 programs on WoA and, for example, I'm currently working in this direction.
- Though existing C++ apps can be recompiled for ARM from sources, it is not a 100% working solution. Current VS11 contains a rather limited set of ARM libraries - no DirectX libs earlier than 11, no import libraries for NtDll.Dll and similar DLLs.
I don't have access to any WoA builds, so I can't check whether these features are completely removed from ARM, or those LIBs are just not present in current VS11 build. But at least now we can compile test apps for ARM and analyze the code (though we don't have where to execute them yet).
- Native WoA programs use THUMB2 instruction set (ARMv7 and above). Though ARM instruction set would be supported too.
- According to "Microsoft Portable Executable and Common Object File Format Specification v8.2" WoA machine type in PE files would be 0x1c4, and some new relocations types are added (for example IMAGE_REL_BASED_ARM_MOV32T = 7). IDA understands such EXE files, though complains on relocs.
- SEH is implemented in a different way than on x86 (similar to x64, google for RtlAddFunctionTable to get the idea).
- WoA is more secure by default. For example TPM can be rarely found on x86, but it would be required on ARM.
- Most of existing drivers are source-code compatible with ARM (of cause if not using x86-specific stuff). But ARM would never allow to load unsigned drivers (unlike x86 Win7/8).
- As platform is completely new - all ARM drivers would be added to windows update site to simplify our life. Some obsolete hardware like 1394 is not implemented at all, so there would not be so many drivers for ARM llike for x86.
- All binaries would be the same for all SoC providers.
- No "native" ARM VisualStudio - developer tools are x86 only.
WoA requirements from different sources:
- 10.1” display with 1366x768 min resolution (though smaller screens may be supported with reduced functionality)
- Volume Control, Windows, Rotation, Lock power buttons
- Dual core CPU with hardware accelerated GPU
- at least 1 Gb RAM
- min 16 Gb fixed storage
- 100mW idle power in standby
- there are rumors that there would be standart "Phone call API" ("Apollo" UI)
Does anyone have access to ARM WDK? It would definitely contain a complete set of import libraries and would provide lots of info on WoA internals in headers/documentation. Seems that Windows 8 WDK on MSDN does not have ARM tools

so your bottom line says: no w8 on arm (ever)?

I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
The UEFI requirement is expected, and I doubt will be that much of a hurdle. UEFI is all open, and it should be pretty trivial to chainload a UEFI-compatible environment on top of the existing firmwares, provided that nvidia doesn't provide us with an implementation to start with, which I suspect they'll do.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two. A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Everything I could find relating to the TPM says that it's optional, but will be automatically utilized if available.
The rest is pretty inconsequental, at least to what I think most people here are interested in.
nvidia started a windows 8 development program for ARM (Clickey here), but I haven't seen anything else from it, has anyone else gotten anything?

mamaich said:
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
Click to expand...
Click to collapse
Actually they said it would continue to support BIOS for older devices.
See: Current machines dual-booting Windows 7 and Linux should be able to upgrade to Windows 8 without wiping out the Linux install. As Microsoft notes in the Building Windows 8 blog, “We will continue to support the legacy BIOS interface.” However, machines using UEFI instead of BIOS “will have significantly richer capabilities” including faster boot times and greater security. (from Arstechnica)

That's for x86. ARM was said to require UEFI. Besides, there is no real bios on Android tablets, at least not a common platform.

netham45 said:
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
Click to expand...
Click to collapse
I've got it in one of the "windows-on-arm" non-public documents dated the first half of this year. While UEFI,ACPI,TPM are an option for x86, they are required for ARM hosts.
So no custom WM8 bootloaders, drivers, patched kernel on ARM hosts (like "windows activators" do) until sign keys would be leaked or some backdoors would be found. Of cause this is good as this would make rootkit creation more difficult, and require device drivers signed by MS (so we'd get more stable OS) but I really don't think that this "protection" would last more than 1-2 months after WoA would be released.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two.
Click to expand...
Click to collapse
I'm already working on such tool. It emulates x86 instruction set with dosbox or bochs CPU emulation library (I'm using both of them for debugging purposes, while working on my own one that would be much more simple->faster), translates x86 WinAPI to "native" host WinAPI + emulates API that is not present or differently implemented on WoA. It is designed to be truly cross-platform, so just a recompilation + creating several thunks/stubs would be necessary when I'll get my hands to an ARM host running windows8.
Of cause programs that use heavy anti-debugging, self-modifying code, undocumented features and SEH tricks would not work. Currently it is rather far from being finished (I have to implement&debug WinAPI and COM thunks that cannot be automatically generated) but old games like "heroes of might and magic" are already working fine in a test environment.
A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Click to expand...
Click to collapse
Of cause I'm talking about "ultimate" VS11, as express is designed to target mostly .NET (though ARM compiler is present there too).
And WDK that it published on MSDN does not allow creation of ARM drivers. I'm currently in a process of renewing my company's MSDN subscription, so I can't prove that myself, but I've read that on OSR forums.

I am waiting to hack my iPad and put win8 on it

I would hope touchpad would be the next viable option. Hp could still make more and just dump W8 on it. Thanks all of you for working this thread. I will be reading your progress as it unfolds. Good Luck devs and if I can find anything you will be the first to know.
Sent from my mwp6985 / Trophy using XDA Windows Phone 7 App

Some information on Win8 "Apollo" is available. Apollo - is a name for a new "windows phone" OS from MS.
- Apollo is based on the same "desktop" code as Windows 8. No Windows CE at last!
- Apollo would provide the same user experience as old Windows Phone 7.x - Metro UI, People hub, builtin office apps, etc. Seems that software compatibility with WinPhone 7.x apps would be preserved, but this is just my own guess.
- All applications on Apollo are required to be signed, similar to Windows Phone 7.
- Device drivers can be written only by IHVs, MS and OEMs, not by ISVs. This would be a problem for antivirus vendors or tools like daemon-tools.
- There would be a "built-in" eMMC card with OS and vendor partitions, and maximum one SD card. eMMC supports NTFS, SD-card supports only FAT/exFAT.
Build-in eMMC would have C:\ drive letter, SD-card would be D:\ if present.
eMMC contains several partitions. Some of them would be made readonly during boot.
- Near Field Communication is built in.
- The same list of sensors as in WP7 Mango is supported.
- There would be BSOD like in a desktop OS
- Unproven, but it seems that only .NET ("Splash UI framework" and "Silverlight") APIs would be available to independent developers. So no native code again.
- Seems that x86 architecture is supported for Apollo too.