Names of classes stored in executables

After reading on the website for Arbed, I saw it said they are planning ‘Code obfuscation’. Does this mean that when Xojo is compiled, the names of variables, classes, modules, etc, all of the names of the methods are stored as string. Wouldn’t it be more efficient and wouldn’t the app run faster if all of the methods where numbered or have I

You have.

Oliver, the names are only used to set up references between functions when a program gets loaded. Once these refs are resolved, the code uses pointers and doesn’t have to look them up any more. Once the program runs, they’re not needed any more (unless you play with some of the advanced low level features such as introspection or when patching a function because it’s buggy).

How would you go about “patching” a function?

Or how would you know what function to patch ?

Maybe this and this ?

Ask Joe, he can explain it better :slight_smile:

BTW, this is getting riduculous about the “no reverse engineering” requirement. If you want to tell your users they are not even allowed to fix bugs in your code if you can’t fix them yourselves, please say to clearly. They’ll love it.

Just wanted you to admit that yet again you’ve violated he EULA.
If honoring an EULA is an issue you should probably take it up with Geoff.

Also, I’ve patched out functions that caused trouble in my own app. I found out those functions when I traced thru my own code and ran into the troublesome function of the rb library. So, are you telling me that I may step thru my own code but when I step into a subroutine that’s part of the RB lib, I have to stop debugging my app? And just give up?

You seem to be forgetting that you’re catering a tool to programmers here. Programmers can look at code and understand it by their nature. Telling us to blindfold and ignore bugs in your code and just give up is riduculous.

Besides, when I talked about patching above, I talked about patching lib functions from Apple’s libs. Apple has no problem with that, BTW.

So the EULA is meaningless to you ?
Just curious as to what other legal agreements you choose to ignore ?

[quote=47591:@Norman Palardy]Just curious as to what other legal agreements you choose to ignore ?

To be fair to Thomas, these are contractual requirements, not legal requirements, and there is a difference. However, considering the amount and scope of explicit and implicit support provided to each user who interacts on the forums, in Feedback, and other support channels, it would certainly be reasonable to demand a premium to cover support time and effort that most surely results from some users patching things, not disclosing their patches, and not compensating the support people for the extra effort needed to understand how a patch might interact with other code. Which is the reason that a contractual prohibition against such patching is entirely reasonable.

I should have written [quote=47591:@Norman Palardy]Just curious as to what other legally enforceable agreements you choose to ignore ?[/quote]

The other half of the question is this: why would Xojo continue to enter into contracts with a customer who routinely violates them?

isn’t the whole reverse engineering thing about making a competing product? Just patching bugs for non competing apps one produces using Xojo, as long as they don’t distribute the patches or patched version of xojo, it shouldn’t be a problems, no? Logically I don’t see how that would damage Xojo in any way as long as they don’t demand support for their patches… But I also coudl see suc detailed bug reports could be very helpful.

I know Thomas tends to rub people the wrong way, and has the whole 12+ years I have been in this community, but in general IMO he has contributed significantly to it.

I don’t see a problem here, too.
If we search for bugs, we often end up in a low level debugger to find the bug. Whether it’s in our code, xojo runtime, Apple’s frameworks or Microsoft’s DLLs. And sometimes it turns out that when we know the cause of a bug, we can work around.
For example case 28050. It’s simply the assignment of a Integer to a Int16 which cuts away one bit.
I’d love to help to fix that but how?
Yes, we can patch the instruction or write our own replacement code. But I’d rather love to see Xojo engineers fix it.

If wonder how Xojo would like it if I removed these “illegally” determined fixes in the next version of my apps such as Find Any File, and told me users that, sorry, I had to undo these fixes because I am not allowed to know how to fix them, and so users should please live with a buggy FAF for now, and not give any second thought towards Xojo enforcing this.

Their is a reason the EULA prohibits this. Patching can potentially create extra unnecessary work for us. When you patch the framework, you can’t be sure you haven’t just created other bugs. When you encounter one, you report it to us and even provide a simple project that reproduces it. But we can’t reproduce it. Why? Because unbeknownst to us, we are using a different framework than you are. The result is that we waste time trying to reproduce a bug that we will never be able to reproduce.

If you find a bug, don’t patch it, report it.

… and wait months or forever if Xojo decides not to act on it.

(and, of course, the case where I had to patch some function out was indeed reported to RS and never fixed. Go figure!)

I don’t like to continuously be made the one who violates an EULA that gives us all the penalties but no rights if Xojo doesn’t comply with fixes in return. It’s not me who is a fault here, it’s Xojo’s bugs. And I shall suffer for that instead of fixing it myself??