Hello Michael,
Tuesday, June 30, 2009, 3:34:31 AM, you wrote:
> What, that the free help doesn't feel like helping you implement a
> proprietary DRM scheme makes it impossible to develop games on OS X?
> You're free to develop whatever scheme you wish. Expecting people to
> help you with it even
On Mon, Jun 29, 2009 at 8:11 PM, Kyle Sluder wrote:
>> 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
On Mon, Jun 29, 2009 at 6:56 PM, Peter
Mulholland wrote:
> This is exactly the kind of attitude that means game dev does *not* happen on
> OS X.
What, that the free help doesn't feel like helping you implement a
proprietary DRM scheme makes it impossible to develop games on OS X?
You're free to
On Mon, Jun 29, 2009 at 5:30 PM, Peter
Mulholland wrote:
> 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 really might just want to save yourself the effort and do it now.
Things break in extremely subtle ways when
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 desi
On Mon, Jun 29, 2009 at 3:56 PM, Peter
Mulholland 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
Hello Steve,
Tuesday, June 30, 2009, 12:42:31 AM, you wrote:
> It's actually described very clearly in Xcode's developer docs for
> TransformProcessType:
> ...
> Parameters
> PSN
> The serial number of the process you want to transform. You can also
> use the constant kCurrentProcess to r
On Jun 29, 2009, at 3:22 PM, Peter Mulholland wrote:
Monday, June 29, 2009, 11:12:20 PM, you wrote:
You don't use kCurrentProcess as an argument. You use it like this:
ProcessSerialNumber psn = { 0, kCurrentProcess };
TransformProcessType( &psn, ... );
I see. It isn't really explained all t
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 incor
On Mon, Jun 29, 2009 at 3:20 PM, Peter
Mulholland wrote:
> Monday, June 29, 2009, 9:17:35 PM, you wrote:
>
>> Woah... this is kinda nuts.
>
> How exactly?
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
Hello Stephen,
Monday, June 29, 2009, 11:12:20 PM, you wrote:
> You don't use kCurrentProcess as an argument. You use it like this:
> ProcessSerialNumber psn = { 0, kCurrentProcess };
> TransformProcessType( &psn, ... );
I see. It isn't really explained all that clearly.
I'll give that a shot.
Hello Kyle,
Monday, June 29, 2009, 9:17:35 PM, you wrote:
> Woah... this is kinda nuts.
How exactly?
> 1) Applications need to be in their own app bundle.
Really, this isn't an application, its a component. There's probably a better
way to do it, but I can't think of one.
> 2) Don't fork/exe
On Mon, Jun 29, 2009 at 3:03 PM, Peter
Mulholland wrote:
> BTW Yes I know about kCurrentProcess. It doesn't work. Passing that to
> TransformProcessType() causes a crash.
You don't use kCurrentProcess as an argument. You use it like this:
ProcessSerialNumber psn = { 0, kCurrentProcess };
Transfo
On Mon, Jun 29, 2009 at 10:21 AM, Peter
Mulholland wrote:
> I am not using NSApplicationMain() as this would attempt to load the original
> app's nib. Instead I do this:
>
> int main(int argc, char *argv[])
> {
>[[NSAutoreleasePool alloc] init];
>[NSApplication sharedApplication];
On Mon, Jun 29, 2009 at 8:21 AM, Peter
Mulholland wrote:
> A typical protected app bundle looks like so:
Woah... this is kinda nuts.
1) Applications need to be in their own app bundle.
2) Don't fork/exec to launch an application. Use LaunchServices instead.
3) Your "protection" will be easy to b
Hello,
> What's going on? What is NSApp trying to do that falls over when it's not in
> a bundle, or in another apps bundle on 10.4?
I've solved it. The problem was that [NSApplication sharedApplication] did not
add the app to the Dock for some reason. The following code solves that:
P
Hello,
I've made a program that handles doing a registration dialog for our protected
apps. The protection works by encrypting the original Mach-O executable and
attaching a stub. This stub attempts to load a licence file. If it's not
present, it vfork()/execve()'s this app.
A typical protecte
17 matches
Mail list logo
