“You agree not to decompile, reverse engineer or modify any part of the Xojo IDE or the Xojo Framework.” We don’t specify on disk or in memory- it’s stated simply on purpose. If you were to change a binary framework file- that means you would have had to reverse engineer it in some fashion as well.
There are several reasons we make that statement. Piracy obviously isn’t the concern in this particular context. But you might be surprised how many support issues are caused by someone creating a framework patch/hack and distributing it publicly. Not just because they may not realize the cascading effect it has on other pieces, but those kinds of things will certainly break in another version of Xojo- and we’re the ones who get the support calls about it- it makes it difficult.
Of course there will always be some people who would do something like an in-memory change for their own use- if things break for them, we can’t support it. Technically against the agreement, but we may never even hear about it. What we really do not want is public discussion of changing binary frameworks in violation of the agreement- and then have people who tried it wonder why something seemingly unrelated broke, and asking us to support it.
OK. This makes sense. Most every software publisher has provisions against modification of its files or their reverse engineering.
Outright patch of the memory image of these files, as unverifiable as it may be once it happens in the confines of one’s app, is indeed a breach. I may add that it is a technique that has fallen in disgrace years ago as it is typical of the kind of thing malware would do. Not so sure digital signature would not prevent it anyway.
I makes sense also not to support on disk or in memory patches that can break apps and generate support requests for self-inflicted bugs.
In the case of this wakeup thing that started it all, though, let us forget the horrid and forbidden dylib modification practiced by Thomas in a moment of temporary loss of sanity.
Now I know Joe is aware of the issue and will probably mitigate it in a coming release.
In the meantime, the only “clean” solution would seem to be to find out which call is made too often, intercept its vector, and suppress some of the requests. Of course, it is a lot more involved than a quick and dirty patch.
This also explains an issue that I kept running into as I use a LOT of async shells in my apps when testing high loads during the 10.11 beta cycles. Since I didn’t see it in prior OS releases, I just chalked it up to another addition to the iOS-ification of OS X.
I don’t suppose you have any project that is sensitive to the throughput of async or interactive shells, or just a project that tests throughput? I’d prefer not to inadvertently make things worse for those use cases.
Gr… I’m seeing this, too, in the old version of my app that is using the shell to communicate with Python. No wonder that this puked for some customers at some point of time.
@Joe: I even should have a test version for this already available. Do you want to have a look?
Well, if I understand it correctly then Thomas identified the problem and the solution, which is to set a timer from 1 ms to a lower frequency. I would really be surprised if this could not be fixed quickly then. Only question is if it warrants a point release (which I think it does when it prevents your app from getting into the app store) or wether we have to wait for the next major release