Metrowerks CodeWarrior Best Version and Updates

[David Cook]

There are a number of threads on this forum regarding present-day development with Metrowerks CodeWarrior. I have a couple of projects in mind, but first need to select a development environment.

Historically, I began with Lightspeed C on a Mac SE and continued through Symantec C 7.0.5 / 8.0.3 on a Mac IIci. Compiler bugs and slowness caused me to switch over CodeWarrior 7 on a Power Macintosh 6100 in late 1995. My Mac career concluded with CodeWarrior Pro 2 on a Power Macintosh 8500 in late 1997.

As I have the CodeWarrior Pro 2 environment set up from years ago, that would be the easiest answer. My criteria for other CW candidates are:
1. A development environment that other people could replicate for collaboration. So, the original installer and update files should be publicly available.
2. Fewest known bugs/crashes, because we aren't going to get support or updates.
3. C/C++ compiler. The Pascal, Java, and Windows compilers aren't relevant to my needs.
4. Ability to make 68K, PPC, and fat binaries
5. Produces output compatible with System 6.0.7 through 8.1 (last 68040 support). Environment must run on 7.5.5 (last 68000 support) and 8.1 (HFS+ nice for SSDs).
6. Environment runs on Basilisk, Quadra 630/650, Power Macintosh 7300.

Candidates:
CodeWarrior Pro 5: Disqualified because it doesn't run on 68K Macs. Wikipedia says it is compatible by reference to this 2001 article.

But, trying to run the CW 5 IDE (which is poorly named 4.0) let's you know the installer was not joking. Mingling the old IDE with the new compiler might work, but I feel like there needs to be a compelling reason to ask people to hybridize.



CodeWarrior Pro 4: CD ISO is available. The updates are available as part of the massive FTP dump.

Metrowerks Updates FTP Archive - Macintosh Repository

Metrowerks Updates FTP Archive (Mac abandonware from 2004)

www.macintoshrepository.org

After downloading the 5 GB file, you'll need to use a tool like 7-Zip to extract the archive, as Windows thinks the zip is corrupt due to overflowing the 32-bit limit. For those interested, I pulled the update files for the C/C++ compiler and uploaded those to the repository.

Metrowerks CodeWarrior Pro 4 Update 4.1 for Mac C/C++ - Macintosh Repository

Macintosh IDE, C/C++ compiler, PPC linker, and Find File updates extracted from the massive "Metrowerks Updates FTP Archive" found...

www.macintoshrepository.org

After updating, you need to recompile the MSL libraries. Unfortunately, this is where I discovered that the PowerPC portion apparently doesn't compile on 68K hardware or an emulator. I tried Basilisk, Quadra 630, and a Quadra 650 on System 7.5.5 and System 8.1 (even with minimal extensions and with virtual memory on/off) without luck. However, booting from that same drive on a Power Macintosh 7300 compiled everything just fine.

That caused me to test compiling my old programs under the same conditions. Shockingly, the PPC compiler crashes or produces an 'internal error' on 68K machines, but works on the Power Macintosh. I tried CodeWarrior Pro 2 with my own programs, and it also won't successfully compile on a 68K machine (but will on the Power Macintosh). In contrast, compiling the same code but for 68K binaries works in all environments.

At some point, did the Metrowerks team just assume all developers switched over to PowerPC machines for PPC and Fat compiles? How far back do I need to go to find a version of CodeWarrior that outputs PPC binaries on a 68K platform?

CodeWarrior Pro 3: CD ISO is available. The updates are available as part of the massive FTP dump. Haven't tested.

CodeWarrior Pro 2: CD ISO is available. The updates are available as part of the massive FTP dump. Crashes when compiling my PPC code on 68K machines.

CodeWarrior Pro 1: CD ISO and updates available. Another thread suggested people standardized on this release. Does anyone know why?

At this point, I am open to suggestions. Does anyone have any reasoning behind using a particular version (like fewer bugs or improved IDE or nice C extensions)?

 

[Corgi]

Does anyone have any reasoning behind using a particular version (like fewer bugs or improved IDE or nice C extensions)?

It's probably not helpful for your case, obviously, but I standardised on CW Pro 6 and have it installed on my 1400c (with G3 upgrade), beige G3, and various G4s. I can still build for 68K, but I have no interest in hosting on 68K.

This is also the version of CW I used in 2011 to port some of the software I was working on to Mac OS 9. I actually had a full set of modern Web libraries with TLS 1.2, XML serdes, and such all working. Now I kinda desperately want to see if I can get that going again, but targeting FAT binaries and down to 7.5 or 7.1 (with OT).

edit: I picked CW Pro 6 also because it has full C++98 and C99 support, even though at that point it was still a draft standard. A lot of libraries can still be convinced to build with C99. I recall trying CW Pro 3 in 2011 and finding its standards compliance rather lacking in that department, but I don't recall the exact issues I had.

 

[Crutch]

Am I crazy in thinking CW could never compile PPC code on a 68K Mac? I recall using CW non-Pro 1.0 and am pretty sure there were separate apps for the 68K and PPC compilers, and that the PPC compiler app was PPC-native and not fat.

 

[David Cook]

I picked CW Pro 6 also because it has full C++98 and C99 support

C99 is exactly the sort of improvement I was hoping for. Specifically, intermingled declarations and code. Unfortunately, as you point out, Pro 6 won't host on 68K.

Am I crazy in thinking CW could never compile PPC code on a 68K Mac?

That got me interested in testing it. I downloaded Code Warrior 11 and applied the updates except for the MSL. It successfully compiles PPC code on a 68k Mac! Also, CW 11 runs on 68020 through PowerPC, System 7.1 through at least 8.1 (tested). So, this is a valid candidate.

Since Pro 2 and Pro 4 partially compile and then crash, I think it is fair to say that the PPC compiler was originally designed to work on 68k but they likely introduced a bug at some point that went untested.

 

[David Cook]

Something very interesting about the transition from CodeWarrior 11 to Pro. They flipped the switch to disable the old Inside Macintosh names and definitions. In fact, the flip occurs in CodeWarrior 11 MSL update patch 2.1.1. So, don't install that if you have an old code base or regularly refer to Inside Macintosh I-VI, rather than the later named volumes ("Inside Macintosh: Devices").



Earlier system calls, constants, and variables had names that were at times too generic, conflicting, or misspelled (DisposPtr). The system and applications were continuing to became more complex with larger code bases, libraries, and constants. There was a desire to start having dynamically bound libraries that could be updated instead of systems and ROMs. And, PowerPC hardware and modernized OS made some calls do nothing (SetSoundVol and SetChooserAlert). So, Apple wanted to clean up.

For example. InsMenuItem becomes a more readable InsertMenuItem. Generic sounding SetItem becomes SetMenuItemText.



Some names were so generic and common that they would conflict with variables and enums you might want to define in your own code. I mean, if you use QuickDraw then you couldn't define your own 'fill'. So, they gave the QuickDraw 'fill' an unwieldy new name that was unlikely to conflict with anything you wanted for variable names.



During the transitional periods, the headers supported both the old and new names. At a certain point, they turned off the old names. Although understandable, this broke old code without providing a helpful error message. A developer referring to Inside Macintosh I-VI would be left scratching their head. "But, DisposCIcon is in Quickdraw!". Little did they know it is now DisposeCIcon in Icons.h.

Anyway, I just wanted to alert people to this transitional period in case it bites you on an old code base.

- David

 

[Corgi]

C99 is exactly the sort of improvement I was hoping for. Specifically, intermingled declarations and code. Unfortunately, as you point out, Pro 6 won't host on 68K.

Funny, that's the one C99 feature I don't use. Years and years of targeting Visual C++ taught me to never rely on that working. I can't find any reference back to CW 10 Gold about when the feature was added to CW.

That got me interested in testing it. I downloaded Code Warrior 11 and applied the updates except for the MSL. It successfully compiles PPC code on a 68k Mac! Also, CW 11 runs on 68020 through PowerPC, System 7.1 through at least 8.1 (tested). So, this is a valid candidate.

Since Pro 2 and Pro 4 partially compile and then crash, I think it is fair to say that the PPC compiler was originally designed to work on 68k but they likely introduced a bug at some point that went untested.

Now you have me wondering: could this have anything to do with the version of the CFM 68K Enabler you're running? I believe CW Pro releases required that on 68k machines, and it was notoriously buggy…

That said, I found a reference online that states:

Another implementation difference is the size of int. In MPW and CodeWarrior PPC int is 4 bytes. In CodeWarrior 68K it is 2 bytes unless you tell CodeWarrior 68K to use 4 byte ints in the "Processor" section of the preferences. Make sure you tell CodeWarrior that ints are 4 bytes if you depend on this. Ideally you should only use ints when you don't care how big int is and long and short when you do.

Maybe Metrowerks themselves forgot this and didn't bother to ever test the PPC compiler on 68k, and that's why it is broken.

 

[cheesestraws]

This is a really interesting thread, please keep talking .

(I don't tend to build stuff for PPC that isn't PPC-only, so I have nothing to add here, really)

So, Apple wanted to clean up.

Yeah, this makes using older sample code also kind of painful, but the increase in readability afterwards is a lovely thing to see...

 

[pfuentes69]

Also quite interested... I'm right now in a project using Symantec C++ 7 and I'm not too satisfied. I get funky errors when using the FPU and some other issues.

What would be the recommended version of CW to run on a 68K and System 7?

 

[Crutch]

Gosh I would love it if there were a C99 compiler that runs on 68K. (There’s not, right?)

 

[Crutch]

@David Cook did you come up with a good solution?

 

[bigmessowires]

Something very interesting about the transition from CodeWarrior 11 to Pro. They flipped the switch to disable the old Inside Macintosh names and definitions. In fact, the flip occurs in CodeWarrior 11 MSL update patch 2.1.1. So, don't install that if you have an old code base or regularly refer to Inside Macintosh I-VI, rather than the later named volumes ("Inside Macintosh: Devices").

I recently ran into this probelm while updating some very old code. In a routine for handling scroll bar clicks, some control manager constants like inThumb and inPageUp were no longer defined. I poked around in the headers and eventually found the new name for inThumb was kControlIndicatorPart, but I never found any renamed definitions for inUpButton, inDownButton, inPageUp, or inPageDown. I'm not sure what happened to those constants, or where they're defined now, but I ended up having to define my own local constants using the numerical values from Inside Macintosh.

 

[joevt]

I recently ran into this probelm while updating some very old code. In a routine for handling scroll bar clicks, some control manager constants like inThumb and inPageUp were no longer defined. I poked around in the headers and eventually found the new name for inThumb was kControlIndicatorPart, but I never found any renamed definitions for inUpButton, inDownButton, inPageUp, or inPageDown. I'm not sure what happened to those constants, or where they're defined now, but I ended up having to define my own local constants using the numerical values from Inside Macintosh.

Universal Interfaces 3.4.2 in Metrowerks CodeWarrior Pro 6, Pro 7, Pro 8, CodeWarrior 10 has control definitions in .p, .h, and .a files.

In ControlDefinitions.h, they look like this:

/*——————————————————————————————————————————————————————————————————————————————————————*/
/*  • Control Part Codes                                                                */
/*——————————————————————————————————————————————————————————————————————————————————————*/
enum {
  kControlLabelPart             = 1,
  kControlMenuPart              = 2,
  kControlTrianglePart          = 4,
  kControlEditTextPart          = 5,    /* Appearance 1.0 and later*/
  kControlPicturePart           = 6,    /* Appearance 1.0 and later*/
  kControlIconPart              = 7,    /* Appearance 1.0 and later*/
  kControlClockPart             = 8,    /* Appearance 1.0 and later*/
  kControlListBoxPart           = 24,   /* Appearance 1.0 and later*/
  kControlListBoxDoubleClickPart = 25,  /* Appearance 1.0 and later*/
  kControlImageWellPart         = 26,   /* Appearance 1.0 and later*/
  kControlRadioGroupPart        = 27,   /* Appearance 1.0.2 and later*/
  kControlButtonPart            = 10,
  kControlCheckBoxPart          = 11,
  kControlRadioButtonPart       = 11,
  kControlUpButtonPart          = 20,
  kControlDownButtonPart        = 21,
  kControlPageUpPart            = 22,
  kControlPageDownPart          = 23,
  kControlClockHourDayPart      = 9,    /* Appearance 1.1 and later*/
  kControlClockMinuteMonthPart  = 10,   /* Appearance 1.1 and later*/
  kControlClockSecondYearPart   = 11,   /* Appearance 1.1 and later*/
  kControlClockAMPMPart         = 12,   /* Appearance 1.1 and later*/
  kControlDataBrowserPart       = 24,   /* CarbonLib 1.0 and later*/
  kControlDataBrowserDraggedPart = 25   /* CarbonLib 1.0 and later*/
};


#if OLDROUTINENAMES
/*——————————————————————————————————————————————————————————————————————————————————————*/
/*  • OLDROUTINENAMES                                                                   */
/*——————————————————————————————————————————————————————————————————————————————————————*/
enum {
  kControlCheckboxUncheckedValue = kControlCheckBoxUncheckedValue,
  kControlCheckboxCheckedValue  = kControlCheckBoxCheckedValue,
  kControlCheckboxMixedValue    = kControlCheckBoxMixedValue
};

enum {
  inLabel                       = kControlLabelPart,
  inMenu                        = kControlMenuPart,
  inTriangle                    = kControlTrianglePart,
  inButton                      = kControlButtonPart,
  inCheckBox                    = kControlCheckBoxPart,
  inUpButton                    = kControlUpButtonPart,
  inDownButton                  = kControlDownButtonPart,
  inPageUp                      = kControlPageUpPart,
  inPageDown                    = kControlPageDownPart
};

enum {
  kInLabelControlPart           = kControlLabelPart,
  kInMenuControlPart            = kControlMenuPart,
  kInTriangleControlPart        = kControlTrianglePart,
  kInButtonControlPart          = kControlButtonPart,
  kInCheckBoxControlPart        = kControlCheckBoxPart,
  kInUpButtonControlPart        = kControlUpButtonPart,
  kInDownButtonControlPart      = kControlDownButtonPart,
  kInPageUpControlPart          = kControlPageUpPart,
  kInPageDownControlPart        = kControlPageDownPart
};


#endif  /* OLDROUTINENAMES */

My Pro 4 has Universal Interfaces 3.2. I didn't keep Pro 5 since it didn't have anything that wasn't in Pro 6. Pro 7 and Pro 8 dropped Pro from the folder name. I didn't install 9 or I deleted it.

https://en.wikipedia.org/wiki/CodeWarrior has info about the versions.

 

[bigmessowires]

Thanks, is that a precompiled header? That's obviously the file I needed to look at, but I didn't find it anywhere among the headers #included from my project, nor among the files that those headers include. This was with Codewarrior Pro 4. I was thrown off because Controls.h had the kControlIndicatorPart definition, but none of the other related definitions for scrollbar parts. Now I know, thanks!

 

[joevt]

Thanks, is that a precompiled header? That's obviously the file I needed to look at, but I didn't find it anywhere among the headers #included from my project, nor among the files that those headers include. This was with Codewarrior Pro 4. I was thrown off because Controls.h had the kControlIndicatorPart definition, but none of the other related definitions for scrollbar parts. Now I know, thanks!

For Pro 4, the enums are at

MacOS Support/Headers/Assembler Headers/Controls.a (Mac OS 8.1; Universal Interfaces 3.1)
MacOS Support/Headers/Universal Headers/Controls.h (Mac OS 8.1; Universal Interfaces 3.2)
MacOS Support/Interfaces/Universal Interfaces/Controls.p (MacOS 7.x; AppearanceSDK, CWP2 Special)
MacOS Support/Interfaces/MW Universal Interfaces/Controls.p (MacOS 7.x; AppearanceSDK, CWP2 Special)

Maybe you need to update headers? What version does it say at the top of your Controls.h file?

After updating the headers, I think you need to rebuild precompiled headers? MacHeaders.mcp for C headers and MacOS_PPU.mcp for Pascal interfaces?