Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations John Tel on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Hacking source code out of EXE 1

Status
Not open for further replies.

chpicker

Programmer
Apr 10, 2001
1,316
Wow...

I remembered seeing something awhile back about deleting all PRG files and hacking your SCX, VCX, FRX, etc. files to remove the source code from them when building your final EXE file. This is because the uncompiled source code gets included in the EXE file if you don't do this, which is a nasty security loophole if I ever saw one.

I finished my project tonight, so I decided to give it a try. After making a backup copy, I opened up all of my forms, etc. and BLANKed the Methods field in all records. I deleted all PRG files. I stripped the print driver info from my reports.

My final EXE file was less than 1/4 its original size! 802k reduced to 190k! I still need to test it thoroughly to make sure it is still fully functional, but wow.

So, why am I posting this, you ask? Well, there doesn't seem to be an FAQ about this, and I was wondering if anyone with more experience than me would be willing to write one. This procedure is a TREMENDOUS help even if it's not really a Frequently Asked Question. I would post one if I thought I could do so without forgetting anything. However, I don't think I know all the parts to this.

Any takers?

Ian
 
It's always the big debate. On one hand we (as programmers) scream at the fact that there is barely any documentation on automating things like Outlook and Word, yet once we figure it out we feel the need to "hide" this from our client. We request large software manufacturer to change to a more "open source" and allows us to "see" to way they did it so we can duplicate it.
Personnaly if I feel the need to "hide" specific functions, I may consider to put them in a DLL instead, but I usually develop for clients that want to use the product I supply more than trying to decompile it.
 
chpicker,

I'm with you on this one. When you have put in the time and effort to develope a package with some innovative tecniques, why should you hand it to someone who is hell bent on cutting you out of compensation for your work? I have heard of ReFox but this does not seem to me to be the real solution to the problem. What I would consider a 'solution' is to create a 'pure' exe without soucre code. Since I don't have the answer, this is still an open issue for me.

Thanks chpicker for starting a dialog on what I would consider a real problem.

WJS
 
This article is incomplete: It only highlights the way to "Turn Debug Info Off" in the project options.

I believe chpicker is right that by deleting the code from the memo fields of the VCX/VCT, SCX/SCT, etc, you can reduce size even further. It also disables the ability for error processing routines to report the source code for the line that fails.
 
You are correct in that this article didn't give the "whole" story. I assumed that those who were interested would follow the links to the other articles, like:
- "PRB: Visual FoxPro Makes Bigger .EXE Files Than FoxPro 2.6 Did (Q131302)", which does describe claering out the VCT & SCT code.

Sorry for the confusion.

Rick
 
Hello Ian,

Don't know about you but I haven't seen the answer that makes my heart want to sing yet.

One question. If you deleted all the PRG files, how does your app run? I must be missing something. When I do a project, I put all source code (Including forms and reports) in a folder by themselves. Classes in a subfolder. Next I create a completely separate folder for the executable with the data folder structure under that. Then, compile the excutable to the executable folder. The distribution file contains the folder structure and files where the executable was placed.

I hope this explanation doesn't cause an undue amount of laughter from you that are more experienced at this than me. Well, unless you just like to laugh. My traing is strictly OJT and I'm the only teacher in the school. That's a real nightmare, but, such is reality.

WJS
 
I believe deleting the PRG's (and leave only the FXP's) does not reduce the total exe. But deleting the (not compiled) code from the VCX's and SCX etc does.

One other technique that I used, but this requires setting up a kind of framework that has certain programming rules, is to only use classes and prg's.

What I did in my CrownBase app, is to convert during the building process, all visual classes, to coded classes, using the class browser, put all classes in one big prg, also adding all other prg's/menu mpr's in this big PRG.
Compile it to one FXP.
In my exe there is only the main startup PRG included, and my global application class.

This caused my exe to be only 19 K and my FXP to be 283 K.

To establish this I used the project hook class.

Because I now only have two procedure files (my startup included in the exe and the fxp with all classes and procedures), the startup time of the exe can be reduced significantly, since I only have to issue:
SET CLASSLIB To mymainapplication classlib
SET PROCEDURE TO mybigProcedureFile

So my application only consists (besides the graphics and dbc's) of an EXE of 18K and an FXP of 283 K.

See also the link in my signature. [smarty]
Weedz (Edward W.F. Veld)
My private project:Download the CrownBase source code !!
 
WJS,

As you probably know, your .PRG files are simply a text file which you edit directly. When FoxPro executes your code, it first compiles it into a .FXP file. Once compiled, FoxPro doesn't even LOOK at the .PRG anymore (unless you have SET DEVELOPMENT ON in which case it looks to see if the .PRG has been modified).

I haven't tested Weedz's theory that PRGs don't affect your file size much. When you BUILD your EXE file, VFP complains that it can't find the PRGs, too. You have to hit Ignore to get past each one. However, the program still runs fine, because the FXP files are there and that's all the EXE actually uses.

I found it interesting that, in the link Rick provided above, it says: "The developer can eliminate the source code in the forms and class tables by opening the project and deselecting Debug Info in the Project Information dialog box." However, it doesn't actually seem to do this. *boggle*

In any case, as Rick also mentioned, the link for "Visual FoxPro Makes Bigger .EXE Files Than FoxPro 2.6 Did (Q131302)" does describe removing the Method code.

I'll be doing more experimenting with the process to see what does and what doesn't make a difference. With luck, I can do that soon, and I'll post my findings here. Anyone else who wishes to contribute is more than welcome! We are, after all, a tight community here :eek:)

Ian
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top