scotty@l5comp.UUCP (Scott Turner) (05/28/87)
In article <1930@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >Guess that's why you didn't report it. Have you reported it yet ? >Still time for V1.3.. Ye already fixed it, that was the move.l d1,IO_ERR(Ax) in trackdisk.device. That was the point of my little example, guess you had smoke in your eyes when you read my message. :) The point was not "CATS people can't find bugs", but rather "if you want your bug FIXED then it's best to find the bug yourself than trust that CATS will find the time to nail it and fix it before the next release" >(BTW, we did send you a couple of kickstarts with the bugs you reported >fixed, right ?) Yep! But that was mainly so I wouldn't write a program to patch the kickstart and distribute that with each copy of the program I was working on. >Now that you have email, its even easier to send in bug reports. But I'm not an 'offical' developer anymore. But you're right, if I find a bug I'll toss it on the usenet. >best not to call, then :-) Yep. Haven't called in what, oh 7 months now I think. Haven't felt the urge yet. Life has been much more level, I don't get my hopes all up thinking CATS will have the answer only to have them dashed on the cold hard rocks of reality. Plus no long distance phone bills for pointless phone calls. Of course in all fairness things DID look up once I got past the first level CATS people and got to you. But it was very clear that your time was/is valuable and thus I shouldn't expect to have you as my 'Amiga Answer Man' on an ongoing basis. And the first level staff has proven pretty ineffectual in dealing with my problems. They loved to listen though. :-) >>When something >>bites me again and again and again (like the sorry collection of amigadog >>library calls) I just knuckle down and find a solution. >Well, this is one way to ensure that the bugs you find will never be fixed. >(unless someone else finds them; nice guy) I was refering to things like "I have two file handles, how can I tell if they are for the same file?" A quick look at the dog.lib and we find Examine which returns a 'key' for the FILELOCK which would have done the job quite nicely. Too bad what I had was two FILEHANDLE's. Solution, refit system to keep both a handle and a lock for every open file. Couldn't be done for various reasons. Result: Feature that needed to know if filehandles were for the same file was dropped. This is just ONE example... Other such problems with the dog.lib WERE reported to CATS. Results? ZIP! I only have to get ZIP results so many times before I get the tired of wasting my time/money. Like the -h switch for the macro assembler. It's broken in 10.178. At first I thought I must be using the switch wrong so I called CATS. They had no idea of what -h was even supposed to do much less wether I was using it correctly. So I entered it as a bug and was promised that it would get floated on the in-house vax to see if someone had an answer ie was I using it wrong, or was it indeed busted. I called back several times over a period of 3 months. Never got an answer. That is until MCC allowed me to upgrade to 11.00 and what ho, it works now! More examples available till we're both tired of hearing them. :( >Legal and upper management have their own reasons for keeping source >confidential. Personally, my reason is this: >We don't want people mucking around with the internals of the Amiga libraries >and devices. Not only does this create a support nightmare when talking >to developers, it causes a support nightmare when talking to users. >And it makes upgrading the OS almost impossible. "But I saved 12 cycles >by knowing that A6 held ExecBase, and A3 held GraphicBase", or the ever >popular "I knew the routine used 123 bytes of stack, so that's how much >I gave it." >Sorry if you don't like the reasoning. Uh Andy, I submit that people that would use source code to make those kinds of optimizations will fire up their disassemblers and figure them out in the absence of source code. As for your example of stack space... We have to figure out how much to throw at it SOME how! I like to KNOW about things like that rather than whip out my HP11C and hit the random number function. Lack of source code wouldn't be so bad if the system were fully documented. The system is NOT fully documented hence said source is badly missed at times. Also, you noted I used the example of the Mac serial driver? WHO is going to shave any cycles calling I/O drivers thru DoIO? >Now, this *is* interesting. What you are announcing is that you took >the C-A parallel.device (which is written in assembler), disassembled it, >made a few changes, and are distributing it ? Did you get permission ? >Is this type of thing legal ? Andy, 1. Said posting was made last year. ie I wasn't announcing it for the first time. 2. I have some 'vague' idea about what the original was written in. Parts seem to have been in some form of higher level language, like maybe C. Other parts were clearly not from that same source but were also not very well written for hand assembly code. There are all these code fragments I would expect from a compiler but not from a human, and then bang we're back into what had to be hand assembly code. There were also NUMEROUS interesting bugs. There still are these curious goings on inside that I THINK are bugs but... One architectural problem of note is that the resources for the parallel port are broken into two pieces. One piece is the data port and the other is the status port. You have to grab each with it's own call. Well parallel.device would grab one and then try to grab the other. If it couldn't get the second it exited WITHOUT releasing the FIRST! tsk tsk tsk ;) It seems to me that there should only be one resource call to allocate both parts of the parallel port. I can see little reason to grab one part without the other. (Other than to screwup parallel.device) 3. Made a 'few' changes? How about stir fried, version number bumped, code optimized, bugs removed. And a nice useful example of how to do a device driver made available. 4. I ain't stupid Andy. If I didn't feel I'd made more than few changes I'd have sat on it like I'm doing with my relabelable ram-handler (That is till I get IT re-written :). Of course you guys could just hack in support for ACTION_RENAME_ DISK... But then there's this issue of using 488 byte 'blocks' on the ram disk. Shift by 9 is cheaper than 32x32 divide. I must admit I got a real chuckle out of that little detail when I found it. :) The handler also decodes ACTION_ codes just so it can call the routine to return them as not supported! All it had to do was NOT decode and fall thru to the default call to the routine to flag the packet as bad. Weird. Also, you should see how BCPL codes a loop to copy bytes/words/whatever from one place to another. And, did you know names on the RAM: can be longer than names on DF0? Another nifty fact is that the comment field is not copied with a nul terminating loop. Rather you can cram anything you want into the comment field and it will be copied verbatim. Nice for attaching hex data eh what? :) But back to parallel.device... I made no money off it because I floated it out as FREE in the hopes that others could benifit from it. Using the object code was really secondary to me. I wanted to write a hardisk.device and the dox/examples provided by C-A raised more questions in my mind than they answered. So I took apart parallel.device to figure out what made it tick, then rebuilt it to prove I did know how it ticked. I then slapped a copyright on MY source code, which I DID put time into creating, commenting, debugging. It doesn't resemble whatever source C-A may have a copyright on. The source when assembled does NOT produce an identical object file to the copyrighted C-A object file. And indeed when compared the object files do have more than a few differences. But before we haul me into court, IS the OBJECT code to parallel.device copyrighted? Or is it just a blanket copyright? Was the copyright filed within 30 days? And will your copyright to it standup in court? And if you didn't file within 30 days the whole issue of wether you can prove it is almost mute since the automatic $250 penalty won't kick in. Which means C-A will have to prove damages for something that I think C-A would have a tough time proving damages over. If ANYTHING, C-A has GAINED from my actions, not been DAMAGED. Besides, you can't stop reverse engineering with a copyright. That's was 'trade secrets' are all about. This was NOT a cheap rip off attempt. Nor was it a cloning effort by a competitor. Just some silly fool who invested his time/mental effort to help himself and his fellow Amiga users. The harddisk.device turned into scottdisk.device and you'll note I'm giving IT away as well. I have yet to re-coup even 1 penney for my efforts in figuring out Amiga device drivers and I don't expect to. Scott Turner, un-reformed Eagle Scout. :) >that you know the copyright owner reads ??? And now probably is going Only those impure of heart shrink in the dark. I feel I have nothing to fear, and my intention was not to hurt but to VOLUNTEER help where help appeared to be needed. >Diasssembling a program, then reassembling it with a few changes does not >make it yours. I agree 100%. And I think that if you had applied more thinking time to my message you would have noticed that I held the same view. After all, I said QUITE clearly that I would NOT distribute my hacked up ram-handler as it sat right now since it only had a small (but rather nifty) change made to it. I think that should have been rather clear. Smoke in the eyes again I guess. >I'm not a lawyer, but I didn't think copyright laws had changed that much. They haven't. But they are pretty cloudy over this subject. After all, the source code it MINE. I reverse engineered it and then went from there. It is NOT an exact clone. Thus we are reduced to battling over how large a piece of code must be before it is considered to be copyrighted. Is how my MakeLibrary call too much like the C-A call? If so what happens to all the folks out there that write device drivers? Do they all have to come up with some clever way of loading registers before they make a call to the Exec? Maybe its that snipet of code for comparing the in-coming register against the special characters array? (BTW you MIGHT want to document that characters must be placed into this array in ascending ASCII code sequence) Personally I think this is one can of worms best left alone. >The intelligent thing to do would have been to say to us, hey, the following >changes in the parallel.device will do XXX for you. And, if you were >correct, it would have found its way into the next release. >But nooooooo. I made the patches, then tossed it to the public. I figured it would float by you guys someday. Besides, I did all this work last Nov-Dec. I got tired of playing 'footsie' with CATS, that's why I took it apart in the first place. And, the changes were NOT what I was after. I found the changes as I explored the code. What I wanted was a clear example of HOW TO DO a device driver. And just because I'm right about something doesn't mean you guys are going to put it in. Or does it??? If it does I'll be MORE than happy to pump you guys full of things that could be improved/fixed/or both. :) Feel free to take any of the items in this message that I've mentioned and do something about them. >Speaking of which, I never did receive a copy of the program you were working >on. Which program is that? If I can send it to you I will be more than happy to do so. Please note that I can't send you the 'vapor' M2 compiler at this time though. :( But I can send you some code it produced. :) Let me close by stating that while some of the CATS people may have taken some measure of offense from my message, it can't be ANYWHERE near the offense I've taken from the way I, and others, have been treated by C-A. Not to mention the REAL frustration from ineffectual tech support when I needed it most. It would be nice to let bygones be bygones. Is the new developer support program worth the $450 I'd have to shell out for it? Or should I just go for the $45 program? Or current choice, just keep on truckin' the way I am? Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /devevePL i
keithe@tekgvs.UUCP (06/02/87)
[sorry folks - I tried to mail this but tektronix (a major backbone site) is unable to find scott's machine in it's mailer routing tables] Scott - Could you be pursuaded to keep your flame level down on usenet? It's getting to be quite tiresome to wade through your overblown ranting and raving to get to the message. What you have to say _is_ worth saying. It's just becoming increasingly difficult to separate the wheat from the chaff. keith
carolyn@cbmvax.UUCP (06/03/87)
In article <160@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >[] > ...The point was not "CATS people can't find bugs", but >rather "if you want your bug FIXED then it's best to find the bug yourself than >trust that CATS will find the time to nail it and fix it before the next >release" That's a good point Scott, since CATS are not the people who fix the bugs. CATS stands for Commodore Amiga Technical Support. We do receive some bug reports by phone. Our job is to get the name and phone number of the person reporting the bug, and enough information to reproduce it. Sometimes it's a known bug and we can suggest a workaround. Sometimes it's a user or programmer error and we can help them correct it. Otherwise, we type in a bug report and we email to whoever is cataloging and prioritizing bugs, to our qa departments, to the rest of CATS, and to all software engineers who are maintaining the OS. If we have time, or even if we don't have time but would personally like a particular low-priority bug fixed asap, we will go into the source and try to pinpoint the code that is causing that problem and suggest a specific fix to whoever is maintaining that piece of the OS. >[] > ...Results? ZIP! I only have to get ZIP results so >many times before I get the tired of wasting my time/money. Like the -h switch >for the macro assembler. It's broken in 10.178. At first I thought I must be >using the switch wrong so I called CATS. They had no idea of what -h was even >supposed to do much less wether I was using it correctly. So I entered it as >a bug and was promised that it would get floated on the in-house vax to see if >someone had an answer ie was I using it wrong, or was it indeed busted. I >called back several times over a period of 3 months. Never got an answer. >That is until MCC allowed me to upgrade to 11.00 and what ho, it works now! That was me you reported that bug to. It was immediately written up and emailed to all involved as described above. The person at Los Gatos who was cataloging the bugs passed all Metacomco bugs on to Metacomco and as you said, the bug was fixed. If you want to gripe about not being personally informed of the fix, maybe you should talk to Metacomco. Your name and phone number was in the bug report I submitted. I won't apologize for not being familiar with the -h switch. I still have not found a single person other than you who is aware of that switch. >[] >More examples available till we're both tired of hearing them. :( I think we're all tired of hearing them. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=