On Mon, Jun 29, 2009 at 3:56 PM, Peter
Mulholland<[email protected]> wrote:
> If you are referring to me not using NSApplicationMain(), how is that 
> unsupported? In fact the code is based on things I've seen in Apple samples. 
> [NSApplication sharedApplication] is a documented API. So is loading your own 
> NIB. I'm not doing anything illegal there.

I'm referring to your use of NSApplication in an app that's not
bundled.  You can't do that.  Apps must be in app bundles.

>> Then perhaps you should be considering a refactor.
>
> No. Effectively, the code functions like an executable unpacker. In fact, I 
> got the idea from the source code to the UPX executable packer. There is 
> nothing wrong with this approach provided the methods are fully understood.

You mean aside from the whole idea of non-executable pages?  Or do you
write the contents out to disk and execute them from there?

> Besides, what do you think Launch Services does? Eventually, it calls 
> vfork()/execve(). It just adds some friendly fluff over the top of it.

Well yes, but that's not saying much.  This is UNIX, after all.  It's
a bit like saying "Besides, what do you think Quartz does?
Eventually, it shoves data over PCI-Express.  It just adds some
friendly fluff over the top of it."

>> You don't know what Apple has in store for code signing requirements
>> on post-Leopard operating systems.  It is known that code signing
>> requirements will be stricter in the future than they are now.  How
>> and when is still unknown, but trying to decrypt and execute an
>> application like this might result in irking the security gods.
>
> Since when do apps running on OS X *have* to be code signed?

They don't, currently.  Apple has not said anything beyond "we'll be
using this more in the future than we are right now."

> IF Apple start requiring ALL apps to be code signed (and presumably, charge 
> for the privilege), watch as support from smaller developers disappears. Even 
> MS aren't going to do that.

I doubt that.  Code signing is easy for anyone to do.  Every single
iPhone app is code signed, for example.

> This is exactly the kind of attitude that means game dev does *not* happen on 
> OS X.

I highly doubt that.  I would imagine the fact that the Mac doesn't
run DirectX or expose a Win32 API has a lot to with that.

> We reserve the right to attempt to protect our investment and hard work! More 
> to the point, we do a lot of porting work, and it is a requirement of the 
> original publisher/developer that we protect the port as much as possible.

There's a rather large OT argument to be had here.  For Scott's sake,
I'm going to avoid it.

> The aim is not to prevent cracking - that will happen. The aim is to make it 
> as difficult as possible, and delay it so that our product has a chance to 
> sell. Also, it means we can make thinks awkward for those people using 
> cracked copies.

Fair enough.  But these kinds of copy protection schemes are always
fraught with peril.

--Kyle Sluder
_______________________________________________

Cocoa-dev mailing list ([email protected])

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to