System 6 (Systemicus) GUI, some aspects

Work continues on OS System 6 (formerly Systemicus). A little dealt with the GUI - except for some shortcomings, it is already close to the working version. What is this brief article.

Looking ahead, I post ( github.com/omegicus/System6 ) an HDD image for testing at QEMU (it’s too early to experiment with a minimum memory value - set from 64 MB, although it should work at lower values). If someone wants to open an image, here is a link to GitHub with a brief description of the file system and a Windows-tool for mounting it. github.com/omegicus/OMFS3

So, I’ll just share my experience (far from being final) of creating a GUI for an operating environment. For everything, basically two files are responsible - explorer.exe (9 kilobytes) and user32.dll (31 Kb).
')
Actually, we should already be able to display graphic primitives and I will not describe this topic, in my opinion, it’s more interesting to understand the background.

The main structure of the window manager is the window texture. Each entry is represented by the following structure (in my implementation):

WNDLIST_ITEM:
.handle dd 0 ; +00
.x dd 0 ; +04
.y dd 0 ; +08
.width dd 0 ; +12
.height dd 0 ; +16
.flags dd 0 ; +20
.rsrc dd 0 ; +24
.parent dd 0 ; +28
.wbmp dd 0 ; +32
.caption dd 0 ; +36
;
.clickx dw 0 ; +40
.clicky dw 0 ; +42
.winstyle dd 0 ; +44
.icon dd 0 ; +48
;
.message dd 0 ; +52
.processid dd 0 ; +56
.res dd 0 ; +60
WNDLIST_ITEM_SZ = 64


Of interest is the .rsrc containing the .gui section of the PE executable (some analogy of the rsrc Windows PE file). When PE is loaded into memory, a standard block of memory is allocated to 64Kb for the section .gui and the specified section is copied there.

.parent points to the parent window (usually = 0, i.e. the parent is the desktop)
.wbmp points to a memory containing an 8-bit window image. 256 colors may seem small, but for my implementation this is enough. Those. the window is drawn in this buffer and only then displayed on the screen. Those. this is a shadow buffer.

.clickx, .clicky - contain the coordinates of the window where the cursor is now (even if the key is not pressed).
To track events (including pressing a keyboard or a mouse) there is a .message field - this is the place to put a pointer to an entry in the message structure. The structure of messages and their implementation can all be different, so I don’t write about it here.

Example of sending a message to the active application:
invoke SendMessage, [activeHndlr], WM_LBUTTONDOWN, param1, param2


A separate story with a kind of similarity Ddraw. I did not limit myself to the usual image display. The program should initiate the creation of the DDraw domain and write there directly. So far this has been implemented through an intermediate buffer, but the true approach consists, of course, in virtual memory remapping, so that the buffer points directly to the video memory. This is ahead. In the meantime, the structure of Ddraw windows is used, in which the coordinates and dimensions of the output window are written, the address of the video memory (more precisely, the offset with which the output begins) and the address of the buffer where the applications are written. The address of the video memory offset is optional, i.e. the system can calculate it, but this is done to speed up, so that with each frame output to the screen, this offset will not be calculated.



Now about the composition. In principle, the biggest problem that I encountered when creating a graphical environment is clipping pixels when windows overlap each other. In this demonstration, only one window, but the working implementation can be seen in one of my previous posts. Otherwise, the principle of operation is as follows:

1) drawing the background
2) drawing windows in shadow buffers (including window elements)
3) output data buffers on the screen.

Next, we track changes, namely the keyboard and mouse clicks, we transmit these messages to the appropriate windows. Some changes occur in the shadow buffers (either the application itself rendered something, or we changed the state of the buttons (the system does this)) and after that the desktop is updated, i.e. There is a redrawing of everything. This happens quite quickly, because just hidden buffers are copied to the screen.

Everything is quite simple and obvious, but it is at first glance. There is very little documentation on this topic and for those who write something from scratch (like me), many things are discovered through trial and error.