Changeset 54


Ignore:
Timestamp:
Oct 8, 2006, 5:51:49 PM (19 years ago)
Author:
ktk
Message:

Plenty of changes, mostly done in Glengarriff, Ireland. This is quite close to the 0.1 version.

Location:
DOV
Files:
9 added
2 deleted
6 edited

Legend:

Unmodified
Added
Removed

  • TabularUnified DOV/appa.xml

    r19 r54  
    11<appendix>
    22        <title>A</title>
     3        <para>This will be the appendix A one day.</para>
    34</appendix>

  • TabularUnified DOV/book.xml

    r53 r54  
    11<?xml version='1.0'?>
    2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN" "http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd"
     2<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3b2/docbookx.dtd"
    33[
    44<!ENTITY foreword SYSTEM "foreword.xml">
    … …  
    99<!ENTITY ch04     SYSTEM "ch04.xml">
    1010<!ENTITY ch05     SYSTEM "ch05.xml">
     11<!ENTITY ch06     SYSTEM "ch06.xml">
     12<!ENTITY ch07     SYSTEM "ch07.xml">
     13<!ENTITY ch08     SYSTEM "ch08.xml">
     14<!ENTITY ch09     SYSTEM "ch09.xml">   
    1115<!ENTITY appa     SYSTEM "appa.xml">
     16<!ENTITY appb     SYSTEM "appb.xml">
     17<!ENTITY appc     SYSTEM "appc.xml">
     18<!ENTITY bibl     SYSTEM "bibl.xml">
    1219]>
    1320
    1421<book id="dov">
    1522        <title>The Design of Voyager</title>
     23        <subtitle>A Desktop for the 21th Century.</subtitle>
    1624       
    1725        <bookinfo>
    18                 <edition>First</edition>
     26                <edition>0.1, First</edition>
    1927                <copyright>
    2028                        <year>2006</year>
    … …  
    2230                </copyright>
    2331               
    24                 <authorgroup> <author>
    25                         <firstname>Adrian</firstname>
    26                         <surname>Gschwend</surname></author>
     32                <authorgroup>
     33                        <author>
     34                                <firstname>Adrian</firstname>
     35                                <surname>Gschwend</surname>
     36                        </author>
     37                        <author>
     38                                <firstname>Chris</firstname>
     39                                <surname>Wohlgemuth</surname>
     40                        </author>
     41                        <author>
     42                                <firstname>Peter</firstname>
     43                                <surname>Cocsis</surname>
     44                        </author>                       
    2745                </authorgroup>
    2846               
    … …  
    4563        &ch03;
    4664        &ch04;
     65        &ch05;
     66        &ch06;
     67        &ch07;
     68        &ch08;
     69        &ch09;
    4770        &appa;
    48        
    49         <bibliography xmlns="http://docbook.org/ns/docbook">
    50                
    51                 <title>References</title>
    52                
    53                 <bibliodiv>
    54                        
    55                         <title>Books</title>
    56                        
    57                         <biblioentry>
    58                                
    59                                 <abbrev>Kogan92</abbrev>
    60                                 <authorgroup>
    61                                        
    62                                         <author>
    63                                                 <personname>
    64                                                         <firstname>Mike</firstname>
    65                                                         <surname>Kogan</surname>
    66                                                 </personname>
    67                                         </author>
    68                                        
    69                                         <author>
    70                                                 <personname>
    71                                                         <firstname>Harvey M.</firstname>
    72                                                         <surname>Deitel</surname>
    73                                                 </personname>
    74                                         </author>
    75                                        
    76                                 </authorgroup>
    77                                
    78                                 <copyright>
    79                                         <year>1992</year>
    80                                 </copyright>
    81                                 <biblioid class="isbn">0201548895</biblioid>
    82                                 <publisher>
    83                                         <publishername>Addison-Wesley</publishername>
    84                                 </publisher>
    85                                 <title>The Design of OS/2</title>
    86                                
    87                         </biblioentry>
    88                        
    89                 </bibliodiv>
    90                
    91         </bibliography>
     71        &appb;
     72        &appc;
     73        &bibl;
    9274       
    9375</book>

  • TabularUnified DOV/ch00.xml

    r52 r54  
    11<?xml version='1.0'?>
    2 <!DOCTYPE preface PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN" "http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
     2<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3b2/docbookx.dtd">
    33<preface>
    4        
    5         <title>Preface</title>
    6         <simplesect>
    7                
    8                 <blockquote>
    9                         <para><quote>I just called IBM software support: OS/2, this is an IBM product right?</quote>
    10                                 &mdash;Achim calling IBM</para>
    11                 </blockquote>
    12         </simplesect>
    13        
    14         <section>
    15                 <title>Audience</title>
    16                 <para>Audience of the book</para>
    17         </section>
    18        
    19         <section>
    20                 <title>Acknowledgments</title>
    21                 <para>Blablabla</para>
    22         </section>
    23        
     4
     5  <title>Preface</title>
     6
     7  <simplesect>
     8
     9    <blockquote>
     10
     11      <attribution>Achim calling IBM&apos;s software
     12      support</attribution>
     13
     14      <para>OS/2, this is an IBM product right?</para>
     15
     16    </blockquote>
     17
     18  </simplesect>
     19
     20  <section>
     21
     22    <title>Audience</title>
     23
     24    <para>This book is thought for everyone who loves good software
     25    design - and it is for OS/2 and the users of it.</para>
     26
     27    <para>One can write a lot about IBM but the design of OS/2 was
     28    definitely good, unlike many other software out there. The team
     29    working on OS/2 implemented some concepts that are still unique in
     30    its way, for example the WPS (Workplace Shell). Designed in the
     31    early 90&apos;s it shows concepts of object orientation that do not
     32    exist like this in any other desktop until now. Projects like Gnome
     33    claimed to use the WPS as a reference but they still do not reach
     34    the same object orientation as the WPS did many years before. The
     35    WPS itself was built on top of PM, the Presentation Manager. While
     36    no one would use an API as complicated as PM for writing user
     37    interfaces anymore, it still provides components that can not be
     38    found in other systems, like GDI/GPI (Graphic Device
     39    Interface/Graphic Programming Interface). Its matrix based backend
     40    allows one to write complex software like CAD or DTP applications
     41    by design, one does not have to implement all the mathematical
     42    functions on its own.</para>
     43
     44    <para>So where is the link to good software design? It is mainly
     45    about thinking what one wants to reach before sitting down and
     46    writing it. Our group of programmers and users has years of
     47    experience with both open source and commercial software, in both
     48    using and implementing them and one of the main complaints is the
     49    lack of quality and documentation in both source code and usage of
     50    the program. Voyager tries to implement many things that can be
     51    found in OS/2 as open source software, parts of it rewritten from
     52    scratch. We use and program for the WPS and its object oriented
     53    concept for many years, we know the API, we know the power of it
     54    and we also know the pitfalls. So what we gonna do should be done
     55    right from the beginning - simply because we know what works and
     56    what does not work in this object oriented concept.</para>
     57
     58    <para>If you do not know OS/2 nor its concepts so far, do not
     59    worry. We will explain what the technology is about, why it is done
     60    that way and even more important, we will give you examples about
     61    how to use it. That is after all the main idea of this book.</para>
     62
     63  </section>
     64
     65  <section>
     66
     67    <title>Acknowledgments</title>
     68
     69    <para>So far credits go out to all the users and especially
     70    developers of OS/2, eComStation and everything related to it. We
     71    reached a lot the past 8 years with netlabs.org and all related
     72    projects and we are looking forward to a fascinating new chapter of
     73    object orientation on the desktop!</para>
     74
     75  </section>
     76
    2477</preface>
    2578

  • TabularUnified DOV/ch01.xml

    r52 r54  
    11<?xml version='1.0'?>
    2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN" "http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
     2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3b2/docbookx.dtd">
    33<chapter>
    44
    55  <title>Motivation</title>
    66
     7  <para>Every user of eComStation or OS/2 knows that: When people see
     8  our desktop, they usually ask what kind of Linux you are running. If
     9  you explain them that this has nothing to do with Linux and that the
     10  original system was done by IBM and they called it OS/2, we either
     11  end up with a big question mark on their face or with a statement like
     12  <quote>Oh, I used to work with that as well, it was good but I
     13  didn&apos;t had any software/drivers/whatever for it</quote>. People
     14  who worked with it a bit more explain that it was the best thing to
     15  administrate their fileservers, if they were even more skilled they
     16  start telling stories about how they did interact with the desktop
     17  and you can still see a glimpse (FIXME) in their eyes if they talk
     18  about it. The authors of this book are still using OS/2 or its
     19  official successor eComStation every day. We work on it, we write
     20  software for it, we extend it. But we are realistic. We know, that
     21  one day there will not be any more hardware to run it on, at least
     22  not in native mode. We know, that we have to invest already nowadays
     23  a lot of time, money and energy to get things like ACPI done, and to
     24  port de-facto standards like OpenOffice and the Mozilla suite to it.
     25  We also know, that we will never get the source code of the system by
     26  IBM, the thing we would need desperately to fix some very annoying
     27  bugs and limitations in it.</para>
     28
     29  <para>So we have to think about the options we have. Some of us did
     30  that the past years and some of us came up with more or less detailed
     31  ideas, about how this could be done. Some of the ideas were simply
     32  not realistic but we finally think, that we found a good concept by
     33  now. A concept that provides all the things we love about OS/2, PM
     34  and the WPS but also a concept that solves the limitations and
     35  restrictions of our current system, a concept that has a future. This
     36  is what this book is about.</para>
     37
    738  <section>
    839
    9     <title>The Story so far</title>
    10 
    11     <para>So far most attempts to <quote>save</quote> OS/2 were to come
    12     up with a group of people which started working on a kernel that
    13     has an OS/2 like API (<filename>DOS*</filename>, <filename>
    14     MOU*</filename>, <filename>VIO*</filename>, <filename>
    15     KBD*</filename>, ...). There are some fundamential missconcepts in
    16     this thinking:</para>
    17 
    18     <itemizedlist>
    19 
    20       <listitem>
    21 
    22         <para>No user works with the kernel itself. The kernel is just
    23         there to provide abstractions to the hardware. Users work with
    24         applications and OS/2 users work a lot with the desktop as well
    25         (The <firstterm>WPS</firstterm>).</para>
    26 
    27       </listitem>
    28 
    29       <listitem>
    30 
    31         <para>The OS/2 Kernel was ahead of its time in the early 90ies
    32         but meanwhile even Microsoft did their job and made the Windows
    33         kernel much more stable than it used to be. There are some
    34         things that are still great in the OS/2 kernel like a stable
    35         API, a working ABI and clearly separated parts which do not
    36         mess with each other. The OS/2 kernel is history nowadays, as
    37         porting to new hardware like 64bit processors is impossible to
    38         do.</para>
    39 
    40       </listitem>
    41 
    42       <listitem>
    43 
    44         <para>Even if the OS/2 API was stable and great one day noone
    45         will code like this anymore nowadays. PM programming will scare
    46         away every student that grew up with Java or another high-level
    47         language like C++ and (RAD) toolkits like wxWidgets, qt and
    48         GTK2. The OS/2 PM API is definitely dead and a big
    49         <emphasis>don&apos;t</emphasis> for the future. There are
    50         enough alternatives which can provide what OS/2 programmers
    51         were used to work with (GPI/GDI for example).</para>
    52 
    53       </listitem>
    54 
    55       <listitem>
    56 
    57         <para>The OS/2 community lost way too much time in porting
    58         drivers and software. Instead of focusing on real stuff like
    59         WPS integration most time spent on projects is stupid and
    60         boring porting work. This did not bring us further at all, just
    61         a few things were done the OS/2 way (like CDRecord).</para>
    62 
    63       </listitem>
    64 
    65     </itemizedlist>
     40    <title>Facts and Religion</title>
     41
     42    <para>In FIXME we explain the history of the Voyager project,
     43    including some details about what IBM planned to do with OS/2 years
     44    ago. As we all know, it came different, OS/2 never got the success
     45    it deserved from a technical point of view, the world is still
     46    dominated by Microsoft and Windows.</para>
     47
     48    <para>After the first presentation of Voyager to the public at
     49    Warpstock Europe 2006 we got a lot of feedback about the idea, both
     50    positive and negative. There were people that got the idea of
     51    Voyager right from the beginning, they understood that we do not
     52    want to take away OS/2 from anyone, nor give up development of new
     53    features for eComStation or anything. But still, the negative
     54    feedback was there, some people absolutely didn&apos;t want to
     55    understand why Voyager is necessary and why people should invest
     56    time into it. So before we go into the glory details let me explain
     57    why we think Voyager is necessary from our point of view. To
     58    explain that we go more that 10 years back, and we get a bit more
     59    personal than in the other chapters.</para>
     60
     61    <section>
     62
     63      <title>The Reason for OS/2</title>
     64
     65      <para>The author of those lines was using Windows 3.1 until
     66      sometime in 1994. After a lot of system breakdowns on a rainy
     67      Saturday evening I decided that it can not go on like this
     68      anymore. I went to my neighbour who was working at IBM and I told
     69      him <quote>get me this operating system from IBM</quote>. I
     70      didn&apos;t know the name and I didn&apos;t know what it was
     71      about, I just heard that it was more stable than Windows and that
     72      was tempting enough for me. A few weeks later I got a brand new
     73      box of OS/2 Warp 3, went home and installed it. I started the
     74      destkop and shut down the system shortly afterwards, I had no
     75      idea what I am supposed to do with that system now.</para>
     76
     77      <para>It took me a few weeks to get used to it, I got software
     78      for the new system from German magazines with a lot of shareware
     79      and freeware on it, OS/2 was pretty popular in Germany back then
     80      so there was a market for that. I never used the Windows support
     81      in it a lot, the only application I wanted to run did not work
     82      because it was a MIDI sequencer which required support for sound
     83      cards that were not supported on OS/2. But I still liked it, it
     84      was stable, it was innovative, it was different. And I learned
     85      that from a technical point of view it was far superior than any
     86      Windows, including the upcoming Windows 95.</para>
     87
     88      <para>The follwoing years I had my advocacy period where I tried
     89      to explain everyone why I am using OS/2, why
     90      <emphasis>they</emphasis> should use OS/2 and why Windows sucks
     91      and Microsoft is evil. I didn&apos;t had much success, for most
     92      friends it was more important to be able to play the latest games
     93      and get drivers for about every hardware they could buy for
     94      money. They lived with the fact that the system was not stable or
     95      that they had to reinstall it every few months from scratch.
     96      Recently one of those friends told me that they were very jealous
     97      back then when I took my OS/2 machine to a demoscene event
     98      because I was the only one in there who could play Quake and burn
     99      a CD at the same time without the system crashing. So at least
     100      for a little moment I had my fame with OS/2.</para>
     101
     102      <para>My advocacy time is over for a long time, meanwhile I
     103      started a project called netlabs.org and I&apos;ve met a lot of
     104      great people all over the world with the same spirit: The idea
     105      that there is more out there than Windows, MacOS, Linux or any of
     106      the other operating systems. The knowledge that IBM
     107      <emphasis>did</emphasis> do some things right, even if it was not
     108      marketing nor the technical implementation of some of the
     109      concepts they designed. I still use OS/2 every day, even if I
     110      work with many Unix-like operating systems out there every day to
     111      earn my living.</para>
     112
     113      <tip>
     114
     115        <title>netlabs.org</title>
     116
     117        <para>Describe netlabs.org here.</para>
     118
     119      </tip>
     120
     121      <para>You might ask why I write that in a book about Voyager. The
     122      reason is pretty simple: Every OS/2 user had a story of his own
     123      about how he or she started using it. I bet that for most people
     124      it had something to do with technical reasons, because you
     125      <emphasis>knew</emphasis> that it was better. So what was your
     126      motivation back then? Think about that again before you read the
     127      next sections.</para>
     128
     129    </section>
     130
     131    <section>
     132
     133      <title>The Reason for eComStation</title>
     134
     135      <para>While IBM was investing less and less time into the
     136      development of OS/2, a group of people at Serenity Systems
     137      International (SSI) managed to get a license from IBM to
     138      distribute the core of OS/2 under a new name and extend it with
     139      new software. The final product is now called eComStation and it
     140      is by now the only legal way to get an OS/2 like operating
     141      system, especially since IBM stopped selling OS/2 in January
     142      2006.</para>
     143
     144      <para>When eComStation 1.0 got released in FIXME IBM was still
     145      selling OS/2 but many OS/2 users switched to eComStation. The
     146      reason was pretty simple: eCS included a lot of things in the
     147      default installation users of OS/2 installed anyway - and much
     148      more. It was no longer necessary to patch a freshly installed
     149      system right away with the latest fixpacks and install software
     150      like <application>WarpIN</application>, <application>
     151      XWorkplace</application>, <application>Mozilla</application> and
     152      all the other applications.</para>
     153
     154      <para>Meanwhile OS/2 does not exist anymore, eCS is the only way
     155      to get the <quote>OS/2 feeling</quote> on your desktop and you
     156      get much more with it. SSI is currently working on eComStation
     157      2.0, which will add more important features and which also shows
     158      a clear trend: Use industry standards which are available as open
     159      source software and integrate them into the WPS. Examples of this
     160      are <application>OpenOffice.org 2.0</application>, <application>
     161      Samba</application>, <application>CDRecord</application> and much
     162      more.</para>
     163
     164    </section>
     165
     166    <section>
     167
     168      <title>The Reason for Voyager</title>
     169
     170      <para>As described above, eComStatio made it for the first time
     171      possible to add things to our operating system IBM refused to
     172      include all the years before. This is a great thing because it is
     173      now possible to extend and adjust the system to our needs.</para>
     174
     175      <para>However, it became also clear the past months that the
     176      current kernel of eComStation will reach its design limits one
     177      day. While we still can get it to work on recent hardware due to
     178      extensions like ACPI support, things might change in the future.
     179      The trend nowadays is clearly 64 bit platforms and even if it
     180      will take some months or even years until they are used
     181      everywhere, we cannot use new features of such CPUs and
     182      mainboards with the current kernel.</para>
     183
     184      <para>Another issue is the time needed to develop new features
     185      like ACPI. After years of running a project like netlabs.org we
     186      are simply tired of writing device drivers for new hardware and
     187      trying to circumvent limitations in the current kernel to get
     188      something to work. This is very boring work and it does not lead
     189      anywhere, because new hardware is released every day. So instead
     190      of focusing on interesting work like integrating applications
     191      into the Workplace Shell, we lose time on moving targets.</para>
     192
     193      <tip>
     194
     195        <title>Workplace Shell (WPS)</title>
     196
     197        <para>Describe the WPS here.</para>
     198
     199      </tip>
     200
     201      <para>The same issue comes up for GUI based applications like
     202      <application>Mozilla</application> and <application>
     203      OpenOffice.org</application>. They always rely on a GUI Toolkit,
     204      popular toolkits nowadays are GTK+, qt, wxWidgets and SWT. We
     205      spent and still spend quite some time on getting those toolkits
     206      to work on OS/2 PM, this is also a never ending work because they
     207      get extended on a regular base as well. Again, we loose time on
     208      things that do not bring a direct benefit, they are just required
     209      to get the application itself to OS/2. This costs a lot of time
     210      and also a lot of money, because we have to pay developers to
     211      port those toolkits, otherwise they get never finished in a
     212      reasonable time.</para>
     213
     214      <para>Earlier in the book we asked you about your motivation to
     215      use OS/2 back then. We hope you could remember the motivation and
     216      we also hope that it has something to do with the technical
     217      benefits of OS/2. If you are sceptic against the idea of Voyager
     218      answer yourself the following questions:</para>
     219
     220      <itemizedlist>
     221
     222        <listitem>
     223
     224          <para>Are the arguments for OS/2 still valid nowadays in a
     225          technical point of view?</para>
     226
     227        </listitem>
     228
     229        <listitem>
     230
     231          <para>Would you still choose OS/2 if you wouldn&apos;t care
     232          about unique concepts like the WPS?</para>
     233
     234        </listitem>
     235
     236      </itemizedlist>
     237
     238      <para>For sure there is more in OS/2 and eCS than just the WPS,
     239      we will talk about that later. But in our opinion those concepts
     240      are not necessarily bound to OS/2 as a kernel and operating
     241      system. And that is exactly what Voyager is about:
     242      <emphasis>Implement the unique concepts as open source software
     243      for eCS and for other platforms!</emphasis></para>
     244
     245    </section>
    66246
    67247  </section>
    … …  
    72252
    73253    <para>There are many things in OS/2 that are worth keeping but it
    74     wouldn&apos;t make sense to clone the current OS as a whole. The
     254    would not make sense to clone the current OS as a whole. The
    75255    community could never do that and even if we could, it
    76256    wouldn&apos;t solve the problems we suffer from nowadays.</para>
     257
     258    <para>Based on the arguments mentioned before we can come up with a
     259    list of things that would be nice to have in a perfect
     260    environment:</para>
     261
     262    <itemizedlist>
     263
     264      <listitem>
     265
     266        <para>The system provides a stable kernel with a decent device
     267        driver subsystem.</para>
     268
     269      </listitem>
     270
     271      <listitem>
     272
     273        <para>All recent GUI toolkits are provided by the system,
     274        without porting or maintenance work for us.</para>
     275
     276      </listitem>
     277
     278      <listitem>
     279
     280        <para>Hardware is just there to do a job for us. We do not care
     281        about device drivers, they are provided by the base
     282        system.</para>
     283
     284      </listitem>
     285
     286      <listitem>
     287
     288        <para>De-facto standards can easily be compiled. Patching of
     289        application source code is not required.</para>
     290
     291      </listitem>
     292
     293      <listitem>
     294
     295        <para>Our programmers implement a WPS like environment on top
     296        of this system.</para>
     297
     298      </listitem>
     299
     300      <listitem>
     301
     302        <para>Applications are perfectly integrated into this WPS like
     303        desktop.</para>
     304
     305      </listitem>
     306
     307      <listitem>
     308
     309        <para>And in a really perfect world we even get our legacy OS/2
     310        and eCS applications to work.</para>
     311
     312      </listitem>
     313
     314    </itemizedlist>
    77315
    78316    <para>A project like Voyager needs to focus on its main idea,
    … …  
    82320    written by ourself and which components can be taken from other
    83321    projects. We believe that this approach makes it possible to make
    84     Voyager a real peace of software instead of vapoware or a nice
     322    Voyager a real piece of software instead of vapoware or a nice
    85323    design study, as it is at the time writing.</para>
    86324
     325    <para>It would not make sense to give any statement about how fast
     326    this can be implemented and about how many of the mentioned things
     327    will be reached within the next months and years. But if we do not
     328    try, we will never find out.</para>
     329
    87330  </section>
    88331

  • TabularUnified DOV/ch02.xml

    r52 r54  
    11<?xml version='1.0'?>
    2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN" "http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
     2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3b2/docbookx.dtd">
    33<chapter>
    44
    5   <title>An Overview of Voyager</title>
    6 
    7   <para>Basically a translation of the freeX Article.</para>
     5  <title>A Short Overview of Voyager</title>
     6
     7  <para>This chapter will give you a short overview about Voyager. We
     8  will not go into many technical details because those are covered in
     9  the corresponding chapters.</para>
    810
    911  <section>
    … …  
    1113    <title>The Voyager Project</title>
    1214
    13     <para>Main overview</para>
     15    <para>Before we talk about the different parts of Voyager we want
     16    to explain how Voyager started of. Voyager is the result of a lot
     17    of ideas we had the past years so we would like to explain how we
     18    got there.</para>
    1419
    1520    <section>
    1621
     22      <title>History</title>
     23
     24      <para>Shortly after OS/2 Warp 3 IBM started working on a new
     25      project, with the goal to move the kernel to a microkernel
     26      architecture and thus make it more portable. They started to
     27      implement an OS/2 personality on top of a Mach 3 Kernel and they
     28      called the project <emphasis>OS/2 Warp (PowerPC
     29      Edition)</emphasis>. For various reasons the project got
     30      canceled later but before that happened IBM released the book
     31      <citetitle>OS/2 Warp (PowerPC Edition) A First Look</citetitle>
     32      <citation>SG24-4630</citation>, which documented the basic design
     33      of it.</para>
     34
     35      <para>In 1996 IBM released the last real release of OS/2 with
     36      significant changes in it, named OS/2 Warp 4. They back-ported
     37      some of the things designed for the PowerPC version like GRADD
     38      <citation>SG24-4639</citation> to the <quote>old</quote> OS/2
     39      kernel, but the microkernel project itself was dead. After Warp 4
     40      IBM just released some updated releases for servers, the end-user
     41      market was at this time already dead inside IBM. The only part
     42      that still got extended was the OS/2 Kernel, development on that
     43      stopped end of 2005.</para>
     44
     45      <tip>
     46
     47        <para>A more detailed history of OS/2 is available in the
     48        Internet. Michal Necasek did a very detailed overview about the
     49        different releases. It also gives some details about what IBM
     50        did wrong. <ulink url="http://FIXME"/></para>
     51
     52      </tip>
     53
     54      <para>For several years people in the OS/2 community were
     55      thinking about options we have in mid-term to work with our
     56      beloved operating system. Most of the ideas were focusing on
     57      rewriting large parts of OS/2, with the goal to have an open
     58      source clone of OS/2. Projects like OSFree started, but they did
     59      not reach much attention so far and there is not much outcome by
     60      the time writing.</para>
     61
     62      <para>Bigger projects like netlabs.org never actively joined or
     63      supported those projects for various reasons. Most programmers at
     64      netlabs.org think that there is not enough manpower to finish a
     65      project like OSFree. Beside this most programmers are already
     66      fully occupied with other projects and we did not see many new
     67      people joining the community. It is also a fact that the design
     68      of OS/2 in general (with some notable exceptions) is no longer
     69      state of the art. IBM addressed that back then with the
     70      microkernel concept but as mentioned before it was neither
     71      released nor finished.</para>
     72
     73      <para>With or without IBM, there was always a hard core of
     74      programmers and users using and enhancing OS/2. With Warpstock
     75      USA 1996 OS/2 users started to meet each other once a year, one
     76      year later the European community started to do that as well,
     77      followed by East-European users a few years later. At around the
     78      same time netlabs.org got founded by Adrian Gschwend. The goal
     79      was as simple as this: Create open source software for OS/2,
     80      which was not that common yet back then. Meanwhile there is an
     81      active core of developers and users gathered around netlabs.org
     82      and its projects.</para>
     83
     84      <para>When Apple released MacOS X in the late 90&apos;s, parts of
     85      it were released as open source software, especially the kernel
     86      and its tools. Beside the source code Apple also released a lot
     87      of documentation about it, which made it easier for developers to
     88      extend the OS. The MacOS X Kernel, called Darwin, is based on a
     89      Mach 3 microkernel with a FreeBSD and MacOS X personality on top
     90      of it. For that reason some people at netlabs.org started to get
     91      interest in that project, because of the obvious relations to the
     92      microkernel project of IBM.</para>
     93
     94      <para>At Developers Workshop 2005 in Dresden Adrian Gschwend of
     95      netlabs.org presented the first thoughts about the perspective of
     96      the OS/2 community. The presentation showed that in mid-term the
     97      community has to move on because we will not be able to support
     98      OS/2 forever on recent hardware. Also, we cannot expect any more
     99      enhancements from IBM. It was also shown that there are things
     100      and concepts worth keeping in OS/2 which should be kept for the
     101      future. Inspired by Darwin, the main statement from a technical
     102      point of view was to create an OS/2 personality on top of Darwin
     103      and implement PM and WPS on top of it.</para>
     104
     105      <para>The presentation showed some interesting thoughts but it
     106      missed the main point: It would not solve any of the issues we
     107      have nowadays with PM or WPS because both of them are not
     108      available in source code. During summer 2005 Bart Van Leeuwen and
     109      Adrian Gschwend pushed the idea further which lead to a radical
     110      change of the focus: One has to think about the desktop first and
     111      then address the system underneath of it.</para>
     112
     113      <para>In November 2005 the new conclusion was presented at
     114      Warpstock Europe 2005. For the first time there were also
     115      presentations of replacement parts for things like PM and core
     116      components of the WPS like SOM. The focus was pretty clear: Use
     117      as many existing technologies as possible and implement something
     118      like a WPS on top of it and make sure we just write the minimum
     119      needed to get there. There were also ideas presented about how a
     120      backward compatibility to OS/2 applications could be done. An
     121      important statement was also that the kernel does not really play
     122      an important role at the moment and that netlabs.org will most
     123      probably not focus on that until there is more work done on the
     124      desktop part.</para>
     125
     126      <tip>
     127
     128        <title>eComStation</title>
     129
     130        <para>Describe eCS &amp; SSI here.</para>
     131
     132      </tip>
     133
     134      <para>A year after the first presentation of Voyager the next
     135      Developers Workshop 2006 took place in April 2006 in Biel,
     136      Switzerland. People like Chris Wohlgemuth, Peter Cocsis and
     137      Harald Studer presented first concepts and prototypes of core
     138      components of Voyager, including an object model, a multimedia
     139      subsystem and an OpenGL based window manager. Adrian Gschwend and
     140      Bart Van Leeuwen talked about the next steps the project has to
     141      take and they also clearly showed that eComStation is the current
     142      way to go for the mid-term future. There were also students from
     143      the Berne University of Applied Sciences joining the
     144      presentations which did not know OS/2 and its concepts at all. It
     145      was great to see that those concepts are indeed unique and that
     146      most students liked the idea of Voyager a lot and talked about
     147      joining the project as soon as there are prototypes available.
     148      This is an important step for community itself!</para>
     149
     150      <para>The release of this book is hopefully the next milestone
     151      for Voyager, as you can see it is far away from being complete
     152      but we still think it is an important next step and we look
     153      forward to contributions from all over the world.</para>
     154
     155    </section>
     156
     157    <section>
     158
    17159      <title>About the Codename</title>
    18160
    19161      <para><quote>The Voyager Project</quote> so far is just a
    20       codename.</para>
     162      codename for what we discuss in this book. It is a reference to
     163      the <trademark>Star Trek</trademark> related history of codenames
     164      used by IBM in OS/2 development. The codenames were already used
     165      for a long time at IBM but the marketing department decided to
     166      use the codename <emphasis>Warp</emphasis> as a name for the
     167      public as well with OS/2 Version 3.0 so it became <trademark>OS/2
     168      Warp 3</trademark>.</para>
     169
     170      <para>Voyager is also the name of a NASA FIXME.</para>
     171
     172      <para>Many programmers contributing to the project decided to
     173      pick up related names as well, like Neptune (First moon FIXME)
     174      and Triton (FIXME).</para>
     175
     176      <para>Most probably the name Voyager will not be used for the
     177      project itself as soon as we got something ready for use.</para>
    21178
    22179    </section>
    … …  
    26183  <section>
    27184
    28     <title>Voyager Object Model</title>
    29 
    30     <para>blabla</para>
     185    <title>The Story So Far</title>
     186
     187    <para>So far most attempts to <quote>save</quote> OS/2 were to come
     188    up with a group of people which started working on a kernel that
     189    has an OS/2 like API (<filename>DOS*</filename>, <filename>
     190    MOU*</filename>, <filename>VIO*</filename>, <filename>
     191    KBD*</filename>, ...). There are some essential miss-concepts in
     192    this thinking:</para>
     193
     194    <itemizedlist>
     195
     196      <listitem>
     197
     198        <para>No user works with the kernel itself. The kernel is just
     199        there to provide abstractions to the hardware. Users work with
     200        applications and OS/2 users work a lot with the desktop as well
     201        (The <firstterm>WPS</firstterm>).</para>
     202
     203      </listitem>
     204
     205      <listitem>
     206
     207        <para>The OS/2 Kernel was ahead of its time in the early 90ies
     208        but meanwhile even Microsoft did their job and made the Windows
     209        kernel much more stable than it used to be. There are some
     210        things that are still great in the OS/2 kernel like a stable
     211        API, a working ABI and clearly separated parts which do not
     212        mess with each other. The OS/2 kernel is history nowadays, as
     213        porting to new hardware like 64bit processors is impossible to
     214        do.</para>
     215
     216      </listitem>
     217
     218      <listitem>
     219
     220        <para>Even if the OS/2 API was stable and great one day no one
     221        will code like this anymore nowadays. PM programming will scare
     222        away every student that grew up with Java or another high-level
     223        language like C++ and (RAD) toolkits like wxWidgets, qt and
     224        GTK2. The OS/2 PM API is definitely dead and a big
     225        <emphasis>don&apos;t</emphasis> for the future. There are
     226        enough alternatives which can provide what OS/2 programmers
     227        were used to work with (GPI/GDI for example).</para>
     228
     229      </listitem>
     230
     231      <listitem>
     232
     233        <para>The OS/2 community lost way too much time in porting
     234        drivers and software. Instead of focusing on real stuff like
     235        WPS integration most time spent on projects is stupid and
     236        boring porting work. This did not bring us further at all, just
     237        a few things were done the OS/2 way.</para>
     238
     239      </listitem>
     240
     241    </itemizedlist>
     242
     243    <para>Voyager tries to address those issues. In its first
     244    incarnation, Voyager is not a complete replacement for OS/2 but it
     245    starts to replace some important parts like the object model and
     246    the multimedia subsystem. The further the project gets, the more
     247    components can be replaced. The goal is to reach the point where we
     248    have our own desktop which can run on any kernel that provides the
     249    necessary APIs.</para>
    31250
    32251  </section>
    … …  
    34253  <section>
    35254
    36     <title>Neptune</title>
    37 
    38     <para>blabla</para>
     255    <title>Voyager Components</title>
     256
     257    <para>So what are those components we talk about? While we can
     258    define some parts pretty detailed it is not that easy yet for other
     259    parts, simply because we need to do some more work first. We talked
     260    about things like the WPS, that is what about most OS/2 users would
     261    define as the <quote>OS/2 feeling</quote>. And it is actually also
     262    what we, the current developers of Voyager, appreciate most about
     263    OS/2. So it was obvious that we will start with an object model
     264    first - this is the base needed to implement a WPS like desktop.
     265    Another developer has a lot of know how in the multimedia field, so
     266    he started to work on a multimedia subsystem replacement. We will
     267    show more than those two parts but you will see that there is not
     268    much work done on that right now. The reason is simple: We do not
     269    have any developers yet for those parts. We hope that this will
     270    change soon, also because we release this book to the public.
     271    Contributions are very welcome, please see <xref /> to get an
     272    overview about how you can join the projects!</para>
     273
     274    <section>
     275
     276      <title>Voyager Object Model</title>
     277
     278      <para>The WPS is a fully object oriented desktop, instead of
     279      <emphasis>everything is a file</emphasis> the credo is
     280      <emphasis>everything is an object</emphasis>. This opens a whole
     281      new way of interacting with the desktop for the user, but also
     282      for the developer. We will not go into the details about the
     283      object model itself in this introduction, a more detailed example
     284      is covered in <xref linkend="dov.vom"/>. If you don&apos;t know
     285      the WPS at all you might want to download the eComStation Demo
     286      CD, which is available for free at
     287      <ulink url="http://www.ecomstation.com"/>.</para>
     288
     289      <para>The object model of the WPS is called <firstterm>System
     290      Object Model</firstterm> (SOM) and it introduced a new concept
     291      that is just known in a few languages like Java:
     292      Release-to-Release Binary Compatibility
     293      <citation>Forman94</citation>. A developer can release binary
     294      releases of objects and they will work between different releases
     295      of the desktop, even if the subclassed object changes its
     296      interface. Other systems like Gnome do not provide this, even a
     297      minor release between 2.10 and 2.12 might break a plugin when the
     298      interface changes. The developer would have to adjust his source
     299      code to get it to work again.</para>
     300
     301      <para>Neither SOM nor the Voyager Object Model restrict
     302      developers to a specific programming language, one can use any
     303      language as long as there are bindings to the object model
     304      available. The development of the Voyager Object Model is done in
     305      an object oriented fashion of C.</para>
     306
     307      <para>The development of the new Voyager Object Model is done on
     308      OS/2 so far. However, the code is very portable and should
     309      compile on other platforms as well.</para>
     310
     311    </section>
     312
     313    <section>
     314
     315      <title>GUI Toolkit and Graphical Subsystem</title>
     316
     317      <para>IBM provided two important things to the developer for
     318      creating GUI based applications on OS/2: The
     319      <firstterm>Presentation Manager</firstterm> (PM) and
     320      <firstterm>GPI/GDI</firstterm> (Graphic Programming
     321      Interface/Graphic Device Interface). The PM is responsible for
     322      drawing common controls, window handling, input handling and
     323      more, while GPI/GDI provides a powerful matrix based subsystem
     324      which can be used to draw about everything one might need.
     325      Applications like Maul Publisher on OS/2 show how powerful the
     326      subsystem actually is.</para>
     327
     328      <para>While being powerful, neither PM nor GPI/GDI or the
     329      underlying GRADD architecture are available as open source. This
     330      means they cannot be extended and we cannot fix known bugs in it.
     331      So it was important to look for alternatives and it was clear
     332      from the beginning that we will not rewrite something as complex
     333      as GPI by ourself.</para>
     334
     335      <para>To find a replacement for PM was not that difficult: Almost
     336      all big applications or toolkits on Unix-like systems like
     337      OpenOffice.org, Mozilla, SWT and wxWidgets are based on GTK+. The
     338      second option would be the qt-toolkit which is also quite popular
     339      among developers. The problem of the qt-toolkit is its license:
     340      It is dual-licensed as GPL or a commercial license. GPL actually
     341      forces the developer to release everything under the GPL license
     342      as well, which is absolutely not the intention of Voyager. GTK+
     343      however is licensed under the LGPL license, which does not have
     344      that strict restriction, it does not force the developer to
     345      release the source code of his application. That is for example
     346      also the reason why commercial products like Acrobat Reader on
     347      Linux are using GTK+. GTK+ is also a very modern and powerful
     348      toolkit which is well maintained. The only drawback is its quite
     349      rudimentary documentation but this is unfortunately a general
     350      problem of many open source software and toolkits
     351      available.</para>
     352
     353      <para>To find a replacement for GPI was tricky. For quite some
     354      time we did not know what to choose as a replacement for that.
     355      But during 2005 there was a newcomer in this area getting a lot
     356      of attention: Cairo Graphics Library (
     357      <ulink url="http://www.cairographics.org"/>). Cairo basically
     358      provides everything one might ask for as GPI programmer, like
     359      FIXME. And developers start using it, the Mozilla foundation
     360      announced that the Geko rendering engine will move its rendering
     361      to Cairo, OpenOffice.org also wants to use it for its rendering
     362      and the GTK+ team moves a lot of drawing functions to Cairo as
     363      well. So it looks like the perfect choice as a GPI replacement
     364      and the first feedback from OS/2 developers that know GPI well
     365      seems to prove that.</para>
     366
     367      <para>While Cairo is already ported to OS/2 we still work on
     368      getting GTK+ to work as well. We hope to reach that point soon
     369      with the support of Everblue (Xlib-Layer for OS/2:
     370      <ulink url="http://everblue.netlabs.org"/>).</para>
     371
     372    </section>
     373
     374    <section>
     375
     376      <title>Triton</title>
     377
     378      <para>OS/2 introduced a modern multimedia subsystem in 1994. It
     379      provided the abstraction of codecs and transports, which made it
     380      possible that even a media player from 1994 can play new codecs
     381      like FLAC and Ogg Vorbis, simply because the system knows the
     382      codec for it. Also, it does nto matter if the stream is coming
     383      from a local harddisk or if it is provided by an Internet radio
     384      station using the http protocol. Any application using this
     385      interface can handle any protocol and codec supported by the
     386      system, without the need to implement that for each one of them
     387      separately.</para>
     388
     389      <para>It was clear that we would like to provide something like
     390      this for Voyager as well. By chance one of our developers, Peter
     391      Cocsis, is skilled in this area and decided to implement a
     392      similar concept from scratch. This is also necessary nowadays,
     393      back when MMPM in OS/2 got designed no one talked about things
     394      like HDTV, Satellite TV and DivX yet so it does have its
     395      limitations for todays requirements.</para>
     396
     397      <para>We think it is important that developers get a modern
     398      multimedia subsystem right from the beginning, like this we can
     399      integrate the applications according to it and integrate them
     400      even better into the desktop. More information about Triton can
     401      be found in <xref linkend="dov.triton"/>.</para>
     402
     403    </section>
     404
     405    <section>
     406
     407      <title>Neptune</title>
     408
     409      <para>On Unix-like systems the desktop is usually running inside
     410      an X-session, the most known implementation of that is called
     411      Xorg. Xorg implements Xlib and provides an interface for graphics
     412      device drivers. This interface can be binary only and the two big
     413      players nowadays, Nvidia and ATI, both provide just binary only
     414      drivers.</para>
     415
     416      <para>Desktops like KDE, Gnome and Xfce are no longer implemented
     417      on Xlib itself, instead they use high-level toolkits like GTK+ or
     418      qt. For historical reasons it seems to be impossible right now to
     419      get rid of Xlib itself, which does not make sense anymore because
     420      no (properly written) application nowadays is using Xlib for
     421      drawing. This is all done by the toolkit itself, on GTK+ for
     422      example this is now done using Cairo Library. qt is using his own
     423      rendering engine called Arthur.</para>
     424
     425      <para>Unfortunately there were no successful attempts so far to
     426      get rid of Xlib completely, most of the time people argue that
     427      one can still use the desktop remote like this. This is just true
     428      for applications that are not using any direct rendering and
     429      beside this, most users never use that feature anyway. But the
     430      current trend on Unix-like systems finally goes into the direction
     431      of using OpenGL accelerated backends and doing the whole
     432      rendering in it. This is exactly where Neptune comes in.</para>
     433
     434      <para>Neptune will provide a window manager for both Xlib and
     435      Cario, where Cairo is using the Glitz backend for OpenGL
     436      accelerated rendering. Unlike PM on OS/2 Xlib is not providing
     437      any methods for window management so we need a 3rd party
     438      application doing that and this is the job of so called window
     439      managers.</para>
     440
     441      <para>There are still many open questions for Neptune. We do not
     442      have many developers working on that yet so this part will not be
     443      finished anytime soon, contributions are again very welcome. More
     444      information about the design of Neptune can be found in the
     445      presentation of Harald Studer at Developers Workshop 2006 (
     446      <ulink url="ftp://ftp.netlabs.org/pub/events/dws06/presentations/AWMBasedOnCairo.pdf"/>
     447       ). The Neptune chapter in this book needs to be started
     448      first.</para>
     449
     450      <para>Note that Neptune is not critical for Voyager, even if it
     451      would be <emphasis>nice to have</emphasis>, Voyager can and will
     452      run on a normal Xlib based Xorg with any window manager.</para>
     453
     454    </section>
     455
     456    <section>
     457
     458      <title>Kernel</title>
     459
     460      <para>Many OS/2 users adore the OS/2 kernel for various reasons.
     461      It is pretty stable, it provides a stable ABI for device drivers,
     462      the multitasking is still excellent and it is fast. Most probably
     463      it will be possible to work with this kernel for another few
     464      years on recent hardware, but it will not go on like this
     465      forever. Hardware and technology is changing and so do kernels.
     466      The OS/2 kernel did not get any major enhancements since around
     467      1997 so it is time to think about an alternative.</para>
     468
     469      <para>It is absolutely clear that whatever option might come up,
     470      we will <emphasis>not</emphasis> write device drivers on our own
     471      again. This was and is one of the major problems we had and no one
     472      of the core developers of Voyager wants to spend time on that
     473      anymore.</para>
     474
     475      <para>As you can see in <xref id="dov.kernel"/>, there are plenty
     476      of options available nowadays and it would be a waste of time to
     477      write yet another one by ourself. Voyager will compile on as many
     478      kernels and possible, the team will abstract everything in a way
     479      that the kernel is just one of the decisions we take.</para>
     480
     481      <para>We would like to get to a point where we can release
     482      Voyager as a complete OS/2 replacement one day. This means we
     483      <emphasis>have</emphasis> to choose a kernel at that time but
     484      before this happens we need to do a lot of research about the
     485      best options. So far the development of Voyager is done on OS/2
     486      only so we do not need to hurry.</para>
     487
     488    </section>
    39489
    40490  </section>
    … …  
    42492  <section>
    43493
    44     <title>Kernel</title>
    45 
    46     <para>blabla</para>
     494    <title>Source Code License</title>
     495
     496    <para>Voyager is open source software. This means everything which
     497    belongs to the core of Voyager is available in source code and thus
     498    everyone can have a look at the implementation and even better,
     499    improve and extend it.</para>
     500
     501    <para>There are plenty of open source licenses available and the
     502    Voyager core team discussed for quite some time which one we should
     503    choose for Voyager. Our requirements were:</para>
     504
     505    <itemizedlist>
     506
     507      <listitem>
     508
     509        <para>The source code of the core of Voyager must be available
     510        to the public.</para>
     511
     512      </listitem>
     513
     514      <listitem>
     515
     516        <para>It must be possible for anyone to enhance and extend the
     517        source code of the Voyager core.</para>
     518
     519      </listitem>
     520
     521      <listitem>
     522
     523        <para>It must be possible to create a commercial product out of
     524        Voyager that can be sold.</para>
     525
     526      </listitem>
     527
     528      <listitem>
     529
     530        <para>Because of the binary compatible object model, it must be
     531        possible to provide binary only extensions to classes and
     532        objects, both open source and closed source, commercial or
     533        non-commercial.</para>
     534
     535      </listitem>
     536
     537      <listitem>
     538
     539        <para>We want to provide templates and code samples that can be
     540        used by developers as a base, for open source and for closed
     541        source applications.</para>
     542
     543      </listitem>
     544
     545    </itemizedlist>
     546
     547    <para>This already made one thing pretty clear: The license cannot
     548    be the GNU General Public License (GPL). The GPL prohibits the use
     549    of binary only components, as we can see very well in the endless
     550    discussions in the Linux kernel mailing-list. And what is a binary
     551    object model for when we cannot use its advantage because of the
     552    license? So we had to discuss different licenses and after some
     553    discussions we came up with the following license model:</para>
     554
     555    <itemizedlist>
     556
     557      <listitem>
     558
     559        <para>The core of Voyager is dual-licensed under the CDDL and
     560        the LGPL. </para>
     561
     562      </listitem>
     563
     564      <listitem>
     565
     566        <para>All sample applications and code templates are licensed
     567        under the Apache License.</para>
     568
     569      </listitem>
     570
     571    </itemizedlist>
     572
     573    <para>We decided to use a dual-licensing of the core to avoid
     574    endless discussions with those programmers who think the GPL solves
     575    every problem, it will most probably not make everyone happy but
     576    the LGPL is the only logical way for our requirements in that case.
     577    The CDDL gives more freedom to us because we as developers can also
     578    sell our product like this, but if someone changes source code of
     579    us they would have to at least release the changes in our classes.
     580    </para>
     581
     582    <para>The Apache License for sample applications and code templates
     583    also makes sense. It should be easy for new programmers and
     584    companies to code for Voyager. There are almost no restrictions in
     585    the Apache license so we do not force any code release at all like
     586    this.</para>
     587
     588    <para>For sure we hope that many programmers release their classes,
     589    objects and applications as open source software. In best case
     590    under the same license as we do. But we also think that a project
     591    like Voyager can just get its full potential when we open up the
     592    market for commercial companies and programmers as well - and most
     593    open source desktops nowadays do not provide that freedom.</para>
     594
     595    <para />
     596
     597    <para />
    47598
    48599  </section>
    49600
    50   <section>
    51 
    52     <title>License</title>
    53 
    54     <para>blabla</para>
    55 
    56     <para />
    57 
    58   </section>
    59 
    60601  <para />
    61602

  • TabularUnified DOV/ch03.xml

    r52 r54  
    11<?xml version='1.0'?>
    2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN" "http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
    3 <chapter>
     2<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3b2/docbookx.dtd">
     3<chapter id="dov.vom">
    44
    55  <title>Voyager Object Model</title>
    66
    7   <para>Copy the stuff from Cinc</para>
     7  <section id="dov.vom.g">
     8
     9    <title>General</title>
     10
     11    <section id="dov.vom.g.i">
     12
     13      <title>Introduction</title>
     14
     15      <para>The desktop follows a document centered approach in
     16      contrast to other task driven implementations. This means the
     17      user is working with documents to be found on the system rather
     18      then starting some kind of application and working inside of
     19      that. For example to modify a text document the user just clicks
     20      the document and doesn&apos;t has to care which application is
     21      able to handle that kind of document because the system will find
     22      an appropriate one. In task driven environments the user first
     23      starts an application, for example a word processor, and opens
     24      documents from inside the application using a file chose
     25      dialog.</para>
     26
     27      <para>All documents, files etc. the user interacts with are
     28      objects because the desktop is based on an object model described
     29      elsewhere in this document. This means the desktop is fully
     30      object orientated with all the benefits coming from that. So
     31      it&apos;s possible to have data encapsulated in the objects and
     32      subclassing of document or file classes is not even allowed but
     33      encouraged by the underlying system.</para>
     34
     35    </section>
     36
     37    <section id="dov.vom.g.co">
     38
     39      <title>Classes and Objects</title>
     40
     41      <para>The user of the desktop is dealing with objects. Files for
     42      example are not classic files like on other systems but are real
     43      objects in the sense that they might carry additional information
     44      which is encapsulated and come with object methods to work with
     45      them. For example one doesn&apos;t copy a file by using a
     46      filemanager or the desktop application and calling some
     47      <function>copy()</function> API of the operating system. Instead
     48      a method on the file object is invoked and the file object
     49      handles the copying on itself.</para>
     50
     51      <para>Every object is an instance of a class which is registered
     52      with the desktop. Classes may be registered and de-registered at
     53      any time (a restart of the desktop may be necessary). They are
     54      implemented as shared libraries and link dynamically to the
     55      desktop. Basing the whole desktop on an object model which allows
     56      subclassing and class replacement without recompiling it&apos;s
     57      possible for independent developers to create new classes without
     58      access to the desktop source code. In fact developers are
     59      encouraged not to modify sources to extend the desktop but to
     60      create new classes to add functions to the desktop. By replacing
     61      classes with new versions overriding inherited methods it&apos;s
     62      possible to modify the behaviour of any class of the
     63      desktop.</para>
     64
     65      <para>The root class of the whole desktop is
     66      <classname>SOMObject</classname> which is also the root class of
     67      the underlying object system (see picture below).
     68      <classname>WPObject</classname> implements basic desktop methods
     69      like menus or property notebooks. Derived from the basic desktop
     70      class is the filesystem class for objects representing files or
     71      folders. A subtree handles all types of folders which isn&apos;t
     72      covered here. All kinds of files live on the left part of the
     73      tree. A basic datafile class <classname>WPDataFile</classname>
     74      implements methods common to all files like querying the filesize
     75      or getting the date of creation. A subtree starting with
     76      <classname>MMAudio</classname> implements audio multimedia files
     77      while a class <classname>MMVideo</classname> handles digital
     78      video files. The <classname>WPDataFileExt</classname> class will
     79      be covered later.</para>
     80
     81      <para>The benefits of using such a class tree in the desktop are
     82      easily spotted. The <classname>MMAudio</classname> class
     83      implements basic features like playing audio files or displaying
     84      audio information like the playtime of the file in question using
     85      operating system features. It may also provide a method for
     86      accessing tags in the audio file containing the artists name or
     87      the trackname. One may implement the latter by adding code to
     88      handle ID3 tags of MP3 files and code to handle the same for OGG
     89      files. In the end <classname>MMAudio</classname> would contain
     90      code for every tag format known. If a developer ever came up with
     91      a new audio codec and a different tag architecture the maintainer
     92      of the desktop or the <classname>MMAudio</classname> class had to
     93      be asked to add additional parsing code. Even after the code
     94      addition users can&apos;t immediately benefit from it because the
     95      next release may only be available at some point in the
     96      future.</para>
     97
     98      <section id="dov.vom.g.s">
     99
     100        <title>Subclassing</title>
     101
     102        <para>Using derived classes said developer may just create a
     103        new class which inherits everything from
     104        <classname>MMAudio</classname> but overrides the method which
     105        deals with tag parsing to implement the new parser. Using a
     106        binary compatible object system this class can be added without
     107        recompiling the desktop. Even more the developer doesn&apos;t
     108        need the desktop sources at all and doesn&apos;t have to care
     109        about the rest of the class hierarchy or changes to
     110        <classname>MMAudio</classname> made by others (as long as the
     111        others don&apos;t break the class by changing the binary
     112        interface by purpose). Users may install the new class without
     113        changing anything of their current system and may immediately
     114        use the new features implemented by the class seamlessly. So
     115        instead of adding more and more code to
     116        <classname>MMAudio</classname> it&apos;s better to move
     117        specialized code like tag parsing to specialized classes as
     118        done in the example with <classname>MMMp3</classname> and
     119        <classname>MMOgg</classname>. This also helps to keep the
     120        source maintainable because possible execution path are clear
     121        and well contained.</para>
     122
     123      </section>
     124
     125      <section id="dov.vom.g.cr">
     126
     127        <title>Class Replacement</title>
     128
     129        <para>FIXME</para>
     130
     131      </section>
     132
     133    </section>
     134
     135    <section id="dov.vom.g.fv">
     136
     137      <title>Folder Views</title>
     138
     139      <para>Each folder object opens in its own window (spatial view).
     140      The characteristics of this window like size, position, used font
     141      are saved in the instance data of the folder object. This means
     142      the window reopens exactly the way the user left it before.</para>
     143
     144      <para>Three different kind of views are supported:</para>
     145
     146      <variablelist>
     147
     148        <varlistentry>
     149
     150          <term><emphasis>Icon View</emphasis></term>
     151
     152          <listitem>
     153
     154            <para>All objects are shown with an icon and a name</para>
     155
     156          </listitem>
     157
     158        </varlistentry>
     159
     160        <varlistentry>
     161
     162          <term><emphasis>Details View</emphasis></term>
     163
     164          <listitem>
     165
     166            <para>Objects are shown in a list with each row containing
     167            the icon, the name and details about the object in question
     168            like filesize or creation date.</para>
     169
     170          </listitem>
     171
     172        </varlistentry>
     173
     174        <varlistentry>
     175
     176          <term><emphasis>Tree View</emphasis></term>
     177
     178          <listitem>
     179
     180            <para>A tree of the folder and the subfolder is shown.
     181            Single objects are not shown in this view. If any of the
     182            subfolders contains additional folders this is depicted by
     183            a plus sign next to it. Clicking on this plus shows the
     184            subfolder tree.</para>
     185
     186          </listitem>
     187
     188        </varlistentry>
     189
     190      </variablelist>
     191
     192      <para><emphasis>Browser View</emphasis> is not supported because
     193      this kind of traversing the filesystem breaks the object metaphor
     194      of the desktop. Changing the folder one is in has to also change
     195      position, size and shape of the browser window because in the
     196      object world the view should represent the underlying object. Not
     197      taking into account the object settings confuses the user because
     198      he can&apos;t rely on a consistant behaviour of folder views with
     199      respect to the folders window settings.</para>
     200
     201    </section>
     202
     203    <section id="dov.vom.g.t">
     204
     205      <title>Templates</title>
     206
     207      <para>New documents, files or other objects are created by
     208      dragging an object template somewhere into the filesystem.
     209      Templates normally are located in the central Templates folder
     210      but may also be created in other places. Beside the system or
     211      application provided templates the user may create his own
     212      templates. This is done by checking the Templates checkbox in the
     213      settings of an object.</para>
     214
     215      <note>
     216
     217        <para>Voyager-desktop compliant applications handling documents
     218        should create the appropriate templates for the user.</para>
     219
     220      </note>
     221
     222      <para />
     223
     224    </section>
     225
     226  </section>
     227
     228  <section id="dov.vom.i">
     229
     230    <title>Implementation</title>
     231
     232    <para>This Chapter describes the implementation of the desktop.
     233    It&apos;s a technical document intended merely for
     234    developers.</para>
     235
     236    <section id="dov.vom.i.mm">
     237
     238      <title>Memory Management</title>
     239
     240      <para>Using <function>wpAllocMem()</function> and
     241      <function>wpFreeMem()</function> allocated memory is tracked in
     242      an inuse list. Whenever an object is deleted or goes dormant this
     243      list is scanned by the system and memory still allocated will be
     244      freed automatically. Nevertheless memory not in use anymore
     245      should be freed by the programmer as usual because the desktop
     246      does not include a garbage collector. The inuse list should be
     247      considered as a kind of safety net.</para>
     248
     249      <warning>
     250
     251        <para>While the usual memory function like
     252        <function>malloc()</function>, <function>g_alloc()</function>,
     253        <function>SOMMAlloc()</function> are available to desktop
     254        developers it is strongly adviced to only use
     255        <function>wpAllocMem()</function> and
     256        <function>wpFreeMem()</function>.</para>
     257
     258      </warning>
     259
     260      <orderedlist numeration="loweralpha">
     261
     262        <listitem>
     263
     264          <title>Memory allocation with
     265          <function>wpAllocMem()</function></title>
     266
     267          <para>A programmer asks for memory using</para>
     268
     269          <funcsynopsis><funcprototype><funcdef>int
     270          <function>wpAllocMem</function></funcdef> <paramdef>WPObject
     271          <parameter>somSelf</parameter></paramdef> <paramdef>ULONG
     272          <parameter>cbBytes</parameter></paramdef>
     273          <paramdef><parameter>...</parameter></paramdef></funcprototype></funcsynopsis>
     274          <para>This method is introduced by the
     275          <classname>WPObject</classname> class.</para>
     276
     277          <para><function>wpAllocMem()</function> does the
     278          following:</para>
     279
     280          <itemizedlist>
     281
     282            <listitem>Call <function>SOMCalloc()</function>to allocate
     283            a memory block of size cbBytes+sizeof(USEITEM)+sizeof
     284            (MEMORYITEM)</listitem>
     285
     286            <listitem>Fill information area of the USEITEM part of the
     287            memory block</listitem>
     288
     289            <listitem>Fill information area of the MEMORYITEM part of
     290            the memory block</listitem>
     291
     292            <listitem>Call <function>wpAddToObjUseList(somSelf,
     293            ...)</function>to add the item to the objects inuse
     294            list</listitem>
     295
     296            <listitem>Return a pointer to the memory block following
     297            USEITEM and MEMORYITEM to the caller</listitem>
     298
     299          </itemizedlist>
     300
     301          <para>The layout of the memory is like this.</para>
     302
     303          <para>To ensure the desktop is thread safe each object has a
     304          semaphor to serialize access to critical object instance
     305          variables. The inuse list is such a critical resource so
     306          <function>wpAddToObjUseList()</function> tries to aquire the
     307          objects semaphor using
     308          <function>wpRequestObjectSem()</function>.</para>
     309
     310          <warning>
     311
     312            <para>Calling <function>wpAllocMem()</function> while
     313            holding the object semaphor will cause a deadlock.</para>
     314
     315          </warning>
     316
     317        </listitem>
     318
     319        <listitem>
     320
     321          <title>Freeing memory with
     322          <function>wpFreeMem()</function></title>
     323
     324          <para>Memory is freed using
     325          <synopsis>wpFreeMem()</synopsis></para>
     326
     327          <para>This method introduced by
     328          <classname>WPObject</classname> takes the memory pointer and
     329          travels back to the USEITEM part of the allocated memory
     330          block (see the section about memory allocation). Using a
     331          pointer to the USEITEM the memory is removed from the objects
     332          inuse list using
     333          <function>wpDeleteFromObjUseList()</function>.</para>
     334
     335          <para>Be aware that this method tries to aquire the object
     336          semaphor so a deadlock may occur when the semaphor is already
     337          held.</para>
     338
     339          <warning>
     340
     341            <para>Calling <function>wpFreeMem()</function> while
     342            holding the object semaphor will cause a deadlock.</para>
     343
     344          </warning>
     345
     346          <para>After removing the item from the inuse list a call to
     347          <function>SOMFree()</function> deallocates the memory
     348          block.</para>
     349
     350        </listitem>
     351
     352      </orderedlist>
     353
     354    </section>
     355
     356  </section>
    8357
    9358</chapter>
Note: See TracChangeset for help on using the changeset viewer.