mks@cbmvax.commodore.com (Michael Sinz) (06/11/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. 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. In addition to the disaster (see below), why should we release to the public part of the secrets that make the Amiga what it is? Why should we "give away" the many hundreds of thousands of hours of work and design that C= has paid for and is hoping makes the Amiga a better machine than many of the others? >>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? This is only part of the reason... >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... :) Ah, but if your code works correctly, you should not care. Not only that, but if we need to change the OS, you better not care. Here is where a major reason comes from. Imagine if, by looking at the source you saw some side-effect of a routine and the started to count on it. (For example, the form of code used to RectFill()) Now, as we get either new hardware or a better way to do a RectFill(), we change RectFill() to work as documented only under the new method/hardware/etc. What happens when you break? Is it our fault? No. Do we get the blame; bad press; flames? Yes. Do we like this? *NO* >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... Ah, but is this from Apple or did some 3rd party disassemble the ROM and add his own comments? Also, you may note that Apple does not take too kindly to this sort of operation but they have rather little recourse. /----------------------------------------------------------------------\ | /// Michael Sinz - Amiga Software Engineer | | /// Operating System Development Group | | /// BIX: msinz UUNET: rutgers!cbmvax!mks | |\\\/// Programming is like sex: | | \XX/ One mistake and you have to support it for life. | \----------------------------------------------------------------------/
valentin@btr.BTR.COM (Valentin Pepelea valentin@btr.com) (06/12/91)
In article <22326@cbmvax.commodore.com> mks@cbmvax.commodore.com (Michael Sinz) writes: >>>> >>>> Please explain what is so bad about releasing the source code ? I >>>> don't see your point. > >In addition to the disaster (see below), why should we release to the >public part of the secrets that make the Amiga what it is? Why should >we "give away" the many hundreds of thousands of hours of work and design >that C= has paid for and is hoping makes the Amiga a better machine than >many of the others? This argument is invalid. The source code of the OS is protected by copyrights. You may show it, list it, publish it, distribute photocopies of it, let the entire universe see and analyse it, and you will still hold the copyright onto it, preventing others to use it without your permission. >>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... :) > >Ah, but if your code works correctly, you should not care. Not only that, >but if we need to change the OS, you better not care. Here is where a >major reason comes from. You are missing the point. Looking at the source code will give the reader a much better understanding of what a function does then those foggy autodocs. It will in no way encourage the misuse of these functions. Many full page autodocs explain the actions of a mere 5 line routine. I recommend to everybody to seek out Markus Wandel's disassembly of the Exec if they wish to understand the inner workings of the OS. 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
DXB132@psuvm.psu.edu (06/13/91)
In article <3034@public.BTR.COM>, valentin@btr.BTR.COM (Valentin Pepelea valentin@btr.com) says: >I recommend to everybody to seek out Markus Wandel's disassembly of the Exec >if they wish to understand the inner workings of the OS. I second this recommendation! There is also a German book called 'Dr. Ruprechts Kommentiertes Rom- Listing' that I use -- although Markus's is generally much more detailed. -- Dan Babcock
dillon@overload.Berkeley.CA.US (Matthew Dillon) (06/13/91)
In article <3034@public.BTR.COM> valentin@btr.BTR.COM (Valentin Pepelea valentin@btr.com) writes: >In article <22326@cbmvax.commodore.com> mks@cbmvax.commodore.com (Michael >Sinz) writes: >>>>> >>>>> Please explain what is so bad about releasing the source code ? I >>>>> don't see your point. >>.. > >You are missing the point. Looking at the source code will give the reader >a much better understanding of what a function does then those foggy >autodocs. It will in no way encourage the misuse of these functions. Many full >page autodocs explain the actions of a mere 5 line routine. > >I recommend to everybody to seek out Markus Wandel's disassembly of the Exec >if they wish to understand the inner workings of the OS. > >Valentin I am sure that many of us would use the source for appropriate purposes. Unfortunately, a greater number will definitely misuse it in major ways. Apart from recompiling it with 'enhancements', many hacker types will begin utilizing side effects they discover in the source that are not officially supported, or be more inclined to run direct ROM calls. The source should NOT be made available. The point is moot anyway since Commodore isn't about to release it anyway :-) By the way, I do not believe it is legal for Markus to disassemble Exec and publish the results, there are several clauses relating to this in Commodore's copyright statement. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
ins760z@monu4.cc.monash.edu.au (mr c.r. hames) (06/14/91)
In article <91164.020625DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >In article <3034@public.BTR.COM>, valentin@btr.BTR.COM (Valentin Pepelea >valentin@btr.com) says: > >>I recommend to everybody to seek out Markus Wandel's disassembly of the Exec >>if they wish to understand the inner workings of the OS. > >I second this recommendation! >There is also a German book called 'Dr. Ruprechts Kommentiertes Rom- >Listing' that I use -- although Markus's is generally much more >detailed. > >-- Dan Babcock So who's going to do 2.?? when its ROM (soon please!) I know I will be doing Exec if no one else does it. 512k is a hard slog so how about we divide it up...... Get ReSource fired up! -- Chris Hames Person to blame for DirWork(1.3 RSN), VMK, FSDirs, etc And soon for PC-Task? ins760z@monu4.cc.monash.edu.au
<LEEK@QUCDN.QueensU.CA> (06/14/91)
In article <dillon.8625@overload.Berkeley.CA.US>, dillon@overload.Berkeley.CA.US (Matthew Dillon) says: > > The source should NOT be made available. The point is moot anyway since > Commodore isn't about to release it anyway :-) > Agreed. > By the way, I do not believe it is legal for Markus to disassemble Exec > and publish the results, there are several clauses relating to this in > Commodore's copyright statement. > He didn't exactly disassembled exec and give it away to everybody. What he did was to distribute the comments portion of the disassembly. You run the disassembler on your machine and there is a second program that recombines them to give you the commented dissembled code. The programs only works with 1.2 exec library by the way and it was on fred fish disk for a long while. I am not a lawyer so I can't tell you whether or not this is legal. I just want to clarify things a little bit. Now if dissambling ROM is illegal then the person running it also is breaking the law. > -Matt >-- > > Matthew Dillon dillon@Overload.Berkeley.CA.US > 891 Regal Rd. uunet.uu.net!overload!dillon > Berkeley, Ca. 94708 > USA > K. C. Lee "2.0 is not the question. The question is WHEN ?" -me. :) Be patient !!
ken@cbmvax.commodore.com (Ken Farinsky - CATS) (06/14/91)
>In article <3034@public.BTR.COM>, valentin@btr.BTR.COM says: >>I recommend to everybody to seek out Markus Wandel's disassembly of the Exec >>if they wish to understand the inner workings of the OS. > >I second this recommendation! >-- Dan Babcock I would like to recommend that you ignore any disassembly of the ROM, throw away your hardware manuals and treat the OS as a black box. I know this is not possible in some cases, but doing so will provide maximum compatibility with future versions of the OS. If you rely on ANY undocumented details, then you make it much harder for Commodore to upgrade the OS. Please follow the documentation. Don't assume what unused bits do. Don't test values to see what happens. If you have a problem which has no documented solution, ask! If you find a bug in the RKMs, report it. -- Ken Farinsky - CATS - Commodore Business Machines
espie@ibis.Stanford.EDU (Marc Espie) (06/15/91)
In article <22451@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: >>In article <3034@public.BTR.COM>, valentin@btr.BTR.COM says: >>>I recommend to everybody to seek out Markus Wandel's disassembly of the Exec >>>if they wish to understand the inner workings of the OS. >> >>I second this recommendation! >>-- Dan Babcock > >I would like to recommend that you ignore any disassembly of the ROM, >throw away your hardware manuals and treat the OS as a black box. >I know this is not possible in some cases, but doing so will provide >maximum compatibility with future versions of the OS. If you rely >on ANY undocumented details, then you make it much harder for >Commodore to upgrade the OS. > >Please follow the documentation. Don't assume what unused bits do. >Don't test values to see what happens. If you have a problem which has >no documented solution, ask! If you find a bug in the RKMs, report it. >-- >Ken Farinsky - CATS - Commodore Business Machines Something I would like to see in the next release of the manuals is a deeper emphasis on overhead issues, for instance how much time does it take to get through a given interrupt server ? Will that break in the future, or can we expect the overhead to stay the same ? Some time-critical applications (like music playing) are for now very difficult to do in an unbreakable way. I would also appreciate to get more caveats related to that problem. For instance, explain that relying on interrupts will probably break any serial communication program running at high speed. Right now, it's impossible to know what will happen except by running the program, which is not very easy unless you happen to have a high-speed serial line available... Some other solutions to typical problems should be in the manuals. My feeling is that some hardware hackers refer to the hardware manual because there is a lot of guesswork in the current RKMs. For instance: stealing the mouse from intuition requires playing with the input.device. This should be documented in the intuition part of the manual (like a ``getting rid of intuition'' paragraph), not as a sidenote in the input.device chapter. Then people wouldn't bang the hardware directly in such cases. (I know, I'm dreaming...) ---- Marc Espie (espie@flamingo.stanford.edu)
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (06/16/91)
In recent articles, people have asked Commodore to release the
source code of the operating system. Since Commodore has decided not to
do this, I thought it would get the ball rolling by releasing the source
code to BLAZEMONGER.
As you are well aware, BLAZEMONGER is the fastest program ever
written. On the average, it is finished running just slightly before you
reach for your joystick. (Don't worry... it's usually faster in practice.)
We figured that the source code would prove instructive to young
hardware-bangers eager for MAXIMUM SPEED, but still not sure how to get it.
(Hint: you're doing it WRONG.) And next, who knows: perhaps other
companies will release THEIR source code too! Then we can all laugh and see
how STUPID it is compared to BLAZEMONGER's ultimate form.
Aren't we worried about BLAZEMONGER clones being written now, as
EVIL, WIMPY companies steal our source code and incorporate it into their
own games? GET REAL!!! We fear NOTHING!! In fact, if anybody tries to use
even ONE BYTE of BLAZEMONGER code in their programs, even modified beyond
recognition, we will know. Trust us, we'll know. You don't want to do this.
It will be very bad for your, uh, health. So much for the "legal-ese"
portion of our posting.
So, without further ado, here it is: the SOURCE CODE FOR
BLAZEMONGER, THE FASTEST PROGRAM EVER WRITTEN!! It is in uuencoded
format. Simply save it in a file and type "uudecode filename" to
decode it.
------------8<----------------- cut here ----------------8<------------------
begin 644 BLAZEMONGER.X
end
------------8<----------------- cut here ----------------8<------------------
Enjoy!!
Dan
//////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| Dan Barrett - Systems Administrator, Computer Science Department |
| The Johns Hopkins University, 34th and Charles Sts., Baltimore, MD 21218 |
| INTERNET: barrett@cs.jhu.edu | |
| COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP |
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////rsm@delfax.Amiga.OCunix.On.Ca (Rick Morrow) (06/16/91)
In article <dillon.8625@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > > By the way, I do not believe it is legal for Markus to disassemble Exec > and publish the results, there are several clauses relating to this in > Commodore's copyright statement. > > -Matt >-- > > Matthew Dillon dillon@Overload.Berkeley.CA.US > 891 Regal Rd. uunet.uu.net!overload!dillon > Berkeley, Ca. 94708 > USA > -- Marcus didn't publish a _disassembly_ of Exec. What he released was a text file of comments that related to specific positions in a disassembly of the Exec, and a program that would disassemble the _user's_ Exec and tack the comments on in the appropriate places, leaving the user with a text file that consisted of a commented disassembly of the Exec. There was absolutely _NO_ Exec code in the program he released. He even included appropriate disclaimers to the effect that it would only work with 1.2, and that this just represented _his_ idea of what was going on, and in no way was to be considered _official_ information. Let's make sure we have our facts straight before we start flinging the arrows, ok people? -Rick ------------------- Rick Morrow, Ottawa Ontario Canada Internet....rsm@delfax.Amiga.OCunix.On.Ca, Fido Net....1:163/109.31 Quote: "I yamm what I yamm!"......Popeye.. =-) ------------------- -Rick ------------------- Rick Morrow, Ottawa Ontario Canada Internet....rsm@delfax.Amiga.OCunix.On.Ca, Fido Net....1:163/109.31 Quote: "I yamm what I yamm!"......Popeye.. =-) -------------------
mt87692@cc.tut.fi (Mikko Tsokkinen) (06/16/91)
In article <22451@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: > >In article <3034@public.BTR.COM>, valentin@btr.BTR.COM says: > >>I recommend to everybody to seek out Markus Wandel's disassembly of the Exec > >>if they wish to understand the inner workings of the OS. > > > >I second this recommendation! > >-- Dan Babcock > I would like to recommend that you ignore any disassembly of the ROM, > throw away your hardware manuals and treat the OS as a black box. [ more about the os deleted ] The disassebly of the exec is very useful if for example your amiga hangs on bootup and has a yellow screen. Also disassembling of the ROM was necessary with the old hardware manual which didn't tell you what was the sign bit in blitter drawing (it was quite obvious afterall :-) and it was rather unclear on many other areas too (like MFM coding). Mit -- Bubble Bobble
mks@cbmvax.commodore.com (Michael Sinz) (06/17/91)
In article <22451@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: >>In article <3034@public.BTR.COM>, valentin@btr.BTR.COM says: >>>I recommend to everybody to seek out Markus Wandel's disassembly of the Exec >>>if they wish to understand the inner workings of the OS. >> >>I second this recommendation! >>-- Dan Babcock > >I would like to recommend that you ignore any disassembly of the ROM, >throw away your hardware manuals and treat the OS as a black box. >I know this is not possible in some cases, but doing so will provide >maximum compatibility with future versions of the OS. If you rely >on ANY undocumented details, then you make it much harder for >Commodore to upgrade the OS. > >Please follow the documentation. Don't assume what unused bits do. >Don't test values to see what happens. If you have a problem which has >no documented solution, ask! If you find a bug in the RKMs, report it. >-- >Ken Farinsky - CATS - Commodore Business Machines What he said, and then some! We spent the last 6 months doing mainly compatibility work, finding out what strange and twisted code is out there and assuming things about the OS. Over all, I think maybe a year of development effort went into keeping programs working. Now, I am not saying it was not good for the OS. We have made major steps forward, but it does make life rather difficult. If you wish to see the OS grow, then use the documentation. If the documentation is not enough, ask. If you can not program the system from the documentation and any clarification given by CATS or Engineering, then the source code would be of no help. It is rather foolish to think that the source would be a better way to understand what a function does. Many (most) times, the amount of time it would talk (and skill) to understand all of the aspects of a piece of code is many orders of magnitude more than just reading the documenation. -- Mike /----------------------------------------------------------------------\ | /// Michael Sinz - Amiga Software Engineer | | /// Operating System Development Group | | /// BIX: msinz UUNET: rutgers!cbmvax!mks | |\\\/// Programming is like sex: | | \XX/ One mistake and you have to support it for life. | \----------------------------------------------------------------------/
rbabel@babylon.rmt.sub.org (Ralph Babel) (06/18/91)
In article <3095@public.BTR.COM>, valentin@public.BTR.COM (Valentin Pepelea) writes: > What imbeciles are going to do with a very usefull tool is > irrelevant. Quite a few people consider nuclear fission a very useful tool. I'm fairly sure that most of them do not agree with you - fortunately. > Kitchen knives are very useful, yet many use them to kill > people. Are we going to stop manufacturing kitchen knives > for that reason? > > In the same light, we might then argue for/againt the > banning of guns, but that is another story. I have yet to try cutting my tofu with a gun ... well, maybe a laser gun would do. Followups to comp.sys.amiga.advocacy, alt.desert-shield, talk.politics, alt.flame, or rec.food.veg, as you see fit. Ralph
aduncan@rhea.trl.OZ.AU (Allan Duncan) (06/18/91)
From article <22497@cbmvax.commodore.com>, by mks@cbmvax.commodore.com (Michael Sinz): [...] > If you can not program the system from the documentation and any clarification > given by CATS or Engineering, then the source code would be of no help. > It is rather foolish to think that the source would be a better way to > understand what a function does. Many (most) times, the amount of time > it would talk (and skill) to understand all of the aspects of a piece of > code is many orders of magnitude more than just reading the documenation. I agree that the source alone is not the way to go, but it can give the occasional _insight_ into a problem. Case in point - I was doing some work with the parallel port and interrupts. Now what I wanted to did not appear in _any_ examples, either RKM or Fish that I could find. What I could find that were analogous on the surface were misleading. The long shot of it was that I finally got the clues necessary to understand the RKM's very brief and scatttered info on the topic and hints from queries here by walking the interrupt process starting at the vectors themselves. The clarity of vision that resulted fixed all my misunderstandings at once. It also showed me that a 7MHz 68000 is sailing pretty close to the wind at high interrupt loads. Allan Duncan ACSnet a.duncan@trl.oz (+613) 541 6708 Internet a.duncan@trl.oz.au UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
valentin@public.BTR.COM (Valentin Pepelea) (06/18/91)
In article <1070.285770a5@vger.nsu.edu> manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) writes: > >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. First of all, only AT&T does such a thing to my knowledge. Secondly, *most* software packages come with an additional licensing agreement thrown into the box, even if no source code is included? Why? The software industry is still young, and therefore lawyers fell the need to protect their companies right with additional mubo jumbo. Either that, or they just need a way to justify their bills. >Releasing the source would be like 'putting ones laundry out'. I see >no advantage for Commodore to do this. Do you? In my opinion, Commodore's source code is not that ugly. But perhaps you have previously heard that releasing a list of known bugs would be "putting one's laundry out." But then Sun does exactly that, to the relief of many developers. Actually, it might be illegal to conceal the existence and nature of such deficiencies in products, but that is another subject. >> "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.. :-) And so does Commodore, but the competition will eventually force them to adopt my stance. 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 <dillon.8625@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > > I am sure that many of us would use the source for appropriate purposes. > > Unfortunately, a greater number will definitely misuse it in major > ways. What imbeciles are going to do with a very usefull tool is irrelevant. Kitchen knives are very useful, yet many use them to kill people. Are we going to stop manufacturing kitchen knives for that reason? In the same light, we might then argue for/againt the banning of guns, 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
mcr@Sandelman.OCUnix.on.ca (Michael Richardson) (06/18/91)
In article <22451@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: >>In article <3034@public.BTR.COM>, valentin@btr.BTR.COM says: >>>I recommend to everybody to seek out Markus Wandel's disassembly of the Exec >>>if they wish to understand the inner workings of the OS. >> >>I second this recommendation! >>-- Dan Babcock > >I would like to recommend that you ignore any disassembly of the ROM, >throw away your hardware manuals and treat the OS as a black box. While this is good advice generally, it doesn't help you when you are trying to debug a program with a memory leak/clobber via RomWack after it has crapped out in an OS routine somewhere. Knowing that 0xfc800a (a random number) is somewhere in Wait() versus ReplyMsg() is rather valuable. To my knowledge, even if I had an MMU equipped machine, I still can't walk into my dealer and buy Unix. My dealer has started asking ME for Unix help. I have no source to my 2090's hddisk device (doesn't autoboot, but neither do my 1.2 roms) -- I'd write a Unix disk driver for my 2090 if I had a commented source code for hddisk.device. Which reminds me -- my disassembly of hddisk.device is half done. Will I have to go through the same song and dance that Markus had to go through with his 1.2 disassembly? >on ANY undocumented details, then you make it much harder for >Commodore to upgrade the OS. When will CA= fix the serial.device? OpenDevice/CloseDevice is not good enough for DTR control given shared mode. Until then, we gotta hit the hardware to hang the modem up reliably. ASDG went and defined a number of control options, and documented them. Until we can get better turn-around for feature requests, a good knowledge of the OS is the only way find the right work-around. (Like when will I get a reliable System() command? 2.0 doesn't count -- my dealer doesn't have it, so I can't tell a customer to upgrade in order to use my program) I really wish the ROMs were getting smaller, not bigger. >Please follow the documentation. Don't assume what unused bits do. >Don't test values to see what happens. If you have a problem which has >no documented solution, ask! If you find a bug in the RKMs, report >it. If only I could remember all the problems which had no documented solutions. Here is one: How do I allocate 16 bit (Zorro II accessible) RAM on a 3000? So it might be CHIP ram, that's too bad about the speed, but I might also have 2 meg of on my DMA data acquisition board. Sorry -- but in my impression you belabour the point of following the RKMs. To those that would listen, it is an old tune. To those that won't, well, their A500 is just a bigger C-64 to them anyway. Markus Wandel put a lot effort into that disassembly, and put even more effort into making it redistributable. I have found it invaluable in understanding how my Amiga works. I just wish CA= had released that beta of 2.0 that I heard was almost entirely pure. -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so little time. HOME: mcr@sandelman.ocunix.on.ca Bell: (613) 237-5629 Small Ottawa nodes contact me about joining ocunix.on.ca!
es1@cunixb.cc.columbia.edu (Ethan Solomita) (06/18/91)
In article <3095@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <dillon.8625@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >> >> I am sure that many of us would use the source for appropriate purposes. >> >> Unfortunately, a greater number will definitely misuse it in major >> ways. > >What imbeciles are going to do with a very usefull tool is irrelevant. Kitchen >knives are very useful, yet many use them to kill people. Are we going to stop >manufacturing kitchen knives for that reason? > But, then again, the kitchen knife is not a copyrighted product. Commodore's source code is. That gives Commodore the right to decide, based on their financial goals, whether it is beneficial for THEM to release the code. That IS capitalism after all. Commodore is the only group authorized to release that source, whereas I could (well, if I had a factory) go out and make knives. Apples and oranges. -- 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."
jms@vanth.UUCP (Jim Shaffer) (06/19/91)
In article <dillon.8625@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > > By the way, I do not believe it is legal for Markus to disassemble Exec > and publish the results, there are several clauses relating to this in > Commodore's copyright statement. But Markus isn't publishing the disassembly. He's distributing a program that disassembles Exec and adds comments to it. At least, that's how it's *supposed* to be distributed. -- * From the disk of: | jms@vanth.uucp | "Let's become Jim Shaffer, Jr. | amix.commodore.com!vanth!jms | alive again." 37 Brook Street | uunet!cbmvax!amix!vanth!jms | Montgomery, PA 17752 | 72750.2335@compuserve.com | --Yes
mbs@turing.acs.virginia.edu (Michael B. Smith) (06/19/91)
In article <3094@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <1070.285770a5@vger.nsu.edu> manes@vger.nsu.edu ((Mark D. Manes), >Norfolk State University) writes: >> >>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. > >First of all, only AT&T does such a thing to my knowledge. Secondly, *most* >software packages come with an additional licensing agreement thrown into >the box, even if no source code is included? Why? The software industry is >still young, and therefore lawyers fell the need to protect their companies >right with additional mubo jumbo. Either that, or they just need a way to >justify their bills. > >Valentin What? Most of the mainframe manufacturers require signing pretty hefty legal-type agreements which (in at least Unisys' case) specifically PROHIBIT any disassembly or decompilation of any object or source provided, except for the specific use of the licensee. For many things, you can't get sources anymore, and to get what you can, a hefty premium is paid. It isn't just AT&T. Most of those licenses come out of long term experience in the mainframe software marketplace, plus additional experience gained in the last ten years in the micro/mini world. The software industry isn't really young. It is as old as computers themselves. Michael >-- >"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
dillon@overload.Berkeley.CA.US (Matthew Dillon) (06/19/91)
In article <3095@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <dillon.8625@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >> >> I am sure that many of us would use the source for appropriate purposes. >> >> Unfortunately, a greater number will definitely misuse it in major >> ways. > >What imbeciles are going to do with a very usefull tool is irrelevant. Kitchen >knives are very useful, yet many use them to kill people. Are we going to stop >manufacturing kitchen knives for that reason? > >In the same light, we might then argue for/againt the banning of guns, but that >is another story. > >Valentin We generally hold pests in low regard, but locust swarms still turn thousands of acres into sand. One has to look at the reality of the situation, which you are clearly not doing. The fact is that those few people can, through their misuse, destroy what stability the Amiga has as well as make tech people's job impossible. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
daveh@cbmvax.commodore.com (Dave Haynie) (06/19/91)
In article <3095@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <dillon.8625@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >> I am sure that many of us would use the source for appropriate purposes. >> Unfortunately, a greater number will definitely misuse it in major >> ways. >What imbeciles are going to do with a very usefull tool is irrelevant. Kitchen >knives are very useful, yet many use them to kill people. Are we going to stop >manufacturing kitchen knives for that reason? Of course not. And I might hand you a kitchen knife even if I figured you were going to kill yourself with it. But if I thought there was a good chance you were going to come after me with it, you wouldn't get it in the first place. Knife companies stand a real minor chance of damaging themselves by selling knives. -- 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.