No need
You’ve had a conversation with Geoff about this
No, I really do not understand what you mean, honestly. I said we are not allowed to modify the framework. You suggest that there’s more to it, i.e. that there may be a way to modify the framework that doesn’t violate the EULA? I would like to understand that, because, as you surely know, I like to go the easy way to work around this bug. so, if there is a way around it, I’d welcome your help. And Geoff said there is no way around it, so I don’t understand what you a re suggesting.
You can’t modify the framework itself, as that is a EULA violation. Norman was not suggesting that there was a “workaround” to that.
If you were to intercept a call or otherwise dynamically change your apps behavior at runtime as you mentioned, you wouldn’t be modifying the framework itself and that would address that issue.
Intercepting an OS call is the only way I can think of
[quote=232003:@Travis Hill]You can’t modify the framework itself, as that is a EULA violation. Norman was not suggesting that there was a “workaround” to that.
If you were to intercept a call or otherwise dynamically change your apps behavior at runtime as you mentioned, you wouldn’t be modifying the framework itself and that would address that issue.[/quote]
Right. Isn’t that exactly what I wrote to do as a solution to work around the bug? I still don’t get why Norman commented on that with that cryptic message with my quote, then. I am still confused.
Anyway. What Norman meant and what I thought he meant is not really important.
What’s important to me is to understand how to work around this issue by hooking into the CF function. Does anyone know how?
If anyone can help, I’ve also asked the question on SO: http://stackoverflow.com/questions/33925488/how-do-i-intercept-an-os-x-api-call-in-an-app
As far as I can tell, that’s all about objc bridge classes, which won’t help me here (and I already know how to intercept objc class methods, code for that is also in MacOSLib).
Hmm … that might work or not. It looks like it’s patching the actual function calls in memory. Which may mean it’s changing the framework’s code in memory. Which may or may not be allowed by the EULA. I can’t tell whether that’s allowed by the EULA or not. The EULA prohibits changing the framework, but it doesn’t specify whether it means not to change the file or the data loaded into working memory.
Could someone from Xojo Inc comment on this?
[quote=232044:@Thomas Tempelmann]Hmm … that might work or not. It looks like it’s patching the actual function calls in memory. Which may mean it’s changing the framework’s code in memory. Which may or may not be allowed by the EULA. I can’t tell whether that’s allowed by the EULA or not. The EULA prohibits changing the framework, but it doesn’t specify whether it means not to change the file or the data loaded into working memory.
Could someone from Xojo Inc comment on this?[/quote]
Come on Thomas. Changing code in memory is perfectly alright. If not most of the declares would not be permitted.
I am glad you see it that way. But does Xojo Inc? I am doubtful, as they even considered looking at the binary file format to be illegal reverse engineering of their code.
I don’t follow you there. A declare does not change any code in their framework code. Can you give an example?
Mind you - I originally thought that patching a bug in their framework after they did not even think into looking into it would allow me to at least fix it myself. But no, I was told that that would violate the EULA, with no option offered around it other than what I’m asking for help with there. So I am now sitting here, with an app I cannot deploy, at least not without looking like an clueless programmer when OS X write to the Console that my app is doing something it shouldn’t. How am I do handle that if I keep getting stone thrown in my way? So don’t you think it’s prudent of me to double check that I am allowed to patch the framework code in memory after already making once a wrong assumption and being chastised for it?
[quote=232049:@Thomas Tempelmann]I am glad you see it that way. But does Xojo Inc? I am doubful, as they even considered looking at the binary file format reverse engineering of their code. Seriously.
I don’t follow you there. A declare does not change any code in their framework code. Can you give an example?[/quote]
Seriously, I think you fail to realize the difference between physically changing a dylib file code with an hex editor or some other mean, which means in effect modifying the distribution Xojo’s intellectual property, and modifying events in memory or bypassing Xojo’s access to the framework as code executes in memory.
What is forbidden by Xojo and most other software publishers including yours truly is modifying the files. By essence, your executing code in memory is your own, and even if it calls into a dylib, nothing prevents it to do something else with that call or upon its return.
MacOSLib contains several declares that hook existing events. Same thing for WFS. I routinely modify events behavior in Xojo Web and without that RubberViewsWE would not have for instance LiveResize.
You are overthinking it.
Modifying framework files : TABOO.
Placing hooks on events : PERMITTED.
That’s your interpretation of it. I have not yet gotten a confirmation from Xojo that they see it that way, too. I hope they do, and I hope you help me if they don’t. That’s all I want to make this work. But I’ve been warned before that modifying their code in memory is not allowed, either. That’s why I’m careful here.
Just to be clear: Their EULA says that we’re not allowed to change their framework code. Whether that means their file or a copy in memory is not specified. I’ve been accused by them to violate the EULA more than once, and if I want to play by their rules I need to get this cleared up.
Or - think of it in the reverse: If they allow us to modify their code in memory, then what’s the difference to change the same code before it gets loaded into memory, i.e. by changing the file that gets loaded into memory? What’s the diference? None, effectively. Hence, if they disallow changing the file, then they would probably also disallow the change to the same data loading into memory. Hence, I do not believe that your argument is valid, although I’d hope it is.
What Travis posted is crystal clear to me :
You may want to post the code you plan on using eventually based on what Jean-Paul pointed to if you want extra confirmation, but I am confident you are fine with executable time code.
Michel, that does not match what you stated here, though:
What is forbidden by Xojo and most other software publishers including yours truly is modifying the files. By essence, your executing code in memory is your ownIf that were true, then I should be allowed to modify the framework once it’s loading in memory, i.e. I could simply search for the wrong parameter value (i.e. the 0.001 value) and change it to “0.01” value, the same way I’d change it in the file. But I’m sure I’m not supposed to do that, the way Xojo interprets their EULA. But I’d be happy if that would be allowed, as that would solve my problem. So I hope you’re right with this, it’s just not clear to me that it is, yet. Mind you, no one has yet offered any alternative - see the SO question I posted - it seems there is no other way.
I like to just solve this in any way. I am at the point where I want to release a big upgrade to my app, and I cannot because of this issue - yet I find no working way to work around it. If you know a way to patch the CF function, please share, and I’m happy. I’d even take a solution that works around using the buggy Shell class - but I need something that’s proven to work. Investing a few more days writing my own just because Xojo doesn’t allow me to fix this bug where it is is just not fair, and costs me resources I don’t think I should be liable for.
[quote=232060:@Thomas Tempelmann]Michel, that does not match what you stated here, though:
What is forbidden by Xojo and most other software publishers including yours truly is modifying the files. By essence, your executing code in memory is your ownIf that were true, then I should be allowed to modify the framework once it’s loading in memory, i.e. I could simply search for the wrong parameter value (i.e. the 0.001 value) and change it to “0.01” value, the same way I’d change it in the file. But I’m sure I’m not supposed to do that, the way Xojo interprets their EULA. But I’d be happy if that would be allowed, as that would solve my problem. So I hope you’re right with this, it’s just not clear to me that it is, yet.[/quote]
Thomas, I give up. As the question to Geoff.
I had noticed the same issue with excessive wakeups in a helper app I am currently working on.
Until the bug is fixed perhaps the easiest solution would be for Xojo to make available a patched dylib that we could use in place of the buggy one.
Michel: I was right - Geoff means that patching of their code in memory is not allowed, either.
Richard: I highly doubt they’ll do that as they’re overburdened with fixing other bugs already, anyway. And it’s not like this is a severe issue, it’s just an annoying one.
Damn, I had just added a longer comment to my previous one, explaining how to make this work with the fix, and when I clicked the “post” button, it told me that I had no permission, and my edit was gone. Oh, screw this forum.
Really ? I would love to read it from the horse’s mouth. Geoff ? Care to chime in ?