In-depth analysis on new improvements of the MiniGUILite version

Article title: in-depth analysis of new improvements in the MiniGUILite version. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
　　 1 Introduction: why should we develop the Lite version?
　　
Currently, most UNIX systems use the X Window System as a graphical user interface, while MS Windows uses a GUI system designed by Microsoft. These two GUI systems also represent the two common GUI systems. For example, the well-known free software MicroWindows has simultaneously implemented MicroWindows APIs similar to MS Windows and NanoX APIs similar to X Window.
　　
MiniGUI originally adopted an architecture similar to MS Windows, and established a thread-based message transmission and window management mechanism. However, it is based on POSIX Threads, which provides the maximum degree of data sharing, but also results in the weak MiniGUI architecture. If a thread stops running because of illegal data access, the entire system will be affected.
　　
Another method is to use the UNIX inter-process communication mechanism to establish a Window system, that is, a client/server system similar to X Window. However, this architecture also has its inherent shortcomings, mainly because the normal IPC mechanism cannot provide efficient data replication, and a large amount of CPU resources are used to copy data between processes. In devices such as PDAs, this waste of CPU resources will eventually lead to a reduction in system performance and an increase in device power consumption.
　　
To solve the above problems and make MiniGUI more suitable for embedded systems, we have developed the MiniGUI Lite version.
　　
　　 2 Lite version
　　
In the MiniGUI Lite version, we can run multiple MiniGUI applications at the same time. First, we start a server program mginit, and then we can start other MiniGUI applications that run as customers. If the customer terminates for some reason, the server can continue to run. The mginit program creates a virtual console window. We can start other programs from the command line on the Virtual Console, or even debug these programs through gdb. This greatly facilitates debugging of the MiniGUI application.
　　
The biggest difference between MiniGUI-Lite and MiniGUI is that we can create multiple windows in the MiniGUI-Lite program, but cannot start new threads to create windows. In addition, almost all other APIs are compatible with the original MiniGUI version. Therefore, porting from the original MiniGUI version to the MiniGUI-Lite version is very simple. Similar to the program in the mglite-exec package, all the programs are from the miniguiexec package, and each source file has no more than five changes.
　　
　　 3. Lite version Design
　　
At the beginning of the design, we determined the development purpose of the MiniGUI Lite version:
　　
Maintain compatibility with the original MiniGUI version at the source code level of 98% or above.
LinuxThreads is no longer used.
You can run multiple MiniGUI Lite-based applications at the same time, that is, multiple processes, and switch between the frontend and backend processes.
Obviously, to meet these three design objectives, if the traditional C/S structure is used to transform the existing MiniGUI, it should not be difficult to achieve. However, the defects of the traditional C/S structure cannot be avoided. After analysis on PDA and other embedded systems, we found that some PDA products have the ability to run multiple tasks, but the screen at the same time for drawing programs, generally no more than two. Therefore, as long as the two processes are isolated from each other, there is no need to use a complex C/S structure to process the mutual cut between multiple process windows. In such a product, it is a waste to use a multi-window system based on the traditional C/S structure.
　　
Therefore, the MiniGUI-Lite version is simplified as follows:
　　
Each process maintains its own Z-order main window, and the main windows created by the same process are cut between each other. That is to say, except for only one thread and only one message loop, there is no difference between a process and the original MiniGUI version. Each process does not need to consider other processes when drawing the screen.
Establish a simple customer/server system, but ensure that data replication between processes is minimized. Therefore, data transmitted between the server and the customer is limited to the input data of the input device and some request and response data between the customer and the server.
There is a server process (mginit) that initializes some input devices and sends messages from the input devices to the MiniGUI Lite client process at the front end through UNIX Domain sockets.
The server and the customer are respectively limited to draw in two non-intersecting rectangles of the screen. at the same time, only one customer and the server can draw the screen. Other customers can continue to run, but the screen input is blocked. The server can use the API to switch a customer to the foreground. At the same time, the server and the customer use signals and System V semaphores for synchronization.
The server also uses the System v ipc mechanism to share some resources, including bitmap, icons, mouse, and font, to reduce the actual memory consumption.
　　 4. implementation details of Lite version
　　
4.1 initialize the system
The entry point of the application is the main () function, and the entry point of the MiniGUI application is MiniGUIMain. between these two entry points, the initialization part and the end part of the MiniGUI. 1.
　　 　
　　 Figure 1 MiniGUI application process
　　
During system initialization, MiniGUI is divided into two types: Server and Client ). The subsequent operations vary depending on the global variable mgServer. The server name can only be "mginit ". InitGUI () is a function used to initialize the MiniGUI. it is mainly responsible:
　　
Obtain information about the terminal.
Initialize the image abstraction layer.
If it is a server, it loads shared resources. if it is a customer, it establishes a connection with the shared resources.
Create a runtime environment related to window activities.
If it is a server, initialize the event-driven abstraction layer (IAL). if it is a customer, open the channel with the server event Drive.
If it is a server, set idle processing to IdleHandler4Server. if it is a customer, set idle processing to IdleHandle4Client.
Process 2 (to highlight the key points, we ignore some details ):
　　 　
　　 Figure 2 InitGUI process
4.2 initialize shared resources
Shared resources are an important element in the customer server model. they are created and released by the server and provide data resources shared by all customer programs. The initialization process is completed by the call stream shown in figure 3.
　　 　
　　 Figure 3 InitGUI call stream
If it is a server, initialize this structure. src/kernel/sharedres. c/LoadSharedResource () is responsible for completing this task. its execution flow is 4:
　　 　
　　 Figure 4 LoadSharedResource process
For customers, you only need to connect to this structure. it is implemented in src/kernel/sharedres. c/AttachSharedResource (). see figure 5.
　　 　
　　 Figure 5 AttachSharedResource process
4.3 Server customer communication connection initialization
In the discussion of the customer server model, we will also discuss in detail the communication mechanism of the server customer. here we only provide the initial call relationship. See figure 6.
　　 　
　　 Figure 6 communication connection initialization
ServerStartUp implementation process 7 is shown below:
　　 　
　　 Figure 7 ServerStartUp process
The implementation of ClientStartUp () is shown in Figure 8:
　　 　
　　 Figure 8 ClientStartUp process
4.4 Multi-process model
Lite version is a multi-process system that supports the client server (C/S) mode. only one server program is running during the running process, and its global variable mgServer is set to TRUE, the other MiniGUI applications are customers, and the mgServer variable is set to FALSE. Each application runs in different process spaces, as shown in Figure 9:
　　 　
　　 Figure 9 multi-process model
The current program structure enables each loaded process to have its own desktop model and its message queue. Inter-process communication relies on the process communication model mentioned below.
　　
4.5 Process Communication Model
Here we refer to process communication, including data exchange through shared memory and client server communication model implemented through sockets. First look at the communication model structure of using Socket in MiniGUI, 10:
　　 　
　　 Figure 10 Socket-based communication model
Next, let's take a look at the resource sharing problem between MiniGUI processes. See Figure 11.
　　
　　 Figure 11 memory shared communication model
As shown in, the server is responsible for loading shared resources, including system icons, bitmaps, and fonts. the customer obtains the pointer to shared resources through AttachSharedResource, the method for initializing a shared memory and using the existing shared memory is mentioned in the previous description and will not be described here.
　　
4.6 synchronization between processes
The process synchronization mentioned here mainly refers to the synchronization of various processes. Obviously, two processes cannot be drawn to the screen at the same time. Most of the traditional GUI implementations are drawn by only one process, and in our Lite version, each process is drawn by itself. At the same time, our Lite version also supports virtual screen switching. when we switch out, no one can draw to the screen.
　　
Lite version uses Unix signals to solve the problem of drawing synchronization. The system defines two signals: SIG_SETSCR and SIG_DNTDRAW. they are actually redefined signals SIGUNUSED and SIGSTKFLT. Each process defines two variables: dont_draw and cant_draw.
　　
The server uses SIG_SETSCR and SIG_DNTDRAW to control each client program who has the right to draw the screen, rather than acting on its own. This also greatly reduces inter-process traffic: when the server wants a client program not to draw to the screen, it sends the SIG_DNTDRAW signal to it and sends the SIG_SETSCR signal when drawing it. In this way, screen rendering between processes is synchronized.