Newbie
denis
suggestions for Objective C programming...
TIA!!
Andrew
The book most people recommend (and I'd concur) is "Cocoa Programming
for MacOS X" by Aaron Hillegass. It might be worth hanging fire,
though, because I suspect a new edition may be in the offing.
denis
<thec...@macunlimited.net> wrote:
Thanx, i'll give it a look...
Gregory Weston
No need to suspect. The new edition is due in May. I made the same
recommendation and caveat to the OP in a different group a few days ago.
FWIW, the 3rd ed ISBN is listed as 0321503619.
Andrew
Thanks. I'd missed that. I'll look forward to it.
rodmc
I am in the same situation so if you are prepared to join the
Association of Computing Machinery ($99) per year you can get access
to quite a few books on Objective-C, Mac programming via their
electronic books services (namely Safari). The book you mention is on
it as well as is "Programming in Objective-C" which although I bought
in its real form some time ago I can say is a good read for getting to
grips with the basics of the language before diving into Mac OS X
specifics. If you want to explore other languages you can find many on
Applescript and Python. So all in all the $99 per year I think is a
very good deal.
The ACM can be found at www.acm.org (please note I have no affiliation
within them beyond having been a member for years).
Hope this helps and saves you some cash.
Best,
rod
On Mar 4, 9:42 pm, Andrew <thecr...@macunlimited.net> wrote:
> On 2008-03-04 16:20:23 +0000, Gregory Weston <u...@splook.com> said:
>
>
>
> > In article <cEO1eB.A.6bH.luH...@sol01.ashbva.gweep.ca>,
> > Andrew <thecr...@macunlimited.net> wrote:
David Phillip Oster
<Pine.LNX.4.44.080507...@onyx.spiritone.com>,
Beta Zero <beta...@spiritone.com> wrote:
> On Thu, 6 Mar 2008, rodmc wrote:
> >Subject: Re: Newbie
> >
> >Hi,
> >
> >I am in the same situation so if you are prepared to join the
> >Association of Computing Machinery ($99) per year you can get
> >access to quite a few books on Objective-C, Mac programming
> >via their electronic books services (namely Safari). The book
> >you mention is on it as well as is "Programming in Objective-C"
> >which although I bought in its real form some time ago I can
> >say is a good read for getting to grips with the basics of the
> >language before diving into Mac OS X specifics.
>
> Hi! I'm relatively new to the Mac 'mini' and would like to port some
> vintage 68000 assembly language source over to 'C' on the Mac. It's
> pure 68000 code, and I regret to say I have zero experience with 'C.'
>
> Do you know of any good books to get, or scope out? Even if they are
> hard to come by? I want to port some Atari ST code over to the Mac.
> I have about a meg of 68000 source code - that's not much but it
> represents several years of handtinkering, and fine-tuning. It's
> independent of GEM binding (I always had trouble with GEM, so I
> manhandled the thing into existence, occasionally delving into
> supervisor mode when necessary.).
>
> I was wondering if it would be easier hand-tinkering this into shape
> for execution on a Mac. What is your favorite assembler for the Mac?
>
> Are there any good books you can suggest?
Aaron Hillegas' "Cocoa Programming for OS X"
http://www.amazon.com/Cocoa-Programming-Mac-OS-2nd/dp/0321213149 is the
book to get. (Actually, the third edition, which isn't quite out yet, is
the one to get.)
You'd have to be pretty crazy to program Macs in assembly language: a
substantial fraction are Intel Macs. a substantial fraction are Power PC
Macs. iPhones, and iPod Touches run OS X, but use the Arm processor.
Macs have one to eight "cores" (Think independent CPUs). Some Macs have
vector processing units. They have varying degrees of processing power
in the video card. Future machines may be yet again different.
Do you want to spend your life coding for all the possible combinations
of machines that will run your code?
If you call Apple's libraries, then you'll get optimized performance by
experts of the whole range of current (and future!) hardware.
That said, you can intermix Objective-C, C, and C++, if you know what
you are doing, and many people treat C as a universal assembler. You can
pretty much do a one-to-one translation from a line of assembly language
to a line of C. You'll produce hideous C, though.
Consider this web page:
http://www.vetta.org/2008/05/scipy-the-embarrassing-way-to-code/
The author describes how doing a blind translation from one language
resulted in something much longer to write, and much slower to run, than
taking advantage of the support that was built-in.
Gregory Weston
> Hi! I'm relatively new to the Mac 'mini' and would like to port some
> vintage 68000 assembly language source over to 'C' on the Mac. It's
> pure 68000 code, and I regret to say I have zero experience with 'C.'
Then, bluntly, you're in for a huge project.
> Do you know of any good books to get, or scope out?
The very first starting point is "The C Programming Language." The ISBN
is 0131103628.
> Even if they are
> hard to come by? I want to port some Atari ST code over to the Mac.
> I have about a meg of 68000 source code - that's not much but it
> represents several years of handtinkering, and fine-tuning. It's
> independent of GEM binding (I always had trouble with GEM, so I
> manhandled the thing into existence, occasionally delving into
> supervisor mode when necessary.).
>
> I was wondering if it would be easier hand-tinkering this into shape
> for execution on a Mac.
The assembly? No. Not least because at the moment the active base of Mac
users includes two radically different architectures, neither of which
has an assembly language that looks more than superficially like 68k.
The odds you'll beat modern compilers by hand-tinkering are miniscule.
The odds you'll beat them significantly enough to eclipse the time taken
hand-tinkering are essentially nil.
--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix
Robert Spykerman
> In article
> <Pine.LNX.4.44.0805071236490.13992-100...@onyx.spiritone.com>,
> Beta Zero <beta_z...@spiritone.com> wrote:
<SNIP>
> > hard to come by? I want to port some Atari ST code over to the Mac.
> > I have about a meg of 68000 source code - that's not much but it
> > represents several years of handtinkering, and fine-tuning. It's
> > independent of GEM binding (I always had trouble with GEM, so I
> > manhandled the thing into existence, occasionally delving into
> > supervisor mode when necessary.).
>
> > I was wondering if it would be easier hand-tinkering this into shape
> > for execution on a Mac.
>
> The assembly? No. Not least because at the moment the active base of Mac
> users includes two radically different architectures, neither of which
> has an assembly language that looks more than superficially like 68k.
> The odds you'll beat modern compilers by hand-tinkering are miniscule.
> The odds you'll beat them significantly enough to eclipse the time taken
> hand-tinkering are essentially nil.
That's one problem, but really, learning another architecture to code
is not that unsurmountable. What's more difficult imho is learning how
to call the API. If your orignal code does nothing but console type i/
o you could link to c standard libs or perhaps do naughty
unrecommended things like call the kernel with syscalls, but given
you're saying you coded for an Atari I'm guessing there's graphics
involved. This will be more involved and imho you're going to have to
learn to deal nicely with the OS nicely and that will mean learning
the necessary APIs to call what you need.
Then you're better off learning to do it in objective-C, which
probably means just a little more effort than learning a new CPU
architecture. I think you'll get to know the API's much quicker this
way. I know it sounds like more work but that's probably what you'll
need to do, and ultimately my guess is going the objective-C way is
probably going to result in you porting it faster... Part of the
problem is finding documentation on how to do things the right way in
assembly.
Don't be put off though, if you still want to learn IA-32 assembly,
and have the time to do it, by all means do it. It may not be very
productive but you got to admit it, if you've time to burn it's a lot
of fun. One thing I think you'll notice and will have to get used to
is the smaller register set, and somewhat slightly less orthogonality.
If you actually you have a PowerPC in your mac mini, then you may see
a few more similarities to a 68k but there are drastic differences as
well. Pity that chip is going to be resigned to embeddeds and game
consoles :( Would have loved to see it developed more for the
mainstream pc. :( :( :( :( Now we're stuck with intel/amd pretty
much...
One great way is to gcc with the -S option on to see what the compiler
spits out. The other way is to trawl on line. The one thing you
probably won't find a lot on is how to write and link asm code on OS X
to c libs or cocoa but I have to admit, I've not been actively looking
for stuff like this for a while and I've a feeling the best way is
just to see what the compiler spits out.
If you do find good links do let me know I'm interested.
Robert Spykerman
glenn andreas
<Pine.LNX.4.44.08050...@onyx.spiritone.com>,
Beta Zero <beta...@spiritone.com> wrote:
> >You'd have to be pretty crazy to program Macs in assembly language:
> >a substantial fraction are Intel Macs. a substantial fraction are
> >Power PC Macs. iPhones, and iPod Touches run OS X, but use the Arm
> >processor.
>
> Okay.
>
> >Macs have one to eight "cores" (Think independent CPUs). Some Macs
> >have vector processing units. They have varying degrees of processing
> >power in the video card. Future machines may be yet again different.
>
> Yes, the Mac is an amazing machine; the graphics capabilities are
> absolutley dazzling! But I was curious why the Darwin 'Unix'
> implementation lacks any apparent way of manipulating .WAV files?
Why would you expect Unix have anything that works with Windows format
sound files?
OTOH, QuickTime and CoreAudio both support WAV files...
Jolly Roger
<gandreas-8094CC...@sn-ip.vsrv-sjc.supernews.net>,
glenn andreas <gand...@mac.com> wrote:
There are plenty of other both built-in and third-party software titles
that support WAV as well. I don't see where the OP gets the crazy idea
Mac OS X somehow doesn't support WAV.
--
Please send all responses to the relevant news group. E-mail sent to
this address may be devoured by my very hungry SPAM filter. I do not
read posts from Google Groups. Use a real news reader if you want me to
see your posts.
JR
Sherman Pendley
> The one thing you
> probably won't find a lot on is how to write and link asm code on OS X
> to c libs
If you want to see what the ABI looks like in asm, you could have a look
at the source for libffi, which is included with the gcc source. That's
its job - you create a set of structures that describe a function's args
and return value, and pass them along with a pointer to the function
itself to a function in libffi. That function sets up the required stack
frame and makes the function call.
Apple also publishes their ABI details here:
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Introduction.html>
Or tinyURLd: <http://preview.tinyurl.com/s7f85>
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
Robert Spykerman
> Robert Spykerman <robert.spyker...@gmail.com> writes:
> > The one thing you
> > probably won't find a lot on is how to write and link asm code on OS X
> > to c libs
>
> If you want to see what the ABI looks like in asm, you could have a look
> at the source for libffi, which is included with the gcc source. That's
> its job - you create a set of structures that describe a function's args
> and return value, and pass them along with a pointer to the function
> itself to a function in libffi. That function sets up the required stack
> frame and makes the function call.
This, I didn't know. Thank you very very much :)
Not having RTFM'ed just quite yet I'm assuming libffi is a DLL loaded
and present eh? Do you have any links to examples on how to link
assembly to DLL's ?
I have to admit I don't really like writing GUIs but I was thinking of
writing stuff that will call GTK - that way I (hopefully) will only
need to write most of the code once somewhere ie linux and might have
a fairly decent chance of porting to OSX and perhaps even windoze.
Cheers + thanks
> sherm--
Robert Spykerman
Sherman Pendley
> On May 10, 7:25 am, Sherman Pendley <spamt...@dot-app.org> wrote:
>> Robert Spykerman <robert.spyker...@gmail.com> writes:
>> > The one thing you
>> > probably won't find a lot on is how to write and link asm code on OS X
>> > to c libs
>>
>> If you want to see what the ABI looks like in asm, you could have a look
>> at the source for libffi, which is included with the gcc source. That's
>> its job - you create a set of structures that describe a function's args
>> and return value, and pass them along with a pointer to the function
>> itself to a function in libffi. That function sets up the required stack
>> frame and makes the function call.
>
> This, I didn't know. Thank you very very much :)
>
> Not having RTFM'ed just quite yet I'm assuming libffi is a DLL loaded
> and present eh? Do you have any links to examples on how to link
> assembly to DLL's ?
In my project, I build and link to a static .a library. DLL's aren't used
on Macs - if you're talking about dynamic libraries, they've got .dylib
extensions. Sometimes .so. But never .dll - too many horrible memories for
some of us. :-)
Anyhow, to load them, you'll probably want to call dyld:
<http://developer.apple.com/documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html>
<http://preview.tinyurl.com/3tk758>
In general, I think you'll find this an interesting read too:
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/introduction.html>
<http://preview.tinyurl.com/3qvmh5>
> I have to admit I don't really like writing GUIs but I was thinking of
> writing stuff that will call GTK - that way I (hopefully) will only
> need to write most of the code once somewhere ie linux and might have
> a fairly decent chance of porting to OSX and perhaps even windoze.
Honestly, I think Gtk apps are best written in C. When in Rome...
Robert Spykerman
<SNIP>
> Honestly, I think Gtk apps are best written in C. When in Rome...
>
> sherm--
Thanks for your tips. True that. But you see I don't do this for a
living, and I have a perverse interest in doing things the hard way,
mainly because I just want to understand how things work. I'm also
kind of trying to port a linux forth (originally in IA-32 assembly +
forth ) over to OSX - it's going pretty well by the way, functionally
it's all pretty much there except now I've to figure out how to hack
the mach-o headers to do a SAVE-SYSTEM. Be nice after I get that bit
of hackery done to get it to call dynamic libraries on OSX (those so
ones - sorry for calling them DLL's :P) Be nice if I can get this
forth linked up to GTK on all these systems ultimately.
I can see lots of heads shaking (lol).
Thanks for all your tips
Robert Spykerman
Sherman Pendley
> Thanks for your tips. True that. But you see I don't do this for a
> living, and I have a perverse interest in doing things the hard way,
> mainly because I just want to understand how things work.
Can't argue with that. If you have no boss and no deadline, have at it.
> I'm also
> kind of trying to port a linux forth (originally in IA-32 assembly +
> forth ) over to OSX
Cool. I think you'll find that Forth isn't completely unknown to Mac
users. The Open Firmware used on later PPC Macs had a Forth stack.
> Be nice if I can get this
> forth linked up to GTK on all these systems ultimately.
Actually, it would be *much* better received by Mac users if it were
linked up to a native interface - that is, one that's a native Mac app,
not a Unix app displayed on an X11 server that happens to be running on
a Mac. A native Aqua interface is non-portable, but portability went out
the window when you chose assembler to begin with.
Paul Russell
> On Fri, 9 May 2008, Jolly Roger wrote:
>>> Why would you expect Unix have anything that works with Windows format
>>> sound files?
>>>
>>> OTOH, QuickTime and CoreAudio both support WAV files...
>> There are plenty of other both built-in and third-party software titles
>> that support WAV as well.
>
>
>> I don't see where the OP gets the crazy idea Mac OS X somehow doesn't
>> support WAV.
>
> "Terminal" line editor, (that is, I understand, called "Darwin") and
> still, somehow, manipulate .WAV or .RAW files. Can you give me an
> example, please? We all know that the Mac OS X can manage sound just
> fine. But doing it from the "Terminal" line editor? How would I do
> that? Talk me through it slowly. First, I move the mouse down to the
> 'terminal' icon and click it. A window opens up, and I can type stuff
> in. What am I to do next, aside from typing 'exit'?
>