Re[4]: NSApp problem outside of bundle
Re[4]: NSApp problem outside of bundle
- Subject: Re[4]: NSApp problem outside of bundle
- From: Peter Mulholland <email@hidden>
- Date: Mon, 29 Jun 2009 23:56:52 +0100
Hello Kyle,
Monday, June 29, 2009, 11:36:54 PM, you wrote:
> Because it directly violates quite a few requirements of working on OS
> X? And you're resorting to pretty convoluted workarounds to try to
> get things working again. That should be a pretty good clue that
> you're doing things incorrectly.
Such as what?
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.
> You need NSApplication? It's an application. It needs its own
> bundle. That bundle can live in Resources (or this mythical, unnamed
> "Support" directory referred to in the code signing documentation).
I might well move it to a bundle and put it in Resources, anyway. If we get any more problems, I will do so. Originally I had written the dialog in Carbon to avoid this hassle.
> 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.
Besides, what do you think Launch Services does? Eventually, it calls vfork()/execve(). 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?
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.
> Frequently people come to this list asking for help with their
> copy-protecting scheme. The consensus is that it is not worth the
> time and money you will invest in the process, or the frustration you
> will (not may, will; I dare anyone to prove that there is absolutely
> no circumstance under which their copy protection can fail) cause for
> your users. Meanwhile, someone's going to strip off your copy
> protection, upload your game to the web, and pirates who never would
> have purchased your game in the first place will enjoy it hassle-free.
> By all means, make a pass at it. Do a simple check on startup, and if
> it fails, guilt and shame the user into purchasing the app. But
> attempting to intervene in the loading process is not going to bode
> well for your code health.
This is exactly the kind of attitude that means game dev does *not* happen on OS X.
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.
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.
--
Best regards,
Peter mailto:email@hidden
_______________________________________________
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