Re: Re[4]: NSApp problem outside of bundle
Re: Re[4]: NSApp problem outside of bundle
- Subject: Re: Re[4]: NSApp problem outside of bundle
- From: Kyle Sluder <email@hidden>
- Date: Mon, 29 Jun 2009 17:11:02 -0700
On Mon, Jun 29, 2009 at 3:56 PM, Peter
Mulholland<email@hidden> 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@hidden)
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:
This email sent to email@hidden