Symbian application development best practice suggests keeping the main engine and gui part separately. A good design should avoid creating unnecessary dependencies between components.Also, maximizing code reuse so that common functional requirements can be satisfied from shared libraries is very desirable. The engine for the intended application should be a functional unit that stands apart from whatever GUI layer represents the data to the user and allows them to interact with it. For the purposes of flexibility, it is best to allow the engine to reside in its own DLL and to offer its own API to any UI layer that might want to use it.
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?
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.
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
