Discussion:
[Lazarus] Using a component OBJ file in Lazarus?
Bo Berglund via Lazarus
2018-06-10 10:37:32 UTC
Permalink
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?
--
Bo Berglund
Developer in Sweden

--
Mattias Gaertner via Lazarus
2018-06-10 10:58:42 UTC
Permalink
On Sun, 10 Jun 2018 12:37:32 +0200
Post by Bo Berglund via Lazarus
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
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.
Your package must inherit an object search path.

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

Add '$(PkgDir)' without quotes.
Post by Bo Berglund via Lazarus
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
--
Bo Berglund via Lazarus
2018-06-10 12:15:06 UTC
Permalink
On Sun, 10 Jun 2018 12:58:42 +0200, Mattias Gaertner via Lazarus
Post by Mattias Gaertner via Lazarus
Your package must inherit an object search path.
Package editor / Options / Package Options / Add path to dependent
packages / Object
Add '$(PkgDir)' without quotes.
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?
--
Bo Berglund
Developer in Sweden

--
Mattias Gaertner via Lazarus
2018-06-10 12:59:11 UTC
Permalink
On Sun, 10 Jun 2018 14:15:06 +0200
Post by Bo Berglund via Lazarus
On Sun, 10 Jun 2018 12:58:42 +0200, Mattias Gaertner via Lazarus
Post by Mattias Gaertner via Lazarus
Your package must inherit an object search path.
Package editor / Options / Package Options / Add path to dependent
packages / Object
Add '$(PkgDir)' without quotes.
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.
$(PkgDir)\..\Sentinel
Glad you figured that out. I don't know your setup (yet).
Post by Bo Berglund via Lazarus
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?
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
--
Bo Berglund via Lazarus
2018-06-10 13:11:14 UTC
Permalink
On Sun, 10 Jun 2018 14:59:11 +0200, Mattias Gaertner via Lazarus
Post by Mattias Gaertner via Lazarus
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
Developer in Sweden

--
Michael Schnell via Lazarus
2018-06-11 08:23:44 UTC
Permalink
... 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


--
Bo Berglund via Lazarus
2018-06-11 19:03:14 UTC
Permalink
On Mon, 11 Jun 2018 10:23:44 +0200, Michael Schnell via Lazarus
Post by Michael Schnell via Lazarus
... Build IDE: Exit code 2, Errors: 23 ...
You want to compile some 3rd party Dongle code in the IDE ?
That is more than weired !
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...
--
Bo Berglund
Developer in Sweden

--
Mattias Gaertner via Lazarus
2018-06-11 21:17:30 UTC
Permalink
On Mon, 11 Jun 2018 21:03:14 +0200
Post by Bo Berglund via Lazarus
On Mon, 11 Jun 2018 10:23:44 +0200, Michael Schnell via Lazarus
Post by Michael Schnell via Lazarus
... Build IDE: Exit code 2, Errors: 23 ...
You want to compile some 3rd party Dongle code in the IDE ?
That is more than weired !
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...
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
--
Bo Berglund via Lazarus
2018-06-11 22:08:42 UTC
Permalink
On Mon, 11 Jun 2018 23:17:30 +0200, Mattias Gaertner via Lazarus
Post by Mattias Gaertner via Lazarus
On Mon, 11 Jun 2018 21:03:14 +0200
Post by Bo Berglund via Lazarus
On Mon, 11 Jun 2018 10:23:44 +0200, Michael Schnell via Lazarus
Post by Michael Schnell via Lazarus
... Build IDE: Exit code 2, Errors: 23 ...
You want to compile some 3rd party Dongle code in the IDE ?
That is more than weired !
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...
Yes. But you don't need to 'install' every package. Only those with
actual IDE code.
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.
Post by Mattias Gaertner via Lazarus
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 unit at all. But 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....
--
Bo Berglund
Developer in Sweden

--
Mattias Gaertner via Lazarus
2018-06-11 22:46:03 UTC
Permalink
On Tue, 12 Jun 2018 00:08:42 +0200
Post by Bo Berglund via Lazarus
[...]
Post by Mattias Gaertner via Lazarus
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 unit at all. But 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.
Yes.

Mattias
--
Paul Breneman via Lazarus
2018-06-11 22:40:50 UTC
Permalink
Post by Bo Berglund via Lazarus
On Mon, 11 Jun 2018 10:23:44 +0200, Michael Schnell via Lazarus
Post by Michael Schnell via Lazarus
... Build IDE: Exit code 2, Errors: 23 ...
You want to compile some 3rd party Dongle code in the IDE ?
That is more than weired !
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.
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?
--
Michael Schnell via Lazarus
2018-06-12 08:36:57 UTC
Permalink
Post by Michael Schnell via Lazarus
You want to compile some 3rd party Dongle code in the IDE ?
That is more than weired !
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...
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

--
Sven Barth via Lazarus
2018-06-12 09:30:14 UTC
Permalink
Post by Michael Schnell via Lazarus
On Mon, 11 Jun 2018 10:23:44 +0200, Michael Schnell via Lazarus <
You want to compile some 3rd party Dongle code in the IDE ?
That is more than weired !
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...
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.
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
Michael Schnell via Lazarus
2018-06-12 09:48:20 UTC
Permalink
 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
--
Sven Barth via Lazarus
2018-06-12 12:06:52 UTC
Permalink
Post by Michael Schnell via Lazarus
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
Michael Schnell via Lazarus
2018-06-12 13:25:42 UTC
Permalink
Post by Sven Barth via Lazarus
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

--
Sven Barth via Lazarus
2018-06-12 15:08:31 UTC
Permalink
Post by Michael Schnell via Lazarus
Post by Sven Barth via Lazarus
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.)
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
Michael Schnell via Lazarus
2018-06-13 08:29:05 UTC
Permalink
Post by Sven Barth via Lazarus
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

--
Bo Berglund via Lazarus
2018-06-20 05:54:31 UTC
Permalink
On Wed, 13 Jun 2018 10:29:05 +0200, Michael Schnell via Lazarus
Post by Michael Schnell via Lazarus
Post by Sven Barth via Lazarus
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.
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 barfs at it.

Not 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.
--
Bo Berglund
Developer in Sweden

--
Paul Breneman via Lazarus
2018-07-25 17:31:08 UTC
Permalink
Post by Bo Berglund via Lazarus
On Wed, 13 Jun 2018 10:29:05 +0200, Michael Schnell via Lazarus
Post by Michael Schnell via Lazarus
Post by Sven Barth via Lazarus
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.
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 barfs at it.
Not 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!
--
Bo Berglund via Lazarus
2018-07-27 06:36:32 UTC
Permalink
On Wed, 25 Jul 2018 13:31:08 -0400, Paul Breneman via Lazarus
Post by Paul Breneman via Lazarus
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.
Post by Paul Breneman via Lazarus
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);
--
Bo Berglund
Developer in Sweden

--
Paul Breneman via Lazarus
2018-07-27 16:58:08 UTC
Permalink
On 07/27/2018 02:36 AM, Bo Berglund via Lazarus wrote:
...
Post by Bo Berglund via Lazarus
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
--

Loading...