comp.sys.mac.programmer.codewarrior FAQ

Written and maintained by Michael Hudson
HTML formatting by Matt Keith

Last updated 11/01/97 (a UK date)

NB This is only a draft version!

First a disclaimer:

All code in this FAQ has been compiled and minimally tested unless stated otherwise. However it has NOT been fully tested, and I accept no responsibility for errors in the code.

Further/Parallel reading:

Macintosh Programming Guide
comp.lang.c++.moderated FAQ URL?
comp.std.c++ faq URL?
comp.lang.java faq Is there one? URL?
pascal faq?

"I get an error message during linking that 'some_function' referenced from 'some_other_function' is undefined, but I've included every header I can think of. What can I do?"

Firstly, this is absolutely NOT to do with HEADER files. If you don't include the necessary headers, it will not COMPILE. If it fails during LINKING then either a source file or a library is missing, most likely a library.

Assuming it is a library, there is a feature provided by MW to help you find the right one. Quoting from the 'Find Library Notes':

"By creating a "Search File Set" using all the files in the 'find library Ä' folder, you can easily search for and find the library which includes a function or global name that is unknown. This is very useful for resolving linker errors."

"I've found I need to include the ANSI C library in my project, but when I look for the library I find loads of different ones. Which do I want?"

Most libraries supplied by MW come in many flavours. Taking the example the ANSI C library, there are at least 70 sorts of ANSI C lib, and almost as many C++ ones, too.

There is, however, hope to be had. The most convoluted name I could find was:

ANSIFa(N/4i/F/8d)C.A4.68K.Lib
Lets take this step by step and see what it means.

ANSI	this means (wow!) that it is an ANSI library.
Fa	this is for use with the 'Far Method Tables' switch in the 68K Codegen panel. If this switch is on, you want a lib with Fa in its name. If it aint, you don't.
N	his is for use with the 'MPW Newlines' switch in the C/C++ Language panel. If this switch is on, you want a lib with N in its name (The 'N' in ANSI doesn't count!). If it aint, you don't.
4i	this is for use with the '4-byte ints' switch in the 68K Codegen panel. If this switch is on, you want a lib with 4i in its name. If it aint, you want one with 2i instead.
F	this is for use with the '68020 Codegen' switch in the 68K Codegen panel. If this switch is on, you want a lib with F in its name. If it aint, you don't.
8d	this is for use with the '8-byte doubles' switch in the 68K Codegen panel. If this switch is on, you want a lib with F in its name. If it aint, you don't.
C	this means its the standard C library, rather than the C++ library.
A4	this is for use in a code resource, rather than an app.
68K	this is for use in a 68K app, rather than PPC.
Lib	Guess!

I most commonly use the ANSI(2i)C.68K.Lib, and in fact have trashed nearly all the others to save disk space.

Many of these options only apply to 68K. There is also CFM68K to worry about, but I'll assume you know what you're doing with that.

Make sure you match library to preference options, or risk crashes. It's only 'risk crashes' because some libraries might not use doubles (for instance) and so whether they were compiled with the '8-byte doubles' switch on or not is irrelevant.

"When I step through my code in the debugger, some variables seem to change at random. What's going on?"

This is often erroneously described as a bug. It isn't. It's register coloring.

For an example, try this in a new CW project:

01>    #include "stdio.h"
02>    
03>    void main(void)
04>    {
05>        int i,j,k;
06>        
07>        i = 8;
08>        j = i + 10;
09>        k = i - 5;
10>        
11>        printf("k is %d",k);
12>    }

Hit debug and step through the code, seeing what changes. (On PPC, make sure that optimization level 1 is ON).

As you step through, at line 5 all the values are junk. Notice that j & k are the same. When you get to line 8, both j AND k become 18. Then at line 9, both j & k become 3. This is a bit scary for the newcomer, but if you think about it, its safe because j is never referenced again.

If line 11 became:

11> printf("j is %d, k is %d",j,k);
then the program would behave more as expected, as j and k could not share the same address.

If you don't want this to happen, line 5 could be rewritten:

05> volatile int i,j,k;
But most of the time you do want it to happen, because register coloring increases code speed and decreases code size. It doesn't half confuse the newcomer, though.

On PPC, optimization level 1 is register coloring. You might want to turn it off for debugging, but it will do scary things to the size and speed of your executable. For 68K it is always on.

"When I try to link my project I get these error messages:

Link Error : Error while creating new file.
The read/write permission of only one access path to a file can allow writing

Link Error : Error while saving resources.
Saving spool file / Entry not in queue

This currently holds the unnofficial record for being the least helpful error message known to mankind.

What the problem usually is is that the name of the application you're trying to build (set in the '68K Project' or 'PPC Project' preferences panel) is the same as the name of the project.

A class one way of getting this problem is to fail to add a mu (option-m) to the project name when creating the project.

To get rid of the message either:

(1) Change the name of the app you're trying to build
(2) Change the name of your project.

(1) is quicker, as doing (2) necessitates closing your project file. Changing the name of a file while an app has it open is not really fair.

And no, it's not English.

NB The slightly less unhelpful messages

Link Error : Error while creating/copying resource fork.
Resource map read error

Link Error : Error while saving resources.
Saving spool file / Entry not in queue

can be provoked by having a resource or source file in your project (and in the same folder as your project) with the same name as the app you're trying to build.

"How do I concatenate two pascal strings in C/C++?"

There are two ways of doing this.

Route one: use someone else's sweat. For example you can use the functions declared in PLStringFuncs.h (specifically PLstrcat). If you do C++ I recommend LString from PowerPlant, even if you don't normally use PP.

If you do use PLstrcat, make sure you add PLStringFuncs.glue.lib to your project. This can be found at 'MacOS Support:Libraries:MacOS 68K:MacOS Files:PLStringFuncs.glue.lib'.

Route two: Roll your own, something like:

NB: This has received no testing at all. It compiles.


StringPtr
concat(StringPtr inLeft, ConstStringPtr inRight)
{
   short charsToCopy = inRight[0];
   if (charsToCopy + inLeft[0] > 255) {
      charsToCopy = 255 - inLeft[0];
   }

   BlockMoveData(&inRight[1],&inLeft[inLeft[0]],charsToCopy);

   inLeft[0] += charsToCopy;

   return inLeft;
}

This assumes that inLeft points to a Str255.

"I'm new to the newsgroup. How do I know what's being discussed at the moment? What should I do if I need a question answering?"

To the first point, the only answer is to read the newsgroup. The sheer volume of traffic can be a bit daunting, but there's no other way.

Common discussion topics are what's coming in the next release of CodeWarrior, what people would like to see in the next release of CodeWarrior, when CodeWarrior will catch up with the C++ standard and various things about Java which I don't understand.

Occasionally stuff gets massively cross-posted saying things like "PCs rul, Macz suck," but decent people ignore them. This hasn't happened for a while.

To answer the second point, post it! Generally people are helpful and polite, but to make this more likely, think about the following:

• Is this the right newsgroup?
  If it is a language question, ask it on a language newsgroup (unless it's about MW's implementation). If it's a general Macintosh programming question ask it on comp.sys.mac.programmer.help. If it's a PowerPlant related question ask it on comp.sys.mac.oop.powerplant.
  This is very poorly adhered to.

• Is it really obvious?
  Just take a metaphorical step back, and look at your question. It's really embarassing to post "why doesn't this work?" and get 20 replies pointing out that you've missed a semi-colon.
  Could it be solved by just reading the manuals?

• Giving the right amount of detail.
  This is tricky. If you just post "why doesn't this work?" and one line of code, it's immpossible to know what you're barking on about. If you post "why doesn't this work?" and 50K of source, no-one will be bothered enough to wade through it and do your work for you.
  Try to give enough detail, but nothing unecessary. It is very good if you can post a complete, but very small, program that shows your problem. This is not always possible.
  Do NOT post binaries.
  More than just code, it's important to explain your problem in English too (not to be biased, but this is an English - or American - newsgroup). "Why doesn't this work?" isn't enough. Make sure you say what you are trying to acheive, and the way in which it doesn't work.
  

Having said all that, don't be shy. This is a civilised and helpful newsgroup.

"When I try to debug a project, I hit MacsBug almost instantly. I have a 68K Mac. Help!?"

This is a known bug. Download the update from metrowerks' web pages { find url } Alternatively you can still use the debugger from CW9. Globals seem to be screwed, but it mostly works.

"How do I access the QuickDraw globals from my XCMD/MDEF/CDEF/code resource?"

The best bet is to see if the calling process can give it to you. Netscape will do this, for example. If you are using the Code Fragment Manager, that can get it for you:
Code example needed
If you are coding for straight 68K, I'm afraid to say you have to rely on register-and-pointer-arithmetic thuggery:
Code example needed

"Metrowerks C++ gives me this warning:

Warning : 'derived::aFunc(int)' hides inherited virtual function 'base::aFunc()' hmm.h line 7 };

This is really a C++ issue, but it's a confusing one, so here goes:

Take this example (which was used to generate the above warning):

01>    struct base {
02>        virtual void aFunc() {}
03>    };
04>
05>    struct derived : public base {
06>        virtual void aFunc(int) {}
07>    };
08>    
09>
10>    void main(void)
11>    {
12>        base    base_object;
13>        derived    derived_object;
14>        
15>        base_object.aFunc(); // OK so far I hope... 
16>                             // This calls derived::aFunc()
17>        derived_object.aFunc(1); // Still following? 
18>                                 // This calls derived::aFunc(int)
19>        derived_object.aFunc();  // Error! 
20>                // "function call does not match prototype"
21>    }

This strikes most new C++ programmers as completely loopy (it certainly did me). The reason becomes apparent when you have a really big class heirachy and then you might end up calling the wrong function by mistake and not have any clue from the compiler.

To preserve aFunc(void) in derived, insert a line in its declaration like:

virtual void aFunc() { base::aFunc(); }
The ISO Committee has added a more convenient syntax for doing this, but Metrowerks haven't implemented it yet...

If you need this explained properly read Scott Meyers' Effective C++, a very good book.

It's dead handy that CodeWarrior produces this warning because nine times out of ten you actually wanted to override the function you're in fact hiding and you've made a typo.

"Is there any way to define macro symbols globally? I miss the -d switch from MPW."

Yes, using a prefix file.

In the C/C++ Language preference panel there is a text field for a prefix file. This file will be implicitly #included in every file in your project. If you haven't changed this field it will most likely read MacHeaders.h. This file just #includes the most appropriate precompiled version of the Universal Headers. What you want to do is create a file in the project folder (or wherever you keep project specific headers) and in this file type:

#include 

#define a_very_interesting_symbol 1
...
#define whatever you need. this is also a good place for miscellaneous
constants
...

Now go to the C/C++ Language preferences panel and type this file's name into the prefix field.

You'll need to completely recompile your entire project whenever you change this file.

"I'm porting an application from 68K to PPC and have found that CountAppFiles, GetAppFiles,ClrAppFiles, and GetAppParms have vanished! Where've they gone?"

They've GONE. Apple threatened this when System 7 came out. You'll have to use AppleEvents instead, which are a rather different - and better! - way of thinking about things. This makes it hard to write code that mimics these calls exactly, though I guess it would be possible. Now we're in the nineties, AppleEvents are the way to go.

You can use a framework such as DropShell URL? to ease the burden of transition.

"I'm porting an application from 68K to PPC and get error messages like:

Error : Can't convert unsigned char (*)(struct WindowRecord *, struct EventRecord *, short *) to struct RoutineDescriptor * file.c line 87 ModalDialog(MyModalFilter, &itemHit);"

Welcome to the world of the universal procedure pointer and the mixed mode manager!

Some unecessary background:

The PowerMacintoshes are very different from all that has gone before (you knew this, right?), as they have a different sort of chip in. However due to some extremely clever programming at Apple, software compiled for old (68K) Macs still works.

Now consider calling a function such as ModalDialog. If Apple have gotten around to implementing this trap in native PowerPC code, but you call it from 68K code you will have passed it a function pointer that POINTS TO 68K CODE, but is being handled by native code. The converse is worth considering, ie if ModalDialog is still emulated, but native code calls it with a PowerPC function pointer. The problem is that the toolbox needs to be able to tell what sort of function the pointer points at. To this end, Apple devised the universal procedure pointer, or UPP.

A UPP actually points to a struct of type RoutineDescriptor. The first two bytes of a RoutineDescriptor contain the constant _MixedModeMagic. So the toolbox takes the function pointer, dereferences it and checks what it finds against _MixedModeMagic. The toolbox knows that if they match the function is PowerPC code and if they don't its good old 68K (_MixedModeMagic is not a valid 68K instruction so an old program will not unfortunately pass a function that looks like PowerPC code - although read on).

But what, I hear you ask, about that other scenario you mentioned, where native code calls an emulated ModalDialog with a PowerPC function pointer? Well, if a RoutineDescriptor gets executed the first instruction is _MixedModeMagic. It just so happens that _MixedModeMagic is an A-trap, so the mixed mode manager gets control from the trap dispatcher and handles the function call properly.

It's not all sweetness and light because switching from executing PPC to emulating 68K takes quite a while in processor terms (like a thousandth { is that right? } of a second or so) so if native code calls an emulated toolbox trap which calls a native callback function there will be four mode switches, a significant overhead. Of course the opposite is true, ie if 68K code calls a PowerPC native toolbox trap which calls a 68K native callback there will be the same overhead.

I have no idea if ModalDialog is implemented natively yet.

Enough of that. What you need to do is take your function pointer and make a UPP of it. There is a call NewRoutineDescriptor that does just this, but the mixed mode manager needs some more information if it is to do its job, so Apple provide macros to call it properly. In the case of ModalDialog it's NewModalFilterProc. You might be tempted to use it thus:

01> ModalDialog(NewModalFilterProc(MyModalFilter), &itemHit);
but you dont want to do that, because NewRoutineDescriptor allocates space in the heap for the RoutineDescriptor, and calling it every time you call ModalDialog is a memory leak.

There are two strategies. If the UPP is likely to be called often, just create it once:

    
01>        static ModalFilterUPP myModalFilterUPP = NewModalFilterProc(MyModalFilter);
02...n>    ...
0n+1>      ModalDialog(myModalFilterUPP, &itemHit);

If the UPP is not going to be used often then it is probably best to create and destroy it as you need it.

        
01>    ModalFilterUPP theModalFilterUPP = NewModalFilterProc(MyModalFilter);
02>    
03>    ModalDialog(theModalFilterUPP, &itemHit);
04>
05>    DisposeRoutineDescriptor(theModalFilterUPP);

A good thing: When compiling for 68K NewModalFilterProc (and relatives) and DisposeRoutineDescriptor are macros that disappear leaving you with code that is mighty similar to what you've always done, and no larger. They're called the Universal Headers for good reason.

"Can anyone send me their old copy of CW9 now that they've got CW10?"

No. This violates the licence agreement between Metrowerks and their customers.

"What's the difference between CW Academic Pro & CW Gold?"

The licence agreement. That's it. Oh yes, the design printed on the CD, too.

CW Academic includes the frontends for C, C++, Pascal, Object Pascal and Java, and backends and debuggers for Win32/x86, Magic Cap, Be and MIPS, just like CW Gold. You still get 2 'free' updates. The only difference is you are not licensed to develop commercial software with the Academic version. Share and freeware are OK. Academic Pro is a fantastic deal for the beginner, but if you don't qualify Discover Programming For Macintosh is pretty cool, and Metrowerks will deduct its price from that of CW Gold should you decide to upgrade.

"What's this I hear about a major bug in the 68K CFM Enabler?"

Basically, code compiled for CFM68K that executes at interrupt time won't work.

This is because some of the glue involved trashes A5, thus making sure the interrupt code has no way of resetting it, which causes major strife for your computer and crashes. If your CFM68K code doesn't execute at interrupt time, don't worry. If it does, you have problems. I'd contact Apple Developer Technical Support for help. { Is there some technote which explains this properly? }

"I have a ............ with ... megs of RAM and ... megs of hard disk space. Will CodeWarrior run on my system?"

Well, I have a LC475 8/160 which I use for my hobbyist programming. I would not like anything less in any department, especially memory.

On the PowerMac, more memory is required {?} being a realistic minimum.

I this were my job, I'd want a PowerPC with as much RAM as I could gouge out of my employers (at least 20MB) and a gigabyte or so of hard disk. A 14 inch screen can get cramped very easily. The bigger the better.