https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2015F_Lecture_17 2026-05-01T04:35:30Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2015F_Lecture_17&diff=20379&oldid=prev 2015-11-11T20:21:02Z

<p>Created page with &quot;==Video== The video from the lecture given on November 11, 2015 [http://homeostasis.scs.carleton.ca/~soma/os-2015f/lectures/comp3000-2015f-lec17-11Nov2015.mp4 is now availabl...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> The video from the lecture given on November 11, 2015 [http://homeostasis.scs.carleton.ca/~soma/os-2015f/lectures/comp3000-2015f-lec17-11Nov2015.mp4 is now available].<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 17<br /> ----------<br /> <br /> Administration<br /> <br /> * Solutions for Assignment 4 are up<br /> * Assigment 5 goes up tonight, is due on November 18th. Solutions<br /> will go up on the 19th. <br /> * Test 2 is on November 20th<br /> <br /> Project<br /> <br /> Graphics<br /> --------<br /> <br /> Devices<br /> - keyboards<br /> - printers<br /> - disks<br /> - tapes<br /> - text displays<br /> - text displays + keyboards = terminals<br /> <br /> Abstractions for devices:<br /> - character devices<br /> - non-cached data<br /> - block devices<br /> - cached data<br /> <br /> But what about graphics?<br /> <br /> How do printer graphics work?<br /> - send raster data (bits/pixels), but at 600dpi+, that&#039;s a lot of bits<br /> - fixed function commands (old inkjects)<br /> - text<br /> - simple geometric figures (circles, squares, lines)<br /> - raster images<br /> - create a program to generate the pages<br /> e.g., postscript<br /> <br /> <br /> Diversion: Kolmogorov complexity<br /> - smallest program that encodes a bitstring<br /> - random data means trivial program plus data<br /> <br /> lpr = line printer<br /> <br /> So what about the graphics display?<br /> <br /> Key difference - interactivity<br /> - how do I update the display, and do so quickly?<br /> <br /> Display types<br /> - text<br /> - raster graphics (bitmapped screen)<br /> - generally RAM mapped to screen<br /> - e.g., Apple II&#039;s<br /> - hardware accelerated graphics<br /> - manipulating RAM (frame buffer)<br /> - creating circles, lines, text, etc<br /> - fixed function<br /> - GPUs<br /> - send a program to the &quot;display&quot; and have it run the program<br /> - multiple programming languages<br /> - old: display Postscript, used by NeXTStep<br /> - later, display PDF (Quartz), used by Apple MacOS/iOS<br /> - OpenGL (Silicon Graphics, SGI), for 3D graphics<br /> - DirectX, Microsoft&#039;s alternative<br /> <br /> What about shared displays? (between programs)<br /> <br /> Need code to multiplex display between running programs<br /> - sounds like an OS job right?<br /> - could be in the kernel, but it is really complicated<br /> - normal practice is to abstract display management into a userspace process<br /> - kernel still does some low-level work<br /> <br /> - the classic display manager on UNIX is the X Window System<br /> - late 1980&#039;s<br /> - predated by proprietary UNIX graphics managers, classic MacOS, EARLY<br /> Windows, and Xerox PARC work<br /> <br /> Xerox PARC<br /> - company for making paper copies<br /> - created the Palo Alto Research Center (PARC) to develop new technologies<br /> - drew on work by Doug Engelbart (go watch the Mother of All Demos)<br /> - AMAZINGLY successful at developing tech, not so good at commercializing it<br /> - Graphical User Interfaces<br /> - Ethernet<br /> - Laser Printer<br /> <br /> X Windows was developed with Distributed Computing in mind<br /> - the X display manager was an &quot;X Server&quot; that served many &quot;clients&quot;<br /> - clients could run anywhere on the network<br /> - actually defined a network protocol for sharing displays, the<br /> X Windows protocol, implemented by a low-level library, Xlib<br /> <br /> X Windows is on the way out<br /> - network protocol was designed for fixed-function graphics<br /> - now we want to do compositing rather than manage windows<br /> - overlay graphical elements, not manage programs running in windows<br /> <br /> New generation of compositing managers, not network enabled<br /> - Wayland<br /> <br /> Fancy way of saying...<br /> - the kernel don&#039;t do much with graphics<br /> - there are graphics drivers, but they only have one customer,<br /> the display manager<br /> <br /> If you want to display something on the screen coming from the kernel...<br /> - use a userspace helper process!!!<br /> <br /> Processes like dbus relay data between processes<br /> - dbus can be slow because it copies data in memory<br /> - Android is faster because it uses a new kernel mechanism, Binder<br /> &lt;/pre&gt;</div>

Soma