chem194@csc.canterbury.ac.nz (John Davis) (06/02/91)
In article <1603@glyph.kingston.ny.us>, ahh@glyph.kingston.ny.us (Andy Heffernan) writes: > In article <21956@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: >>In article <1601@glyph.kingston.ny.us> ahh@glyph.UUCP (Andy Heffernan) writes: >>>In article <22877@shlump.lkg.dec.com> plouff@kali.enet.dec.com (Wes Plouff) writes: > [...] >>>Can heavier stock paper be far behind? >> >>Look carefully at the page count. If we go to heavier stock the books >>will end up a foot thick. Also remember that there is a direct >>correlation between paper quality and retail price. How much do you >>want to pay for these? > > Oh, yes, I realize very well that good stuff comes at a price. > That's why I bought a 3000UX instead of a 500. > Regarding your last question, I'd pay $50-60 for better quality paper, > or better yet, loose-leaf with binders. But that's me. what I'd _really_ like to see if the WHOLE RKM set released on disk ( as opposed to just the autodocs ). The Unix box I use has all it's manuals on a single CDROM, and being able to get the machine to search for info (as opposed to thumbing thru often incomplete indexes on paper manuals) is a real god-send... ----------------------------------------------------------- | o John Davis - CHEM194@csc.canterbury.ac.nz o | | o (Depart)mental Programmer,Chemistry Department o | | o University of Canterbury, Christchurch, New Zealand o |
es1@cunixb.cc.columbia.edu (Ethan Solomita) (06/02/91)
In article <1991Jun2.121530.942@csc.canterbury.ac.nz> chem194@csc.canterbury.ac.nz (John Davis) writes: > >what I'd _really_ like to see if the WHOLE RKM set released on >disk ( as opposed to just the autodocs ). The Unix box I use has >all it's manuals on a single CDROM, and being able to get the >machine to search for info (as opposed to thumbing thru often incomplete >indexes on paper manuals) is a real god-send... > Hmm. Very interesting idea. CD-ROMs are becoming more and more widespread. If CATS released the entirety of the series on CD ROM, perhaps charged $150 or so for the CD, and included programs to automate interfacing with the Amiga via word processing, printer output, etc., I think CBM would have a serious product, one that would improve efficiency. If, for example, from CED I press a function key that signifies the autodocs, type a keywork, and then up pops a window which I can cut-and-paste from... > >----------------------------------------------------------- >| o John Davis - CHEM194@csc.canterbury.ac.nz o | >| o (Depart)mental Programmer,Chemistry Department o | >| o University of Canterbury, Christchurch, New Zealand o | Now the world has gone to bed, Now I lay me down to sleep, Darkness won't engulf my head, Try to count electric sheep, I can see by infrared, Sweet dream wishes you can keep, How I hate the night. How I hate the night. -- Marvin
plouff@kali.enet.dec.com (Wes Plouff) (06/02/91)
In article <1991Jun2.121530.942@csc.canterbury.ac.nz>, chem194@csc.canterbury.ac.nz (John Davis) writes... >In article <1603@glyph.kingston.ny.us>, ahh@glyph.kingston.ny.us (Andy Heffernan) writes: >> In article <21956@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: >>>In article <1601@glyph.kingston.ny.us> ahh@glyph.UUCP (Andy Heffernan) writes: >>>>In article <22877@shlump.lkg.dec.com> plouff@kali.enet.dec.com (Wes Plouff) writes: >> [...] Whoa! Too many levels of references here. I was the original poster of this thread, but readers may recall that the only opinion offered there was regarding the timeliness of technical publishers. Leave me out of this heavier paper debate, please! -- Wes Plouff plouff@kali.enet.dec.com
chem194@csc.canterbury.ac.nz (John Davis) (06/03/91)
In article <1991Jun2.003143.21316@cunixf.cc.columbia.edu>, es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > Hmm. Very interesting idea. CD-ROMs are becoming more and > more widespread. If CATS released the entirety of the series on > CD ROM, perhaps charged $150 or so for the CD, and included > programs to automate interfacing with the Amiga via word > processing, printer output, etc., I think CBM would have a > serious product, one that would improve efficiency. Ideally it should have some form of hypertext front end - makes following the complex interelation of data structures a lot easier (though it does make for a LOT more work in both creating the front end, and in setting up the database). The Unix system I've used has just that (running under X) - the time it saves it really unbelievable. Anyone who brings out something similar on the Amiga would be onto a sure-fire seller (even at $300+ .. it's so convenient people will happily pay serious money for it). The only real problem I see is the agreement Addison Wesley has with CBM for the amiga tech ref series - depending on the limits of the agreement it might mean A-W has sole rights. > If, for example, from CED I press a function key that > signifies the autodocs, type a keywork, and then up pops a window > which I can cut-and-paste from... you can already do that using CED, ARexx and a bit of glue ( in fact I'm certain there's an example of just how to do it in one of the arexx examples dirs on the CED disk). Trouble is it only uses the autodocs - better than nothing, but often you end up having to drag out the full RKMs to clarify the situation... ----------------------------------------------------------- | o John Davis - CHEM194@csc.canterbury.ac.nz o | | o (Depart)mental Programmer,Chemistry Department o | | o University of Canterbury, Christchurch, New Zealand o |
mks@cbmvax.commodore.com (Michael Sinz) (06/03/91)
In article <1991Jun2.121530.942@csc.canterbury.ac.nz> chem194@csc.canterbury.ac.nz (John Davis) writes: >what I'd _really_ like to see if the WHOLE RKM set released on >disk ( as opposed to just the autodocs ). The Unix box I use has >all it's manuals on a single CDROM, and being able to get the >machine to search for info (as opposed to thumbing thru often incomplete >indexes on paper manuals) is a real god-send... Watch out, you may get what you wish for... /----------------------------------------------------------------------\ | /// Michael Sinz - Amiga Software Engineer | | /// Operating System Development Group | | /// BIX: msinz UUNET: rutgers!cbmvax!mks | |\\\/// | | \XX/ "I don't think so" said Ren'e Descartes, then he vanished. | \----------------------------------------------------------------------/
higgin@cbmvax.commodore.com (Paul Higginbottom - CATS) (06/03/91)
In article <1991Jun2.003143.21316@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: $In article <1991Jun2.121530.942@csc.canterbury.ac.nz> chem194@csc.canterbury.ac.nz (John Davis) writes: $> $>what I'd _really_ like to see if the WHOLE RKM set released on $>disk ( as opposed to just the autodocs ). The Unix box I use has $>all it's manuals on a single CDROM, and being able to get the $>machine to search for info (as opposed to thumbing thru often incomplete $>indexes on paper manuals) is a real god-send... $> $ Hmm. Very interesting idea. CD-ROMs are becoming more and $more widespread. If CATS released the entirety of the series on $CD ROM, perhaps charged $150 or so for the CD, and included $programs to automate interfacing with the Amiga via word $processing, printer output, etc., I think CBM would have a $serious product, one that would improve efficiency. $ If, for example, from CED I press a function key that $signifies the autodocs, type a keywork, and then up pops a window $which I can cut-and-paste from... We are looking into making this a reality. It is a big job. We're currently experimenting with putting just the includes and autodocs with a nice "hypertext" browse/search front end on it. If this experiment goes well, we could get the whole thing done by early next year. (It will take that long because we haven't finished the 2.0 RKMs yet for one, and we have a Developer's Conference in there, too). If you or anyone you know has experience in putting large reference works onto CD-ROM, and think that you could help us speed up the process, please contact me or Dan Baker (dan@cbmvax...) who is in charge of CATS documentation. Regards, Paul Higginbottom Manager, Developer Support, CATS. -- Paul Higginbottom - working for, uucp: {uunet|pyramid|rutgers}!cbmvax!higgin but not officially representing: domain: higgin@cbmvax.commodore.com Commodore, CATS Group
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (06/04/91)
From article <1991Jun2.121530.942@csc.canterbury.ac.nz>, by chem194@csc.canterbury.ac.nz (John Davis): > what I'd _really_ like to see if the WHOLE RKM set released on > disk ( as opposed to just the autodocs ). The Unix box I use has > all it's manuals on a single CDROM, and being able to get the > machine to search for info (as opposed to thumbing thru often incomplete > indexes on paper manuals) is a real god-send... I disagree. Sure, having the index on disk is a great help. But looking around my chair here (I'm in the middle of a project), there's six different manuals open to pages that I'm referencing, and combs, pencils, and Post-It notes stuck in other places that I'm referencing. I simply cannot do that on my computer screen, because it isn't *BIG* enough (my floor is a lot bigger than my 1084 :-). I haven't found a text editor yet that's good at quickly accessing a "marked" location without requiring you to remember "mark #1, or mark #45?"... closest would probably be "tags" or DME's "refs" facility. Here, it's easy to say "Well, that yellow comb is intuition.h, because that blue pen before it is console.h". I've used a "C" compiler that had the documentation on disk. I swiftly gave up trying to reference it, and in disgust went to the bookstore to buy a third-party manual for it. (Hint -- Microsoft product). I don't really relish the prospect of spending $150 for the privilige of undergoing that experience again! Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/04/91)
In article <1991Jun3.140107.945@csc.canterbury.ac.nz> chem194@csc.canterbury.ac.nz (John Davis) writes: >In article <1991Jun2.003143.21316@cunixf.cc.columbia.edu>, es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > >> Hmm. Very interesting idea. CD-ROMs are becoming more and >> more widespread. If CATS released the entirety of the series on >> CD ROM, perhaps charged $150 or so for the CD, and included >> programs to automate interfacing with the Amiga via word >> processing, printer output, etc., I think CBM would have a >> serious product, one that would improve efficiency. > >Ideally it should have some form of hypertext front end - >makes following the complex interelation of data structures >a lot easier (though it does make for a LOT more work in >both creating the front end, and in setting up the database). > >The Unix system I've used has just that (running under X) - the >time it saves it really unbelievable. Anyone who brings out something >similar on the Amiga would be onto a sure-fire seller (even at $300+ .. >it's so convenient people will happily pay serious money for it). > >The only real problem I see is the agreement Addison Wesley has with CBM >for the amiga tech ref series - depending on the limits of the agreement >it might mean A-W has sole rights. I'd actually like to see CBM put the SOURCE CODE to the OS on the disk as well. It would be a good way to understand the inner workings of each routine that one might call. As well, maybe we'd see a Berkeley ROM Kernel (a la BSD Unix) :) -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
ahh@glyph.kingston.ny.us (Andy Heffernan) (06/04/91)
In article <23099@shlump.lkg.dec.com> plouff@kali.enet.dec.com (Wes Plouff) writes: -> ->In article <1991Jun2.121530.942@csc.canterbury.ac.nz>, chem194@csc.canterbury.ac.nz (John Davis) writes... ->>In article <1603@glyph.kingston.ny.us>, ahh@glyph.kingston.ny.us (Andy Heffernan) writes: ->>> In article <21956@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: ->>>>In article <1601@glyph.kingston.ny.us> ahh@glyph.UUCP (Andy Heffernan) writes: ->>>>>In article <22877@shlump.lkg.dec.com> plouff@kali.enet.dec.com (Wes Plouff) writes: ->>> [...] ->Whoa! Too many levels of references here. I was the original poster of ->this thread, but readers may recall that the only opinion offered there ->was regarding the timeliness of technical publishers. Leave me out of ->this heavier paper debate, please! It is too late. We have you in our clutches. Mwaa ha haaa. -- ------------------------------------------------------------------------- Andy Heffernan 文字 uunet!glyph!ahh
manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) (06/06/91)
In article <mykes.3136@amiga0.SF-Bay.ORG>, mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > In article <1991Jun3.140107.945@csc.canterbury.ac.nz> chem194@csc.canterbury.ac.nz (John Davis) writes: >>In article <1991Jun2.003143.21316@cunixf.cc.columbia.edu>, es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: >> >> [Fascinating stuff deleted] > I'd actually like to see CBM put the SOURCE CODE to the OS on the disk > as well. It would be a good way to understand the inner workings of > each routine that one might call. As well, maybe we'd see a Berkeley > ROM Kernel (a la BSD Unix) :) I am glad that you put a smiley on the end. The last thing we need is a public domain version of the kernal. In fact, I am against Commodore releasing the SOURCE CODE to the operating system. That would be a complete disaster. ARP was bad enough, a public domain kernal... ack!!! > > -- > **************************************************** > * I want games that look like Shadow of the Beast * > * but play like Leisure Suit Larry. * > **************************************************** -mark= +--------+ ================================================== | ¥/ | Mark D. Manes "The Most lopsided deal since ..." | /¥ ¥/ | manes@vger.nsu.edu | / | (804) 683-2532 "Make up your own mind! - AMIGA" +--------+ ================================================== "I protest Captain! I am not a merry man!" - Lt. Worf
DXB132@psuvm.psu.edu (06/07/91)
In article <1057.284e0dbf@vger.nsu.edu>, manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) says: >> I'd actually like to see CBM put the SOURCE CODE to the OS on the disk >> as well. It would be a good way to understand the inner workings of >> each routine that one might call. As well, maybe we'd see a Berkeley >> ROM Kernel (a la BSD Unix) :) >I am glad that you put a smiley on the end. The last thing we need is >a public domain version of the kernal. In fact, I am against Commodore >releasing the SOURCE CODE to the operating system. That would be a >complete disaster. >ARP was bad enough, a public domain kernal... ack!!! Oh, come on, where's your hacker spirit? I think the Amiga community (especially here in the US) could use a little. (Actually a lot!) TINAF (This is Not a Flame :-)) -- Dan Babcock
GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) (06/07/91)
>I am glad that you put a smiley on the end. The last thing we need is >apublic domain version of the kernal. In fact, I am against Commodore >releasing the SOURCE CODE to the operating system. That would be a >complete disaster. Please explain what is so bad about releasing the source code ? I don't see your point. >ARP was bad enough, a public domain kernal... ack!!! What's bad about ARP ? In my opinion ARP was a very good thing. Of course I don't need it anymore since I have AmigaOS 2.0, but still... Jorrit Tyberghein
ken@cbmvax.commodore.com (Ken Farinsky - CATS) (06/07/91)
In article <91158.110654GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: >>I am glad that you put a smiley on the end. The last thing we need is >>apublic domain version of the kernal. In fact, I am against Commodore >>releasing the SOURCE CODE to the operating system. That would be a >>complete disaster. > >Please explain what is so bad about releasing the source code ? I >don't see your point. Don't worry, Commodore will never release the source code. We'll do our best to document it, though. Let's concentrate on making killer applications! -- Ken Farinsky - CATS - Commodore Business Machines
saunders@triton.unm.edu (Richard Saunders CIRT) (06/08/91)
In article <22247@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: >In article <91158.110654GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: >>>I am glad that you put a smiley on the end. The last thing we need is >>>apublic domain version of the kernal. In fact, I am against Commodore >>>releasing the SOURCE CODE to the operating system. That would be a >>>complete disaster. >> >>Please explain what is so bad about releasing the source code ? I >>don't see your point. I agree. > >Don't worry, Commodore will never release the source code. We'll do >our best to document it, though. Let's concentrate on making killer >applications! >-- >Ken Farinsky - CATS - Commodore Business Machines That's too bad ... having the source code around for your operating system is extremely useful ... it's instructive (you can see how the "pros" did it), allows you to fix bugs you find immediately, (this is the reason Matt Dillon included the source for his Library in DICE), and is, in a sense, the ultimate documentation for the operating system (manuals always tend to be incomplete/out of date). IMHO, I think it would be nice to have the source for everything I ever used. Why? I like to know how things are done ... Oh well. It's a moot point anyway. * saunders@triton.unm.edu * "This is _NOT_ Mel Torme!" - Top Secret
manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) (06/11/91)
In article <91158.110654GHGAQA4@cc1.kuleuven.ac.be>, GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: >>I am glad that you put a smiley on the end. The last thing we need is >>apublic domain version of the kernal. In fact, I am against Commodore >>releasing the SOURCE CODE to the operating system. That would be a >>complete disaster. > > Please explain what is so bad about releasing the source code ? I > don't see your point. Releasing source code would create a nightmare for Commodore and their dealers. Consider the possibility of a friendly persoon putting out a hacked version of the operating system and it becoming semi-popular. What should Commodore do? Adopt it? How would Commodore support it? Would it still be owned by Commodore? What is a dealer to do when he orders software for the Amiga? Does he make sure it just runs on Commodore's operating system or the more popular 'hacked' AmigaDOS? How can Commodore create new machines? Will Commodore need to get permission from the authors of the hacked operating system to support it? If they don't support it, will Commodore have to put up with tons and tons of messages from usenet saying that they were idiots for not including the 'obvious enhacements' that the hack provided? What we would have is a nice can of worms of which no developer would have a chance of making their software work reliably on all of the amiga computers. I don't need to mention how wonderful this would be for virus writers. If you don't intend to modify the operating system, why release the source code? What would the advantage be for Commodore to release it? Sure I am as interested as the next guy, but I can easily see the dangers, can't you? If knowledge is the reason, you can gleam the knowledge you need to program the Amiga from the RKM's and the tons of source code that is available. > > >>ARP was bad enough, a public domain kernal... ack!!! > > What's bad about ARP ? In my opinion ARP was a very good thing. Of > course I don't need it anymore since I have AmigaOS 2.0, but still... > Without starting up the old Mark vs. Larry Phillips argument again (Whatever happened to Larry anyway?) about ARP. I will say that the intentions of ARP were peaceful, and did produce some nice things, but in my opinion ARP (the command set) did more to hurt the Amiga than it did to help it. I like arp.library, but that is it. > Jorrit Tyberghein -mark= +--------+ ================================================== | ¥/ | Mark D. Manes "The Most lopsided deal since ..." | /¥ ¥/ | manes@vger.nsu.edu | / | (804) 683-2532 "Make up your own mind! - AMIGA" +--------+ ================================================== "I protest Captain! I am not a merry man!" - Lt. Worf
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/11/91)
In article <1062.2853935b@vger.nsu.edu> manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) writes: >In article <91158.110654GHGAQA4@cc1.kuleuven.ac.be>, GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: >>>I am glad that you put a smiley on the end. The last thing we need is >>>apublic domain version of the kernal. In fact, I am against Commodore >>>releasing the SOURCE CODE to the operating system. That would be a >>>complete disaster. >> >> Please explain what is so bad about releasing the source code ? I >> don't see your point. > >Releasing source code would create a nightmare for Commodore and their >dealers. Consider the possibility of a friendly persoon putting out >a hacked version of the operating system and it becoming semi-popular. >What should Commodore do? Adopt it? How would Commodore support it? >Would it still be owned by Commodore? What is a dealer to do when >he orders software for the Amiga? Does he make sure it just runs on >Commodore's operating system or the more popular 'hacked' AmigaDOS? >How can Commodore create new machines? Will Commodore need to get >permission from the authors of the hacked operating system to support >it? If they don't support it, will Commodore have to put up with >tons and tons of messages from usenet saying that they were idiots >for not including the 'obvious enhacements' that the hack provided? > The intent of publishing source code isn't so people can make better versions, although it might be a neat school project :) Ever have a question like, "Does RectFill() use QBlit()?" Well, the answer can be found in the code (or you can bug folks on the net with the question... :) If you buy MacNosy (for the Mac), you can get a wide variety of annotated "sources" for the Mac ROMs (and they've been around for years), yet nobody is selling or hacking on the OS (except AMax :) or selling a variation... The real threat might be that some Macoid might want to put a REAL OS on their computer (or the ST...) and would have a great starting place to port from. It's a moot point, since CBM already has said they won't release the source. (Maybe it's really bad to look at anyway :) -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
andy@cbmvax.commodore.com (Andy Finkel) (06/12/91)
miga0.SF-Bay.ORG> Sender: Reply-To: andy@cbmvax.commodore.com (Andy Finkel) Followup-To: Distribution: Organization: Commodore, West Chester, PA Keywords: In article <mykes.3498@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >The intent of publishing source code isn't so people can make better >versions, although it might be a neat school project :) Ever have >a question like, "Does RectFill() use QBlit()?" Well, the answer can >be found in the code (or you can bug folks on the net with the question... :) Would this argument work with the authors of Populus or Lemmings or SimCity ? I'm curious about each of their techniques and simulation models. Having the source code would help improve my gameplay. Plus, there's probably a few tweaks I could add that would improve those games a bit. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "2.0 is not the answer. 2.0 is the question. Yes is the answer." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
valentin@btr.BTR.COM (Valentin Pepelea valentin@btr.com) (06/12/91)
In article <22342@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: > >>The intent of publishing source code isn't so people can make better >>versions, although it might be a neat school project :) Ever have >>a question like, "Does RectFill() use QBlit()?" Well, the answer can >>be found in the code (or you can bug folks on the net with the question... :) > >Would this argument work with the authors of Populus or Lemmings or >SimCity ? I'm curious about each of their techniques and simulation >models. Having the source code would help improve my gameplay. >Plus, there's probably a few tweaks I could add that would improve those >games a bit. Having the source code of these games is not a necessity to understand how to play, but having the source code to the OS can cut down sharply on the learning curve of how to use some functions. Quite a few companies provide the OS sources to their custommers; Commodore would not be an exception. Any real-time OS for embedded systems is supplied in source code form, including Vrtx, pSOS, OS/9, and others. Ever wondered how come these companies are not afraid of having their work plagiarized? The answer is quite simple, copyrights. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
andy@cbmvax.commodore.com (Andy Finkel) (06/13/91)
In article <3036@public.BTR.COM> valentin@btr.BTR.COM (Valentin Pepelea valentin@btr.com) writes: >In article <22342@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy >Finkel) writes: >Quite a few companies provide the OS sources to their custommers; Commodore >would not be an exception. Any real-time OS for embedded systems is supplied >in source code form, including Vrtx, pSOS, OS/9, and others. Ever wondered >how come these companies are not afraid of having their work plagiarized? >The answer is quite simple, copyrights. Ever hear of "Copyright Unpublished Trade Secrets" ? Apparently not. Those companies that give source code do so with heavy licensing agreements and cost big bucks. It is conceiveable to me that Commodore might do the same, on terms similar to those between AT&T and their commercial licensees. (This isn't to say that it is happening, only that I don't see that its out of the question) Of course, this is quite a different thing from the source being passed around freely! >Valentin andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "2.0 is not the answer. 2.0 is the question. Yes is the answer." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
daveh@cbmvax.commodore.com (Dave Haynie) (06/13/91)
In article <mykes.3498@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <1062.2853935b@vger.nsu.edu> manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) writes: >>In article <91158.110654GHGAQA4@cc1.kuleuven.ac.be>, GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: >>>>I am glad that you put a smiley on the end. The last thing we need is >>>>apublic domain version of the kernal. >>Releasing source code would create a nightmare for Commodore ... >The intent of publishing source code isn't so people can make better >versions, although it might be a neat school project :) Ever have >a question like, "Does RectFill() use QBlit()?" Well, the answer can >be found in the code (or you can bug folks on the net with the question... :) I that actually illustrates one of the dangers of releasing any source code. You should treat every function as a black box, unless told otherwise. While sometimes questions like that are just out of interest, if folks start to depend on HOW functions are implemented, rather than simply on what they do, we're all doomed. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "This is my mistake. Let me make it good." -R.E.M.
boblu@tekgen.BV.TEK.COM (Robert Luneski) (06/13/91)
>-- >andy finkel {uunet|rutgers|amiga}!cbmvax!andy >Commodore-Amiga, Inc. > > "2.0 is not the answer. 2.0 is the question. Yes is the answer." > Wrong, "When, is the question" In our lifetime? It is now in excess of a year since the introduction of the 3000 and there is still no romable code and no sign whatsoever of WB2.0 on A500/A2000. So when WILL we actually see God's gift to operating systems? Bob Luneski boblu@tekgen.BV.TEK.COM
manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) (06/14/91)
In article <3036@public.BTR.COM>, valentin@btr.BTR.COM (Valentin Pepelea valentin@btr.com) writes: > In article <22342@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy > Finkel) writes: >> > Quite a few companies provide the OS sources to their custommers; Commodore > would not be an exception. Any real-time OS for embedded systems is supplied > in source code form, including Vrtx, pSOS, OS/9, and others. Ever wondered > how come these companies are not afraid of having their work plagiarized? > The answer is quite simple, copyrights. > Yes, but all of them that I know of require a large licensing fee and lengthy legal documentation to be signed. I wonder why they bother since the 'copyright' protects them. I find it hard to believe you are trying to say that a 'copyright' is good enough protection. Are you saying that the releasing of the source code would not cause harm? Releasing the source would be like 'putting ones laundry out'. I see no advantage for Commodore to do this. Do you? > Valentin > > > -- > "An operating system without virtual memory Name: Valentin Pepelea > is an operating system without virtue." Phone: (408) 985-1700 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Boy do I disagree with this.. :-) > Usenet: mips!btr!valentin > - Ancient Inca Proverb Internet: valentin@btr.com -mark= +--------+ ================================================== | ¥/ | Mark D. Manes "The Most lopsided deal since ..." | /¥ ¥/ | manes@vger.nsu.edu | / | (804) 683-2532 "Make up your own mind! - AMIGA" +--------+ ================================================== "I protest Captain! I am not a merry man!" - Lt. Worf
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/14/91)
In article <22342@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: >miga0.SF-Bay.ORG> >Sender: >Reply-To: andy@cbmvax.commodore.com (Andy Finkel) >Followup-To: >Distribution: >Organization: Commodore, West Chester, PA >Keywords: > >In article <mykes.3498@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>The intent of publishing source code isn't so people can make better >>versions, although it might be a neat school project :) Ever have >>a question like, "Does RectFill() use QBlit()?" Well, the answer can >>be found in the code (or you can bug folks on the net with the question... :) > >Would this argument work with the authors of Populus or Lemmings or >SimCity ? I'm curious about each of their techniques and simulation >models. Having the source code would help improve my gameplay. >Plus, there's probably a few tweaks I could add that would improve those >games a bit. > andy I don't know how many Amiga Users/programmers NEED to see with the sources to applications (or games), even though it would surely be educational. It would be great to see some of the algorithms to ADPro, for example. The Amiga OS is a COMMON piece of code that EVERY application has the potential to require to function. If DPaint and CygnusEd (to name two programs) required the programmers to have knowledge of the internal workings of Lemmings, then Lemmings source should be made public. In other words, the Amiga OS makes over 400 functions (more under 2.0) public, while Lemmings et al make none public. There is the difference. By the way, I wouldn't mind it if publishers did indeed publish source to their games (after sales diminish, of course). -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
vinsci@nic.funet.fi (Leonard Norrgard) (06/14/91)
In article <3036@public.BTR.COM> valentin@btr.BTR.COM (Valentin Pepelea valentin@btr.com) writes: In article <22342@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: > >>The intent of publishing source code isn't so people can make better >>versions, although it might be a neat school project :) Ever have >>a question like, "Does RectFill() use QBlit()?" Well, the answer can >>be found in the code (or you can bug folks on the net with the question... :) > >Would this argument work with the authors of Populus or Lemmings or >SimCity ? I'm curious about each of their techniques and simulation >models. Having the source code would help improve my gameplay. >Plus, there's probably a few tweaks I could add that would improve those >games a bit. Having the source code of these games is not a necessity to understand how to play, but having the source code to the OS can cut down sharply on the learning curve of how to use some functions. Quite a few companies provide the OS sources to their custommers; Commodore would not be an exception. Any real-time OS for embedded systems is supplied in source code form, including Vrtx, pSOS, OS/9, and others. Ever wondered how come these companies are not afraid of having their work plagiarized? The answer is quite simple, copyrights. Valentin Add VMS from Digital to the list. Now the difference with their source code is that it is clean and readable. Something I've not yet heard about CBM's (cf. the code in the RKM's). If you want the source to VMS, talk to Digital. The last time I checked the entire operating system was available on micro fiche (about 400 of them...). So what do you need it for? Doing to the right thing in systems programming! Of course, here another difference comes up, in that VMS is actually *documented*. Nice, very clean descriptions of each OS/library function, and that documentation was written by *technical writers*, not by the OS designers such as the autodocs are (I suppose, since they are extracted from the OS source code, right?) Now, style isn't everything. Publishing your not all too nice source code is OK. What *may* scare CBM is clones of the OS. Now it has already happened to the PC BIOS, Apples ROMS, and no doubt we will see Amiga clones in the future (provided Amigas continue to be successful). Reverse engineering is of course much simpler if you have source, but: HIDING THE SOURCE DOESN'T PROTECT YOUR OS FROM BEING CLONED. IT SURE DOES HURT YOUR APPLICATION DEVELOPERS. -- Leonard
valentin@public.BTR.COM (Valentin Pepelea) (06/14/91)
In article <22380@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: > >> Ever wondered how come these companies are not afraid of having their work >> plagiarized? The answer is quite simple, copyrights. > >Ever hear of "Copyright Unpublished Trade Secrets" ? >Apparently not. > >Those companies that give source code do so with heavy licensing >agreements and cost big bucks. It is conceiveable to me that >Commodore might do the same, on terms similar to those between >AT&T and their commercial licensees. You are confusing the protections accorded by law to copyright holders and the special licensing agreement that AT&T requires. AT&T, prints at the top of each source code file "This is unpublished source code of AT&T." And instead of depending on the copyright law to protect themselves, they require in their licensing agreements stiff secrecy from their clients. But then, you already knew that. To my knowledge, only AT&T refuses to publish (copyright) their software. Perhaps they are afraid of having their code freely distributed 50 years from now. Perhaps they are forced to keep the source code secret by the DoD. >Of course, this is quite a different thing from the source >being passed around freely! This is not what I suggest. I suggest that you distribute the source code eiter in printed form, like the ROM Kernel Manuals, or on disk, changing a decent fee. ($100?) That constitutes publication. You will then be granted the protection of the law. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
peter@cbmvax.commodore.com (Peter Cherna) (06/14/91)
In article <VINSCI.91Jun14003452@nic.nic.funet.fi> vinsci@nic.funet.fi (Leonard Norrgard) writes: > Now, style isn't everything. Publishing your not all too nice source >code is OK. Style has nothing to do with it. In fact, significant chunks of the OS are in excellent shape, for example Intuition (thanks in large part to Jim Mackraz - hi jimm!) >What *may* scare CBM is clones of the OS. Now it has >already happened to the PC BIOS, Apples ROMS, Apple II ROMs and PC BIOS ROMs are quite trivial compared with the Amiga ROM. >Reverse engineering is of course much simpler if you have >source Reverse engineering is quite illegal if you work from the source. There's nothing reverse about it then. >IT SURE DOES HURT YOUR APPLICATION DEVELOPERS. If you think not having source will hurt application developers, you've not begun to imagine the long-term hurt to users and developers which would be caused by releasing the source. Why? Because there seems to be some confusion that the _implementation_ of the OS is its definition. Nothing could be farther from the truth. The documentation is the definition, and the implementation is subject to change. Seeing the insides of routines will only encourage developers to take advantage of tricks that are not part of the definition and not supportable. It would effectively mean either the end of OS development or a significant down-turn in compatibility with future revs of the OS. We won't allow it, and you shouldn't want it. The funniest part about it is that one of the Usenetters arguing for sources to be released has recently dealt with a bug in code he is responsible for. The problem was code that was depending on Intuition preserving some fields that in the manuals were specifically _defined_ as being trashed. Under 1.3, they just happened to be preserved. Under 2.0, they weren't. Boom. You can't seriously want more of that? Further, Commodore has a very dynamic and accessible support program. Official developer support is affordable and easy to reach. Unofficial support is provided on places like Usenet by CBM employees who aren't required to be here. If you have a question, ask it, instead of asking for the source. And before you ask for the source, be sure you avail yourself of the existing documentation and tools that exist to make your life easier. Do you have the 1.3 RKMs? Do you have the 1.3 autodocs and include files? Do you subscribe to AmigaMail? Are you a registered developer? Do you stay up-to-datewith the Fish Disks and other sources of freely-redistributable stuff? Do you own the good books that are out there? Do you run the validation tools we make available (eg. mungwall, enforcer?) Start there. >-- Leonard Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Gosh, didn't he have anything positive to say at all?"
manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) (06/15/91)
In article <7893@tekgen.BV.TEK.COM>, boblu@tekgen.BV.TEK.COM (Robert Luneski) writes: >>-- >>andy finkel {uunet|rutgers|amiga}!cbmvax!andy >>Commodore-Amiga, Inc. >> >> "2.0 is not the answer. 2.0 is the question. Yes is the answer." >> > > Wrong, "When, is the question" In our lifetime? It is now in excess of > a year since the introduction of the 3000 and there is still no romable > code and no sign whatsoever of WB2.0 on A500/A2000. So when WILL we > actually see God's gift to operating systems? > It runs fine on my A2000... I guess you will have it when 'it's ready'. I hate messages like yours. > Bob Luneski -mark= +--------+ ================================================== | ¥/ | Mark D. Manes "The Most lopsided deal since ..." | /¥ ¥/ | manes@vger.nsu.edu | / | (804) 683-2532 "Make up your own mind! - AMIGA" +--------+ ================================================== "I protest Captain! I am not a merry man!" - Lt. Worf
leh@crane.cis.ufl.edu (Les Hill) (06/15/91)
In article <VINSCI.91Jun14003452@nic.nic.funet.fi>, vinsci@nic.funet.fi (Leonard Norrgard) writes: |> Add VMS from Digital to the list. Now the difference with their source |> code is that it is clean and readable. Something I've not yet heard |> about CBM's (cf. the code in the RKM's). CBM's source code is clean and readable. |> If you want the source to VMS, talk to Digital. The last time I |> checked the entire operating system was available on micro fiche |> (about 400 of them...). So what do you need it for? Doing to the right |> thing in systems programming! Of course, here another difference comes |> up, in that VMS is actually *documented*. Nice, very clean |> descriptions of each OS/library function, During my 2 year stint as a VMS systems programmer, I never HAD to read the fiche. As you say, VMS is very well documented. The only time anyone ever used the fiche was for one of two reasons: diving into the kernel to pull out obscure system information or personal enrichment (i.e. for fun.) |> successful). Reverse engineering is of course much simpler if you have |> source, but: HIDING THE SOURCE DOESN'T PROTECT YOUR OS FROM BEING |> CLONED. IT SURE DOES HURT YOUR APPLICATION DEVELOPERS. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is ridiculous. I am currently employed as a UNIX systems programmer, and again, my use of the source has been limited -- the only time I need to use it is when I am making modifications to the kernel (or other "system" programs.) When I write application code, I use the DOCUMENTED system calls, and work within the calls DOCUMENTED parameters. On the rare occasion when true system bugs are discovered, most are already patched by the vendor. It has been my experience that many, many people clamour for the "source", when they get it, few, if any, ever really use it -- in fact, it seems to be mostly a "bragging-rights" desire ("Yea, I READ the source!") by people with nothing else to brag about. Les -- Extraordinary crimes against the people and the state have to be avenged by agents extraordinary. Two such people are John Steed -- top professional, and his partner, Emma Peel -- talented amateur; otherwise known as "The Avengers." INTERNET: leh@ufl.edu UUCP: ...!gatech!uflorida!leh BITNET: vishnu@UFPINE
andy@cbmvax.commodore.com (Andy Finkel) (06/15/91)
In article <3068@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >You are confusing the protections accorded by law to copyright holders and >the special licensing agreement that AT&T requires. AT&T, prints at the top No, I am not confusing anything. I simply note that AT&T apparently feels that a standard copyright may not meet their needs or goals. >of each source code file "This is unpublished source code of AT&T." And instead >of depending on the copyright law to protect themselves, they require in their >licensing agreements stiff secrecy from their clients. But then, you already >knew that. > >To my knowledge, only AT&T refuses to publish (copyright) their software. You are confusing publishing software and publishing source. Software can be copyright without publishing source. >Perhaps they are afraid of having their code freely distributed 50 years from >now. Perhaps they are forced to keep the source code secret by the DoD. BTW, the Lynx fee for the entire OS wasn't small, last time I checked. >decent fee. ($100?) That constitutes publication. You will then be granted >the protection of the law. You can have copyright protection by publishing a binary, Valentin. And we do. > >Valentin andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "2.0 is not the answer. 2.0 is the question. Yes is the answer." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
andy@cbmvax.commodore.com (Andy Finkel) (06/15/91)
In article <mykes.3524@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >I don't know how many Amiga Users/programmers NEED to see with the sources to >applications (or games), even though it would surely be educational. It would It depends on how serious a game player you are, I guess. :-) >be great to see some of the algorithms to ADPro, for example. The Amiga OS is >a COMMON piece of code that EVERY application has the potential to require to >function. If DPaint and CygnusEd (to name two programs) required the programmers >to have knowledge of the internal workings of Lemmings, then Lemmings source should >be made public. > >In other words, the Amiga OS makes over 400 functions (more under 2.0) public, while >Lemmings et al make none public. There is the difference. Except we'd like people to program to the external interface of the OS, rather than to the internal workings. Having the source available is often educational in the wrong way. "Knowing" that register A5 is free, or that a routine happens to not touch A1 is the usual outcome. andy > >By the way, I wouldn't mind it if publishers did indeed publish source to their >games (after sales diminish, of course). > >-- >**************************************************** >* I want games that look like Shadow of the Beast * >* but play like Leisure Suit Larry. * >**************************************************** -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "2.0 is not the answer. 2.0 is the question. Yes is the answer." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/16/91)
In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >If you think not having source will hurt application developers, you've >not begun to imagine the long-term hurt to users and developers which >would be caused by releasing the source. Why? Because there seems to >be some confusion that the _implementation_ of the OS is its definition. >Nothing could be farther from the truth. The documentation is the >definition, and the implementation is subject to change. Seeing the insides >of routines will only encourage developers to take advantage of tricks that >are not part of the definition and not supportable. It would effectively >mean either the end of OS development or a significant down-turn >in compatibility with future revs of the OS. We won't allow it, >and you shouldn't want it. > I hate to argue the point, Peter, but the documentation doesn't define the OS, because it (like the code) is subject to change. I've bought three full sets of manuals that are radically different from one another over the years. And to top it off, I get developer support materials that come with the disclaimer that any information contained within is subject to change without notice. It's also interesting that I have at least 4 different (I don't mean copies - really different) sets of 1.3 header files... Seeing the insides of routines is an awesome way to learn about programming in all aspects. It is also a good source to start from if you need a routine similar to one in the OS. Consider the case where you want to do BltMaskBitMapBitMap(), which the OS doesn't have. You could roll your own by taking the source to BltMaskBitMapRastPort() (that is a mouthful :) and hack out what you don't want. If you want to encode/decode MFM with the blitter, you could reinvent what CBM has already done, or you could just go look at the source and take what you need. The apps that use routines done this way won't at all break under future OS revs or anything. Seeing the insides of routines doesn't encourage me to rely on the action of what an OS call does. Not having source code hasn't prevented this from being a problem anyway. >Further, Commodore has a very dynamic and accessible support program. >Official developer support is affordable and easy to reach. Unofficial >support is provided on places like Usenet by CBM employees who aren't >required to be here. If you have a question, ask it, instead of >asking for the source. Too many Europeans with A500s programming the Amiga aren't able to access your support program. It costs money, and they don't want to call long distance. I'm not demeaning the value of CATS in any way, it's just that CATS can't reach out and touch every developer. >And before you ask for the source, be sure you avail yourself of >the existing documentation and tools that exist to make your >life easier. Do you have the 1.3 RKMs? Do you have the 1.3 autodocs >and include files? Do you subscribe to AmigaMail? Are you a registered >developer? Do you stay up-to-datewith the Fish Disks and other sources >of freely-redistributable stuff? Do you own the good books that are out >there? Do you run the validation tools we make available (eg. mungwall, >enforcer?) Start there. > All great things to look for/at. If CBM ever did publish the source, why not ship all the machine readable files you can find with it. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/17/91)
In article <22483@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: >>In other words, the Amiga OS makes over 400 functions (more under 2.0) public, while >>Lemmings et al make none public. There is the difference. > >Except we'd like people to program to the external interface of the >OS, rather than to the internal workings. Having the source available >is often educational in the wrong way. "Knowing" that register A5 is >free, or that a routine happens to not touch A1 is the usual outcome. > I wouldn't recommend that anyone ever rely on "knowing" that registers are used or not. If you do want to ensure that your APP will work with future releases of the OS, and you MUST rely on the way the current implementation of the OS works, you could cut and paste the routine from the OS sources into the APP. Carrying along the extra baggage (duplicate of a routine in ROM) is the price the app programmer decides to pay. Again, there are also routines in the ROM that CAN be used to do what you want, but aren't ideal. I used the example of BltMaskBitMapBitMap() in an earlier post... You could emulate such a routine with 2 BltBitMap() calls, but you pay a serious price in speed. Calling BltMaskBitMapRastPort() is not an answer, either, because it is even slower than 2 BltBitMap() calls :) It would be much easier for an application programmer to go and hack BltBitMap() so that it took fewer parameters (faster calling convention), and used 3 inputs instead of 2... >> >>By the way, I wouldn't mind it if publishers did indeed publish source to their >>games (after sales diminish, of course). When I do games under contract, the contracts specifically forbid me from publishing the sources. It would be up to the publishers to decide... -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
peter@sugar.hackercorp.com (Peter da Silva) (06/17/91)
In article <3036@public.BTR.COM> valentin@btr.BTR.COM (Valentin Pepelea valentin@btr.com) writes: > Quite a few companies provide the OS sources to their custommers; Commodore > would not be an exception. Any real-time OS for embedded systems is supplied > in source code form, including Vrtx, pSOS, OS/9, and others. Ever wondered > how come these companies are not afraid of having their work plagiarized? Their customers aren't the end-users? There aren't any rad-kool games that run on them? There's no significant user base? They don't sell the O/S sources for $500, including a computer? -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@sugar.hackercorp.com (Peter da Silva) (06/17/91)
In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: > >What *may* scare CBM is clones of the OS. Now it has > >already happened to the PC BIOS, Apples ROMS, > Apple II ROMs and PC BIOS ROMs are quite trivial compared with the > Amiga ROM. Let me add that the reason that the IBM-PC and Apple-II bogged down, and were unable to make significant enhancements beyond the early '80s, was because of all the software that took advantage of knowing the internals of what I will charitably term their operating systems. Apple, with the IIGS, was able to dump all this old software and launch a new set of system software that didn't depend on the old ROMs. IBM has been trying to do it with OS/2, but have lost out because OS/2 was too ambitious and complex. On the Mac, however, they have been able to make enhancements in some areas that weren't documented. They are still stuck with a lot of backwards- compatibility problems, though, because they haven't been fascist enough about breaking stuff. I'm glad that Commodore has, and don't want them to change. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@sugar.hackercorp.com (Peter da Silva) (06/17/91)
In article <mykes.3594@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > Consider the case where you want to do BltMaskBitMapBitMap(), which the OS > doesn't have. You could roll your own by taking the source to > BltMaskBitMapRastPort() (that is a mouthful :) and hack out what you don't > want. And if enough people do that sort of thing it blocks Commodore from usefully changing the blitter interface. It might be arguable that in this particular case it's too late, but what about all the rest of the code out there? Why not just fake up a RastPort and call BltMaskBitMapRastPort? I agree, a BltMaskBitMapBitMap would be more general, but instead of inventing new tools why not try figuring out to use the ones you have? > The apps that use routines done this way won't at all break under future > OS revs or anything. How do you know? -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
rbabel@babylon.rmt.sub.org (Ralph Babel) (06/18/91)
In article <3096@public.BTR.COM>, valentin@public.BTR.COM (Valentin Pepelea) writes: > Nobody in his right mind would start using tricks or > undicumented features that would break their software in > the future. As you said: "in his right mind" ... :-( > Besides, we all have a constitutional right to shoot > ourselves in the foot. America the Beautiful! :-) > On the contrary, the error was produced by the lack of > documentation and a significant error in OS design. > > Regular device IO requests have their input fields > preserved. If you are talking about the actual implementation, you may be right. If you are talking about the _definition_, you are definitely wrong! The 1.1 Exec documentation only guarantees io_Device, io_Unit, and io_Command to be preserved. It does not say anything about other input field, such as io_Flags, io_Length, io_Data, and io_Offset (even though it _does_ say: "This permits repeated I/O using the same request."). The 1.3 documentation explicitly allows a device driver to modify these latter fields. Btw: I'd also consider this a design mistake, but this point is completely moot. > And then there are questions which will never be answered, > particularly not on Usenet. Like, is there a bug in > function XXX? I agree; this is a serious problem! Commodore might acknowledge the existence of a specific bug, but a list of known bugs has yet to be published. Ralph
peter@cbmvax.commodore.com (Peter Cherna) (06/18/91)
In article <mykes.3594@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >I hate to argue the point, Peter, but the documentation doesn't define the OS, >because it (like the code) is subject to change. The documentation is supposed to define the OS, and largely does. We attempt to address areas where this is untrue. You're overlooking that older documenation still holds true, it's just incomplete (doesn't document features implemented after the documentation was written). And, like any definition, it's subject to be improved (as well as extended) over time. >I've bought three full sets >of manuals that are radically different from one another over the years. Right, but you can program according to the 1.1 or 1.3 RKMs and still expect to work pretty well under 2.0. That would not be as true if you took your inspiration from 1.1 or 1.3 source code. >And to >top it off, I get developer support materials that come with the disclaimer that >any information contained within is subject to change without notice. Those are typically distributed in advance of the finalization of the spec. At that time, I suppose you'd want pre-releases of source code. And you honestly believe that preliminary source wouldn't have such a disclaimer? Be serious, the documentation specification can be finalized long before the last significant code changes. >Seeing the insides of routines is an awesome way to learn about programming in >all aspects. Assuming the quality of the routines. The Amiga OS is pretty good, but like any real-world product, it has it's ugly bits. There are also multiple compilers and languages at play, including a few arcane pre-processors. Not only that, but the ROM-writers have certain special priviledges not enjoyed by "external" software. For example, 2.0 Intuition.library is guaranteed to have 2.0 graphics.library available. Your routine based on source to 2.0 intuition.library doesn't have that luxury. As well, if we make a hardware improvement to the Amiga, we can alter the ROM at that time. Therefore we can leave code that's technically incorrect according to the Amiga specification but is 100% correct for all existing machines. We get to change it before the new machine is out. You can't. Nevertheless, we haven't done anything wrong in the ROM. >It is also a good source to start from if you need a routine similar >to one in the OS. Consider the case where you want to do BltMaskBitMapBitMap(), >which the OS doesn't have. Developer support can provide information on how to proceed. The answers they give are sometimes based on their inspection of the source. If you don't ask, you'll never find out. >Seeing the insides of routines doesn't encourage me to rely on the action of what >an OS call does. Good for you. However, that doesn't mean there are no people unlike you. As well, even though we can list dozens of ways in which you could incorrectly rely on the action of a particular implementation, one doesn't need to be too clever to accidentally stumble on a different dependency that one doesn't even recognize until it's too late. >Too many Europeans with A500s programming the Amiga aren't able to access >your support program. It costs money, and they don't want to call long distance. >I'm not demeaning the value of CATS in any way, it's just that CATS can't reach >out and touch every developer. There are plenty of programmers on both sides of the Atlantic who program with insufficient documentation. There is plenty of documentation they can avail themselves of, and the biggest problem is they don't. Someone who doesn't acquire what we make available is unlikely to understand and/or care about the fairly complex issues involved in working from source. We guarantee the functional and structural interface, not the implementation. Therefore, it is entirely natural that we publish the former, and not make the latter available.
vinsci@nic.funet.fi (Leonard Norrgard) (06/18/91)
In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: In article <VINSCI.91Jun14003452@nic.nic.funet.fi> vinsci@nic.funet.fi (Leonard Norrgard) writes: > Now, style isn't everything. Publishing your not all too nice source >code is OK. Style has nothing to do with it. In fact, significant chunks of the OS are in excellent shape, for example Intuition (thanks in large part to Jim Mackraz - hi jimm!) Good. >What *may* scare CBM is clones of the OS. Now it has >already happened to the PC BIOS, Apples ROMS, Apple II ROMs and PC BIOS ROMs are quite trivial compared with the Amiga ROM. Triviality hasn't got much to do with it, I'm afraid. As soon as someone sees a decent margin on the project and they have a customer, it will be done. Not that I'd envy those poor programmers who would have to do it! >Reverse engineering is of course much simpler if you have >source Reverse engineering is quite illegal if you work from the source. There's nothing reverse about it then. "Reverse engineering" is writing specs from *something* and then have someone else, who didn't check out *something*, implement it from the specs. Like the black box you all want us to think of. Of course, I'm no lawyer, and especially not a US lawyer. >IT SURE DOES HURT YOUR APPLICATION DEVELOPERS. If you think not having source will hurt application developers, you've not begun to imagine the long-term hurt to users and developers which would be caused by releasing the source. Of course, every developer is a child and from this follows that Commodore must babysit every developer. With every rule you can come up with, someone is going to break it no matter what. When will you tell people it's naughty to write viruses? Do you seriously think virus-writers would follow your recommendation? Will developers start to write viruses when they see the bad guys writing viruses? I think not. Why? Because there seems to be some confusion that the _implementation_ of the OS is its definition. Nothing could be farther from the truth. The documentation is the definition, and the implementation is subject to change. Seeing the insides of routines will only encourage developers to take advantage of tricks that are not part of the definition and not supportable. Try to decide now, you just said that the OS wasn't ugly. Now you're telling us the opposite. Do you mean that the OS relies on side effects? Have you knowingly designed in side-effects? Hope you're all walking encyclopedias, you must have some memory! Unless you specifically documented the things as side-effects of course. But then it wouldn't hurt anyone, devlopers *can* read comments if they *can* read the code. It would effectively mean either the end of OS development or a significant down-turn in compatibility with future revs of the OS. We won't allow it, and you shouldn't want it. Is this how Unix ended? VMS? OK, so you'll say that every application will have to be recompiled for each new OS version, maybe even with a change or two. Since most game software seems to not be using the OS anyway, that leaves the "serious" software. Well, if your software supplier doesn't update the software you bought, it will be outdated anyway. If you want the OS to mature and become an accepted citizen in this world, you'd rather accept that backward compatibility isn't everything. Someone from West Chester recently wrote here that more than 50% (if my memory serves me right) of the 2.0 development time was put in areas meant to maintain bug-level compatibility with old software. IMHO, this is not sane. Let's continue on this track and in 7 more years, the Amiga will be then what the PC is today. Backwards compatible, but nothing you'd really want. The funniest part about it is that one of the Usenetters arguing for sources to be released has recently dealt with a bug in code he is responsible for. The problem was code that was depending on Intuition preserving some fields that in the manuals were specifically _defined_ as being trashed. Under 1.3, they just happened to be preserved. Under 2.0, they weren't. Boom. You can't seriously want more of that? Yes, I want exactly that. A developer who maintains his software, namely. Let's face it: the perfect software package doesn't exist. We all try hard to deliver it, and some even claim they're doing just that. Customers who don't make sure they're running with the latest (or so) version of a package take unnecessary risks and likely have problems they need not have. So what do I do with 1.3 software that hasn't been upgraded to be 2.0 compatible? It's either the trash can, or if I need it real bad, I boot a machine in 1.3 mode. Usually there is better and compatible software on the market, so no big harm is done anyway. The developers who properly maintain their software will get my money again and again, this while I'm still happy! Further, Commodore has a very dynamic and accessible support program. Official developer support is affordable and easy to reach. It's not as homogenous as it could, though. In europe, there's usually quite a long delay (as in 24 hours) before you can have an answer. If the answer needs a clarification, or leads to related questions, add 24 hours again, and so on. I could elaborate on this, but this isn't the right forum. Talk to you in July, when the "accessible support" forum should be available here again *if* the current promises hold (currently after a pause for more than six months!). This has nothing to do with you however, so let's not talk about it. Unofficial support is provided on places like Usenet by CBM employees who aren't required to be here. If you have a question, ask it, instead of asking for the source. As you probably know, I have done just that (through the appropriate channels, when possible). Most of the time, if there had been source, there would have been no reason for it. And that's not because we're looking for side effects to "benefit" from. Some of the most usual reasons are things like timing, efficiency & algorithms used (maybe your developer community happen to unknowingly sit on faster code?). And as you decribe above, debugging. Why is this code suddenly blowing up? With the source you can check it out and understand it immediately. More important, you'll know if the bug is in the OS or in your own code. Believe me, no developer can afford to test their code agains your *written specifications*. If it doesn't work as it is assumed to, you try 10 different ways before making an OS bug report. Doing those 10 different ways takes time and costs money. Time and money that could have been saved. OS bugs that could have been reported immediately, OS documentation bugs that could have been reported as well, if only somebody had been given a decent chance to pin-point the problem. And before you ask for the source, be sure you avail yourself of the existing documentation and tools that exist to make your life easier. Good general advice! Do you have the 1.3 RKMs? Yes. Do you have the 1.3 autodocs and include files? No, I deleted them since they aren't up-to-date anymore. What kind of advice is this anyway? Do you subscribe to AmigaMail? Yes. Are you a registered developer? Yes, commercial level. (CBM's highest level for those of you wondering) Do you stay up-to-datewith the Fish Disks and other sources of freely-redistributable stuff? Yes, but *never* trust those sources. You'd be depending on something that isn't necessarily written to the specs. (I'm serious, even if this could be written with a great deal of irony in response to your previous comments about relying on side-effects in the OS.) Do you own the good books that are out there? Yes. Do you run the validation tools we make available (eg. mungwall, enforcer?) Yes, in addition to our own. Start there. I did. I'm still frustrated. Not that I'm looking for any particular bug right now, but I know the day will come, again and again and again. All the time we could have saved. All the time that could have been used for productive programming instead. BTW, are you aware that the September/October '90 Amiga Mail master index for Amiga documentation listed 21 sources for Amiga technical documentation (almost all originating from Commodore). What is this? Distributed documentation? To "do the right thing" usually requires being familiar with all of these. My hat is off to Ken Farinsky of CATS for writing the x-ref, though. >-- Leonard Peter Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. -- Leonard
valentin@public.BTR.COM (Valentin Pepelea) (06/18/91)
In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: > >If you think not having source will hurt application developers, you've >not begun to imagine the long-term hurt to users and developers which >would be caused by releasing the source. Why? Because there seems to >be some confusion that the _implementation_ of the OS is its definition. >Nothing could be farther from the truth. The documentation is the >definition, and the implementation is subject to change. Seeing the insides >of routines will only encourage developers to take advantage of tricks that >are not part of the definition and not supportable. This is absolute nonesense. Nobody in his right mind would start using tricks or undicumented features that would break their software in the future. This cynical attitude has no place in this discussion. What imbeciles are going to do with a usefull tool is totally irrelevant to this discussion. Besides, we all have a constitutional right to shoot ourselves in the foot. >The funniest part about it is that one of the Usenetters arguing for >sources to be released has recently dealt with a bug in code he >is responsible for. The problem was code that was depending on >Intuition preserving some fields that in the manuals were specifically >_defined_ as being trashed. Under 1.3, they just happened to be >preserved. Under 2.0, they weren't. Boom. This is totally irrelevant. The error that you are alluding to was produced without the availability of source code. On the contrary, the error was produced by the lack of documentation and a significant error in OS design. Regular device IO requests have their input fields preserved. Input events on the other hand have their inputs destroyed. This is a serious design mistake. >Further, Commodore has a very dynamic and accessible support program. >Official developer support is affordable and easy to reach. If you can afford the $450/year fee, plus the long distance phone charges. Many of our contractors cannot afford this 'accesible' program. >If you have a question, ask it, instead of asking for the source. And then there are questions which will never be answered, particularly not on Usenet. Like, is there a bug in function XXX? >And before you ask for the source, be sure you avail yourself of >the existing documentation and tools that exist to make your >life easier. Do you have the 1.3 RKMs? Do you have the 1.3 autodocs >and include files? The 1.3 RKMs are certainly a vast improvement over their predecessors. Particularly when it comes to examples. But there is no substitue for source code. I certainly am happy with them. But that is not the case of my colleagues, nor of many other devellopers I know. There are advantages of having the OS writers also write the documentation. But disadvantages also abound. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
valentin@public.BTR.COM (Valentin Pepelea) (06/18/91)
In article <22472@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: > >>To my knowledge, only AT&T refuses to publish (copyright) their software. > >You are confusing publishing software and publishing source. >Software can be copyright without publishing source. > >>decent fee. ($100?) That constitutes publication. You will then be granted >>the protection of the law. > >You can have copyright protection by publishing a binary, Valentin. >And we do. This reply is totally irrelevant. We were talking about source code only. And publication of binaries does not constitute publication of source code, particularly when time limitations are to be taken into account. Our discussion has been limited to whether publishing the source code is a good idea. So far we have been given only the following reasons against it: 1. The copyright laws do not adequately protect you. 2. Imbeciles might do imbecile things. Any other bright arguments? In my opinion, the only reason that a company might have to not publish source code is that it does not want to give other people the opportunity to learn for studying the Amiga operating system. I'm not talking copying, since no individual would be stupid to plagiarize, but rather to learn from other people's mistakes and prevent any reoccurences. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
valentin@public.BTR.COM (Valentin Pepelea) (06/18/91)
In article <1991Jun17.141923.2835@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >> would not be an exception. Any real-time OS for embedded systems is supplied >> in source code form, including Vrtx, pSOS, OS/9, and others. Ever wondered >> how come these companies are not afraid of having their work plagiarized? > >Their customers aren't the end-users? Depends on what you mean by end-user. Are Amiga developers considered mere end-users? >There aren't any rad-kool games that run on them? > >There's no significant user base? I have propely mentioned OS/9, have I not? Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
es1@cunixb.cc.columbia.edu (Ethan Solomita) (06/18/91)
In article <3096@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter >Cherna) writes: >> >>If you think not having source will hurt application developers, you've >>not begun to imagine the long-term hurt to users and developers which >>would be caused by releasing the source. Why? Because there seems to >>be some confusion that the _implementation_ of the OS is its definition. >>Nothing could be farther from the truth. The documentation is the >>definition, and the implementation is subject to change. Seeing the insides >>of routines will only encourage developers to take advantage of tricks that >>are not part of the definition and not supportable. > >This is absolute nonesense. Nobody in his right mind would start using tricks >or undicumented features that would break their software in the future. This >cynical attitude has no place in this discussion. > I guess you haven't used all that much Amiga software? How many workarounds had to be made for 2.0 to try to make it compatible with assinine decisions programmers have made? How about copy protection schemes? It seems to be realism, not cynicism. >What imbeciles are going to do with a usefull tool is totally irrelevant to >this discussion. Besides, we all have a constitutional right to shoot ourselves >in the foot. > If a developer breaks the rules and shoots him/herself in the foot, he then shoots customers in the foot, which then shoots Commodore in the foot. Anything that affects the apparent quality of the Amiga affects Commodore. It doesn't HELP them to release the source. It only seems to hurt. We do have constitutional rights which allow us to be as stupid as we like (unless you go to college and have to be P.C. 8), but you have no right to impose your will/opinions on CBM. >>Further, Commodore has a very dynamic and accessible support program. >>Official developer support is affordable and easy to reach. > >If you can afford the $450/year fee, plus the long distance phone charges. >Many of our contractors cannot afford this 'accesible' program. > Every business has its costs. To be a programmer, you need to buy your development system, buy your compilers, buy your DTP program to write the manual, market the product or find a distributor, etc. If you can't afford $450 and phone charges (or a BIX/Usenet account), then you don't have the money realistically to make it in the software market, at least unless you get really lucky. -- Ethan "...Know-Nothing-Bozo the Non-Wonder Dog, an animal so stupid that it had been sacked from one of Will's own commercials for being incapable of knowing which dog food it was supposed to prefer, despite the fact that the meat in all the other bowls had engine oil poured all over it."
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/18/91)
In article <1991Jun17.144051.3418@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <mykes.3594@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >> Consider the case where you want to do BltMaskBitMapBitMap(), which the OS >> doesn't have. You could roll your own by taking the source to >> BltMaskBitMapRastPort() (that is a mouthful :) and hack out what you don't >> want. > >And if enough people do that sort of thing it blocks Commodore from usefully >changing the blitter interface. It might be arguable that in this particular >case it's too late, but what about all the rest of the code out there? > >Why not just fake up a RastPort and call BltMaskBitMapRastPort? I agree, a >BltMaskBitMapBitMap would be more general, but instead of inventing new tools >why not try figuring out to use the ones you have? > I've used BltMaskBitMapRastPort() quite a few times, and every time, I am amazed at how SLOWWWWWWW it is. It has to do layers and RastPort clipping. It is faster to do two BltBitMap() calls (one to AND, one to OR). >> The apps that use routines done this way won't at all break under future >> OS revs or anything. > >How do you know? Because you won't be relying on how the OS works. You will have code that is guaranteed to work (as long as you allocate your resources correctly) embedded in your application instead of external where CBM might muck it up. >-- >Peter da Silva. `-_-' <peter@sugar.neosoft.com>. > 'U` "Have you hugged your wolf today?" -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (06/18/91)
In article <3096@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >This is absolute nonesense. Nobody in his right mind would start using >tricks or undocumented features that would break their software in the >future. Valentin, did you really WRITE this? Didn't Commodore just spend months adapting the operating system so people's incorrectly-written programs would run? If "nobody in his right mind" uses undocumented features, then there are a lot of insane people in the world.... My two cents on the issue: I wouldn't mind seeing the source code for some of the applications (like C: commands, etc), but I see no real need for the OS source code. I have been a UNIX systems administrator for 5 years, and we always buy the source code. I use it (/usr/src) daily. But I NEVER needed the source code for the low-level operating system stuff -- UNIX system calls -- except when I am modifying the kernel. There's absolutely no information in there that I would use (read "rely on") in my own applications, because it's all subject to change by the manufacturer. (And modified kernels are something I'd HATE to see appearing in the Amiga community. It would create a support nightmare for Commodore.) Just the other day, I rewrote one of my programs to use a totally different memory-allocation model. If any of my users had relied on my ordinary use of malloc() and free(), they'd be sorely surprised now! Instead, they use the program in the way it is documented. I'm sure Commodore does this kind of thing on a much larger scale.... All IMHO. Dan //////////////////////////////////////¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | ¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥/////////////////////////////////////
peter@cbmvax.commodore.com (Peter Cherna) (06/18/91)
In article <VINSCI.91Jun18030222@nic.nic.funet.fi> vinsci@nic.funet.fi (Leonard Norrgard) writes: >In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: > In article <VINSCI.91Jun14003452@nic.nic.funet.fi> vinsci@nic.funet.fi (Leonard Norrgard) writes: > >Reverse engineering is of course much simpler if you have > >source > > Reverse engineering is quite illegal if you work from the source. There's > nothing reverse about it then. > >"Reverse engineering" is writing specs from *something* and then have >someone else, who didn't check out *something*, implement it from the >specs. Like the black box you all want us to think of. Of course, I'm >no lawyer, and especially not a US lawyer. I do believe you're agreeing with me, and contradicting yourself. You said that reverse engineering is simpler if you have source. Now you say reverse engineering is done from a black box spec. Thus, you see my point. > If you think not having source will hurt application developers, you've > not begun to imagine the long-term hurt to users and developers which > would be caused by releasing the source. > >Of course, every developer is a child and from this follows that >Commodore must babysit every developer. With every rule you can come >up with, someone is going to break it no matter what. It is in our right and to the benefit of Amiga customers to act in a manner that will best preserve the future of the Amiga. The specific aspect of that which is at hand is "how shall we best ensure that the OS and the hardware can continue to evolve and have significant compatibility with third-party software that preceeds it?" It is in our commercial interest to do so, and we have every right. We take steps to maximize the ease of writing correct software, and minimize the kinds of information that can lead to incorrect software. >tell people it's naughty to write viruses? Do you seriously think >virus-writers would follow your recommendation? I agree with you that there are people out there who violate the rules we have today. However, it does not follow from that that if we release source, with far more complex rules, that things won't get worse. They will. > Seeing the insides > of routines will only encourage developers to take advantage of tricks that > are not part of the definition and not supportable. >Try to decide now, you just said that the OS wasn't ugly. Now you're >telling us the opposite. Please stop stuffing words into my mouth. Please re-read what I have written. _Some_ parts of the OS are very nicely written, but as in any real-world project, not all parts are so nice. >Do you mean that the OS relies on side >effects? Have you knowingly designed in side-effects? We can (and do) change the ROM when new hardware or software comes out, and _every_ user of an Amiga has an appropriate ROM. The same cannot be said for application software. > It would effectively > mean either the end of OS development or a significant down-turn > in compatibility with future revs of the OS. We won't allow it, > and you shouldn't want it. > Someone from West Chester recently wrote here that more >than 50% (if my memory serves me right) of the 2.0 development time >was put in areas meant to maintain bug-level compatibility with old >software. IMHO, this is not sane. Let's continue on this track and in >7 more years, the Amiga will be then what the PC is today. Backwards >compatible, but nothing you'd really want. Your memory fails you. A few months of time for several engineers, that's all. You're missing the point that the acceptance of 2.0 is critical for its success, and therefore anything (such as increased compatibility) that helps the acceptance is a friend of you and of me. Please trust us when we assure you that by and large we did not insert kludges that compromise the integrity, maintainability, or future of the OS. There were things we could fix, but only in ways we deemed unacceptable. Here were some of the criteria for deciding if a kludge would go in. Based on those, you should be able to rest knowing that the process was extremely sane: 1. How many applications are affected? 2. How seriously broken are they? 3. Was the incorrectly-coded section a fair attempt, or blatantly stupid? 4. Was there any documentation on this issue, and how clear was it? (a good example is overscan: there was no approved technique for a while, and it was important; therefore many different techniques have been made to work) 5. How much of our time and ROM-space would be needed to fix the problem? 6. Would the kludge entail a serious performance penalty? 7. How would it affect the long-term future of our system to put in the kludge? The final decision was a carefully considered weighted decision based on questions such as these. Also, our interface is pretty well-defined. Which means that the kinds of kludges we did have to put in tend to affect the integrity of the system the way they've hurt other machines. Not only that, but we've kept a list of what we've done, so we can make that available, and also write tools that re-break kludged software, so a developer could tell if he was accidentally relying on such a kludge. >Customers who don't make sure they're running with the latest >(or so) version of a package take unnecessary risks and likely have >problems they need not have. So what do I do with 1.3 software that >hasn't been upgraded to be 2.0 compatible? It's either the trash can, >or if I need it real bad, I boot a machine in 1.3 mode. Usually there >is better and compatible software on the market, so no big harm is >done anyway. The developers who properly maintain their software will >get my money again and again, this while I'm still happy! There were a large number of first-rank applications that didn't run under 2.00. A large number now work under 2.04. Face it, even the person with the best intentions can write software that may have a bug that will only appear when a new processor, OS, or machine comes out. The active developer will always have an advantage, and Commodore DOES encourage active developers. However, we will not do this by avoiding easy modifications that make existing copies of software run again. I remain unpersuaded that there are sound technical reasons for releasing the source. Even if there were, there exist sound non-technical reasons to hang on to it. It doesn't have to be a whole lot more complex than that. > Peter > > Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. > >-- Leonard Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Gosh, didn't he have anything positive to say at all?"
peter@cbmvax.commodore.com (Peter Cherna) (06/18/91)
In article <3096@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter >Cherna) writes: >This is absolute nonesense. Nobody in his right mind would start using tricks >or undicumented features that would break their software in the future. This >cynical attitude has no place in this discussion. This "cynical" attitude is based on a significant amount of experience figuring out just which trick or undocumented feature dozens of pieces of software that people who claim to be in their right minds have indeed written for our computer. The attitude not only belongs in this discussion, it is CENTRAL. >What imbeciles are going to do with a usefull tool is totally irrelevant to >this discussion. Besides, we all have a constitutional right to shoot ourselves >in the foot. Commodore chooses to not avail itself of this right :-) Remember that the people you refer to as "imbeciles" (I rather think of them as developers who are already grappling with a sizable amount of documentation and rules who you wish to inundate with an order of magnitude more stuff) are quite capable of shooting Commodore in the foot. That is also central to this discussion. >>Further, Commodore has a very dynamic and accessible support program. >>Official developer support is affordable and easy to reach. > >If you can afford the $450/year fee, plus the long distance phone charges. >Many of our contractors cannot afford this 'accesible' program. I believe you should look at the fee schedule again. It's considerably less than that. >>If you have a question, ask it, instead of asking for the source. > >And then there are questions which will never be answered, particularly not >on Usenet. Like, is there a bug in function XXX? Please do not claim to know what is and isn't answered on Usenet. I myself have answered countless individuals who have asked or reported a bug in the system. When there is a problem in the OS, I tell them so. When the problem doesn't appear to be in the OS, I've often helped them to locate the reason and identify a fix. The kind of questions that don't get answered typically involve proprietary information that can't be disclosed, like how many 68040's will be in an Amiga 9000... >The 1.3 RKMs are certainly a vast improvement over their predecessors. >Particularly when it comes to examples. But there is no substitue for >source code. I agree there would be some benefit to some developers, for the source code. On the other hand, just look at the reams of wonderful software written for Amigas, MACs, Windows, etc. that do not have source code available. There are plenty of developers out there capable of doing fine work without source, and a good thing too. The cost to Commodore in terms of what it will do to the future of the OS and the hardware is significantly greater than any benefit you imagine might be reaped. >Valentin Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Gosh, didn't he have anything positive to say at all?"
navas@cory.Berkeley.EDU (David C. Navas) (06/18/91)
In my opinion, this belongs in .advocacy, so I have set the FollowUp-To there. In article <22523@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >Be serious, the documentation specification can be finalized long before >the last significant code changes. Ah, so we should all expect 2.0 documentation before the ROMs? As in "long before?" I guess I won't hold my breath for 2.0 ROMs then... The main beef that I have with the documentation is two fold. The RKMs are perfect reference manuals. In fact when I first taught myself the Amiga's kernel, I printed out the includes (this was back in '86). You see, I lived way back in the boonies where we were lucky to have a dealer (who later went under), nevermind access either to documentation or even information about such documentation. This does in no way change the fact that the RKMs are perfectly INADEQUATE for learning the Amiga's OS. You see, I had a good deal to go on with those includes, but the thing that taught me the OS was *EXAMPLE CODE* that was *documented*. In particular fastdir by Dave Haynie taught me all the things I didn't want to know about DOS, and some triangle rotating program which was written by someone whos name slips the mind. At least the 2.0 Autodocs have a little more code here and there.... Under unix, it's pretty easy to experiment with function calls -- if you get them wrong, you core dump. If you get an Amiga program wrong, your system reboots. Makes the learning curve a bit more frustrating. On an A3000, that's okay, on an A500 where you're developing out of RAM, it's a might unacceptable.... In essence, then, we need a couple of goal-oriented type documentation. I realize AmigaMail is supposed to help here, but AmigaMail is too little too infrequently IMHO. I'd rather pay you folks a moderate sum for a weekly publication or something like that. In fact, I'd rather pay a lump sum and get the whole thing in a book. Anybody that could, for instance, explain the iffparse.library to me.... Of course, if I had source to the Display program, no one would need to (I assume). That's probably the argument in these circles. Although, to be perfectly fair, it must be noted that Cmdre *does* release source for a number of programs in their DevCon disks. *I* would rather have a manual, but it is better than nothing. Secondly, books are written by third parties to fill in these gaps. BUT when push comes to shove, Cmdre can always say, "but that manual wasn't written by *us*. We can't help it if it has incorrect or misleading information." You see? I want a manual that tells me how to program the OS the way YOU envision that it ought to be programmed. That's not to say that you restrict us to one method, rather you give us a working method that we can start with. We can then consult the RKM's when we want to change a feature or two. >We guarantee the functional and structural interface, not the implementation. >Therefore, it is entirely natural that we publish the former, and not >make the latter available. Perfectly acceptable. I want good documentation, though. By the by, you could write a book comparing the Amiga OS's programming methodology to other system models, give good points and bad points and lots of example code written for different systems (Mac, Windows, Xt/Unix, etc.). It's a bit of advocacy, it would point out the weak parts of your own OS to you, and it would benefit at least one developer that I know :) David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus
andy@cbmvax.commodore.com (Andy Finkel) (06/19/91)
In article <3098@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: > >1. The copyright laws do not adequately protect you. >2. Imbeciles might do imbecile things. > >Any other bright arguments? It doesn't take an imbecile. Let me give you an example you might be able to relate to. The 2.0 parallel.device turns out to depend heavily on side effects of the 2.0 cia resource and timer.device, in any of its three speed modes. It's just not that reliable under 1.3. The programmer apparently did this without knowing, and has no idea he even was depending on the side effects. If he had realized it, he might have done a version check, or at the least put comments about the problem in the source. The only way to discover the side effects was via the source. It would be a shame if this problem were magnified a thousandfold. >Valentin andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "2.0 is not the answer. 2.0 is the question. Yes is the answer." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
peter@cbmvax.commodore.com (Peter Cherna) (06/19/91)
In article <22539@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >In article <3096@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >>In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter >>Cherna) writes: >>>Further, Commodore has a very dynamic and accessible support program. >>>Official developer support is affordable and easy to reach. >> >>If you can afford the $450/year fee, plus the long distance phone charges. >>Many of our contractors cannot afford this 'accesible' program. > >I believe you should look at the fee schedule again. It's considerably >less than that. In particular, Commodore offers the "Certified" level of support, which is only $75 per year. The $450 "Commercial" level of support allows making one contractor eligible for access to CATS. Commodore's main area of support is on Bix, and there are local dial-in points for Tymnet and so-on to minimize long-distance calls. Any active developer on Bix can tell you that the quality of information, response time, and resources that you can tap into is very good. (As usual, I'm referring to options offered by CBM USA. Support in other countries may vary). There are avenues of freer support from Commodore which are not official, eg. here on Usenet and in the open conferences on Bix. As well, developers can obtain support from non-CBM people as well, on BBS's, bix, Usenet, at user-groups, etc. Therefore there is a broad range of support available for a range of prices. There is also some rough correspondance between the need for support and the ability to afford it. We need not apologize that the "gold card" treatment costs more. Myself, I try to keep the level of support I can offer relatively high. And it's free to you. I think I've said my peace here. Instead, I'll spend my Usenet time answering technical questions instead. Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Gosh, didn't he have anything positive to say at all?"
daveh@cbmvax.commodore.com (Dave Haynie) (06/19/91)
In article <3100@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <1991Jun17.141923.2835@sugar.hackercorp.com> >peter@sugar.hackercorp.com (Peter da Silva) writes: >>> Any real-time OS for embedded systems is supplied in source code form, >>> including Vrtx, pSOS, OS/9, and others. >>Their customers aren't the end-users? >Depends on what you mean by end-user. The folks who receive the source code for such realtime embedded systems are porting that code to their embedded hardware. This is analogous to Commodore receiving source code from AT&T for their port of UNIX. The users of the embedded system itself aren't getting the source. >>There's no significant user base? >I have propely mentioned OS/9, have I not? So all those folks with OS/9 on their Tandy CoCo systems have the source to OS/9? That would be interesting... -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "This is my mistake. Let me make it good." -R.E.M.
cg@ami-cg.UUCP (Chris Gray) (06/19/91)
In article <3098@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >Our discussion has been limited to whether publishing the source code is a >good idea. So far we have been given only the following reasons against it: > >1. The copyright laws do not adequately protect you. >2. Imbeciles might do imbecile things. > >Any other bright arguments? > >In my opinion, the only reason that a company might have to not publish source >code is that it does not want to give other people the opportunity to learn >for studying the Amiga operating system. I'm not talking copying, since no >individual would be stupid to plagiarize, but rather to learn from other >people's mistakes and prevent any reoccurences. I disagree. The past shows that with many systems, the Amiga included, there are lots of people out there who will do stupid things, again and again. If the only people who programmed the Amiga were "professionals", then a) what you are saying MIGHT be true, depending on your definition of professional (what about the game programmers?) b) there would be a lot less innovation, a lot less tools, etc. c) there would be very little "hacker excitment" about the Amiga, which would be a bad thing, in my opinion Commodore is doing the only reasonable thing by not releasing the source code to the system. An argument could be made for licensing to professionals (for enough money, and with enough legal guarantees to make it safe), but it likely isn't worth the effort. On your other pet peeve: I'm academically interested in your VM implementation, but I don't have any use for it. I would like to have protected processes, however, but we know how hard that would be in general. Can you please take your disagreements with CBM to mail - your posts sound like a combination of sour grapes and dirty laundry. [Gee, have I just flamed someone?] -- Chris Gray alberta!ami-cg!cg or cg%ami-cg@CS.UAlberta.CA
valentin@public.BTR.COM (Valentin Pepelea) (06/19/91)
In article <22539@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: > >In article <3096@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >>In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter >>Cherna) writes: > >>This is absolute nonesense. Nobody in his right mind would start using tricks >>or undicumented features that would break their software in the future. This >>cynical attitude has no place in this discussion. > >This "cynical" attitude is based on a significant amount of experience >figuring out just which trick or undocumented feature dozens of pieces >of software that people who claim to be in their right minds have indeed >written for our computer. The attitude not only belongs in this discussion, >it is CENTRAL. This is absolute nonesense. Are you now advocating the use of undocumented features by patching the OS in such a way that stupid programs still work under a new OS? Of course not. What imbeciles do with a useful tool is irrelevant. The above example of yours demontrated to what ridiculous lengths developers must go in order to make their program do what they want. They had no access to the source code. Perhaps if they had, they would have been able to figure out an OS friendly way to accomplish their objective. Pure speculation, of course. :-) >>If you can afford the $450/year fee, plus the long distance phone charges. >>Many of our contractors cannot afford this 'accesible' program. > >I believe you should look at the fee schedule again. It's considerably >less than that. An I believe a retraction is in order! >Please do not claim to know what is and isn't answered on Usenet. I myself >have answered countless individuals who have asked or reported a bug >in the system. When there is a problem in the OS, I tell them so. Do you realize that you may be violating Commodore's policy? Divulgating bugs to developers would not, but is it not Commodore's policy not to disclose the existence of bugs? I ask because frankly, I don't know. Of course, such a policy might be illegal, but that is another story. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
valentin@public.BTR.COM (Valentin Pepelea) (06/19/91)
In article <22547@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: > >The 2.0 parallel.device turns out to depend heavily on side effects >of the 2.0 cia resource and timer.device, in any of its three speed modes. >It's just not that reliable under 1.3. The programmer apparently did this >without knowing, and has no idea he even was depending on the side effects. Since I am the one wrote the parallel device, would you mind telling me what side effect you are claiming is being depended on? I cannot write a valid reply without that information. In your opinion, was this side effect taken advantage of because I had access to the source code, or because the documentation was unclear? Incidentally, there are only two modes in the parallel device. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (06/19/91)
peter@cbmvax.commodore.com (Peter Cherna) writes: >And before you ask for the source, be sure you avail yourself of >the existing documentation and tools that exist to make your This is a VERY good point peter. Most people don't realize the usefullness (is that even a word??) of the various tools. People say "but they make my programs crash!" .. ahem.. that's the point. when a program no longer crashes with these tools, it might be nearly well behaved :) .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
jbickers@templar.actrix.gen.nz (John Bickers) (06/19/91)
Quoted from <3117@public.BTR.COM> by valentin@public.BTR.COM (Valentin Pepelea): > What imbeciles do with a useful tool is irrelevant. The above example of yours > demontrated to what ridiculous lengths developers must go in order to make Uh, what makes it a useful tool? That it provides information outside the official documentation, the RKMs (or developer periodicals)? > Perhaps if they had, they would have been able to figure out an OS friendly > way to accomplish their objective. Pure speculation, of course. :-) Friendly to that specific version of the source. > Valentin -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
mks@cbmvax.commodore.com (Michael Sinz) (06/19/91)
In article <3117@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >What imbeciles do with a useful tool is irrelevant. The above example of yours >demontrated to what ridiculous lengths developers must go in order to make >their program do what they want. They had no access to the source code. >Perhaps if they had, they would have been able to figure out an OS friendly >way to accomplish their objective. Pure speculation, of course. :-) Valentin, I thought that by now that a guy who portends to have such wisdom would, by now, have seen the wisdom of the arguments. And even if the arguments are not of high enough calibre to warrent your consideration, your last comment has surprised me since a programmer of your experience and skill would have known that the source would have no way of telling you in what way the system will change. Now, if you would just think about the methods that you must have learned throughout your vast experience of software engineering, you will find that the only way multi-programmer projects where one programmer uses routines from another, be they within the same company or in the form of vender <-> customer or even operating system <-> developer, that it is the documented interfaces that makes it possible for each side to change, enhance, and optimize thier part of the system without damage to that of the other parts. Any knowledge other than the documented interfaces can not, and infact *MUST* not be used and thus becomes unimportant. Now, maybe you have achieved a new level of "awareness" that we poor souls have not yet reached so we will have to continue along our blind path hoping to find the light. Please give us our peace such that we may find the way. /----------------------------------------------------------------------¥ | /// Michael Sinz - Amiga Software Engineer | | /// Operating System Development Group | | /// BIX: msinz UUNET: rutgers!cbmvax!mks | |¥¥¥/// | | ¥XX/ Quantum Physics: The Dreams that Stuff is made of. | ¥----------------------------------------------------------------------/
consp03@bingsuns.cc.binghamton.edu (Kriston J. Rehberg) (06/19/91)
In article <22554@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) writes: |>In article <3100@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: |>>I have propely mentioned OS/9, have I not? |> |>So all those folks with OS/9 on their Tandy CoCo systems have the source to |>OS/9? That would be interesting... Nope, Microware (OS-9 people) don't supply source to Tandy CoCo users - and I doubt anyone else. Maybe NASA, I suppose. |>Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" -Kris +---------------------------------------------------------------------+ | Kriston J. Rehberg, Consultant, SUNY-Binghamton Computer Services | | <consp03@bingsuns.cc.binghamton.edu> or <consp03@BINGVAXA.BITnet> | | #include <stddiscl.h> "Hackito ergo sum" - old Latin proverb | +-------------------------------------------------------------- ;-b --+
andy@cbmvax.commodore.com (Andy Finkel) (06/19/91)
In article <3118@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <22547@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy >Finkel) writes: >Since I am the one wrote the parallel device, would you mind telling me >what side effect you are claiming is being depended on? I cannot write a >valid reply without that information. > >In your opinion, was this side effect taken advantage of because I had access >to the source code, or because the documentation was unclear? Since the cia resource dependencies involved are *intentionally* not documented, the conclusion I reach is that use of the source was involved. Since the parallel.device is part of the OS this use would have been justifiable if intentional. But I believe the dependency was unintentional, judging from the lack of version checks or comments. > >Incidentally, there are only two modes in the parallel device. Interesting. I see PARF_SLOWMODE, PARF_ACKMODE, and PARF_FASTMODE defined in the public include files, and in the source, but you are right, it turns out that the PARF_SLOWMODE code is just duplicated code of the PARF_ACKMODE case. >Valentin andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "2.0 is not the answer. 2.0 is the question. Yes is the answer." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
riley@theory.TC.Cornell.EDU (Daniel S. Riley) (06/20/91)
In article <VINSCI.91Jun18030222@nic.nic.funet.fi>, vinsci@nic.funet.fi (Leonard Norrgard) writes: >Try to decide now, you just said that the OS wasn't ugly. Now you're >telling us the opposite. Do you mean that the OS relies on side >effects? Have you knowingly designed in side-effects? Hope you're all >walking encyclopedias, you must have some memory! Unless you >specifically documented the things as side-effects of course. But then >it wouldn't hurt anyone, devlopers *can* read comments if they *can* >read the code. A ridiculous argument. Peter says that OS routines may have side effects which developers should not depend on, and you somehow conclude that the OS depends on these side effects. Entirely specious... > BTW, are you aware that the September/October '90 Amiga Mail master >index for Amiga documentation listed 21 sources for Amiga technical >documentation (almost all originating from Commodore). What is this? >Distributed documentation? To "do the right thing" usually requires >being familiar with all of these. My hat is off to Ken Farinsky of >CATS for writing the x-ref, though. Guess what--even if you had the source, you *still* need all that documentation. The source only tells you what the implemented behavior is; you need the documentation to tell you what the defined behavior is. Programming to the implemented behavior without referring to the defined behavior of the OS is exactly why Commodore doesn't want to release the source. -- -Dan Riley (riley@theory.tc.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) (06/20/91)
In article <3098@public.BTR.COM>, valentin@public.BTR.COM (Valentin Pepelea) writes: > In article <22472@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy > Finkel) writes: >> >> [Andy's comments deleted...] > > Our discussion has been limited to whether publishing the source code is a > good idea. So far we have been given only the following reasons against it: > > 1. The copyright laws do not adequately protect you. > 2. Imbeciles might do imbecile things. > > Any other bright arguments? Yes. 1. Protectin of Commodore's proprietary work. They paid to have the Amiga operating system developed why should they 'give it away'? 2. You know as well as I do, that direct copying of the Amiga operating system would probably not be done, BUT, the ideas and the solutions in the code could/would be taken. It would be very difficult to prove that an individual 'stole' something. Do we really need to get Commodore's lawyers more work? 3. Releasing the source code does nothing to improve Commodore's situation. It would result in the locking of operating system down as the developers _will_ make use of a particular design of a function instead of using a 'black-box' approach. 4. Commodore is not in the business of 'teaching' programmers how to program. Commodore has no social responsibility for education. 5. If the source code is released as 'documentation' what would happen to the current documentation efforts? I think it much wiser to improve the documentation than to just say "ohh.. look at the source code". 6. It is a bad idea. Do you publish the source code to everything you write? Would you really spend two years of your life working on something for commercial use and then 'freely' give away the source? I hope so, because that is what you are asking Commodore to do. Actually you are asking Commodore to deliver for $100 seven years of work to your doorstep so you can 'learn'. That certainly would be a deal, but I suspect that would really put an end to the Amiga. What good would this new-found education be if the Amiga (as we know it) does not exist? Using your arguments it makes sense for the government to give us for $100 a complete and working nuclear weapon so that we can learn. ;-) What? Me worry... :-) > > In my opinion, the only reason that a company might have to not publish source > code is that it does not want to give other people the opportunity to learn > for studying the Amiga operating system. I'm not talking copying, since no > individual would be stupid to plagiarize, but rather to learn from other > people's mistakes and prevent any reoccurences. > > Valentin > -- > "An operating system without virtual memory Name: Valentin Pepelea > is an operating system without virtue." Phone: (408) 985-1700 > Usenet: mips!btr!valentin > - Ancient Inca Proverb Internet: valentin@btr.com On this virtual memory thing... you said in a earlier message that Commodore did not agree with your signature either. Is that really a surprise? I would _like_ virtual memory on the Amiga as long as: 1> I could turn it OFF! 2> It does not destroy the performance of the machine 3> If it doesn't break all the software In my opinion, memory is cheap. If I need more, I'll buy more. Let the Amiga 500 owners who want to process 24 bit graphic files in 512k of memory burn in hell. :-) :-) -mark= +--------+ ================================================== | ¥/ | Mark D. Manes "The Most lopsided deal since ..." | /¥ ¥/ | manes@vger.nsu.edu | / | (804) 683-2532 "Make up your own mind! - AMIGA" +--------+ ================================================== "I protest Captain! I am not a merry man!" - Lt. Worf
caw@miroc.Chi.IL.US (Christopher A. Wichura) (06/20/91)
In article <mykes.3658@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>> The apps that use routines done this way won't at all break under future >>> OS revs or anything. >> >>How do you know? > >Because you won't be relying on how the OS works. You will have code that is >guaranteed to work (as long as you allocate your resources correctly) embedded >in your application instead of external where CBM might muck it up. And what happens when we get DIG? If you've done an OwnBliter() and played your own little games instead of using graphics.library functions (or a combination thereof, as may be needed) then the chance for a DIG board to translate that blitter job to something of its own goes down the tubes. -=> CAW Christopher A. Wichura Multitasking. Just DO it. caw@miroc.chi.il.us (my amiga) ...the Amiga way... u12401@uicvm.uic.edu (school account)
rkushner@sycom.UUCP (Ronald Kushner) (06/20/91)
peter@cbmvax.commodore.com (Peter Cherna) writes: > >I agree there would be some benefit to some developers, for the source >code. On the other hand, just look at the reams of wonderful software >written for Amigas, MACs, Windows, etc. that do not have source code >available. There are plenty of developers out there capable of doing >fine work without source, and a good thing too. The cost to Commodore >in terms of what it will do to the future of the OS and the hardware >is significantly greater than any benefit you imagine might be reaped. > If the source was avaiable, I would be very worried that companies like MicroSoft or Apple with interests in destroying the future of the machine could put alot of programming effort into really cool applications that abuse routines and their side affects or flaws, and encourage others to do the same, just to cripple the evolution of the operating system. It just seems like a good way to slowly kill the competition... -- C-UseNet V0.42e Ronald Kushner Life in Hell BBS +1 (313) 939-6666 P.O. Box 353 14400 USR HST V.42 & V.42bis Sterling Heights, MI 48311-0353 Complete Amiga Support UUCP: uunet!umich!vela!sycom!rkushner (We are not satanic, just NUTS!) I KNOW, I LISTEN TO MARK SCOTT
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/20/91)
In article <caw.2101@miroc.Chi.IL.US> caw@miroc.Chi.IL.US (Christopher A. Wichura) writes: >In article <mykes.3658@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>>> The apps that use routines done this way won't at all break under future >>>> OS revs or anything. >>> >>>How do you know? >> >>Because you won't be relying on how the OS works. You will have code that is >>guaranteed to work (as long as you allocate your resources correctly) embedded >>in your application instead of external where CBM might muck it up. > >And what happens when we get DIG? If you've done an OwnBliter() and played >your own little games instead of using graphics.library functions (or a >combination thereof, as may be needed) then the chance for a DIG board to >translate that blitter job to something of its own goes down the tubes. Not really, there is a kludge (actually 2 kludges) that a board and DIG can add for "old" apps. 1) Have the board use Amiga chip ram for it's buffer 2) Copy the Amiga's screen(bitmap ram) occasionally to the board's onboard buffer (slow). Colorburst does this and so does the A2024. Colorburst is probably limited to 10hz refresh in it's highest res/color mode. >-=> CAW > >Christopher A. Wichura Multitasking. Just DO it. >caw@miroc.chi.il.us (my amiga) ...the Amiga way... >u12401@uicvm.uic.edu (school account) -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not ¥ | INET:r_cromwe@upr2.clu.net | ¥X/ in any way reflect the views of my self.| ¥ UUCP:uunet!tnc!m0023 * /
valentin@public.BTR.COM (Valentin Pepelea) (06/20/91)
In article <22570@cbmvax.commodore.com> mks@cbmvax.commodore.com (Michael Sinz) writes: > >[article omitted] You message was entirely an insult and personal attack on me. There is no place for such cynicism in a debate. If you are unable to discuss different options objectively, then refrain from discussing them at all. Next to Andy Finkel's personnal attack, there was yours. So far the rest of Usenet readers have been able to vigorously defend their point of view without getting personal. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/20/91)
In article <22523@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >In article <mykes.3594@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: > >>And to >>top it off, I get developer support materials that come with the disclaimer that >>any information contained within is subject to change without notice. > >Those are typically distributed in advance of the finalization of the spec. >At that time, I suppose you'd want pre-releases of source code. And >you honestly believe that preliminary source wouldn't have such a disclaimer? >Be serious, the documentation specification can be finalized long before >the last significant code changes. > Hey, if I could step through beta OS routines with CPR or SDB with FULL source, I would be able to give you REAL accurate bug reports. I could tell you what file had the bug, what the problem is, and what to change to fix the problem. >>Seeing the insides of routines is an awesome way to learn about programming in >>all aspects. > >Assuming the quality of the routines. The Amiga OS is pretty good, but >like any real-world product, it has it's ugly bits. There are also >multiple compilers and languages at play, including a few arcane >pre-processors. Make it all available in machine readable form. Just make sure it all makes... >Not only that, but the ROM-writers have certain special >priviledges not enjoyed by "external" software. For example, 2.0 >Intuition.library is guaranteed to have 2.0 graphics.library available. >Your routine based on source to 2.0 intuition.library doesn't have that >luxury. As well, if we make a hardware improvement to the Amiga, >we can alter the ROM at that time. Therefore we can leave code that's >technically incorrect according to the Amiga specification but is 100% >correct for all existing machines. We get to change it before the new >machine is out. You can't. Nevertheless, we haven't done anything >wrong in the ROM. > The rules for writing applications are well known, and you are always going to have to rely on us developers to tiptoe around the ugly bits. Some of the ulginess might get shaken out even. How about warning us developers way in advance of any hardware changes, so we can prepare our source code as correctly as possible as early as possible. >>It is also a good source to start from if you need a routine similar >>to one in the OS. Consider the case where you want to do BltMaskBitMapBitMap(), >>which the OS doesn't have. > >Developer support can provide information on how to proceed. The answers >they give are sometimes based on their inspection of the source. If you >don't ask, you'll never find out. > When I see the source, it is like the programmer speaking directly to me in the most natural language available for expressing algorithms. The transfer of this level of understanding of the source code through a third party is nowhere as good as seeing the code. >>Seeing the insides of routines doesn't encourage me to rely on the action of what >>an OS call does. > >Good for you. However, that doesn't mean there are no people unlike you. >As well, even though we can list dozens of ways in which you could incorrectly >rely on the action of a particular implementation, one doesn't need to be >too clever to accidentally stumble on a different dependency that one >doesn't even recognize until it's too late. > Let the reviewers flame away. Good products should get support for a long time to come. Some products have already been supported for years already. As these apps mature with your OS, you get progress. >We guarantee the functional and structural interface, not the implementation. >Therefore, it is entirely natural that we publish the former, and not >make the latter available. Put all the disclaimers you want on the source code. Why not put the RKM in machine readable form, too? There are a lot of program fragments that would be nice to be able to cut and paste from. An on-line manual with documented source could be put on CD-ROM and would be an excellent thing to go with a CD Drive machine. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
valentin@public.BTR.COM (Valentin Pepelea) (06/20/91)
In article <22582@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: > >>Since I am the one wrote the parallel device, would you mind telling me >>what side effect you are claiming is being depended on? I cannot write a >>valid reply without that information. >> >>In your opinion, was this side effect taken advantage of because I had access >>to the source code, or because the documentation was unclear? > >Since the cia resource dependencies involved are *intentionally* >not documented, the conclusion I reach is that use of the source >was involved. Since the parallel.device is part of the OS this >use would have been justifiable if intentional. But I believe >the dependency was unintentional, judging from the lack of version >checks or comments. I have asked you already once to tell me what side effect your are claiming is being depended on. If you refuse to divulge it, I have to conclude that this is false, and that you have decided to make a personal attack. You did not like to see me disagreeing with you, and therefore you thought that a stab at my reputation would do the trick. I have attempted to remain as objective as I can in this debate. I do not have the intention of hurting Commodore's reputation in any way. It is in my personal best interest after all, to be known as someone who was part of a great development team, rather than a party to history's buggiest operating system. Again, I demand that you tell us what the alleged side effect is. >>Incidentally, there are only two modes in the parallel device. > >Interesting. I see PARF_SLOWMODE, PARF_ACKMODE, and PARF_FASTMODE defined >in the public include files, and in the source, but you are right, it turns >out that the PARF_SLOWMODE code is just duplicated code of the PARF_ACKMODE >case. The PARF_ACKMODE was brain damaged. It was removed in winter 1990. The definition and check remained there for possible backward compatibility. The ACK mode was the subject was the most vigorous debate we had over the parallel device, and therfore am suprised you have forgotten about it. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/20/91)
In article <22538@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >We can (and do) change the ROM when new hardware or software comes >out, and _every_ user of an Amiga has an appropriate ROM. The same >cannot be said for application software. > When CBM acts, developers react. The programs that get real use are all getting 2.0 compatibility and are supporting new CBM AND 3rd party hardware. The same and MORE can be said about application software. An application might be updated 3 or 4 times by the time CBM comes out with another significant release of the OS (after 2.0). -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
vinsci@nic.funet.fi (Leonard Norrgard) (06/21/91)
In article <1991Jun19.171539.5525@batcomputer.tn.cornell.edu> riley@theory.TC.Cornell.EDU (Daniel S. Riley) writes: In article <VINSCI.91Jun18030222@nic.nic.funet.fi>, vinsci@nic.funet.fi (Leonard Norrgard) writes: >Try to decide now, you just said that the OS wasn't ugly. Now you're >telling us the opposite. Do you mean that the OS relies on side >effects? Have you knowingly designed in side-effects? Hope you're all >walking encyclopedias, you must have some memory! Unless you >specifically documented the things as side-effects of course. But then >it wouldn't hurt anyone, devlopers *can* read comments if they *can* >read the code. A ridiculous argument. Peter says that OS routines may have side effects which developers should not depend on, and you somehow conclude that the OS depends on these side effects. Entirely specious... Reread it. The argument is rather simple: the os has, of course, built-in side-effects (without them, some things would be terribly ineffective). So that the WC people know why this code is there, it has to be documented as side-effects, when they knowingly rely on them. If they weren't documented, I'm sure they'd all tear their hair out each day. However, the last time I saw the team, they weren't bold, so I assume that is false and thus side-effects are documented. Well, system/application programmers aren't different from os designers/programmers. If *one* can read those comments, then the other can as well. Seems like a dead horse to me. :-) > BTW, are you aware that the September/October '90 Amiga Mail master >index for Amiga documentation listed 21 sources for Amiga technical >documentation (almost all originating from Commodore). What is this? >Distributed documentation? To "do the right thing" usually requires >being familiar with all of these. My hat is off to Ken Farinsky of >CATS for writing the x-ref, though. Guess what--even if you had the source, you *still* need all that documentation. The source only tells you what the implemented behavior is; you need the documentation to tell you what the defined behavior is. Nobody has disagreed on this point. The usefulness of source code are in the debugging area, avoiding the re-invent-the-wheel syndrome, making good choises of what routines to actually use (relative timing, and before you scream: I'd rather call the faster routine with this version of the os and risk loosing speed in a future version: that can be optimized in upgrades, which are inevitable anyway. Calling the slower thing now is definitely more costly). Programming to the implemented behavior without referring to the defined behavior of the OS is exactly why Commodore doesn't want to release the source. Why do they release the OS then, when people write viruses for it? The answer is that you'll never be 100% secure anywhere or with anything. Knowing this, they take the risk (not much choice there anyway :-). Let's assume that source was available. Let's also assume, for the sake of your argument, that a programmer reading the os source notes an (undocumented) side-effect in a routine. What would happen: a) Since the programmer always tries to cause CBM as much harm as possible, he proceeds to make worst possible use of the side-effect, knowing it will explode in his face anytime. b) Noting that the side-effect might at some point hurt the program he's writing, or CBM's business and thus indirectly his own business, the programmer duly reports his findings to bugs@commodore.com and the things get fixed or documented if the side-effect is intentional. c) Seeing that the world isn't perfect, the programmer makes suicide since the bugs will never end anyway. :-) d) Nothing, because the programmer doesn't know what a side-effect is and wouldn't recognize it even if it was documented. My bet is for case b) for most people programming this machine. Not many of us are sadists after all. So let's assume source isn't available. Our brave programmer, fighting his way through guru meditations finally gets his program to run as it is supposed to. In calling FooBar(), which actually contains a side-effect nobody is aware of yet, he happens to rely on said side-effect. What happens: a) Nothing. Nobody knows about any problems. No os bugs is reported. Nobody else gains from the os bug report, since it couldn't be done. b) Nothing at first, but then the program suddenly blows up after an OS revision. Nobody knows why. Otherwise like a). My personal preference happens to be with the source scenario. To every developer it is quite clear that the os isn't bug free. When more people can read the source, it means that bugs will be found sooner. *That* will benefit all of us. Maybe the whole argument is just about what effects you choose to be concerned about and how you weigh them. The negative approach is to concentrate on what possible harm could be done. The positive approach is to concentrate on the things than can be achieved. I'm quite proud of having a positive attitude to most things. But then, that's all personal. The above is also why you may see more of me working on unix, X11 and Sather than AmigaDOS in the future. Not that I don't like the Amiga, but unneccessary obstacles like no source availability sure makes it hard to justify. *Where is* that protected and virtual memory anyway? Followups directed to poster. I won't waste any more energy on this for now. At least CBM knows how we feel about it, maybe they'll change their mind sometimes in the future. For now, I'll concentrate on systems whose designers saw the source light long ago. -Dan Riley (riley@theory.tc.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University -- Leonard
mks@cbmvax.commodore.com (Michael Sinz) (06/21/91)
In article <3136@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <22570@cbmvax.commodore.com> mks@cbmvax.commodore.com (Michael >Sinz) writes: >> >>[article omitted] > >You message was entirely an insult and personal attack on me. Not completely... Just on your position on this issue and your stedfast refusal to see the other side. >There is no place for such cynicism in a debate. If you are unable to discuss >different options objectively, then refrain from discussing them at all. I guess you did not get the point: Let me state it another way... "Enough already!" -- Mike /----------------------------------------------------------------------¥ | /// Michael Sinz - Amiga Software Engineer | | /// Operating System Development Group | | /// BIX: msinz UUNET: rutgers!cbmvax!mks | |¥¥¥/// | | ¥XX/ "I think not." said Ren'e Descartes, then he vanished. | ¥----------------------------------------------------------------------/
andy@cbmvax.commodore.com (Andy Finkel) (06/21/91)
In article <3137@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <22582@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy >I have asked you already once to tell me what side effect your are claiming >is being depended on. > >If you refuse to divulge it, I have to conclude that this is false, and that >you have decided to make a personal attack. You did not like to see me >disagreeing with you, and therefore you thought that a stab at my reputation >would do the trick. > Sorry you viewed it as a personal attack. I carefully did not mention anything about the authorship of the 2.0 parallel.device, but attempted to use an example that you would understamd. >Again, I demand that you tell us what the alleged side effect is. This is the last word I'm going to say on this, and just as a favor I will remind you of the cia resource loop back mode which is found in only one of the interrupt chains. (Remember now ?) andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "2.0 is not the answer. 2.0 is the question. Yes is the answer." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
srwmcln@windy.dsir.govt.nz (06/21/91)
In article <3136@public.BTR.COM>, valentin@public.BTR.COM (Valentin Pepelea) writes: > In article <22570@cbmvax.commodore.com> mks@cbmvax.commodore.com (Michael > Sinz) writes: >> >>[article omitted] > > You message was entirely an insult and personal attack on me. That was not so much a personal attack, but evidence that your own arguments are flawed. It might be interesting to see more Amiga source from CA, but with a vast population of hackers out there, and very little communication between software providers and users, then being able to get source would just produce a real maintainance nightmare for Commodore and others. The statements from your (old/previous) friends/? at Commodore suggests that team software developement by them, is non existant or has some other problems, or was it that you were too inexperienced to ask/know about the rules. I help support some software products for Vax VMS, and in one case we use nonpublic info to make our software appear better integrated, but we have to remember that at each new release of the DEC system software we may have to fix our software and ship it to all our customers,fortunatily there are few customer (not >2,000,000) and DEC's software is very stable in the area where we cheated. Lets stop this thread about public source for Commodore software and get on with the real issues to make these systems greater. Clive.
dillon@overload.Berkeley.CA.US (Matthew Dillon) (06/22/91)
In article <3137@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <22582@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy >Finkel) writes: >> >>>Since I am the one wrote the parallel device, would you mind telling me >>>what side effect you are claiming is being depended on? I cannot write a >>>valid reply without that information. >>> >>>In your opinion, was this side effect taken advantage of because I had access >>>to the source code, or because the documentation was unclear? >> >>Since the cia resource dependencies involved are *intentionally* >>not documented, the conclusion I reach is that use of the source I'm not sure what this particular discussion is about, but I have had NO trouble using the cia or misc resources to allocate and use the parallel port myself. The only problem with the parallel.device that I have had is that it insists on hanging on to the resources until flushed instead of mearly closed. I use the CIA autodocs and hardware reference manual. This is related to the ParNet code. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
es1@cunixb.cc.columbia.edu (Ethan Solomita) (06/23/91)
In article <mykes.3678@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > >Hey, if I could step through beta OS routines with CPR or SDB with FULL source, >I would be able to give you REAL accurate bug reports. I could tell you what file >had the bug, what the problem is, and what to change to fix the problem. > Sure, you could. But then, how many programmers are willing to spend time doing that volunteer work for Commodore? -- Ethan "...Know-Nothing-Bozo the Non-Wonder Dog, an animal so stupid that it had been sacked from one of Will's own commercials for being incapable of knowing which dog food it was supposed to prefer, despite the fact that the meat in all the other bowls had engine oil poured all over it."
elg@elgamy.raidernet.com (Eric Lee Green) (06/26/91)
From article <mykes.3678@amiga0.SF-Bay.ORG>, by mykes@amiga0.SF-Bay.ORG (Mike Schwartz): > Hey, if I could step through beta OS routines with CPR or SDB with FULL source, > I would be able to give you REAL accurate bug reports. I could tell you what file > had the bug, what the problem is, and what to change to fix the problem. > Make it all available in machine readable form. Just make sure it all makes... Hah! CPR would blow up (debug stuff is too gruesome), and I don't know if you have enough hard drive space for the full source anyhow :-). (It's all done using a huge NFS partition on their VAX). Not to mention that some of the tools they use don't even run on the Amiga (like GreenHills "C", which a few parts of the OS are still written in). > Put all the disclaimers you want on the source code. Why not put the RKM in machine > readable form, too? There are a lot of program fragments that would be nice to be > able to cut and paste from. An on-line manual with documented source could be put The RKM source code available on the Fish disks and on BIX. I have it sitting on my DH1: partition. Comes in handy, for snipping parts of their console-handling code etc... -- Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg