典型的例子是：List<Object> objects = (List<Object>) new List<String>()

可能很多人（包括我在内）起初都会认为这是无法理解的。那么请看下面的代码：

objects.add(new Integer(7));

假设前述的类型转换成立，那么这个objects实例中不就可以加入新的Integer项了？这等于是破坏了List<String>的约束。由于这个反例的存在，所以上述类型转换是不被Java所允许的。

从2001年的8.0、8.0a一直走到2008年的8.0x，PC-Lint v8一共延续了超过7个年头，估计不是考虑到26个英文字母的后缀都即将耗尽，Gimpel还舍不得用v9的版本号……

粗略看了一下v9的发布说明，相比v8确实有长足的进步（其实我想说的是，v8实在是发展的太落后了……）。不错，很好，很强大！

·终于加入了众望所归的线程分析，可检查锁使用的正确性以及可能缺少锁保护的变量。不过说实话我对这个特性尚持保留态度，因为多线程竞争分析在C/C++中是一个相当复杂的技术，还是等到试用之后再作评论。

·通过预编译头大幅提升复杂项目的检查速度。早该这么做了，PC-Lint对大型工程的检查速度实在不敢恭维。

·栈空间使用统计，可以汇总出单个应用的最大栈空间需求，只要程序中不存在递归并且是具有流程确定性的。赞一下这个功能，在嵌入式开发中尤其实用！

» Read more…

前两天为了在C下编写一个类似Erlang式消息传递的框架，需要定义一个receive宏，使得coroutine处理函数的编写可以类似这样：

int foo()
{
    ...
    receive(msg)
    {
        // Deal with the message
    }
    ...
    receive(msg)
    {
        // Deal with another message
    }
    ...
}

因为foo()函数以coroutine方式执行，所以消息的及时释放就显得尤为重要了，receive()之后紧接的代码块就是这个消息的生存周期，完成之后需要立即对消息进行释放。这就对receive宏的编写提出了一个特别的要求：包含扫尾工作。

» Read more…

升级到Windows Server 2008后，面临最大的一个挑战便是Symbian开发环境的迁移。让Carbide + S60第三版SDK 工作在Vista下的讨论已经比较多了，实现起来也并不复杂，所以本文主要关注Symbian 6.1等低版本OS的迁移问题，并以Nokia S60 SDK 1.2在Windows 2008 (x64)为蓝本进行说明，方法同样适用于Symbian 7.0s/8.1和Windows Vista (x86/x64)系统。

兼容性问题主要集中在GCC和模拟器上，后者相对比较容易，只需赋予管理员运行权限即可。GCC则是一个真正的麻烦事儿，由于它是Symbian为其工具链所改造的一个GCC 2.9的私有版本，不同于主版本分支，目前也没有继续的维护者^[*]。Vista之后版本的Windows由于DEP和安全性保护的增强，使得GCC在编译中会出现“Exception: STATUS_ACCESS_VIOLATION”错误，即使定向关闭DEP或者完全关闭DEP也无济于事。为GCC工具所有的执行文件赋予管理员权限同样不管用，错误表现可能会有差异，但结果都一样。

» Read more…

IDA Pro 5.2自带了Symbian的导入符号映射表，但Emulator Build部分只含有Symbian 9系列的.ids文件。没有较早版本适用的，因为懒得去找旧版本IDA，所以自己写了下面这个批处理，可以快速的从.lib生成.ids，即IDA所需的导入符号映射表。

以.lib文件做参数时生成对应的.ids；不带参数则处理当前文件夹下全部的.lib文件。

@echo off
if %1. == . goto all
echo Process %1 ...
dumpbin /exports %1 | sed --text \"/         [ ]*[0-9]*    /!d;s/^[ \\t]*//;s/)$//;s/    / Name=/;s/ (/ Comment=/\" > %1.idt
zipids %1.idt
goto end
:all
for %%f in (*.lib) do call %0 %%f
:end

注1：调用到的三个工具，dumpbin是VC6中包含的，sed可以用UnxUtils中得到，zipids是IDA官方提供的附加工具包。
注2：只适用于Emulator Build，Target Build暂时还没有需求，因为IDA已经为Symbian提供了大部分.ids文件。

Merged to How to use unpublicized APIs in Symbian.

1. Why are these APIs unpublicized?

You can usually find the unpublicized APIs in four ways:

1. APIs are written in SDK document, but marked as “Published Partner” or “Internal”.
2. APIs are declared in header file with corresponding linkable library, but not documented.
3. APIs are dumped from linkable library, but nowhere declared.
4. APIs are exported from dynamic libraries without corresponding linkable library.

* “Linkable library” is a stub library which hold the information required for the linker to link client programs to the correct ordinals to the real dll. In emulator build or Symbian pre-9 toolchain, the linkable library is appeared as .lib file, but in target build of Symbian 9 onwards, it is actually a dummy dynamic library of ELF format with extension .dso.

» Read more…

经过两周业余时间的努力，终于初步完成了S60 3rd FP1中Position Provider接口(EPos Plug-in Framework)的反向工程（主要是CPositioner及相关类），并成功在模拟器上将测试第一个Demo Plug-in通过。

说起这个Position Framework，还真有点耐人寻味。 » Read more…

(1) Emulator Build (Win32 PE)

First, find the start address of section “.SYMBIAN” by typically using “dumpbin /section:.SYMBIAN <Excutable File>”.

The output looks like:

SECTION HEADER #6
.SYMBIAN name
30 virtual size
17000 virtual address (00417000 to 0041702F)
1000 size of raw data
17000 file pointer to raw data (00017000 to 00017FFF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0000040 flags
Initialized Data
Read Write

According to the line containing “virtual address”, section “.SYMBIAN” starts at address 0×00017000.

Now, use any hex-editor to view the content at this address:

00017000h: 7A 00 00 10 00 00 00 00 B2 97 1F 10 5E 01 00 00
00017010h: B2 97 1F 10 57 B6 1F 10 B6 E1 0F 00 00 00 00 00

The first 3 dwords are UIDs: 0×1000007A stands for “Symbian EXE”, 0×101F97B2 is the unique UID of this file. (no UID2 for Symbian EXE, but this field is essential for DLL to indicate the framework, eg. 0×10009D8D for ECOM)

The capabilities field at offset 0×18h holds all the capabilities for this executive in the form of bitmask. Thus, 0×000FE1B6 is translated to the following capabilities: (see enumerator TCapability in Symbian SDK)

CommDD PowerMgmt ReadDeviceData WriteDeviceData TrustedUI ProtServ NetworkServices LocalServices ReadUserData WriteUserData Location SurroundingsDD UserEnvironment

(2) Target Build (Symbian PE)

3 UIDs located at the very beginning of the executive file, and the capabilities field is at fixed offset 0×88h. (same meaning as described for emulator build)

之前看过一些文章，在比较Symbian开发常用的两个IDE——VC和CodeWarrior时，都不约而同的提到了一点易用性上的差别：CodeWarrior不必重启模拟器就可以重新编译应用程序，言下之意用VC就必须重启模拟器才能再次编译程序并进行调试。（Carbide C++呢？老实说，我不知道，因为我一般不用那个河马一样笨重和迟缓的庞然大物……）

众所周知，Symbian模拟器的启动确实是一个漫长到可以顺便去煮咖啡的过程（机器配置高的朋友就别砸我了……），正因为上面提到的这一点劣势，很多人放弃了熟悉的VC而选择了重新学习陌生的CodeWarrior。其实，事情也不尽然如此。略施小计，我们也能在VC下实现开着模拟器重新编译应用。方法如下：

（1）在模拟器中退出你的应用程序。
（2）在VC下Detach EPOC进程：下拉菜单“调试”-“全部分离” 。
（3）OK，现在可以修改代码并重新编译你的应用程序了。
（4）编译好后，回到VC，重新Attach EPOC进程：下拉菜单“调试” -“进程”，在“可用进程”中选中“epoc.exe”并点击“附加…”。
（5）在模拟器中启动你的应用程序并继续调试吧。

上面的步骤可能稍显繁琐，但看在CW那昂贵License的份上，还是继续用我们亲切的VC吧~ ;)

注：这个方法可能不适用于调试一些特殊程序，比如OFS插件，因为它们始终在被系统使用而无法从内存中卸载。不过这种情形下我相信CW也同样没辙吧。