-
Notifications
You must be signed in to change notification settings - Fork 0
/
report.html
130 lines (130 loc) · 9.7 KB
/
report.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="generator" content="pandoc">
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
<title></title>
<style type="text/css">code{white-space: pre;}</style>
<!--[if lt IE 9]>
<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
</head>
<body>
<h1 id="patos---graphical-interface-and-tiling-window-manager">PatOS - Graphical Interface and Tiling Window Manager</h1>
<p>Team Members: Patricio Lankenau</p>
<h3 id="main-features">Main Features</h3>
<ul>
<li>Dynamic Tiling Window Manager</li>
<li>Secure window abstraction</li>
<li>Support for up to 6 windows</li>
<li>Arbitrary focus selection</li>
<li>Dynamic window addinga and removing</li>
<li>Automatic output history</li>
<li>Automatic window cleanup</li>
<li>Automatic Scrolling and resizing</li>
<li>VGA Output support</li>
<li>Full keyboard driver</li>
<li>User library (libwin)</li>
<li>Request window</li>
<li>Get window size</li>
<li>Clear window</li>
<li>16-Color support</li>
</ul>
<h3 id="extra-features">Extra Features</h3>
<ul>
<li>Dual output driver</li>
<li>Backspace support</li>
<li>Upgraded shell</li>
<li>Welcome program</li>
</ul>
<h1 id="window-manager">Window Manager</h1>
<p>The dynamic tiling window manager (dtwm) is tasked with managing the resource of windows, and abstracting away the positioning and actions on all the windows as a whole. It provides abstractions to add windows and remove windows. It is backed by a map from process ids to Window objects, where it stores the windows that are currently open. In addition to the window map, it keeps of track of what the current layout is.</p>
<h2 id="window">Window</h2>
<p>Manages the screen resources and creates abstractions for writing to the screen and moving the cursor around. The window stores metadata such as the title, size, location, and position. It also handles resizing and scrolling of the contents of the window. This is powered by a backing TextBuffer. The window is what makes the drawing calls to the VGA driver.</p>
<p>Windows are considered to be a per-process resource, with the exception that children will share their parent's window unless they request their own. Although they share it, the children cannot close the parent's window.</p>
<h3 id="textbuffer">TextBuffer</h3>
<p>Stores the characters and metadata in a buffer that's twice as big as the biggest window possible (80x25). It provides abstractions for writing to the buffer, as well as accessing data within the buffer, especially accessing data relative to the window size (eg: getting the correct 10 lines after the resized to a height of 10).</p>
<h2 id="layouts">Layouts</h2>
<p>Layouts are used to store window positions and sizes within the screen. This is backing feature behind the dynamic tiling window manager. Layouts are stored as an array of arrays of Layouts (<code>Layout***</code>). The array stores the specified array of layouts for a given number of windows. For example the layout array for 1 contains a single layout which dictates that the window should take up the whole screen (minus borders and the top OS line) and be positioned at the top left. Likewise, the layout for two windows specifies that there should be two windows, with full height, but half of the width, one positioned on the left and the other on the right. In order to facilitate the math required to calculate the specific widths, heights, and positions I created abstractions for the constructor a Layout object. The constructor takes the number of vertical and horizontal splits, and the position of the window within those splits. So a 1 window layout would have 1 vertical, 1 horizontal splits, and the 1st window vertically and horizontally. However, a two window layout would have two horizontal splits, 1 vertical splits. Adding a window brings the window manager to the next layout array, and removing a window brings it to the previous layout array. Whenever switching to a new layout, the window manager will resize, rescroll, and redraw all the windows.</p>
<p>The layouts I designed are as follows</p>
<p>1 window</p>
<pre><code>+---------------+
| |
| |
| |
| |
| |
+---------------+</code></pre>
<p>2 windows</p>
<pre><code>+-------+-------+
| | |
| | |
| | |
| | |
| | |
+-------+-------+</code></pre>
<p>3 windows</p>
<pre><code>+-------+-------+
| | |
| | |
| +-------+
| | |
| | |
+-------+-------+</code></pre>
<p>4 windows</p>
<pre><code>+-------+-------+
| | |
| | |
+-------+-------+
| | |
| | |
+-------+-------+</code></pre>
<p>5 windows</p>
<pre><code>+-------+-------+
| | |
| +-------|
+-------| |
| +-------|
| | |
+-------+-------+</code></pre>
<p>6 windows</p>
<pre><code>+-------+-------+
| | |
+-------+-------|
| | |
+-------+-------|
| | |
+-------+-------+</code></pre>
<h2 id="focus">Focus</h2>
<p>With the ability to have more than one window (and program) running on the screen at once, we had to introduce the concept of focus. Focus represents the currently running window, in other words the window that gets to print things to the screen and gets the input from the keyboard. This is extremely crucial because without out all windows would "fight" for the keyboard input and potentially also draw thigns wrong on the screen. In order to solve this problem, I added a focus event to every window. Whenever a program tries to get input, the process will first wait on the focus event. That way, if the window has focus, it can continue to get input from the keyboard while all other processes wait. This is also a good solution because it meant that programs that don't require input from the keyboard can continue running without focus.</p>
<p>The rules of focus are: 1. The program can run until it requires input without focus 2. Forking and executing a program that uses a window gives up your focus 3. Whenever a process with a window exits focus is given to the first window 4. Focus can be preempted by the user</p>
<p>To implement the fourth rule I mapped the Function keys (F1-F6) to switch focus to their corresponding windows. So pressing F1 switches focus to the first window, etc... This gives the user control over where the input goes. In order to inform the user of how to focus on windows, the window number is displayed with the title. Switching focus to a non-existant window does nothing.</p>
<p>Focus is represented with the blinking cursor on the screen. Switching focus to a given window will move the cursor to the correct position within that window (where it last was before the window lost focus).</p>
<h2 id="keyboard-driver">Keyboard Driver</h2>
<p>In order to compliment the support for the VGA, I also implemented a full keyboard driver, with support for all alphanumeric characters, as well as punctuation and extra characters. Finally I also added support for the function keys which serve as a way of selecting which window has focus.</p>
<h2 id="libwin---user-library">Libwin - User Library</h2>
<p>In order to expose all the features of my window manager and graphical support to user programs, I created libwin, an accompany user library. Distributed as a header file and assembly implementation, it allows user programs to interact with the window system.</p>
<p>The list of system calls is as follows:</p>
<p><code>win_req(const char* name)</code></p>
<p>Request a window with the specified name</p>
<p><code>win_color(int color)</code></p>
<p>Set the foreground color for subsequent text (16 bit color code)</p>
<p><code>win_cursor(int r, int c)</code></p>
<p>Draw the cursor</p>
<p><code>win_clear()</code></p>
<p>Clear your window</p>
<p><code>win_height()</code></p>
<p>Get your window height</p>
<p><code>win_width()</code></p>
<p>Get your window width</p>
<h3 id="upgraded-shell">Upgraded Shell</h3>
<p>As an example of how easy it is to incorporate the window system into existing user-level applications, I demonstrated an upgraded version of our shell. By calling <code>win_req("shell")</code> at the start of main, the system will create a window for the shell and automatically route all outcoming characters to the correct window. Including the headers and adding that line are the only modifications required to fully support the window system. However, I also added colored output using the <code>win_color</code> system call, to differentiate between the shell prompt, user input, informational output, and errors. Additionally, I modified the shell to spawn and disown additional shells as well as added the ability to exit a shell.</p>
<h3 id="welcome-program">Welcome Program</h3>
<p>As another example of the versatility of the user library and window program I wrote another demo program which uses the <code>win_req</code> and <code>win_color</code> system calls to draw a welcome message to screen</p>
<h3 id="clear-program">Clear program</h3>
<p>In order to demonstrate the <code>win_height</code> syscall, I also wrote a simple clear program that gets the current window size and prints that number of new lines to clear the current shell.</p>
<h3 id="dual-output-driver">Dual Output Driver</h3>
<p>Because the windows are very small, and it can confusing to combine debug output with window output, I created a dual output driver. This means that output from user programs and <code>Debug::printf</code> go to the current window, but output from <code>Debug::cprintf</code> goes to the serial output. This makes it much easier to debug because debug output goes to the serial and program output goes to the VGA driver.</p>
</body>
</html>