I've been using FastMM for very long time always placing 'FastMM4' in all Delphi projects. Does it make sense with the latest Delphi versions?
It still does make sense, yes.
Delphi c.2007 starting using a version of FastMM4 as the default memory manager - but it has some stuff removed.
Continue to use the "real" version of FastMM.
Related
I have a really old (Photoshop SDK for Delphi from Centaurix Interactive) component set. We could recompile it and successfully use it in our application without any problem. But it has started to create an access violation when we upgrade to Delphi 11.
If I change the line for memory allocation from
new(Stub) to Stub:= VirtualAlloc(nil, SizeOf(TStub), MEM_COMMIT, PAGE_EXECUTE_READWRITE)
it works at first, but it creates several 'memory problems' during further operations...
what's the reason for this issue, and is there any compiler directive or workaround to fix this?
Update : It is a Windows 32bit application and it could work with delphi 10.3 so it supports unicode.
I found the reason for this issue. it is not directly creating memory allocation but about creating a stub function for dll. Several PE security flags have been introduced in Delphi 11. you can find the details in Marco Cantu's blog.
One of them, DEP flag, apparently prevents some memory operations. If I uncheck it, the application works pretty well.
I use FastMM4, normally in full debug mode during development. If I turn off this mode should I arrange my app to go back to the Delphi (XE2) MM or is there a performance benefit in leaving FastMM4 linked all the time?
Delphi's memory manager (since D2007, IIRC D2006) is FastMM4, so you won't get any improvement in speed. The full FastMM4 might be faster, because you get improvements and bug fixes by using it straight from the source.
Up until now I am developing using Delphi 7. In order to pass f.e. TStringLists to my DLL's I use the FastShareMem unit as first unit in every program and dll I develop.
If I should migrate to Delphi-2010, Does FastShareMem still necessary ?
Thanks for any insight you may provide.
Short answer: No, SimpleShareMem comes with Delphi 2010
Long answer: Yes, Delphi still has its own memory manager and memory claimed from one memory manager (exe) can not be returned to another (dll). But since Delphi 2006 Delphi comes with a new memory manager called FastMM which can do the same as FastShareMem and also does not require any extra dlls to be distributed. You need to use a unit called SimpleShareMem. FastMM also has other nice features you might want to check out. FastMM is also available for Delphi 7 BTW.
You don't need to use any of those tricks if you compile with runtime packages, since the memory manager is then shared. It also comes with the advantage of sharing the same types. No more TFont can not be assigned to TFont problems. Of course this does mean you have to distribute the runtime packages.
No, use SimpleShareMem instead as first unit in your Application and DLL.
Delphi 2007 and above include now FastMM as default memory manager, which used by SimpleShareMem and no need to distribute any DLL with your application.
Currently we use Delphi 2007 because our application and some of our components are not compatible with Unicode. If and when we upgrade is it better to jump directly to Delphi 2010?
Propably, but I wonder if there is other compability issues except unicode?
How is performance, memory requirements and stability of those versions?
If you decide to upgrade, then yes, go with the latest version.
Delphi 2010 is definitely better than 2009, by not much though.
Don't expect your upgrade to be smooth.
For example: Delphi has a new version almost every year.
Then why it never helps you with the transfer of the settings between the versions?
Why all components are written in a way to lock you to the latest known version to the component? (this is not necessarily problem with Emabracadero, but they could provide guidelines)
Check if your components have '2010 version or you might need to fix hundreds of small but problematic lines of code.
No doubts, you should go directly to D2010, not to D2009 - in this aspect D2010 is actually more like D2009 SP1 than a fully new version, just with some nice additions like an updated RTTI. D2010 has no new known compatibility issues, has better stability, etc.
This is related to another Delphi-version question but still different;
I'm looking for a way to detect the service-pack (or build number) of the Delphi compiler that's compiling my code. The jedi.inc is nice, but it doesn't tell me the exact version. (I can't use the SUPPORTS_* defines in there either, as those are version-related too)
I need this, because some bugs are present in older versions (in this case, it's a _ValLong bug in Delphi 2009) that's fixed in a later service-pack (Delphi 2009 service pack 3 in this case).
Currently I have all kinds of checks in my code, like this :
{$IFDEF BUG_QC_68123}
But I can't just say this in my main include file :
{$IFDEF DELPHI2009_UP}
{$DEFINE BUG_QC_68123}
{$ENDIF}
...As this would miss the fact that D2009SP3 and later don't have this bug anymore.
Any ideas?
PS: This will probably also apply to older (and newer) versions of Delphi, so any library- and/or component-vendor will have an interest in this too, I presume.
There are symbols defined for each version:
VER80 - Delphi 1
VER90 - Delphi 2
VER100 - Delphi 3
VER120 - Delphi 4
VER130 - Delphi 5
VER140 - Delphi 6
VER150 - Delphi 7
VER160 - Delphi 8
VER170 - Delphi 2005
VER180 - Delphi 2006
VER180 - Delphi 2007
VER185 - Delphi 2007 (Note: symbol VER185, for example, is used to indicate Delphi 2007 compiler or an earlier version.)
VER190 - Delphi 2007 for .NET
VER200 - C++ Builder 2009
VER210 - Delphi 2010
VER220 - Delphi XE
VER230 - Delphi XE2
VER240 - Delphi XE3
VER250 - Delphi XE4
VER260 - Delphi XE5
VER270 - Delphi XE6
VER280 - Delphi XE7
WIN32 - Indicates that the operating environment is the Win32 API.
LINUX - Indicates that the operating environment is Linux
MSWINDOWS - Indicates that the operating environment is the MS Windows/li]
CONSOLE - Indicates that an application is being compiled as a console application
Source
Another source
You can't check for different build numbers.
And for the curious, VER10-VER70 where the turbo pascal versions, and VER110 was a C++ builder version.
Unfortunately, constants like RTLVersion in System.pas aren't updated in updates, but I think it would be a good suggestion if someone wants to make a QC entry for it.
If the bugs you are testing for are practical to reproduce in code, you could always test for them on startup and set your own global flags.
I get around these differences by making sure we always apply the latest updates. I haven't run in to a case yet where an update was unstable and forced me to roll it back. At least not with Delphi.
You could try including the compiler file version in your software. For example, DCC32.exe has a file version on it which you can programmatically get at and then write to a unit as a const. This could be done as part of your build process so it gets the version info before building your app (it'd be very easy to do with something like FinalBuilder).
I've done this for other things so that on our About screen we can get various bits of useful info. Also when we have an error in one our applications, we can bundle this info into our EurekaLog bug reports.
However I don't know if the file version on DCC32.exe is updated with every Delphi update.
The compiler does not expose that information. It only tells you the major version, which doesn't change when updates are applied.
I think the best you can do is to always write code for the latest update. Assume that consumers of your code will also have the latest update. If they don't, then it's their own fault, and not a problem you need to worry about. Mention it in your system requirements. Sure, your code won't work for them, but neither will anyone else's because they're still using known-bad code.
The next-best alternative is to write assuming that no updates have been applied. That is, write your code as though all known bugs are still present. The downside is that your code probably won't run as well as it otherwise could, so everyone who did the right thing by upgrading gets punished by continuing to have your suboptimal code.