Related
I'm currently doing a little reverse engineering of Coredll so that I can understand how a few functions work. Occasionally I run across a function call to an address similar to F000BDD8. Is this a function call into the kernel or does it correspond to an address in the dll? If someone could point me to the correct reference, I'd appreciate it.
This is how it is layed out:
LDR r0, &0000b650
MOV lr, pc
MOV pc, r0
And at address 0000b650 the value is F000BDD8.
Thanks!
it is something like a "syscall" command on WinCE. The "FIRST_METHOD" value (0xF0010000) is subtracted form the given address, then value is divided by 2 (in your case we get -8468 or 0xff..ffdeec). If the value is negative it is "API call to an implicit handle. In this case, bits 30-16 of the method index indicate which entry in the system handle table." (probably its a typo in comment, bits 8-22 are used instead of 30-16). Lower bits are offset in SystemAPISets[] table for the function address.
For more information look into PrefetchAbort function in "PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\armtrap.s" file, and ObjectCall function in "PRIVATE\WINCEOS\COREOS\NK\KERNEL\objdisp.c"
You should get PlatformBuilder and look into Wince 4.20 partial source code that is coming with it. It does not have much information on indexes inside SystemAPISets table for any table except for SystemAPISets[SH_WIN32] (SH_WIN32 == 0).
see this page for a list of systemcalls.
and this page for a description of how systemcalls work.
to convert a trap address ( like 0xF000BDD8 ) back to the syscall nrs:
Code:
$a= (0xf0010000-$addr)/4; # = 0x108a
$api=$a>>8; # 0x10 = SH_GDI
$call=$a&0xff; # 0x8a = ExtCreateRegion
( call defined in public/common/oak/inc/mwingdi.h )
hmm. not sure which is correct though, my wince-systemcalls page lists a different call signature than the headerfile. they should match.
Thank you for the information. I actually have the sample source that comes with the Platform Builder demo. In this case, the call I was investigating was the GetSysColorBrush API.
That brings me to another point. In several of the APIs a check is made to a value (KData->lpvTls[-20], I believe) to see if the 0-bit is 1. The only thing I can determine is whether or not this is checking for the ready state of the API. Whatever the case, it seems that this bit determines whether the function I mentioned earlier is called or whether a function address is loaded from RAM. It's really weird.
The main reason I'm doing this is so that I can access the system's brush cache for the system colors. I've noticed that if I intercept calls to GetSysColor and GetSysColorBrush, it only works for applications that have not called them yet. So, if I override the color for COLOR_BTNFACE, menubars for newly launched applications are colored correctly, but buttons (which belong to GWES) do not use the appropriate color. It's weird because my code has been injected into GWES.Exe.
I guess that brings me to my ultimate question of whether or not someone can point me to the location in RAM where the system brush cache is stored.
Thanks!
is the '-20' in bytes ?
in PUBLIC/COMMON/OAK/INC/pkfuncs.h
#define PRETLS_THRDINFO -5
#define UTLS_INKMODE 0x00000001 // bit 1 set if in kmode
#define IsThrdInKMode() (UTlsPtr()[PRETLS_THRDINFO] & UTLS_INKMODE)
this must be the bit that is set when calling 'SetKmode();'
Yeah, the -20 is in bytes. Here's the disassembly of what I was looking at:
00B5EC E59F6068 LDR r6, &0000B65C
00B5F0 E59F5060 LDR r5, &0000B658
00B5F4 E5960000 LDR r0, [r6, #0]
00B5F8 E5101014 LDR r1, [r0, #-20]
00B5FC E3110001 TST r1, #1
00B600 15950000 LDRNE r0, [r5, #0]
...
00B650 F000BF08 ANDNV r11, r0, r8, LSL #30
00B654 01FC6758 MVNEQS r6, r8, ASR r7
00B658 01FC6760 MVNEQS r6, r0, ROR #14
00B65C FFFFC800 SWINV &FFC800 <-- Points to KDataStruct
What you said makes sense, yet it seems kind of strange that this API would be looking at an offest of -20.
so what you are seeing, is a call to 'IsThrdInKMode()' .
there is a space of thread local storage used by the kernel, just before the publicly accessible thread local storage. - look for SIZE_PRETLS, and PRETLS_RESERVED in the wince source.
this function ( well implemented as a macro actually ) is not a very strange function to call from a system call.
btw, you should have a look at IDA from datarescue. it will give you a much more readable disassembly. the stuff in your example from 00b650-b65c will be recognised as a constant pool, and the references to it, like at 00b5ec will be disassembled as 'LDR r6, =0xffffc800'
The only problem I have with IDA is that I can't afford it and their demo doesn't handle ARM processors. The generated output was done with a fairly simple program and has forced me to learn quite a bit about the underlying code in the OS. I've had to go back and forth between the disassembly and the shared source, but I've managed so far (with this exception).
I do have one other question while I have your attention. I've managed to inject a dll into all of the running processes and I've successfully managed to intercept several APIs by patching an application's IAT (and all attached modules, too) in an attempt to provide a better color handler for the system. It appears, however, that some programs, like Gwes.exe, don't use call my functions, but instead call the functions built into Coredll. For example, the GetSysColorBrush I mentioned earlier. This is what prompted me to begin reverse engineering Coredll in the first place. Do you know if the addresses are being stored somewhere? If so, that would explain why even though I've patched the IAT that the original function is still being called.
contact me in PM, I can help with IDA 4.51 full
gwes.exe is the program implementing the API, so quite likely it either calls it's api's directly, or calls the systemcalls directly.
and maybe someprograms are linked to a statically linked version of coredll?
a while back I experimented with trapping systemcalls, by modifying the method table in an API. ( see hookapi.cpp )
I do remember that my device became very unstable. so I guess that it somewhat worked, but haven't figured out what exactly I did wrong yet.
btw, I would be quite interested to see your code to trap calls via the IAT.
When you have a look to romimage.exe source code in platform builder you will notice that there is a special handling for coredll.dll.
All programs included in the MODULES section will directly resolve calls to coredll.dll. Only if you build a new XIP section a warning will appear "missing coredll.dll ... will late bind".
This means that a hook to coredll.dll will not be visible for in ROM programs since they will call the system functions directly (without the trap).
John
itsme said:
btw, I would be quite interested to see your code to trap calls via the IAT.
Click to expand...
Click to collapse
Unfortunately, I'm not at the computer where I have the code, so I'll have to upload it to you tomorrow. However, it involves extracting the IAT from the PPROCESS structure of a given program, then enumerating through the entries until I find the API I'm looking for. It's actually pretty straight forward. Give me your email address and I'll send it to you as soon as I can.
JohnSmith said:
When you have a look to romimage.exe source code in platform builder you will notice that there is a special handling for coredll.dll.
All programs included in the MODULES section will directly resolve calls to coredll.dll. Only if you build a new XIP section a warning will appear "missing coredll.dll ... will late bind".
This means that a hook to coredll.dll will not be visible for in ROM programs since they will call the system functions directly (without the trap).
Click to expand...
Click to collapse
I don't have the full source code, only what's available in the shared source, so I'm not sure what modules would be affected. However, I'm really only interested in a few of the Gwes APIs. I know it's possible at least at some point to hook into those as I've seen it done, though the individual who did it is under an NDA and can't tell me how he did it.
Itsme's process looks to be about the best so far, assuming I can get it to work. The only thing is that I need to find a way to translate the physical address to a virtual adress (and vice-versa) for MIPS, SH3 and the emulator, not just the ARM/XScale processors. If I could do that, then I might be able to get things to work.
Thanks for all of your help so far. I appreciate the time you have spent in explaining a few things to me.
[email protected]
for translating physical to virtual you would need to find the translation tables for each process, which I assume must exist somewhere, but have not found them yet. - my guess is it may be the 'pPTBL' entry from the process struct, but have not verified this yet.
( you know that virtual addresses can not uniquely be translated back to physical without knowing what process they are for? for instance the virtual address 0x11000 is visable in each process, and mapped to a different physical address each time. )
Fortunately, I've written an OS before, so I know what you mean about address mapping. If the pTBL does contain the page mappings, that would make sense. I found it easier in my OS to keep the TLB entries with the process they belonged to. That way the OS wouldn't have to search through its memory chain looking for the process's mappings.
Also, if the pTBL does contain the TLB entries, then it should be relatively easy to decode the addresses. After reading your code, itsme, I determined that the CINFO structure holds a pServer field which points to the process which contains the APIs. So, for example, the GDI and USER API sets are being held in Gwes.exe (at least, according to the pServer field). The ppfnMethods field is a VA referring to the pServer. If pServer is NULL, then the ppfnMethods field seems to be a PA. So, what I could do is check for pServer. If it is NULL, I could use the current process's pTBL structure to map the PA to a VA. If the pServer field is non-NULL, then I could try the pServer's pTBL field to do the mapping and then do the replacement that way.
If this works, I owe you big!
here is another experimental program, that investigates all the handles present in the system.
I used it to generate this overview of handles.
Progress So Far
I just thought I'd post an update on my progress so far. It appears that I can overwrite the API table pretty easily. Instead of taking a physical address, the table takes a pointer to a function in virtual memory. You just need to map it to slot 0 using MapPtrToProcess.
I've come across two issues in doing this. The first thing is that I can't call the original function address. For example, I store the original address contained in ppfMethods[x] and then attempt to typecast it to the proper function type, passing the incoming variables.
The other issue is that it appears that the API table is NOT refreshed upon a soft-reset. Fortunately, I was playing around with it on the emulator. Had I not, I would have been forced to hard-reset my device.
Does anyone have ideas on either of these issues?
Thanks again for your help so far!
a thing that just occurred to me, is that if you duplicate the apiset struct, the memory pointed to by ppfnMethods should be readable from the process specified in pServer.
so you should allocate the memory in the address space of pServer.
or set pServer to yourself, and add some hook code which does not modify the stack, so you can just pass most calls directly to the original server.
to call the original function address, you have to somehow switch process context, and then call it.
Well, in the case that I tested, I replaced the QueryAPISetID API which exists in Wn32 and therefore has no pServer. It appears that if there is no pServer, then there is no context switch needed. I've been able to verify that the API will execute my code and the generated assembly does not modify the stack in any way.
This one is really weird. Thanks for the suggestions.
chmckay said:
itsme said:
btw, I would be quite interested to see your code to trap calls via the IAT.
Click to expand...
Click to collapse
Unfortunately, I'm not at the computer where I have the code, so I'll have to upload it to you tomorrow. However, it involves extracting the IAT from the PPROCESS structure of a given program, then enumerating through the entries until I find the API I'm looking for. It's actually pretty straight forward. Give me your email address and I'll send it to you as soon as I can.
Click to expand...
Click to collapse
Hi,
Just wondring if you could post/PM/email me the code that lets you replace the API call. This is for the purpose of hooking a different DLL to do my own thing, or see here:
http://forum.xda-developers.com/viewtopic.php?p=131857#131857
I just sent you a PM with the information you requested.
I was wondering if anyone here could help me out.
I have a need to intercept a couple of GDI apis. At this point, I can successfully inject a library into GWES and hook the apis using the api set data structure contained in the kernel's memory (i.e. KDataStruct->aInfo[KINX_APISETS]). However, this doesn't work when Gwes calls the api internally.
So, I came up with a method that allows me to "hook" the api, similar to the way Detours works. What I did was allocate 8 bytes of virtual memory and copy the first instruction of the api to the first 4 bytes of the memory block. Then, I created an ARM branch instruction to jump from the second 4 bytes of the buffer to the second instruction in the original api, kind of creating a trampoline function. Then, I created one more branch that jumped to my new function and overwrote the first instruction of the original function.
Basically, this is what ends up happening:
The api is called
The function branches (unconditionally) to my function
My function calls the trampoline function
The trampoline executes the first command of the original function (the one that was overwritten) and branches unconditionally to the original function
The original function does its thing and returns to my function
My function handles whatever it needs and returns to the caller
Now, here's the problem. On my handheld, it works flawlessly. However, this code did NOT work on several other devices, causing freezes and hard-resets. I was wondering if anyone knows what I can do to get this fixed.
Here's how I calculate a branch:
branch = (((dest-source-8)>>2)&0xffffff)|0xea000000;
I've verified that all of the values come out correctly for the ARM specifications.
If anyone can help, I'd really appreciate it.
Thanks!
3 ideas. First is dumb. Maybe these devices keep GDI code you are trying to patch in ROM?
The second idea. Maybe the GDI code is mapped to every process address space without any modifications, and when your hook is called, some of the processes does not have your injected code in them and jump goes to unexistent address -> crash. You may try to use a jump command that uses full 32 bits of adress and a MapPtrToProcess() function to get your address that is visible in every proccess. In this case you should patch 8 bytes of hooked command.
The third idea. Are you sure that the patched bytes does not contain instructions that use PC-relative offsets? In this case you'll have to emulate them manually.
Well, all GDI/USER functions exist in Gwes.Exe. When you call something like BeginPaint, coredll transfers control to Gwes, Gwes makes the function call and control returns to the application. So placing a hook in Gwes is the best location.
On the ARM/Xscale platform, all branches are relative to the PC. My example in my first post shows how the branch offset is calculated. Each branch must be within 32MB (24-bits). The first instruction of the function I'm hooking, according to IDA, is an STFMD.
So, I thought that my original problem was that the jumps were more than 32MB away. However, I've confirmed that this is not the case in any of the crashes, which is why I'm confused.
I believe I wrote everything to ARM specifications, but I guess not. If it will help, I xan post some of code for a reference.
instead of a jump, maybe use
Code:
04 F0 1F E5 LDR PC, [PC-4]
xx xx xx xx DCD jumptarget
There are a lot of clock area today screen apps out there, from the simple such as PDClock, through mid-level stuff like HTC home, up to the fully customizable rlToday.
Few of these seem to be a good all-round solution though, except maybe rlToday, but I am having issues with the rlToday / Sys-to-Reg / Mortscript combo, both in terms of features (ie no support for "on" or "off" images), stability, and ease-of install (S2R seems a bugger to set up right, especially for the less technically inclined user), and the whole rlToday / S2R / Mortscript combo is hardly a turnkey one-install solution.
So to that end, I decided to try my hand at crafting a solution more appropriate to my needs.
Now, until this point I have never coded for C++ or windows mobile. I am not even a professional coder, far from it, but I do have a knack for designing good solutions, so I thought I would start teaching myself native C++ and see what I could come up with. Ultimately, my goal is to release as open source, I am hoping to maybe start a sourceforge project at some point...
I am making this post because I am now starting to get past the proof-of-concept stage and am coming up with some working code. I am tackling the various hurdles one by one and learning as I go, but it is starting to look promising.
This thread is to serve two purposes:
1) Gather my thoughts on how things are going to work so potential users can chime in on possible tweaks or changes to the features and how they should work.
2) Serve as a rallying call for any (preferably more experienced) coders who wish to get involved. I will post up any problems that I am having surmounting various issues, please feel free to help out on those. If an experienced coder liked the project that much and wanted to take the lead, I have no issues with that, as long as it remained open source.
So, with that out the way, here is what I am thinking so far:
Overall idea is pretty similar to rlToday - a script (ie a .INI or .XML file) which lists Widgets is processed and the result is drawn on the screen.
For example, here is an example INI file for a background (say transparent) PNG with a clock overlaid in the middle of the PNG, that has different layouts / images for portrait and landscape mode on a qVGA device.
Code:
;ini profile for qVGA (240 width and 320 width)
;PORTRAIT
[PortBG]
width=240
widget=image
clickable=0;
image="bgport.png"
x=0
y=0
[PortClock]
width=240
widget=text
subwidget=clock
clickable=1
clicktype=exe
clickstring="<exe to launch calendar>"
dateformat = "dddd MMMM d"
x=120
y=25
origin="cc"
;LANDSCAPE
[LandBG]
width=320
widget=image
clickable=0
image="bgland.png"
x=0
y=0
[LandClock]
width=320
widget=text
subwidget=clock
clickable=1
clicktype=exe
clickstring="<exe to launch calendar>"
dateformat = "dddd MMMM d"
x=160
y=25
origin="cc"
The [Name] of each section actually does nothing, but it will be useful in debugging / error messages ("Image for [PortBG] not found!").
Widget = choses which kind of widget it is (eg Image, Text)
subwidget = choses the subtype of widget (eg clock is a subtype of text)
The Width= entry is an idea I came up with to handle multiple screen orientations and resolutions within one profile. Basically, as this is not intended to be a full-screen app, the only relevant dimension is the screen width. Each widget therefore has an associated width. When the screen is rendered, it will check what the current width is and only render widgets that match that width. Furthermore, if a script has entries for resolutions not supported by your device, these will be ignored. Profiles are likely to be a directory with one .INI file and assorted images. Images can be in subdirectories, say grouped by width (ie a "240" dir and a "320" dir for qVGA) - that way you could release a skin as one zipped dir that supported all devices and resolutions, and you would not need to upload the "480" and "640" dirs to a qVGA device, thus saving storage space.
Each widget also has x/y coords, which usually refer to the top left, but the origin entry can change that (eg cc would be centre horizontally and vertically)
Each widget will also be able to be specified as clickable, with options as to what to do when it is clicked.
With this system it should be possible to create most things, however, here is what I am currently NOT planning on doing:
I am not aiming at offering tabbed pages of widgets, or an easy way to change widgets without writing a new script. This is aimed at a companion to something like UltimateLaunch for handling the top of the screen - a Clock, SMS / Missed Calls / VM messages, BT / WiFi status and toggles etc.
I am currently using VS2005 and the WM5 SDK, but the app is still so simple that this could probably be changed. I would like to support as much as possible, but am not overly worried about providing backwards compatibility beyond WM5. I am using Native Win32 - I want to avoid as much bloat as I can.
Planned features:
Per-pixel Alpha PNGs - IMPLIMENTED
Widgets parsed from INI - IMPLIMENTED
Parse only items from INI that match screen caps - IMPLIMENTED
Display only items that match current screen width - IMPLIMENTED (Effectively switch profile on screen orientation change)
Options screen to set current profile
Widgets
======
Text Type: - IMPLIMENTED
Source: String in INI - IMPLIMENTED
Source: String in Registry
Source: Date from format string - IMPLIMENTED
Image type: - IMPLIMENTED
Plain image - IMPLIMENTED
Status Image - Registry value
Toggles - BlueTooth / WiFi / Phone etc
Other features
===========
Multiple screen resolutions supported per INI - IMPLIMENTED
Detect Power but no Activesync - Allow enabling of BlueTooth for automatic pairing with in-car BT handsfree.
Current questions and stumbling blocks:
Having issues finding a lightweight way of displaying per-pixel alpha PNGs. Current thinking is that AlphaBlend is perfectly capable of doing the blending, it is just SHLoadImageFile that is stripping the alpha info.
See threads here and here
Not sure how I am going to handle toggling of BT / WiFi. Could use VJ's tool, but I would rather do it in my code. Any pointers on how to do it and maintain maximum WM5 / WM6 compatibility would be appreciated - VJ's tool will not toggle WiFi on my Kaiser anyway...
Could do with decent chop and chomp routines (split by char and remove leading / trailing whitespace) - does anyone know an easy way to do this in native code?
Need to work out how to find the size of a text string in pixels *before* it gets drawn to the screen with ExtTextOut
Need to impliment a date format string to text string converter that can handle date and time objects in the same string
Currently I use a bit of code to look at the string and pass it to either GetDateFormat or GetTimeFormat, but not split the string and pass relevant bits to relevant routine, then reassemble.
Need to make whole thing a today item, but delaying doing this as it seems that debugging will be harder? I also guess this would be quite easy, so I am planning on leaving this until near the end. Any advice on this subject would be appreciated.
I am interested in this. I don't know C++, but I have experience coding with other computer languages. I'll definitely be following this thread and watching for updates.
iContact source contains some pretty lightweight INI library. It isn't written by me, and it's called SimpleIni. Everything is contained in one .h file and it's very easy to use.
good luck,
larna
larna said:
iContact source contains some pretty lightweight INI library. It isn't written by me, and it's called SimpleIni. Everything is contained in one .h file and it's very easy to use.
good luck,
larna
Click to expand...
Click to collapse
Nice one, thanks
I got simpleini in and working - you were right larna, it was really easy and pain-free. Thanks!
Update:
I have a working prototype.
All basic functionality coded - text and image widget types, orientation switching, ini parsing...
Currently still not a today item, and there is loads to do in terms of error checking and freeing up memory etc, but it parses INI files OK
Once I have done some tidying up, I will release some source and maybe a demo EXE.
Hey!!
I'm already developing an application which load and extends rlToday Themes!
sources will be released soon!
The app is XIAMultitheme:
Done:
- fully working rltoday themes on a HWND
- done today plugin
- loading external dll
- all widgets are external dll
To do:
- avoid image loading via ImageFactory due to memory leak on wm6x
- port to CxImage to load PNG
- use AAROT to free rotate images (analog clock)
- today plugin does not load the engine yet
http://www.xiaprojects.com/?section=All&project=XIAMultiTheme
what do you think? mail me on priv (stefano) on xiaprojects.com
stefanux said:
Hey!!
I'm already developing an application which load and extends rlToday Themes!
sources will be released soon!
The app is XIAMultitheme:
Done:
- fully working rltoday themes on a HWND
- done today plugin
- loading external dll
- all widgets are external dll
To do:
- avoid image loading via ImageFactory due to memory leak on wm6x
- port to CxImage to load PNG
- use AAROT to free rotate images (analog clock)
- today plugin does not load the engine yet
http://www.xiaprojects.com/?section=All&project=XIAMultiTheme
what do you think? mail me on priv (stefano) on xiaprojects.com
Click to expand...
Click to collapse
hi stefano
i see nothing on your web site , nor screenshots nothing in download binaries
Why ???
evilc said:
Update:
I have a working prototype.
All basic functionality coded - text and image widget types, orientation switching, ini parsing...
Currently still not a today item, and there is loads to do in terms of error checking and freeing up memory etc, but it parses INI files OK
Once I have done some tidying up, I will release some source and maybe a demo EXE.
Click to expand...
Click to collapse
can you upload here the demo program ?
Sounds pretty neat!
I don't understand some of the terminology you use, but I think you may be talking about a feature I had an idea for:
profiles (XML files) can be associated with a today plugin such that you can make a profile appear in the today plugins list for each skin (XML file) you have installed - thus making each XML profile behave like it was a today plugin in it's own right.
Is that what you are talking about?
brunoisa10 said:
can you upload here the demo program ?
Click to expand...
Click to collapse
Demo uploaded to first post. Unzip it to \Storage Card\shared on your device and run.
BE AWARE, there is very little error checking when parsing the INI.
If you omit a horizres line for any widget, for example, the program will crash.
Well I checked out XIAMultiTheme and it looks promising.
I was not aware that there was a memory leak bug in IImagefactory, I wasn't planning on using it in the final version anyway, so no biggie.
If XIAMultiTheme is capable of doing what I had envisaged for openClock, I will probably stop development, as you obviously know what you are doing much more than I do
However, a couple of points:
1) Size.
XIAMultiTheme seems to be a lot bigger and requires .NET - This seems to mainly be to do with the CxImage library - just PNG support seems to add more size than my entire app is! I am flabberghasted that supporting per-pixel Alpha PNGs takes this much, an alphablend routine can be done in a K or two, hundreds seems overkill. Apart from the requirement for rotation (for analogue clocks) I do not see why a full image lib is needed. Just a load and alpha blit.
2) Orientation awareness.
As in I don't see any in XIAMultiTheme. I am really happy with the way I have handled this in openClock - each item in the INI (XML in your case) has a "horizres" value associated with it. At render time, current screen width is compared to each item's horizres and if it matches, the item is drawn, if it doesn't then it isn't shown.
This provides a nice way to combine portrait, landscape and multi-res capabilities into one theme. And as long as you allow relative paths in the theme(eg 320\320bg.png, 240\240bg.png, common\common.png) then you can have a theme which supports all resolutions and orientations, and allow the user to store what they want on their PPC (eg if their device is qVGA, they know they do not need to put the 640 and 480 dirs on their PPC for a given theme, as they won't be used)
3) Stateful buttons.
Items like a voicemail button / wifi button etc should probably have two images associated with them - one for "no messages", one for "have messages". I was planning on putting something in openClock along the lines of specifying a reg key, an operator and an image.
eg:
regkey=HKEY_LOCAL_MACHINE\...
on=thisimage.png, gt, 0
off=thatimage.png
To set to thisimage if the key is of value greater than (gt) 0 or thatimage.png if not.
Good luck!
evilc said:
just PNG support seems to add more size than my entire app is!
Click to expand...
Click to collapse
Yep. Same goes for MortButtons... (and MortPlayer, but there, the player itself is bigger in relation...)
I am flabberghasted that supporting per-pixel Alpha PNGs takes this much, an alphablend routine can be done in a K or two, hundreds seems overkill.
Click to expand...
Click to collapse
The alphablend routine is in the Draw method, and even in source code not much more than 1kB.
The trouble is to load the PNG without losing the alpha information. With Windows' API, you can't do it - there's only the crippled SHLoadImage. So you need the entire code to decode PNGs, i.e. libpng, which in return requires zlib - over 200kB only to load PNG! The remaining kBs are spend to load/decode JPEG (quite some kBs, too), GIF (if enabled), BMP, ... and some basic image processing (resample, rotate, ...).
btw, you might want to check MortImg.dll and MortImage.lib, which is a (quite) simple wrapper. If only one image library is used, at least some memory on the device is saved (and if MortButtons or MortPlayer since b72 is used, also main memory).
Check out http://mort.svnrepository.com/svn/mort/MortTools/trunk with any SVN client (e.g. Tortoise), use "guest" for login and password.
evilc said:
Well I checked out XIAMultiTheme and it looks promising.
I was not aware that there was a memory leak bug in IImagefactory, I wasn't planning on using it in the final version anyway, so no biggie.
If XIAMultiTheme is capable of doing what I had envisaged for openClock, I will probably stop development, as you obviously know what you are doing much more than I do
However, a couple of points:
1) Size.
XIAMultiTheme seems to be a lot bigger and requires .NET - This seems to mainly be to do with the CxImage library - just PNG support seems to add more size than my entire app is! I am flabberghasted that supporting per-pixel Alpha PNGs takes this much, an alphablend routine can be done in a K or two, hundreds seems overkill. Apart from the requirement for rotation (for analogue clocks) I do not see why a full image lib is needed. Just a load and alpha blit.
2) Orientation awareness.
As in I don't see any in XIAMultiTheme. I am really happy with the way I have handled this in openClock - each item in the INI (XML in your case) has a "horizres" value associated with it. At render time, current screen width is compared to each item's horizres and if it matches, the item is drawn, if it doesn't then it isn't shown.
This provides a nice way to combine portrait, landscape and multi-res capabilities into one theme. And as long as you allow relative paths in the theme(eg 320\320bg.png, 240\240bg.png, common\common.png) then you can have a theme which supports all resolutions and orientations, and allow the user to store what they want on their PPC (eg if their device is qVGA, they know they do not need to put the 640 and 480 dirs on their PPC for a given theme, as they won't be used)
3) Stateful buttons.
Items like a voicemail button / wifi button etc should probably have two images associated with them - one for "no messages", one for "have messages". I was planning on putting something in openClock along the lines of specifying a reg key, an operator and an image.
eg:
regkey=HKEY_LOCAL_MACHINE\...
on=thisimage.png, gt, 0
off=thatimage.png
To set to thisimage if the key is of value greater than (gt) 0 or thatimage.png if not.
Good luck!
Click to expand...
Click to collapse
thanks you for your good words
1) beta version will be lighter ... (need to known what image loader use)
2) will be done on Page component (tab themes are already working)
3) will be done on sensor dll with "regex" (maybe)
XIAMultiTheme is in alpha development...
I would like to "merge" code with you or may be DLL collaboration.
XIAMultiTheme does NOT need .NET it's low level GDI "C" source
When XIAMultiTheme go on Beta status the dll will be around 10kb
Configurator is .net
Thanks you
Thanks for that mort!
However, if my entire app is (currently) 61K and it supports per-pixel alpha PNGs (Via the apparently bugged IImagefactory), then surely it is more than possible in less than 100K.
It seems like libpng must be grotesquely bloated for our needs. In an ideal world, someone would re-code SHLoadImage to not lose the alpha channel for PNGs. Maybe a workaround would be to convert the PNG into a 32bit per-pixel BMP with alpha before it is passed to SHLoadImage, as SHLoadImage deals with alpha BMPs just fine and AlphaBlend works just fine with AC_SRC_ALPHA data.
stefanux said:
thanks you for your good words
1) beta version will be lighter ... (need to known what image loader use)
2) will be done on Page component (tab themes are already working)
3) will be done on sensor dll with "regex" (maybe)
XIAMultiTheme is in alpha development...
I would like to "merge" code with you or may be DLL collaboration.
XIAMultiTheme does NOT need .NET it's low level GDI "C" source
When XIAMultiTheme go on Beta status the dll will be around 10kb
Configurator is .net
Thanks you
Click to expand...
Click to collapse
Hi stef,
I am more than happy to help out on your project with design ideas, testing and proofreading of english translations.
I have plenty of ideas on what the ultimate today screen widget app should feature, I just had to set my sights lower due to my (lack of) coding abilities.
Do you have a forum or something on your site? I don't see one.
I am slightly concerned about point (3) and your regex example. I would maybe try and keep it simpler, XML is already a little complicated for non-technical users to understand, throwing regexs into the mix may be the straw that broke the camel's back. That's why I went with INI files - simpler to use for lusers
evilc said:
Thanks for that mort!
... it supports per-pixel alpha PNGs (Via the apparently bugged IImagefactory), ....
Click to expand...
Click to collapse
Please try to do this test:
load 20 png's with imgfact. and start drawing all of them like a simple animation for 10 fps... image[]->Draw() after 5 minutes my application will blow up my pda (wm61) I thinks it's a "COM" bug because it happend only calling "Draw"
stefanux said:
Please try to do this test:
load 20 png's with imgfact. and start drawing all of them like a simple animation for 10 fps...
Click to expand...
Click to collapse
Are you kidding??? 10FPS? I have a kaiser!
Seriously though, if we can get a code snippet that proves this, surely we can get MS to issue a patch?
*** PLEASE READ CAREFULLY BEFORE INSTALLING OR FLASHING ANY SOFTWARE POSTED IN THIS THREAD ***
The software posted here is for TESTING purposes only, Team P3D or any of the posters of software, or links to software on this thread take absolutely no responsibility or liability for damage caused by the result of installing or flashing software or links to software found on this thread - correctly or otherwise, you do so on the sole understanding that you do so at your own risk.
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Project Name: Polaris 2D Driver Project
Driver Name: P3D 2D Driver (Working title)
Development and Testing Team: SEE Post #2
---------------------------------------------------------------------------------------------------------------------------------------------------------------
ANNOUNCEMENT:
The P3D team would like to extend an OPEN INVITATION to all developers and programmers from all forums of EVERY device to come forward and help us create the 2D driver which, as it is being developed from scratch will require much development work with many dll files created from scratch.
If you are interested in helping, please post your interest in this forum and we will add your name to the developers list. If you would like to help but own a different device to which the 3D driver is yet to be ported to, we would also like to hear from you and hopefully assist you with the knowledge we have gained in return for your efforts here. (actually we'll help you anyway but.. we do want your help! )
---------------------------------------------------------------------------------------------------------------------------------------------------------------
11/10 - BigKVak successfully dumped the G810 rom and work has started in analyzing its content
---------------------------------------------------------------------------------------------------------------------------------------------------------------
P3D 2D Driver Development Team:
Administration/Testing:
Support and Testing:
Bally3
NikMel
Neos2007
BigKvak
Imfloflo
Developers: (TBC)
Rogro82
NuShrike
Chainfire
Monkeyass
maqui01
It started with a few simple questions:
"Can the Polaris be hardware accelerated?"
"Why doesnt the CA Kaiser 3D driver work on the Polaris?"
That was a month ago..since then, thanks to the help and support of NikMel, NeoS2007, Rogro82 and NuShrike to name a few, we now have a working 3D driver which is currently in a version 1 state and with the release of the cab version through CA last night, we can now concentrate on improving speed and compatibility to make better use of the graphic chips capabilities.
My intention then was never to start a 2D driver or work on a 2D driver until I was satisfied no more could be done to improve it and a "final" release was in the cards, but through my own testing and various posts and conversations, I now find myself wondering whether the improvements with 3D is linked to the 2D driver?
From day 1, before we released the 3d driver and after, users have expressed faster speeds in 2d as well as 3d - though many have explained it to be a "placebo" effect, we naturally attributed this to the gpu sharing the workload with the cpu which makes sense in a common sense way - itje posted a humorous answer on his thread explaining this very thing as worth a read just to put a smile on your face, but on a serious note a question has to be asked - Does improvement on 3D really effect 2D and if that is the case, would a 2D driver help improve the 3D drivers perfornance?
So why start a 2D thread when the 3D driver still needs refining?
Well, apart from the question above, the overwhelming requests for 2D support on both Polaris and Kaiser forums (it should work on both in theory), we now have a dump of the long awaited Toshiba G810 rom to get us started- A BIG THANK YOU TO BIGKVAK - welcome to the team!
Originally Posted by BigKvak
I have dumped ROM from Toshiba, here the link http://rapidshare.com/files/152085600/dump.rar.html
Click to expand...
Click to collapse
It is inevitable then that work needs to start on this project. We also need to preserve the 3D thread for future 3D driver developments and defer 2D driver related posts from it, for these reasons, this new thread has been opened for all to start working with the P3D team in bringing 2D greatness to our devices.
Lets share our knowledge and have fun doing it like we did with the 3D driver!
PS: Although I have named the project Polaris 3D driver project, I would like to extend an invitation to users of all devices that could benefit from the 2D drivers creation, after all through CA Kaiser development, we have now ported the 3D driver to the Polaris AND the NIKE and hopefully to many more devices
Let our devices not make us divisive - whats is the point?
It is common knowledge that files from newer devices are used to help create the drivers we need for our devices - so why should we gloat and mock other less supported devices, should we not help them and share our knowledge and in the words of a good friend here "Pay it Forward?"
This is not the spirit of XDA Developers and it is certainly not the ethos of Team P3D - We have and pledge tol share all knowledge with users of all devices.
Besides, its so much more fun when we all work together!
It appears that HTC-CA were already in the process of
Reserved for p3d 4
Reserved for p3d 5
Reserved for p3d 6
Reserved for p3d 7
Reserved for p3d 8
Reserved for p3d 9
Reserved for p3d 10
I found this link on microsoft MSDN: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1214862&SiteID=1
It's a guy asking for a 2d driver library. Maybe we can look into that?
I have dumped ROM from Toshiba, here the link http://rapidshare.com/files/152085600/dump.rar.html
Click to expand...
Click to collapse
To move the discussion of 2d in here..
Windows Mobile 2D and 3D explained on MSDN
I believe this: http://msdn.microsoft.com/en-us/library/aa911096.aspx will be out first place to look. It's mostly there: 2D AND 3D info.
Here's what functions there are:
AlphaBlend API
Provides information about adding support for the AlphaBlend function to your OS design.
Direct3D Mobile
Provide information about adding 3-D graphics support to your OS design and creating applications that use the API.
DirectDraw
Provide information about adding 2-D graphics support to your OS design and creating applications that use the API.
Gradient Fill Support
Provides information about adding support for the GradientFill function to your OS design.
Imaging
Provide information about adding support for compressed still images to your OS design and reference information for the API.
Multiple Screens
Provide information about adding support for multiple displays to your OS design and creating applications to support them.
NeoS2007 said:
I believe this: http://msdn.microsoft.com/en-us/library/aa911096.aspx will be out first place to look. It's mostly there: 2D AND 3D info.
Click to expand...
Click to collapse
reading it now.. some of it we know.. let see what we can learn..
http://msdn.microsoft.com/en-us/library/aa925824.aspx
Here we go:
"Applications direct output to a specified device by creating a device context for the device. The device context is a GDI-managed structure containing information about the device. An application creates a device context by calling device context functions. GDI returns a device context handle used to identify the device.
Applications can direct output to a physical device, such as a display or printer, or to a logical device, such as a memory device.
A device context also contains attributes that determine how GDI functions interact with a device. These attributes eliminate the need to specify every piece of information Windows Embedded CE requires to display an object on a device. If you want to change an attribute, you can use attribute functions to change current device settings and operating modes. Operating modes include text and background colors and the mixing mode that specifies how colors in a pen or brush combine with colors already on a display surface."
GDI is the source of 2D on our devices. Maybe we need to look out for GDI tweaks in the registry?
BPP (Bits Per Pixel) explained
I also found this blog about the colors used on a mobile device. It's said that if you have a colordepth of 18 instead of the usual 8, 16, 32 bits, it's more cpu intensive. Isn't there a registry key for colordepth?
http://blogs.msdn.com/windowsmobile/archive/2005/09/07/462187.aspx
"The next thing to understand is how the bits turn into colors on the screen. Say you've got a typical PocketPC with a resolution of 240x320 and 65536 colors. That means you've got 320 rows of 240 pixels (dots), each of which has 16 bits of data representing its color. All of that information is stored in a chunk of memory known as the "Frame Buffer." The LCD hardware takes whatever is in the Frame Buffer and converts it directly to what's on the screen. Want to change what's on the screen? Change what's in the Frame Buffer and the screen will update.
Okay, so we need 16 bits for every pixel, and we've got 240 times 320 dots. 16 bits is two bytes, so that's a total of 153600 bytes, or 150K of RAM used to hold what's on the screen."
Maybe a good thing to mention: we're hoping that the Toshiba g810 Portege has the files we need to develop a 2D driver. We're currently trying to extract a dump we got. Anyone have experience in extracting Toshiba's .Bin files?
Direct Draw explained
On MSDN:
"The DirectDraw® API provides support for hardware-accelerated 2-D graphics. It offers fast access to display hardware while retaining compatibility with the Windows graphics device interface (GDI). DirectDraw is a specialized memory manager for both system and display device memory and uses hardware acceleration where available. With DirectDraw, you can allocate and manipulate both system and graphics memory, including transfers between the two.
DirectDraw for Windows Embedded CE is adapted from DirectDraw for Windows-based desktop operating systems. Some capabilities from the desktop version have been extended and others have been curtailed to better suit embedded devices.
DirectDraw supports the following effects:
Bit-block transfers (blits)
Page flipping and multiple back buffers
Overlays, which is placing one image surface over another on the video display
Alpha source over destination blending, which is blending two surfaces using the source alpha image component
Video YUV pixel formats and color conversion
Direct video access to the frame buffer
What if we compare our HKLM\system\DDRAW\ keys in the registry with other devices? I see the values in ALL keys there are empty.
Yes.. I've noticed that and played around with them.. no difference.
I've tried the LG KS520, Diamond and HD ddraw.dll files.. none work out of the box. Maybe the G810 one might make a difference?
We need to find out what calls are made and to what other dll files. If you remember the problem we had with the 3.13 ddi? it could be similar situation in that theirs a dependencies issue.
For those who know what it is, I have created a complete install for the HP 48GX Emulator optimized for WVGA devices. The emulator itself is based on Sébastien Carlier's Emu48 (now maintained by Christoph Gießelink).
My goals were to have a realistic but finger-useable HP 48GX. I have included the complete package in a single CAB (the ROM is an HP 48GX-R model). As HP released the ROMs for all the 48 models about 9 years ago, I can't imagine them complaining that I'm packaging them together as a useful package these days
See the attached Todo.txt before posting any bug reports please. FYI, I do not really plan to address any of the Todo items anytime in the near future.
Enjoy!
HP 48GX-R 1.18.1
Change Log
2009.09.24
v1.18.1
Converted 709 KB bmp file into 94 KB gif with no data loss. The screen should now load much faster.
Updated CAB file installation to allow for Storage Card installation.
P.S. The thumbnail doesn't even begin to do it justice. I spent *DAYS* on the visual appeal of the interface and for anyone who owns/owned an HP 48GX I hope you'll agree the level of detail and realism is nearly perfect.
P.P.S. If you don't know what an HP calculator is, or more importantly what RPN means, then its probably not worth your time even trying this.
48GX State Files
I have now attached some state files which includes two .e48 files and a SHARED.BIN file. The SHARED.BIN file is a 512K Port 2-5 attached card which both .e48 files share. The files are as follows:
SHARED.BIN
Port3
EDFlags 2.0G
HPTabs (Part of the Jazz package, see below)
Hack 9.4.1 (Based on Hack 9.4 with my own customizations)
StringWriter 4.4
MiniWriter 1.2
SmartKeys 1.59
Port2
Unitman 7.2001
QPI 4.3
ALG48 4.2
ALG48_SpecialFunction 4.2 (Part of the ALG48 package, see above)
ALG48_LongPrecision 4.2 (Part of the ALG48 package, see above)
ALG48_SymbolicIntegration 4.2 (Part of the ALG48 package, see above)
ChemLab 2.7
Neopolys 6.5
Bode-Routh 7.1
HP 48GX-R Math.e48
Port1
Erable 3.201 Beta
Marable
Erable_MODULO 3.2 (Part of the Erable package, see above)
Erable_GEO 3.2 (Part of the Erable package, see above)
Erable_PREP 3.2 (Part of the Erable package, see above)
Erable_LIN 3.2 (Part of the Erable package, see above)
Matrix 1.2
MathTools 7.0
Universal Font Library 1.0.2
Port0
Java 3.6a
HP 48GX-R Dev.e48
Port1
Jazz 6.8
Universal Font Library 1.0.2
MathTools 7.0
Matrix 1.2
Port0
Java 3.6a
Included in the zip is a file called InstallConfigure.txt which is simply the steps I took to create the .e48 files. Please note that I did not include the application .lib files themselves, though I did link most of them above. Remember, you can always recall them to the stack and save to your device if you plan to use any of them to make your own state file(s) from scratch.
48GX WVGA Photoshop Source
If your goal is to modify the visual appearance of the calculator without modifying the position or operation of any of the keys (onscreen or keyboard) then you may be interested in downloading the Photoshop source (attached).
Using it you must create a BMP file that is dimensionally identical to the one included in my installation (else you must change the KML appropriately). This means that there must be the entire image with no buttons pushed followed by the annunciators, followed by an image with the buttons pushed (without the annunciators again though). See the BMP that comes with the installation to know what I am talking about here.
The photoshop source is currently set to output an image with no buttons pressed and the annunciators. You will save as a BMP image to get the initial image with annunciators. You must then hide all the appropriate layers (and there are MANY) for unpressed button mode, and finally show all the appropriate layers (again there are MANY) for pressed button mode. Now change the image canvas size (cutting 14 pixels--the annunciators) from the bottom of the image, and save this as a BMP image. You will then take the first BMP image, expand the canvas size by 748 pixels at the bottom, adding the second BMP image (with the pressed buttons) in that area. Then simply merge layers and convert that image to Indexed color mode (selective) and save as the final BMP image.
If you are planning on changing colors note that where possible all you have to do is select every appropriate text layer and then change the colors for all of them at once. However, you will notice there are two layers (one for text graphics, and one for button graphics) that you cannot do this. You may deal with these in one of two ways:
Use the wand tool selection with shift to select all items of a given color, and then use some form of Image|Adjustment|... to match the colors.
Recreate the items manually. This is where the HP48.csh file comes into play. These are vector items I created for some of the button graphics (and annunciators). Access them through the custom shape tool (load custom shapes from file).
The button pressed version of the button graphics is precisely the same as the non-pressed version, simply shifted down one pixel. So my recommendation there is to simply make changes to the non-pressed version, duplicate it, shift down one pixel, and make that the new (Pressed) layer.
If you spend the time to properly create a graphics file that you think others would enjoy, please upload it and the source for others!
Cheers!
I still have my 48gx from more than 10 years ago, now I am just a HP12c type of guy
Excellent Work! Much appreciated! I also have a Emu48 version used by a company called EaglePoint (used to be SMI). It is called Pocket SMI v8. I have a licensed version but it is no longer supported. It is basically a custom tweaked Emu48 with a different skin and kml script specifically for surveyors/engineers. I would like to modify the skin but I am not sure how to get started...
Very Nice! Thanks much!
You think you can skin it for my 48SX as well?
The GX colors annoy the heck out of me...
wow, I haven't tried it yet but will, awesome idea. I still have my 48GX from college but I doubt my professors would like me to use cell phone during tests.
Thanks, will try it.
Thanks!
Quentin- said:
For those who know what it is, I have created a complete install for the HP 48GX Emulator optimized for WVGA devices. The emulator itself is based on Sébastien Carlier's Emu48 (now maintained by Christoph Gießelink).
[...]
Click to expand...
Click to collapse
AWESOME!!!!
glhs509 said:
Very Nice! Thanks much!
You think you can skin it for my 48SX as well?
The GX colors annoy the heck out of me...
Click to expand...
Click to collapse
If you have Photoshop and some time/know-how to make minor changes (difference in keys) to the KML file I can provide you with the graphics source that you can work with to make an SX skin.
Thank you!
This is fantastic, I will be looking for any updates and improvements. Will test and report back.
Wow... that's amazing...
...Here's my HP 48SX from my college years (circa 1992) for comparison...
glhs509 said:
Very Nice! Thanks much!
You think you can skin it for my 48SX as well?
The GX colors annoy the heck out of me...
Click to expand...
Click to collapse
See the original post now for the Photoshop source files!
Version 1.18.1
For those that subscribe to the thread, this is notification of a new version in the First Post.
Change Log
2009.09.24
v1.18.1
Converted 709 KB bmp file into 94 KB gif with no data loss. The screen should now load much faster.
Updated CAB file installation to allow for Storage Card installation.
Thanks a lot for this.
If anyone doesn't know there is a HP Calculator Conference in Fort Collins, CO next weekend.
http://holyjoe.net/hhc2009/
help on resizing the skin hp48gx
I have tried to resize it with photoshop, but I don't know how to remap the keys.
Could be a way to include scroll bar option?
Thanks