home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 230.lha / IffLib_v16.1 / Bugs < prev    next >
Internet Message Format  |  1989-04-06  |  15KB
  1. From: ewhac@well.UUCP (Leo L. Schwab)
  2. Subject: Biased Comments on the IFF Library in comp.binaries.amiga.
  3. Date: 20 Nov 88 11:22:15 GMT
  4. Organization: Catholic High School Girls In Trouble.
  5. Keywords: IFF, library, my ego
  6.  
  7. Quote: "Boo!  We changed 'Coke' again!  Bleah! Bleah!"  -- Binkley's Closet
  8.  
  9.  
  10. [ The exact value of PI is 3.141592654^#&&@%~r{_^?^MNO CARRIER ]
  11.  
  12.     Recently, Bob Page posted an IFF library written by a gentleman in
  13. Switzerland.  Since Stu Ferguson and I have been working dilligently on just
  14. such a beast (Stu more than I), I grabbed it and took a look at it, trying
  15. as hard as I could to keep my bruised ego out of the way.  Having done this,
  16. I have some hopefully pertinent comments to make.
  17.  
  18.  
  19. Overview
  20. --------
  21.  
  22.     I'm sure his motivation for writing this library was the same as our
  23. motivation:  The currently available tools for manipulating IFF files are
  24. sadly inadaquete.  EA's code sucks dead badgers through steel conduit, and
  25. Jim Kent's code -- while a vast improvement -- isn't nearly general enough
  26. to address all the irritating aspects of IFF.
  27.  
  28.     Up 'til now, the way to deal with these little irritating details of
  29. IFF has been to ignore them.  Since everyone has, so far, been ignoring the
  30. same details (like LIST's and CAT's), we've been getting by pretty well.
  31. However, I would hazard a guess that 90% of all non-EA based IFF readers
  32. will toss their cookies if, instead of being handed a FORM.ILBM, they were
  33. handed a FORM.SHAK with embedded FORM.ILBM's.
  34.  
  35.     Therefore, our goal -- Stu's and mine -- was to create a set of
  36. routines that would make the manipulation of IFF files simple.    We wished to
  37. make in particular the handling of FORM.ILBM's easier.  We also wished to
  38. comply rigidly with all the rules, both explicit and implicit, of IFF.
  39.  
  40.     This has not been easy.  We're currently on our second pass of the
  41. library, and we might go for a third before a general Alpha release.  A
  42. recent conference with some AmiGuys helped to highlight some areas of
  43. uncertainty, and also clarify some periphery issues.
  44.  
  45.     As a result of this, we think we have an approach which will make
  46. dealing with IFF files simpler, and will also more or less automatically
  47. enforce all the rules of IFF for you, saving you from the headache.
  48.  
  49.     And now that the sales pitch is out of the way...
  50.  
  51.  
  52. The Swiss IFF Library
  53. ---------------------
  54.  
  55.     I've given the library documentation a very thoughtful glance.
  56. Curiously enough, he appears to have implemented a couple of concepts we hit
  57. upon as well.  He also has a couple of neat ideas which we may plagiarize.
  58. However, I believe the major shortcoming in this library is that it makes
  59. too many assumptions.
  60.  
  61.     One feature of his code is that, if it encounters a FORM.8SVX, it
  62. will automatically load it into CHIP RAM for you.  This is a decision that,
  63. by rights, should be made by the client program.  If I'm loading a sample
  64. into RAM for Fourier analysis, and I happen to have 32-bit RAM hanging off
  65. my 75 MHz 68030, I'll want to load it in there rather than the slower CHIP
  66. RAM.
  67.  
  68.     His code also appears to be tuned to dealing with FORM.ILBM's.
  69. Because of this specific tuning, the library may not be well-suited to other
  70. applications.  Of course, this supposition would have to be verified by
  71. someone actually trying it.
  72.  
  73.     Even with this tuning towards FORM.ILBM's, the code, from what I
  74. can gather, is making poor assumptions about the layout of a FORM.ILBM;
  75. namely, that the BMHD always comes first.  (I assume this is what the
  76. library is doing based on the sample C source enclosed with it.)  This
  77. is not the case; the ILBM spec does not specify that the BMHD must come
  78. first.    In fact, it specifically says that BMHD, CMAP, CAMG, CRNG, and
  79. other ILBM chunks can appear in *any* order.  The only thing you're
  80. guaranteed is that the BODY will come last.
  81.  
  82.     In general, I feel that his code is trying to do too much for the
  83. client application.  It is taking too much control from the programmer and
  84. hiding it in the library.  While this makes the general case easier to
  85. program for, the special cases become difficult or impossible to code for
  86. under this scheme.
  87.  
  88.     Also, his iff.h file is highly unusual.  It has assembly code in it.
  89.  
  90.  
  91. Closing
  92. -------
  93.  
  94.     The code is not useless, however.  There is a fair piece of utility
  95. to be found in his library.  The bitmap packer/unpacker is worth a lot (am I
  96. the only person who hates reading and writing run-length-encoding
  97. programs?).  And, as I said, for 90% of the cases you'll encounter, it's
  98. perfectly useable for dealing with FORM.ILBM's.
  99.  
  100.     However, I would consider it an academic curiosity, and would not
  101. recommend using it in anything "real".  If you're looking for something that
  102. observes all the rules and is still relatively easy to use, then please be a
  103. bit more patient; Stu's and my library will be available Real Soon Now.
  104.  
  105.     Realize, of course, that all the above comments come from a guy
  106. who's going to have a "competing product" on the market very soon.  Grains
  107. of salt, and all that...
  108.  
  109. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  110. Leo L. Schwab -- The Guy in The Cape    INET: well!ewhac@ucbvax.Berkeley.EDU
  111.  \_ -_        Recumbent Bikes:    UUCP: pacbell > !{well,unicom}!ewhac
  112. O----^o       The Only Way To Fly.          hplabs / (pronounced "AE-wack")
  113. "Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor
  114.  
  115. ============================================================================
  116.  
  117. From: lel@wuphys.UUCP (Lyle E. Levine)
  118. Subject: Re: IFF.LIBRARY
  119. Date: 5 Dec 88 03:20:41 GMT
  120. Organization: Physics Dept., Washington U. in St. Louis
  121.  
  122.  
  123. In article <62827UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes:
  124. >I will cede to Leo that the recently distributed iff.library is not
  125. >the ultimate word on iff, but it would do exacly what I need IF I used
  126. >Manx and not Lattice 4.01.  So, I am gonna try to Lattice-ify it.
  127. >
  128. >      Will the lattice supplied asm handle that simple piece of asm source,
  129. >or do I have to change some of the mnemonics, or add some magic at the
  130. >beginning or end, or ???
  131.  
  132. Sorry I took so long on this one. A two week vacation can do wonders
  133. for generating a huge backlog of USENET articles!  The easiest way
  134. to Lattice-ify this stuff is to replace the #asm code with some
  135. Lattice #pragma statements.  The correct statements are:
  136.  
  137. #pragma libcall IFFBase OpenIFF 1e 801
  138. #pragma libcall IFFBase CloseIFF 24 901
  139. #pragma libcall IFFBase FindChunk 2a 0902
  140. #pragma libcall IFFBase GetBMHD 30 901
  141. #pragma libcall IFFBase GetColorTab 36 8902
  142. #pragma libcall IFFBase DecodePic 3c 8902
  143. #pragma libcall IFFBase SaveBitMap 42 0A9804
  144. #pragma libcall IFFBase SaveClip 48 43210A9808
  145. #pragma libcall IFFBase IffError 4e 00
  146. #pragma libcall IFFBase GetViewModes 54 901
  147.  
  148.  
  149. >             thanks
  150.  
  151. You're very welcome.    :^)
  152.  
  153. P.S.  Has anyone gotten FindChunk() to work?  If so, how about a
  154. witto hint?
  155.  
  156. P.P.S. The IFF loader is FAST!!!
  157.  
  158.  
  159. ==========
  160. IBM is a Division of Sirius Cybernetics Corporation
  161. "their fundamental design flaws are completely hidden by their
  162. superficial design flaws."
  163.             - "So Long And Thanks For All The Fish"
  164.  
  165. Lyle Levine: Paths -> ihnp4!wuphys!lel         Best way: (314)889-6379
  166.               uunet!wucs!wuphys!lel
  167.  
  168. ============================================================================
  169.  
  170. From: lel@wuphys.UUCP (Lyle E. Levine)
  171. Subject: Re: IFF.LIBRARY
  172. Date: 5 Dec 88 06:01:36 GMT
  173. Organization: Physics Dept., Washington U. in St. Louis
  174.  
  175.  
  176. In article <587@wuphys.UUCP> lel@wuphys.UUCP (Lyle E. Levine) writes:
  177. >
  178. >P.S.  Has anyone gotten FindChunk() to work?  If so, how about a
  179. >witto hint?
  180.  
  181. Nevermind!  I just got it to work. To clear up any future
  182. confusion, the arguments are FindChunk(ifffile,chunkname).
  183. chunkname is a packed ASCII (ULONG).  Thus, 'CRNG' is
  184. 0x43524e47. This is because 'C' = 0x43, 'R' = 0x52, etc...
  185. Hope this helps someone!
  186.  
  187.  
  188. ==========
  189. IBM is a Division of Sirius Cybernetics Corporation
  190. "their fundamental design flaws are completely hidden by their
  191. superficial design flaws."
  192.             - "So Long And Thanks For All The Fish"
  193.  
  194. Lyle Levine: Paths -> ihnp4!wuphys!lel         Best way: (314)889-6379
  195.               uunet!wucs!wuphys!lel
  196.  
  197. ============================================================================
  198.  
  199. From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
  200. Subject: Re: IFF.LIBRARY
  201. Date: 6 Dec 88 02:53:42 GMT
  202. Organization: Missionaria Phonibalonica
  203.  
  204.  
  205. I'd add a "#ifndef" around those pragmas. I also turned the function
  206. declarations into prototypes:
  207.  
  208.  
  209. /************** F U N C T I O N   D E C L A R A T I O N S ***************/
  210.  
  211. APTR OpenIFF(char *);
  212. void CloseIFF(APTR);
  213. struct Chunk *FindChunk(APTR, char *);
  214. struct BitMapHeader *GetBMHD(APTR);
  215. LONG GetColorTab(APTR, UWORD *);
  216. BOOL DecodePic(APTR, struct BitMap *);
  217. BOOL SaveBitMap(char *, struct BitMap *, UWORD *, long);
  218. BOOL SaveClip(char *, struct BitMap *, UWORD *, int, int, int, int, int);
  219. LONG IffError(void);
  220.  
  221.  
  222. /************** F U N C T I O N   P R A G M A S ***************/
  223.  
  224. #ifndef NOPRAGMA
  225. #pragma libcall IFFBase OpenIFF 1e 801
  226. #pragma libcall IFFBase CloseIFF 24 901
  227. #pragma libcall IFFBase FindChunk 2a 0902
  228. #pragma libcall IFFBase GetBMHD 30 901
  229. #pragma libcall IFFBase GetColorTab 36 8902
  230. #pragma libcall IFFBase DecodePic 3c 8902
  231. #pragma libcall IFFBase SaveBitMap 42 0A9804
  232. #pragma libcall IFFBase SaveClip 48 43210A9808
  233. #pragma libcall IFFBase IffError 4e 00
  234. #pragma libcall IFFBase GetViewModes 54 901
  235. #endif
  236.  
  237.  
  238. Finally, for those who want it, here's the assembler interface for
  239. Lattice. Just asm it, copy the library into lib: as lib.o, and then
  240. link it with programs that need the iff.library (assuming you compiled
  241. with NOPRAGMA defined).
  242.  
  243.  
  244. ; asm interface to iff.library
  245.         csect    text
  246.  
  247. ; Pointer to the library, supplied by the caller
  248.         xref    _IFFBase
  249.  
  250.         xdef    _OpenIFF
  251. _OpenIFF:    move.l    4(sp),a0
  252.         move.l    _IFFBase,a6
  253.         jmp    -30(a6)
  254.  
  255.         xdef    _CloseIFF
  256. _CloseIFF:    move.l    4(sp),a1
  257.         move.l    _IFFBase,a6
  258.         jmp    -36(a6)
  259.  
  260.         xdef    _FindChunk
  261. _FindChunk:    move.l    4(sp),a1
  262.         move.l    8(sp),d0
  263.         move.l    _IFFBase,a6
  264.         jmp    -42(a6)
  265.  
  266.         xdef    _GetBMHD
  267. _GetBMHD:    move.l    4(sp),a1
  268.         move.l    _IFFBase,a6
  269.         jmp    -48(a6)
  270.  
  271.         xdef    _GetColorTab
  272. _GetColorTab:    move.l    4(sp),a1
  273.         move.l    8(sp),a0
  274.         move.l    _IFFBase,a6
  275.         jmp    -54(a6)
  276.  
  277.         xdef    _DecodePic
  278. _DecodePic:    move.l    4(sp),a1
  279.         move.l    8(sp),a0
  280.         move.l    _IFFBase,a6
  281.         jmp    -60(a6)
  282.  
  283.         xdef    _SaveBitMap
  284. _SaveBitMap:    move.l    a2,-(sp)
  285.         movem.l 8(sp),a0/a1/a2
  286.         move.l    20(sp),d0
  287.         move.l    _IFFBase,a6
  288.         jsr    -66(a6)
  289.         move.l    (sp)+,a2
  290.         rts
  291.  
  292.         xdef    _SaveClip
  293. _SaveClip:    movem.l d4/a2,-(sp)
  294.         movem.l 24(sp),d0-d4
  295.         movem.l 12(sp),a0-a2
  296.         move.l    _IFFBase,a6
  297.         jsr    -72(a6)
  298.         movem.l (sp)+,d4/a2
  299.         rts
  300.  
  301.         xdef    _IffError
  302. _IffError:    move.l    _IFFBase,a6
  303.         jmp    -78(a6)
  304.  
  305.         xdef    _GetViewModes
  306. _GetViewModes:    move.l    4(sp),a1
  307.         move.l    _IFFBase,a6
  308.         jmp    -84(a6)
  309.  
  310.         end
  311.  
  312.  
  313.     <mike
  314.  
  315. --
  316. I know the world is flat.                Mike Meyer
  317. Don't try tell me that it's round.                      mwm@berkeley.edu
  318. I know the world stands still.                ucbvax!mwm
  319. Don't try to make it turn around.                       mwm@ucbjade.BITNET
  320.  
  321. ============================================================================
  322.  
  323. From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
  324. Subject: Re: IFF.LIBRARY
  325. Date: 6 Dec 88 02:56:35 GMT
  326. Organization: Missionaria Phonibalonica
  327.  
  328.  
  329. Whoops - I made a major mistake. The prototype for SaveClipRect should
  330. be filled out with 'long', not 'int'. That way, if you compile with 16
  331. bit ints, the compiler will still push longs for you - and not
  332. complain when you give it longs.
  333.  
  334.     <mike
  335. --
  336. ICUROK2C, ICUROK2.                Mike Meyer
  337. ICUROK2C, ICWR2.                mwm@berkeley.edu
  338. URAQT, I WANT U2.                ucbvax!mwm
  339. OO2EZ, I WANT U2.                mwm@ucbjade.BITNET
  340.  
  341. ============================================================================
  342.  
  343. From: lel@wuphys.UUCP (Lyle E. Levine)
  344. Subject: Re: IFF.LIBRARY
  345. Date: 8 Dec 88 07:20:12 GMT
  346. Organization: Physics Dept., Washington U. in St. Louis
  347.  
  348.  
  349. In article <17861@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:
  350. >
  351. >I'd add a "#ifndef" around those pragmas. I also turned the function
  352. >declarations into prototypes:
  353. >
  354. >
  355. >/************** F U N C T I O N   D E C L A R A T I O N S ***************/
  356. >
  357. >struct Chunk *FindChunk(APTR, char *);
  358.                    ^^^^^^
  359. This is what is implied by the docs but it doesn't work this way.
  360. It should be a (APTR, ULONG). The format used is packed ASCII.
  361. Thus:
  362.  
  363.    cname = 0x43524e47;         /* This is packed ASCII for 'CRNG' */
  364.    CRNGstart = FindChunk(ifffile,cname);
  365.  
  366. /* 'C' = 0x43, 'R' = 0x52, 'N' = 0x4e, 'G' = 0x47 */
  367.  
  368. By the way, one gotcha: on the first calling, FindChunk returns a
  369. pointer to the first chunk of the requested type. On subsequent
  370. callings, it still returns a pointer to this SAME FIRST CHUNK!!!
  371. Thus, if the file has > 1 'CRNG' chunk (as a common example),
  372. FindChunk will NOT FIND ANY BUT THE FIRST!!!!!! Since OpenIFF()
  373. reads the file into memory and FindChunk() gives a pointer to the
  374. first chunk of the requested type, you can just change 'CRNG'
  375. into say 'CRNF' in memory and call FindChunk() again to get the
  376. next 'CRNG' chunk.  It's dirty but it works. UGH!!!!  Leo, I am
  377. eagerly awaiting your library.    If it wasn't for the speed of the
  378. loader in this one, I'd go back to my own routines. At least they
  379. get the job done.
  380.  
  381.  
  382. >/************** F U N C T I O N   P R A G M A S ***************/
  383.  
  384. Glad you liked my PRAGMAS :^)
  385.  
  386. *** PETS ***    Programmers Extraordinaire, Technically Supportive!
  387.  
  388. ==========
  389. IBM is a Division of Sirius Cybernetics Corporation
  390. "their fundamental design flaws are completely hidden by their
  391. superficial design flaws."
  392.             - "So Long And Thanks For All The Fish"
  393.  
  394. Lyle Levine: Paths -> ihnp4!wuphys!lel         Best way: (314)889-6379
  395.               uunet!wucs!wuphys!lel
  396.  
  397. ============================================================================
  398.  
  399. To: uts.amdahl.com!kim
  400. Subject: Christian Weber?
  401. Date: Thu, 22 Dec 88 13:46:26 EST
  402. From: barrett@cs.jhu.edu
  403.  
  404.  
  405. Hi Kim:
  406.  
  407.     Since you submitted the "IFF library" to the Amiga source archives,
  408. I am writing to you.  I would like to send a bug report to Christian A.
  409. Weber, the author of the IFF library.  He did not include his mailing
  410. address in his program.
  411.  
  412.     If there is a way to forward e-mail to him, could you forward
  413. this letter?  If not, perhaps you can tell me how to get in touch with
  414. him.  Otherwise... never mind!
  415.  
  416.     Thanks so much.
  417.  
  418.                             Dan
  419.  
  420. ------------------------------ cut here -----------------------------------
  421.  
  422. Dear Mr. Weber:
  423.  
  424.     I have found a problem in your IFF library, version 15.3.  The
  425. following sequence of commands illustrates the problem.
  426.  
  427.     1> copy iff.library LIBS:
  428.     1> grabbit
  429.     1> ShowIff grabbit.pic
  430.  
  431.         (Picture gets shown just fine.)
  432.  
  433.         (Now hit ^C.  ShowIff ends.)
  434.  
  435.     1> ShowIff grabbit.pic
  436.     Copy the iff.library to your LIBS: directory!
  437.     1>
  438.  
  439. In other words, the iff.library gets "lost" if I hit ^C.  This might be
  440. a problem with ShowIFF and not the iff.library, but I wanted you to be
  441. aware of it.
  442.  
  443.     Thanks for a great product!
  444.  
  445.                             Dan
  446.  
  447. #############################################################################
  448. # Dan Barrett    barrett@cs.jhu.edu    (128.220.13.4)  ARPA                #
  449. # Dept. of Computer Science, Johns Hopkins University, Baltimore, MD  21218 #
  450. #############################################################################
  451.  
  452. ----------------------------- end of letter ------------------------------
  453.