What to do with unsupported components?

[Mike Torrettinni 198]

I have a situation where a parsing component (non visual) is not available for Delphi 10.3, and I don't have access to the sources - I have dcu files. If I want to move the project to 10.3, I see these options:

- replace parsing component (couldn't find any comparable component that is up to date)

- wrap parsing functionality into DLL and use in the 10.3 project

- write my own replacement - probably 3 weeks of dev time (would span across several months as is not a priority) - this means delayed moving to 10.3

 

I like the DLL option, but the client is not too happy about it as they don't want to have additional external files for deployment.

 

Are there any other options?

[timfrost 79]

The obvious one that you have missed is to use an earlier version of Delphi, that matches the DCU version.

[Bill Meyer 337]

5 minutes ago, Mike Torrettinni said:

I like the DLL option, but the client is not too happy about it as they don't want to have additional external files for deployment.

 

Are there any other options?

Been there, went with a DLL. The component was unsupported, the vendor gone, and no source. As it was an encryption tool, and not easily reverse engineered because of compatibility issues, we had no real choice. Comparable components using the "same" algorithm delivered quite different results.

[Uwe Raabe 2064]

3 minutes ago, timfrost said:

The obvious one that you have missed is to use an earlier version of Delphi, that matches the DCU version.

That is somewhat against the introducing condition ruling that option out in the first place.

9 minutes ago, Mike Torrettinni said:

If I want to move the project to 10.3

 

[Mike Torrettinni 198]

6 minutes ago, timfrost said:

The obvious one that you have missed is to use an earlier version of Delphi, that matches the DCU version.

Oh, yes, sorry. The full project is in Delphi 7, they have prototypes ready in 10.2 (where the parsing components is available), but want to move all to 10.3 now. If they move to newer version, they want to move to newest Delphi version. I was only tasked for this component and it is only small part of the whole project... so not enough to stop the whole move.

[Mike Torrettinni 198]

5 minutes ago, Bill Meyer said:

Been there, went with a DLL. The component was unsupported, the vendor gone, and no source. As it was an encryption tool, and not easily reverse engineered because of compatibility issues, we had no real choice. Comparable components using the "same" algorithm delivered quite different results.

Yes, similar thing, it would be a lot of trial and error to replicate the parsing engine, so I thought DLL would be just fin for now. Was there any significant performance penalty or not noticeable?

[Bill Meyer 337]

1 minute ago, Mike Torrettinni said:

Yes, similar thing, it would be a lot of trial and error to replicate the parsing engine, so I thought DLL would be just fin for now. Was there any significant performance penalty or not noticeable?

Not noticeable, but this was years ago, and I don't recall how large the encrypted files were. We were moving from D6 to D2006 at the time.

[dummzeuch 1517]

I think you found all options. There are no others.

 

I would

1. Kick the person who bought this component without source. (Who was / is an idiot, nobody did that even back when Delphi 7 was new.)
2. Suggest not updating to Delphi 10.3 but 10.2 (which will be rejected)
3. Go with the DLL solution.

Edited March 27, 2019 by dummzeuch

[Bill Meyer 337]

2 minutes ago, dummzeuch said:

1. Kick the person who bought this component without source. (Who was / is an idiot, nobody did that even back when Delphi 7 was new.)

In my case, it was worse. All evidence suggested that we had no source because we (probably) had no license.

[Mike Torrettinni 198]

I'm getting only very limited information about the situation with this component, but seems like the sources were like 10x of the component price, which at the time of purchasing was not approved, or something similar.

[Remy Lebeau 1436]

2 hours ago, Mike Torrettinni said:

I like the DLL option, but the client is not too happy about it as they don't want to have additional external files for deployment.

You could always embed the DLL in the EXE's resources and then extract it at runtime before using its functions.  That way, the DLL does not have to be deployed separately.

[Mike Torrettinni 198]

6 minutes ago, Remy Lebeau said:

You could always embed the DLL in the EXE's resources and then extract it at runtime before using its functions.  That way, the DLL does not have to be deployed separately.

This is interesting... quick search on this topic gives show some challenges with antivirus and anti malware software. I assume with right approach, this should be a non-issue, right?

[David Heffernan 2353]

5 hours ago, Mike Torrettinni said:

 

I like the DLL option, but the client is not too happy about it as they don't want to have additional external files for deployment.

Spend the time to get the deployment right and it's no problem. If you can deploy a single exe file then you can deploy a dll alongside it. If anyone is complaining then perhaps you aren't deploying correctly. I wonder, you aren't trying to deploy to system 32? 

[Mike Torrettinni 198]

I think they are realizing the dll option is not that bad.

[Edwin Yip 154]

DLL seems to be the way to go.

This reminds me the now on going discussion about not to buy a library without source in the other thread which announced a new commercial SVG library library.

[dummzeuch 1517]

Embedding a DLL can be done without extracting it (at least for some DLLs for 32 bit Windows programs). But I am not sure whether this would work with that DLL.

 

My dzlib contains a unit for that: u_dzRessourceDllLoader.

[Holger Flick 12]

23 hours ago, Mike Torrettinni said:

I like the DLL option, but the client is not too happy about it as they don't want to have additional external files for deployment.

(I apologize as I did not see the posts initially that suggest exactly the same approach!)

 

Add the DLL as a resource into the exe and extract it into the user directory etc. when it does not exist on the system. So the customer still deploys only an exe file... You could even do that for many files that you zip and then put as a resource into your exe.  RCDATA makes this very easy and there are functions in the RTL (SysUtils if I am not mistaken). Furthermore, Delphi RTL now has ZIP included that will also allow for the zip approach.

 

Is it crazy, yes, but it will make the customer happy and you can use a more recent version of Delphi.

Edited March 28, 2019 by Holger Flick

[Darian Miller 366]

Curious - what's the component?