More on that Symbian OS Parallels bug
So, now I’m using this blog like my personal wiki, but perhaps there’s somebody out there who wants to know.
For the S60 3rd edition SDK, here’s my fix for the bug I talked about a while back.
Open up \epoc32\release\winscw\udeb\ecust.dll in your favourite hex editor. Find this bit:
0002c10: 894d bcc7 45c0 0009 3d00 6a0f c745 fcff .M..E…=.j..E..
0002c20: ffff ffff 1538 4241 0050 c745 fcff ffff …..8BA.P.E….
0002c30: ffff 153c 4241 008d 45c4 50c7 45fc ffff …<BA..E.P.E…
0002c40: ffff ff15 4042 4100 83f8 000f 84a8 0000 ….@BA………
0002c50: 008b 45c0 4848 4848 4848 4848 4848 4848 ..E.HHHHHHHHHHHH
See the 84a8 above?
That ‘84′ corresponds to the second byte of the instruction :00402C4B 0F84A8000000 je 00402CF9, which jumps around the problematic code if QueryPerformanceCounter gives the wrong answer.
We want to always jump around the problematic code. So, change the 84 to 81. That will change it from “jump if equal” to “jump if not overflow”. My x86 assembler is useless, but hopefully the overflow bit will never be set, and the code will always be avoided. Parallels still haven’t replied to say whether it’s a bug in their VM or in Symbian OS or both.
Sorry to any non-techies reading.
There is a moral to this story, though, for anybody reading within Symbian: this is the sort of thing us ISVs have to go through, in order to get Symbian OS debugged without access to the source code. Great eh?!