Interface = contract
An interface is also a kind of contract, but remember that the contract applies to both parties. In most cases, when we read the interface documentation, we look at the interface from the perspective of the interface client, but if we can understand it from the interface server, there will be unexpected gains.
Role play begins
Let's take an example: Interface for control panel
Usually when you have a document about the control panel interface, you will think that you are a client. For example, the document is written like this:
When the control panel manager first loads the "Control Panel" application, it will retrieve the CPIApplet function Address, and then use that address to call the function and pass the message.
Let's take a look at how this interface description is viewed in different roles.
Control panel application: I need to export a function called CPIApplet to receive information from the manager.
Control Panel Manager: I need to use GetProcAddress to get the CPIApplet address provided by the customer and send a message to it.
Regarding the message processing part, the role play is as follows:
Control Panel Application: I need to be ready to receive messages in the order stated in the document.
Control Panel Manager: I need to be ready to send messages in the order stated in the documentation.
There is also such a sentence in the document: The control panel manager needs to call the FreeLibrary function to release the control panel application.
Control Panel application: I better prepare for the upcoming uninstallation.
Control Panel Manager: I want to start uninstalling the DLL.
Practical example
Let's write a simple small program to demonstrate:
In addition to creating the display window and entering the message loop in the above code, our code represents a control panel manager. We used the control panel application access.cpl as a test program. After determining the path of the program, we call the following RunControlPanel function to perform most of the work, as shown in the following figure:
Please ignore the parts marked in red above, we will discuss them later.
What we do is actually follow the steps stated in the document, but from a server-side perspective. We loaded the DLL, located the function to be called, used CPL_INITL to call this function, and then CPL_GETCOUNT. If there are any control panel programs in this CPL file, we query their information and double-click, and finally stop.
After going through the above interesting work, we finally performed the cleanup work (by sending CPL_EXIT message) according to the requirements of the document.
That's it, then, what's the matter with the red part on it?
These are to support those control panel applications with custom lists, they are new things introduced in Windows XP.
If you use the v6 version of ComCtl32 or the DLL run by RunDll32.exe in the control panel, you will see: the application provides its manifest to the control panel host by appending its manifest as resource number 123. This is what the red code does: it loads and activates the list, then calls the control panel application to perform its operations (the list is active at this time), and then cleans up. If there is no list, CreateActCtx will return INVALID_HANDLE_VALUE. We do not regard this as an error, because many programs have not yet provided a list.
Practice questions after class
When calling SearchPath, we passed NULL in the first parameter. Will this have any security implications?
At last
Raymond Chen's "The Old New Thing" is one of my favorite blogs. It contains a lot of little knowledge about Windows, which is really helpful for the majority of Windows platform developers.
This article comes from: "You can read a contract from the other side"
