When converting components to Lazarus (see separate thread) I have encountered a problem for a component that interfaces to a software protection dongle.
My component files (pas) need to reference a unit + an obj file from the dongle maker. In the maker's pas file is this:

IMPLEMENTATION
USES
   Windows;
{$L SPROMEPS.OBJ}  { LINK WITH THE SUPERPRO OBJECT FILE }

The Spromeps.obj file is located in the same directory as the source files and in package manager I have added the main component source file and checked that it compiles without errors. OK. When the component source file was added PM asked if the path to the file should be added to the search path, so I expected it to be known...

But when I command PM to install the package and it asks to rebuild Lazarus this happens:

Build IDE: Exit code 2, Errors: 1, Warnings: 2
lazarus.pp(161,1) Warning: Object SPROMEPS.OBJ not found, Linking may
fail !
lazarus.pp(161,1) Warning: Object SPROMEPS.OBJ not found, Linking may
fail !
lazarus.pp(161,1) Error: Can't open object file: SPROMEPS.OBJ

I tried to add the obj file to the files for the package but it did not change anything.

I also tried Package/Options/Compiler options/Paths and added the path to the component to Libraries

But it caused the same error on Lazarus rebuild...

So how do I tell Lazarus that this file is available?

Your package must inherit an object search path.

Package editor / Options / Package Options / Add path to dependent packages / Object

Add '$(PkgDir)' without quotes.

When the component source file was added PM asked if the path to the file should be added to the search path, so I expected it to be known...

Pascal sources and object files have different search paths.

Mattias

I did this literally as you wrote. So my Package options Object box contains the text $(PkgDir)

It does not work, Lazarus does not find the obj file anyway.

So next I tried:
$(PkgDir)\..\Sentinel

This time it passed the previous error only to arrive at:

lazarus.pp(161,1) Error: Illegal COFF Magic while reading
D:\Engineering\Projects\Subversion\EI\CMPFPC\Sentinel\SPROMEPS.OBJ

Does this mean that the OBJ file that has worked for more than 15 yesra on different versions of Delphi is somehow of a format not acceptable by Lazarus?

What is COFF Magic?

Glad you figured that out. I don't know your setup (yet).

Find out the format of your obj file and then find a converter to COFF format, which fpc require. Maybe objconv can be used for that. I never tried.

Mattias

Mattias Gaertner wrote

Find out the format of your obj file and then find a converter to COFF format, which fpc require. Maybe objconv can be used for that. I never tried.

Meanwhile I found an old post in the lazarus forum: https://forum.lazarus.freepascal.org/index.php?topic=30324.0

It directed me to objconv, so I have tried to use it but even though it brings me somewhat further I have banged my head aginst this now:

Compile package customcmpfpc 0.0: Success
Build IDE: Exit code 2, Errors: 23
lazarus.pp(161,1) Error: Undefined symbol:
SPROMEPS_$$_RNBOSPROFORMATPACKET$RB_SPRO_APIPACKET_PTR$WORD$$WORD ....
lazarus.pp(161,1) Error: Undefined symbol:
SPROMEPS_$$_RNBOSPROQUERY$RB_SPRO_APIPACKET_PTR$WORD$POINTER$POINTER$POINTER$WORD$$WORD lazarus.pp(161,1) Error: Undefined symbol: GetVersion ....
lazarus.pp(161,1) Error: Undefined symbol: CreateFileA

I will have to systemize my tests later tonight and try every possible permutation of objconv arguments....

Bo Berglund wrote

... Build IDE: Exit code 2, Errors: 23 ...

You want to compile some 3rd party Dongle code in the IDE ?

That is more than weired !

-Michael

Sorry, I don't really know what you mean here...
What is the reason for this comment?
Unlike Delphi it seems like when one wants to add components to the development IDE palette in Lazarus one has actually to *rebuild* the IDE, there seems to be no otehr way...

We have analysis software (developed in Delphi) that we sell and it is protected by the dongle.
Now I was looking at migrating our code to Lazarus/FPC and in that process I had to also convert the custom components used in our code to Lazarus. I managed to do so (with help from some people here) save for 2 components, one is a TRichEdit derivative, which I think is not really used, and the other is this dongle interface.

Now, for historical reasons, the dongle code was implemented as a Delphi component contained in a component package in Delphi, so that is why I am struggling to convert it.

However late last night I ran across an earlier attempt I had at this about 3 years ago. In the leftover files on my disk I found a Lazarus application that can actually interface with the dongle!

I also found a batch file that processed the SPROMEPS.OBJ file to produce a COFF file (using objconv) for use in this test.

So I tried to copy this apparently working COFF file to my package conversion project and edited the calling code to use this. But when I tried installing the package I got the exact same errors and Lazarus would not rebuild.

When I examined the main dongle file I noticed that I had earlier modified it so it is not a component file anymore, just an ordinary class definition file.

So now the plan is to take this modified class file and use it in the migrated project without the component paradigm and see what happens...

Yes. But you don't need to 'install' every package. Only those with actual IDE code.

Since your package contains Register procedures it probably has design time stuff.

Mattias

In this case with IDE code do you mean it contains a GUI visible part that can be manipulated inside Lazarus (like a listbox for example)? THere is no such thing. When dropped on a form only the icon shows up and it is invisible in the running program.

Since your package contains Register procedures it probably has design time stuff.

I don't know what counts as "design time stuff"... There is no GUI stuff in the it can be dropped on a form just like a Dialog component can. Then it is possible to manipulate the published properties of the component in the Delphi Object Inspector.
And there is one event handler OnKeyAlarm that can be implemented via the Events tab in Object Inspector.

If this counts as "design time stuff" then it has.

I mentioned the 3-year old de-componentified version of the source file I found in an experimental folder on my hard disk. This has been stripped of the component parts (like the Register method), but it has the same set of public and published properties as the original.

So if I manage to port the least complex of the analysis programs I will use the dongle class file rather than the component. The strange thing is that the included library (COFF file) seems to work in Lazarus in this use case, but not when trying to install as a component....

I am converting data acquisition software to Lazarus that uses the same dongle:
http://forum.lazarus-ide.org/index.php/topic,40040.0.html

Can I hire you Bo?

Yes.

Mattias

As fpc/Lazarus dos not (yet) provide run time packages, and IMHO it will ask for major problems when compiling the Lazarus IDE to contain the Dongle code, I suppose your best option is to replace the Dongle .OBJ file by a small pascal function and use this to build your package to allow it for compiling the IDE (providing the design time stuff) and the user program (providing the run time stuff).

Now you need to "fake" the runtime package behavior by doing the said small pascal function in a way that it dynamically (not in the startup code !) loads and then uses a dll .

The dll would be done in a way that it just forwards the call to the functions provided by Dongle .OBJ to same, and statically links to it.

-Michael

Michael Schnell via Lazarus schrieb am Di.,
12. Juni 2018, 10:37:

Would you please stop spreading nonsense? Only because the code is part of a package that's loaded by the Delphi IDE does not mean that it also is one in the final Delphi program. Delphi package distributions more often than not also contain the DCU for static linking.

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180612/f3c2b220/attachment.html>

Sven Barth wrote

 Only because the code is part of a package that's loaded by the Delphi IDE does not mean that it also is one in the final Delphi program. Delphi package distributions more often than not also contain the DCU for static linking.

Of course you are correct that in Delphi a package can be linked dynamically to the IDE (it can't be linked statically, as the IDE never is recompiled), but statically in the final executable.

But Lazarus does not provide dynamic linking to the IDE in such a way. That is why the IDE needs to be recompiled when adding a package with "design time stuff". (IMHO this is not harmful at all.)

Am I wrong supposing that this means that the package will be statically linked to both the IDE and the executable, and hence it content will be linked in with both ?

AFAIU, there are means to control how the code is executed at runtime and how at design time, but this does not affect linking.

Hence the dongle code will be linked in with the IDE and might (or might not) provide problems.

-Michael

Michael Schnell via Lazarus schrieb am Di.,
12. Juni 2018, 11:48:

Hence the dongle code will be linked in with the IDE and might (or might not) provide problems.

The dongle code would also be linked if it would be in a dynamic package and Lazarus would support them.
The important point is what a component does while in design mode (e.g. the OpenGL component does not initialize a OpenGL context in design mode). As long as the component does not use the dongle code while in design mode then nothing happens no matter whether it is linked dynamically or statically.

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180612/d25ef620/attachment.html>

Sven Barth wrote

The dongle code would also be linked if it would be in a dynamic package and Lazarus would support them.

Sorry, I seem not to be have been clear.

The (potential) problem I want to provide a solution for is: not to link the Dongle code in the Lazarus IDE executable. (But have it usable in the compiled user application.)
(Delphi does this by using the dynamic linking for the package the Delphi IDE uses, but this is of no concern when doing Lazarus.)

That is why I suggest to avoid the Dongle code in the package altogether, and have it only dynamically linked late (on request, which only is supposed top occur with the user application).

-Michael

Michael Schnell via Lazarus schrieb am Di.,
12. Juni 2018, 15:25:

No. Delphi does *not* solve this by using dynamic linking. If a package is installed in the IDE (no matter whether it is Delphi or Lazarus) its code becomes part of the running process (for Delphi when the package is loaded at IDE start, for Lazarus during compilation and linking). The execution of the dongle code is only prevented if the developer of the component checked whether the design mode is active and does not execute the dongle code in that case (or the component is not used, because a project is loaded that does not use the component).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180612/bc8b0775/attachment.html>

Sven Barth wrote

No. Delphi does *not* solve this by using dynamic linking.

OK. I see. Thanks for pointing this out.

Hence in such a (potentially problematic) case the suggested solution might be helpful even with Delphi.

But as Bo's code seemingly works fin with Delphi, hopefully compiling the Dongle code into the Lazarus IDE will simply work as expected.

-Michael

I gave up on having the dongle as part of the IDE since simply creating the object in application code as needed is OK. It works in that setting so the OBJ file after conversion to CUFF format seems to be OK for the application even though Lazarus itself a real issue enymore. The concept of dropping a component on a form to use it is coming from when we started using Delphi a long time ago.
And the non-visual components were dropped on a data module at the time.

I need to use the *same* security dongle in Lazarus. I don't want to change to a different dongle.

I'd like a few more details on how to create the object in application code.

Any links to other discussion of this issue would be appreciated.

Thanks *very* much Bo!

Paul Breneman wrote

I need to use the *same* security dongle in Lazarus. I don't want to change to a different dongle.

Since Safenet does not provide any new OBJ file n´than the one fpc cannot use the only path seems to be to somehow convert it using objconv.
But I have not yet succeeded and have given up because even if it would be successful the solution relies on a vendor specific driver for the operating system it will run on.
And we have had lots of problems over the years with their dongle driver for Windows.

I'd like a few more details on how to create the object in application code.

Simple:

var
  MyDongle: TMyDongleType;
begin
  MyDongle := TMyDongleType(NIL);
  try
    ....use the dongle functions....
  finally
    MyDongle.Free;
  end;
end;

You can also declare the dongle variable in global scope and use it in more places.

The NIL argument is needed if the dongle is defined as a component descendant since it has an owner:

type
  TMyDongle = class(TComponent);

On 07/27/2018 02:36 AM, Bo Berglund via Lazarus wrote: ...

And we have had lots of problems over the years with their dongle driver for Windows.

Thankfully we've not experienced that.

Thanks Bo for your comments!

Regards,
Paul
www.ControlPascal.com