>>So it's not cut-and-paste code; whatever. What one is usually after are the algorithms, not code you can paste directly into an editor. Any number of today's reverse engineering tools will get you at least that far, and some of the Delphi decompilers will get you just shy of cut-and-paste code.

I disagree; in my experience, "algorithms" weren't the issue. It was the ripping off of entire apps, with only a few "cosmetic" changes made.

>>Visual dBase seems to be relatively secure compared to VFP;
>
>How so? Is it truly more secure, or is the user base so small that no one bothered to write the equivalent of ReFox for dBase? If it compiles to genuine machine code, you could be right. If it's tokenized, it may still be easy to crack.

It's not machine code, and I could not find any decompilers. The rest is speculation.

>> MS doesn't even have the will to "try".
>
>Considering that this is the first time I've heard anyone make a big deal out of not having native strong encryption, I don't think it's a question of whether or not Microsoft wants to implement it.

I thought the problem was obvious ... but then again, only some of us think of it as a problem.

>>The cost of ReFox was about four hours of billable time for me. Hey, I feel for the "little guy", I used to be one, but to me it was just the cost of doing business.

I don't like extortion.

In any event, someone on UT already pointed out that they cracked the ReFox branding.

>>I can't see why MS cannot "tweek" the encryption process so that at least it isn't so easy for ReFox to stay "current".
>
>Oh, it could be arranged such that we lock out decompilers completely (well, not quite, obviously). Personally, I'd like the ReFox folks to stay in business.

[bites lip]

>>Besides, I can't tell you how many clients I've bailed out with ReFox. From a consultant point of view, I'm not sure I'd want Microsoft to change the encryption. There are just too many clients out there w/o source code, and the original developer is no longer around, got hit by a bus, or whatever.

Your loyalties are in the wrong place; I'd prefer to see MS provide the ability/service to recover code (when it was necessary).

The fact is that there are any number of ways to distribute a VFP app; some of which do not include encryption and would allow for decompiling.

At some point, a developer should be able to commit to a particular "level" that impedes decompilation (IMO).

If your "clients" have a "legitimate" VFP app that they presumably own the rights to, why are the encrypting it in the first place ? And the "bus" argument doesn't fly if everyone is dealing above board to start with. If I really wanted to screw you, I'd throw in a couple of C DLLs and "lose" the source to that.

When a programmer "walks", it's usually because they got stiffed on an invoice ... and then my sympathies wouldn't be with the client.

>>I'm open to arguments about why this should change, but you'll have a tough sell on your hands. Sure, there are lots of arguments on the pro side, but there's a lot of downside, too.

I develop commercial (application) software; I don't expect any sympathy unless it's from someone in the same boat. We have enough problems dealing with "reviewers" that point out our stuff isn't written in C++ or VB and therefore must somehow be "inferior".

Who am I to think that my software is as "special" as the stuff that MS thinks to protect ("Gee ... I've lost the source to my Operating System ...").