给大家一个很好的建议，那就是在Symbian程序开发中保持主引擎和GUI分离。最简单的方法是适用静态DLL代替ECOM插件，这个时候开发者会遇到这样的问题：为什么要冻结DLL 呢？

我们在SDK和网上都可以找到很多资源，但是到处都没有能找到我们为什么要这样做。

1. 需要冻结
好的DLL需要在发布之前冻结他们的输出，以致确保和新版本库的向后兼容性。必须确保现有版本的库和以后版本库的DLL的函数顺序一直，甚至包括新函数的添加。这个描叙就是冻结的目的。但是当冻结时发生什么呢？他是必须的吗？

2. 冻结的原因
在搜索解决方案的时候我发现，问题被定位到PETRAN，PETRAN工具可以为ARM对象去掉可执行文件的相关组件信息，因此使用DLL会小得多因此ARM对象仅仅支持顺序的链接。

3. 冻结过程
当DLL被构建每个输出的函数被分配一个唯一的整数值作为他的顺序。DLL函数在运行时通过使用他的顺序值被调用。举个例子，可以认为是某一个特定情节。

设想我们开发一个DLL，它将作为第三方的接口发布某些功能，我们发布一个DLL和相应的输出库。现在开发者使他们的程序与输出库链接，然后DLL不在与我们使用的DLL兼容，因此输出库需要使用链接前的顺序。

输出库和DLL顺序值必须得匹配，如果应用程序链接到老的输出库，调用一些输出函数那么错误的功能将被调用。无论什么函数，现在必须得按照顺序来调用。

看下面的例子，列举了Somedll.dll的函数：[attach]50[/attach]

现在上面的输出函数的顺序可能看起来像这样：


随后我们伴随相应的库发布这个DLL，在定义中匹配的是内联函数。

在客户端程序调用输出库的SomedllFunction2 时，它将通过函数顺序号2来调用DLL中相应的SomedllFunction2()函数。[attach]51[/attach]

现在如果DLL发生变化，可能会使SomedllFunction()函数得到一个新的顺序号。而应用程序使用的是老的DLL输出库可能不能正常工作。

为了使开发简单，必须保证界面DLL的兼容性。

Symbian application development best practice suggests keeping the main engine and gui part separately. And the easiest way to do this is by developing a static DLL instead of a ECOM plug. While doing so every symbian developers do come across this question. Why do we need to freeze the DLL?
We have enough resource in sdk and on the internet, but nowhere I was able to get why do we have to do it.

1. Need for Freeze Well DLLs should freeze their exports before release, so as to ensure the backward compatibility of new releases of a library. It works by ensuring that the function ordinals currently available in a released import library correspond with the ordinals used by future versions of the DLL, even when new functions are added. . .. This explains the purpose of freeze. But what happens when you freeze? Is it that necessary?
   
2. Reason for Freeze
   After hunting for the solution I found this, the blame should go to PETRAN. The petran tool strips a Portable Executable format file of its irrelevant symbol information for an ARM target; thus making DLLs much smaller. As a consequence, ARM targets only support linking by ordinal.
3. Freeze Process
   When the DLL is built each exported function is assigned a unique integer value known as an ordinal. DLL functions are invoked at runtime using these ordinal values. To illustrate this lets consider this scenario.
   Imagine that we are developing a DLL that will be released as a 3rd part interface for some functionality; we release the DLL itself and a corresponding import library. Now developers are linking their application with this import library. Now we want to update our DLL or to add some other interfaces and re-release it. After modify the DLL, the function ordinals change, then that DLL is no longer compatible with the applications that use our DLL, since the import library they link to Uses the previous function ordinals. The import library and the DLL ordinal numbers must match. if applications linked with the older import library are run – and on calling some import function the wrong function in the DLL will be invoked .whatever function is now corresponds to this ordinal will be invoked.
   To illustrate this see the fig below. Example Somedll.dll with functions
   
   Now the ordinals for the above exported function may look some thing like this
   SomedllFunction1 – 1
   SomedllFunction2 - 2
   After we release the dll along with the corresponding library the match is inline with the definition.
   In client application calling the import library’s SomedllFunction2 will invoke the corresponding SomedllFunction2()function in the DLL by looking up function ordinal number 2.
   
   Now if we have to make some changes to our dll, this may result in somedllFunction() function gets a new ordinal number. Now the application developed using our older dll an import libray may not work because of this reason.
   To make the developers life easy and to keep the compatabiliy freeze is a must for our interface dll’s
   

【原文地址】

看懂了，谢谢搂主的好贴。