• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: coremidi & codewarrior
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coremidi & codewarrior


  • Subject: Re: coremidi & codewarrior
  • From: Kurt Bigler <email@hidden>
  • Date: Mon, 25 Feb 2002 20:07:01 -0800

I have also now sucesfully ported my MIDI application to OS X as a Mach-O
target under CodeWarrior 7.2.


The catches along the way were:

(1) I used CodeWarrior's built-in tool to convert my Carbon target to Mach-O
(Convert Target to Mach-O under File menu). Somehow in this process things
got a bit messed up (possibly my fault) and I think I ended up with an
executable having no resource fork. This resulted in a crash that
CodeWarrior did not trap. Instead my application appeared to just quit
cleanly. I could step in the debugger but if I stepped to far I had to
start over. I finally isolated this to some constructor which I had trouble
stepping into - perhaps I needed to turn inlining off. In any case I
noticed something was wierd when the Mach-O executable had the same name as
my Carbon Executable (!) in the same folder, and this was because it was
being created as a package folder with an invisible .app extension.

I resolved this tentatively by getting rid of the packaging entirely since I
was confused by it and it seemed extraneous. It took a while to figure out
how to do this since it involved changing options in several different
target preference panels, but I ended up with a working Mach-O executable
with a resource fork and no package.

(2) My application was built using PowerPlant which made my transition from
Classic to Carbon almost trivial. The transition to Mach-O was more painful
because of unexpected kinds of unresolved externals. There were unresolved
PowerPlant externals in the Mach-O target that did not exist in the Carbon
target. The Classic and Carbon targets were apparently able to "realize"
that I was not really calling certain parts of PowerPlant, but under Mach-O
this realization was somehow crippled. So I had to add a bunch of "unused"
PowerPlant sources to my Mach-O target only.


Now the app is ported except that I am still using SoundManager, but there
is one remaining problem. When the application quits the OS produces the
message "The application ... has unexpectedly quit." When I run under the
CodeWarrior debugger this message does not occur. When I run under gdb, the
message does not occur, but gdb reports "Program exited with code 0110."

Any clues about this? (Maybe this belongs on a different mailing list, but
it also fits in with the content of the "coremidi & codewarrior" thread.)

Also, I am curious how ProjectBuilder might compare to CodeWarrior in these
areas:
* in better recognizing code that does not need to be linked in
* in catching all exceptions correctly in the debugger instead of having the
"suddenly disappearing application" syndrome
* in terms of effectiveness of code optimization

Also is there any easy way to convert a large project from CodeWarrior to
ProjectBuilder?

Thanks,
Kurt Bigler
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: coremidi & codewarrior
      • From: Herbie Robinson <email@hidden>
  • Prev by Date: Re: Questions on data in MIDIPackets
  • Next by Date: Re: Questions on data in MIDIPackets
  • Previous by thread: cfmlateimport help
  • Next by thread: Re: coremidi & codewarrior
  • Index(es):
    • Date
    • Thread