I am a C# developer by trade, but have been tasked with making some changes to a Delphi desktop application. I have never used Delphi and I'm trying to identify the version of Delphi the application has been compiled with, and find a (preferably free) development stack/environment.
Looking at the source, there are a bunch of .DCU, .DPP, .DFM, and .PAS files.
There's a .DPR file that would seem to reference all of the forms.
In the .CFG file I found reference to
c:\program files (x86)\borland\delphi7\Projects\Bpl
Based on the above info, what tools should I use to design and compile this application?
That entry in the .cfg file is a clear cut indication that the project was most recently built with Delphi 7.
However, it may be more tricky to build this project than just to install Delphi 7 and press build. You may very well need to install a bunch of third party packages and libraries. In an ideal world there would be documentation on how to build, or at the very least, how to create a build environment. Sadly, you may not be living in an ideal world!
I'm trying to .... find a (preferably free) development stack/environment.
Well, Delphi 7 is not free. There are free Delphi like development environments, most specifically Lazarus. However, you would need to port the existing code, which is likely to be a non-trivial task. Especially if you have no Delphi experience.
It appears to be Delphi 7.
But the compiler version is only part of your problem, as several commentators have mentioned here. Unless they used only Delphi components, you're going to need to find the component libraries that were used, and that could be nearly impossible in itself. If it used any DLLs or BPLs, you'll need to find them as well, and possibly re-build the interfaces.
I'd spend some time trying to track down a backup that was made of the system that this software was developed on, as that's your best bet. It won't cost you anything assuming everything is still intact.
But trying to load up the source into D7, or anything for that matter, is going to be a total crap shoot unless you know all of the libraries that were used, how things were configured, all that good stuff.
It would be far more efficient for your company to just hire a Delphi expert for a day or so to dig into this for you than for you to waste a week or two of your time on something you don't know anything about.
Related
For over a decade, I have been stuck (lovingly) on Delphi 6 and have developed hundred of thousands of lines of code in a logical (to me) unit structure, where a project tends to be a few hundred lines of code referencing high-level work routines in my "library". In trying to migrate to XE5, I just can't find a way to have all my library units compiled in one place on the search path, and then just used by the project (and recompiled if necessary), but that the dcus are off with the library source rather than in with each individual project.
I'm just starting to accept that "hello world" takes 2.5Mb in XE5, and I can't stand the idea that each library unit has to be separately compiled into dcus at the project level. In the "old" days, these unit dcus would sit next to the pas files and not be recompiled if nothing changed in the source file.
The obvious place to look is the Project options, but I can't find the right setting to make the project stop keeping copies of each dcu.
I am vaguely aware that multi-platform development will cause restructuring, but I can't help feeling that there is some compromise position.
There must be something big I am missing.
Starting in Delphi XE2, Delphi supports compilation for multiple platforms, as well as different build configurations. Because of this, Delphi needs to create DCU files for each combination. For example, Win32, Win64, and OS-X DCU files are saved in separate folders by default. Otherwise, if it weren't like this, the DCU files would overwrite each other, which you should avoid (if you use different configurations/platforms).
These settings can be changed in the Project Options in the very first section Delphi Compiler by modifying the Unit output directory. This is by default .\$(Platform)\$(Config) which creates a subfolder for the platform, then another subfolder for the config, for example \Win32\Debug\. Careful for the Target at the very top, which by default is set to your current platform/config. You would typically want to first change it to All Configurations. If you clear this field completely from the options, it will produce your default behavior from older versions.
It sounds like you should create a Package. This would allow you to group all your "library" units together in one place (BPL). This package can then be installed into your IDE, and if you have any components, those components can then be installed into your component pallet.
Or you can do without a package too. All the units from all these different projects should be moved to this central place though - a single folder containing all your "library" units. This way it's less maintenance, and you can just add that one folder to your global library path.
If you put your files in a central folder, and use those files from a project, the DCU files for both the project and this "library" will be saved for that project. Delphi doesn't know that these files are a "library", it just knows that you're using them, and since it can't find an already compiled version of those units, it creates one in your project. If you want the DCU files to be saved only once and in this central place, then you would need a package.
First, let me thank all the respondents to this question - all provided useful insight. I experimented with the various suggestions (including breaking XE5 so badly that I had to reinstall -- at least I learned some areas not to mess with.)
Important to me, but a known bad coding practice, is having individual projects edit shared library units (only my own units - I do not mess with code belonging to Delphi or 3-rd party). This is critical to having multiple applications working on the same data, but in bite-sized pieces. the shared code lets me make high-level pieces of an app available to other projects. There might be better ways (I would love to hear about them), but this has worked for me for a long time.
The multi-platform model really requires the dcu structure used by default, so I will adapt to it. Share the source code, but accept multiple compilations to individual projects. A good suggestion by JensG is just to clean up the dcus when the project is not actively being worked on. Should be straight-forward utility program.
The D6 -> XE5 migration (which will take months for some of the less used areas) requires me to know which units compile successfully, so I will maintain one project whose function is to include all units and recompile them all. This will make it practical to map library unit pas files to dcu files.
The AnsiString/AnsiChar <-> String/Char problem is the major migration problem area. Simply making edit-level changes may get the code past the compiler, but there is no guarantee that the code still works the same way. Especially troubling is at interface points to Windows calls and such. My answer will be to make the units compilable first, but then write test code for trouble areas. This is what will take the months - I need to get on with new stuff, as well as fixing the old. I REALLY don't know yet if I will be able to substitute the XE5 compatible code back into Delphi 6 without another layer of testing. I THINK it should work, but it will take careful checking.
A second major migration problem is 3rd party code such as VCLZip. XE5 has its own zip support, but I have a lot of places where I use VCLzip and the conversion will not be trivial. For this specific library, it may be possible to find XE5-level source and simply work it in. There are other pieces of code gotten from the internet that I used, but never needed to truly understand which will cause significant hassles.
Again - thank you to all. This has been an interesting 24 hours. Howard
My general question is how do you troubleshoot "My BPL won't load due to a dependency that just won't go away, no matter how much I clean up and recompile". Update You may think you have a clean recompiled system, but thanks to the inverse-miracle that is Windows and its file system virtualization mis-features, you haven't.
When I try to load my designtime package (in this case named dclFsTee.bpl) into my Delphi IDE (it's the fast report 4 teechart wrapper component package), it complains:
The program can't start because tee7100.bpl is missing from your computer. Try reinstalling ...
That tee7100.bpl is not referenced on any DCP or DCU file on my system THAT I KNOW OF. But clearly, something is wrong, and I can't find the problem.
All Delphi users face a hundred "won't compile or won't load" problems with BPLs. The universal refrain when asked what to do is to clean up your computer.
However, I've now spent hours cleaning up my computer, and while everything compiles file, clearly there must be something out of date hiding somewhere, because the resulting BPL file that I'm trying to load still wants to load a version of a TeeChart BPL that I removed from this system days ago, along with every trace I could find.
The traces of TeeChart stuff in Delphi 2007 that I removed include everything in the $(BDS)\Lib and $(BDS)\Lib\debug folder, and all DCP and BPL folders on the system. Also every TeeChart-unit-named dcu file is gone.
Once you've gotten to the end of the road, what do you try next? (Format the hard drive, buy new computer.) Seriously. I think I'm a smart guy, but I have a 1 tb hard drive, a library path that runs to 80+ folders, and a source code repository that seems to be well organized, but clearly something is hiding where I can't find it.
I have TeeChart Standard 2012, with full source code, and as far as I know, my development machine no longer contains any old TeeChart BPLs or DCP files from the "tee chart tee7100.bpl" version that ships with delphi.
I have run the "recompile.exe" wizard that comes with teechart, which appears to just run MSBuild and build the packages, after writing a {$DEFINE x} declaration to the tee.inc files (there are two of them in the source distribution).
However, somehow, silently it seems like one of the implicit imports into one of the packages is drawing in some stale file which has not been rebuilt, and which therefore tries to load the tee7100.bpl. The new bpl name is tee911.bpl.
Rather than ask the pretty-specific-to-fastreport question, I'm only mentioning it as a specific instance of a general world of hurt that I have faced dozens of times while developing in Delphi.
I'm only giving the fast-report details so you can see that this is in fact a specific instance of a general problem that one faces sometimes inside Delphi IDE when dealing with a component source code or package, or set of packages, with dependencies. Cleaning up your computer so that your code even builds can be tricky.
So here is my Delphi package-to-package-dependency-resolution question:
What is the most effective way to find or trace implicit-load-of-some-no-longer-wanted BPL-problems so that my code (which builds and compiles just fine!) will actually load into the Delphi IDE. The BPL file that results from running Recompile seems to be linking properly to the right DCP files, and no old/stale DCP or DCU files are present. The new DCP file name is tee911.dcp, for instance.
Can you get somehow, any idea of what package is actually stale, and what is being read and linked and imported statically when the .bpl links? (I'm thinking maybe like a special MAP-like file for BPL files?)
Update After many hours of fighting with this, and using every trick I know, I realized I hadn't checked for some VirtualStore related issues caused by file virtualization in Windows 7. That means that Windows 7 lies to the programs that run on top of it. It gives you another version of the file, that isn't the one you want. This can be deadly in several ways; One; You recompile a BPL but that's not the one that loads. The BPL that was killing me was in the SysWow64 folder that was part of the VirtualStore. Note that the virtualstore basically makes phantom files appear that are only there if you're a certain "low privelege" program, which Delphi 2007 on Win7/64 bit, apparently is. To remove BPL files in your SysWow64 VIRTUALSTORE folder for your current user account:
del %HOMEPATH%\AppData\Local\VirtualStore\Windows\SysWow64\*.bpl
... Some days I just hate Windows architecture. Anyways, I'm not going to put the above as the answer, because I'd like to know if anyone has a better way or any tip or suggestion that might help next time.
Okay nobody else answered so I'll put this here to be helpful for future people:
-- Remember Windows VirtualStore when cleaning up broken systems which have old versions of DLLs on them including TeeChart, FastReport, Indy and so on which tend to be involved in messes because they can exist both as "out of box packages that ship with delphi" as well as frequently installed as upgraded versions if you purchased and installed them from the vendors directly, or third, you may have your own compiled copy in your company's mega-component-pack-directory.
-- When searching for duplicate or out of date BPLs, doing a file search in windows doesn't look in the virtualstores, you'll have to locate and zap the whole virtualstore area for your process or user, or program, manually.
The second level of this issue is this:
The dependency graph for FastReports is complex:
It depends on Indy and you might have your own version of Indy, and Delphi itself has one, and other things on your hard drive might have their own copy of Indy.
It supports various editions of TeeChart, including the binaries that come with Delphi, and perhaps the Standard version or other purchased version of TeeChart that you might have bought from Steema.
It uses a precompiled header include file to do the compilation and not just ONE but TWO different copies of an identically named include (.inc) file.
When you use their own compiler tool (recompile FastReport) it works pretty reliably but isn't the best for when you want to build everything in your project from a single build script, thus the source of my problem.
The key is to learn everything there is to know about the dependencies of all the components in your giant pile of packages, and to organize your system cleanly so that you don't have old stuff (like Indy and TeeChart bpls, dcp, or dcu files) lying around. Cleaning that up is quite a complex job if you don't know what you're doing.
A utility to really remove all traces of the version of Indy and TeeChart that ship with your system, and the "Embarcadero edition" of FastReports is key to getting this situation resolved. A general tip is that "if a version of X ships with Delphi and you are going to install a new version, prepare to suffer until your system is really cleaned up".
A really amazing technique to avoid all this crap is to just not install Indy, FastReport or TeeChart (uncheck them or skip them) during your initial Delphi IDE install, then install them yourself, one by one, from sources. Just because a version comes pre-installed in Delphi doesn't make that a good thing. (Update: You can no longer unselect Indy during install, it's part of the base Delphi product since at least Delphi XE8. A clean-up utility to remove the built-in Indy from Delphi's own lib dirs is necessary for anyone who builds their own.)
Another really amazing technique is to run the Installers for commercial components on a virtual machine, then just collect up the pascal source code and transfer that onto your clean development machine, and build it yourself. That way you can avoid the terrible things that happen when you've got BPLs and stuff scattered around your system, and even installed into C:\Windows\System32 (on 32 bit systems) and C:\Windows\SysWow64 (the equivalent path on 64 bit systems).
put that BPL (tee7100.bpl) under $(BDSCOMMONDIR)\Bpl
for XE: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\8.0"
for XE5: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\12.0"
The other issue that can cause this, is not having the folder where you've stored your .bpl files in your system path.
This happens because Delphi attempts to call the WinAPI function LoadLibrary with a file name, instead of an absolute path. So if Windows can't find the file, Delphi can't load it.
See this forum post for more information.
This seems to be an issue in Windows 7, though not in Windows 10.
Should I upgrade from Delphi 2009 to delphi XE?
As I don't use all the technologies, such as mobile, cloud computing, profiling, 64 bit, new database drivers, I don't need to change to the new XE?
What would change my mind?
Does the new Delphi IDE help me to write less code? Is the package management better?
Do you feel that the IDE gives more automation? And is it worth the upgrade?
I use Delphi XE all day every day, and I wouldn't use anything else.
It is the most stable version of the IDE that I have ever used. The compiler has had a huge amount of attention paid to it, and it works, and doesn't have the many internal failures, internal access violations, or other ways that compilers fall down, that every Delphi release since Delphi 2005 has. So the main feature that makes Delphi XE the best version ever is stability. It is even more stable than my old standby - Delphi 7. And delphi 7 is pretty stable, but working all day in Delphi 7, I did experience regular crashes, something that is finally a thing of the past, with Delphi XE. Okay, I've crashed XE's IDE a couple times, but it's rare.
The second reason is that it comes with great tools; A version of final builder, a version of CodeSite, and a version of AQTime are included. CodeSite was new to me with XE, but I love it, and now that I have used it I couldn't live without it. AQTime is an old friend of mine, and the version included with XE does most of the things that the full standalone AQTime will do, that I need it to do. The final builder version included, is also a huge time saver, especially if you have complex builds to do, including several Delphi application compiles, and an installer script to run, and perhaps other steps.
I like the code-formatter. I am not a big fan of Generics, but you can use them now, and they don't kill the compiler. I still prefer simple readable code, to a morass of generics, and I don't like the way that you do constraints with generics using IUnknown-style reference counted interfaces. Not nice, and not fun.
I don't use much of the database, cloud, or multi-tier application development features. I can't report on that aspect, but I do know that there's a lot more in the RAD XE product than any single developer, however intrepid, can probably even discover.
(Ethical Disclosure Footnote; I work for embarcadero. But even if I didn't, I'd still say everything above. Perhaps, I'd state it even more strongly.)
Does the new Delphi IDE help me to
write less code? Is the package
management better? Do you feel that
the IDE gives more automation?
No real changes there I think.
The area with possibly the most noticeable differences is generics. If you use generics at all then you should upgrade. The versions that followed 2009 have far fewer bugs and wrinkles in the implementation of generics.
In addition to what David said, there also is the new RTTI in Delphi XE which might make the upgrade worthwhile.
Besides the generics improvements, there are new features in the IDE. The addition of a code formatter, IDE Insight improvements to help you find things, integration of SVN, the reworking of the configuration manager, custom build tools, form designer changes, and more. There's also a bunch of new stuff in RTTI.
See this page for a list of what's new in XE, and go up a level from there to see a listing of what's changed specifically from 2009 to XE.
I think it's worth it...
Many bug fixes - they have focused alot on closing out issues. You cannot discount this...you'll never get any more fixes in your current version and the time saved by not having to work around just a single bug or two certainly pays for the upgrade cost if your time is valuable.
SVN integration is handy.
"Show In Explorer" from the project manager. (I don't know if it's just me, but I use this alot and it saves me time.)
If you like code formatters, there's a new option to format all sources in the project.
Debugger visualizers are kinda cool
Third Party Tools included: somewhat crippled, but very usable versions of: AQTime, Beyond Compare, CodeSite, IPWorks, Finalbuilder (depending on Pro/Enterprise)
Online help updated quite a bit
Can it help you write less code? Yes, as you can now rely on generics more due to many fixes from 2009, 2010 and XE. There's also some additional live templates added if that's what you are after.
What would change your mind? I'd say the bug fixes, additional Third party tools, and Online Help improvements make it a no-contest upgrade for the Pro edition. If you are going for Enterprise upgrade, and not using dbExpress, or other enterprise features, then it might be a little less convincing of an update depending on your budget.
The Help has been improved a great deal in XE - in 2010 it was a (bad) joke. 'Show in Explorer' is also great, although not enough reason to lay out that much money. Also much better support for REST, JSON etc. And XE just feels very mature and stable - I don't work for Embarcadero, but I use XE every day, as much as possible - unfortunately I am currently working on a project that uses components compiled for Delphi 5 without source code so I can't use XE for everything. There are some VS guys in my shop who think 'Delphi is Dead' and give me some grief - I am proving them wrong with XE...
I'm writing delphi app which should have capability of loading plugins. I'm using JvPluginManager as plugin system/manager ;) Now, in the new plugin wizard they say it's better to use .bpl type plugins instead of .dll plugins ... What are the pros of this solution versus dll type plugins?
So far I've found only cons of this solution:
I have to put all the common interface units in separate package so that while loading plugins it won't throw any error about the other package containing common unit
if, let's say, one of plugin developers decides to uses some well-known unit (like synapse), which doesn't have runtime package by default, and the second plugin developer does the same, than bump... it's crash here ...
So, what are actually the pros of using bpls instead of dlls compiled with runtime packages?
Thanks in advance
Another disadvantage to BPL's. When you switch Delphi versions you will have to re-distribute new plugins. After many attempts at attempting to find the perfect plugin system, I ended up with COM and I have never regretted that decision. In a commercial application which has had the plugin requirement for over 8 years, the application has continued to move forward and yet some of the plugins that were released with the first iteration still exist in their ORIGINAL form.
If you choose this method, do yourself a favor and start with a simple interface and then add new interfaces upon it. You don't want to ever change your base interface, so keep it simple and sweet.
As Alexander said, a BPL is basically a DLL. But there are some conditions (from a not-so-short summary I made: http://wiki.freepascal.org/packages ):
A unit can only exist once in BPL's +Exe. This avoids duplication of state (twice the heapmanager and other global vars of system etc, VMT tables etc)
.BPL's can only USE other .BPLs.
This means that dynamic types like ansistring and IS/AS work properly over BPL interfaces.
Initialization/finalization are separate procedure and their initialization order is strictly controlled. For static dynamic loading this is simpler, for dynamic loading (plugin-like) all dependancies on units are checked .
Everything is essentially one big program, which means that the BPL's must be compiled with the same compiler version and RTL and depends on the versions other dependancies. It might be harder to make .BPL's to plugin to an existing EXE, since the Delphi version must match.
This also means that you must deliver .dcp's for (non Delphi) .BPLs the plugin .BPLs depend on
In short: if the plugin architecture is open, make it a DLL. Otherwise people have to have the exact same Delphi version to write plugins.
Hybrid is also possible. An higher level .BPL interface for functionality you factor out into .BPL yourself and selected devels, and a rock bottom procedure DLL interface for the rest.
A third option is using DLLs, but ordain Sharemem. Strings will work, multiple Delphi versions will work. Objects can work but are unsafe (e.g. I guess e.g. D2009 with an earlier version wouldn't work). Even other language users might be able to allocate over COM, not entirely excluding non Delphi.
Your first con is also a pro. If you replicate shared code in each dll the dlls get bigger and bigger. Even when using dlls you can prevent this by moving shared code in a separate dll.
Pros:
Types are shared. No TFont is not a TFont problem
Memory manager is shared. Strings and classes can be used as parameter between plugins without problems.
Cons:
Plugins can be built using Delphi or BCB only.
Plugins should use the same Delphi or BCB version.
Have you considerd using COM? COM makes it possible to share types, strings and classes and the plugins can be written in many programming languages.
I'm not familiar of JvPluginManager, but it depends on how you're going to use BPLs.
Basically, BPL - is just a usual DLL, but its initialization/finalization work is stripped from DllMain to separate functions: 'Initialize'/'Finalize'.
So, if you're going to use BPL like usual DLL, there are no cons that I'm aware of, only pros: there will be no more troubles with DllMain. That's all. The only difference.
But BPL in Delphi also provide a convient way to share code. This means great advantages (common memory manager, no duplicated code, etc, etc). So usual BPL does a lot more than "being just a DLL".
But this also means, that now your plugin system is limited to Delphi only (well, may be C++ Builder too). I.e. both plugins and exe MUST be compiled in the very same compiler to run smoothly.
If this is acceptable for you (i.e. no MS Visual Studio, no, sir, never) - then go ahead, you can use all power of BPLs.
P.S. But upgrading such BPLs plugins can be also a nightmare, if you do not design interface side carefully. In certain worst cases, you may need to recompile everything.
P.P.S. Like I said: I have no idea, how it is applied to plugins, created by JvPluginManager.
Avoid blp approach as you will have to ship a big bag of bpl with you software and thus, distribution will become bulky.
why do we use Delphi to compile small stand alone programs that just RUN anywhere without any runtime dependency. Using bpls means defeating this very purpose.
I don't know as to how comfortable you are with DLLs, but I would suggest you to use DLLs.
This will give other developers (who
may get interested in your software)
a chance to use any development
language (as long as that language
can spit out dll) to write their own
plugins that can be used in your
developed software.
Another thing is that you will be
saved from Delphi's vcl version
dependency tyranny. A major weak
point of Delphi till date.
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!