[Q] carbonization...
DOA
would make the carbonization of a major project
easier? If not, I will just begin carbonizing using Pro6.
CW6 on MacOS 9.1 is PERFECTLY suited to my needs.
Upgrading to MacOS 10.X is a ZERO-VALUE PROPOSITION
for me. However, my understanding is that Apple is
force-feeding us 10.X on all newly shipping Macs, so
if I want to do software development on a
new Mac after my Titanium PB fails (as it
inevitably will), I will need carbonized software. I
suspect that I should carbonize now while the sun is
shining rather than wait until after the PB failure.
Thanks in advance for any assistance!
P.S. Over the last 17 years, I'm proud to say that I've
violated every known Apple Mac software development
guideline, which may make carbonizing my application
and libraries a pain in the patootie.
Sean McBride
dode...@aol.com (DOA) wrote:
> Is anyone aware of any changes to CW since Pro6 that
> would make the carbonization of a major project
> easier?
There are lots. And an scaled down Pro 8 is coming soon for only $100us.
Anyway, if you want your app to be Mach-O, Pro 8 will make your life
much easier. Also Pro 8 makes building bundled apps much easier too.
Miro Jurisic
> CW6 on MacOS 9.1 is PERFECTLY suited to my needs.
> Upgrading to MacOS 10.X is a ZERO-VALUE PROPOSITION
> for me.
If you want your software to run properly on Mac OS X, the only way to debug it
is under Mac OS X. At that point, you might as well develop it under Mac OS X as
well.
meeroh
Warren J. Dew
However, my understanding is that Apple is
force-feeding us 10.X on all newly shipping Macs, so
if I want to do software development on a
new Mac after my Titanium PB fails (as it
inevitably will), I will need carbonized software. I
suspect that I should carbonize now while the sun is
shining rather than wait until after the PB failure.
While the new Macs won't boot to OS 9, I believe they will still have the
Classic environment available. Unless your software patches the operating
system, it's likely to run under Classic. You could try it on an OS X machine
to make sure.
Is your software PowerPC or 68k? If the latter, it's convenient to have an
older version of CodeWarrior (one that supports 68k code) available while
converting the software to native PowerPC, a necessary prerequisite to
carbonization.
Warren J. Dew
Powderhouse Software
DOA
the OS X environment. For example, direct access to low-memory globals may not
be permitted in Classic mode. The concept of "low-memory globals" may no
longer exist. If what you say is true, then I have less to worry about.
I'm doing PowerPC development - no issues there.
I'm not interested in doing any OS X development until 99% of the
CodeWarrior OS X stability complaints disappear. CW6 is rock-solid
on OS 9. Even then, it's irritating to do a huge amount of work just
to get back to the functionality I already have on OS 9. Some of the
OS 9 stuff I can do now (e.g. seizing the processor entirely for my
number-crunching, opening a full-screen window with no menu bar or
other OS-related crap using up screen "real estate") may be difficult
to duplicate in OS X.
Thanks for your assistance.
Sean McBride
dode...@aol.com (DOA) wrote:
> My impression is that carbonization is necessary to run in Classic mode within
> the OS X environment.
No. Carbonisation is needed for your app to NOT run in Classic mode.
If you're OS 9 app doesn't even run in Classic mode within the OS X
environment, then that's another story. Perhaps it is using APIs that
don't work even in Classic, like the Name Registry APIs.
> I'm not interested in doing any OS X development until 99% of the
> CodeWarrior OS X stability complaints disappear.
I'd say 8.3 is at 95%...
MW Ron
Sean McBride <cwa...@cam.org> wrote:
>In article <8e850c98.02123...@posting.google.com>,
> dode...@aol.com (DOA) wrote:
>
>> Is anyone aware of any changes to CW since Pro6 that
>> would make the carbonization of a major project
>> easier?
>
>There are lots. And an scaled down Pro 8 is coming soon for only $100us.
This will be Mach O only it will not be Carbonized it will not do OS 9
stuff and it will not do Java.
Ron
--
Free Programming Courses at CodeWarrior U
<http://www.codewarrioru.com>
Metrowerks, maker of CodeWarrior - "Software Starts Here"
Ron Liechty - MW...@metrowerks.com - http://www.metrowerks.com
MW Ron
>I'm not interested in doing any OS X development until 99% of the
>CodeWarrior OS X stability complaints disappear.
Well then this is your day because while we aren't perfect on OS X I am
confident enought to say that 99% of the CodeWarrior OS X stability
complaints are fixed with CW 8.3 and OS X 10.2 .x This really is a good
development system.
You need a bit more ram to have things run smoothly but this is nice.
(of course CW 8.3 runs just fine on OS 9 still).
>CW6 is rock-solid
>on OS 9. Even then, it's irritating to do a huge amount of work just
>to get back to the functionality I already have on OS 9. Some of the
>OS 9 stuff I can do now (e.g. seizing the processor entirely for my
>number-crunching, opening a full-screen window with no menu bar or
>other OS-related crap using up screen "real estate") may be difficult
>to duplicate in OS X.
may not be either, and there are advantages to the UNIX kernal with
treading and such.
10.2 adds more to the Carbon framework which you will probably miss if
you still want to be backwards compatible with OS 9.
Juri Munkki
>10.2 adds more to the Carbon framework which you will probably miss if
>you still want to be backwards compatible with OS 9.
Speaking of 10.2, when will we get libraries and headers from Metrowerks
that will support the new features in 10.2? I'm trying to compile something
with QDSwapPortTextFlags with very little success.
The headers are included with Jaguar, but not Codewarrior Pro 8.3, which
seems a bit odd to me, since 8.3 was released long after Jaguar.
And, to add something to this thread: I still prefer developing under
MacOS 9. I just run Metronub Remote on my laptop with Jaguar and compile
and debug from the MacOS 9 desktop. It's a bit slower than I would like,
but it works OK. (But you need two machines.)
While Codewarrior Pro 6 was very pleasing, it isn't up to date enough to
really work for for Carbon/MacOS X development. I still keep a copy around
to compile stuff for 68K (I have a PowerBook 190cs running a weather station
server application that I wrote myself).
I've had quite a few problems with 8.3, but my PowerMac G4 was still
running 9.0.4, which I have recently upgraded to 9.2.2. I hope that
resolves the problems.
I was very disappointed to find out that running 8.3 with the debug version
of CarbonLib keeps dropping me into the debugger so often that it's
practically impossible to get anything done. How am I supposed to test
my application with the debug carbonlib if the development system isn't
running smoothly? (Version 1.6 of CarbonLib.)
All these are really minor quibbles compared to the state of carbon
documentation from Apple.
I really used to enjoy software development...I have to say that the
frustrating parts have increased immensely and have reduced software
development on MacOS to something that I consider rather tedious.
--
Juri Munkki jmu...@iki.fi What you see isn't all you get.
http://www.iki.fi/jmunkki Windsurfing: Faster than the wind.
MW Ron
wrote:
>In article <mwron-2833F8....@enews.newsguy.com> MW Ron
><mw...@metrowerks.com> writes:
>>10.2 adds more to the Carbon framework which you will probably miss if
>>you still want to be backwards compatible with OS 9.
>
>Speaking of 10.2, when will we get libraries and headers from Metrowerks
>that will support the new features in 10.2? I'm trying to compile something
>with QDSwapPortTextFlags with very little success.
Never, you get these from Apple not Metrowerks. You need to download
the Apple Developers Tools from ADC and install them. If you do that
then Metrowerks will have support for them. We do not include this
tools package with CodeWarrior.
>
>The headers are included with Jaguar, but not Codewarrior Pro 8.3, which
>seems a bit odd to me, since 8.3 was released long after Jaguar.
The tools package that came with 10.2 has some bugs, be sure to get the
August version at a minimum or better still the December version.
>And, to add something to this thread: I still prefer developing under
>MacOS 9. I just run Metronub Remote on my laptop with Jaguar and compile
>and debug from the MacOS 9 desktop. It's a bit slower than I would like,
>but it works OK. (But you need two machines.)
Thanks I'll pass this on, engineers like to know their work is being
used.
>I've had quite a few problems with 8.3, but my PowerMac G4 was still
>running 9.0.4, which I have recently upgraded to 9.2.2. I hope that
>resolves the problems.
It might have been your version of Carbon you were using, it may be
something else but without knowing the problems I can't say.
>I was very disappointed to find out that running 8.3 with the debug version
>of CarbonLib keeps dropping me into the debugger so often that it's
>practically impossible to get anything done. How am I supposed to test
>my application with the debug carbonlib if the development system isn't
>running smoothly? (Version 1.6 of CarbonLib.)
I've never tried it but it, this is Apples library not Metrowerks. I
would guess if I had to guess that it has various assertions in it by
design.
Juri Munkki
>Never, you get these from Apple not Metrowerks. You need to download
>the Apple Developers Tools from ADC and install them. If you do that
>then Metrowerks will have support for them. We do not include this
>tools package with CodeWarrior.
But you include universal headers, MacHeaders and the stub carbonlib.
I assume I have to replace those. In the past, I have relied on
Codewarrior updates to bring my headers up to date as well.
I guess the next update will be with Codewarrior Pro 9 then and until
then you are supposed to try to extract stuff from Apple and inject
those into Codewarrior Pro 8.3?
>>I was very disappointed to find out that running 8.3 with the debug version
>>of CarbonLib keeps dropping me into the debugger so often that it's
>>practically impossible to get anything done. How am I supposed to test
>>my application with the debug carbonlib if the development system isn't
>>running smoothly? (Version 1.6 of CarbonLib.)
>
>I've never tried it but it, this is Apples library not Metrowerks. I
>would guess if I had to guess that it has various assertions in it by
>design.
Excuse me? If DebuggingCarbonLib causes a DebugStr, it's usually a sign
that you are doing something bad and that there's a bug in your software.
If the program that causes that is Codewarrior, I assume that the bug is
in Codewarrior and your engineers should look into it. When the assert
happens in my program and I'm running it under the Codewarrior debugger,
I can debug symbolically - what's making this impractical is that
Codewarrior also gets trapped all the time and keeps dropping me into
Macsbug.
I would prefer to be able to both debug symbolically and use
DebuggingCarbonLib. IMHO, it's bad design from Apple that
DebuggingCarbonLib has to be installed globally and has to
replace the regular version, but it's also a bad sign that
a shipping product causes system level asserts so often that
it's practically unuseable using the debugging version.
I guess I could take the remote approach with MacOS 9 as well
and run DebuggingCarbonLib on the target machine and the regular
CarbonLib on my development machine...but I think that's besides
the point.
How do other developers use DebuggingCarbonLib? Do you find it
useful? Do you find that Codewarrior works well with it?
Miro Jurisic
> IMHO, it's bad design from Apple that
> DebuggingCarbonLib has to be installed globally and has to
> replace the regular version
Uhhhh.... but it doesn't. Read <http://developer.apple.com/qa/qa2001/qa1033.html>
hth
meeroh
Juri Munkki
>> IMHO, it's bad design from Apple that
>> DebuggingCarbonLib has to be installed globally and has to
>> replace the regular version
>
>Uhhhh.... but it doesn't. Read <http://developer.apple.com/qa/qa2001/qa1033.html>
Ok, so they realized that it was bad and kind of fixed it by writing that
note in May 2001. Yet they neglected to incorporate this note into the
Carbonlib technical note instructions that come with Carbon SDK 1.6.
The instructions still say that the debugging version can not co-exist
with the other version.
As for QDSwapPortTextFlags, I copied CarbonLibStub from MacOS 10.2, then
found the relevant part from the headers installed with 10.2 and edited
them so that they would work with everything else I had.
Other than getting bitten by the weak linking feature once again, things
went "relatively smoothly" once I found all the right parts. (I think I
used a content-based search in Sherlock to find the right header.)
That weak link feature is that I always forget that you have to
go and set the linking options for each target separately and having
quite a few targets, I tend to forget one or two...A "set for all
targets" button in the window would be good addition. You have to
weak link or the binary will no longer work with MacOS 9, since
the calls from CarbonFrameWorkLib are also in CarbonLibStub.