UNIX @EU de:PE1CHL 25.12.92 05:47 0 8915 Bytes Linux News #8 *** Bulletin-ID: LINUXNEWS8 *** 921225/0154z DK0MWX, 921225/0108Z PI8AIR, 921225/0058Z PI8UTR Message #6382 - USENET.COMP.OS.LINUX Date: 19-12-92 21:56 From: Lars Wirzenius To: All Subject: Linux News #8 (November 28 - December 19, 1992) L i n u x N e w s A summary of the goings-on of the Linux community Issue #8, November 28 through December 19, 1992 **** Highlights in this issue - kernel now at 0.99 - new newsgroups: comp.os.linux.announce, comp.windows.x.i386unix - the end of Linux News? - mpeg-1.1 - deliver - TeX sources for Linux - Lilo 0.7 - xgraph - efsprogs alpha 11 - xphoon - Newspak 1.1 - ckermit - mawk - Seyon 1.5 - Xcomm - Epoch 4.2 - SLS updates **** Editorial In case you haven't noticed, I'm unusually late with this issue, about three weeks. Sorry about that. Due to the large number of things that I had saved for inclusion, and my chronic lack of time, I have had to keep things very short in this issue, and have also skipped unusually many things. Probably the biggest news at the moment is that "1.0 is coming, are you ready?". Well, actually there is not that much to be ready about, since 1.0 will not introduce many changes from the current kernel. Unless you are dedicated into building your system from scratch, you'll probably be best of with the SLS release, and if you update your system to that, you can be fairly certain of having a well-working system. Two other quite important things are two new newsgroups: comp.os.linux.announce, and comp.windows.x.i386unix. If you don't have the time to read all of comp.os.linux, but want to stay up to date with what is happening with Linux (and are disgusted with the delays with LN :), read that group. Also, if you have something to announce that is of general interest for the Linux community, do it in c.o.l.a. (Nice acronym, eh?) C.o.l.a will be gatewayed to a mailing-list for those without Usenet access sometime in the future. The splitting vote for comp.os.linux failed to create the other proposed groups. There will not be a new vote until at least six months have passed since the previous one. Comp.windows.x.i386unix is intended for discussions about X on 386 Unices, including Linux. It is a good idea to use it instead of comp.os.linux for such discussions, since there is quite enough of traffic in c.o.l as it is. Last, and probably least, I'm looking for a volunteer to take over Linux News. I don't seem to be able to have enough time to do it often enough and well enough, so I'd like to hand it over to somebody else. Mail me if you are willing. I'd like somebody who has been using Linux actively for some time so that she (or he :-) has some understanding of what is going on and what various things are. Alternatively, I might change LN into a non-periodic thing and only publish and issue every few weeks or months, and include more articles and less news items. (Might have to change the name too, then.) **** Legalese Linux News can be copied, re-published, printed, hung on walls, used as toilet paper, and used in any other way you wish. If you distribute LN outside comp.os.linux and the LINUXNEWS channel, please tell me: the more people I know are reading LN, the more eager I am to put energy into it. I take no responsibility whatsoever for any information in Linux News, or any problems due lack of information. If you get killed due to Linux News, mail me, and I'll feel sorry for you, but that's just about all I can do. **** Notices Linux News is only a summary, if you want more information about a given subject, please see the source that is referenced at the end of each note (for Usenet articles, the reference is the Message-ID of the article). I try to include all the relevant information, including ftp sites and filenames, as given in the announcements (I probably won't have the time or energy to check filenames, or to find pointers to other ftp sites). If possible, I will try to indicate directories with a trailing /, e.g. ``pub/linux/SLS/''. I won't include announcements on mailing lists or testing releases, only things that are meant to be used generally (I admit that the line can be somewhat difficult to draw, since the whole system is pre-release). There will be exceptions. **** News section November 30. Scott A. Laird announced an upload of MPEG-1.1. It is a program for viewing "movies" in the MPEG compressed format. Needs X. Scott says he gets about 8 frames per second on a 486DX2/50 with ATI Graphics Ultra, so it is probably not particularly fast on a 386SX... FTP: tsx-11.mit.edu (binary), toe.cs.berkeley.edu: /pub/multimedia/mpeg/ (source). (Source: <1992Nov30.070546.23765@midway.uchicago.edu>) December 8. Matthew Donadio announced binaries for Deliver for Linux. It is a program which delivers electronic mail once it has arrived at a given machine. FTP: sunsite.unc.edu: deliver.TZ (Source: <1992Dec8.173324.19957@tc.cornell.edu>) December 8. Thomas Dunbar announced Linux TeX source upload. FTP: tsx-11.mit.edu: /pub/linux/packages/TeX, files web2c.taz (essential things) and texweb.taz (misc source). (Source: <1992Dec8.191750.22643@tc.cornell.edu>) December 7. Werner Almesberger announced Lilo 0.7. Lilo is the Linux Loader, the set of programs that allows Linux to boot from a hard disk. FTP: tsx-11.mit.edu: pub/linux/packages/lilo, files lilo.7.tar.Z (sources for programs and docs), lilo.7.ps.Z (docs in PostScript format). (Source: <1992Dec7.062414.6307@bernina.ethz.ch>) December 7. Isaac Wong announced xgraph for Linux. It is a two-dimensional plotting program. FTP: tsx-11.mit.edu: xgraph.taz (source and binary). (Source: <1992Dec7.193518.21471@netcom.com>) December 9. Remy Card announced version alpha 11 of the extended filesystem support programs. FTP: ftp-masi.ibp.fr: /pub/linux/ALPHA/extfs/, tsx-11.mit.edu. (Source: <1992Dec9.172910.22669@tc.cornell.edu>) December 10. David Peterson announced binaries for xphoon. It is a FTP: sunsite.unc.edu and tsx-11.mit.edu: phoonbin.tar.Z. (Source: <1992Dec10.160753.22094@tc.cornell.edu>) December 11. Vince Skahan announced Newspak-1.1. It is a set of programs for setting up a Usenet site. It includes cnews, tin, trn, and nn. It doesn't include UUCP or other networking, which you need from elsewhere. FTP: sunsite.unc.edu: /pub/Linux/System/news/ (Source: <1992Dec11.170805.22139@tc.cornell.edu>) December 12. hutchinson@wrair-emh1.army.mil announced ckermit5A(188) and mawk 1.1.2 binaries upload. ckermit is a terminal / file transmission program, mawk is an implementation of the AWK language. FTP: tsx-11.mit.edu: ckermit5A.188.tar.Z, mawk1.1.2bin.tar.Z (Source: <1992Dec12.053016.6610@tc.cornell.edu>) December 13. Linus released version 0.99 of the kernel. This version should have all the functionality of 1.0, and should only be changed to fix bugs before 1.0, which will hopefully be released before the end of the year. There were a couple of problems with 0.99, fixed by small patches posted by Linus. FTP: nic.funet.fi: pub/OS/Linux/PEOPLE/Linus: linux-0.99.tar.Z (Source: <1992Dec13.193812.6958@tc.cornell.edu>) December 13. M. Saggaf announced Seyon 1.5. It is a terminal program for X. FTP: sipb.mit.edu: /pub/seyon; also export.lcs.mit.edu, nic.funet.fi, and sunsite.unc.edu. (Source: <1992Dec13.194528.7230@tc.cornell.edu>) December 14. Jeff Randall announced Xcomm patchlevel 5. It is a terminal program. FTP: xcomm3b-L1.5.src.tar.Z, xcomm3b-L1.5.bin.tar.Z (Source: <1992Dec14.191822.12572@tc.cornell.edu>) December 14. Thomas Dunbar uploaded a binary of Epoch-4.2. It is an X version of GNU Emacs. FTP: tsx-11.mit.edu: /pub/linux/packages/TeX/epoch42.taz (Source: <10438@vtserf.cc.vt.edu>) December 18. Ian Jackson announced archives of comp.os.linux.announce, up to December 17. FTP: nic.funet.fi, tsx-11.mit.edu, ftp.informatik.tu-muenchen.de, sunsite.unc.edu, fgb1.fgb.mw.tu-muenchen.de, ftp.dfv.rwth-aachen.de, ftp.win.tue.nl, ftp.ibr.cs.tu-bs.de, ftp.uni-kl.de. (Source: <1992Dec18.194443.2246@tc.cornell.edu>) Lotsa dates. Peter MacDonald has been updating SLS fairly often. The changes include: nfs and shadow password support, the syslogd daemon, ghostscript, mailpak, and the 0.99 kernel. Check the HISTORY file on ftp sites for more information. UNIX @EU de:PE1CHL 25.12.92 05:51 0 10135 Bytes Linux Info *** Bulletin-ID: LINUX-INFO *** 921225/0205z DK0MWX, 921225/0112Z PI8AIR, 921225/0102Z PI8UTR Message #6490 - USENET.COMP.OS.LINUX Date: 20-12-92 22:14 From: Lars Wirzenius To: All Subject: Linux INFO-SHEET Replies: #1756 <- Archive-name: linux-faq/info-sheet Last-modified: 1992-12-10 LINUX INFORMATION SHEET by Lars Wirzenius (lars.wirzenius@helsinki.fi), earlier versions done by other people 0. About this INFO-SHEET This INFO-SHEET tries to be a concentrated distillation of the necessary information one needs to decide whether Linux is a suitable operating system for you. It is kind of an advertisment, although hopefully more truthful. This INFO-SHEET is posted every other week to the comp.os.linux newsgroup. 1. What Is Linux? Linux is a freely distributable UNIX clone. It is mostly compatible with System V and POSIX specifications, but is quite compatible with BSD as well. The Linux kernel has been written from scratch, and therefore does not contain any proprietary code, either from AT&T, MINIX, or other places--not in the kernel, the compiler, the utilities, or the libraries. For this reason it can be made available with the complete source code via anonymous FTP. (The software that runs under Linux, on the other hand, is mostly already existing Unix freeware, with a lot of stuff coming from the GNU Project.) Linux runs only on 386/486 machines with an ISA or EISA bus; porting to other architectures is likely to be difficult, as the kernel makes extensive use of 386 memory management and task primitives (but there are people working on at least an Amiga port). MCA is not supported because there is little available documentation (especially for poor-hacker -friendly prices) about it. (See below for more information on hardware.) Linux is still in beta testing and therefore not really considered to be suitable for production work (although it is used for that anyway). There are still bugs in the system, and since it develops rapidly, new bugs creep up often. However, some releases are quite stable, and you can stay with those if you don't want to be on the bleeding edge. Some sites have been running Linux systems continuously doing real work for more than 50 days, without a single reboot, crash, or other lock-up! One thing to be aware of is that Linux is developed using an open and distributed model, instead of a closed and centralised model like much other software. This means that the current development version is always public (with up to a week or two's delay) so that anybody can use it. The result is that whenever a version with new functionality is released, it almost always contains bugs, but it also results in a very rapid development so that the bugs are found and corrected quickly, sometimes in hours. (The closed and centralised model means that there is only one person or team working on the project, and they only release software that they think is working well. Often this leads to long intervals between releases, long waiting for bug fixes, and slower development. Of course, the latest release of such software is often of higher quality.) As of December 10 the current version is 0.98 patchlevel 6. 2. Linux Features * multitasking: several programs running at once * multiuser: several users on the same machine at once (and NO two-user licenses!) * memory protection between processes, so that one program can't bring the whole system down * core dumps for post-mortem analysis (using a debugger on a program after it has crashed) * demand loading of executables: only read in those parts of a program that are actually used * virtual memory using paging (not swapping whole processes) to disk, to a separate partition or a file in the filesystem, or both, and with a possibility to add more swapping areas at runtime (they're still called swapping areas) * shared pages among executables with copy-on-write * shared libraries (static too, of course) * a unified memory pool for user programs and disk cache (so that all free memory can be used for caching, and the cache can be reduced when running large programs) * mostly compatible with POSIX, System V, and BSD at the source level * all source code is available, including the whole kernel and all drivers, the development tools and all user programs; also, all of it is freely distributable * POSIX job control * pseudoterminals (pty's) * 387-emulation in the kernel so that programs don't need to include math emulation packages * support for many national or customized keyboards, and it's fairly easy to add new ones * runs in protected mode of the 386 * multiple virtual consoles: several independent login sessions through the console, you switch by pressing a hot-key combination (not dependent on video hardware) * normal and extended Minix filesystems (the extended version supports up to 4 TB, filenames up to 255 chars) * transparent access to MS-DOS partitions (or OS/2 FAT partitions) via a special filesystem: you don't need any special commands to use the MS-DOS partition, it looks just like a normal Unix filesystem (except for funny restrictions on filenames, permissions, and so on) * CD-ROM filesystem * Xenix filesystem In addition the following are being worked on (in various states of usability): * networking (TCP/IP, including ftp, telnet, etc) * compressed file system * Xenix binary compatibility 3. Hardware Issues Minimal configuration The following is probably the smallest possible configuration that Linux will work on: 386SX/16, 2 MB RAM, 1.44 MB or 1.2 MB floppy, any supported video card (+ keyboards, monitors, and so on of course). This should allow you to boot and test whether it works at all on the machine, but you won't be able to do anything useful. In order to do something, you will want some hard disk space as well, 5 to 10 MB should suffice for a very minimal setup (with only the most important commands and perhaps one or two small applications installed, like, say, a terminal program). This is still very, very limited, and very uncomfortable, as it doesn't leave enough room to do just about anything. (It's definitely not recommended for anything but testing if things work, and of course to be able to brag about small resource requirements. :-) Usable configuration If you are going to run computationally intensive programs, such as gcc, X, and TeX, you will probably want a faster processor than a 386SX/16, but even that should suffice if you are patient. In practice, you need at least 4 MB of RAM if you don't use X, and 8 MB if you do. Also, if you want to have several users at a time, or run several large programs (compilations for example) at a time, you may want more than 4 MB of memory. It will still work with a smaller amount of memory (should work even with 2 MB), but it will use virtual memory and that will be so slow it's unusable. The amount of hard disk you need depends on what software you want to install. The normal basic set of Unix utilities, shells, and administrative programs should be comfortable in less than 10 MB, with a bit of room to spare for user files. For a more complete system, the SLS documentation reports that a full base system without X fits into 20 MB, and with X into 40 MB (this is only binaries). Add the whatever space you want to reserve for user files. Add more memory, more hard disk, a faster processor and other stuff depending on your needs, wishes and budget to go beyond the merely usable. Supported hardware Note: This section is still sketchy. Feedback appreciated. CPU: Anything that runs 386 protected mode programs (all models of 386s and 486s should work; 286s don't work, and never will). Architecture: ISA or EISA bus (you still need an ISA-bus hard disk controller, though). MCA (aka PS/2) does not work. Local bus should work. RAM: Theoretically up to 1 GB (but more than 16 MB requires a kernel recompilation). (It will work with "too much" memory, but it won't use it.) Data storage: Generic AT drives (IDE, 16 bit HD controllers with MFM or RLL), generic XT controllers (8 bit controllers with MFM or RLL) need a special driver (not currently part of the standard kernel), SCSI hard disks and CD-ROM. Supported SCSI cards: Adaptec 1542 (but not 1522), the 1740 in extended (not 1542 compatible) mode, Seagate ST-01 and ST-02, Future Domain TMC-88x series (or any board based on the TMC950 chip) and TMC1660/1680, Ultrastor 14F, and Western Digital wd7000. SCSI and QIC-02 tapes. UNIX @ALLE de:DL2LQB 27.12.92 10:46 0 16022 Bytes x-window-system 1/2 *** Bulletin-ID: 25C227DB0BOX *** 921227/0335z DK0MWX, 921227/0313z DB0IZ , 921226/1051z DB0GE 921226/0925z HB9EAS, 921226/0846z OE9XPI, 921226/0727z DB0CZ 921226/0432z DB0KCP, 921226/0408z DB0MWE, 921226/0433z DB0LAN 921225/1643z DB0BOX de DL2LQB @ DB0BOX Da in der letzten Zeit immer fter von s.g. Grafischen Benutzeroberflchen die Rede ist (WINDOWS fr DOS ist wohl die bekannteste) will ich hier mal auf die Grundlagen eines Systems eingehen, welches eigentlich als Ursprung dieser Art der Computerbedienung gelten kann, nmlich das X-WINDOW-SYSTEM vom MIT. hnliche Konzepte, meist aber nicht alle, sind in den weiteren heute bekannten Benutzeroberflchen realisiert. Ich bin zwar in Bezug auf das X-WINDOW-SYSTEM auch noch kein Profi, aber ich will trotzdem versuchen, einige grundlegende Eigenschaften zu erlutern und hoffe, da so auch einige Fragen beantwortet werden knnen, die immer mal wieder an mich herangetragen werden. Mit der immer weiteren Verbreitung des LINUX-Systems (das mit allen Quelltexten frei erhltlich ist), wird sich auch das mit enthaltene X-WINDOW-SYSTEM weiter verbreiten. vy 73, 55 de Mike DL2LQB @ DB0BOX.GER.EU 1. Was ist das X-WINDOW-SYSTEM ? Das X-WINDOW-SYSTEM ist ein leistungsfhiges Konzept fr die rechner- und gerteunabhngige grafische Ein- und Ausgabe, das sowohl die Tastatur als auch die Maus untersttzt. Es ist so angelegt, da es auf einem Rechner allein, aber auch verteilt ber ein Netzwerk arbeiten kann. Entwickelt wurde das System 1984 am MIT (Massachusetts Institute of Technology). Seitdem hat es sich zu einem Quasi-Industriestandard im UNIX-Bereich entwickelt. 2. Wie macht das X-WINDOW-SYSTEM Ausgaben auf den Bildschirm ? Will ein normales Anwenderprogramm eine grafische Ausgabe machen, z.B. eine Linie zeichen, ruft es meist aus einer entsprechenden Grafikbibliothek ein Unterprogramm auf (z.B. draw_line() ), das die entsprechende Aufgabe erledigt. Nachdem das Unterprogramm nun die Linie auf den Bildschirm gezeichnet hat, gibt es die Steuerung an das aufrufende Programm zurck, welches dann weiterarbeiten kann. Ŀ Ŀ Ŀ Anwender- Ŀ programm Grafik- > MONITOR bibliothek draw_line() < Beim X-WINDOW-SYSTEM wird die Grafikbibliothek durch ein Programm ersetzt, das X-Server genannt wird. Dieser X-Server arbeitet parrallel zum Anwenderprogramm und hat die alleinige Kontrolle ber den Bildschirm, d.h. kein anders Programm als der X-Server ist in der Lage, irgend etwas auf den Bildschirm zu schreiben. Wenn hier ein Anwenderprogramm eine Ausgabe auf den Bildschirm machen will, kann das nur erreicht werden, indem das Programm eine bestimmte Nachricht an den X-Server sendet, worauf dieser dann die gewnschte Aktion fr das Anwenderprogramm ausfhrt. Die Steuerung geht sofort nach dem Senden der Nachricht wieder an das Programm zurck. Der X-Server fhrt die Aktion unabhngig vom Anwenderprogramm aus. Die unterschiedlichen Nachrichten, die ein X-Server versteht, sind genau festgelegt und werden X-Protokoll genannt. Es gibt z.B. Nachrichten, die Linien zeichen oder auch Text an bestimmten Positionen ausgeben. Ein Anwenderprogramm, das Ausgaben macht, indem es Nachrichten an einen X-Server sendet, wird X-Client genannt. Der X-Server kann auch Nachrichten zurck an den X-Client senden, z.B Nachrichten ber bestimmte Ereignisse (Eingaben, Maus-Click usw.) oder Fehlernachrichten. Diese Nachrichten sind ebenfalls Teil des X-Protokolls. Wenn ein X-Client Ausgaben ber einen X-Server abwickelt, so werden die Ausgaben meist in ein Fenster geschrieben. Es ist aber auch mglich, da ein einziger X-Client mehrere Fenster auf dem Bildschirm bedient. Ein X-Server kann gleichzeitig die Ausgaben von mehreren X-Clients erledigen. Er reagiert allerdings nur auf Anforderungen, die dem X-Protokoll entsprechen. Es gibt keinen anderen Weg, Ausgaben zu produzieren. Ŀ Ŀ Ŀ Anwender- > programm Programm > MONITOR draw_line() < X-Client X-Protokoll X-Server 3. Was ist ein ereignisgesteuertes System ? Das X-WINDOW-SYSTEM wird auch als ereignisgesteuertes System bezeichnet, d.h. X-Clients tun solange nichts, bis sie vom X-Server die Nachricht ber ein eingetretenes Ereignis, das sie interessiert erhalten. Der X-Server schickt so z.B. Nachrichten an seine Clients, wenn in bestimmten Fenstern ein Maus-Click erfolgte, wenn Eingaben ber die Tastatur gemacht worden sind, oder wenn gar ein Fenster eines Clients neu gezeichnet werden mu, da z.B. die Gre eines anderen Fensters verkleinert worden ist, oder es gar vom Bildschirm entfernt oder verschoben wurde. Diese Ereignisse koordiniert der X-Server und er schickt seine Nachrichten an die betroffenen Clients. Die Clients bearbeiten nun diese Nachrichten, produzieren vielleicht irgendwelche Ausgaben und legen sich anschlieend zur Ruhe, bis wieder irgendwelche Nachrichten eintreffen. Diese Vorgehensweise unterscheidet sich sehr stark von der bisher allgemein blichen Programmart. Die Anwendungen wurden bisher meist prozedurorientiert angelegt und hatten die aktive Rolle im Dialog mit dem Nutzer. Das Programm machte irgendwelche Ausgaben, wartete dann auf eine Eingabe vom Benutzer und rief entsprechende vordefinierte Unterprogramme auf. Wesentlich dabei ist, da solche Programme nur zu bestimmten Zeitpunkten irgendwelche Eingaben vom Nutzer akzeptieren. Ein gutes Beispiel sind da die Eingabemasken von Datenbanksystemen. Mit dem Aufkommen der Maus als bequemes Eingabemedium, war diese Vorgehensweise nicht mehr sehr sinnvoll. Ein ereignisgesteuertes Anwenderprogramm spielt im Dialog Mensch-Maschine eine eher passive Rolle. Der Nutzer kann zu jedem beliebigen Zeitpunkt irgendwelche Eingaben machen (z.B. indem er mit der Maus auf >ENDE< clickt). Das erlaubt natrlich ein viel flexibleres Arbeiten. Es gibt im Allgemeinen keine vorgefertigten Ablufe mehr, um zu bestimmten Ergebnissen zu gelangen. Vielmehr gibt es nun viele Mglichkeiten fr den Nutzer, den Ablauf selbst zu bestimmen. Ein gutes Beispiel sind hier die weit verbreiteten Mal- und CAD-Programme. 4. Wie kann das X-WINDOW-SYSTEM in Netzwerken eingesetzt werden ? Wenn der X-Client nur durch X-Protokoll-Nachrichten mit dem X-Server kommuniziert, ist es auch mglich, den X-Client auf einem anderen Rechner laufen zu lassen, als den X-Server. Die Kommunikation der beiden Programme kann ber verschiedenste Kabelkanle (wie z.B. serielle Leitungen, Modem-Leitungen oder Netzwerke) abgewickelt werden. Wenn ich z.B. mit meinem PC an einem Netzwerk angeschlossen bin, kann ich auf meinem PC einen X-Server starten und dann mit Programmen, die auf verschiedenen Rechnern im Netz laufen, arbeiten. In der Tat ist es sogar so, da das X-WINDOW-SYSTEM als grafisches Netzwerksystem konzipiert worden ist. Ŀ Ŀ X-Server v ^ >1< >2< >3< Ŀ <ij͹ X-Client >Ĵ <Ĵ RECHNER 1 >Ĵ Ŀ <Ĵ >Ĵ <Ĵ >2< >6< >Ĵ Ŀ Ŀ ͹ X-Client X-Client RECHNER 2 Ŀ <Ĵ X-Server >Ĵ 6 v ^ >4< <Ĵ Ŀ Ŀ >5< X-Client X-Client X-Client>ij͹ >3< <Ĵ RECHNER 3 >Ĵ Ŀ Ŀ X-Server <ij͹ >5< >Ĵ RECHNER 4 Netzwerk 5. Welche Betriebssysteme und welche Rechner sind mglich ? Da der X-Server mit den X-Clients nur ber das genau definierte X-Protokoll kommuniziert, ist es vllig gleichgltig, auf was fr einer Maschine der Client oder der Server luft. Es spielt weder der Prozessor, noch das Betriebssystem irgendeine Rolle. Wichtig ist nur, da ein Client fr die gewnschte Maschine und ein X-Server fr jede Nutzermaschine verfgbar ist. 6. Was ist ein X-Terminal ? Auf dem Bild der vorigen Frage war der RECHNER 4 zu sehen, auf dem nur ein X-Server lief. Man kann diesen Rechner auch als grafisches Terminal betrachten, mit dem Programme auf anderen Rechnern bedient werden knnen. Solche speziellen Rechner werden X-Terminals genannt. Ein X-Server-Programm auf einem IBM-PC macht diesen also zu einem X-Terminal. Es gibt aber auch spezielle Terminals, die von sich aus das X-Protokoll verstehen. Diese sind aber noch sehr teuer. Das dazu ntige X-Server-Programm ist dabei als Firmware im Terminal untergebracht. Es gibt auch X-Terminals, bei denen bestimmte Komponenten direkt als Hardware realisiert sind, so da solche X-Terminals auch sehr schnell sind. 7. Knnen Rechner ohne Terminal im Netz arbeiten ? Der RECHNER 2 im obigen Bild spielt nur die Rolle eines Servers. Auf ihm laufen verschiedene Programme, die ausnahmslos von anderen Rechnern aus bedient werden, d.h. fr diese Rechner ist kein Terminal ntig. So ist es z.B. mglich in einem Netzwerk komplizierte Simulationen auf einem solchen Server laufen zu lassen und die Ergebnisse auf dem Terminal des PC zu betrachten. Sollen allerdings X-Server und X-Client auf dem selben Rechner laufen, so ist es ntig, da es sich hierbei um ein Multitasking-System handelt, da ja dann zwei Programme gleichzeitig laufen mssen. Bei UNIX-Systemen ist das von vornherein kein Problem. Bei DOS-basierten Systemen geht das so nicht, da DOS zu einer Zeit nur ein Programm abarbeiten kann, z.B. den X-Server. Wenn man aber s.g. DOS-Erweiterungen, wie z.B. WINDOWS verwendet, ist schon ein eingeschrnktes Multitasking mglich. Ein echt gleichzeitiger Betrieb von X-Server und X-Clients auf einem PC erfordert dann aber ein anderes Betriebssystem, wie z.B UNIX oder in neuester Zeit OS/2 oder WINDOWS/NT. 8. Was ist ein Window-Manager ? Der X-Server produziert nur auf Anforderungen ber das X-Protokoll irgendwelche Ausgaben, er stellt nicht etwa Funktionen (wie z.B. Vergrern eines Fensters oder ndern der Anordnung von Fenstern auf dem Bildschirm) fr ein Programm zur Verfgung. Diese Funktionen knnten in jedem X-Client realisiert werden. Das wrde aber bedeuten, da in jedem X-Client die gleichen Funktionen programmiert werden wrden. Das ist aber nicht sinnvoll. Man knnte diese Funktionen aber auch im X-Server selbst realisieren, aber die Entwickler des X-WINDOW-SYSTEM haben eine noch flexiblere Lsung gefunden. Fr jeden X-Server luft ein spezieller X-Client, entweder lokal auf der gleichen Maschine, oder aber auf einer anderen Maschine. Dieser spezielle X-Client hat bestimmte Privilegien, die es ihm erlauben, alle Fenster die, die vom X-Server verwaltet werden, zu manipulieren. Dieser spezielle X-Client wird Window-Manager genannt. Der Window-Manager bestimmt das Aussehen der Fenster, wie z.B. die Umrandung, die berschriften von Fenstern und die Bereiche zur Manipulation der Fenster (Vergrern, Verkleinern, Verschieben, Schlieen usw.). Auch das Ausfhren solcher Manipulationen wird vom Window-Manager erledigt, wie z.B. das Verschieben oder Neuzeichnen eines Fensters weil ein Nutzer auf die entsprechenden Fensterbereiche mit der Maus geklickt hat, oder weil er aus einem Men des Window-Managers eine Funktion (z.B. Neuzeichen) ausgewhlt hat. Fr das X-WINDOW-SYSTEM gibt es mehrere Window-Manager. Die bekanntesten sind OSF/Motif, OPEN LOOK und der Tab (besser bekannt als Tom's) Window Manager. Es ist nun mglich, den Window-Manager zu wechseln, ohne da das auch nur irgendeinen Einflu auf die X-Clients, also die eigentlichen Programme, die die Ausgaben ttigen, htte. Es ndert sich nur das Aussehen der Fenster entsprechend dem verwendeten Window-Manager, der Inhalt der Fenster, der ja vom X-Client kommt, bleibt der gleiche. Der Window-Manager bestimmt also das Aussehen der Fenster, wobei der Fensterinhalt vom X-Client kommt, also unabhngig vom Window-Manager ist. Es gibt aber auch Programmbibliotheken, die es einem X-Client-Programmierer erlauben, Anwendungen mit einem bestimmten Aussehen zu erzeugen, wie z.B. OPEN LOOK oder OSF/Motif. Diese Bibliotheken werden Toolkits genannt. UNIX @ALLE de:DL2LQB 27.12.92 11:03 0 12047 Bytes x-window-system 2/2 *** Bulletin-ID: 25C233DB0BOX *** 921227/0343z DK0MWX, 921227/0328z DB0IZ , 921226/1300z DB0GE 921226/1110z HB9EAS, 921226/1045z OE9XPI, 921226/0816z DB0CZ 921226/0634z DB0KCP, 921226/0633z DB0AAB, 921226/0621z DB0FSG 921226/0622z DB0LNA, 921226/0612z DB0RGB, 921225/1824z DB0BOX de DL2LQB @ DB0BOX 9. Welche Programmierhilfsmittel gibt es ? Zur Programmierung von X-Clients stehen eine Menge von Programmbibliotheken zur Verfgung. Die wichtigsten sollen im folgenden kurz vorgestellt werden. a) Xlib : Ein X-Client, der mit einem X-Server kommunizieren will, mu Anforderungen senden knnen, die dem X-Protokoll entsprechen. Um die Programmierarbeit fr solche Anforderungen zu erleichtern und um Fehlerquellen auszuschlieen, gibt es eine Bibliothek, in der dafr schon fertige Funktionen zusammengefat sind. Diese Bibliothek wird Xlib genannt. Die Xlib ist die unterste Schnittstelle, ber die ein X-Client mit einem X-Server kommuniziert. Sie ist eine Sammlung von C-Funktionen. Dabei gibt es fr jede X-Protokoll-Nachricht eine C-Funktion. Einige Funktionen knnen auch mehrere X-Protokoll-Anforderungen erzeugen, je nach den bergebenen Parametern. Nutzt z.B. ein X-Client die Funktion XDrawLine() der Xlib, so wird der entsprechende Code in der Xlib ausgefhrt, der dann eine X-Protokoll-Anforderung erzeugt (in diesem Fall eine PolySegment-Anforderung), die dann zum X-Server geschickt wird. Wichtig ist noch, da die Funktionen der Xlib kein bestimmtes Aussehen der Ausgaben der X-Clients festlegen, sondern da hier nur die Anfordeung gestellt wird, ein Fenster zu erzeugen, eine Linie zu zeichnen oder Text auszugeben. Das Aussehen dieser Ausgaben wird von einer anderen Bibliothek festgelegt, dem Toolkit. Ŀ X-Client . . . XDrawLine() . . . Ŀ Xlib > Ŀ XDrawLineĴPolySegment> b) Toolkits : ber den eher als einfach zu bezeichnenden Funktionen der Xlib gibt es eine Programmierschnittstelle, die Toolkit genannt wird. Toolkits beinhalten Funktionen zum Bilden von Mens, Druckknpfen zur Mausbedienung und hnlichen Elementen. Seit die grundlegenden Fensterkomponenten mit Hilfe solcher Toolkits erzeugt werden, legen auch sie fest, wie ein Anwendungsprogramm aussieht und wie es zu bedienen ist. Eine Toolkitfunktion kann mehrere Xlib-Funktionen aufrufen, die dann wiederum X-Protokoll-Anforderungen erzeugen. Ŀ X-Client . . . XtPopup() . . . Ŀ Toolkit > XtPopup Ŀ > > > Xlib X-Protokoll-Anforderungen Ŀ Ŀ Ŀ >Ĵ Ĵ Ĵ > Will z.B. ein X-Client ein Popup-Fenster ffnen, ruft er die Funktion XtPopup (je nach dem verwendeten Toolkit) auf, die diese Arbeit erledigt. XtPopup wiederum ruft dann verschiedene Xlib-Funktionen auf, die dann die notwendigen X-Protokoll-Anforderungen erzeugen. Ein X-Client kann zustzlich zu den Funktionen eines Toolkits auch direkt Funktionen aus der Xlib aufrufen. Meist wird dies auch getan. Die bekanntesten Toolkits sind folgende : * Athena Toolkit: Das ist ein eher einfaches Toolkit, das vom MIT zum X-WINDOW-System geliefert wird. * OSF/Motif Toolkit : Dieses Toolkit wird von der Open Software Foundation untersttzt. Es wird einschlielich dem dazugehrigen Window-Manager von einer Firmenvereinigung (der OSF), der u.a. DEC, Hewlett-Packard und Microsoft angehren verbreitet. * Xol Toolkit : Das ist ein Toolkit, der dem OPEN LOOK Standard fr grafische Benutzeroberflchen entspricht. Typisch fr diese Darstellungen ist eine leichte 3-D-Darstellung der Fensterelemente. Anzumerken ist noch, da der OPEN LOOK Standard kein Toolkit oder Window-Manager an sich ist, sondern nur einen Standard darstellt, wie die Benutzeroberflche auszusehen hat. Das Xol-Toolkit stammt von AT&T. * Xview Toolkit : Dies ist ebenfalls ein Toolkit, das wie das Xol-Toolkit eine Realisierung des OPEN LOOK Standards darstellt. Allerdings hat es eine etwas andere Programmierschnittstelle als das Xol-Toolkit. Dieses Toolkit wurde von Sun Microsystems entwickelt. * XVT Toolkit : Dieses Toolkit ist fr Anwendungen interessant, die auf andere Systeme ohne X-WINDOW-SYSTEM portiert werden sollen, wie z.B Apple's Macintosh, Windows oder OS/2. Im Gegensatz zu den vorherigen Toolkits, wo die grafischen Ausgaben nur mit Hilfe der Xlib erzeugt wurden, werden hier s.g. Toolkit-Calls erzeugt, die von einer Bibliothek (Xlib oder eine andere) bearbeitet werden, die spezifisch fr die Zielmaschine angeboten werden. Somit knnen mit Hilfe dieses Toolkits Programme erstellt werden, die entweder die Xlib, OSF/Motif- oder OPEN LOOK - Bibliotheken benutzen, um ihre Ausgaben zu erzeugen. Das wiederum ermglicht es, da die Programme, je nach verwendeter Bibliothek beim Linken aussehen wie OSF/Motif oder OPEN LOOK. Es ist natrlich auch mglich, solche XVT-Anwendungsprogramme mit spezifischen Macintosh - , Windows - oder Presentation-Manager - (OS/2) Bibliotheken zu linken und so Programme zu erzeugen, die unter den jeweiligen grafischen Systemen dieser Maschinen laufen. 10. Was sind Intrinsics und Widgets ? Manche Toolkits sind als eine kompakte Bibliothek verfgbar, aber es gibt auch welche, die konzeptionell in zwei Teile geteilt sind. Der eine Teil ist dabei die s.g. Intrinsic-Bibliothek und der andere Teil ist die Widget-Bibliothek. Widgets sind abstrakte Datenobjekte, wie z.B. Mausknpfe oder Rollbalken. Ein X-Client kann nun sehr einfach aus einer Menge von Widgets zusammengesetzt werden. Der X-Client hat dabei keine Mglichkeit, auf ein bestimmtes Widget zuzugreifen und es zu verndern. Er hat nur die Mglichkeit, das allgemeine Aussehen eines Widgets zu ndern, wie z.B. die Farbe oder evtl. Inschriften u.. . Das allgemeine Aussehen solcher Widgets wird durch das Toolkit festgelegt. Ŀ X-Client Ŀ Ŀ Widget- Intrinsics Bibliothek Ŀ Xlib Eine Widget-Bibliothek nutzt sowohl Aufrufe in der Xlib als auch in der Intrinsics-Bibliothek. Eine Intrinsics-Bibliothek stellt ein objektorientiertes Grundgerst dar, auf dem dann eine Widget-Bibliothek beruht. Sie bearbeitet die Erzeugung, Beseitung und gesamte Behandlung von Widgets einschlielich dem Bearbeiten von Nachrichten und eingetretenen Ereignissen. Es ist auch mglich, da ein X-Client direkt auf die Intrinsics-Bibliothek zugreift, oder natrlich auch die Xlib. Das Athena, das OSF/Motif und das Xol-Toolkit bestehen jeweils aus einer Widget- und einer Intrinsics-Bibliothek. OSF/Motif und Xol benutzt dabei eine modifizierte Form der Intrinsics-Bibliothek vom Athena-Toolkit, der Xt. Es gibt X-Clients, die nur auf Xt-Intrinsics und die Xlib zugreifen. Solche Anwendungsprogramme kommen dann ohne eine Widget-Bibliothek aus, da ihre abstrakten Datentypen (Widgets) mit Hilfe det Xt-Bibliothek selbst verwalten. Dadurch ist es solchen Anwendungen auch mglich, ihr Aussehen selbst zu bestimmen. Das erfordert zwar einen erhhten Aufwand fr die Programmierer, aber durch die objektorientierten Funktionen der Xt-Bibliothek wird ein Maximum an Untersttzung gegeben. Ŀ X-Client Ŀ Xt- Intrinsics Ŀ Xlib 11. Wie ist der Stand der Dinge ? Das MIT realisiert zusammen mit einer Firmenvereinigung, dem X-Konsortium, das ein Interesse an der Verbreitung des X-WINDOW-SYSTEM hat, die Verbreitung von Bndern, die die Xlib, Xt-Bibliotheken, einen X-Server und einige X-Clients als Beispiel enthalten. Auf geanu diesem Band basieren alle anderen X-Produkte und Toolkits. Momentan ist die Release 11, Revision, auch bekannt als X11R4 die aktuellste Version. 12. Zusammenfassung der besprochenen Toolkits : Toolkit Ursprung Programmier- Grafik- schnittstelle schnittstelle Athena MIT Xt einfach OSF/Motif OSF angepates Xt OSF/Motif Xol AT&T angepates Xt OPEN LOOK Xview Sun SunView OPEN LOOK XVT XVT XVT verschieden