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).
Related
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.
Okay -- we have an interesting problem.
Some background:
Our main application uses Indy 10. However, we take the Indy 10
source and fix bugs in it, recompile, and install our own set of Indy
components.
We are migrating to Delphi XE and want to start using DataSnap.
DataSnap requires the "official, shipping" version of Indy which is
incompatible with our customized version of Indy.
Our DataSnap servers will be separate applications, but since we
have our own Indy installed in the IDE, we can't "cross the streams".
Okay, therefore, we are unable to use Delphi XE's DataSnap out of the
box because of this compatibility issue.
So my questions is this:
Is it possible to recompile the DataSnap packages in Delphi XE with a new/different version of Indy?
Your thoughts gratefully accepted.
The common belief is No, that's not possible due to not all sources being provided by Embarcadero and some of these sources are reliant on the build of Indy as shipped. (Which is extremely frustrating to end users as the version of Indy that ships with Delphi is out of date relatively quickly and sometimes the version selected at the time is not necessarily a very good one.)
See related SO question:
Is it possible to use Indy 10.5.8.0 in Delphi XE and DataSnap?
Also see the Indy project page:
http://www.indyproject.org/Sockets/Docs/indy10Installation.de.aspx
which states:
Note: In D/CB/RAD 2009+, DataSnap uses
Indy 10 internally. Installing a new
version of Indy will render DataSnap
unusable, as it will not be able to
load the Indy packages anymore.
DataSnap is compiled against the Indy
packages that ship with the IDE, and
DataSnap cannot be recompiled by end
users. If you need to use DataSnap,
then you will need to maintain the
original Indy 10 packages for use in
DataSnap projects.
It's been said that the next version should hopefully allow for easier updates of Indy.
If all DataSnap source is included, is of course possible using some kind of PE executable analisys program to detect which classes and units are used in BPL (as BPLs are just customized DLLs). An very easy one to use is provided with GExperts.
In BPLs, the exports list lines from GExperts\PE Information have an format like #xp$#[nn][UnitName]#[TypeName] (for types) and #[UnitName]{#[Type>]}#[Unit global element like procedures or variables] (for the rest).
You can save that list to a file and GREP to get an list of Units used on a BPL.
Real Examples (vcl140.bpl):
#$xp$11Forms#TForm
#Appevnts#TCustomApplicationEvents#Activate
#Clipbrd#Clipboard
ive a news server Built on Delphi7, using Indy9 TIdTCPServer, and the clients are using TClientSocket from ScktComp for size, and the traffic is encrypted in RC4 (string)
what exactly do i need to make my app work on XE or 2010 with Unicode support? what of these things will i have to change?
Unicode has introduced in Delphi 2009, so if you want the unicode support you can do it with Delphi 2009.
But if you are going to upgrade, get the latest one, you can get all the benefits of Delphi 2010 with less bugs and more Third party tools bundled with Delphi XE.
the other problem may you face is the translation between Indy 9 to Indy 10, because unicode support added to Indy 10, but also it's not 100% compatible with Indy 9.
I suggest you to try to compile your application with Delphi 7 and Indy 10, then move later to Delphi XE with Indy 10.
Don't know if Indy 9 is still supported on XE and 2010. Indy 10 has improvements but also some breaking changes. Moving binary data into strings is IMHO never a good choice, but depending the situation it could just need some minor changes. What you exactly need depends on your application code - without actually looking at it is difficult to say. All string manipulation routine should be checked, especially if you use them as low-level binary buffers, and the select which path is best to port them to the Unicode world.
I am a user of Orpheus. There is nothing better for table handlin,f.ex.
I have downloaded your version for D2009. How do you get it work for You with
all the CHARs in there, and without using H- for the strings ?
I think the project is maintained at sourceforge TurboPower Orpheus. The version called 4.07 Unicode likely supports Delphi 2009. There's also another build on May 22, 2009 by SongBeamer. Thread: Disabling Unicode in D2009? mentions it.
FWIW, Nick Hodges is now the admin of the sourceforge project. It should be updated soon to support 2009/2010.
Why is there an Indy9 folder (The default install folder of C:\Program Files\CodeGear\RAD Studio\6.0\source\Indy contains subdirectories for "Indy9" and "Indy10") Why are both versions installed? What is using Indy9? I didn't think it had been updated for 2009...is Indy9 now safe to use with Delphi 2009?
There is an opened QC report about this, but it's only visible to QC sysops.
The status of "open" typically means that it's accepted that this is a bug, rather than by design.
Remy Lebeau - one of the Indy developers - said this:
The 2009 installer does ship with the
Indy 9 source code, but it is not
selectable during install. There is a
note in the documentation that Indy 9
can be installed manually if needed.
But keep in mind that Indy 9 has not
been updated to actually support 2009.
At the moment, I am not sure if it
will be.
There are some changes in Indy 9 (from the 2007 version) so that it will compile under Delphi 2009 (a few String to AnsiString changes), but based on my tests it doesn't work. It tries to, but does not connect. If you want I can give you the changes that have been added for Unicode support, but I don't believe they are sufficient.
I can't really answer why. I could conjecture a few reasons, but I do not have any insider information.
Is it safe to use? YMMV. There is a lot to Indy, so there may be some parts that work fine for your project. Even a simple test with the TIdTCPClient resulted in Socket Error #11004 every time. Same for TIdHTTP. It seems like I tried the MD5 previously and it just got garbage, but I am not sure on that one.
Answer: It was included by mistake (assumption), and it is not safe to use (based on limited tests).
That is unfortunate, because Indy 10 has issues too, and I have some legacy apps that use Indy 9.
Indy9 is there for compatibility. There were some breaking changes in Indy10 (your code that was written against Indy9 may not compile under Indy10) so you have the option of continuing to use Indy9 (I think the installer prompts and asks what Indy you want to use - at least it did with D2007).
Update: Okay a few people have correctly commented that Indy9 wont compile with D2009 (because of the new Unicode support), so I guess I don't know why it is there.
My guess, it was in the source tree, and was automatically included by installer.
Keep in mind that the source files are not used unless you tell Delphi to recompile them.
If you do not have the Enterprise version you will not even have these folders.