I've recently joined a new company with a suite of legacy apps written in C++ Builder 6 and am investigating some memory issues. To do this I'm using the latest Fast MM from GitHub and got it working ok with a simple BCB project.
In the actual projects, Fast MM says it can't start because 'Another third party memory manager has been installed'. After investigating this, it seems to be because of Teechart V7, which is used extensively in the projects.
If I add a Teechart control to my simple app I get the above message. We have the Teechart source code but I can't find anything in it that looks like a custom memory manager and am wondering if I can recompile it to use Fast MM. But, being a C++ Builder dev with very humble Delphi skills, I'm unsure if this is the right approach or why TeeChart causes Fast MM to think another memory manager is operating...
Any hints would be appreciated...
Andy
Teechart Pro V7 makes direct calls to the memory manager and building our app with runtime packages meant that TeeChart.bpl's dependency on the the Borland memory manager caused the problem. The simplest fix is to not include any Teechart package in the build with runtime packages list (assuming the linker can cope with the increased .EXE size) and/or use the third party ULink linker (ftp://ftp.styx.cabel.net/pub/UniLink/) which seems to cope with any size of deliverable.
Another option is to add FastMM to Teechart's projects (assuming you have the sources) and rebuild...
Related
I use Embarcadero Delphi XE5 Enterprise Edition. I have a project group consisting of 17 projects. When I click 'Compile All' after 7th compiled project IDE throw me an exception:
[Fatal Error] Exception of type 'System.OutOfMemoryException' was thrown.
What is a reason of such error and how to handled with it?
The Delphi IDE has several issues managing memory that were never really fixed by Embarcadero, one of the main issue is that the IDE and compiler have huge memory consumption due
to caches that are not released between compilation runs.
A workaround that I've applied with success with my codebase is to compile all the projects from the command line with a tool like ANT using the dcc compiler, this will save IDE memory consumption. In the case you need to debug applications then you can compile and build a project at time and restart the IDE every 2/3 compilation.
Another workaround that I've applied successfully in Delphi XE7 to reduce IDE memory consumption was renaming the following IDE files :
Borland.Studio.Delphi.dll
Borland.Studio.Refactoring.dll
refactoride210.bpl
This makes the XE7 IDE usable again; just the refactoring feature aren’t available anymore.
If the aforementioned solutions don't work for you you will have to split your project group in single projects and switch between project each time as someone else suggested commenting your question.
The new Delphi 10 Seattle seems to address some of these memory related issues since they claim :
“Under the hood” the IDE’s project, file, and build management
handling has gone through a major overhaul and redesign to provide
significantly extended available memory, giving developers a more
stable, capable, and faster development experience.
But honestly I don't think it is the definitive solution, is just an improvement of the situation. The final solution of this situation is a 64bit IDE that is not a simple thing to implement by them since I think they have to handle a legacy and not very flexible codebase ...
Try the new Delphi 10 and see if the situation improve, if not apply the workaround and wait for a 64bit IDE release.
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.
The following question has had me wondering for some time now as to how 3rd party component developers are able to ensure there components are compatible with all the various IDE versions?
I am just a single developer who uses Delphi XE and occasionally Lazarus, if I developed some components in Delphi XE how would I ensure they are compatible up to Delphi XE6 for example, and also compatible with older IDEs?
I don't mean in a coding sense because I believe you use the IFDEF flags when checking the Delphi version numbers. I mean if you don't have access to different Delphi versions how do you test the component?
It is not possible for me right now to purchase XE6 or a new Delphi IDE for a while - if it all, and even if I could I would not have previous IDE's like Delphi 5,6,7 etc.
So how do other component developers do it?
Purchase all the IDEs? which seems unlikely
Download Trials for the IDEs? which also seems unlikely
Get people to test the component if they have another IDE? Seems possible
Make it Open Source and let others test it? Also seems possible unless you want it Close Sourced
What it comes down to is I want to make a few simple components but I want them to be compatible with as many Delphi versions as possible should they ever be released to the public.
I don't have the means to get all the Delphi IDE versions and downloading trials may also not be possible. Even if I bought XE6 or the next release I would not be able to test with Delphi 8 for example.
So, how do 3rd party component developers make there components compatible and tested on various IDEs? Am I missing something obvious here, how can you have access to every Delphi IDE Version?
As a component vendor myself (I am the primary developer of Indy) who needs to support multiple versions, I can only speak for myself, but here is how I do it:
Purchase all the IDEs?
If possible, yes. I have a number of IDE versions installed in VMs, which I use for testing purposes. And for some versions that I do not have installed, I do have their RTL source code for reference purposes, at least. On the other hand, as a member of TeamB, I get free IDE licenses, which helps. Not everyone can afford to purchase every version, although newer versions do provide free licenses for older versions, so you should take advantage of that. I recently installed Delphi 7 through this. If a components works in Delphi 7 and Delphi XE6 then there is a good chance it will work in all versions in between (barring any version-specific RTL bugs, etc).
Download Trials for the IDEs?
N/A for me, but that might be a viable option for some people.
Get people to test the component if they have another IDE?
I do this with Indy. Although I do have several versions, I don't have every version. Other users who have versions I don't have myself do help. If nothing else, for setting up version-specific project files and testing install procedures.
Make it Open Source and let others test it?
This also helps. If you want to develop closed-source components, you could setup a private repository and give access to select users/volunteers. Most users want/need source code (to find and fix bugs when used in their projects, to satisfy corporate policy requirements, etc), so you should make sure you offer an option to pay for source code.
When you buy the latest you get access to all the previous versions (from v7 on - thanks Uwe Raabe)
Previous versions
I am using the first approach: Buy all versions. I have all Delphi versions back to version 3 (from 1997), but only 6 to XE6 are installed on my machine (with the exception of Delphi 8 which in my opinion should better be forgotten). But of course I didn't buy them all at the same time, I started with Delphi 3 and updated from there on.
Unfortunately it becomes more and more complicated to get older versions installed and running on "modern" operating systems (currently Windows 8.1 so far) so sooner or later I will be forced to switch to virtual machines. Not yet, though. Switching to VMs has the drawback that you can't batch compile using different Delphi versions:
call CompileForDelphi6.cmd
call CompileForDelphi7.cmd
etc.
like I do for GExperts.
I have upgraded a project from RAD Studio 2010 to RAD Studio XE4. The project is mostly C++ using the C++ Builder half of RAD Studio, with smatterings of Delphi.
Under 2010, the Release build was 22MB. Under XE4, the same Release build is 55MB.
This is a problem because:
55MB is remarkably large for an EXE
It takes noticeably longer to start the program (not much, but some.)
Many of our customers download new versions from remote areas or on board ship while at sea. Size matters.
What could cause this, and how do I fix it?
Notes
Oddly enough, the debug build is still only 23MB. Project settings seem very similar. I diffed an export of the option sets and saw only <UsePackages>True</UsePackages> as something present in Release not Debug; removing it made no difference. Beyond that there's code optimisation turned on and lack of a _DEBUG define.
Debug info is generated for the Release build, but goes into an external .tds file. (This will be used for EurekaLog in future, and currently allows us to debug release builds of the program.) I wondered if the linker was linking in debug info, but as far as I know the C++ linker always places the debug info in an external file, which exists, plus EurekaLog is not yet enabled in the build.
The project files (.cbproj) were created in XE4, not upgraded from old 2010 ones. I made new projects and added the old .cpp and .pas files. This was to avoid issues caused by upgrading - on the Embarcadero forums it's often recommended to create projects anew when upgrading IDE versions. Until this occurred, I had indeed encountered fewer issues than in 2010.
There are many mentions of Delphi XE2+ EXEs being noticeably larger than those produced by old versions of Delphi. (1, 2, 3, 4, 5, 6.) While the C++ linker is different to that used by Delphi, it is possible the causes are similar.
The cause there appears to mostly be RTTI used by the Delphi RTL code, which in a Delphi project can be removed by specifying {$WEAKLINKRTTI ON}. The XE4 documentation does not mention an equivalent C++ linker pragma. There is #pragma explicit_rtti (the C++ analog of {$RTTI}) and __declspec(delphirtti) (the C++ analog of {$M}/{$TYPEINFO}).
The project is linked using runtime packages and the dynamic RTL. It is a 32-bit VCL forms application. I have XE4 Update 1 installed on Windows 7.
Edit: David Heffernan asks in a comment below about the .map file sizes of each project.
The release .map size is 17MB, and .tds size is 80MB.
Debug has now stopped linking, with the linker reporting it is out of memory (an old, old bug that should have been fixed years ago.) There are no .map or .tds files generated and so I can't give a comparison size accurately. From memory the .tds was about 100MB, and unfortunately I don't recall the .map size. If I get the project linking I will update the question.
Edit again: I found the answer (sortof) - turning 'Expand inline functions' OFF reduces the EXE size to the expected value. This is puzzling itself though - see my answer below. Note that the debug build already had this turned off and still won't link, giving an out of memory error.
I haven't marked my answer as correct yet, in case someone can provide some insight into exactly what is going on, which would be a much better answer than just 'turn this option off'.
Solved (sortof.)
The Release build had "Expand inline functions" turned on. Turning this off reduced the EXE size from 55MB to 17MB.
This is an astounding difference and I don't know why the difference is so big. I find it unlikely we have 38MB worth of inlined functions, even counting templates and headers, let alone ones using the inline keyword. If there is a way to examine the linker steps, output, or obj files to see what is being expanded, please comment - I'd find this really valuable.
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!