ftp.mactech.com 2010/ftp.mactech.com.tar/ftp.mactech.com/csmpdigest/csmp-digest-v3-010

Text File | 2010-09-21 | 54KB | 1,432 lines

Received-Date: Thu, 7 Apr 1994 12:50:15 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-010
To: [e-mail]
Date: Thu, 7 Apr 94 12:50:06 MET DST
X-Mailer: ELM [version 2.3 PL11]
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 12

C.S.M.P. Digest             Thu, 07 Apr 94       Volume 3 : Issue 10

Today's Topics:

        *Simple* CopyMask question
        C-C++ public domain compiler
        Code Fragment Loader and VM
        Code to rebuild desktop?
        CodeWarrior features?
        Graphic Elements release announcement
        How to get Finder icon?
        Porting Think C to CodeWarrior
        Quickdraw GX Beta 3 fun
        Spoofing a serial port
        Using Think Pascal Library in SC++
        rowBytes for the screen too big?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

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.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

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
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks 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 digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


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

>From [e-mail] (Gavin  Kistner)
Subject: *Simple* CopyMask question
Date: 21 Mar 1994 21:07:59 GMT
Organization: Duke University; Durham, NC; USA


I'm new to programming the mac (making my first) and want to use CopyMask
to put a picture over a background with a non-square clip.
The picture is stored as a 'PICT' resource, but CopyMask needs a BitMap
(or pixMap for source or dest) record.  The placement is a one-shot
deal...I've been trying to understand some serious SPRITE toolkits, but
they're way too overkill and (I think) complex.

Can someone give me the simplest, even ineffecient, way to use CopyMask
with 'PICT' resources.  I'm programming in C, if you want to show in
source code :D
Oh, and there are actually many pieces and masks to use...I can either
keep them in one conglomerate picture or put each in its own
resource...you tell me.

One other question - I've used Photoshop to create beautifully dithered
8-bit versions from the 24-bit originals, but when I tell PS to save the
colormap it created, it makes some file that's all data fork...I want a
'clut' to set the palette up correctly, right?  Anyone know of an easy way
to do this?  Or even a hard one?

Many thanks, and may God bless the Mac and especially its programmers!

- Gavin

PS My apologies if this appeared before...I tried to post it last night, but
never was able to find my article.  Perhaps my newsreader is messed -
perhaps it would be best if you could mail replies to me directly.
[e-mail]
--
This message brought to you by Gavin Kistner, aka The Rabid Yak, aka RabYak
[e-mail]   My experimental ftp server: alspaugh-2181.dorm.duke.edu

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

>From [e-mail] (Chris Arsenault)
Date: Thu, 24 Mar 1994 12:26:29 -0500
Organization: Motorola Codex

In article <2ml2bf$[e-mail]>, [e-mail] (Gavin  Kistner)
wrote:

> Can someone give me the simplest, even ineffecient, way to use CopyMask
> with 'PICT' resources?

I'm assuming here that your 'PICT's are primarily pixel or paint images vs
drawn (pict opcode) images.

Grab a copy of Tony Myle's excellent SpriteWorld sprite library on
sumex-aim or some of the other ftp archives.  There are a number of image
functions provided in the utilities file that allow you to load pictures
into GWorlds etc. This is a good starting point for what I describe below.

Draw your pict image in a paint program. Duplicate the file and convert it
to a 1 bit (B&W) image. This is your mask bitmap.  Copy this into your
resource file. Load the mask bitmap into a grafport (there is a function in
the SpriteWorld utils that does this), then use this for your CopyMask
operation, or alternately convert the bitmap mask into a region
(BitmapToRegion) and use CopyBits with the maskRgn.

There are a number of other ways to mask off images, but this should get
you started.

> One other question - I've used Photoshop to create beautifully dithered
> 8-bit versions from the 24-bit originals, but when I tell PS to save the
> colormap it created, it makes some file that's all data fork...I want a
> 'clut' to set the palette up correctly, right?  Anyone know of an easy way
> to do this?  Or even a hard one?

There is a problem with how color information is exchanged when working
with various paint programs. (Images that are copied into a ResEdit PICT do
not retain the correct palette that the paint program uses, but use the
system palette instead)  I'll assume that you are using PS to save the
image as a PICT resource so you should be okay. Do a GetPicture to obtain
the PicHandle, then use the Picture Utilities call GetPictInfo().  This
will return all the information you could need about the picture, including
a CTabHandle (the color table for the picture). The GetPictInfo also
returns a palette. If you assign this palette to the window you're going to
display your picture in, you'll get the correct picture colors in the
window instead of the approximations the Palette Manager provides.

Have fun!
 Chris
--
#include <UsualLegalDisclaimers.h>

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

>From [e-mail] (Giovanni Iachello 366675/IF)
Subject: C-C++ public domain compiler
Date: Mon, 14 Mar 1994 11:55:05 GMT
Organization: B.B.B - Universita' di Padova, Italia

does anybody know where to find a public domain C/C++ compiler for the
MAc? Maybe the GNU compiler?

Thank you!
[e-mail]


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

>From [e-mail] (Stefan Arentz)
Date: Sun, 20 Mar 1994 13:04:42 GMT
Organization: Knoware

In article <[e-mail]>, [e-mail] (Giovanni
Iachello 366675/IF) wrote:

> does anybody know where to find a public domain C/C++ compiler for the
> MAc? Maybe the GNU compiler?
>
> Thank you!
> [e-mail]

On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need
MPW to use it though...

-- Stefan

- -----------------------------------------------------------------------
Stefan Arentz          -- Software Constructor --       [e-mail]

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

>From [e-mail] (Matthew Holiday)
Date: 21 Mar 1994 15:20:47 GMT
Organization: Bell-Northern Research, Richardson, TX

In article <[e-mail]>, [e-mail] (Stefan Arentz) writes:
-> In article <[e-mail]>, [e-mail] (Giovanni
-> Iachello 366675/IF) wrote:
->
-> > does anybody know where to find a public domain C/C++ compiler for the
-> > MAc? Maybe the GNU compiler?
-> >
-> > Thank you!
-> > [e-mail]
->
-> On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need
-> MPW to use it though...

Where can one obtain this CD?  And how much does it cost?

--
Matt Holiday                                  #include <std/disclaimer>
[e-mail]
BNR Richardson, TX            "Proud owner of an unregistered computer"

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

>From [e-mail] (Stan Shebs)
Date: Mon, 21 Mar 1994 18:26:24 GMT
Organization: /cygint/s1/users/shebs/.organization


In article <2mke0f$[e-mail]> [e-mail] (Matthew Holiday) writes:

   -> On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need
   -> MPW to use it though...

   Where can one obtain this CD?  And how much does it cost?

There is also a slightly more up-to-date version of 2.3.3 on
ftp.atg.apple.com.  Neither version is totally usable however,
since they have some bugs in code generation for Pascal-declared
functions.  With care, you might be able to use it, but don't cry
too loudly if the object code crashes and takes your machine with it.

At this point, I've abandoned the 2.3.3 port and am starting over with
a different strategy for 2.5.x, involving very few MPW-Assembler-specific
hacks and a *real* cross-compilation setup (i.e. sit on a Sun and produce
a Mac executable, resources, fat binary, etc as desired).

                            Stan Shebs
                            Cygnus Support
                            [e-mail]

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

>From [e-mail] (Matthew Holiday)
Date: 22 Mar 1994 14:47:05 GMT
Organization: Bell-Northern Research, Richardson, TX

In article <[e-mail]>, [e-mail] (Stan Shebs) writes:
->
-> In article <2mke0f$[e-mail]> [e-mail] (Matthew Holiday) writes:
->
->    -> On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need
->    -> MPW to use it though...
->
->    Where can one obtain this CD?  And how much does it cost?
->
-> There is also a slightly more up-to-date version of 2.3.3 on
-> ftp.atg.apple.com.  Neither version is totally usable however,
-> since they have some bugs in code generation for Pascal-declared
-> functions.  With care, you might be able to use it, but don't cry
-> too loudly if the object code crashes and takes your machine with it.
->
-> At this point, I've abandoned the 2.3.3 port and am starting over with
-> a different strategy for 2.5.x, involving very few MPW-Assembler-specific
-> hacks and a *real* cross-compilation setup (i.e. sit on a Sun and produce
-> a Mac executable, resources, fat binary, etc as desired).

That's neat, but all I want to do is compile MPW tools under MPW, using C++
instead of C.

Thanks for 2.3.3 -- I'm going to try building that tonight.  Does the C++
front end part of 2.3.3 work, or am I stuck with Apple's port of CFront 2.1?

--
Matt Holiday                                  #include <std/disclaimer>
[e-mail]
BNR Richardson, TX            "Proud owner of an unregistered computer"

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

>From [e-mail] (Stan Shebs)
Date: Tue, 22 Mar 1994 21:57:02 GMT
Organization: /cygint/s1/users/shebs/.organization

In article <2mn0d9$[e-mail]> [e-mail] (Matthew Holiday) writes:

   That's neat, but all I want to do is compile MPW tools under MPW, using C++
   instead of C.

   Thanks for 2.3.3 -- I'm going to try building that tonight.  Does the C++
   front end part of 2.3.3 work, or am I stuck with Apple's port of CFront 2.1?

Although I haven't tried it lately, "cc1plus" has been observed to build
and run under MPW.  However, it won't generate code that will link with any
MPW C++ libraries (different name mangling).  You would have to recompile
any and all libraries from source code, then work out a way to run static
constructors and destructors, and do many other weird and obscure bits of
work.  Might take a couple weeks of dinking around.  Note also that the
dialect of C++ is different than what you would get with CFront 2.1, or
even the latest (2.5.8) version of GCC.

                            Stan Shebs
                            Cygnus Support
                            [e-mail]


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

>From [e-mail] (Matthew Holiday)
Date: 23 Mar 1994 20:48:57 GMT
Organization: Bell-Northern Research, Richardson, TX

In article <[e-mail]>, [e-mail] (Stan Shebs) writes:
-> In article <2mn0d9$[e-mail]> [e-mail] (Matthew Holiday) writes:
->
->    That's neat, but all I want to do is compile MPW tools under MPW, using C++
->    instead of C.
->
->    Thanks for 2.3.3 -- I'm going to try building that tonight.  Does the C++
->    front end part of 2.3.3 work, or am I stuck with Apple's port of CFront 2.1?
->
-> Although I haven't tried it lately, "cc1plus" has been observed to build
-> and run under MPW.  However, it won't generate code that will link with any
-> MPW C++ libraries (different name mangling).  You would have to recompile
-> any and all libraries from source code, then work out a way to run static
-> constructors and destructors, and do many other weird and obscure bits of
-> work.  Might take a couple weeks of dinking around.  Note also that the
-> dialect of C++ is different than what you would get with CFront 2.1, or
-> even the latest (2.5.8) version of GCC.

Good points.  I really hadn't thought about name mangling conventions.  It's
probably more effort than I've got to put into it to make it work with MPW.

I haven't heard anything from Apple/APDA about planned improvements to MPW
C++ (i.e., supporting a later version of the C++ language), so I guess I'll
just keep doing tools in C.  Or switch to a Unix machine....

--
Matt Holiday                                  #include <std/disclaimer>
[e-mail]
BNR Richardson, TX            "Proud owner of an unregistered computer"

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

>From Willie Rauchwerger <[e-mail]>
Subject: Code Fragment Loader and VM
Date: 17 Mar 1994 19:53:35 GMT
Organization: OU Health Sciences Center

Here is a dumb question...

Why does your application memory requirement decrease on native PPC
apps when virtual memory is turned on?

- -----------------------------------------------------------------
Willie Rauchwerger         AppleLink: Willie
Telemedicine Software Guy  Internet:  [e-mail]
OU Health Sciences Center

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

>From [e-mail] (Anton Rang)
Date: 19 Mar 1994 02:01:14 GMT
Organization: Minnesota Angsters

In article <2macfv$[e-mail]> Willie Rauchwerger <[e-mail]> writes:
>Here is a dumb question...

  Actually, it's not a dumb question.  :-)

>Why does your application memory requirement decrease on native PPC
>apps when virtual memory is turned on?

  When virtual memory is turned on, an application's code (as well as
that of any shared libraries it uses) is mapped into high memory,
rather than being loaded into the application heap.  Because this
high-memory area doesn't correspond to real RAM, the program doesn't
need any memory to be allocated for its code.
--
Anton Rang ([e-mail])

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

>From [e-mail] (Michael Peirce)
Date: Wed, 23 Mar 94 21:09:25 PST
Organization: Peirce Software, Inc.


In article <2macfv$[e-mail]> (comp.sys.mac.programmer), Willie Rauchwerger <[e-mail]> writes:
> Here is a dumb question...
>
> Why does your application memory requirement decrease on native PPC
> apps when virtual memory is turned on?

No CODE resources get loaded into your heap.  With VM turned on, your
code (from the data fork) is paged into its own memory area as needed
(and it never gets paged back to disk since it's read only, it can
always be read back from the data fork).


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

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

>From [e-mail]
Subject: Code to rebuild desktop?
Date: Tue, 22 Mar 1994 18:46:44 GMT
Organization: University of Richmond

Does anyone have a pointer to source code (C/C++ preferred) to rebuild
the desktop?

Herb Martin
[e-mail]

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

>From [e-mail] (Leonard Rosenthol)
Date: Thu, 24 Mar 1994 18:53:07 GMT
Organization: Aladdin Systems, Inc.

In article <[e-mail]>,
[e-mail] wrote:

> Does anyone have a pointer to source code (C/C++ preferred) to rebuild
> the desktop?
>
   It is IMPOSSIBLE for an application to do the rebuild itself since most
of the contents of the Desktop File are undocumented.

   What you can do is to ask the Finder to quit (via Apple events), delete
the DTDB files yourself, and the relaunch the Finder.  At that point the
Finder will rebuild the DTDB for you.

Leonard
- ------------------------------------------------------------------------
Leonard Rosenthol                      Internet:       [e-mail]
Director of Advanced Technology        AppleLink:      MACgician
Aladdin Systems, Inc.                  GEnie:          MACgician

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

>From [e-mail] (Matthew T Diamond)
Subject: CodeWarrior features?
Date: 23 Mar 1994 19:56:35 GMT
Organization: University of Pennsylvania


I know; every coupla days someone wants to know if
CodeWarrior supports feature X.

But I AM very curious about it.  Is there any online
information available that summarizes the whole thing?
I would like to learn more about the editing environment,
as well as what tools it comes with, how good is the code,
what debugging is like, etc.  (Yes, I know it's still alpha or beta)

Presumably some kind of promotional text was written up
somewhere?  It might answer my own and other folks' questions.

Matt
[e-mail]

ps. On a related note, I noticed that Symantec 7.0 press releases
didn't mention improvements to the editor.  Did I miss something??

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

>From [e-mail] (MW Ron)
Date: 23 Mar 1994 17:15:03 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <2mq6tj$[e-mail]>, [e-mail]
(Matthew T Diamond) writes:
>Is there any online information available that summarizes the whole thing?


a bit of background on Metrowerks:

Metrowerks has been developing and selling  academic computer language
products since 1988 and has registered users in 26 countries.

On January 5th, 1994, Metrowerks introduced Metrowerks CodeWarrior, a
completely new, very powerful development environment for C/C++ and Pascal on
either 68K Macintosh or the new PowerMacintosh.

Metrowerks CodeWarrior contains very fast, state-of-the-art compiler
technology that builds your products faster than any other development
environment on Macintosh. CodeWarrior also is compatible with MPW C/C++
source code and both MacApp 3.1 and the TCL have been successfully compiled
with CodeWarrior since introduction. It is currently in use in most of the
major software companies worldwide to port their products to the new
PowerMacintosh.

Also included on the CodeWarrior CD is PowerPlant, our new application
framework, written by Greg Dow, the orginal architect of the Think Class
Library.


Metrowerks business hours are (EST):

Monday to Friday, 9 AM to 5 PM.

Address:

In the USA
Metrowerks, Inc
The Trimex Building
Route 11, Mooers NY
12958

Canada and International
Metrowerks, Inc
1500 Du College, Suite 300
St-Laurent, QC
H4L 5G6

Other electronic addresses:

[e-mail]
[e-mail]
[e-mail]

Tel:  [phone]
Fax:  [phone]




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

>From [e-mail] (John W. Baxter)
Date: Thu, 24 Mar 1994 15:10:58 -0800
Organization: Internet for the Olympic Peninsula

In article <2mq6tj$[e-mail]>, [e-mail]
(Matthew T Diamond) wrote:

>
> I know; every coupla days someone wants to know if
> CodeWarrior supports feature X.
>
> But I AM very curious about it.  Is there any online
> information available that summarizes the whole thing?
> I would like to learn more about the editing environment,
> as well as what tools it comes with, how good is the code,
> what debugging is like, etc.  (Yes, I know it's still alpha or beta)

MacTech magazine has had several articles recently about CodeWarrior.
*Should* be available at your library, but with budgets the way they are
these days, who knows.  [MacTech is also a convenient place to buy
CodeWarrior.  That does not seem (to this outsider) to have affected the
articles.]

Frameworks magazine has, I think, had one or two, also.  Harder to find.

Both "MacTech" and "develop" are essential parts of one's Macintosh
developer closet, IMHO.
--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

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

>From [e-mail] (Al Evans)
Subject: Graphic Elements release announcement
Date: 23 Mar 94 15:41:54 GMT
Organization: PowerTools, Austin, Texas


I am pleased to announce the net release of Graphic Elements.
Graphic Elements is a new paradigm for implementing high-performance
interactive computer graphics in a framework-independent (and,
potentially, platform-independent) manner. The Graphic Elements
system is modular and extensible, and individual Graphic Elements
can be re-used in new applications by simple inclusion.

This release is available from mac.archive.umich.edu and its mirrors
in the file:

    /mac/misc/demo/graphicelementsdemo.sit.hqx

I do not know why they put it in the demo area, since it is a
completely functional version including linkable library and
examples with source code (Think C 6.0). Note: I do ask a
fee for the "registered shareware version", which includes
an additional code module to speed up the graphics, a linkable
MPW library, source for a TCL pane, and source for a MacApp view.

Here are some excerpts from the Graphic Elements README file:

[begin excerpts]

Graphic Elements is a very general, high-performance, framework-
independent graphics presentation system. It offers graphic performance
comparable to that of a "sprite animation" system. At the same time, it
affords a very flexible mechanism for defining what a graphic is and does.
Anything that can be drawn on the screen can be a Graphic Element.

...the Graphic Elements system is completely "legal". Any normal
Macintosh window can contain a Graphic Elements "world".

>From the viewpoint of the application programmer, a Graphic Element is
an independent software object which knows how to image itself on
demand into an offscreen workspace. Each Graphic Element may optionally
have ways of reacting to 1) the passage of time, 2) contact with
another Graphic Element, and 3) the user's actions. These methods will
be called automatically by the Graphic Elements system, as required. In
addition, the application program can act on Graphic Elements explicitly
at any time.

After initialization, the application (or the view or pane object, if
a class library is being used) needs only two calls to the Graphic
Elements system to run a window full of animated graphics.

...the Graphic Elements system allows any graphic to be defined as a
Graphic Element.

...scenes can easily be moved from one program to another by simply
including them in the new program and calling their initialization
routines.

The same Graphic Elements "scene" source can [...] be compiled under
MPW C or C++, Think C 6.0, and Symantec C++. The compiled code can be
utilized from a normal application or from one based on the MacApp
or TCL class libraries.

[end excerpts]

If you're still with me, thank you for your attention.

                    --Al Evans--
--

Al Evans                         Tu causes, tu causes
[e-mail]               C'est tout ce que tu sais faire
cs.utexas.edu!crucible!al                     -- LaVerdure

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

>From Steve Barrera <[e-mail]>
Subject: How to get Finder icon?
Date: 23 Mar 1994 16:37:33 GMT
Organization: Computing Center


I want to make a call to the standard get file dialog, then extract
the Finder icon associated with the selected file and put it in a window.
I can't find a hint anywhere in Inside Mac:Files as to how to do this.
Anyone have a clue?

Steve Barrera
[e-mail]

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

>From E.J. Draper <[e-mail]>
Date: 23 Mar 1994 17:06:04 GMT
Organization: U.T.M.D. Anderson Cancer Center

In article <2mpr8d$[e-mail]> Steve Barrera, [e-mail]
writes:
>I can't find a hint anywhere in Inside Mac:Files as to how to do this.
>Anyone have a clue?


Here!s a little snippet.  The main call you!re looking for is
PBDTGetIcon().

PBDTGetIcon() is only available on volumes that use the System 7 desktop
manager scheme.




    clearbytes(&DTDBparamBlock,longsizeof(DTDBparamBlock));

    DTDBparamBlock.ioVRefNum = volrefnum;

    DTDBparamBlock.ioNamePtr = nil;

    if (PBDTGetPath(&DTDBparamBlock) == noErr)
    {
        if (DTDBparamBlock.ioDTRefNum == 0)
        {
            return nil;
        }

        icondata = NewPtrClear(kLarge8BitIconSize);

        if (icondata == nil)
            {
                return nil;
            }

        DTDBparamBlock.ioDTReqCount = kLarge8BitIconSize;

        DTDBparamBlock.ioDTBuffer = icondata;

        DTDBparamBlock.ioIconType = kLarge8BitIcon;

        DTDBparamBlock.ioFileCreator = Creator;

        DTDBparamBlock.ioFileType = Type;

        Err = PBDTGetIcon(&DTDBparamBlock,false);

        if (Err == afpItemNotFound)
            {
                DisposePtr(icondata);

                icondata = nil;

                thePic = dogenericdocicon();

                if (thePic != nil)
                {
                    return thePic;
                }

                return nil;
            }


      |E|J-  ED DRAPER
 rEpar|D|<-  Radiologic/Pathologic Institute
             The University of Texas M.D. Anderson Cancer Center
             [e-mail]

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

>From [e-mail] (Thomas KC Chan)
Subject: Porting Think C to CodeWarrior
Date: 22 Mar 1994 21:57:21 GMT
Organization: Imaging Labs, Robarts Research Institute, London


I am porting my programs from Think C to CodeWarrior.  Right now I
am just testing the 68K port.  The programs works...but...

   1. when I time my program speed using clock(), the program gives
      me a big ellapse time.  It turns out that the constant CLOCKS_PER_SEC
      is declared as (_CPS which is) 1.  I check with Think C and find
      that it has CLOCKS_PER_SEC declared as 60.  ???

   2. My program generates output for a line counter using ANSI printf.
      Everything I use "\r" to overwrite the previous value. It works
      in Think C.  But in CodeWarrior, the output would go to SIOUX. And
      seemingly the "\r" character is treated as a new-line char.  ???


Any one knows any fix to my problems?  Are patches needed for my
CodeWarrior (Gold) compiler?

I find the on-line ref. manual does not provide enough details
(like PowerPC's PEF [what is it anyways???]) Is there any doc
available on s/w porting to PowerPC?



Thomas Chan                   email: [e-mail]

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

>From [e-mail] (Michael Levy)
Date: Wed, 23 Mar 94 13:38:46 GMT
Organization: University of Victoria

In Article <2mnpk1$[e-mail]>, [e-mail] (Thomas KC
Chan) wrote:
>
>I am porting my programs from Think C to CodeWarrior.  Right now I
>am just testing the 68K port.  The programs works...but...
>
>   1. when I time my program speed using clock(), the program gives
>      me a big ellapse time.  It turns out that the constant CLOCKS_PER_SEC
>      is declared as (_CPS which is) 1.  I check with Think C and find
>      that it has CLOCKS_PER_SEC declared as 60.  ???

Yes, I found this too. Change #define _CPS 1 to #define _CPS 60
in <yval.h>. (See item 2 in the bug-report below).

There were a couple of other bugs that I have reported to Metrowerks.
There was no response from them, but I assume they
will fix most of them in the next release. The most serious bug
(not included in the report) was with malloc - its supposed to take
an unsigned long as its argument. Instead, it is treating its argument
as a signed int. If you try to allocated more than 32,767 bytes, malloc
will return NULL. (Actually, its a bit worse than this. It is taking the
least significant 16 bits of its argument, and treating that as a signed
int. If you pass a long that is larger than 32,767, but which happens to
have a zero in bit 16, malloc will succeed, giving you much less storage
than you think you received). I did phone tech-support about this bug,
and they said that it would be fixed in their next releasw
(apparantly being cut into CD as we spoke - about 2 or 3 weeks ago).

I do not know about your second problem, but here for your benefit,
and for the benefit of anyone else trying a THINK C->Metroworks C port,
is a copy of the message I sent them. Because of these problems
(and, most notably, with the debuggers inability to evaluate
expressions,) SYMANTEC still gets my vote as the ANSI C compiler
of choice for the Mac. I haven't done any C++ programming on the
Mac, so I am not entering the other debate.

Here is the bug report:

1. In the <yval.h> file, you have
#define _ILONG 1
Shouldn't this be conditional, depending on the value
of __FOURBYTEINTS__?

2. In the same file,
#define _CPS 1
is wrong - shouldn't it be 60 on the Mac? I think its
ticks-per-second to divide into the value returned
by the ANSI function clock().

3. SystemSevenOrLater seems to be defined as 0 instead of 1
even though I am using system 7.1. I can't figure out how to change
it, or find out where it is defined.

4. I got the version 1.a -> 1.b updater. It changed Macheaders
but not Macheaders.c What gives?

5. The predefined names in the C manual (such as __mwerks__)
are in lower-case. They should be in upper case.


I also noticed some bugs in the debugger, most notably,
in a case like this:

int t1,t2;
....
t1 = 1000;
t2 = 2000;
...
the debugger showed the same values for t1 and t2, and
changed them simultaneously!

While I am on the debugger, I would like to add an item
to your wishlist. I like the overall structure of your debugger
when compared with THINK C. However, for me it is crucial
to be able to evaluate expressions in the debugger. For example,
I have a horrible macro called TAG(X) defined like this:
#define TAG(X) \
((!(heap[X]&1))?(heap[X]&3):((!(heap[X]&2))?(heap[X]&15):(heap[X]&63)))

THINK C's debugger lets me place the expression TAG(X) in the "data"
window and see a value (like 1 or 63). I find this soooo useful.
Please consider adding something similar. In fact, if I could
coerce the result to an enum type and get the symbol instead of
a number in the debugger, I would be ecstatic.

Good luck with your product.

+============================================+
| Michael Levy                               |
| Department of Computer Science             |
| University of Victoria                     |
| PO Box 3055 Victoria B.C.                  |
| Canada V8W 3P6                             |
| email: [e-mail]                   |
| phone: [phone]                      |
| fax: [phone]                        |
+============================================+

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

>From [e-mail] (John McEnerney)
Date: Thu, 24 Mar 1994 02:18:33 GMT
Organization: The World Public Access UNIX, Brookline, MA

>int t1,t2;
>....
>t1 = 1000;
>t2 = 2000;
>...
>the debugger showed the same values for t1 and t2, and
>changed them simultaneously!

This is probably -not- a bug in the debugger. If the compiler can
determine that t1 and t2 will never be live simultaneously, it is free to
place them in the same register or memory location. In fact, it is free
to delete the assignments altogether if t1 and t2 are never used. (Unless
they are declared 'volatile')

>I have a horrible macro called TAG(X) defined like this:
>#define TAG(X) \
>((!(heap[X]&1))?(heap[X]&3):((!(heap[X]&2))?(heap[X]&15):(heap[X]&63)))
>
>THINK C's debugger lets me place the expression TAG(X) in the "data"
>window and see a value (like 1 or 63). I find this soooo useful.
>Please consider adding something similar.

This will not be possible with our current debugger/compiler
architecture. THINK C is one of the only environments I've ever seen
which does this; it is a side-effect of the way the debugger works, which
is to call the compiler to evaluate the expression.

We will probably support some form of expression evaluation in the
debugger eventually (post-DR3) but it will probably not include macro
expansion.

-- John McEnerney, Metrowerks PowerPC Product Architect


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

>From [e-mail] (Thomas KC Chan)
Date: 24 Mar 1994 16:46:07 GMT
Organization: Imaging Labs, Robarts Research Institute, London


Michael Levy, thanks you for sharing your list with us.


In article <[e-mail]> [e-mail] (John McEnerney) writes:
>>int t1,t2;
>>....
>>t1 = 1000;
>>t2 = 2000;
>>...
>>the debugger showed the same values for t1 and t2, and
>>changed them simultaneously!
>
>This is probably -not- a bug in the debugger. If the compiler can
>determine that t1 and t2 will never be live simultaneously, it is free to
>place them in the same register or memory location. In fact, it is free
>to delete the assignments altogether if t1 and t2 are never used. (Unless
>they are declared 'volatile')

As a high-level language programmer, I don't think I have to worry
about which register is assigned to which variable.

If this happens only when certain optimization option is on, then it is not
a bug; otherwise it definitely is a bug!  Can Michael verify this?


>>I have a horrible macro called TAG(X) defined like this:
>>#define TAG(X) \
>>((!(heap[X]&1))?(heap[X]&3):((!(heap[X]&2))?(heap[X]&15):(heap[X]&63)))
>>
>>THINK C's debugger lets me place the expression TAG(X) in the "data"
>>window and see a value (like 1 or 63). I find this soooo useful.
>>Please consider adding something similar.
>
>This will not be possible with our current debugger/compiler
>architecture. THINK C is one of the only environments I've ever seen
>which does this; it is a side-effect of the way the debugger works, which
>is to call the compiler to evaluate the expression.

How about unix's dbx & debuggers on VMS ... ?  This feature is definitely
needed.  As a matter of facts, CW debugger is the only one I used so far
that lack of this feature.

I also want the capability of hidding some of the variables
(local & global) that I am not interested in.  Currently I have to
scroll the window ups & downs just to see the variables I have
doubts on...  (Have I overlooked that such feature is already
implemented in CW debugger?!!)


As for my second question, I only want to overwrite the same line on
the screen by using a "<cr>" character instead of a "<nl>" in the
ANSI "printf" function.  Any special character I could use to
send to CW's SIOUX to simulate this behavior?!

(Any way to re-position a SIOUX window besides manually draging it?
Any DOC on SIOUX besides the on-line User Manuals that comes with
the CD-ROM?)


I always want to ask this: Is "[e-mail]" the
e-mail address for "support" from Metrowerks.  (It was printed on
the little booklet that comes with the CW CD-ROM.)  I have sent my
queries there for a couple/several weeks but never got any
replies ??!!



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

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: Quickdraw GX Beta 3 fun
Date: 23 Mar 94 12:00:23 +1300
Organization: University of Waikato, Hamilton, New Zealand

Just for fun, I tried duplicating the example on page 207 of the PostScript
Red Book, 2nd Ed.

For those without the book, the design is a large letter A against a rectangular
background. Both the letter and the rectangle are filled with a pattern of
stars, alternately black and grey.

The first snag I hit is that QuickDraw GX doesn't allow multicoloured fill
patterns--not unless you use a bitmap for the pattern shape, I guess. So all
my stars are one colour for now.

The second problem I hit was that the fill for the letter would not draw
properly: stars would appear well outside the character outline. This bug
is still present in beta 3, but I can get around it by changing the shape
type from text to a path. The same thing would happen for the rectangle
before, but this works properly in beta 3.

The next problem was that the fills for the rectangle and the letter would
not match up--the positions of the stars were different. This is also fixed
in beta 3.

All in all, the betas are getting better and better. I hope release isn't
too far off now...

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

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

>From [e-mail] (Tom Dowdy)
Date: Wed, 23 Mar 1994 00:46:58 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) wrote:

> Just for fun, I tried duplicating the example on page 207 of the PostScript
> Red Book, 2nd Ed.
>
> For those without the book, the design is a large letter A against a rectangular
> background. Both the letter and the rectangle are filled with a pattern of
> stars, alternately black and grey.
>
> The first snag I hit is that QuickDraw GX doesn't allow multicoloured fill
> patterns--not unless you use a bitmap for the pattern shape, I guess. So all
> my stars are one colour for now.

Ah!

You can make *two* shapes, each filled with a different pattern/color.
I haven't seen the picture in a while, but I assume that it's just
one phase is gray and another black.  Since only the pattern
areas of the filled shape are blitted, you can place them on
top of one another to get the alternating behavior you mention.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

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

>From [e-mail] (Jasna M. Arezina-Wilson)
Subject: Spoofing a serial port
Date: 22 Mar 1994 20:54:55 GMT
Organization: Ohio State University

I have a need to write an app/extension/cdev that will allow me to either
intercept a port speed call and/or modify said call (the reason is that I
have an older software package that drives the port at 19200, but my lab's
scanner interface is limited to 9600, and the software doesn't let me
change the port speed). Before I start on this nasty little project, does
anyone have any tips/clues/warnings?

- -------------------------------------------------------
#include <standard.disclaimer.h>
/* "My words are my own, and nobody paid me to say them." */
void void(void);   /* void where voided */

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

>From Frank Price <[e-mail]>
Date: 22 Mar 1994 22:40:47 GMT
Organization: Pomona College

In article <[e-mail]> Jasna M.
Arezina-Wilson, [e-mail] writes:
>I have a need to write an app/extension/cdev that will allow me to either
>intercept a port speed call and/or modify said call (the reason is that I
>have an older software package that drives the port at 19200, but my lab's
>scanner interface is limited to 9600, and the software doesn't let me
>change the port speed). Before I start on this nasty little project, does
>anyone have any tips/clues/warnings?

A MUCH better idea would be to modify the subject program's code directly.
Making a patch on PBControl would be unreliable depending on how they
decided to set the baud rate.  There are two ways to set the baud rate.
One is a PBControl with csCode of 13 (this is from memory so don't quote
me).  The other is the standard SerReset call which the Apple glue should
translate into a different PBControl call (see Serial Driver chapter of
IM).  Basically, use Macsbug (TMON would be a lot easier here) to trap on
all PBControl calls in the app.  Look at the csCode.  When you find the
place in the code that the appropriate call is occurring, use the ResEdit
CODE disassembler or similar device to edit the hex instructions directly
to modify the baud rate requested into what you really want.  This solution
will solve your problem permanently and reliably, and will not introduce a
whole slew of potential problems caused by trap patches.

-Frank
_______________________________________________________________________
| Frank Price   |  [e-mail]                        |
|_______________|______________________________________________________|

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

>From [e-mail] (Jasna M. Arezina-Wilson)
Date: 23 Mar 1994 15:44:41 GMT
Organization: Ohio State University

In article <2mns5f$[e-mail]>, Frank Price
<[e-mail]> wrote:

> [Idea on using MacsBug to hack serial speed]

This is pretty much what I did. The problem I had in not doing this in the
first place is that I had no way to get MacsBug to run (no int button on
the SE here), so I had to track down the F-Key to get into MacsBug. Plus,
adding to the fact that I have never used MacsBug before (other than
finding where my program crashed), it was real fun. I still wasn't able to
change the baud-rate directly - I had to patch the code and check the
control call, but at least it works!

(PS: I still think writing a program to spoof the baud rate would be
interesting)



- -------------------------------------------------------
#include <standard.disclaimer.h>
/* "My words are my own, and nobody paid me to say them." */
void void(void);   /* void where voided */

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

>From Dan Crevier <[e-mail]>
Subject: Using Think Pascal Library in SC++
Date: 22 Mar 94 05:18:13 GMT
Organization: Harvard University


    Hi, I'm trying to use the WASTE TextEdit engine with SC++.  WASTE
comes with WASTE.lib, a Think Pascal library.  I used oConv from Think C
5.0 (I couldn't add it to my project to use the .o converter...).  That
gave me a .pi file I could add to the project, and when I tried to link,
I got a message that WESetInfo, _LMUL, and _LDIV weren't defined.  I
assume that the are some long multiplication and division routines.  Can
I write short routines to implement these?  I have MWC, and MPW, but not
Think Pascal.
    As for WESetInfo, I used DumpObj from MPW (I'd never used it
before, I'm not a MPW person), and it showed a list of routines at the
top with EP= in front of them, and the routine name in all caps
(including WESETINFO).  What does this mean?

    Any help would be appreciated.

Thanks.

dan


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

>From [e-mail] (Ingemar Ragnemalm)
Date: Thu, 24 Mar 1994 10:49:25 GMT
Organization: (none)

Dan Crevier <[e-mail]> writes:

>    Hi, I'm trying to use the WASTE TextEdit engine with SC++.  WASTE
>comes with WASTE.lib, a Think Pascal library.  I used oConv from Think C
>5.0 (I couldn't add it to my project to use the .o converter...).  That
>gave me a .pi file I could add to the project, and when I tried to link,
>I got a message that WESetInfo, _LMUL, and _LDIV weren't defined.  I
>assume that the are some long multiplication and division routines.  Can
>I write short routines to implement these?  I have MWC, and MPW, but not
>Think Pascal.

This is exactly the problem I wrote about in my recent post (about how to
make SAT work under Think C v6).

1) You must include uRuntime.lib. Convert it to a C library and include it.
Using Think C 5, this was all you had to do. (You may have to fiddle with
the .v file a bit too.)

2) Under Think C 6 (or C++), there's a bug in the linker (?) that makes it
really confused with uRuntime.lib. You must open it with Think C 5 and REMOVE
the segment named TOOLBOX. Ugly, isn't it?



--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

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

>From [e-mail] (Alex Metcalf)
Subject: rowBytes for the screen too big?
Date: Sat, 19 Mar 1994 00:52:44 GMT
Organization: Demon Internet


   Hey there!

   After hacking around with my custom CopyBits routine (which works
nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My
screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the
rowBytes is 1024. What gives? Is this something to do with making the
transfer faster in/out of video RAM?

      Hmm...


   Alex
   [e-mail]

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

>From [e-mail] (M. Scott Smith)
Date: Sat, 19 Mar 1994 04:35:11 GMT
Organization: The Great Beyond

In article <[e-mail]> [e-mail] (Alex Metcalf) writes:
>
>   Hey there!
>
>   After hacking around with my custom CopyBits routine (which works
>nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My
>screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the
>rowBytes is 1024. What gives? Is this something to do with making the
>transfer faster in/out of video RAM?
>
>      Hmm...
>   Alex

Alex,

   If your rowBytes is sincerely 1024, then take your Mac to an Apple
service center immediately.  It must be quarantined before you begin to
cause others' Macs to have obscure video symptoms.

   But seriously..  You've discovered a truth about how video works on
Macs, and some pretty quantitative evidence why it's not safe to assume
that jumping ahead 640 bytes puts you on the next line (particularly if
you're fooling around with direct-screen addressing, as I do).

   Part of the reasoning behind this (and this is true of all video cards,
Mac and non-Mac) is that you can't buy a, say, 3.7 byte RAM chip.  RAM
chips only come in certain sizes, so it's not really possible to have
_exactly_ the right amount of RAM for the screen dimensions and depth.
Since it probably wouldn't be a good idea to have _less_, most video cards
have _more_ -- and "jump up" to the most convenient (cheap, etc.) amount.

   Keep in mind that most video cards can drive monitors of varying
resolutions, and depths.  If you switch your monitor to black and white
mode, you don't even need 640 bytes per scanline.  (More like 80.)  Jump
it up to 24-bit mode, and you need quite a bit more.  There's _always_
going to be wasted space, even if you're at the best monitor configuration
your video hardware can support.  (Step beyond that, and your video
hardware won't support it -- which is a good reason why you can often
get 24-bit color on 13" monitors with some cards, but not on 21"
monitors.)

   Now, you're talking about the screen's PixMap.  In my own PixMap's I
"align" the data to fit nice boundaries, and there's handy formulas for
doing this.  In that case it does benefit things like CopyBits.  The
strategy is that you have a width and height of "usable" space in a PixMap
(what you intend to actually be there), and rowBytes (and colBytes)
might not necessarily jive with width and height.  So you subtract
rowBytes from width to know how to get to the next line in a PixMap.  But
there's other reasons, as I listed, for the screen's PixMap to be super-
aligned.

   Now, just think!  You've found a lot of extra RAM that you can use if
you need!  Let's see, 1024-640 = 384 * 480 = 180k of free RAM!  (Pardon
any math errors, it's late.)  And imagine what's in store with video
cards that are perfectly happy driving 21" monitors in 24-bit color but
are only hooked up to 12" black and white monitors..

   Of course I'm sort of kidding.  But that extra RAM has been put to
good use in the past; as I recall, someone wrote a program called
MaxAppleSomethingOrOther that "enlarged" the dimensions of the 13" monitor
when used with the 8/8-24 video card.  (It essentially got rid of the black
borders around the 13" screen.)  It didn't work with my 8-24GC, darn it,
so I never got to try it, but I saw it and it was neat.

   In any case, it can be baffling to see inflated rowBytes but that's how
it is; just be sure to make no relations between width of screen and number
of bytes dedicated to each line by the video card..

   Hope that made sense!

Have fun,

Scott

- -
M. Scott Smith   ([e-mail] || [e-mail])

  Mac developer. Student. Ski bum.  Not responsible for the national debt.


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

>From [e-mail] (Chris DeSalvo)
Date: Mon, 21 Mar 1994 04:48:51 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Alex Metcalf ([e-mail]) wrote:

:    Hey there!

:    After hacking around with my custom CopyBits routine (which works
: nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My
: screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the
: rowBytes is 1024. What gives? Is this something to do with making the
: transfer faster in/out of video RAM?


Always do a & 0x07FF on a rowBytes field before using it.

L8R
Chris
--
+-----------------------------------------------------------------+
| [e-mail]           |   Macintosh:  Changing the world, |
| Chris De Salvo              |        one person at a time!      |
| Professional Mac Geek       |    -----------------------------  |
| MacPlay, Irvine, CA         |      (I wish they'd hurry up!)    |
+-----------------------------------------------------------------+

Any opinions expressed, or implied, are my own!  They should not be
considered representative of the opinions or policies of my employer,
MacPlay, a division of Interplay Productions, Inc.

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

>From [e-mail] (Chris DeSalvo)
Date: Tue, 22 Mar 1994 07:45:08 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Chris DeSalvo ([e-mail]) wrote:
: Alex Metcalf ([e-mail]) wrote:
: :    Hey there!
: :    After hacking around with my custom CopyBits routine (which works
: : nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My
: : screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the
: : rowBytes is 1024. What gives? Is this something to do with making the
: : transfer faster in/out of video RAM?


: Always do a & 0x07FF on a rowBytes field before using it.

Mistake already realised.  Please, no flames.  I was thinking GWorlds,
not monitors.

Yes, a monitor's rowBytes might very well be 1024 because 1K block
transfers probably go a heck of a lot faster than 640K transfers.


Chris

--
+-----------------------------------------------------------------+
| [e-mail]           |   Macintosh:  Changing the world, |
| Chris De Salvo              |        one person at a time!      |
| Professional Mac Geek       |    -----------------------------  |
| MacPlay, Irvine, CA         |      (I wish they'd hurry up!)    |
+-----------------------------------------------------------------+

Any opinions expressed, or implied, are my own!  They should not be
considered representative of the opinions or policies of my employer,
MacPlay, a division of Interplay Productions, Inc.

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

>From [e-mail] (Paul Campbell)
Date: 24 Mar 1994 06:37:09 GMT
Organization: Taniwha Systems Design

In article <[e-mail]>
[e-mail] (Chris DeSalvo) writes:
> Alex Metcalf ([e-mail]) wrote:
> :    After hacking around with my custom CopyBits routine (which works
> : nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My
> : screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the
> : rowBytes is 1024. What gives? Is this something to do with making the
> : transfer faster in/out of video RAM?

nah ... it's just easier for the hardware guys - esp. if the same
hardware has to do 1024x768 - chances are you weren't going to use
that extra memory anyway

> Always do a & 0x07FF on a rowBytes field before using it.

NO!! ... always do a & 0x7FFF before using it [and DON'T do as older
IMs
suggest do an & 0x3FFF - there are now cards out there with genuine
rowbytes equal to 0x4000 (or greater) - if you bypass quickdraw
and write directly to the screen BEWARE!)

    Paul

______________________________________________________________________
Paul Campbell                                         [e-mail]
"Xenon? It's a rare gas ...."

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

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