From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 25 Nov 93 09:13:06 EST Subject: Linux-Development Digest #260 Linux-Development Digest #260, Volume #1 Thu, 25 Nov 93 09:13:06 EST Contents: special hardware driver needed (Andreas Kugel) SPecial hardware driver needed (Andreas Kugel) Re: corewar (Pedro Pimentel de Figueiredo) Re: WANTED: COBOL compiler Re: WANTED: COBOL compiler (Thomas James Jones) Re: Creeping featuritis (post --rant --flame) (Kjetil Torgrim Homme) Re: Don't use Motif for free sw: it now requires runtime royalties! (Matthew Roderick) Re: Free Software and Motif (was: Re: Don't use Motif for free sw:...) (Mike Hopkirk) smail conf/os file for linux (Chris Royle) Attn: C++ developers and Linux package developers (H.J. Lu) Linux Modula-2 Interfaces (Simon Johnston) ---------------------------------------------------------------------------- From: kugel@mp-sun6informatik.uni-mannheim.de (Andreas Kugel) Subject: special hardware driver needed Date: 25 Nov 1993 08:10:19 GMT Reply-To: kugel@mp-sun6informatik.uni-mannheim.de (Andreas Kugel) Hi. We have an interface card to connect an ibmpc to a VME bus as master cpu. the task is to write some kind of driver which allows to map some megabytes of VME memory into the pc address space. in addition the driver must compensate for the quite mean hardware which splits longword (32bit) access into two 16bit accesses to be performed by the pc. furthermore the VME interface supplies only 64k of continous memory - and this 64k page serves both for data memory and control data accesses. this functions are separated via a control register in the i/o address space. the easyest way i can think of is to have a little kernel extension which provides a pointer to a (for example) 128 MByte large virtual VME address space. every access to this virtual VME memory should lead to an exeption from which the real VME address is loaded to the interface and the two 16bit accesses are assembled to one 32 bit access (or vice versa). maybe the method to do a mapping to /dev/zero or the shared memory interface is helpful, but i am not an expert on these functions yet. the main problem is, that we have to get a soltuion in a very short time, because our usual system (os9) broke and the new one will not arrive before next year. so every hint from you quick hack or highly sophisticated function will be appreciated. thanks, andreas ------------------------------ From: kugel@mp-sun6informatik.uni-mannheim.de (Andreas Kugel) Subject: SPecial hardware driver needed Date: 25 Nov 1993 08:12:29 GMT Reply-To: kugel@mp-sun6informatik.uni-mannheim.de (Andreas Kugel) Hi. We have an interface card to connect an ibmpc to a VME bus as master cpu. the task is to write some kind of driver which allows to map some megabytes of VME memory into the pc address space. in addition the driver must compensate for the quite mean hardware which splits longword (32bit) access into two 16bit accesses to be performed by the pc. furthermore the VME interface supplies only 64k of continous memory - and this 64k page serves both for data memory and control data accesses. this functions are separated via a control register in the i/o address space. the easyest way i can think of is to have a little kernel extension which provides a pointer to a (for example) 128 MByte large virtual VME address space. every access to this virtual VME memory should lead to an exeption from which the real VME address is loaded to the interface and the two 16bit accesses are assembled to one 32 bit access (or vice versa). maybe the method to do a mapping to /dev/zero or the shared memory interface is helpful, but i am not an expert on these functions yet. the main problem is, that we have to get a soltuion in a very short time, because our usual system (os9) broke and the new one will not arrive before next year. so every hint from you quick hack or highly sophisticated function will be appreciated. thanks, andreas ------------------------------ From: ppf@almacus.fct.unl.pt (Pedro Pimentel de Figueiredo) Subject: Re: corewar Date: Thu, 25 Nov 1993 00:56:19 GMT Estes estranjas estao marados da cabeca!? Bute falar em portuga! ------------------------------ Crossposted-To: comp.os.linux.help From: zzassgl@gl.mcc.ac.uk () Subject: Re: WANTED: COBOL compiler Date: Thu, 25 Nov 1993 08:54:59 GMT gostling delano javier andres (jgostlin@isluga.puc.cl) wrote: : (zzassgl@gl.mcc.ac.uk) wrote: : : Nick Hilliard (nick@quay.ie) wrote: : : > [Book against Pascal] : : : : It may be a ``devastating attack on the deficiencies of *an old standard* : : Pascal''. It says nothing about modern Pascal implementations - and he : : particularly mentions how his critisism is restricted to unextended Pascal, : : a language that almost nobody uses today. : That's exactly what's being said about pascal. To make it worthwhile, you must : use non-standard implementations, and that means a BIG decrease in portability. But portability to what? If you write a Windows application in Borland Pascal your major portability problem is Windows not the Pascal implementation. If you write a curses based program the major portability problem is the available curses library not the C compiler. The implied thought behind all this is that C code is in some way inherently more portable than code written in other languages. In my experience this is not true as demonstrated by the huge numbers of #ifdefs in the popular packages. Portability covers many more aspects of program design than just the few trival changes in language syntax and contents of run-time libraries -- all of which will be detected for you by a half decent compiler. -- Geoff. Lane. zzassgl@gl.mcc.ac.uk or zzassgl@uts.mcc.ac.uk UTS Sys Admin,Manchester Computing Centre, Oxford Rd, Manchester, M13 9PL, UK I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work. -- Gallagher ------------------------------ Crossposted-To: comp.os.linux.help From: tom@cs.su.oz.au (Thomas James Jones) Subject: Re: WANTED: COBOL compiler Reply-To: tom@cs.su.oz.au Date: Thu, 25 Nov 1993 09:44:41 GMT In article <1993Nov24.210334.5272@tolten.puc.cl>, jgostlin@isluga.puc.cl (gostling delano javier andres) writes: |> (zzassgl@gl.mcc.ac.uk) wrote: |> : Nick Hilliard (nick@quay.ie) wrote: |> : > [Book against Pascal] |> : |> : It may be a ``devastating attack on the deficiencies of *an old standard* |> : Pascal''. It says nothing about modern Pascal implementations - and he |> : particularly mentions how his critisism is restricted to unextended Pascal, |> : a language that almost nobody uses today. |> That's exactly what's being said about pascal. To make it worthwhile, you must |> use non-standard implementations, and that means a BIG decrease in portability. |> Yep it does. But beyond that Ritchie's paper is a worthless attack on something that nobody uses. If portability really existed then nobody would need to 'port' anything anyhow. |> -Javier Gostling D. -- tom --------------------------------------------------------------- Thomas J. Jones | PHONE : +61 2 692-3788 | Office : G6a Basser Department of Computer Science, Sydney University --------------------------------------------------------------- ------------------------------ From: kjetilho@ifi.uio.no (Kjetil Torgrim Homme) Crossposted-To: gnu.misc.discuss Subject: Re: Creeping featuritis (post --rant --flame) Date: 25 Nov 1993 11:13:35 +0100 Richard Brooksby: > My complaint is that GNU is a chance to make things better, not > worse. All these GNU tools are making their way into our lives in > one way or another, and yet they are repeating the same basic design > mistakes. I think the GNU project is more than happy to adopt new utilities which work in new and exciting ways. I just happen to think that GNU utilities are useless if they can't serve as drop-in replacements. Most people use GNU utilities _because_ they have more features, less restrictions (which mean they use more disc and RAM) and often run a lot faster due to more special-case code. You may continue to live in V7, but I do prefer a bourne shell with built-in test, even if it is a "design mistake". Kjetil T. ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: csh060@rowan.coventry.ac.uk (Matthew Roderick) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Thu, 25 Nov 1993 10:56:24 GMT In article joe@morton.rain.com (Joe Moss) writes: >ehhchi@maroon.tc.umn.edu (Ed H. Chi) writes: > >>I vote tk/tcl to be the toolkit of the choice. If you have never looked >>at tk/tcl, it is the time NOW. > >Agreed. > Sorry if I sound completely mad and maybe way out of touch but what is tk/tcl (I presum a widget set of sorts) and way's it so good ? Cheers Matt, -- -- Matthew Roderick (csh060@cov.ac.uk) | \ //\ |`. | Have an exrucialingly pleasant day. | \/\//--\|_| | ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: hops@x.co.uk (Mike Hopkirk) Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw:...) Date: Thu, 25 Nov 1993 11:33:29 GMT >>>>> On Wed, 24 Nov 1993 16:59:25 GMT, lendl@cosy.sbg.ac.at (Otmar Lendl) said: ol> Nntp-Posting-Host: orca ol> Keenan Ross wrote: >I just wanted to emphasize this last sentence in Marc Andreessen's post. >This technique seems applicable to all Motif programs and is a good reason >to keep up your academic contacts. > >marca@ncsa.uiuc.edu (Marc Andreessen) writes: >|> distant future; remember, all it really takes is someone with an >|> academic site license for Motif and a Linux box to make a binary >|> everyone can use, or donate us a development system and we'll do >|> it. Darrel Crow OSF/Motif Technology manager just posted a human readable clarification of the Motif 2.0 licensing to the motif-talk mailing list ( If it doesn't get out to the newsgroup I'll see if its ok to repost it ) Following is ( I hope ) a precis of the main points of his posting vis a vis PD/Freely distributed (binary) software( emphasises and errors omissions are mine ). Broardly Payment of royalties are dependant on two things Whether your apps are statically or dynamically linked and what you ship with them. What licensing your Motif Vendor has. ( the interactions of these two get a little confusing ) Some definitions: 'the working definition of a "Runtime Copy" of Motif means any subset of routines from the "libXm" or "libMrm" library files in object code form statically linked within an application program and executable only with that single application. If you use any other portion of Motif or dynamically link these library files in object code form to the application program then you are not using a Runtime Copy of Motif.' 'a royalty bearing copy of Motif' (is) essentially anything that falls outside the "Runtime Copy" definition in the license supplement' 1) If your Vendor or you has Unlimited or Limited distribution rights and you ship only your application code ( e.g. a binary built to *dynamically* link against Motif AND do *not* ship the shared Motif lib ) no royalty is payable to OSF. ( you're not shipping any OSF code and the assuption is that whoever runs your binary must already have a shared lib that they have already paid the royalty for in some form). 2) If your vendor ( or you ) has an Unlimited Distribution License ( which they must have for you to *purchase* the Motif libs off them ) A application linked with a runtime copy of Motif ( i.e. *statically* linked ) can be installed on any system and there is no royalty to OSF. 3) If you ship a Royalty bearing copy of Motif with your app AND you are not a Source Code Licensee of OSF/Motif. AND your supplier is a Full Distribution licensee AND you have licensed a object code copy of motif from them ( i.e the library you are shipping ) you don't pay OSF a royalty ( since your supplier has already done so and its built into the price you paid them for it ) and the app is installable on any machine. 4) If you ship a Royalty bearing copy of Motif with your app AND you are a Full Distribution licensee AND you are shipping INTERNALLY to your org you don't pay a royalty to OSF. OK Now to the Limited Distribution/University Site License ( which seemed to be a loophole ). 1) You have a Limited Distribution or Universty site license and are 'Shipping' A Motif Runtime ( statically linked ) You can only install your app INTERNALLY on systems already licensed for Motif ( licensee pays OSF for license for Motif) If shipped/made available EXTERNALLY you must 'require that the purchaser install the application only on Motif licensed systems. This requirement must be clearly indicated on the application software license and packaging. The Software Developer owes no royalties to OSF themselves, however the end user may be required to obtain a license. This Motif license is the responsibility of the end user of these applications.' 2) You have a Limited Distribution or University site license - for installation/shipping of 'non runtime copies of Motif' - You can only distribute these copies INTERNALLY and a royalty is payable ( probbaly built in /dependant on the payment options seleceted in the licensing with OSF ). So For free distrib of PD, etc software ( and avoidance of royalty payments to OSF ) what can you do ? My understanding is : 1. Ship statically bound binaries if you have University Site or Limited Distrib license you must also *clearly* state that to use this software you ( the user) must already have bought from someone ( A Motif vendor or OSF directly ) the rights to run Motif ( i.e Motif libraries or Source in some form ) on the system you will install it on and that it is your (the users) responsibility to do so. 2. Ship binaries built to be dynamically linked to Motif *without* the Motif shared libraries ( or any part of it ). ol> Please correct me if I'm wrong, but doesn't this lead to the following ol> reasoning: ol> If I write some freeware Motif software and want to distribute ol> the statically linked version freely, I just send the sources ol> to somebody with an academic site license who makes the binaries ol> and puts them onto some ftp-server. With the above disclaimer ol> Or is there a clause in the ol> license that only locally developed software is covered ? Dunno - never seen a Site/Limited Distrib license. Is that clause enforcable anyway ? ol> Anyway, if this is valid, I don't actually need my friend with the ol> license, for the binaries I generate, and those he can generate are ol> probably identical, so nobody can tell who made them. ol> Thus one is inclined to reason that from all free motif apps, which ol> come with source, a freely redistributeable static binary can be made. ol> IMHO the technicallity of actually compiling it at (for example) ol> NCSA is irrelevant. If you got the MOtif on/from a full distrib licensee you can ship statically linked apps, IF you're on one of the other two you can still do so but you MUST have the disclaimer/notification. ol> This leads me to the following suggestion to OSF: ol> Make the distribution of statically linked binaries royality-free, ol> as long as the sources of the application is also distributed with ol> the binary. Why should they ? What you do with your source is your business. To rebuild it you'll need motif libs for which it is fair that they be paid for your use of. For binary distribution you have the out with static linking and (depending on your own Motif licensing ) the installation licensing disclaimer/notification or dynamic linking without providing the Motif shared libs. ol> This policy should not affect commercial software, for I hardly ol> get the sources for them. But it would allow the continuing developement ol> of free software based on Motif. ol> Comments ? For free software you can distribute your source if you want. You can't freely distribute the Motif source. Source distrib isn't a problem. Its binary distribs that they're interfering with. -- Everything disclaimed (including disclaimer) ======< hops@x.co.uk >======< hops@ixi.uucp >======< ...!uunet!ixi!hops >==== Mike Hopkirk ( hops ) | Whenever possible steal code. IXI Ltd ! Tom Duffy. Bell Labs ------------------------------ From: Chris Royle Subject: smail conf/os file for linux Date: Thu, 25 Nov 1993 11:25:26 GMT For various reasons, I have to rebuild smail for linux. However, every time I do a make depend, the process throws out tons of "X_CC_X: unknown command" errors. I have tried to correct this, but failed. Someone somewhere must have the conf/os file and any other settings required to build smail correctly. For those who are interested, my linux box is about to be used for mail within the ac.uk domain, which as uk people will know has fairly strict guidelines. I have to apply a bindlib patch to smail to make it conform to these guidelines better. (Replies by mail preferred) CHris. -- Chris Royle "The man with a moustache" Managing Director Currently in residence at Cambridge Objectronix Limited c@royle.org Leeds, UK Tel. +44 850 668151 car1002@hermes.cam.ac.uk ------------------------------ Crossposted-To: comp.os.linux.misc From: hjl@nynexst.com (H.J. Lu) Subject: Attn: C++ developers and Linux package developers Date: Thu, 25 Nov 93 12:57:51 GMT Hi, Folks, If you are a C++ developer or Linux package developer, there are somethings you have to know about the upcoming Linux C library. There will be a major change in the Linux C library in the coming weeks. Starting from the next 4.5.x release of the Linux C library, the C++ supports will be dropped from the Linux C library. The iostream will be moved from libc.a to libg++.a. That means all the C++ binaries linked with the shared libc 4.x.x will be broken. If you are a C++ developer or Linux package developer, you have to relink/recompile all the binaries written in C++ when libc 4.5.x and libg++ 2.5.x are released. The new shared C library will be binary compatible with all the binaries written in C linked with the shared libc 4.x.x. Besides that, /usr/lib/lbgcc.* have to be removed when libc 4.5.x is out. Right now, we are testing the new libc 4.5.2. It looks very good. You can join the GCC channel on the Linux mailing list if you want to participate the alpha/beta testing. BTW, don't use libg++ 2.5.1. Please wait for the next release. I hope it will include my fixes without which you will get core dump. Thanks for your attention. -- H.J. Lu The Linux C library maintainer ------------------------------ From: skj@oasis.icl.co.uk (Simon Johnston) Subject: Linux Modula-2 Interfaces Date: Thu, 25 Nov 1993 13:20:04 GMT I am producing a set of Modula-2 interfaces to the Linux run time libraries and have named them LM2I. So far I have the following, please if you feel that I have left something out, please let me know soon. Linux Modula-2 Interfaces (LM2I) 0.0.1 Interface modules: ASCII.md -> gives meaning to a number of special ASCII characters. paths.md -> general paths of use. types.md -> unix types (some cross over with SysLib). pwd.md -> access to /etc/passwd file. grp.md -> access to /etc/group file. shadow.md -> access to shadow password suite. in.md -> netinet defines. netdb.md -> access to get/set host/domain etc functions. socket.md -> the socket API. regex.md -> regular expressions. stdlib.md -> process handling/random numbers etc. Misc: tst.mi -> a test program which also serves to compile whole library. MODULE Sig; FROM ICL IMPORT StdDisclaimer; FROM Interests IMPORT Modula2, Modula3, Linux, OS2; BEGIN (* ------------------------------------------------------------------------. |Simon K. Johnston - Development Engineer |ICL Retail Systems | |------------------------------------------------------|3/4 Willoughby Road| |Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk |Bracknell, Berks | |Telephone : +44 (0)344 476320 Fax: +44 (0)344 476084|United Kingdom | |Internal : 7621 6320 OP Mail: S.K.Johnston@BRA0801|RG12 8TJ | `------------------------------------------------------------------------ *) END Sig. ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************