For security reasons a customer is asking us if we could build a version of his executable which contains no references to procedure names we use in the code. At first I thought this was relatively easy and could be achieved by not building using Debug Information.
Sadly ... when opening the EXE using a text editor like NotePad, we are still able to see a lot of information if our EXE. Especially procedure names which are public. I thought that without debug information all this would be obfuscated.
Now I'm wondering if there is an easy way to achieve this. Build my EXE which has no references to procedure names.
Any suggestion is welcome.
You can include following compiler directive in units you don't want to emit extended RTTI information, and leave only RTTI for published properties, fields and methods that are usually used by streaming or other RTTI based mechanisms.
{$RTTI EXPLICIT METHODS([vcPublished]) PROPERTIES([vcPublished]) FIELDS([vcPublished])}
However, that will not obfuscate class names and will leave RTL/VCL/FMX RTII information intact.
Any suggestion is welcome.
Embed a web browser in the main form and move all code to a web application. Then launch the web app home page in your Delphi program. Try to use notepad now - and Bingo. :)
Related
I have deveoped a custom file type, together with a custom editor (basically a tree with several data pages attached and a few extra buttons). OK, I can run it stand alone and that is fine, and even add it to the tools menu, but I would like to integrate it into the Delphi IDE so that my custom editor (or a similar new version) appears in the IDE, rather like a DFM file has a custom editor. I can find references to most extensions in the Delphi IDE, but not this one. Any guiding hands? Note that this is not a property or component editor (the file type has nothing to do with either of these) nor is it simply syntax highlighting of a text file.
AFAIK it currently isn't possible to reliably integrate a custom editor into the Delphi IDE. The required API simply isn't there. See QC89028 Custom Module support.
During the Delphi 2010 and XE betas I spent most my spare time trying to get a resource editor integrated. Although the effort had the official blessing of Embarcadero and got some, half hearted, support from the IDE engineer, I was never able to get them to deliver on their promises and surface the module API. I eventually abandoned the project.
Update: I've now checked my old correspondence regarding this and it turns out part of the problem was that IOTAModuleCreator (used to implement File|New for custom file types) and IOTAEditorContent (used to transfer data to/from the custom module) only supports text data. Binary data gets mangled.
You can probably do this via an IDE plugin that uses the ToolsAPI (see ToolsAPI.pas in the IDE's source folder (e.g. Program Files (x86)\Embarcadero\Studio\source\ToolsAPI\ToolsAPI.pas.)
For information on writing a plugin in general, see David G Hoyle's excellent blog. Once you know the basics - i.e., write a 'wizard' and get it to do something - you will need to work on integrating your editor.
I have never done this, and so I can't guarantee it is possible. However, some interfaces that look worth investigating and implementing are INTACustomEditorView, which represents a 'view' (file tab when that file is open - think the code editor, Welcome view, type library editor, etc) and IOTAEditorViewServices, to register your custom view. I do not know how you associate a view type with a file type, sorry - possibly something to do with the personality interfaces. You might also be interested in INTACustomEditorSubView which is what creates a tab on the bottom of a file.
Good luck, and if you find a solution please write here so that other people can learn too!
I have a few scripts that I would like my program to work with. However, I would like to know if it is possible for me to store these scripts (eg. batch, javascript, vb scripts etc) in my application as a resource.
How would I go about doing this?
You can store your scripts in resource files. But for example Batch Files need to be file on disk, so you will need to unpack them before working.
There are components to store arbitrary file/files or string in DFM
For example there are such in rxLib/JediVCL but i believe many VCL libs have one or another kind of DFM Storage component.
For example i used to store Firebird Embedded database in DFM to save it into TEMP and use while running.
However that is akin for manual re-reading file into DFM each time you update it. Rather annoying to say sincerely.
One more approach is linking text into resources. You can look into DUnit sources to see how it was done. You would also have .rc file included in project, so that it would be compiler into .res when making .exe
This approach is fragile towards ansi/unicode text interpretations.
Frankly, before i found DUnit in Delphi XE2 (it was disabled due to IDE bug) i tried to make SF's vanilla DUnit to run there. And i failed - the non-unicode text files linked into resource was totally corrupt when reading with unicode-enabled Delphi.
Look here and there, try both approaches and choose the one that suits you more.
Here is a good article that explains how you can add almost anything in a resource file and compile it with your application: http://delphi.about.com/od/objectpascalide/a/embed_resources.htm
I tried to copy and paste a component from one data module into another in Delphi XE2. The component was a Fast Report data source link component. The data module was brand new, just created that second, in XE2.
Someone else had the same problem and reported it on quality central as 106369 and same error message leading me to this mysterious DocWiki entry.
So data modules now have a framework affinity, and a designtime-only pseudo property, which according to the docs:
"Because the ClassGroup pseudo-property is used only by the IDE and is not a compiler-generated property (hence, 'pseudo-property'), ClassGroup is not documented in the compiler-generated Libraries Reference. The page you are reading is the documentation for ClassGroup."
So, the first time I even learn this exists is when it blocks me from copy and pasting components into my data module from an existing set of designtime building blocks that I didn't wish to rebuild from scratch.
Once I change the data module affinity, I can paste stuff into data modules without it bugging me. Thank goodness for Google-that-error or I'd be stuck.
If it is intended to help us write cross platform data modules, and yet it only affects the IDE, according to the documentation, that's inconsistent with the warning that you get when you play with this at designtime, here's the error you get if you change it:
EInvalidType : The following component(s) are not available in the specified
class group. This is likely to cause compile or runtime errors.
frxDBSet.TfrxDBDataset.
What I can't see is how that error message can be correct, and the documentation can also be correct.
The warnings seem to suggest compile, link, and runtime errors if this is set incorrectly. Curious minds who want to know what's really going on, want to know: What is this thing about and why did it get added to the data modules in XE2. I anticipate other people will stumble upon this weird feature, with the feeling that they've stepped in something like dinosaur droppings, and want to know what is up with this feature.
My best answer at this point is that a data module affinity for TPersistent which means, in XE2 lingo, that this data module doesn't want non-visual controls in it, that are VCL-specific. In a future version of Delphi, perhaps a similar marker would allow us to mark forms as being "clean of dependencies on the VCL or windows" too?
Update 1: The .PAS source code of your data module stores this pseudo-property in a way that looks a bit like a compiler directive, like this:
implementation
{%CLASSGROUP 'Vcl.Controls.TControl'}
I think it is pretty obviously what its intended use is for, and the documentation you link to is pretty extensive about that purpose.
It is meant to prevent VCL-only components from being placed on a FireMonkey-accessible DataModule, and vice versa.
Since TDataModule is initially framework-neutral, only framework-neutral components can be placed on it.
So obviously, your source DataModule has a different affinity than your new DataModule, which is why copy/paste does not work until you change the affinity of the new DataModule to match the affinity of the source DataModule.
At the moment, whenever I need a custom dialog, however simple, I use Delphi's form designer to create a new dialog form. The form is then wrapped in an easy to use ShowMessage() type function.
In some situations it would be easier if forms could be created at run-time from a script. The script would detail all form components and their properties, much like Delphi's .DFM files.
Creating GUIs from scripts could be useful in other situations as well. For example, a GUI of a mini application could be embedded into the window of an existing application. Or the GUI script could be modified at run-time to create GUI variations.
I could create something to do this myself, but I assume other people have already tackled this problem. However I can't find anything using google. Is there anything currently available offering this kind of functionality? (Free or otherwise) Or does it already exist in Delphi?
Check out some of the scripting solutions for Delphi. For example, the TMS Scripting Studio, dwScript, RemObject's, FastScript, etc. I believe some of them are able to use DFM's for this purpose.
http://www.torry.net/pages.php?id=280 Delphin v.1.21, it can process DFM files, maybe you just want the DFM to code converter.
You might try XI Library (commercial): http://xilib.com/
I have never used it, it's just something sitting in my bookmarks, but it looks like it fits the bill. Not a scripting engine, more of a way to define dialog boxes via XML. There's sample XML code right on the front page, just click "Show the example".
What is the best way to implement an external module system for a DELPHI application?
What I need is very basic really:
The main APP detects if a module is present and loads it(Run time)
Modules can store form
Modules can store DataModules
Modules can Store code
I need the use the store forms inside other forms, and only as a standAlone
I use something like this
if Assigned(pNewClass) then begin
Application.CreateForm(pNewClass, _lFrm);
_lFrm.Hide;
_lFrm.BorderStyle := bsNone;
_lFrm.Parent := pBasePNL //(TPanel);
_lFrm.Align := alClient;
end;
So I create a TForm, but place it inside a TPanel.
As for DataModules I usally store ImageLists so the ideia is to change the app ICOs just bit changing the external module.
So what is the best way to achieve this?
Looked at runtime BPLs but don’t seem to understand how to do it.
Thanks.
UPDATE : .....................................
After reading some related question and answers i think I found my answer and solution.
http://edn.embarcadero.com/article/27178
The article is old stuff but amazingly simple.
Well the logic is there I just don’t seem to get it to Show the forms
I am just testing example 2
It loads the BPL, but doesn’t get the Form:
AClass := GetClass('TForm2');
Always retrievex ‘nil’
But the BPL as it registered:
RegisterClass(TForm2);
Can anyone help with this one.
Packages are an easy solution but they have one huge drawback. Using packages forces plugin authors to use not only Delphi, but the same version of the compiler as you do.
I personally would prefer to expose the functionality of the app through a number of interfaces. This allows accessibility from languages other than Delphi.
Typically the plugin would be implemented in a DLL and would export a function that the app would call to pass in the root interface representing the app. The plugin would then call methods of that interface thus establishing two-way interaction.
I made you a demo, it's so easy to get started! However... Started is not finished.
Every time I started using plugins, I later regretted it. However, as you say, you want a binary plugin system. So BPLs are the correct solution. David suggests using interfaces (with plain DLLs instead of the full runtime package BPL) and this would solve some of the commonly encountered BPL-instability problems due to not versioning your classes, and thus your Application-and-package-binary-compatibility dependencies, properly. If you do not need to share memory and do not need to use borlandmm.dll (shared memory management) then a straight DLL with interfaces will work fine.
If you can do everything you need to do with just scripting, and make your plugin system with just scripts, then do it that way. If you can get away with DLLs, interfaces, and no memory sharing, then use plain DLLs. If you must share Memory and class types, then yes, use BPLs.
Beware that using BPLs (Runtime Packages) comes with a lot of side effects you might not have been expecting. The largest BPL-based applications I have worked on have been more of a mess, and less stable, than any monolithic apps I have worked on. It seems that it is only possible to pine for packages until you try them, and then I find, I pine for monoliths again.
If you use BPL packages correctly, and you version your plugins properly, everything is fine. BPLs are great. But in the real world, it seems that sane versioning and ABI compatibility and interoperability, and stability are at a premium.
Update: I made you a demo it's here (plugin_r2.zip). It was done in Delphi XE, but if you are using an older version of delphi, you just delete the .dproj files and open the .dpr file for the main app, and the .dpk for the package.