I've received source code for a utility I want to adapt, but it appears to have the .dfm files stored in binary format, and one of the .dfm files seems to be coRruPted.
I also have the compiled .exe file.
Is there any way to extract the form from the .exe?
I can see from the relevant .pas file the form type declaration and the components on the form. How do I go about recreating the form from scratch, and 'attaching' it to the original .pas file?
Try using XN Resource Editor to recover the DFM from the .exe.
Related
I have all the files needed to open the unit and code but I can't make any changes or compile because the Project.dproj and Project.dpr files are missing. However, I have the .exe file. Is there any way by which the aforementioned files can be extracted from the .exe file?
If you have all of the source files, meaning the .pas and .dfm files, then the first thing I'd do is add them all into a new project and try to compile it. It'll either work, meaning you've got everything you need, or it will generate errors.
There would be three kinds of errors:
The first is the most likely -- the forms might use components that you don't have installed. This will be obivous if you try to open the forms in the IDE. If they open without fanfare, GREAT! If you get a warning box saying "Cannot locate component: remove references to it?" or something like that, then you're probably hosed.
The second is version-specific errors -- stuff that's old and crufty and no longer supported by the language.
Third, the program may use run-time libraries that you don't have.
The compiler adds RTTI metadata, including unit names, when it builds, and if you know about how the RTTI tables are laid out it's possible to extract this. The unit list is the principal component of the DPR file, but it takes some serious work to access it and I'm not aware of any tools out there that read the RTTI tables that have been kept up to date beyond the Delphi 7 era.
As for the .dproj file, you're out of luck. That doesn't actually contain any code that gets "compiled in" to the EXE; it's a set of build instructions for how to produce the EXE. But if the Delphi IDE doesn't have one, it can generate a default .dproj from the .dpr, if you can produce that.
I'm curious, though. How did you obtain the .pas files but not the .dpr?
While double clicking the pas file to open it in Delphi XE4 IDE, I am getting this error:
XML Parse Error:
Reason: The system cannot locate the object specified
This file uses xmldom, XMLIntf, oxmldom, XMLDoc units in its uses clause. I have changed nothing in this file and this opens up with no error in Delphi 7, but in Delphi XE4, its throwing above error when I double click .pas file to open it in IDE. After pressing OK, the .dfm file opens up.
Opening the .pas and .dfm files does not involve XML parsing. The fact that your unit uses some XML related units also does not involve parsing of XML at unit load time.
So this sounds like the IDE has a problem opening some auxiliary file associated with the source file. And something about this file or its reference in the source has not survived the transition from XE4. Look for files with the same stem as the troublesome source unit, but a different extension. Or look for IDE generated {...} comments in the source unit that refer to auxiliary files. This should hopefully lead you to a solution.
i want to import exe file into my delphi application resources.
and then extract and run the exe.
my qustion is:
how can i:
Import exe file into my resources
Extract exe file into "c:\" (with SaveToFile function)
Run (Shell exeFilePath) the exe.
See this answer for an example how to include an file as a resource to your app. The example there is for a text file but it is the same idea for the exe file. It also shows you how to load that resource into an TResourceStream and then you just use it's SaveToFile method to save the exe to the disc. Once you have the exe on the disc you can run it with ie CreateProcess.
there are component libraries allow you tou store your file on the from, inside DFMs
For example if installed JediVCL you can drop the TJvDataEmbedded component onto the TDataModule or TForm and load a file into it. Then in the runtime you can extract that file onto disk or into TMemoryStream.
About running - the most simple thing would be to call ShellExecute function - read your Delphi help about it. Or you can use the class from Jedi CodeLib which allow you a lot of customizations. But you probably do not need it.
I have a delphi project that somehow has become corrupted. I upgraded to Advantage 11.1 components (using XE) and now I'm getting the following error message when opening the project:
acctTbl: Error 5018: The handle given was not recognized by
Advantage. Verify specified handle is open/active. The given handle
is not recognized as a valid Advantage Client Engine
Because the error occurs, the data module DFM is not built, so I can't "adjust" any settings.
acctTbl is the first table in the DFM, so the error might occur for the ones following, but I can't tell.
We are not using the server, just the "Local Server".
I have tried to go back to version 10 of the components, but still the error continues.
I have also tried removing all of the projects object code and only opening the PAS and DFM files (by reverting from SVN).
Any help is greatly appreciated.
You can open the .dfm in a text editor (like Notepad), and change the AdsConnection.Connected property to false, and change any AdsTable or ADSQuery component's Active flags to false as well. (I'd suggest closing the IDE first, to make sure it doesn't cache a reference.) This will at least let you open the project and make whatever changes are needed to compile with the new version of ADS.
If the file has been updated through many older versions of Delphi prior to XE, there's a chance you still have a binary format .dfm file (meaning you'll see all kinds of strange symbols in Notepad when you open the .dfm file). If that's the case, Delphi includes a conversion utility (convert.exe, found in your $(DELPHI)\Bin folder), and you can use the following steps to convert it to text format and then make the changes (there's no need to convert it back after - the default is to create text .dfm files when new forms are created, and Delphi uses them very well as text).
Make a backup copy of your datamodule's .DFM somewhere safe first!
After making the backup copy, open a command window in your project folder, and run
Convert.exe -1 YourDataModule.dfm
The command says to convert in place (-i), which means the existing binary .dfm is overwritten by the new text .dfm (and the reason I stressed making a backup copy first). If you don't want to overwrite, you can omit the -i switch, and it will create a YourDataModule.txt file in the folder instead; you can then manually rename YourDataModule.dfm to a different name, and then rename YourDataModule.txt to YourDataModule.dfm.
All exes compiled can be decompiled (but with some hardship )
but delphi application forms are saved as dfms inside exe which can be seen easily (with reshacker) (soooo easily ) can i overcome these problems ,first i thought of copying dfm data to oncreate procedure so i can hide my form information .
tell me a good solution for this ,
i do not like to use compressors
and my application is bit large so i cant port resourese one by one to a dll. i need an effective solution.
.dfm files are not stored as txt when they're linked into the final PE file. They are converted to a tagged binary format that is placed into an RCDATA Windows resource. For the images, they are stored as the raw binary. While building your application, the .dfm files can be stored as text or binary (right click the form designer and there is a selection for choosing one or the other). This only affects the format of the .dfm file itself. It has zero affect on its format once it is linked into your final binary.
You can try to convert the images to constant arrays (there are many tools that will read a binary and write out an array decl in various language formats) and use it as an include file. Another thing is to encrypt the images using a one-way algorithm like RSA or PGP. This won't keep someone from decrypting the image, but it will keep someone from replacing it since they won't have the private key.
If this is about protecting your applications images you are already on the losing side:
https://stackoverflow.com/questions/455623/how-can-i-prevent-users-from-taking-screenshots-of-my-application-window
It is always possible to make screenshots of a running application.