Re[6]: NSApp problem outside of bundle
Re[6]: NSApp problem outside of bundle
- Subject: Re[6]: NSApp problem outside of bundle
- From: Peter Mulholland <email@hidden>
- Date: Tue, 30 Jun 2009 01:30:50 +0100
Hello Kyle,
Tuesday, June 30, 2009, 1:11:02 AM, you wrote:
> 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.
Technically it is. While it does execute on the command line without the nib in a bundle, its not really designed for that. It's just a bit naughty and it's really inside the original apps bundle.
I'll see how it goes. If necessary I'll put RegDialog.app inside Resources and then just have the loader run that instead.
> 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?
The loader uses mmap() to allocate the pages, and decrypt code into them, in a similar manner to what the kernel does when it loads a Mach-O file. I don't want to go into too much detail for obvious reasons! Needless to say, non executable pages are honored. Writing the contents out to disk would be foolish as it would be an obvious attack vector.
> 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."
Exactly, it's UNIX, and that's why i use execve() :)
> They don't, currently. Apple has not said anything beyond "we'll be
> using this more in the future than we are right now."
Making it so all apps must be signed would be incredibly foolish. Look at how much fuss requiring all drivers to be signed on Vista has kicked up, for example.
> I doubt that. Code signing is easy for anyone to do. Every single
> iPhone app is code signed, for example.
If anyone can sign code, what's the point in signing it ? Unless it's signed by a central authority, there is no point.
> 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 have a layer for that ;)
> There's a rather large OT argument to be had here. For Scott's sake,
> I'm going to avoid it.
Good. At the end of the day, if the original publisher demands we protect, we protect. The alternative is - no titles.
> Fair enough. But these kinds of copy protection schemes are always
> fraught with peril.
SO far, we've had only one conflict - Instant Hijack, and that has been known to cause problems in other apps, anyway.
--
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