Related
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'm compiling my application with Delphi 2010. My problem (it may not be a problem for anybody else) is that when you open that EXE with any resource editor you can see RCDATA which holds forms data. I don't like an idea of my program being "exposed" so I want to ask you is there any trick to remove that information from EXE or encrypt it that nobody (at least from resource editor) can see it?
You may create your forms fully via source.
opposite: you can't use the form designer.
with gexperts you can convert existing forms to source.
encrypting and compressing is not a solution. when the app can load the resources a engineer can it do, too.
I have written a DFM compressor that works inside of the Delphi IDE to compress DFMs at compile time. It then decompresses them on the fly at runtime.
I sell it for $15 US and it comes with src.
It currently works with D7, D2006, D2007 and D2009. I don't own D2010 but I have recently gotten XE and I will be upgrading it and making it available for XE as well in the near future. If someone makes a request for XE, or even D2010 compatibility, I'll work to make that happen sooner.
It's called the DeForM System and can be found here.
I use it for a number of my personal projects.
You would need to modify VCL source code to teach form loader to take resources elsewhere. Also, compilation would require post-build step or stripping resources from the compiled EXE and moving them to a separate encrypted file (for example). All of this is manual work, I never heard of any automation for described tasks.
One thing you could do IF your forms are finalized (i.e. they won't be modified further) is take GExperts and use their Component To Code expert to create forms and their contents in runtime. But modification of such forms will require changes in code.
It actually just holds published property of the components you drop on your forms and the form itself (actually the content of DFM file for each form), not any source code. So even if somebody extracts that data, they can at most produce a form visually looking the same as your form, but none of the codes you wrote for the form.
One way to hide such data from resource editors is to build all the components you use in your form at runtime, not using the form designer. This way, the DFM resource will not contain their data. As far as I remember, there are tools which are able to receive a DFM file as input, and generate runtime code for component creations automatically (e.g. GExpert), so that you could copy\paste the code in your form's OnCreate event-handler.
Another option is to use an EXE compressor. A compressor will compress your EXE file so the content of the file will be changed and not usable until being decompressed. Tools like UPX can compress your EXE file and decompress it on the fly when you execute the EXE. Take note that using known compressors like UPX has the drawback that many cracking tools or crackers can detect them and automatically decompress the EXE before processing it. So if you need more security, you'd better go for custom compressors.
I haven't used it, but Citadel for Delphi does automatic compression and encryption of DFM resources in your EXE. It doesn't look like they've updated past Delphi 2009 yet, but it's exactly what you're looking for.
I release a single executable (.EXE) for a desktop program using Delphi 2009. I have no external DLLs or resources that I need for the program to run.
I use two components: LMD Innovative's ELPack and Sergey Tkachenko's TRichView that are compiled into my executable.
When I build my production version, using the "Release" build configuration, the executable file produced is 13,533 KB.
Prior to using Delphi 2009, I was using Delphi 4. The executable it produced was only 2,671 KB while incorporating the same two components and basically having the same code as my current version.
I do understand that Delphi 2009 is completely Unicode (which is the main reason why I upgraded), and being Unicode can cause up to a doubling of size. But this is about 5 times larger.
Is there a reason why my executable has to remain 5 times larger? Or are there some simple ways to cut down a significant chunk of the executable size?
Please note. Some people are answering with ways to compress the Delphi EXE. That is not what I am trying to do. I am trying to simply see why so much space is being used to remove what might not be necessary. If that is done, compression can still be done afterwards if so desired.
It really doesn't matter how big or small the executable is once it is installed. It is for downloading purposes and to minimize server load and download times that you want to compress it. I prefer to use Inno Setup and compress the program inside the install routine itself. Then when it is installed, it is expanded to full size. That both prevents possible detection as a virus and eliminates the extra startup time needed to uncompress the program in memory. Also I code sign both my executable and my install routine and some compression techniques are incompatible with that.
For more info about compressing, see the StackOverflow question: Delphi EXE compressor?
ldsandon asked me to provide exactly what options I'm using, so here they are:
(source: beholdgenealogy.com)
(source: beholdgenealogy.com)
When moving from Delphi 7 to Delphi 2010., our .exe's grew for example from 16 megs to 35 megs.
I asked a question similar to yours on the Embarcadero forum a few weeks ago. (link) In my OP, I listed a series of links on this subject that you might find helpful.
We tried using UPX to compress our .exe's. Letting it work for hours significantly reduced our .exe, but we probably won't use it in production for these reasons:
We have quite a few .exe's and don't want to wait 1/2-day on each build. (It's possible that we could find a non-brute force set of parameters to UPX that would reduce this...)
Although the size of the .exe is reduced, our shippable was not, because our installer (not surprisingly) is unable squeeze much more compression out of the already compressed file... whereas it was able to reduce the original 16 meg .exe down to 8 megs.
I've read some reports that at some time (rarely, but not never), UPX exe's triggered various anti-virus programs to report the application contained a virus. (I don't recall the date, site, or details of where I saw this, so it's a bit unfair of me to report it here.) But, we are so adverse to taking a risk of that even possibility happening, that UPX is off the table...
The link on the Embarcadero forum also includes a link to another SO thread on this topic.
I continue to be surprised and disappointed at the code bloat we found when moving to Delphi 2010. As Nick notes, 2X for Unicode is quite excessive.
However, the bloat is a relatively minor trade-off when moving to D2010, because, IMO, D2010 is such a terrific upgrade in so many other ways. But, it does mean that we'll probably have to move to shipping 2 CDs rather than one. I'm not looking forward to seeing the reaction to this from our organization...
Without seeing the actual settings that your "Release" build configuration uses explaining this increase in size requires a great deal of speculation.
Beyond some perhaps unlikely factors resulting in a vast increase in the amount of code being "dragged in" even though it isn't used, that magnitude of increase would most easily be explained by the inclusion of debug information.
I would check your compiler and linker settings for:
Debug Information (compiler setting)
TD32 info (linker)
Remote debug info (linker)
Compare these settings in your Delphi 2009 project with the equivalents in Delphi 4.
Factor out the expected 2X increase from Unicode and you end up with a 2.5X increase unaccounted for. This makes sense considering how many versions you've skipped. A lot's been added to the VCL and RTL since Delphi 4, and not all of it is stuff that can be easily smartlinked out, even if you never use it. Depending on how many units you're using, you could be hauling in quite a bit of extra baggage.
Allen Bauer and the compiler team added a new feature into D2010 to help reduce this, but apparently they're treading cautiously and didn't use it in as many places as they could have. Hopefully we'll see more cruft reduction in 2011 and subsequent releases.
I will add my few words.
Linker can remove unused procedures and functions only if it can follow the code hierarchy. The nightmare list for linker listed below:
Message-driven code, the sad news is that this code can't be removed whatsoever, that's why Delphi blank project size continues growing from version to version. Every new windows message (WM_TOUCH for example as long as I know introduced recently) creates procedure call hierarchy that can't be removed (even if you don't have plan to use Touch API at all). This is because every case WM_: fragment is something linker can't decide whether it will be used or not.
Code and data structures accessed from the begin end, initialization, finalization secions of the units. Here you have some control, remove unnecessary calls or object creation. Even if you create objects on demand and only free them in finalization section, make it carefully
Use "upx - compress or expand executable files" # http://upx.sourceforge.net
If you go to tools/configure tools, and set it up like this, you can compress the executable that you're working on easily via a menu item in the IDE.
Another way is to have a look to 'what unit increase the size ?'.
To do this, I use the JCL 'Project Analyser IDE', integrated in the IDE with the JCL/JVCL installation, it show you all the units with their respective size. You can export it in text file.
If you do it with the 2 environnements (D4 & D2009) you will have a lot of pertinent informations.
I've done some tests to see the difference between D2007 and D2010, because we are upgrading to D2010. I've tested a medium sized management GUI application, with about 60 forms (grids with detail forms, frames, etc). We're using TMS components + Remobjects.
D2007:
"normal" compilation: 18.8mb
with debug dcu's: 18.8mb (same size!)
D2010
normal: 23.9
debug dcu's: 48.8mb (!)
So using debug dcu's doubles our exe size...
Test with our business service (no big dfm's):
D2007: 12.3mb
D2010: 17.1mb
So yes, D2010 increases the exe (a bit), but this is not a problem for my customer.
Edit: some information about compiled size:
D2007:
D2010:
So an increase of code size, but a more than doubling of the data!
If you don't want to use an exe compressor then you should give StripReloc a try.
Check format of your dfm-s. They must be in binary format if you want to make your exe smaller.
1) You are generating a detailed map file, and because you've set "used debug dcus" it will also contains symbols for the RTL/VCL units. If it is used by an exception handling systems to generate call stacks and the like, it could be added to the executable. And if not compressed somehow, it could make your .exe size pretty large.
2) Using debug dcus will also make your .exe somewhat larger because usually they are compiled without optimization and debug options set, and they will make also your code slower. They shouldn't be used in a release version.
3) Debug information should add debig info only to the unit and not to the executable, although it is required IIRC to generate the map file.
Since D2010 adds extended RTTI, and RTTI is a notorious factor in increasing exe size, it would be interesting to see how big D2009 binaries are for that application.
If D2009 binaries are significantly smaller, it is not Unicode etc. For my own binaries, I only have a 30% increase or so going from D7 to D2009.
It has been stated earlier that using an executable compresser reduces the size of the exe but not of the install package. However, if you want a good compressor then try ASPack.
#Tom1952: ASPack is pretty fast, just a few seconds to compress a file
Also you can change the Icon. Icon in newest delphi IDE (ie XE3) is Vista/7 compatible and contains all sizes (up to 256x256 as far as I know). So you can reduce exe file size with changing the Icon.
The standard units in you newer delphi may contain more strings and constants such as error strings, that is included even if you disable debug information. Check your uses.
Don't have much of a somution besides not using a specific unit, or removing unneeded data from it.
(My experiences are with Delphi 5)
For Delphi 10.3 Rio with default setiings:
Step 1: Switch from Debug to Release in "Projects" window. This reduced my exe file from 22 MB to 5 MB !
Step 2: Use an exe compresor like ASPack. It further reduced my exe file to 1.3 MB. Unbelievable, isn't it ? :)
Uncheck debug information in project options.
If embarcadero can't provide any solution or explanation!!! I think the solution is simple: don't stuck only with Delphi there is a lot of programming languages, every one is limited only by programmer imagination.
I need to compress multiple files into a single archive using Delphi. I'd prefer to use freeware components or open-source components because I am very very cheap :-)
My primary requirements are:
Possible to encrypt the archive
Can create common archives that can be opened by anyone with a copy of WinZip
Does anyone have suggestions with components that they have used? Please feel free to suggest free as well as commercial components/libraries.
Perhaps DelphiZip is what you are looking for, it seems to support encryption, too, and is WinZip compatible. It is released under LGPL.
KaZip is an open-source ZIP archiver. Here is its description:
KAZIP is fast, simple ZIP archiver and
dearchiver which uses most popular ZIP
format.Inflate - Deflate zip
compression format (no encryption
support and no multidisk
support).KAZip is totaly based on
Delphi VCL - no DLL, ActiveX or other
external libraries.KAZip is totaly
stream oriented so you can deal with
data only in memory without creating
temporary files, etc. If you need to
add zip-unzip functionality to your
application,KAZIP is the right
solution. Additional ZipListView and
ZipTreeView components for easy
visualisation.Functionality:Zip-Unzip
using Inflate-DeflateBZip2 unzipping
trough usage of BZIP2 units from
Edison Mera Menndez.Functions:Adding
Files, Folders, Streams; Selecting,
Deselecting, Checking;Extracting to
files and streams;Delete and Rename
filesCreate, Delete and Rename
foldersTest, RepairMany new properties
and methods, improved speed.A very
complex Zip Browser demo application
is included
It is not compatible with Delphi 2009 yet, but with some minor changes in the source code, you can make it work in Delphi 2009 too. Actually, that's what I did.
Regards
I`m using madZip from madCollection
I'm surprised no-one has mentioned JclCompression yet - it's part of the well-known Jedi Code Library (JCL).
Here's a view of the unit itself : http://jcl.svn.sourceforge.net/viewvc/jcl/trunk/jcl/source/common/JclCompression.pas?view=markup
Note, it's compatible with 7-zip DLL version 4.64 - newer versions might not be backwards-compatible...
I recommend the $69 ZipForge from ComponentAce.
You could use 7zip (LZMA) bindings for Pascal (compatible with Delphi): http://www.birtles.org.uk/programming/
Another Delphi resource to look at would be InnoSetup. The source code is available and with a little work might give you an edge up on what your trying to do. There is an option to create self extracting zip archives which are compatible with WinZip,
My thoughts are not to use the program, but to use his source as a starting point since it is very heavily tested and extremely solid.
There are infozips zip32 and unzip32 dlls. They can be used from Delphi (even from Visual Basic), there are interface units/modules for both. The interface isn't as good as I would have liked it, but it works.
In the company that i work, we develop all the GUI in C#, but the application kernel is mainly developed in Delphi 5 (for historical reasons), with a lot of components made in COM+. Related to this very specific sort of application a I two questions:
Experienced guys in Delphi and/or COM, do you have any workrounds to work with the buggy TLB interface ?
Some of the bugs are: IDE crashing during edition of a large TLB, lost of methods IDs, TLB corruption, etc.
Here, we haven't found any good solution. Actually we tried do upgrade do the new 2007 version. But the new IDE TLB interface has the same bugs that we found before.
How do you control TLBs versions ? The TLB file is in a binary format and conflict resolutions are very hard to do. We tried to do it exporting the interfaces descriptions to IDL and commiting into CVS, but we didn't found any good way to generate TLBs from IDL using Delphi. Additionaly, the MIDL tool provided by Microsoft, didn't parse correctly the IDL files that we exported from delphi.
I think you should have a good look at Delphi 2009.
Delphi 2009 has changes to the COM support, including a text-based replacement for the binary TLB files.
You can read more on Chris Bensen's blog.
In the distant past (before I started working for CodeGear) I gave up on the odd Delphi-ized IDL language that the IDE presented, and wrote my own IDL and compiled it using MS midl. This largely worked; the only catch, IIRC, was making sure dispids (id attribute) were correct on automation interfaces (dispinterfaces) for property getters & setters - there was some invariant that tlibimp expected but midl didn't guarantee.
However, now that Delphi 2009 uses a safe subset of midl syntax, and includes a compiler for this midl in the box and integrated into the IDE, these problems should be a thing of the past.
We have also just installed Delphi 2009 and it does seem to have improved the support for Typelibraries. However I have worked with COM and type libraries for quite some time and here are my general gotchas that I have found over the years. I would agree its pretty buggy and is all the way up to Delphi 2006 (our version prior to using 2009).
Always have every file writeable before opening. This may sound obvious, but when working with source control sometimes we forget to do this and try to remove readonly flag after opening a file - Delphi cant deal with this. Ensure tlb is writable before opening.
If editing a standalone typelibrary you MUST have a project open. For some reason if you open a type library on its own it will not save. Create a blank project and then open your typelibrary. For some reason this allows the type library to be saved.
If your type library is used by an application or COM+ ensure that application is shut down or COM+ disabled before opening the type library. Any open apps will prevent the type library from being saved.
However I think your best solution is probably an upgrade. You get Unicode support too.
Using Delphi 2009 has greatly taken much of the pain out of huge TLB files, and conversion of our existing objects was painless, but our com objects don't use any third party libraries.
We will be migrating our gui applications over once the library vendors release supported versions.
Same experience with the TLB interface here: we simply stopped using it.
We work with several separate IDL files (hand-build) for different parts of our framework, making use of the #include construct to include them into the IDL of the actual application, then generate the single tlb using MIDL and tlibimp it. If the application has no IDL of it's own, pre-compiled version of the different framework TLB files are available.
Whenever the framework enters a new version, a script is run to re-generate the GUIDS on all necessary interfaces in the IDL files.
This has served us well for many years, and for us to move over the new Delphi 2009 IDL/TLB toolset will have to be not only integrated into the IDE, but also versatile when it comes to automated builds and whatnot. Can't wait to get my hands dirty with some experiments!