Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-188.txt

Text File | 1994-12-08 | 45.0 KB | 1,186 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 20 Oct 92       Volume 1 : Issue 188

Today's Topics:

    PGP - public key encryption for the Mac!!
    updating window text / getting text lines from buffer
    dereferencing Handles( was Re: incrementation differences/THINK C 4.0 vs. 5.0)
    Advice requested: keyboard programming
    Shareware legality question
    JPEG <-> JFIF with QT.
    handles and MoveHHi



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Bill Williams)
Subject: PGP - public key encryption for the Mac!!
Date: 12 Sep 92 05:58:50 GMT
Organization: HoloNet (BBS: 510-704-1058)

"David Meyers at Georgia Institute of Technology" observed that several
people are using a VERY GOOD mail encryption technology called PGP (Pretty
Good Privacy) and asked for the following info...

PGP 2.0 is discussed in detail in Sept 1992 "BoardWatch" BBS magazine.

PGP uses some RSA-ish stuff and other cryptographic technologies. And is
IMPORTED from abroad and therefore in theory can be exported from this
fascist sick country controlled by the NSA.

PGP  2.0 uses IDEA (International Data Encryption Algorithm" from the
Univ. of Switzerland (ETH Zurich) and thus is not controlled or crippled
by NSA "plants" or NSA restrictions.

PGP SOURCE can be obtained from locations directed from its original
author at address "[e-mail]" but if you bother Philip
Zimmerman unless you are a researcher with important issues, it would be
tacky. Instead FTP the MSDOS source directly from outside the country!

just ftp kauri.vuw.ac.nz  and   cd to /pub/ms-dos/Encryption to get the
source files "PGP20SRC.ZIP"

If you are not a programmer this knowledge will do you no good for the Mac.

BWilliams



+++++++++++++++++++++++++++

From: [e-mail] (HP48SX Archive Maintainer)
Date: 12 Sep 1992 11:06:12 -0500
Organization: Washington University in Saint Louis, MO USA

Please do not download pgp from the site in New Zealand.
As the site mentions: No everseas ftp, it costs them money.
I suggest you check with archie for a closer site or download it from:
nic.funet.fi   /pub/msdos/utilities/sysutl     (Europe)
urth.acsu.buffalo.edu   /pub
gatekeeper.dec.com   /.2/micro/msdos/pgp
pc.usl.edu   /pub/msdos/crypto

just to mention a f. Use archie if you want more addresses.
- --
Povl H. Pedersen             [e-mail]
HP48sx archive maintainer

All Opinions (C) Copyright the Intergalactic Thought Association

---------------------------

From: [e-mail] (Peter C. Gorman)
Subject: updating window text / getting text lines from buffer
Date: 25 Aug 92 15:14:09 GMT

Hello -

I have a couple of basic text-handling questions (using Think C):

1. What's the standard way to update text in a window?  For instance, if I
display a value that needs to be changed periodically, do I DrawString(),
then at update time draw a white rectangle over it and DrawString with the
new value?

2. If I load a text file into a buffer, what's the best way to get it out
a line at a time?  Do I write a version of fgets that gets it from the
buffer, or is this a standard Mac function that's posted somewhere?

Sorry if these are idiot questions; I'm new to both Mac and C programming.
Thanks for your help.

- --
Peter Gorman
University of Pennsylvania
Library Systems Office
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Joshua Rabinowitz-Summer-91)
Date: 25 Aug 92 23:24:49 GMT
Organization: NASA/ARC Information Sciences Division

In article <[e-mail]> [e-mail] (Peter C. Gorman) writes:
>I have a couple of basic text-handling questions (using Think C):
>1. What's the standard way to update text in a window?  For instance, if I
>display a value that needs to be changed periodically, do I DrawString(),
>then at update time draw a white rectangle over it and DrawString with the
>new value?

This is a good, quick way.

>
>2. If I load a text file into a buffer, what's the best way to get it out
>a line at a time?  Do I write a version of fgets that gets it from the
>buffer, or is this a standard Mac function that's posted somewhere?

Sure, write the fgets-type function.  there is a method of reading from
a file documented somewhere in IM for getting the filemanager to
parse files into lines delimited by any desired char ('\n' in this case)
using PBRead (I believe).

If anyone has written a code snippet that does this, pls. inform me
as to how this is done.  Posting here is okay, but mailing me a code snippet
would be godly.

Thanks

>Peter Gorman
>University of Pennsylvania
>Library Systems Office
>[e-mail]


- --
- ----------------------------------
#include <std/disclaimer.h>     Josh Rabinowitz, Mac TCL programmer
[e-mail]
"Send a salami to your boy in the army" - Katz's delicatessen, NYC

+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Date: 28 Aug 92 19:08:26 GMT
Organization: UM Home for the Terminally Analytical

In article <[e-mail]>,
[e-mail] (Joshua Rabinowitz-Summer-91) wrote:

> ...  there is a method of reading from
> a file documented somewhere in IM for getting the filemanager to
> parse files into lines delimited by any desired char ('\n' in this case)

> If anyone has written a code snippet that does this, pls. inform me
> as to how this is done.  Posting here is okay, but mailing me a code snippet
> would be godly.

var
    junk:    Integer;
    Buff:    Packed Array[0..255] of SignedByte;
    PBRec:    ParamBlockRec;
begin
    PBRec.ioRefNum := theFile;
    PBRec.ioBuffer := @Buff;
    PBRec.ioPosMode := $0D80;  <<----80 is read till EOL bit, 0D is CR!
    PBRec.ioPosOffset := 0;
    PBRec.ioReqCount := 256;
    junk := PBReadASync(@PBRec);
    UseText(PBRec.ioActCount,@Buff);

Yipe, I figured this out so long ago I was still doing Pascal...
Bear skins and stone knives...

[e-mail]     -KA3ZDF

+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Date: 28 Aug 92 23:48:55 GMT
Organization: UM Home for the Terminally Analytical

In article <[e-mail]>,
[e-mail] (Charles B. Cranston) wrote:

> var
>     junk:    Integer;
>     Buff:    Packed Array[0..255] of SignedByte;
>     PBRec:    ParamBlockRec;
> begin
>     PBRec.ioRefNum := theFile;
>     PBRec.ioBuffer := @Buff;
>     PBRec.ioPosMode := $0D80;  <<----80 is read till EOL bit, 0D is CR!
>     PBRec.ioPosOffset := 0;
>     PBRec.ioReqCount := 256;
>     junk := PBReadASync(@PBRec);
                 ^ urp!
>     UseText(PBRec.ioActCount,@Buff);

Yeah, I tried to get funky and replace PBRead(@PBRec,False) on
the fly and got it wrong.  It should be PBReadSync not ASync.

[e-mail]     -KA3ZDF

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Urlichs)
Date: 10 Sep 92 15:38:30 GMT
Organization: University of Karlsruhe, FRG

In comp.sys.mac.programmer, article <[e-mail]>,
  [e-mail] (Charles B. Cranston) writes:
> In article <[e-mail]>,
> [e-mail] (Joshua Rabinowitz-Summer-91) wrote:
>
> > a file documented somewhere in IM for getting the filemanager to
> > parse files into lines delimited by any desired char ('\n' in this case)
>
[ PBRead{A}Sync example deleted ]

Depending on what you're doing, though, it may be a lot faster if you
allocate a largish buffer and just read your lines out of it.
PBRead is _slow_ if used unbuffered. I once wrote a TIFF reader and dropping
my own stupid buffer into the read procedure made the file reader five times
faster.

- --
Why does the porridge bird lay her egg in the air?
- --
Matthias Urlichs  --  [e-mail] -- [e-mail]   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  [phone]     \o)/

---------------------------

From: [e-mail] (Gary Cote)
Subject: dereferencing Handles( was Re: incrementation differences/THINK C 4.0 vs. 5.0)
Organization: Bell-Northern Research Ltd.
Date: Tue, 25 Aug 1992 15:09:11 GMT

In article <[e-mail]>,
[e-mail] (Matthew Marx) writes:
    < stuff about how he's maintaining someone else's code deleted >
|>Boolean
|>nxtWrd(char **theDataPtr, char *lab, int  tabs)
|>{
|>    char *temp;
|>    int i=0;
|>
|>    temp = *theDataPtr;
|>
|>    while(*temp == '\t')
|>    {
|>        temp++; i++;
|>    }
    < more stuff regarding ThinkC's order of operator evaluation >

    Does this snippet violate the rule of safe handle conventions? It seems
to me that
once theDataPtr is dereferenced and copied into temp, this leaves him
open to the great
disappearing memory trick. Assuming that the block theDataPtr is
relocatable and
not locked, temp has the potential for becoming obsolete if the block is moved.

    If I am incorrect, I apologize. I haven't been programming the Mac very long.

    Would someone please post a clarification ( my access to e-mail is
restricted ).


|>--
|>Matt Marx       [e-mail]
|>"Too much time on my hands..." -- Styx
|>"Too many hands on my time..." -- Rush
|>


Gary B. Cote
[e-mail]      -for one more week, but I'm not confident that
e-mail will reach me
[e-mail]  -starting September 7



+++++++++++++++++++++++++++

From: [e-mail] (Stepan Riha)
Organization: National Instruments, Austin, TX
Date: Tue, 25 Aug 1992 17:42:28 GMT

In article <[e-mail]> [e-mail] (Gary Cote) writes:

Gary asks whether the following snippet violates "safe hadnle conventions"

>|>nxtWrd(char **theDataPtr, char *lab, int  tabs)
>|>{
>|>    char *temp;
>|>    int i=0;
>|>
>|>    temp = *theDataPtr;
>|>
>|>    while(*temp == '\t')
>|>    {
>|>        temp++; i++;
>|>    }

>[It seems that]
>once theDataPtr is dereferenced and copied into temp, this leaves him
>open to the great disappearing memory trick...

The answer is NO!  temp is going to be fine as long as no functions is
called that might relocate memory.  Thus, if you were to call NewPtr or
NewHandle (for example) *after*  temp = *theDataPtr;  then you would be in
trouble.  Since the only things that are being done are assignment, comparisons
and some arithmetics temp is quite safe.

However a thing to be carefull about is code of the form:

    Handle    h;

    *h = foo();

where foo() causes memory to be relocated.  If the LHS is evaluated first, it
might be incorrect once foo is called.  The correct way to write this would be

    Handle    h;
    char    c;

    c = foo();
    *h = c;

    - Stepan
- --
   Stepan Riha -- [e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Organization: Taligent
Date: Tue, 25 Aug 1992 19:22:51 GMT

In article <[e-mail]>, [e-mail] (Gary Cote)
writes:
>
> In article <[e-mail]>,
> [e-mail] (Matthew Marx) writes:
>     < stuff about how he's maintaining someone else's code deleted >
> |>Boolean
> |>nxtWrd(char **theDataPtr, char *lab, int  tabs)
> |>{
> |>    char *temp;
> |>    int i=0;
> |>
> |>    temp = *theDataPtr;
> |>
> |>    while(*temp == '\t')
> |>    {
> |>        temp++; i++;
> |>    }
>     < more stuff regarding ThinkC's order of operator evaluation >
>
>     Does this snippet violate the rule of safe handle conventions? It seems
> to me that
> once theDataPtr is dereferenced and copied into temp, this leaves him
> open to the great
> disappearing memory trick. Assuming that the block theDataPtr is
> relocatable and
> not locked, temp has the potential for becoming obsolete if the block is
moved.
>
>     If I am incorrect, I apologize. I haven't been programming the Mac very long.
>
>     Would someone please post a clarification ( my access to e-mail is
> restricted ).


Fortunately for the entire world, the Mac Memory Manager moves blocks only at
very well defined times. One very gross rule that you could follow is that if
you don't call any Memory Manager traps (either explicitly or implicitly by
calling subroutines or other traps that in turn call the Memory Manager), then
memory blocks won't move. Using our WayBack machine and resurrecting the
original code:

Boolean nxtWrd(char **theDataPtr, char *lab, int  tabs)
{
    char *temp;
    int i=0;

    temp = *theDataPtr;

    while(*temp == '\t')
        temp++; i++;

    if (i == tabs) {
        i = 0;
        while (temp[i] && (i<(WORDMAX-1)) && (temp[i] != '\n')) {
            lab[i] = temp[i++];  //****THIS IS THE PROBLEM
        }
        lab[i] = '\0';
        while (temp[i] && temp[i]!= '\n') i++;
        if (temp[i] == '\n') i++;
        *theDataPtr = temp+i;
        return TRUE;
    }
    else return FALSE;
}


You'll see a complete lack of calls to the Toolbox or OS. Therefore, memory will
not move, and his pointers will be safe.

OK, OK, before some hotshot jumps down my throat, there _is_ a case you have to
look out for with the above code. I mentioned earlier that even implicit calls
to the Memory Manager could get you into trouble. Sometimes these implicit calls
are very subtle. For instance, assume that the above code is compiled on a
system where ints are 32-bits long (like they are under MPW). Also assume that,
instead of pointing to chars, "temp" points to something larger. In order to
create the offset to the appropriate entry when working with 32-bit indexes, the
compiler will call a standard library routine to perform the long
multiplication. IF THE CODE SEGMENT HOLDING THE LIBRARY MULTIPLICATION ROUTINE
IS NOT LOADED, it will automatically be loaded, which will cause memory blocks
to move around, possibly invalidating "temp". Normally, this won't happen,
because people usually put those library routines in their Main segment, which
is always loaded. But it's something to keep in mind.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 26 Aug 92 18:24:47 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Stepan
Riha) wrote:
>
> However a thing to be carefull about is code of the form:
>
>     Handle    h;
>
>     *h = foo();
>
> where foo() causes memory to be relocated.  If the LHS is evaluated first, it
> might be incorrect once foo is called.  The correct way to write this would be

And you not only have to consider whether the code in foo() can relocate
memory, but whether the call to foo() itself might relocate memory.  This
can happen if foo() is in a different segment from the caller, and that
segment has to be brought into memory or moved.  (That implies that some
calls to foo() might not move memory, but others could.)

Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bayes)
Date: 9 Sep 92 19:48:18 GMT
Organization: Hewlett-Packard Co., Loveland, CO

> Your remaining choices are semi-colon, comma and =. In this case,
> semi-colon and comma are semantically identical, so that's not much of a
> problem. Deciding between = and the others is slightly tricky. You can
> resolve this, in part, by seeing which variables have been initialized.
> If only one of the five variables has been initialized, the answer is
> almost certainly = (otherwise, you'd be assigning something to an
> uninitialized variable). Similarly, if both c and e (for example) have
> just been initialized, you're almost certainly missing a semi-colon.
>

How do I tell which ones are initialized?

I might do this:

extern void dosomething;

dosomething(&c);

Is c now initialized or not? How can the compiler tell?

Lots of library routines do this kind of stuff.

The problem I see is that we expect a compiler to be RIGHT. If it's
not RIGHT, then development of my application and its stability are
both at great risk. It's tough enough to get a compiler to produce
rock-solid code, without having it guess.

ScottB

---------------------------

From: [e-mail] (Cuong T. Nguyen)
Subject: Advice requested: keyboard programming
Date: 26 Aug 92 19:41:49 GMT
Organization: Center for Integrated Systems, Stanford University


I want to implement a Vietnamese keyboard for the Mac.
Vietnamese has diacritical marks, like European languages,
except more complex in that a letter may have up to two
diacritics.  The dead-key mechanism is not acceptable
behavior.  The required, non-negotiable (standardized) behavior
is as follows.  Let's say the user needs to type in the single
Vietnamese letter <a^'>.  She will first type "a", and the
system echoes "a".  Then she types "^", the system echoes BS
to clear the "a", then echoes <a^>.  Similarly, when she types "'",
the system echoes Bs, then <a^'>.  Don't worry about the logic
states, character codes, or glyphs involved.  I would just like
to learn how this keyboard behavior can be implemented on a
system-wide basis, that is, when this keyboard mechanism is turned
on, all input windows will behave as described (something like
a specialized keyboard driver or desk accessory, perhaps).

I have scanned through Inside Mac vols at a bookstore and found
KCHR to be in the right neighborhood, but it's still very fuzzy.
I would greatly appreciate a knowledgeable pointer into the right
direction, but not off to a wild goose chase as I am a Mac neophyte.
You don't need to tell me exactly what to do step-by-step
(although that wouldn't hurt :-), but the idea for me is
to try and save re-discovery time.  I am thinking that
a Mac wizard would be able to name in 5 minutes what
the system components are that I need to mess with.

An estimate of task difficulty will also be appreciated.
As a reference, it took me two days to implement this
on Unix (I already knew X), and two weeks on MS-Windows
(had to learn Windows, which fortunately provides for
message hooks which allow you to filter keyboard messages
as well as to generate fake keyboard events for those
BS's I mentioned above).  Does the Mac provide a similar
mechanism?

Thanks in advance,

Cuong

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Urlichs)
Date: 10 Sep 92 16:46:55 GMT
Organization: University of Karlsruhe, FRG

In comp.sys.mac.programmer, article <[e-mail]>,
  [e-mail] (Cuong T. Nguyen) writes:
>
> I want to implement a Vietnamese keyboard for the Mac.

No you don't. You want to implement a Vietnamese script for the Mac.
The difference is that the Mac's Script Manager already supports most of what
you're trying to do, without ugly hacks like backspace-and-replace.
You'll have to implement the Vietnamese-specific parts and (of course) create
one or two Vietnamese fonts.

There already are a few versions of 7.0.1 which do this sort of thing, for
Thai and Korean; I don't know if any of these are sufficiently close to
Vietnamese but the mechanics should be similar.

Support for scripts is supposed to be better in System 7.1, currently in
beta. I haven't been able to try it because I need MacTCP for my "real" work,
and it's severely incompatible with 7.1.  :-(

> An estimate of task difficulty will also be appreciated.

Not that easy. You won't be able to get away with the BS hack; the Mac's not
Unix, nor is it Windows.

- --
Kirk:  "Did you find the Engine Room ?"
Scott: "Right where I left it, sir."

[James T. Kirk, Montgomery Scott --- Star Trek VI: "The Undiscovered Country"]
- --
Matthias Urlichs  --  [e-mail] -- [e-mail]   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  [phone]     \o)/

---------------------------

From: [e-mail] (Matthew Hall)
Subject: Shareware legality question
Date: 31 Aug 92 20:43:47 GMT
Organization: Oberlin College Computer Science

Hello-

I submitted a shareware copyrighted program to sumex-aim.  In the
README file I included a line that read <Public domain houses, such as
Educorp, must contact me before distributing this program>.  I guess I
aint no legal wizard, and I should have worded that more carefully.

A few months later, I recieved a letter and a complimentary CD-ROM
from NAUTILUS saying that they had published my program on the disc.
Now there are several reasons I would like to have been asked
beforehand.
First, the program is going commercial, and I would like to have put a
demo version of the new program on instead.
Second, I would like to have made the shareware fee plea a little
stronger, since people who buy disks from these places think that they
do not need to pay my fee.
Third, I feel I have the right to ask for a fee from them.  A CD-ROM
is actually pretty hefty, but since I do not have a drive, To me, its
utterly useless.
And last, I just plain asked to know beforehand, and they should have
asked.

Do I have any rights here, or did I goof with my language.  Or should
I just write a kind/nasty letter explaining to them how I feel.  It
disturbs me a little that these people are using my program to make a
profit (not, of course, that people are buying the NAUTILUS CD in
droves because of it, but still) Does anybody have a similar
experience?

- -matt hall

- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Mon, 31 Aug 1992 23:29:29 GMT

[e-mail] (Matthew Hall) writes:

>I submitted a shareware copyrighted program to sumex-aim.  In the
>README file I included a line that read <Public domain houses, such as
>Educorp, must contact me before distributing this program>.  I guess I
>aint no legal wizard, and I should have worded that more carefully.

>Do I have any rights here, or did I goof with my language.  Or should
>I just write a kind/nasty letter explaining to them how I feel.  It
>disturbs me a little that these people are using my program to make a
>profit (not, of course, that people are buying the NAUTILUS CD in
>droves because of it, but still) Does anybody have a similar
>experience?

Does the program or documentation say "Copyright Matthew Hall"
anywhere? If so, I think you have a case. The lawyer folks I spoke to
before sending out my shareware program said that so long as it says
"Copyright Me" on it, you have the only right to copy it and grant
only rights to copy as enumerated. I think your line from the README
file is enough to cover you in court. If you want to push it, I think
you can do something here. Check with a lawyer.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Joseph Nathan Hall)
Date: Tue, 1 Sep 92 01:36:13 EDT
Organization: 5 Sigma Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Pete Resnick) writes:
) >I submitted a shareware copyrighted program to sumex-aim.  In the
) >README file I included a line that read <Public domain houses, such as
) >Educorp, must contact me before distributing this program>.  I guess I
) >aint no legal wizard, and I should have worded that more carefully.
)
) >Do I have any rights here, or did I goof with my language.

You can certainly make them stop.  Alas, you have no other remedy
if your work is not registered with the Library of Congress.

As I understand the law:

If you work is unpublished (which in this case, it is not), you need
not include any copyright notice in order to prevent its unauthorized
distribution and/or reproduction.  In fact, you must explicitly waive
your rights.  Since US copyright law reform you automatically have copyright
of any work (excepting work-for-hire, etc.), even if there is no copyright
notice.

If you distribute your work in a way that looks like publication,
you must have a copyright notice to protect your rights.  However,
this does not allow you to seek any remedy other than to force someone
who is distributing/reproducing/etc. your work without authorization
to stop.  This is the criminal portion of the law, more or less.
I think that the method for sending people to jail if they persist
is contempt of court, but I'm not sure.

If you want civil damages, you must 1) register with LOC, and 2) take
the offender to court.  In that order.  You can't register after the
offense was committed and get post facto damages, alas.

A stiffly worded letter to the offender, either from you or from a
lawyer, should bring results.  Do not be afraid to threaten, even
if your threats are idle!  This is what lawyers do, and you can do
it too.

I'd suggest registering your work with LOC in the future.  That alone
wouldn't save you the trouble of hiring a lawyer ($$$), but you could
possibly recover some $ from the offender.

uunet!joebloe!joseph   [phone] day   [e-mail]
v   v  sssss | Certified Guru: all-grain brewing,| 2102 Ryan's Run East
 v v  s   s  | C, synthesizer comp & arranging,  | Rt 38 & 41
  v    sss   | photography. Also not a bad cook. | Maple Shade NJ 08052
- -----My employer isn't paying for this, and my opinions are my own-----

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 1 Sep 92 01:01:16 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Matthew Hall) writes:
>
> Hello-
>
> I submitted a shareware copyrighted program to sumex-aim.  In the
> README file I included a line that read <Public domain houses, such as
> Educorp, must contact me before distributing this program>.  I guess I
> aint no legal wizard, and I should have worded that more carefully.
>
> A few months later, I recieved a letter and a complimentary CD-ROM
> from NAUTILUS saying that they had published my program on the disc.
> Now there are several reasons I would like to have been asked
> beforehand.
> First, the program is going commercial, and I would like to have put a
> demo version of the new program on instead.
> Second, I would like to have made the shareware fee plea a little
> stronger, since people who buy disks from these places think that they
> do not need to pay my fee.
> Third, I feel I have the right to ask for a fee from them.  A CD-ROM
> is actually pretty hefty, but since I do not have a drive, To me, its
> utterly useless.
> And last, I just plain asked to know beforehand, and they should have
> asked.
>
> Do I have any rights here, or did I goof with my language.  Or should
> I just write a kind/nasty letter explaining to them how I feel.  It
> disturbs me a little that these people are using my program to make a
> profit (not, of course, that people are buying the NAUTILUS CD in
> droves because of it, but still) Does anybody have a similar
> experience?

I don't really understand this reasoning.  I love it when these places
put my shareware on their disks.  Their customers *do* pay for shareware
- - though at about the same rate as people who get it off the online
services or BBSes (single digit percentage if that).

How is Nautilus any different than America Online or Compuserve?
They each make money from their subscribers and they each make shareware
available.

As to your question, is it really worth money to you to try to bring
legal action against them.  I imagine this would burn up any profits
you have made from your shareware very quickly!

If you really feel bad, write them that nasty letter and get it off
your chest.

P.S.  AppSizer was just on the Nautilus CD last month - and I'm happy
about it.

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Tim McClarren)
Organization: University of Illinois at Urbana
Date: Tue, 1 Sep 1992 18:20:14 GMT

[e-mail] (Joseph Nathan Hall) writes:


>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Pete Resnick) writes:
>) >I submitted a shareware copyrighted program to sumex-aim.  In the
>) >README file I included a line that read <Public domain houses, such as
>) >Educorp, must contact me before distributing this program>.  I guess I
>) >aint no legal wizard, and I should have worded that more carefully.
>)
>) >Do I have any rights here, or did I goof with my language.

>You can certainly make them stop.  Alas, you have no other remedy
>if your work is not registered with the Library of Congress.

>As I understand the law:

>If you work is unpublished (which in this case, it is not), you need
>not include any copyright notice in order to prevent its unauthorized
>distribution and/or reproduction.  In fact, you must explicitly waive
>your rights.  Since US copyright law reform you automatically have copyright
>of any work (excepting work-for-hire, etc.), even if there is no copyright
>notice.

Yes, this is exactly right and is known as implicit copyright.  It protects
authors from stolen work.  Anyways, a letter from your lawyer would probably
be most effective, and some lawyers charge a nominal fee (last time I did
it it cost me $50) for the service.  Is it worth the $50 to you?

- --
Tim McClarren     | "...a bajillion brilliant Jobsian lithium licks."
[e-mail]|
[phone]     |

+++++++++++++++++++++++++++

From: [e-mail] (Sean J. Crist)
Date: 12 Sep 92 02:55:34 GMT
Organization: University of Delaware

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Pete Resnick) writes:
>) >I submitted a shareware copyrighted program to sumex-aim.  In the
>) >README file I included a line that read <Public domain houses, such as
>) >Educorp, must contact me before distributing this program>.  I guess I
>) >aint no legal wizard, and I should have worded that more carefully.
>)
>) >Do I have any rights here, or did I goof with my language.
>
>You can certainly make them stop.  Alas, you have no other remedy
>if your work is not registered with the Library of Congress.

I am almost certain that this is not correct.  A few years ago, I was
in the middle of a very annoying and complicated legal snarl involving
some copyrighted material, and I requested some free literature from
(I believe) the U.S. Copyright Office in Washington (I may be wrong
about the department name).

I remember reading that you don't have to register your work with the
Library of Congress for your work to be copyrighted; all you have to
do is include a copyright notice in the form (c) 1992 by Joe Smith.
It seems to me that the literature specifically dismissed the need
to register with the Library of Congress as a common myth.
What registry with the Library of Congress does accomplish is to
make it much easier for you to establish yourself as the rightful
holder of the copyright, should the issue ever go to court.

I recommend that you call information in Washington, obtain the number
for the U.S. Copyright Office, and request literature on copyrighting
your work.  I hope you did include a copyright notice with your
material, since you give up your copyright once your work is released
without one.

- --Kurisuto
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Xavier Mora)
Date: 14 Sep 92 20:21:12 GMT
Organization: SRI International

In article <[e-mail]>, [e-mail] (Sean J.
Crist) wrote:
> I remember reading that you don't have to register your work with the
> Library of Congress for your work to be copyrighted; all you have to
> do is include a copyright notice in the form (c) 1992 by Joe Smith.
                                               ^^^

Won't do. It has to be the real copyright symbol or the word Copyright.
"(c)" is not covered.


Matt

---------------------------

From: [e-mail] (Mike Neil)
Subject: JPEG <-> JFIF with QT.
Date: Fri, 28 Aug 92 21:20:47 EDT
Organization: CAEN (UofM)

  Just thought I'd pass this tidbit of info on to you folks.
  I was working on converting JFIF (JPEG File Interchange Format) files
to QT JPEG files.  I looked at porting the PD JPEG code (available on
think.com) to the Mac.  But I noticed that the Pict Viewer App that
comes on the QT CD was able to read and write JFIFs.  So I looked at
it a bit more, and fould that the data portion that is returned from a
CompressImage call is in the JFIF format (Someone give the QT guys another
cookie).  So basically you can read a JFIF file into memory pass it into
the DecompressImage call (You will need to make a Info block by hand).
and you will get a decompressed image out.  Very Cool.

- -Mike Neil
P.S.  Couldn't find any mention of this in the QT docs so my guess is
it is an unsupported feature.

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 5 Sep 92 05:31:21 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail].>, [e-mail] (Mike Neil) writes:
>
>   I noticed that the Pict Viewer App that
> comes on the QT CD was able to read and write JFIFs.  So I looked at
> it a bit more, and fould that the data portion that is returned from a
> CompressImage call is in the JFIF format (Someone give the QT guys another
> cookie).  So basically you can read a JFIF file into memory pass it into
> the DecompressImage call (You will need to make a Info block by hand).
> and you will get a decompressed image out.  Very Cool.
>
> P.S.  Couldn't find any mention of this in the QT docs so my guess is
> it is an unsupported feature.

I had a read of the JFIF specs. The main thing it offers you over vanilla
JPEG is the X and Y resolution information, which gives you some idea of what
scale to view the image at. It is true, though, that the QuickTime JPEG
compressor reads and writes a standard JPEG data stream (well, it would have
to, wouldn't it?). Thus it's very easy to read and write JPEG files on a
QuickTime-equipped Mac.

Things get a little harder, though, if the image is too big to fit in memory
all at once. Then you have to figure out how to use data loading and unloading
routines with the Image Compression Manager...

Here's one useful piece of information about the JPEG data stream, for those
(like me) who have never seen a copy of the JPEG spec: if you want to determine
the size of the image, look for a hex FF byte followed by a hex C0 byte. Skip
the next three bytes, and you will find a 2-byte integer containing the number
of lines, followed by a 2-byte integer containing the number of columns. Both
are in big-endian format (ie on a Mac, you don't have to worry about it).

Thanks to Dolf Starreveld at Storm Technology for telling me this, along with
several other interesting things, a long time ago...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Ask not for whom the phone rings; it rings for you.

+++++++++++++++++++++++++++

From: [e-mail] (Tom Lane)
Date: 13 Sep 92 04:48:56 GMT
Organization: School of Computer Science, Carnegie Mellon

(Sorry for the slow response ... don't read this group often.)

[e-mail] (Mike Neil) says:
> the data portion that is returned from a
> CompressImage call is in the JFIF format (Someone give the QT guys another
> cookie).  So basically you can read a JFIF file into memory pass it into
> the DecompressImage call (You will need to make a Info block by hand).
> and you will get a decompressed image out.  Very Cool.

I don't recall offhand whether QT makes a true JFIF file (complete with JFIF
marker) or just a "raw JPEG" file.  Either way, though, the information is
compatible with non-Mac JFIF/JPEG programs.  The JFIF marker is considered
optional by most non-Mac decoders; it really just certifies that the file
adheres to the JFIF conventions about colorspace.

> Couldn't find any mention of this in the QT docs so my guess is
> it is an unsupported feature.

I think it's reasonably safe to rely on it --- Apple's chief JPEG engineer
has spent a good deal of time making sure QT is compatible with JFIF-based
decoders :-)

And [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> Here's one useful piece of information about the JPEG data stream, for those
> (like me) who have never seen a copy of the JPEG spec: if you want to
> determine the size of the image, look for a hex FF byte followed by a hex C0
> byte. Skip the next three bytes, and you will find a 2-byte integer
> containing the number of lines, followed by a 2-byte integer containing the
> number of columns.

Bzzt.  Sorry, but that method is guaranteed to break sooner or later.  If
you want reliable info, you have to parse the JPEG marker sequence, at least
well enough to skip over the arbitrary data that may be inside marker bodies
preceding the SOF marker.

If you don't want to buy a copy of the JPEG standard, at least go read the
free JPEG code available from ftp.uu.net: graphics/jpeg/ ... in particular,
jrdjfif.c will show you how to do this right.  It only takes a few more
lines of code.

                regards, tom lane

+++++++++++++++++++++++++++

From: [e-mail] (Aaron Giles)
Organization: University of Chicago High Energy Physics
Date: Sun, 13 Sep 1992 23:50:34 GMT

In article <[e-mail]> [e-mail] (Tom Lane) writes:

> [e-mail] (Mike Neil) says:
> > the data portion that is returned from a
> > CompressImage call is in the JFIF format (Someone give the QT guys another
> > cookie).  So basically you can read a JFIF file into memory pass it into
> > the DecompressImage call (You will need to make a Info block by hand).
> > and you will get a decompressed image out.  Very Cool.

> I don't recall offhand whether QT makes a true JFIF file (complete with JFIF
> marker) or just a "raw JPEG" file.  Either way, though, the information is
> compatible with non-Mac JFIF/JPEG programs.  The JFIF marker is considered
> optional by most non-Mac decoders; it really just certifies that the file
> adheres to the JFIF conventions about colorspace.

Actually, QT *does* include the JFIF marker and in fact produces a
perfectly acceptable JFIF output, not simply a JFIF-compatible output.

Aaron Giles
[e-mail]

---------------------------

From: [e-mail] (Francois Schiettecatte)
Subject: handles and MoveHHi
Organization: Johns Hopkins Univ. Welch Medical Library
Date: Sun, 13 Sep 1992 16:12:38 GMT

Hi, sorry if these questions are a FAQ but here goes:

- - is there a real advantage to using MoveHHi before locking your
handles, I have not really seen much on that except that Think Reference
suggests that is *may* help in reducing heap fragmentation. Are there
any definite rules for using MoveHHi and caveat.

- - Also when passing parameters in C is it better to use pointers or
handles. I guess the answer is really along the lines of it depends
on what you do with them afterwards, ie do you lock them, do you need to
allocate new memory, etc. Does anyone have any guidelines for this.

If there is interest, I wil post back a summary.

thansk

francois


[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Sun, 13 Sep 1992 18:37:11 GMT

> [e-mail] (Francois Schiettecatte) writes:

   Hi, sorry if these questions are a FAQ but here goes:

   - is there a real advantage to using MoveHHi before locking your
   handles, I have not really seen much on that except that Think Reference
   suggests that is *may* help in reducing heap fragmentation. Are there
   any definite rules for using MoveHHi and caveat.

MoveHHi is, uh, somewhat expensive since the toolbox
goes to a fair amount of trouble to move stuff out of
the way and move the handle HIGH up in the heap.

If you're going to keep the handle locked for a long
time (i.e. a minute or more...) it's a very good idea,
but if you only lock the handle to pass it to a toolbox
routine, it's no idea. (Or rather, a bad idea)

   - Also when passing parameters in C is it better to use pointers or
   handles. I guess the answer is really along the lines of it depends
   on what you do with them afterwards, ie do you lock them, do you need to
   allocate new memory, etc. Does anyone have any guidelines for this.

Well, if it's a handle from the start, pass it as a handle
as far as possible, because you get more constrained when
you can't "do" anything with a handle. Also, if your function
takes a pointer, never assume that's a dereferenced handle.
RecoverHandle is EXPENSIVE! The reverse is also true; don't
pass the address of a pointer to something that wants a handle.

- --
Jon W{tte, [e-mail], Sweden, Phone [phone]

Help eradicate FIDO-Net <-> Usenet gateways in our time!

+++++++++++++++++++++++++++

From: [e-mail] (Dean Yu)
Date: 14 Sep 92 17:36:44 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Jon W{tte) wrote:
>
> > [e-mail] (Francois Schiettecatte) writes:
>
>    - is there a real advantage to using MoveHHi before locking your
>    handles, I have not really seen much on that except that Think Reference
>    suggests that is *may* help in reducing heap fragmentation. Are there
>    any definite rules for using MoveHHi and caveat.
>
> MoveHHi is, uh, somewhat expensive since the toolbox
> goes to a fair amount of trouble to move stuff out of
> the way and move the handle HIGH up in the heap.
>
> If you're going to keep the handle locked for a long
> time (i.e. a minute or more...) it's a very good idea,
> but if you only lock the handle to pass it to a toolbox
> routine, it's no idea. (Or rather, a bad idea)
>
>    - Also when passing parameters in C is it better to use pointers or
>    handles. I guess the answer is really along the lines of it depends
>    on what you do with them afterwards, ie do you lock them, do you need to
>    allocate new memory, etc. Does anyone have any guidelines for this.
>
> Well, if it's a handle from the start, pass it as a handle
> as far as possible, because you get more constrained when
> you can't "do" anything with a handle. Also, if your function
> takes a pointer, never assume that's a dereferenced handle.
> RecoverHandle is EXPENSIVE! The reverse is also true; don't
> pass the address of a pointer to something that wants a handle.
>

  In addition to what Jon said, if you're using a handle for the sake of
using a handle, and you keep it locked for the duration of your program's
life, you might as well use a pointer and save yourself a dererference.
This won't cost you much in terms of fragmentation, since pointers are
created as low in the heap as possible.  If you create all the pointers you
need early in your program, your non-relocatable blocks should be neatly
organized at the bottom of your heap.

- -- Dean Yu
   Blue Meanie, Negative Ethnic Role Model, etc.
   Apple Computer, Inc.

---------------------------

End of C.S.M.P. Digest
**********************