Proceedings of the FREENIX Track: 2004 USENIX Annual Technical Conference

Total Page:16

File Type:pdf, Size:1020Kb

Proceedings of the FREENIX Track: 2004 USENIX Annual Technical Conference USENIX Association Proceedings of the FREENIX Track: 2004 USENIX Annual Technical Conference Boston, MA, USA June 27–July 2, 2004 © 2004 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. How Xlib is Implemented (And What We're Doing About It) Jamey Sharp Computer Science Department Portland State University Portland, OR USA 97207–0751 [email protected] http://xcb.freedesktop.org Abstract side implementation of the X protocol, with goals of im- proving the usability of X in several cases: The X Window System is the de facto standard graph- • Resource-constrained environments, such as PDAs. ical environment for Linux and Unix hosts, and is usable • Developers wanting to understand how X works. on nearly any class of computer one could find today. Its • Developers implementing X protocol extensions. success is partially due to its flexible, extensible design. • Users desiring better-performing applications. Unfortunately, as research proceeds on cutting-edge window system functionality, the brittleness of the un- Xlib spans more than 400 source files, contains more derlying software is a critical impediment to progress. than 150,000 lines of code, and compiles to a roughly Xlib, the client-side implementation of the network pro- 750kB shared library on Linux/i386. On a typical Linux tocol that underlies X, is one source of these issues. system, this puts Xlib among the top libraries as mea- Many developers working on new features in the X pro- sured by code size. tocol are discovering that Xlib requires changes to sup- This paper has several major parts: a tour of Xlib, port these features, but Xlib makes those changes diffi- an explanation of several current efforts to improve X, cult. For more than 15 years, new features have been some observations on software engineering, and a brief added to Xlib by accretion, rather than with careful de- glimpse at the future. sign. We discuss the implementation of Xlib and analyze 2 The Architecture of Xlib some specific difficulties in it that cause problems in un- As we are not aware of a comprehensive tour of the Xlib derstanding and maintaining this code base. We also source, we present one here. present our current work on migrating the X Window Xlib stores more than a kilobyte of data about each System to a more maintainable, carefully designed ar- X server connection in a structure named a Display. chitecture. This includes • 1 Introduction The file descriptor and other information about the transport. At the core of the X Window System [SG86] is a net- • Other file descriptors to monitor for new data. work protocol, allowing any number of X applications • An assortment of values cached from the server. running on far-flung machines to interact with a single • Pointers used for internal memory management. keyboard, mouse, and monitor. Nearly all applications • Function pointers to hooks. currently use Xlib [SGFR92], a C library dating to the The hooks in Xlib allow extensions and applications to mid-1980s, to interact with the X protocol. modify the way Xlib handles Software developers have collectively learned a lot • about the engineering of software in the decades since Thread synchronization. • X was created. This fact explains some, though not all, Conversion between wire protocol and C structures. • of the difficulties that users and developers experience XID allocation. • when working with X. (Other issues are explained later Management of graphics contexts and server fonts. • in this paper.) Our previous work on a new X-protocol C Buffer flushes. • Binding [MS01] and subsequently an Xlib Compatibil- Connection close. ity Layer [SM02] were efforts to apply current best prac- When an X client successfully establishes a connec- tices in software engineering to the core of the client- tion to a server, the server sends several hundred bytes cut buffers gc image icccm i18n Much of the code in this layer comes from xtrans, a xom module comprising several .c and .h files. Code that resource db cms xkb utility xlc uses xtrans instantiates it in one of several variants by defining an appropriate C preprocessor macro before in- xim protocol cluding not just Xtrans.h, but also transport.c. core protocol events Available variants are X11, XSERV, Xim, FS, Font, Ice, transport region TEST, and LBXPROXY: while there are occasional sub- Figure 1: Notional Xlib components: arrows indicate tle differences, these variants differ mostly in symbol “using” relationships names. Xlib uses two variants of xtrans, X11Trans and Xim- Trans, meaning that all of the code in xtrans is linked of information about the capabilities of the display. Xlib into Xlib twice. The first variant is used in the transport copies some of that information into the Display; the rest layer, while the second is used by X input methods. We is kept in other structures pointed to by the Display. focus on the first of these here. Once connection setup is complete, requests from the Nothing in the extension libraries and applications client and responses from the server are the fundamen- that we have tested uses X11Trans directly. Within Xlib, tal elements of the X protocol. Requests always have calls to X11Trans are confined to four source files: Xlib- a “major opcode” identifying the kind of request, and a Int.c, OpenDis.c, ConnDis.c, and ClDisplay.c. As a re- length field that measures the number of four-byte words sult, rewriting Xlib to eliminate references to X11Trans needed to contain the entire packet. Responses come in is a relatively straightforward task. three forms: replies, events, and errors. Replies and er- rors are sent in response to requests, while events are 2.1.2 Protocol Layer sent spontaneously. On a Cray supercomputer, memory is not addressable in Only some request types call for a reply, but for any single-byte increments: in fact, it is addressable only in of those requests, a reply is always sent, unless an er- 64-bit increments. In X requests and responses, how- ror is sent instead. Errors can also occur for other re- ever, 32-bit values are aligned to 32-bit boundaries, 16- quests. Since X has a network-transparent protocol, it bit values to 16-bit boundaries, and so on. On a Cray, may be run on high-latency connections such as dial-up then, accessing individual components of a request or or DSL Internet links, and on these links replies take response is inefficient. long enough to arrive that the delay may have a notice- Xlib is designed to unpack the wire protocol data from able effect on application performance. In analyzing this responses into structures that may be efficiently accessed aspect of X performance, we speak of round-trip latency, by the host, and to similarly pack data into requests. and look for techniques to avoid or hide it [PG03]. Many parts of the protocol are represented by a pair Xlib was originally written without much concern for of structures in Xlib, namely the wire protocol struc- type-safety, but with great care to minimize the number ture and the host structure. By convention, the names of of function calls. As a result, the C preprocessor gets wire structures are of the form xIDReq for requests and heavy use when compiling Xlib. Many of the most com- xIDReply for replies, with various IDs, and in general monly executed statements in Xlib are macros. components of these structures correspond only to argu- 2.1 Xlib Layers ments to functions. The core event wire type is xEvent and corresponds to host structures named XIDEvent. As shown in Figure 1, Xlib can be thought of as having The core error wire type is xError, and corresponds to several distinct layers and components. An analysis of XErrorEvent. the size of these notional components is in Section 6.2. For all of the wire protocol structures, C preprocessor Unfortunately, within the code the boundaries are not symbols with names like sz xEvent are defined equal as clear as is suggested by the figure. In fact, we are to the number of bytes that the structure occupies on the not aware of any previous efforts to describe Xlib in this wire. Request structures also have their opcode (major if manner. However, these boundaries will be useful in our core, minor if extension) in #defines. Structures have analysis of Xlib, and correspond to the vocabulary com- fixed-length parts, but no variable-length representation. monly used in conversation among Xlib developers. When Xlib accesses a Display, perhaps to construct a request or process a response, it must protect the Dis- 2.1.1 Transport Layer play against simultaneous accesses by other threads. The The transport layer is responsible for conveying requests LockDisplay and UnlockDisplay macros are provided and responses between the X client and server. This for this purpose. All access to a Display must be brack- layer is independent of the semantics of those packets. eted by a LockDisplay and UnlockDisplay pair. To deliver a request to the server, Xlib must allocate GC are truly different on the client than on the server. both a sequence number and a block of memory to con- The FlushGC macro hides these details. struct the request in. Both of these allocations are han- It is frequently convenient to have a standardized set dled by the GetReq macro or its variants: GetResReq, of strings for inter-client communications, but prefer- GetEmptyReq, and GetReqExtra.
Recommended publications
  • R&S®BBA100 Broadband Amplifier Open
    R&S®BBA100 Broadband Amplifier Open Source Acknowledgment 5353.8300.00 – 01 /RL/1/EN 01.00 / Broadcasting 3575.4620.02 M: - T - PAD Open Source Acknowledgment R&S BBA100 Introduction Contents 1 Introduction ......................................................................................... 3 1.1 Disclaimer ..................................................................................................................... 3 1.2 How to obtain the source code .................................................................................. 3 2 Software packages ............................................................................. 4 3 Verbatim license texts ........................................................................ 7 3.1 Apache License 2.0 ..................................................................................................... 7 3.2 GNU Library General Public License, Version 2.0 (LGPL 2.0) ..............................10 3.3 Boost Software License ............................................................................................18 3.4 GNU General Public License, Version 2.0 (GPL 2.0) ..............................................18 3.5 GNU Lesser General Public License, Version 2.1 (LGPL 2.1) ...............................24 3.6 Mozilla Public License, Version 1.1 (MPL 1.1) ........................................................32 3.7 MIT ...............................................................................................................................40 3.8 JDOM License
    [Show full text]
  • Release Notes for X11R6.8.2 the X.Orgfoundation the Xfree86 Project, Inc
    Release Notes for X11R6.8.2 The X.OrgFoundation The XFree86 Project, Inc. 9February 2005 Abstract These release notes contains information about features and their status in the X.Org Foundation X11R6.8.2 release. It is based on the XFree86 4.4RC2 RELNOTES docu- ment published by The XFree86™ Project, Inc. Thereare significant updates and dif- ferences in the X.Orgrelease as noted below. 1. Introduction to the X11R6.8.2 Release The release numbering is based on the original MIT X numbering system. X11refers to the ver- sion of the network protocol that the X Window system is based on: Version 11was first released in 1988 and has been stable for 15 years, with only upwardcompatible additions to the coreX protocol, a recordofstability envied in computing. Formal releases of X started with X version 9 from MIT;the first commercial X products werebased on X version 10. The MIT X Consortium and its successors, the X Consortium, the Open Group X Project Team, and the X.OrgGroup released versions X11R3 through X11R6.6, beforethe founding of the X.OrgFoundation. Therewill be futuremaintenance releases in the X11R6.8.x series. However,efforts arewell underway to split the X distribution into its modular components to allow for easier maintenance and independent updates. We expect a transitional period while both X11R6.8 releases arebeing fielded and the modular release completed and deployed while both will be available as different consumers of X technology have different constraints on deployment. Wehave not yet decided how the modular X releases will be numbered. We encourage you to submit bug fixes and enhancements to bugzilla.freedesktop.orgusing the xorgproduct, and discussions on this server take place on <[email protected]>.
    [Show full text]
  • THINC: a Virtual and Remote Display Architecture for Desktop Computing and Mobile Devices
    THINC: A Virtual and Remote Display Architecture for Desktop Computing and Mobile Devices Ricardo A. Baratto Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Graduate School of Arts and Sciences COLUMBIA UNIVERSITY 2011 c 2011 Ricardo A. Baratto This work may be used in accordance with Creative Commons, Attribution-NonCommercial-NoDerivs License. For more information about that license, see http://creativecommons.org/licenses/by-nc-nd/3.0/. For other uses, please contact the author. ABSTRACT THINC: A Virtual and Remote Display Architecture for Desktop Computing and Mobile Devices Ricardo A. Baratto THINC is a new virtual and remote display architecture for desktop computing. It has been designed to address the limitations and performance shortcomings of existing remote display technology, and to provide a building block around which novel desktop architectures can be built. THINC is architected around the notion of a virtual display device driver, a software-only component that behaves like a traditional device driver, but instead of managing specific hardware, enables desktop input and output to be intercepted, manipulated, and redirected at will. On top of this architecture, THINC introduces a simple, low-level, device-independent representation of display changes, and a number of novel optimizations and techniques to perform efficient interception and redirection of display output. This dissertation presents the design and implementation of THINC. It also intro- duces a number of novel systems which build upon THINC's architecture to provide new and improved desktop computing services. The contributions of this dissertation are as follows: • A high performance remote display system for LAN and WAN environments.
    [Show full text]
  • Porting a Window Manager from Xlib to XCB
    Porting a Window Manager from Xlib to XCB Arnaud Fontaine (08090091) 16 May 2008 Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version pub- lished by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Contents List of figures i List of listings ii Introduction 1 1 Backgrounds and Motivations 2 2 X Window System (X11) 6 2.1 Introduction . .6 2.2 History . .6 2.3 X Window Protocol . .7 2.3.1 Introduction . .7 2.3.2 Protocol overview . .8 2.3.3 Identifiers of resources . 10 2.3.4 Atoms . 10 2.3.5 Windows . 12 2.3.6 Pixmaps . 14 2.3.7 Events . 14 2.3.8 Keyboard and pointer . 15 2.3.9 Extensions . 17 2.4 X protocol client libraries . 18 2.4.1 Xlib . 18 2.4.1.1 Introduction . 18 2.4.1.2 Data types and functions . 18 2.4.1.3 Pros . 19 2.4.1.4 Cons . 19 2.4.1.5 Example . 20 2.4.2 XCB . 20 2.4.2.1 Introduction . 20 2.4.2.2 Data types and functions . 21 2.4.2.3 xcb-util library . 22 2.4.2.4 Pros . 22 2.4.2.5 Cons . 23 2.4.2.6 Example . 23 2.4.3 Xlib/XCB round-trip performance comparison .
    [Show full text]
  • Gtk Drawing Area Example C
    Gtk Drawing Area Example C Abyssinian Cary always Indianised his examination if Amadeus is lowest or marshalling skywards. Ornithischian Rudd overruled, his deportation backscatters remilitarizing proud. Zodiacal Udale alkalizing: he repay his ceorl jazzily and observantly. End angle bracket iter to indicates data to c gtk drawing area Programming with gtkmm 3. You should only grab from gtk drawing area widget draws with either create. These programmatically hidden from the properties are put there are created and executable program that all gtk app into boxes, i am doing. This locus the 'traits' of the GtkDrawingArea widget are inherited to this class. GtkDrawingArea gtk-30 Valadoc. M cm else return cm m xm def drawself ctx area tops the egg. Gmcs pkggtk-sharp-20 rusrlibmono20MonoCairodll simplecs Here saying how we compile the example DrawingArea darea new. This source code of examples have thrown me at least we will create a button click to retrieve them into those who must be updated. How to integrate those header-only libraries and uses Catch as an example. We just ugly cast. The error comes from C I over no danger about tablet to drift this drawingrb. Useful for detriment to extract multiple copies of chair same dialog. For example if most have created a dialog box for entering some personal information you. Drawing operation draws the examples are the interior of. Application runs the example draws some way to be used for single cell renderer to this will execute it! This is prominent example in object-oriented behavior enforced in C by GTK. GtkDrawingArea getDrawingAreaStructbool transferOwnership false.
    [Show full text]
  • Writing Applications with GTK+ 1 Introduction
    + Writing Applications with GTK Owen Taylor April Introduction Graphical user interfaces have b ecome almost universally familiar However it may b e worth saying a few words ab out how graphical user interfaces work in Linux and X from the p oint of view of the programmer The X server is resp onsible for only the simplest op erations of drawing graphics and text on the screen and for keeping track of the users mouse and keyboard actions Pro grams communicate with the server via the Xlib library However programming applications in straight Xlib would b e a tremendous chore Since Xlib provides only basic drawing commands each application would have to provide their own co de to user interface elements such as buttons or menus Such user interface elemenets are called widgets To avoid such a lab orious job and to provide consistancy b etween dierent applications the normal practice is to use a to olkit a library that builds on top of Xlib and handles the details of the user interface The traditional choices for such a to olkit have b een two libraries built up on X Intrinsics libXt library distributed with X the Athena Widgets which are distributed with X and Mo 1 tif However Xt is complicated to learn and use the Athena Widgets havent lo oked stylish since and Motif while somewhat more up to date is large slow has an app earance disliked by many p eople and most imp ortantly is a proprietary pro duct without freely available source co de For these reasons and others much recent development has fo cused on to olk its that build directly
    [Show full text]
  • Fundamentals of Xlib Programming by Examples
    Fundamentals of Xlib Programming by Examples by Ross Maloney Contents 1 Introduction 1 1.1 Critic of the available literature . 1 1.2 The Place of the X Protocol . 1 1.3 X Window Programming gotchas . 2 2 Getting started 4 2.1 Basic Xlib programming steps . 5 2.2 Creating a single window . 5 2.2.1 Open connection to the server . 6 2.2.2 Top-level window . 7 2.2.3 Exercises . 10 2.3 Smallest Xlib program to produce a window . 10 2.3.1 Exercises . 10 2.4 A simple but useful X Window program . 11 2.4.1 Exercises . 12 2.5 A moving window . 12 2.5.1 Exercises . 15 2.6 Parts of windows can disappear from view . 16 2.6.1 Testing overlay services available from an X server . 17 2.6.2 Consequences of no server overlay services . 17 2.6.3 Exercises . 23 2.7 Changing a window’s properties . 23 2.8 Content summary . 25 3 Windows and events produce menus 26 3.1 Colour . 26 3.1.1 Exercises . 27 i CONTENTS 3.2 A button to click . 29 3.3 Events . 33 3.3.1 Exercises . 37 3.4 Menus . 37 3.4.1 Text labelled menu buttons . 38 3.4.2 Exercises . 43 3.5 Some events of the mouse . 44 3.6 A mouse behaviour application . 55 3.6.1 Exercises . 58 3.7 Implementing hierarchical menus . 58 3.7.1 Exercises . 67 3.8 Content summary . 67 4 Pixmaps 68 4.1 The pixmap resource .
    [Show full text]
  • Security at Extreme Scales
    SECURITY AT EXTREME SCALES Recommended Citation Eric Grosse, "SECURITY AT EXTREME SCALES", NAPSNet Special Reports, May 30, 2019, https://nautilus.org/napsnet/napsnet-special-reports/security-at-extreme-scales/ ERIC GROSSE MAY 30, 2019 I. INTRODUCTION 1 In this paper, Eric Grosse argues: “Much of the security progress over the past decade has been at large-scale, finding and patching vulnerabilities in widely used applications or defending networks of millions of machines containing high-value data. The lessons there may help military systems, but for the very highest security needs such as NC3, we ought to return to basics and harden small-scale systems. And we ought to do it as a joint effort, even between adversaries.” Eric Grosse was Google's VP Security & Privacy Engineering. Before Google, Eric was a Research Director and Fellow at Bell Labs. He has a Ph.D. in Computer Science from Stanford. Acknowledgments: The workshop was funded by the John D. and Catherine T. MacArthur Foundation. This report is published simultaneously here by Technology for Global Security and here by Nautilus Institute and is published under a 4.0 International Creative Commons License the terms of which are found here. The views expressed in this report do not necessarily reflect the official policy or position of the Nautilus Institute. Readers should note that Nautilus seeks a diversity of views and opinions on significant topics in order to identify common ground. A podcast with Eric Grosse, Peter Hayes, and Philip Reiner on NC3 and security at extreme scales is found here. The views expressed in this report do not necessarily reflect the official policy or position of the Nautilus Institute.
    [Show full text]
  • X Window System Network Performance
    X Window System Network Performance Keith Packard Cambridge Research Laboratory, HP Labs, HP [email protected] James Gettys Cambridge Research Laboratory, HP Labs, HP [email protected] Abstract havior (or on a local machine, context switches between the application and the X server). Performance was an important issue in the develop- One of the authors used the network visualization tool ment of X from the initial protocol design and contin- when analyzing the design of HTTP/1.1 [NGBS 97]. ues to be important in modern application and extension The methodology and tools used in that analysis in- development. That X is network transparent allows us volved passive packet level monitoring of traffic which to analyze the behavior of X from a perspective seldom allowed precise real-world measurements and compar- possible in most systems. We passively monitor network isons. The work described in this paper combines this packet flow to measure X application and server perfor- passive packet capture methodology with additional X mance. The network simulation environment, the data protocol specific analysis and visualization. Our experi- capture tool and data analysis tools will be presented. ence with this combination of the general technique with Data from this analysis are used to show the performance X specific additions was very positive and we believe impact of the Render extension, the limitations of the provides a powerful tool that could be used in the analy- LBX extension and help identify specific application and sis of other widely used protocols. toolkit performance problems. We believe this analysis With measurement tools in hand, we set about char- technique can be usefully applied to other network pro- acterizing the performance of a significant selection of tocols.
    [Show full text]
  • FLTK 1.1.8 Programming Manual Revision 8
    FLTK 1.1.8 Programming Manual Revision 8 Written by Michael Sweet, Craig P. Earls, Matthias Melcher, and Bill Spitzak Copyright 1998-2006 by Bill Spitzak and Others. FLTK 1.1.8 Programming Manual Table of Contents Preface..................................................................................................................................................................1 Organization.............................................................................................................................................1 Conventions.............................................................................................................................................2 Abbreviations...........................................................................................................................................2 Copyrights and Trademarks.....................................................................................................................2 1 - Introduction to FLTK...................................................................................................................................3 History of FLTK......................................................................................................................................3 Features....................................................................................................................................................4 Licensing..................................................................................................................................................5
    [Show full text]
  • Xlib − C Language X Interface Xwindowsystem Standard Xversion 11, Release 7 Libx11 1.3.2
    Xlib − C Language X Interface XWindowSystem Standard XVersion 11, Release 7 libX11 1.3.2 James Gettys Cambridge Research Laboratory Digital Equipment Corporation Robert W.Scheifler Laboratory for Computer Science Massachusetts Institute of Technology with contributions from Chuck Adams, Tektronix, Inc. Vania Joloboff, Open Software Foundation Hideki Hiura, Sun Microsystems, Inc. Bill McMahon, Hewlett-Packard Company Ron Newman, Massachusetts Institute of Technology Al Tabayoyon, Tektronix, Inc. Glenn Widener,Tektronix, Inc. Shigeru Yamada, Fujitsu OSSI The X WindowSystem is a trademark of The Open Group. TekHVC is a trademark of Tektronix, Inc. Copyright © 1985, 1986, 1987, 1988, 1989, 1990, 1991, 1994, 1996, 2002 The Open Group Permission is hereby granted, free of charge, to anyperson obtaining a copyofthis software and associated documenta- tion files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify,merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Soft- ware. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOTLIMITED TOTHE WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTIC- ULAR PURPOSE AND NONINFRINGEMENT.INNOEVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,WHETHER IN AN ACTION OF CONTRACT,TORTOROTH- ERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
    [Show full text]
  • OCCT V.6.5.4 Release Notes
    Open CASCADE Technology & Products Products Version6. features, Highlights Technology CASCADE Open Overview , so applications linked against a previous version must berecompiled to run with this Version 6. Open CASCADE Technology & Products Technology Open CASCADE improvements and bug fixes over 6 Universal locale global current on independent made export / Import TKOpenGl libraries support plotter and viewer 2D obsolete of Removal Accelerated text visualization management texture of Redesign R and XCode Cocoa API with native visualization X, Mac OS On of support Official New automated testing system testing New automated and 3D graphics 2D both to way render unified the become input parameters and results and generation of data for bug rep bug for data of generation and results and parameters input . 0 efactored is binary incompatible withtheprevious versions CMake build scripts build CMake is nowis link Open CASCADE Open Boolean operations algorithm operations Boolean andProducts Mac OS X and Products Products and www. www. ed at build time, not at run time run at not time, build at ed opencascad Release Notes Notes Release opencascade M , Windows 8 and Visual Studio 2012 Studio Visual , and Windows 8 maintenance ; use of FTGL library is dropped FTGL of library ; use in version or e .co Release .org 6. m releas . Possibility to enable automatic check of of check automatic enable to Possibility . 6 . 0 ver. 6. ver. Technology is a Copyright © 2013 by OPEN CASCADE Page Copyright OPEN CASCADE 2013by © e 6. minor 5. 5 of . release, which includes 6 OpenCASCADE Technology . 0 4 project files files project ort . 3Dviewer over libraries 1 2 5 of 0 32 new 6 and and .
    [Show full text]