dale@amiga.UUCP (02/19/87)
We do not discourage people from copying and redistributing the include files, however we reserve the right to be called keeper of the master include files to which all changes and updates are made. We do discourage people editing the include files except for removing comments. If you are rewriting the include files for another language, please be especially careful during the translation since that is easy place to introduce bugs that will cause people sleepless nights. Dale Luck of Commodore-Amiga, Inc.
chas@gtss.UUCP (02/19/87)
In article <1627@amiga.amiga.UUCP> dale@amiga.UUCP (Dale Luck) writes: >We do not discourage people from copying and redistributing the include >files, however we reserve the right to be called keeper of the master >include files to which all changes and updates are made. Great! Then do you object to people copying and redistributing the autodocs my Enhancer documentation keeps referring to? This line for 2.11 news This line for 2.11 news
dillon@CORY.BERKELEY.EDU.UUCP (02/19/87)
If you are indeed translating include files, I suggest you write a program to do it (if you havn't already!). Doing translation by hand almost always introduces errors. By having a program do it, at least all the errors will be the same and easily traceable. -Matt
phils@tekigm2.UUCP (02/19/87)
In article <1627@amiga.amiga.UUCP> dale@amiga.UUCP (Dale Luck) writes: >.... > We do discourage >people editing the include files except for removing comments. >.... >Dale Luck >of Commodore-Amiga, Inc. One minor comment here: Manx vs. Lattice, int vs. long. Maybe I needn't say more, but I will. Structures declared in the include files as having elements which are declared as type "int" will have to be changed to "long" for the Manx compiler. I would have to assume that this is included in what you refer to as "editing" the include files, but it is essential nevertheless. Soap box time: These days, I don't know of many (any?) machines for which a "long" is not 32 bits and a "short" is not 16 bits. Personally, I avoid the use of the "int" type wherever possible, and use one of the more descriptive declarations. This even helps in moving code to such machines as pee-cees (argh). -- ------------------------------------------------------------------------------- Phil Staub tektronix!tekigm!phils (206) 253-5634 Tektronix, Inc., ISI Engineering P.O.Box 3500, M/S C1-904, Vancouver, Washington 98668
tenney@well.UUCP (02/20/87)
In article <1627@amiga.amiga.UUCP> dale@amiga.UUCP (Dale Luck) writes: >We do not discourage people from copying and redistributing the include >files, however we reserve the right to be called keeper of the master >include files to which all changes and updates are made. For reference, this is not what C-A's policy has always been. A year and a half or two ago, the management at Los Gatos had a very different view. I had wanted to release the RKM interface for the public domain MVP-FORTH along with a conversion of the include files into FORTH. At that time I was told that it could only be done if I agreed to pay a royalty of "something less than $10 per copy". That ended that, and the RKM interface never got released! It was also suggested that you write a conversion program and distribute that instead of hand-converted include files. That is a noble (and wise) goal, but that is not always possible. -- Glenn Tenney UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY As Alphonso Bodoya would say... (tnx boulton) Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!
mikeb@cbmvax.UUCP (02/21/87)
Keywords:includes The Amiga Includes and their derivatives are all copyrighted property of Commodore-Amiga Inc. They are not public domain and not freely distributable. Their accuracy directly affects the performance of software produced for the Amiga. To insure the best possible control over these files we have not authorized their general circulation other than under our control. That being said, their existance is not confidential. We encourage publication and dissemination of information about their use that does not include copies of the actual files. Because the files themselves are subject to change over time, we cannot allow specific values to be quoted. You can however talk about how to find specific values. You can create tools for utilizing our files. You can even restructure them for your own needs if that is appropriate. But you cannot distribute copies of the Includes in any form. The good news is the latest 1.2 Include files are readily available from: Commodore Business Machines Amiga Technical Support Attn: Kim Montgomery 1200 Wilson Drive West Chester, Pa. 19380 Order the Native Developer Update Price $20. Michael C. Brenner Vice President, Software
fnf@mcdsun.UUCP (02/21/87)
In article <1494@tekigm2.TEK.COM> phils@tekigm2.UUCP (Philip E Staub) writes: >Structures declared in the include files as having elements which are >declared as type "int" will have to be changed to "long" for the Manx >compiler. I would have to assume that this is included in what you refer to >as "editing" the include files, but it is essential nevertheless. Actually, given that these declarations represent fixed length integral quantities that are essentially "cast in concrete" and are part of the fixed hardware (ROM) environment, they should be declared as int32 or int16 as appropriate, with a single compiler typedef taking care of the mapping to a type supported by whatever random C compiler. In general, my experiences over the last 16 months with existing code, lint, and two compilers (Manx and Lattice) have convinced me that the entire object typing situation on the Amiga is a total disaster. It is definately not helped by the split personality of part of the system software being done in BCPL. If someone with extensive experience in portability and use of lint had been working on the project from its earliest days, I suspect we would not be suffering the current problems. Sigh. -Fred -- =========================================================================== Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA {seismo!noao!mcdsun,hplabs!well}!fnf (602) 438-5976 ===========================================================================
cg@myrias.UUCP (03/02/87)
In article <1448@cbmvax.cbmvax.cbm.UUCP>, mikeb@cbmvax.cbm.UUCP (Mike Brenner SW) writes: > > The Amiga Includes and their derivatives are all copyrighted property > of Commodore-Amiga Inc. They are not public domain and not freely > distributable. Their accuracy directly affects the performance of software > produced for the Amiga. > > To insure the best possible control over these files we have not authorized > their general circulation other than under our control. > > That being said, their existance is not confidential. We encourage publication > and dissemination of information about their use that does not include > copies of the actual files. Because the files themselves are subject to > change over time, we cannot allow specific values to be quoted. You can > however talk about how to find specific values. You can create tools for > utilizing our files. You can even restructure them for your own needs if > that is appropriate. But you cannot distribute copies of the Includes in any > form. > > The good news is the latest 1.2 Include files are readily available from: > > Commodore Business Machines > Amiga Technical Support > Attn: Kim Montgomery > 1200 Wilson Drive > West Chester, Pa. 19380 > > Order the Native Developer Update > Price $20. > > > Michael C. Brenner > Vice President, Software Hmm, this is, er, interesting. We're not allowed to give out copies of the full Amiga C include files. I can see some sense in this. As a programmer who doesn't want erroneous copies of his work floating around, and who wants to remain master of the definition of some of that work, I have some sympathy for the point of view. However... I'm still not sure if this means I can't give out copies of my Draco include files (hopefully I didn't forget to mention last time that my forthcoming shareware compiler isn't a C compiler?). I spent a week or so of pretty solid editing to produce them (usually with the equivalent C include file in another editor window). My includes are closer in spirit to those that are used with TDI's Modula-2 compiler than to the C ones. Producing them automagically from the C files would be VERY difficult. (I DO produce my interface libraries automatically from the .fd files.) I've removed all comments, renamed some fields as required by the language (especially in the intuition ones (I split the big intuition.h into several smaller ones)), used Draco's concept of an unknown type to make all includes files independent, reformatted some to make them smaller, added procedure declarations (with parameter types), etc. I refrained from changing lists of constants into enumerated types as TDI did (although I was sorely tempted!) I also made some more of the bit definitions depend on the bit numbers (found one that was wrong too, but I forget where - perhaps in the Expansion stuff?) So anyway, I'll ask again. Can I legally put my Draco include files (derived indirectly from the copyrighted C include files) on a shareware distribution? Keep in mind that it's unlikely that Commodore would add my includes to their disk set so that people can buy them, and that my includes can't be automatically produced from the C includes. Also keep in mind that the TDI files seem to contain only a TDI (and Modula Corporation) copyright. Also that if you forbid this, you are effectively killing any possibility of a useful shareware or freeware compiler for the Amiga. Again, I apologize for posting this, but I suspect a number of people would be interested in any replies. Chris Gray (ubc-vision,sask,ihnp4)!alberta!myrias!cg
hatcher@INGRES.BERKELEY.EDU.UUCP (03/04/87)
In message <489@myrias.UUCP>, Chris Gray writes:
Summary: I'm asking again if I can include derived include files on a
shareware distribution.
I corresponded briefly with Michael Brenner (VP of S/W at CBM) on this
topic when you first posted. He replied that the thing to do is contact
them and get licensed, like Lattice and Manx have.
Rather than posting and reposting your question, the thing to do is mail
directly to Mr. Brenner asking him about the licensing procedure, and
if possible, get thee licensed.
It should be easy; why would they want to restrict software development?
If they are unreasonable about it, please post a message about that.
Actually, please post your results in any case.
Dougmikeb@cbmvax.UUCP (03/04/87)
In article <489@myrias.UUCP> cg@myrias.UUCP (Chris Gray) writes: >In article <1448@cbmvax.cbmvax.cbm.UUCP>, mikeb@cbmvax.cbm.UUCP (Mike Brenner SW) writes: >> >> The Amiga Includes and their derivatives are all copyrighted property >> of Commodore-Amiga Inc. They are not public domain and not freely >> distributable. Their accuracy directly affects the performance of software >> produced for the Amiga. >> >> To insure the best possible control over these files we have not authorized >> their general circulation other than under our control. > >So anyway, I'll ask again. Can I legally put my Draco include files (derived >indirectly from the copyrighted C include files) on a shareware distribution? > >if you forbid this, you are effectively killing any possibility of a useful >shareware or freeware compiler for the Amiga. > >Again, I apologize for posting this, but I suspect a number of people would >be interested in any replies. > > Chris Gray (ubc-vision,sask,ihnp4)!alberta!myrias!cg Chris, You appear to have a valid reason to redistribute include files. Please contact Dave Street, Manager of Commodore-Amiga Technical Support regarding a limited distribution license for the includes. You will need to commit to keeping your versions up to date and making the updates available in the same manner you distributed the original copies. Send Dave a written request including a copy of your compiler and the modified Includes as you would expect to release them. Michael C. Brenner - rutgers!cbmvax!mikeb
fnf@fishpond.UUCP (Fred Fish) (04/08/88)
In article <6009@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >The Manx functions.h is wrong. ConsoleDevice is not a function, it >is a library base pointer for the console.device. It is simply ludicrous that after two and half years, we STILL have confusion about what constitutes an "official" set of include files, what their contents should be, and what the return type and argument types are for the standard library functions. It is too bad that someone with lots of experience in a full C development environment and use of lint, was not available to sort out all the inconsistencies and ambiguities early in the development cycle. When I first got a copy of Amiga Lint in early 1986, I tried to come up with a "definitive lint library" for the Amiga, based on three different sets of include files (C-A Developer set, Manx set, Lattice set), from the C-A documentation, and from various third party manuals. I finally gave it up as hopeless. Given the enormous volume of C source now available for the Amiga, it is probably impractical now anyway, as any reasonable sized program would likely give hundreds or thousands of type violations even if we could agree on the specification of each library function. Sigh. -Fred ><> -- # Fred Fish hao!noao!mcdsun!fishpond!fnf (602) 921-1113 # Ye Olde Fishpond, 1346 West 10th Place, Tempe, AZ 85281 USA
page@swan.ulowell.edu (Bob Page) (04/10/88)
It still can (should) be done. The RKMs are being revised, which means the autodocs can get touched too. How about: FooBar -- Attempt to Bar a section of Foo Usage: #include <exec/types.h> #include <exec/memory.h> #include <libraries/foo.h> struct Foo *FooBar(buf, siz, flags) a1 a0 d0 d1 UBYTE *buf; /* pointer to data area */ USHORT siz; /* size of data area */ ULONG flags; /* bar-related operation flags */ ...etc. Most *NIX man pages are like this. Easy to understand, no? ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page