The user's type does'nt matter. The only important thing to me is to be able to have a 100% safe protection.

Here's what I think should be the perfect protection. A tool that goes throught a VFP project and does a replace of all the variables, function names, procedure names ... by a meaningless name.

A UT member mentioned that they did just that to protect their app. Too bad I don't remember the name of that member.

What do you think about that? That way we would'nt need other tools such as ReFox and KonXise. ReFox would still be needed for those that want to recuperate their source code but that's it.

There would still be a place for a tool like Armadillo because it's not only an encryption tool.

In your reply you said "...no sensible variable names...". Are you sure about that? If it's really the case then there's really no need for us to worry.



>Denis,
>
>Good points!
>
>You are suggesting (as I read it) that there really is a third kind of user: The user who knows almost nothing about hacking, but knows about a certain product, probably has a copy of it, or doesn't mind buying one, and uses it to circumvent the original developer. I agree that these users exist.
>
>Also you criticize MS for not providing better encryption for vfp. I agree here too and wish others would join us.
>
>About those certain products. I believe that the retrieved code will be terrible to read since there will be no comments and no sensible variable names. Am I correct here? I don't know about the contents of scx and vcx tables.
>
>
>><snip>
>>
>>>Okay, it appears we are now in a LOOP. There is one thing that bothers me here. You seem to think that I don't understand you or don't want to understand you. You seem to think that I don't have a point here. However, I think that I do have a point here.
>>>
>>>You are implicitly telling all readers: Hey, buy that external product!
>>>I am telling readers: Don't underestimate the efficiency of the native 'encryption' and don't overestimate the efficiency of those external products.
>>>
>>>To focus on your (c) of your abc: In my view there are only two kinds of users..
>>>1) Those who hack. Nothing really will stop them from succeeding.
>>>2) Those who don't hack. The external products are not more efficient here.
>>
>>Peter,
>>
>>I don't see Jos's mention of other products an incentive to buy one of them. But then again perhaps he has stock for those companies <g>.
>>
>>In the end I want to have all the information needed to make a wise decision.
>>
>>Perhaps my perception is naive but if these products exists there must be a good reason. I think that the majority of fox developer knows that ReFox can decompile a VFP app. So just here there's a big problem. XiTech is practically forcing us to buy ReFox to protect ourselves against ReFox <g>
>>
>>I have a bad habit of trusting people. These days that proves to be something really risky. An example : I developed an app for a company. My app was'nt protected with ReFox or any other product. One day I met the I.T. director and I saw written on a pad "ReFox". I was shocked for a minute. Guess what? I have'nt worked on that app for a while. Hmmm I guess that ReFox could be to partly to blame here.
>>
>>I will never buy ReFox. I don't like the way these guys are earning money. Scare developers by making a product that gets the source code of their app but at the same time protect their apps from the product they're making. Am I the only one that thinks this business plan is really weird?
>>
>>Thank god there are alternatives to ReFox.
>>
>>But in the end the problem begins at MS. THEY should be made responsible for making a product so weak in terms of security of the source code. I just hope that I won't get an OFFICIAL reply telling how hard it would be to protect the source code. That would be a load of crap. It's not like they ever tried something to protect our source code. I guess that they don't take our work very seriously.
>>
>>But VFP is not the only product with that deficieny. .Net also has problems in that area. But the nice thing in .Net is that this should be corrected soon if its not already been taken care of.
>>
>>So that leaves us to poor old VFP (black sheep). But don't despair I heard that there are plans in the future to do something after VFP9. Not a major version but something and then there could be other things following. Oooh with that much precision I can get on with development for the next 10 years in VFP knowing that the product is well taken care of <vbg>