>Is obfuscating Turbo Pascal source code a "safe" way of securing
>code ....?
>If it is, perhaps if we write/get one, we can get convince s/w
>publishers to release obfuscated code, rather than TPU's, or
>better still, get Borland to put the code for one in BP8, so this
>problem doesn't continue. Any comments?
I think that you are much better off with open source code than with .TPU
files or obfuscated source. When you find bugs or need to make
changes because conditions have changed, you can do the fixes. You won't be
relying on someone who may have gone out of business or lost interest in
the code.
If I can possibly help it, I don't use code when the source is unavailable.
The only exceptions I make are for units that ship with the compiler, and
I'm unhappy about those.
Duncan Murdoch
dmur...@mast.queensu.ca
>Is obfuscating Turbo Pascal source code a "safe" way of securing
>code, where any "humanised" names (variables, procedures etc)
>are replaced with random numbers, white space is removed, code
>portions are moved etc? The result is a program that compiles, but
>is essentially unreadable. Such that a very simple 100 line program
>becomes a mammoth 5 hour effort to convert back again?
>If it is, perhaps if we write/get one, we can get convince s/w
>publishers to release obfuscated code, rather than TPU's, or
>better still, get Borland to put the code for one in BP8, so this
>problem doesn't continue. Any comments?
I doubt that it would require 5 hours to figure out 100 lines, since a
pretty printing program could restore all of the program structure very
quickly. However, having nonsense variables and procedure/function names
would certainly secure any very long section of code (maybe a few hundred
lines and up) from all but the most determined.
The problem with this is: the raison d'etre for source code libraries is
exactly so that users **can** figure out what is going on (in inherited
methods, for instance).
If the *only* compatibility problem with the units is that the unit object
structure has changed, then the vendor should simply compile and provide new
units. However, in my experience, the unit problem is usually related to
other language items that have changed significantly, and some *re-writing*
of the unit code is needed (say, by altering the parameter types to be Pchar
instead of strings, or some new disk structure type).
If you're dealing with obfuscated code, then these simple re-writes will be
impossible.
The best solution, IMHO, would be for users to demand source code from unit
providers -- or to demand that the language stop evolving, which none of us
really wants ...
-- chris
-- cc...@bongo.cc.utexas.edu
It certainly isn't safe.
>If it is, perhaps if we write/get one, we can get convince s/w
>publishers to release obfuscated code, rather than TPU's, or
>better still, get Borland to put the code for one in BP8, so this
>problem doesn't continue. Any comments?
I have in the past used units that have been downloaded from various
BBS's that have been through this process, there is a shareware (I think)
program called Mangler that will convert source code.
As an exercise I wrote a program to take a mangled source file and
convert it back into a readable program.
While Mangler makes it dificult to read code, it certainly does not
make it impossible.
I would prefer to see an option to partly compile a unit, so that a
user could download this file and then the compiler would complete
the compilation into whichever version was being used.
I know this won't help for the huge amount of TP3-6 code that is
available, but it will clear up the problem in the long term.
Louise
------
I think as good, or better a question that I've never had answered to my
satisfaction is why should an upgrade to the language necessarily break the
older units? Presumably most of the changes from version to version are of
the "Superset" type (i.e. the new features are additions to the language, not
changes in how what's already there works), how hard would it be for the
compiler to detect the unit version and call it accordingly?
Inquiring minds want to know.
-* Stephen *-
Stephen Posey
S...@uno.edu
University of New Orleans
>I think as good, or better a question that I've never had answered to my
>satisfaction is why should an upgrade to the language necessarily break the
>older units?
TPU files aren't independent entities like .OBJ files are. They are already
linked to each other. Your TP 6 .TPU file has already been linked
to the TP 6 System unit. (Code isn't copied, but the .TPU contains hard
coded file offsets from the System.TPU file.) The BP 7 System unit has more
in it, and things are in different places, so the links from your old .TPU
don't work.
It probably wouldn't be too hard to write a new linker that would link TP 6
units to BP 7 units, but each would have its own copy of System, and those
would almost certainly clash with each other so your program wouldn't work.
It's probably possible to write a program to take a TP 6 unit, unlink it
from the TP 6 libraries, figure out corresponding parts of BP 7 for all
those external references, and rewrite it as a BP 7 unit linked to BP 7
libraries. But that's a *lot* more work, and so far nobody has felt like
wasting their time on it.
Duncan Murdoch
Rob
--
Do not let penguins embarrass you if they happen to drop in when you
are just sitting down to dinner. Evening dress is quite optional in
Arctic Circles. Sellar and Yeatman
Rob Heyes r...@brewster.demon.co.uk, rhe...@cix.compulink.co.uk