Evaluation of RemObjects DataAbstract for Delphi blocked by Indy 10 nightmare

Relativity Server
1

My delphi 2007 apps all rely on a newer version of Indy than the IndyCore100 and IndyProtocols100 bpls that ships with Delphi 7. The binary-only evaluation package for RemObjects data abstract (demos were ever thus) relies both on its own internal Indy package (fine! good!) but also on the standard indy component bpl being present and loadable from the path. I am guessing there’s no way around this Indy DLL Hell problem when evaluating? I should probably evaluate on a non-production system that has Delphi 2007 installed, and still has the factory indy BPLs on it, right?

Idea for future: It would be nice if the PascalScript_RO_D11.bpl depended on RemObjects_Indy_D11 instead of depending on the IndyCore100 and IndyProtocols100.bpls that ship in Delphi 2007.

For instance, Delphi IDEs have some pretty NASTY failure modes when two or more BPLs load into the IDE at the same time, containing the same class names, and so it’s NICE that the RemObjects_Indy_Dxx.bpls have different names and so they can co-exist in the IDE at the same time as some other component using the default names. If only this had been taken to its logical conclusion and done throughout the product?

Anyways. What should I do? I can’t go back to the stock Indy BPLs without wrecking my system. I suppose I could try to get the Evaluation/Trial to run in an alternative Delphi key and run “bds.exe -RBDS_ALT”, but that looks like a giant hell. Clean non-production evaluation machine or virtual machine only, is probably the only reasonable sane alternative to evaluate this product, right?

2
warrenpostmagmailcom said: I should probably evaluate on a non-production system that has Delphi 2007 installed, and still has the factory indy BPLs on it, right?

unfortunately yes, the Indy issue cant be circumvented with trial DCUs, as we cant provide DUCs that will match your exact version :(. there’s two options:

(a) as you suggest, evaluate on a clean VM with standard INDY

(b) simply dont install the RO_Indy package, and use out other channels, such as Synapse (which i hear is better anyways) for your evaluation. all the functionality should be the same.

3

Well if Synapse works better anyways, then I’ll try that first. Thanks.

4

Now I get stuck here: "access violation at address 02df7c38 in module RemObjects_Indy_11.bpl’, read of address 00000088. Sigh!
Also the standard IndyCore100.bpl starts crashing immediately after that, in TIdCustomTCPServer.GetDefaultPort (line 572), according to my MadExcept tracebacks.

5

Okay it all works now on a completely clean VM. That appears to be the best way to evaluate the product.

6

you dont wanna have RemObjects_Indy_11.bpl get installed/loaded at all, if you are using a custom Indy.

7

Okay thanks. I think that if we go with this, we’d be using a purely Synapse transport layer, and dropping an RO Indy and non-RO indy packages from it.