📄 microwindows_architecture.html
字号:
<html><head><meta http-equiv="Content-Language" content="en-us"><meta http-equiv="Content-Type" content="text/html; charset=windows-1252"><meta name="GENERATOR" content="Microsoft FrontPage 4.0"><meta name="ProgId" content="FrontPage.Editor.Document"><title>MicroWindows Architecture</title></head><body><h1 align="left"><img border="0" src="file:///C:/My%20Documents/My%20Webs/myweb2/images/clouds.gif" width="72" height="33">Microwindows Architecture</h1><p align="left">1999/12/04 Copyright (c) 1999 Greg Haerr <<a href="mailto:greg@censoft.com">greg@censoft.com</a>> All Rights Reserved.</p><p align="left">This is my first cut at getting the architecture and implementationspilled out. Please let me know if there's more detail needed in some areas, orwhether you're confused by my explanations. This document is for educational andporting purposes, so please read on.</p><h3>Contents</h3><p>1. Architecture<br> 1.1 Layered Design<br> 1.2 Device Drivers<br> 1.2.1 Screen Driver<br> 1.2.2 Mouse Driver<br> 1.2.3 Keyboard Driver<br> 1.3 MicroGUI - DeviceIndependent Graphics Engine <br> 1.4 Applications ProgrammerInterfaces<br> 1.4.1 Microwindows API<br> 1.4.2 Nano-X API</p><p>2. Device-Independent Engine Features<br> 2.1 Graphics Engine Featuresand Implementation<br> 2.1.1 Regions<br> 2.1.2 Clipping<br> 2.1.3 Line Drawing<br> 2.1.4 Rectangles, Circles,Ellipses<br> 2.1.5 Polygons<br> 2.1.6 Area Fills<br> 2.1.7 Fonts<br> 2.1.8 Text Drawing<br> 2.1.9 Color model andpalettes<br> 2.1.10 Image Drawing<br> 2.1.11 Blitting</p><p>3. Microwindows API<br> 3.1 Message-passingarchitecture<br> 3.2 Window creation anddestruction<br> 3.3 Window showing, hidingand moving<br> 3.4 Window painting<br> 3.4.1 Client and screencoordinates<br> 3.4.2 Device contexts<br> 3.4.3 Graphics drawing API<br> 3.5 Utility functions<br> 3.5.1 Setting window focus<br> 3.5.2 Mouse capture<br> 3.5.3 Rectangle and Regionmanagement</p><p>4. Nano-X API<br> 4.1 Client/Server model<br> 4.2 Events<br> 4.3 Window creation anddestruction<br> 4.4 Window showing, hidingand moving<br> 4.5 Drawing to a window<br> 4.5.1 Graphics contexts<br> 4.5.2 Graphics drawing API<br> 4.6 Utility functions</p><h3>1. Architecture</h3><h3>1.1 Layered Design</h3><p>Microwindows is essentially a layered design that allows different layers to be used orrewritten to suite the needs of the implementation. At the lowest level, screen,mouse/touchpad and keyboard drivers provide access to the actual display and otheruser-input hardware. At the mid level, a portable graphics engine is implemented,providing support for line draws, area fills, polygons, clipping and color models. At the upper level, various API's are implemented providing access to the graphicsapplications programmer. These APIs may or may not provide desktop and/or windowlook and feel. Currently, Microwindows supports the ECMA APIW and Nano-X APIs. These APIs provide close compatibility with the Win32 and X Window systems, allowingprograms to be ported from other systems easily.</p><h3>1.2 Device Drivers</h3><p>The device driver interfaces are defined in device.h. A given implementation ofMicrowindows will link at least one screen, mouse and keyboard driver into thesystem. The mid level routines in the device-independent graphics engine core thencall the device driver directly to perform the hardware-specific operations. Thissetup allows varying hardware devices to be added to the Microwindows system withoutaffecting the way the entire system works.</p><h3>1.2.1 Screen Driver</h3><p>There are currently screen drivers written for Linux 2.2.x framebuffer systems, as wellas 16-bit ELKS and MSDOS drivers for real-mode VGA cards. The real mode drivers(scr_bios.c, vgaplan4.c, mempl4.c, scr_her.c) can be configured to initialize the VGAhardware directly, or utilize the PC BIOS to begin and end graphics mode. Theframebuffer drivers (scr_fb.c, fb.c, fblin?.c) have routines for 1, 2, 4 and 8bpppalletized displays, as well as 8, 15, 16, and 32 bpp truecolor displays. Theframebuffer system works in Linux by opening /dev/fd0 (or getenv("FRAMEBUFFER"))and mmap()ing the display memory into a linear buffer in memory. Some display modes,like the VGA 4 planes mode, require that OUT instructions be issued by the screen driver,while packed pixel drivers typically can get away with just reading and writing theframebuffer only. All the graphics mode initialization and deinitialization ishandled by the Linux kernel. Getting this set up can be a real pain.</p><p>The screen driver is the most complex driver in the system, but was designed so that itcan be extremely easy to port new hardware to Microwindows. For this reason, thereare but a few entry points that must actually talk to the hardware, while other routinesare provided that allow just the small set of core routines to be used, if desired. For example, a screen driver must implement ReadPixel, DrawPixel, DrawHorzLine, andDrawVertLine. These routines read and write a pixel from display memory, as well asdraw a horizontal and vertical line. Clipping is handled at the device-independentlayer. Currently, all mouse movement, text drawing, and bitmap drawing run on top ofthese low level functions. In the future, entry points will be provided for fasttext and bitmap drawing capabilities. If the display is palletized, a SetPaletteroutine must be included, unless a static palette that matches the system palette islinked into the system. The screen driver, on initialization, returns values tellingthe system the x,y size of the screen, along with the color model supported.</p><p>Two font models are currently provided, to be linked in at your desire. Theproportional font model has in-core font tables built from .bdf and other font conversionutilities provided. The rom-based font uses the PC BIOS to find the charactergenerator table address and has routines to draw that fixed-pitch font format.</p><p>The screen driver can choose to implement bitblitting, by ORing in PSF_HAVEBLIT intothe returned flags field. When present, bit blitting allows Microwindows to performoff-screen drawing. Microwindows allows any graphics operation that can be performedon a physical screen to be performed off-screen, and then copied (bit-blitted) to thephysical screen. Implementing a blitting screen driver can be fairly complex. The first consideration in implementing a blitting driver is whether the low-level displayhardware can be passed a hardware address for a framebuffer. If so, then the sameroutines that draw to the physical screen can be used to draw to off-screen buffers. This is the method used for the linear framebuffer drivers provided for Linux packed-pixeldisplays. The system replaces the mmap()'d physical framebuffer address with amalloc()'d memory address and calls the original screen driver entry point. In thecase where the system doesn't use an actual physical memory address, like when running ontop of X or MS Windows, then two sets of routines must be written; one to write the theunderlying graphics system hardware, and another to write to memory addresses. Inaddition, the blit entry point must then know how to copy both ways between the twoformats. In fact, all four operations, screen-to-memory, memory-to-screen,memory-to-memory, and screen-to-screen are supported by Microwindows and may need to beperformed. And of course the bit blitting routine must be _fast_. See thefiles fblin8.c and mempl4.c for examples of supporting both types of display hardware.</p><p>If writing your first screen driver, I would recommend you start with the PC BIOS realmode driver, scr_bios.c, or take a look at the framebuffer driver, scr_fb.c, which isessentially a wrapper around all the fblin?.c routines to read and write variousframebuffer formats. Don't set the PSF_HAVEBLIT flag at first, and you won't have towrite a bitblit routine from the start.</p><p>Note that currently, all SCREENDEVICE function pointers must be filled in to at least avoid function. For speed reasons, the system always assumes that the functionpointers are valid. Thus, even if not implementing bitblit, a do-nothing bit-blitprocedure must be provided.</p><h3>1.2.2 Mouse Driver</h3><p>There are three mouse drivers currently included in Microwindows. A GPM driverfor Linux, mou_gpm.c, as well as a serial port mouse driver for Linux and ELKS,mou_ser.c. For MSDOS, an int33 driver mou_dos.c is provided. The providedmouse drivers decode MS, PC and Logitech mice formats. A mouse driver's basicfunction is to decode the mouse data and return either relative or absolute data for themouse position and buttons.</p><p>In addition, Brad LaRonde has written a touch panel driver mou_tp.c, which masqueradesas a mouse driver. It returns the value of x, y value of the pen on the displaysurface, and can be used like a mouse.</p><p>Under Linux, the main loop of Microwindows is a select() statement, with filedescriptors for the mouse and keyboard driver always passed in. If the system thatMicrowindows is running on doesn't support select() or doesn't pass mouse data through afile descriptor, a Poll() entry point is provided.</p><h3>1.2.3 Keyboard Driver</h3><p>There are two keyboard drivers provided. The first, kbd_tty.c, is used for Linuxand ELKS systems where the keyboard is opened and read as through a file descriptor. The second, kbd_bios.c, read the PC BIOS for keystrokes and is used in MSDOS realmode. The keyboard driver currently returns 8-bit data from the keyboard, butdoesn't decode multi-character function key codes. This functionality will need to beadded soon, by reading termcap files or the like.</p><h3>1.3 MicroGUI - Device Independent GraphicsEngine</h3><p> The core graphics functionality of Microwindows resides in the device independent⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -