Jump to content
Mike Torrettinni

What to do with unsupported components?

Recommended Posts

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?

Share this post


Link to post

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

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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

 

  • Like 2

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
Posted (edited)

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 by dummzeuch
  • Like 5

Share this post


Link to post
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.

  • Haha 1

Share this post


Link to post

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.

Share this post


Link to post
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.

  • Like 2

Share this post


Link to post
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?

Share this post


Link to post
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? 

Share this post


Link to post

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.

  • Like 2

Share this post


Link to post

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.

  • Thanks 1

Share this post


Link to post
Posted (edited)
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 by Holger Flick

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×