Has anyone ported the SafeMM debugging memory manager to Delphi XE2? The 2009 SafeMM on CodeCentral won't compile because the RTL now uses NativeInt instead of Integer for the memory functions.
I've uploaded my Delphi XE2 port of SafeMM to CodeCentral. I've verified that it correctly allocates blocks larger than 4 GB and that it can allocate more than 4 GB worth of smaller blocks when used in a Win64 application and that it still works correctly in Win32 applications.
I've updated my CodeCentral submission on 7 July 2012 to fix a bug that causes SafeMM to crash when two threads try to free a large block (> 4KB) at the same time. This bug was introduced in version 0.3 of SafeMM by its original developer. If you're using this version of SafeMM with an older version of Delphi, you'll need to wrap the code in FreeLargeBlock in a critical section as I did in my version.
Related
I'm running into some problems with sending SMTP messages in XE4 64-bit, and it appears that it's happening somewhere deep in the guts of the Indy code.
It's the standard Indy code that shipped with XE4, but when I look at the headers at the top of each file, it appears that they haven't been updated since 2005! Obviously there's something screwy going on here.
How old is the version of Indy that was shipped with XE4, and have there been significant improvements in Win64 compatibility since then?
The version shipped with XE4 is 10.6.0.4975.
ShowMessage('Indy version: ' + IdHTTP1.Version);
From the indy change log:
Indy 10.6.0 - XE4 Release
------------------------------------------------------------------------
r4986 | Indy-RemyLebeau | 2013-04-14 19:08:12 +0200 (Sun, 14 Apr 2013) | 1 line
So it's from mid April 2013.
The latest version is 10.6.0.5152. I don't see anything in the change log about 64 bit but a lot of the comments are really broad (e.g. "Patches from Jose Antonio Sanchez Lazaro")
http://indy.fulgan.com/indy10.changelog.txt
The comments you see at the top of each source file are remnants of another version control (TeamCoherence) that Indy stopped using years ago. Indy uses SVN now, which does not store revision history in the source code.
Indy has supported 64-bit since at least XE2, when 64-bit was first added to Delphi (maybe even earlier, for FreePascal support).
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to also prepare for 64-bits when migrating to Delphi 2010 and Unicode
I have already developed an application in Delphi 7. Now I need to enable it to support 64 bit.
Delphi 7, and indeed all released Delphi Win32 versions, only produce 32 bit executables. However, 32 bit executables run perfectly well on 64 bit operating systems through the WOW64 emulator. Although this is an emulator, a word that usually implies degraded performance, WOW64 performance is not readily distinguishable from native 64 bit performance.
If you wish to port your Delphi app to 64 bit you need to wait for the next version of Delphi to be released which will produce 64 bit executables.
Then you will have to port your app from Delphi 7 to the latest version of Delphi. This will be a big job because you will also have to port from ANSI string code to Unicode string code. In my view this part of the port will be more time consuming than the 32 to 64 bit part and if you wanted to get a head start you would be wise to start the Unicode port now by upgrading to Delphi XE.
You can check this official Embarcadero video which covers the subject.
As the title suggests!
I'm trying to get a 64bit dll
No.
Nope. Delphi 7 was released in 2002; the first AMD64 processor was released in 2003. No way Delphi 7 knows how to generate 64-bit code.
All released versions of Delphi following the 16 bit Delphi 1 emit 32 bit targets. At the moment your options are:
Wait until the upcoming 64 bit Delphi release. We anticipate this some time this year, but your port will be non-trivial.
Port to FreePascal. Again, a non-trivial port.
Port to a completely different language: even more work than porting to Free Pascal.
Carry on running 32 bit code.
Compiling a program means to translate your source files into CPU opcodes (and something more, it has to generate a executable image that can work on the OS it was designed for, respecting the OS ABI - Application Binary Interface). Each type of CPU has its own set of opcodes, and even if the Intel x86 architecture has many similarities among 16, 32 and 64 bit opcodes, there are enough differences and the ABI is anyway different.
Creating a 64 bit exe/dll means to generate 64 bit opcodes using also the new 64 bit ABI, and to do that a compiler must be written to "know" them, what a compiler can do is defined by how the compiler itself is written, not by the system it is run on. Delphi 7 compiler "doesn't know" about 64 bit CPUs and exe/dll ABI, and thereby can't generate it. This is true as well up to Delphi XE. The next version should be the first one to come with a 64 bit compiler, you can wait for it, or if you're in a hurry there are some partially compatible compilers like FPC.
From what I've read from the previous posts, Delphi 7 is stable and has the best help system but is slow, Delphi 2007 is fast but the help system is bad and the IDE is buggy. Delphi 2009 is stable and fast but the help system is bad too. The posts were made when 2010 isn't available yet. I am planning to upgrade from Delphi 7 to 2010. Is Delphi 2010 stable, fast and has a good help system?
Delphi 2010 is one of the best Delphi releases ever. It stabilizes some of the new features introduced in Delphi 2009. The IDE is fast, and in the project I used it was very stable.
The thing there is that the IDE and the help system are build as a RAD Studio for different languages. Especially the help system tries to be everything for everybody. Even having only one personality installed, it has many entires about other languages I do not care about (but I can filter them). Yet there are many entires missing depth that never made it into the new help format.
The help system starts painstakingly slow (especially at first startup). But, to be fair, this is partially do to the MS Help System being a pain in the neck (this, in my opinion, just was the wrong path to chose).
Embarcadero invests quite some effort into the help system, and it had several updates during the 2010 release.
You do know about the varying expense of conversion to Unicode as 2010 is fully Unicode based?
Here are some reasons why I stick to Delphi 7, having Delphi 2010 at hand to recompile and test what I wrote in Delphi 7, in a cross-version manner:
if your source code compiles on Delphi 7, and you make careful usage of Unicode/AnsiString, it will work as well with Delphi 2010;
if your source code compiles on Delphi 7, it will work as well with Free Pascal, so
cross-platform and 64 bits are open to you;
if your source code compiles on Delphi 7, it can be cross-compiled with CrossKylix directly from the Delphi 7 IDE - see Has any one used CrossKylix for real Cross-platform development?
Delphi 7 runs well on my Windows Seven 64 bits system, if you install it not in "C:\Program Files" but in "C:\Progs" for example;
Delphi 7 starts faster than Delphi 2007, and MUCH faster than Delphi 2009/2010 - see http://andy.jgknet.de/dspeedup
generated code is almost the same since Delphi 7 - when I need speed, I use better algorithms, and assembler if it's worth it;
Delphi 7 IDE is as powerful as Delphi 2010 IDE, if you use some IDE enhancements like http://www.cnpack.org;
Delphi 7 help is still the reference - why waiting for 20 seconds on my Core i7 processor waiting for the awful MS help system to launch? and if you want to create an application able to run under XP, its content will be enough for you; if you want to know about newer OS, just use msdn web site directly, or via google: it sounded to me easier than the help integrated with Delphi 2005/2010;
I use the assembler/CPU view a lot: all Delphi IDE have the Alt-F2, but you can close this window by the escape key on Delphi 7 - I was not able to find such a keyboard shortcut under Delphi 2007/2010, and it's very annoying;
Delphi 7 executable size are small, and even smaller with our LVCL libraries (30 KB for a form with buttons);
I didn't have the need for generics and such up to now - I like knowing which code is generated;
Delphi 7 is Unicode ready, whatever you say - its associated VCL was not, but CharSets are not evil, and work well - what I do is develop under Delphi 7, then compile with Delphi 2010 and get all the Unicode benefits if needed;
I use a large screen (at 1920x1280 resolution), and Delphi 7 makes it easy to have multiple edit windows at once - newer IDE locked layout was not a good idea... at such that EMB officially added the "Delphi 7 way undocked IDE" feature to Delphi 2010: and marketing sell it as a new feature;
and so on, and so on...
You can use Delphi 7 help in Delphi 2010, if you want to.
Use this or this addon. See item 5 here for instructions (sorry, it's machine auto-tranlation).
P.S. You can have more than one help installed. Say, a F1 for Delphi 7 help and Ctrl+F1 for Delphi 2010 help.
delphi 2010 is stable and fast and is actually a good delphi compiler after years of half-baked releases, they have improved help system in delphi 2010 but i still think delphi 7 help system is superior(but thats just my opinion).you do know delphi 2010 has a 1 month trial do you? download it and play around and see if you like it
EDIT: forgot to mention if you buy delphi 2010 you'll get marco cantu's Delphi 2010 Handbook for free ,the book covers whats new in D2010 so if you consider book as part of help system than help system is OK :)
Delphi7 was faster, but it was a lot simpler. I wouldn't worry too much about performance of the IDE, especially if you're working on a modern PC. At work I've got an old P4 machine, and it runs just fine.
New language features like methods on records and generics make it well worth it to switch.
For me it's hard to live without TList<T> nowadays.
For a while I've desperately tried to keep code Delphi7-compatible, but I've ported most of the important applications to D2010 already, and whenever I need to start D7, it all feels so low-tech and simple.
I've always hated the crappy component palette in the older Delphi's. Delphi 2010 has a much better interface, and the filter function is a real time-saver.
I've decided to give up on Delphi7 and just make full use of D2010's capabilities. That makes life a lot easier.
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.