Objective-C on Palmos?

Objective-C on Palmos?

Post by Charlton Wilbu » Fri, 04 Jul 2003 05:59:23



All,

I'm working on an application for MacOS X.  Eventually this
application is going to have a tentacle on PalmOS devices, and
possibly also on Windows.  I'd like to keep as much of the codebase
the same across platforms as possible.  The only mention of
Objective-C I can find in connection with PalmOS is in gcc-building
instructions, which advise against enabling Objective-C because the
gcc runtime has not yet been ported.

Any suggestions?  I'm considering a couple different paths right now,
and if anybody else has done something like this I'd appreciate
hearing about it.

Thanks,
Charlton

 
 
 

Objective-C on Palmos?

Post by David Ste » Fri, 04 Jul 2003 15:19:35



Quote:

> The only mention of
> Objective-C I can find in connection with PalmOS is in gcc-building
> instructions, which advise against enabling Objective-C because the
> gcc runtime has not yet been ported.

One of the issues that you should be aware of, is that there are two kinds
of Objective-C runtimes.  There is on the one hand a completely ANSI C
based runtime, with a messenger that is working pure C (as in POC), and on
the other hand an older implementation of the Objective-C msgSend() which
used to be based on a small amount of assembly or machine-dependent C code.

The effort of porting an Objective-C runtime can be proportional to whether
one uses the plain C variant or the other variant.  In the case of POC, the
port to PalmOS has been done (or you can crosscompile on a platform and
generate code for PalmOS), and the fact that this works depends largely on
the fact that the implementation of messaging in POC is based on pure C.

 
 
 

Objective-C on Palmos?

Post by Chris Hanso » Fri, 04 Jul 2003 17:44:33



The only mention of

Quote:> Objective-C I can find in connection with PalmOS is in gcc-building
> instructions, which advise against enabling Objective-C because the
> gcc runtime has not yet been ported.

I suspect it wouldn't be too difficult to port the runtime to PalmOS,
since I believe the runtime already runs on other 68K & ARM-based
systems.

  -- Chris

--

Custom Application Development        |  Phone: +1-847-372-3955
http://bdistributed.com/              |  Fax:   +1-847-589-3738

 
 
 

Objective-C on Palmos?

Post by Andy Den » Sun, 13 Jul 2003 01:15:18




Quote:> All,

> I'm working on an application for MacOS X.  Eventually this
> application is going to have a tentacle on PalmOS devices, and
> possibly also on Windows.  
...
>if anybody else has done something like this I'd appreciate
> hearing about it.

I've been working for much of the last 8 months on a project which runs
on PocketPC, Windows, OS/X and Palm. (Brainwave monitoring and
broadcasting for http://www.ibva.com/)

The core engine is all c++.

The OS/X GUI is Cocoa using .mm files (Objective C++) so it compiles
calls to the core engine.

If you want to use Cocoa, factor out your engine.

Yes I know that I sell portable PowerPlant tools and using Cocoa may
seem like a contradiction of what we sell - the only Mac version
required was OS/X, the original code base was Windows and I wanted the
best OS/X GUI possible. At present, that's only achievable in Cocoa
(although Carbonised apps are catching up.)

I still recommend PowerPlant as a framework if you need OS 9 or earlier
GUI's and look forward to PowerPlant X.

 
 
 

Objective-C on Palmos?

Post by Charlton Wilbu » Sun, 13 Jul 2003 07:58:20





> > All,

> > I'm working on an application for MacOS X.  Eventually this
> > application is going to have a tentacle on PalmOS devices, and
> > possibly also on Windows.  
> ...
> >if anybody else has done something like this I'd appreciate
> > hearing about it.

> I've been working for much of the last 8 months on a project which runs
> on PocketPC, Windows, OS/X and Palm. (Brainwave monitoring and
> broadcasting for http://www.ibva.com/)

> The core engine is all c++.

The answer I was hoping for is "Oh, you can get the OpenStep libraries
here, and if you use POC to compile them to plain-C you can then write
the interface in C."  It seems to me that this is possible in theory
if not in practice, and it's the path I'm going to try to take.

Further, given the choice between using C++ and gouging my eyes out
with a dull spoon -- let's just say that I'm glad OSX has good
adaptive usability features, if it ever comes to that choice.

Charlton

 
 
 

Objective-C on Palmos?

Post by genetic antagonis » Sun, 13 Jul 2003 09:28:16



> The answer I was hoping for is "Oh, you can get the OpenStep libraries
> here, and if you use POC to compile them to plain-C you can then write
> the interface in C."  It seems to me that this is possible in theory
> if not in practice, and it's the path I'm going to try to take.

I am no fan of Objective-C, myself.  When I first started developing for
MacOSX I looked for ways to make an end-run around it.  Carbon is just
awful, so that's out.  In the back of "Inside MacOSX: The Objective-C
Programming Language," there's very thorough documentation of the C
functions that make up the Objective-C runtime, and I suspect those
could be used to produce a mostly C interface to Cocoa, if you really
worked at it.  It wouldn't be fun, though, and it would be a hell of a
lot of work.  You'd have to become an expert at Objective-C internals,
which is pretty much the *last* thing I want to do.  Cocoa makes heavy
use of Objective-C's runtime polymorphism so a C interface wouldn't be a
very good fit anyway.

Even if you got that to work, you'd still be stuck with what I consider
to be the absolute worst part of Cocoa: retain/release/autorelease.
There's no getting around the fact that Cocoa expects NSObjects to work
that way.  You can't just malloc() things into existence and then free()
them later on, as much as I'd like to.

So what I'm doing instead is writing a C++ API on top of Cocoa.  You can
get by with a surprisingly small amount of ObjC in that case.  I'd guess
it makes up less than five percent of my codebase.  Once I get wrappers
written for all the controls and views and fonts and rects and points
and so on I plan to use, and get them all thoroughly debugged so that
the retain/release crud doesn't cause me to leak buckets-full of
objects, then I can program in C++ and pretend to be blissfully unaware
of what's going on underneath.

I'm almost done, only four or five more control wrappers to write, but
it was a *huge* job.  It's part of a larger project, so I'm not sure how
much time I've devoted to just the Cocoa C++ wrapper, but I'd guess it
was six months of full-time work.  *Way* too long.  I should have bailed
when I realized what a big job it is but I am very stubborn.  At this
point I'm sticking with it out of sheer hard-headed-ness.

If I had it to do over again I might very well write a Cocoa port for
wxWindows instead.  There's another guy claiming he's doing that but
he's not making much progress.  I can't work up much e*ment for
that, though.  wxWindows tends to use MS Windows metaphors: everything
is a window, you draw with a DC, lots of operations require brushes,
etc.  Not my bag.

 
 
 

Objective-C on Palmos?

Post by Stefan Arent » Sun, 13 Jul 2003 19:11:06



...

Quote:> Even if you got that to work, you'd still be stuck with what I consider
> to be the absolute worst part of Cocoa: retain/release/autorelease.
> There's no getting around the fact that Cocoa expects NSObjects to work
> that way.  You can't just malloc() things into existence and then free()
> them later on, as much as I'd like to.

s/malloc/retain/
s/free/release/

You seem to understand the basics of memory management. Why are different
semantics more difficult?

 S.

 
 
 

Objective-C on Palmos?

Post by Charlton Wilbu » Mon, 14 Jul 2003 01:43:14



Quote:> I am no fan of Objective-C, myself.  When I first started developing for
> MacOSX I looked for ways to make an end-run around it.  Carbon is just
> awful, so that's out.  In the back of "Inside MacOSX: The Objective-C
> Programming Language," there's very thorough documentation of the C
> functions that make up the Objective-C runtime, and I suspect those
> could be used to produce a mostly C interface to Cocoa, if you really
> worked at it.  It wouldn't be fun, though, and it would be a hell of a
> lot of work.  

I don't *want* to write the whole thing in C.  I want to write the
whole thing (or as much of it as possible) in Objective-C, and it's
the lack of Objective-C support *on the Palm* that's my problem.

Quote:> So what I'm doing instead is writing a C++ API on top of Cocoa.  

Woo, I'd get to gouge my eyes out with a *sharp* spoon.

Charlton

 
 
 

Objective-C on Palmos?

Post by David Ste » Mon, 14 Jul 2003 05:32:03



Quote:

> Even if you got that to work, you'd still be stuck with what I consider
> to be the absolute worst part of Cocoa: retain/release/autorelease.
> There's no getting around the fact that Cocoa expects NSObjects to work
> that way.  You can't just malloc() things into existence and then free()
> them later on, as much as I'd like to.

This is however, how regular Objective-C works.

+new does a malloc() of some C structure, and -free does a free() of that
C structure, if that is required.

 
 
 

Objective-C on Palmos?

Post by David Ste » Mon, 14 Jul 2003 15:09:50



Quote:

> Until then, say _nothing_ about 'regular' or 'standard' or whatever
> Objective-C methods and classes.

The non-standard retain/release/autorelease memory management can easily
be implemented in a subclass of Object.   You can implement NSObject stuff
as a subclass of Object (implementing autorelease in terms of +new and -free).

It is a design mistake in NSObject that it wasn't just subclassed from the
standard root class (the one that is shipped with all Objective-C compilers,
such as GNU Objective-C, POC etc.)

 
 
 

Objective-C on Palmos?

Post by Michael As » Mon, 14 Jul 2003 15:24:27





> > Until then, say _nothing_ about 'regular' or 'standard' or whatever
> > Objective-C methods and classes.

> The non-standard retain/release/autorelease memory management can easily
> be implemented in a subclass of Object.   You can implement NSObject stuff
> as a subclass of Object (implementing autorelease in terms of +new and -free).

You mean like implementing Color in a subclass of String?

Quote:> It is a design mistake in NSObject that it wasn't just subclassed from the
> standard root class (the one that is shipped with all Objective-C compilers,
> such as GNU Objective-C, POC etc.)

Apple uses GNU Objective-C, and they ship Object with their compiler too.
 
 
 

Objective-C on Palmos?

Post by David Ste » Mon, 14 Jul 2003 16:19:12



Quote:

>> The non-standard retain/release/autorelease memory management can easily
>> be implemented in a subclass of Object.   You can implement NSObject stuff
>> as a subclass of Object (implementing autorelease in terms of +new and -free).

> You mean like implementing Color in a subclass of String?

I mean like in: fixing the non-standard retain/autorelease stuff in order to
make it use the regular +new and -free messages.
 
 
 

Objective-C on Palmos?

Post by Christian Brunsch » Mon, 14 Jul 2003 19:53:52





>> Until then, say _nothing_ about 'regular' or 'standard' or whatever
>> Objective-C methods and classes.

>The non-standard retain/release/autorelease memory management can easily
>be implemented in a subclass of Object.   You can implement NSObject stuff
>as a subclass of Object (implementing autorelease in terms of +new and -free).

>It is a design mistake in NSObject that it wasn't just subclassed from the
>standard root class (the one that is shipped with all Objective-C compilers,
>such as GNU Objective-C, POC etc.)

The main point in all this is that there is _no Objective-C standard_.
There was never any normative document about what is or isn't 'standard
Objective-C' or what is or isn't a 'standard Objective-C root class' -
there was only ever that which the compilers implement, and the class
libraries that are available.

This means that the closes we can come to 'standard Objective-C' right
now, is to look at what might be a _de-facto_ standard; and the usual way
ofdoing that is to look at the usage of what is out there, which
in this case means, look at what compilers and classes libraries and
memory management conventions that people actually _use_.

And in that light, Apple's Objective-C compiler (gcc) and the Foundation
classes (Cocoa / GNUstep) _are_ the de-facto standard. In other words, It
is +new/-free which is, these days, 'non-standard'.

Oh, and don't forget that Apple actually own all rights to the Objective-C
language and trademark, which were bought from Stepstone (the original
developers of Objective-C) by NeXT. This means that Apple are the official
authority on Objective-C.

Best wishes,

// Christian Brunschen

 
 
 

Objective-C on Palmos?

Post by Ian Robinso » Mon, 14 Jul 2003 20:48:21


On Sun, 13 Jul 2003 11:53:52 +0100, Christian Brunschen wrote

Quote:> This means that Apple are the official
> authority on Objective-C.

The words "red", "rag" and "bull" spring to mind :-)

Ian

--
Ian Robinson, Belfast, UK - <http://www.canicula.com>
Soapbox - <http://homepage.mac.com/ianrobinson/index.html>

 
 
 

Objective-C on Palmos?

Post by genetic antagonis » Tue, 15 Jul 2003 01:38:35



> s/malloc/retain/
> s/free/release/

> You seem to understand the basics of memory management. Why are
> different semantics more difficult?

Surely you jest.

In C programming, how many times do you malloc() something, then have
the OS malloc() the very same thing, and you can't free() it until the
OS does?  And in ObjC, there really *is* no free(), just you stating an
intention that you don't want something anymore, because all the
free()ing is done by Cocoa itself.  And in C, you don't need to create
foreign objects (i.e., autorelease pools) to control when your objects
get deallocated.  And there's all these rules, sometimes you have to
indicate you don't want an object anymore, sometimes you don't.  Ad
infinitum.

I don't know the whole history of that, but I'm guessing the NeXTStep or
Cocoa designers looked at the vexing but well-understood problem of
object lifetimes and "fixed" it with retain/release.  Their "fix" is an
order of magnitude more complicated.  With care it's possible to get
correct behavior with malloc()/free(), but with retain/release, it
almost never is.

I have an interesting bug in some of my Cocoa code.  Under certain
circumstances MacOSX itself sends a spurious retain message to my
Services menu, causing it to leak.  See, that's not even my fault!  And
there's nothing I can do about it!  I discovered it only through an
elaborate series of memory-tracking macros I wrote myself so I can stop
leaking buckets-full of ObjC objects, which is definitely going to
happen to any Cocoa first-timer.

retain/release is an *awful* system.  Beginner-unfriendly in the
extreme.  Even after a year and a half of fooling with it I *still* hate
it.

 
 
 

1. Objective C on PalmOS?

Hello,

I've been watching traffic on Sun's KVM (java for PDA's) mailing list
and I have been consistently struck by the idea to put the ObjC runtime
on PalmOS and avoid all the JNI bull***t required to tie the VM to the
system it runs upon, etc.

One of the uses of such a thing might be to do a Palm-based ObjC dev
environment -- at least for writing/testing small objects.  Or, to
leverage some of the dynamic abilities of Objective C for building
less-trivial Palm apps.  Or, to utilize other Objective C tools/libs for
writing Palm apps.  Or, to port OpenStep apps to PalmOS.

Since the runtime source is available from the Darwin site, it would
seem like just a matter of doing it.  Would anyone here have pros/cons
to this undertaking?  Would you consider it a waste of time?  Would
there be any real benefit?  Would it be within the bounds of reason to
think that one could use ProjectBuilder to build an IB-defined Palm app?

If you don't see a benefit, why is Sun porting its VM to PalmOS?

Thanks,
np

Sent via Deja.com http://www.deja.com/
Before you buy.

2. EIDE or SCSI??? Any suggestions?

3. ANSI Objective-C wanted ( Re: Objective-C Tanslator)

4. Direct CTS Need: Senior System Administrator in West Lake Village, CA || Today Interview

5. NeXT Objective-C vs. GNU Objective-C

6. Kodak Easyshare Software

7. Updated C++ Library for PalmOS (Teenee)

8. GALer registration

9. A PalmOS C++ Application Framework

10. Need threads for PalmOS

11. ObjC for PalmOS

12. POC as a cross-compiler for PalmOS?

13. Gnu EMACS and Objective-C ... i.e. Objective-C-mode.el