Again I kind of like Bill's story about the history of a compiler. On the other hand there are occasions when variable name in MBX is something else but the one user defined. One is in a case of module-level dims (defined outside procedure) that seem to disappear. Other sample of intentional modification of variable convention is a case of MapBasic internal variables that are created by the compiler for certain MB structures (Do... Case for example). It really would have been a minor job to at least to drop the names which is not necessity for machine-readability, but it was not done. I still claim that it was ment to be MBX to be decompilable... Obfuscator is but a beautiful idea. On the other hand adding it to wish list isn't probably that successful. This is just one example of not developing the development environment. Unability I refered earlier is another. I haven't been around long enough, but Bill I assume, you have seen the same functionality since the very beginning. People are still using version 4 compilers, since the investment is worth only if one wants tu use a couple of new functions that appear in newer versions. Pretty sick, don't you think? Anssi ========================================================= >The biggest problem rises, because I guess MBX file was in a first place ment >to be decompilable! It is really surprising that the compilation process only >looses the comments of the source code. As you know even the original >variable names, line numbers etc. remain in MBX's. > > No, it is the way it is because it's based on the ideas of Kemeny's BASIC compiler which was simply a tokenizer that prepared code for being interpreted on the fly. It's true that it doesn't create very secure code and a serious hacker with some knowledge of compiler construction can read it, but most people who use BASIC aren't able to read the binary version. Personally, I think it's best not to give a monkey the keys to the banana plantation, but a curious monkey would find such knowledge interesting and enlightning.
>So once you give information for compiling you actually open the gate other >way too. It's unavoidable drawback from this nearly looseless compiling. I >see the future of MB as a useful tool for creating UI, but I guess there is >still much more left. > >Have to reconsider the pros and cons. > > I guess I hadn't considered the possibility of being able to extend it by revealing how it works. There might be some value in that. But since the cat's out of the bag anyway I guess I should consider building a code obfuscator to be used as a pre-compiling step, just to make it harder for hackers to read the source code. That wouldn't be hard to do because MapBasic doesn't need to be "neat" and human readable. Simply changing all the function and variable names to things like x001, x002, etc. would make it a pain to read and understand. And once I saw the decompiler code, I could probably come up with other annoying tricks to make it more difficult for the black hat hackers and wannabes to understand what the code does. - Bill _______________________________________________ MapInfo-L mailing list [email protected] http://www.directionsmag.com/mailman/listinfo/mapinfo-l
