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.
Related
in C# you can easily open an assembly (just another word from an EXE) and then get reflection information from that assembly. I've been looking for something similar for Delphi where I can write a Delphi program that can point to a Delphi EXE then get me reflection information. How can I archive this? Thanks
There are a handful of programs that can extract RTTI from Delphi programs and DLLs. It's not as rich as what's available for .NET, but it can be done to a limited degree. There's a lot more RTTI available in Delphi 2010 and later versions, but as far as I know there's no program out yet that can extract info from them.
I was at the conference where this system was formally announced, and a bunch of people asked how this would affect security. Barry Kelly, who created the new RTTI, said that there would not be enough metadata available to create a "Delphi Reflector".
Well, sad news is, you probably can't. You can easily view .NET assemblies because they a) are compiled to what is called intermediate language (thus you can even get the code back using the likes of Reflector etc.), and b) contain metadata. Delphi, on the other hand, compiles to native code that and produces regular PE files that do not include rich metadata like a .NET assembly.
Delphi just doesn't work that way.
There are tools that can assist in reversing (Delphi written) executables but it will never be easy and it requires good x86 assembly knowledge.
Some examples of such tools are:
IDA Pro and/or Hex Rays
DeDe
Interactive Delphi Reconstructor
PE Explorer
The resource sections of a Delphi Executable also reveals usefull info like the form and it's components.
See also Is there a program to decompile Delphi?
If you have Delphi2010+ you can load a bpl and then use the rich rtti over it lik. e you do with c# and a .net assembly. If you need to do this in a .exe AFAIK you can't.
TestComplete seems to identify most objects in a running Delphi executable. You can extract this information with a script. A demo can be downloaded from http://www.automatedqa.com/downloads/testcomplete
This is maybe not the type of application you want as it is big and made for GUI-testing, but yes it can identify the objects.
As mentioned Remko, IDR (Interactive Delphi Reconstructor) can extract all RTTI information (if program contains it!) for Delphi version from 2 to 2009. Version 2010 will be available later. Moreover IDR can use all information that it finds in program to create a lot of comments to disassemled program code (this is a first step of analyses). You can also look forms and easy go to event hadlers associated with controls.
I'm porting a app to FreePasal/Lazarus & found that their form converter is not good. I have a small utility app, and each time I do a change I need to reconvert, relayout and reimport graphics. Plus, some things are messed up.
I wonder if exist a automatic tool for convert the DFM files to delphi sourcecode, so I can do this more easily. Is not problem if the sourcecode is not FPC compatible.
The free GExperts plug-in has a "components to code" feature. Install it in your Delphi IDE and open the form you wish to convert. Select the components and invoke the command, and it will place equivalent creation and initialization code on the clipboard for you to paste wherever you need it.
Updating to trunk versions of both Lazarus (0.9.29) and FPC (2.5.1) might also be a solution.
Several things have changed:
last month sb started working on the converters (Juha)
FPC 2.4+ bring the resource handling closer to Delphi (no more .lrs)
We recently converted our long-running Delphi project to Open Source. Multiple people have contributed patches already, which is great, but unfortunately forms and frames when saved with Delphi 2006 (and later) contain new properties in the .dfm that are not handled by older versions. Forms are handled quite gracefully by the IDE ("ignore propery?"), but frames are loaded at runtime and result in errors. Not an option, as far as I'm concerned.
I now removed those properties from the .dmf files by hand, but I am really wondering if there is a more elegant solution. There is no way to save in a backwards compatible format from the new IDE's, is there? Are there existing tools to strip the nonsupported properties from the .dfm's ? Any other elegant solution I am missing?
Normally, with a commercial project, I'd just upgrade the project to the most recent version applicable... but as this is open source I really don't want to loose out on those developers still working on Delphi 7. That includes myself, actually.
The JEDI JVCL project uses a little utility dc.exe (delphi cleaner) and a list of properties in DFMs that are not present in older versions of delphi, mine contains the following text:
*.PopupMode
*.PopupParent
*.ExplicitLeft
*.ExplicitTop
*.ExplicitWidth
*.ExplicitHeight
*.BevelKind
*.BufferDocument
*.DoubleBuffered
*.ParentDoubleBuffered
*.DisableHyperlinks
*.AlwaysEnquoteFloats
*.PixelsPerInch
I run this dc.exe utility from a batch file which cleans my dfms before I commit
changes to subversion. The syntax in my batch file for this is:
dc.exe -s -fd10.txt *.dfm -i
You can grab my stuff at:
http://sites.google.com/site/warrenpostma/files
You can try Andy's DFMCheck. It can automatically open and close all forms and frames in a project, which makes the IDE remove unknown properties (as Marco wrote).
Well, for sake of completeness:
Open the dfms in the oldest Delphi supported, let it remove all unknown properties, change a property and save.
For your purposes, Warren's solution is better, but it can be a workaround. I did it for a while when we were dual D7-D2006ing.
Does Delphi support internationalization in any way?
I've seen that I can add different languages for a project, but that seems to create multiple instances of the dfm files. Am I right that the language therefore cannot be changed at runtime?
How do you handle internationalization (if you do)? Are there any best-practices?
Delphi ships with some tools to do this.
Here is a tutorial for Delphi 2005, and a video of Nick Hodges showing off the more recent version for Delphi 2009.
I have once experimented with runtime change of languages. It worked great, but I needed to write lots of code myself (and circumvent the dfm files). The problem is, it is a lot of hassle and you almost never need this.
The better option (in my opinion) is to create a base language version and use a translator tool for the other language. We use a third party translator that works on the executable and dll. It replaces the strings in the resources and creates new binary files.
One big plus of this tool is that it shows the translated dialogs (standard windows components only) so you have direct feedback if labels are too large.
Amd then there is dxgettext:
http://dxgettext.po.dk/
traditionally one of the tools used to change language runtime without restart.
Note that with Delphi/unicode the amount of code changes with this packages has decreased (one no longer has to change any resourcestring use)
I have been using the SiComponents before. They allow you to change all text independently from the executable. You can embed the diferent languages in your executable (not recomended) or load them from files. There is also an editor to support translation. They are very good, stable, and fast.
In Delphi 2006 under Tools, Options, Translation Tools Options you can configure the translation tools, especially theTranslation Repository. It can be found under View, Translation Manager. All translated strings will be ressource strings and can be stored in language specific dll. Searching the help for Translation Manager will point you in the right direction.
I second the recommendation for using the TsiLang components(www.sicomponents.com). I've just used them to upgrade from English-only to English + Chinese, selectable at run-time, and found the process to be quite a lot easier than I was expecting. The end results are not perfect, but certainly good enough to work with.
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!