hatcher@INGRES.BERKELEY.EDU (Doug Merritt) (05/25/87)
Here follows a report of the magic that I've learned so far, and a plea for help on the remaining problems. I am still having problems with distinguishing between different types of executables (program, font, lib, dev, handler). BTW, although there is supposed to be a "moveq #0,d0 + rts" in non-program executables, this is far from dependable. In general I am disturbed that it would seem that I have to use trial-and-error, checking several possible data structures, in order to determine the file type. This implies that I might run into "coincidental" data that makes it ambiguous as to which type the file is. Perhaps worse yet, there are some exceptions to the rules that seem to make some files unidentifiable at all. Perhaps there is something about hunks that might straighten this out. Where are they documented??? The methods I've arrived at so far all depend on looking at what I believe is the hunk count to figure out where the first hunk is (my interpreation of hunks came from staring at hex dumps so this may be slightly off the mark): 000003f3 00000000 00000001 00000000 (magic #) (count) (followed by <hunk count - 1> and a list of hunk offsets or sizes) Then I find the hunk code and a following size, followed by the contents of the hunk: 000003e9 000000a0 <contents> (code) (size) Now I look at the <contents> to find an indication as to file type: See whether <contents> is a struct DiskFontHeader, as indicated by 1) the dfh_DF.LN_TYPE component equals NT_FONT (0x0C) and (2) the dfh_FileID field equals DFH_ID (0x0f80) [ defined in libraries/diskfont.h ] If that fails, search an indeterminate amount forward for RT_MATCHWORD == 0x4AFC [ as defined in exec/resident.h ], and if found, interpret that as the first field of a struct Resident and see whether the rt_Type field is equal to NT_DEVICE (0x03) or NT_LIBRARY (0x09). If that fails, then it is either a regular program, a handler, or a non-conforming library or device, which is a very uncomfortable amount of ambiguity. The translator.library is not identifiable as a library by these methods, nor is the narrator device nor Matt's pipe device (BTW Perry's asdg.vdisk.device *is* identifiable). This leads me to believe that those authors did not follow the full standard, yet they got their devices/libraries to work anyway. How is that possible??? Finally, I can't find any method for distinguishing handlers from regular executables at all. Anyone know how? Thanks, Doug Merritt ucbvax!ingres!hatcher P.S. I still use uucp paths rather than domains because when I mail *out* using domains, they almost always fail, whereas paths are as reliable as they ever were. Don't blindly recommend that people use domain names; they are not yet as robust (especially on some systems) as they could be. Also there are still many, many, many, many, MANY systems that don't know how to talk to domains at all!!! Thus if you care about *receiving* letters, you will still sign with a *path* to idbinbinbifi
scotty@l5comp.UUCP (Scott Turner) (05/27/87)
In article <8705250320.AA18887@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes: >I am still having problems with distinguishing between different types >of executables (program, font, lib, dev, handler). BTW, although there is >supposed to be a "moveq #0,d0 + rts" in non-program executables, >this is far from dependable. Yeah, I for one don't put in the moveq rts mumbo jumbo. It isn't required and if a user executes my code instead of using as I DOCUMENT well Mr. Guru will keep the world from imploding. :) >rules that seem to make some files unidentifiable at all. Perhaps >there is something about hunks that might straighten this out. Where >are they documented??? Hunks are documented in the AmigaDOS technical reference manual from Bantam. But don't expect this info to make life easier for ya. The Amiga binary file structure is a just a way for storing data. It makes no comments on WHAT it is storing. > If that fails, search an indeterminate amount forward for > RT_MATCHWORD == 0x4AFC [ as defined in exec/resident.h ], and if > found, interpret that as the first field of a struct Resident > and see whether the rt_Type field is equal to NT_DEVICE (0x03) > or NT_LIBRARY (0x09). You should also verify that the RT_MATCH_TAG is correct before jumping in with both feet. Be aware when digging through raw hunk data that this data can in many cases change in value due to it's being patched by the relocater after it gets loaded. For references inside the same hunk this shouldn't cause you any trouble, but for links to hunks OUTSIDE the current hunk this CAN cause problems. The easy solution to ALL your trouble with trying to decode the hunk structure is just to do what the system does when it wants to get at the code. Use the LoadSeg call from dos.library to load the file into ram and then stare at it. Then when done call UnLoadSeg to toss it out of ram. LoadSeg and UnLoadSeg are documented in the Bantam book. (see above) > If that fails, then it is either a regular program, a handler, > or a non-conforming library or device, which is a very uncomfortable > amount of ambiguity. The translator.library is not identifiable That's life. Being able to identify what a file is was never it seems a real concern in the minds of the people that designed the dog. But then again my UN*X system has the same problems. :) > Finally, I can't find any method for distinguishing handlers from > regular executables at all. Anyone know how? And finally we get down to the $64,000 answer. You RTFM that came with the product. Which is why it's handy to get a FM in the first place. 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 /dev/null)
hatcher@INGRES.BERKELEY.EDU.UUCP (05/28/87)
In article <154@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >Summary: File identification is out of your worst nightmares. Not really. Just a question of learning the machine. I have completed my project, the "filetype" program. Tells you what any given file is; very handy for browsing, since by default it sorts by file type. This was inspired by the Unix "file" program, which I sorely missed having on my Amiga. It does very well indeed at identifying most any file you'd ever think about aiming it at, including English versus C versus Mail etc, as well as *all* the hairy binary files. I got lazy when it came to recognizing Pascal, Fortran, Basic, and assembly source, but those are the only things left to do that I could think of. However, it takes up 23K using Lattice, and there is still a global variable used, so I may rewrite it. [ Did you know that Flight simulator uses the digits of pi, rounded off, and transposed into hexadecimal, as a magic number on its magic executables? Not that anyone cares...I'll probably remove that one feature...] > ... Be aware when digging through raw hunk data that this data can in >many cases change in value due to it's being patched by the relocater after >it gets loaded. Thanks, I'll check it out. And thanks for your other purely informative comments. >> Finally, I can't find any method for distinguishing handlers from >> regular executables at all. Anyone know how? >And finally we get down to the $64,000 answer. You RTFM that came with the >product. Which is why it's handy to get a FM in the first place. On the one hand I appreciate technical assistence, and answers to my questions. On the other hand, this seems like a pretty rude comment to me. And it doesn't answer the question, either. Fortunately I figured it out from hex dumps already, and tomorrow I will read the AmigaDos Technical Reference Manual...somehow I missed this one buried in the back of my Bantam book. FYI it did *not* come with the product. Half the problem in learning a subject is figuring out exactly where to look for the answers. Looking in the wrong place can make it seem like something is undocumented. However, before asking my question, I had already consulted the 4-volume Addison Wesley RKM, Programmers Guide to the Amiga, Amiga Developers Manual, AmigaDos Users Manual, the Amiga Programmers Handbook, all of my Lattice include files, and spent hours and hours poring over hex dumps. Personally I think that this qualifies as Reading the F.M., so I felt free to ask the net for further help. Perhaps I'm out of line here; maybe I shouldn't ask any questions until I'm already an expert on AmigaDos. I didn't realize that was the policy here (at least since Scotty joined us). >Yeah, I for one don't put in the moveq rts mumbo jumbo. It isn't required and >if a user executes my code instead of using as I DOCUMENT well Mr. Guru will >keep the world from imploding. :) I for one wish that people would be a little less smug about allowing gurus to happen. I suppose it really makes *your* day every time a guru shows up? And you're really unhappy with programs that refuse to guru no matter what? And ashamed if you write a program that is robust? And before I go, I'd like to ask you to aim your flames more carefully when you're complaining about AmigaDo*...some of them are hitting CATS people like Andy Finkel, and it is hardly his fault that the system is the way it is. The problems exist for historical reasons that you are probably very familiar with, and now we all get to live with them. The CATS people probably hate the problems worse than we do, since it is their job to help people understand and work around them. Give them all a break... let them know you appreciate them being here on the net answering questions. People who flame CATS tend to be unpopular with a large audience. And I think Andy deserves a medal for such remarkably calm, informative responses to Scotty's flames. Doug Merritt ucbvax!ingres!hatcher (for Keith :-) hatcher@ingres.BERKELEY.EDU (for Bryce :-)
scotty@l5comp.UUCP (Scott Turner) (05/30/87)
In article <8705280817.AA02563@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes: >Thanks, I'll check it out. And thanks for your other purely informative >comments. You are quite welcome. I enjoy helping others. >>> Finally, I can't find any method for distinguishing handlers from >>> regular executables at all. Anyone know how? >>And finally we get down to the $64,000 answer. You RTFM that came with the >>product. Which is why it's handy to get a FM in the first place. > >On the one hand I appreciate technical assistence, and answers to my questions. >On the other hand, this seems like a pretty rude comment to me. And it [ flames ] >Manual...somehow I missed this one buried in the back of my Bantam book. >FYI it did *not* come with the product. Yep, you're right, the Bantam book doesn't come with any product I can think of. What product were YOU thinking of? For that matter what brought the Bantam manual into this? When I had refered to the Bantam manual previously I did it BY NAME. Well I'll buy that you could get confused and think I meant the Bantam book. But I won't buy your other leap, whatever it was, about the 'product'. I mentioned no products in my posting. You were meant to link 'product' with handlers and device drivers. Which ARE products. And then there's my comment about getting a manual in the first place. This I think would have created even more confusion about what I was saying. But instead of asking me to clarify what I was saying you decided to make the leap that I was attacking YOU personally and decided to attack back. Sure, my message may have had a few items aimed at C-A, as you point out later on, but none CLEARLY directed against you. I think your WHOLE posting serves as a great example of how NOT to use the net. 1. Without the personal attacks upon me it would have amounted to "Thanks for the help". Messages of this sort should be made via E-Mail not public postings. 2. PERSONAL attacks should be made via E-Mail. I'm a big boy, I read my mail and I DO reply to it. By making this attack public you force me to make another bandwidth wasting public posting since silence must be interpreted as agreement not disagreement. Because if I didn't agree I'd do what I'm doing now. 3. Before making personal attacks you should READ and UNDERSTAND what the poster was saying. If you don't understand what he/she was saying then why risk attacking the person if he/she didn't intend an attack upon you? You should get it clarified THEN attack if needed. 4. When I posted the message that sparked the flames I should probably have not posted my message to the net. I should have sent the info via E-Mail. However I felt that the info I had might be of use to others and the person might not understand about summarizing and posting to the net. After reading this reply I feel even more sure I did the right thing. Of course if I had E-Mailed the person he might have replied via E-Mail thus sparing others his mis-directed attack upon me. >Perhaps I'm out of line here; maybe I shouldn't ask any questions until >I'm already an expert on AmigaDos. I didn't realize that was the policy here >(at least since Scotty joined us). Yet another comment from hyper-space. You can search my message high and low and you will find no suggestion on my part that you should not have posted your original message. >I for one wish that people would be a little less smug about allowing gurus >to happen. I suppose it really makes *your* day every time a guru shows up? >And you're really unhappy with programs that refuse to guru no matter what? >And ashamed if you write a program that is robust? More and more personal attacks based on reading who knows WHAT into what I had to say. First, let me take time out from this rebuttal and make an Amiga comment. The intent of this code is to keep a user who decides to charge ahead without reading the manual from meeting Mr. Guru. However, this code will simply cause the program to return to the user. No error message or anything. Wouldn't it be better for this code to return a result code OTHER than 0 so that the user would get an error? ie: moveq #99,d0 rts Back to the rebuttal in progress... My comments above aside. Handlers and device drivers load into ram and stay there. Thus they eat ram on an on going basis. As such it's nice if they use as little ram as possible. I'll summarize the rest of my position by saying that I don't normally do something that has a negative effect on everyone just to keep those reckless enough to use my code, in a manner it was not intended to be used, out of trouble. I do however put in internal checks to keep away Mr. Guru for when my code is used in it's intended fashion. >And before I go, I'd like to ask you to aim your flames more carefully >when you're complaining about AmigaDo*...some of them are hitting CATS >people like Andy Finkel, and it is hardly his fault that the system is >the way it is. The problems exist for historical reasons that you are probably >very familiar with, and now we all get to live with them. The CATS people >probably hate the problems worse than we do, since it is their job to >help people understand and work around them. Give them all a break... >let them know you appreciate them being here on the net answering questions. >People who flame CATS tend to be unpopular with a large audience. And >I think Andy deserves a medal for such remarkably calm, informative responses >to Scotty's flames. Now I think we finally get to the heart of all these flames aimed at me. And not just by the author of this posting. So I'll take this chance to respond to EVERYONE who is taking the time to send me such lovely E-Mails and usenet postings. It seems that the CATS crowd has a few vocal supporters out there in netland. These people do not stand for ANY negative comments about CATS it seems. It's fine to say what you will about management at C-A or C-A but not about CATS. ie CATS are the 'untouchables' of the Amiga. Andy makes the comment about having killed my 'Gold fish'. Gee Andy I wish you people had only done that to me. CATS has cost me time, money, and mental stress. The time is the part I miss the most since it is such a scarce item. The author wishes to pile praise upon CATS in general and a medal on Andy in particular. 1. CATS has done alot in the past to make me want to not heap praise on them. I see SOME promising signs from grr, carolyn, and eric though of maybe making me feel differently. (Note andy IS missing from that list currently) 2. The medal for Andy was to be for his 'informative replys' to my 'flames'. I would direct attention to these replys and Andy's postings in general. His postings have a high content of the following: A. Ducking the subject. For example, his comments on my comments about usage of addbuffers buffers. He comments that my suggested usage of these buffers is not the original intended usage for them. Heck I already had my suspicions about what was wrong. But my comments stand still with no response as to why what I suggest can't be done or shouldn't be done or won't be done. B. Replies that cause confusion. For example, he states that the buffers were not intended to be used with tracked storage devices. First this just begs the followup question "What kind of storage devices are supposed to be used?" Second, every major storage medium in popular usage that I can think of is tracked. My other favorite was his "You can use install on PD bootdisks ...so enough of the PD installs...un-offically Andy Finkel" I've been jumped by more than one person for making item B type replies. Yet no one jumps Andy about it when HE does it. And I'm not the only person to notice what I'm talking about here: >From: richard@pnet02.CTS.COM (Richard Sexton) >Newsgroups: comp.sys.amiga >Subject: Re: BCPL/AmigaDOS >Message-ID: <559@gryphon.CTS.COM> >Date: 28 May 87 17:55:15 GMT >"Stuff we are doing with hard disks" ?? Care to elaborate Andy? Richard was "smart" he didn't employ the same tactics against Andy that others on the net have used against me when I did something like what Andy did. Also, the last Amiga mail carries a plea that can be summarized as: Many of the tech support people can be found on electronic networks. They are doing this on their own time and out of the goodness of their hearts. Thus the plea continues, we should keep this in mind and be nice to them. I can already hear the pro-CATS anti-Scotty crowd reaching for the R or F key to send me a reply along the lines of "If you've read that how can you treat them like you have?!?" (With additional flames added on I'm sure :) Again I invite those of you in netland to inspect the postings of the CATS people. 'cbmvax' is located 5 hours west from GMT. Thus you take GMT time and subtract 05:00:00 from it to get local 'cbmvax' time. For example: From: andy@cbmvax.cbm.UUCP (Andy Finkel) Newsgroups: comp.sys.amiga Subject: Re: BCPL/AmigaDOS Message-ID: <1938@cbmvax.cbmvax.cbm.UUCP> Date: 27 May 87 15:19:07 GMT The above message was posted at 10:19:07 local time. EXCEPT that this message was posted with local daylight savings time in effect, thus we add one more hour to get 11:19:07 corrected local time. If you examine several more postings a 'curious' pattern emerges. The CATS people TEND to post their messages during the 09:00 to 17:00 local time period... 'l5comp' is 8 hours west of GMT. I invite examination of the posting times for my messages. I don't know about the CATS people, but I pay $10 an hour so 'l5comp' can reach out an touch its newsfeed. I also pay $10 an hour to read all flames directed my way via E-Mail. And $10 an hour to respond via E-Mail. I don't get paid by anyone (not even GEnie) to answer Amiga questions no matter the time of day. Thus answering Amiga questions via this forum doesn't make my 'job' any easier. Actions speak louder than words. Thus I let my 'actions' speak for me rather than any plea in Amiga Mail. These postings truely come from the goodness of MY heart. Maybe the CATS postings come from the goodness of their hearts, or maybe it's just another side of their jobs. I'll let them explain if they wish to. This isn't an attack on the CATS people, I'm just curious. Now for some quick public replies to some of the E-Mail I have received... No I'm not a closet (check one): A. ST lover (I enjoy rm /usr/spool/news/comp/sys/atari/st/* too much :) B. Mac lover. C. Amiga hater. My parents were also married through all phases of my conception/birth. And I've had no carnal knowledge of my mother or any other mothers for that matter. :) As for the comment about the current OS not being Andy's fault... There comes a time when the people who step in to clean up/maintain an OS can no longer hide behind 'The Sins Of The Creators'. When does Andy get to start taking the fall? Version 1.3? Version 2.x??? Anyway, I grow weary of responding to flames on what I think of CATS and C-A. So here's what I'll do, no more editorial in nature comments about C-A and CATS. Just the facts, be they pretty or ugly. Anymore publicly posted flames against me will go un-replied to in public. I'll use the R key instead. So please don't assume I'm agreeing with what people had to say about me just because you don't see a response from me. 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 /dev/null)
slc@hoptoad.uucp (Steve Costa) (05/31/87)
Although your messages sometimes contain useful information, I have started to dread and avoid them. In my opinion, you are monopolizing too much of the traffic in this conference. I want my message to be a matter of public record, but of course speak for myself alone, when I request that you be more concise and less inflammatory.
slc@hoptoad.uucp (Steve Costa) (05/31/87)
My apologies for any lack of clarity about who my previous message was directed to. It is a followup to Scott Turner's reply to a previous string of messages.
andy@cbmvax.cbm.UUCP (Andy Finkel) (06/02/87)
In article <162@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >[a lot of stuff] Everyone who has 'come to our defense', I'd just like to say, thank you for your continued support. (It's nice to be appreciated) Following my new 'ignore posted flame but answer the questions' policy, I'll just respond to the points raised: Re: buffers Sorry I confused you. Basically, the AmigaDOS (ie, Tripos) filehandler was not designed for a trackdisk.device. The trackdisk.device reads in a track at a time. The current file handler does not take advantage of this; instead, its logic is more oriented to a conventional "read a sector at a time" type of disk. (I don't think I saw anything especially funny about your use of buffers, BTW. And, looking over my comment, I didn't mention that I did. All I wrote was that it just doesn't happen to work that way now, for reasons like the one above.) Our support of Amiga people on Usenet isn't a company supported thing. (We officially provide support on BIX). My hours are between me and my boss. I participate in the amiga group on Usenet because I like to. I like helping people, and hearing new ideas, suggestions, etc. The interaction isn't one way...I've learned a good bit from the postings people have made, as well as helped people. (hell, I'm downright impressed by some of the postings) re: parallel.device The parallel.device is in assembler. It doesn't look that strange. Has labels, comments, etc. Perhaps the author has an original in C, then played with that; perhaps he just learned programming from reading compiler output. Perhaps he just uses different techniques. It isn't especially relevant. The previous description ("retuned") made is seem like you fixed bugs, and improved some code. I'm glad to hear you rewrote it completely. I hope you bumped the versionation a lot, by the way, to avoid confusion with our releases. Guess I'll see it soon. re: Parallel bits: I just found the allocation bug 2 months ago, and fixed it. Thanks for your report. The reason there are two possible allocations for the parallel bits is based on the actual resource (device) in question. The 8520 port has both 8 bi-directional pins, and 2 handshaking lines. They can be used seperately. In other Commodore computers I occasionally found it useful to give control of the handshaking lines to one part of a program, and the parallel lines to another. Splitting the resource as we did gives a 'supportable under multitasking' method of doing similar things. (as well as a chance for a bug to creep in, but that really is a separate issue) speaking of bugs, we'll fix the docs about the order of EOF chars next documentation. thanks for reporting it. re: copyrights: your comments are certainly interesting. re: goldfish BTW, my comment was "injured your gold fish". If you feel it necessary to jump down my throat about this posting, (though I tried to avoid any flames) why not try email ? Then you can really take the gloves off. :-) (all right, one flame crept in; answering the crack about my hours; as a hacker I resent others telling me when they think I should be working, and when I should be doing other things) andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore/Amiga "An end is always a new beginning." - Captain Cloud Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
carolyn@cbmvax.UUCP (06/03/87)
In article <162@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >[] >Also, the last Amiga mail carries a plea that can be summarized as: > >Many of the tech support people can be found on electronic networks. They are >doing this on their own time and out of the goodness of their hearts. Thus >the plea continues, we should keep this in mind and be nice to them. The exact quote from AmigaMail is: "One final note, several of the Commodore-Amiga personnel are participating on BIX in their free time. I am most grateful for their participation and hope that you will be too (especially when you get a reply from someone at one in the morning)." This is totally true. Several CBM and C-A software engineers and some of the FORMER Commodore-Amiga (Los Gatos) OS designers answer questions in our official developer conferences on BIX in their free time. >[] >Again I invite those of you in netland to inspect the postings of the CATS >people... For example... >[message header] >The above message was posted at 10:19:07 local time... I have three phone lines. Sometimes I'm taking voice questions on two while answering BIX questions on the third. Sometimes I'm taking voice questions on all three WHILE writing code on my Amiga AND handling email or answering usenet questions on my terminal during compiles. [ That's ((PHONE|PHONE|PHONE)&PROGRAMMING&(EMAIL|USENET)) ] Sometimes, after everyone's gone home, including the developers three time zones away, I get to code in peace. Or answer usenet postings that I've repeatedly marked as unread in hopes of getting time to answer them. >[] >I don't know about the CATS people, but I pay $10 an hour so 'l5comp' can reach >out an touch its newsfeed. I also pay $10 an hour to read all flames directed >my way via E-Mail. And $10 an hour to respond via E-Mail. Other people are also paying to read this net. I think we should just drop this whole thing. If you don't agree, please respond via Email. I will gladly forward your messages locally. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=