Is it possible to recompile the DataSnap packages in Delphi XE with a new/different version of Indy?

Question

Okay -- we have an interesting problem.

Some background:

1. 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.

2. We are migrating to Delphi XE and want to start using DataSnap.

3. DataSnap requires the "official, shipping" version of Indy which is incompatible with our customized version of Indy.

4. 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.

Dupleix

Why does DataSnap not work with your Indy version? Are you changing the interface? – Tranship

I have never been able to find the DPK's for these Packages. – Ani

@David -- Hmm. Not sure. Checking.... and they say that they don't believe so. That might be a route to a solution -- apply our fixes to the shipping version. We've been using a newer version of Indy, but the XE shipping version might work. – Dupleix

@Nick I'm not quite sure how the linkage works between these things, and I know nothing about Indy and DataSnap. But it seems to me that so long as the interface to Indy is what DataSnap is expecting then it should have no grounds for rejecting it. If the interface changes then you'd get the dreaded "foo.dcu was compiled with a different version of bar.dcu" message. – Tranship

More info: We've discovered that you can do some digging and find out what is in all the runtime packages and recreate them for DataSnap. However, the source for the design-time support is not available. – Dupleix

I resolved a similar problem once by starting Delphi as another user (via Sysinternals ShellRunAs) with different packages loaded and different search pathes. Needs a little bit of work to configure both Delphi versions, especially when keeping them up to date. – Ill

@Uwe: wouldn't using the IDE's -p parameter be much easier? – Slabber

@afrazier: if it were only the IDE to use a different registry part, yes. But I also have to use different settings for ModelMaker Code Explorer which doesn't care about the -p option. – Ill

@David: the problem is sometimes Indy breaks interfaces even in "minor" releases, unluckily. That makes impossible switching to a newer version without rebuild (and fixing) dependant libraries. Delphi doesn't ship packages code probably to avoid people deploying their own version of standard packages easily (but I guess it would be better to switch to a stronger model, i.e. signing standard packages, strong names and the like), while letting package recompiling if needed. But Hodges should know all that far better than us, having been Delphi Product Manager... – Milker

Answer 1

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.

Tiber

Embarcadero will address the DataSnap/Indy issue in the upcoming XE2 release so users can upgrade Indy independantly without breaking DataSnap anymore. – Sendal

@Mjn: the problem is DataSnap is a Delphi library... you should not use the whole RTL/VCL as well because you don't have full source code (packages...)! :D – Milker

You do have full source code to the RTL and most of the VCL, just not datasnap, and a few of the other "Architect/Enterprise" SKU elements. I really hope this gets fixed in XE2. – Fossilize

Answer 2

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

Puerperal