I am trying to make a test program in Lazarus to evaluate if I can port a dongle component in Delphi to a normal class in Lazarus. So far I had no real problems but now I don't understand what I am doing wrong. Relevant code below:

TSentinel = class
  private
    FTimer: TTimer;
    ...
    procedure OnCheckTimer(Sender: TObject);
    ...
  public
    { Public declarations }
    constructor Create;
    ...
end;
constructor TSentinel.Create;
begin
  FTimer := TTimer.Create(Application);
  FTimer.Enabled := false;
  FTimer.Interval := 0;
  FTimer.OnTimer := OnCheckTimer(Self); //<= Error here
  ...
end;

The timer is used to automatically check the presence of the dongle so I have to assign the OnTimer procedure to the newly created TTimer object. This works fine in Delphi...

On compilation I get an error message as follows.

In the Delphi code there was no argument on the assignment of the OnTimer event procedure, in Lazarus it shows this error: sentinel.pas(647,21) Error: Wrong number of parameters specified for call to "OnCheckTimer"

Using argument Self or NIL (like I often do in Delphi): sentinel.pas(647,39) Error: Incompatible type for arg no. 1: Got "untyped", expected "<procedure variable type of procedure(TObject) of object;Register>"

Why is this difference Delphi/FPC appearing and what can I do?

El 19/06/15 a les 09:25, Bo Berglund ha escrit:

Either you use {$MODE DELPHI} or you prepend the method with @, i.e.

FTimer.OnTimer := @OnCheckTimer

See:

http://wiki.freepascal.org/Code_Conversion_Guide

Bye

Amazing! Minutes to get a good solution! What a difference from the Embarcadero support forum! :)

The address symbol did the job!

Now I am getting to the real hurdle as follows:

DongleTest.lpr(20,1) Error: Illegal COFF Magic while reading
SPROMEPS.OBJ

This caused by the following line in a suppurt file from SafeNet:

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

{ External functions }
...

So what I have is an OBJ file that contains the binary interface to the 12 needed Sentinel driver functions.
This obj file has worked in Delphi versions from D4 up to XE5 without problems. Can it be used with Lazarus/FPC possibly with some linker switch???

Googeling "coff magic" shows e.g. this:

http://wiki.osdev.org/COFF

-Michael

El 19/06/15 a les 09:50, Bo Berglund ha escrit:

Most probably the OBJ file is in a format that ld doesn't understand, see the remark here:

http://www.freepascal.org/docs-html/prog/progsu43.html#x50-490001.2.43

Maybe it's possible to convert it to a suitable format, but I cannot help you here.

Bye

It's worth noting that that's one of the few language-level incompatibilities. Bites everybody :-)

I think that takes you back to Michael's suggestion

"If the obj file format is not GNU/FPC compatible and can't be used by the linker in fpc, " Safenet" might be able to provide a GNU C version of that file."

Except I got a reply from them that they cannot support older software in FPC....
So I guess I have to go the Delphi DLL route instead...

That has nothing to do at all with FPC. FPC uses the same linker (format) as GNU C. So you don't need to tell them anything about FPC but just mention gcc.

-Michael

Interesting,
a number of years ago I had a discussion with them about interfacing C programs on Linux (x86) to the Linux driver they make. Apparently it does exist some support for that, but I did not pursue it because we found that we could stay on Windows (we were developing the 64 bit version of our data processing program at the time). Maybe I could go back to the info I collectad at that time and dig out some such interface file?

Maybe, but remember that GCC also runs on Windows and what you're trying to do is find the "right" object (linkable) files for FPC + Windows.

Mentioning FPC muddied the water, and gave them an excuse to wiggle out of their commitments. Stick to GCC, which is what Michael suggested in the first place, and ask for the libraries suitable for whatever variants of Windows you are interested in plus the .h file. Knowing the content of the .h file, it should be possible to get FPC (or at worst an assembler shim) to call their functions.

Bo Berglund wrote

Except I got a reply from them that they cannot support older software in FPC....

And why we love ISV's and closed source software. ;-)

Regards,
- Graeme -

El 19/06/2015 a las 9:50, Bo Berglund escribi?:

Hello,

Try this tool: http://www.agner.org/optimize/#objconv

Thanks,
I tried the converter but when I entered the command according to the manual I got an error:

D:\Internet\Download\FreePascal_Lazarus>objconv -fCOFF SPROMEPS.obj SPROMEPS.coff

Error 2004: Unknown command line option: fCOFF

Then I tried to use a lowercase version (so NOT according to the manual) and it worked!

D:\Internet\Download\FreePascal_Lazarus>objconv -fcoff SPROMEPS.obj SPROMEPS.coff

Input file: SPROMEPS.obj, output file: SPROMEPS.coff Converting from OMF32 to COFF32
Warning 1211: 270 comment records ignored

0 Debug sections removed
0 Exception sections removed

So now, I changed the line in SPROMEPS.pas from:

{$L SPROMEPS.OBJ}  { LINK WITH THE SUPERPRO OBJECT FILE }

to

{$L SPROMEPS.coff}  { LINK WITH THE SUPERPRO OBJECT FILE }

and the original error disappeared!

Instead I now have a series of undefined identifiers to deal with:

Compile Project, Target: DongleTest.exe: Exit code 1, Errors: 23,
Hints: 2
Spromeps.pas(13,2) Note: Ignored compiler switch "$F"
Spromeps.pas(129,4) Hint: Unit "windows" not used in SproMeps
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROFORMATPACKET$RB_SPRO_APIPACKET_PTR$WORD$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROINITIALIZE$RB_SPRO_APIPACKET_PTR$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROGETFULLSTATUS$RB_SPRO_APIPACKET_PTR$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROGETVERSION$RB_SPRO_APIPACKET_PTR$POINTER$POINTER$POINTER$POINTER$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROFINDFIRSTUNIT$RB_SPRO_APIPACKET_PTR$WORD$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROFINDNEXTUNIT$RB_SPRO_APIPACKET_PTR$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROREAD$RB_SPRO_APIPACKET_PTR$WORD$POINTER$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROEXTENDEDREAD$RB_SPRO_APIPACKET_PTR$WORD$POINTER$POINTER$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROWRITE$RB_SPRO_APIPACKET_PTR$WORD$WORD$WORD$BYTE$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROOVERWRITE$RB_SPRO_APIPACKET_PTR$WORD$WORD$WORD$WORD$WORD$BYTE$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPRODECREMENT$RB_SPRO_APIPACKET_PTR$WORD$WORD$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROACTIVATE$RB_SPRO_APIPACKET_PTR$WORD$WORD$WORD$WORD$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROQUERY$RB_SPRO_APIPACKET_PTR$WORD$POINTER$POINTER$POINTER$WORD$$WORD
DongleTest.lpr(20,1) Error: Undefined symbol: GetVersion
DongleTest.lpr(20,1) Error: Undefined symbol: GetLastError
DongleTest.lpr(20,1) Error: Undefined symbol: WriteFile
DongleTest.lpr(20,1) Error: Undefined symbol: ReadFile
DongleTest.lpr(20,1) Error: Undefined symbol: DeviceIoControl
DongleTest.lpr(20,1) Error: Undefined symbol: CloseHandle
DongleTest.lpr(20,1) Error: Undefined symbol: GetTickCount
DongleTest.lpr(20,1) Error: Undefined symbol: GetPrivateProfileIntA
DongleTest.lpr(20,1) Error: Undefined symbol: GetPrivateProfileStringA
DongleTest.lpr(20,1) Error: Undefined symbol: CreateFileA

PROGRESS!

The warning about the $F switch concerns a setting to force far calls, what is the equivalent in FPC?

And I am not sure that COFF is the correct file type to link against...
Have to look back on all the posts here and find what is recommended.

But now is dinner time and I will quit for a while.

Thanks to all who provided support to me!

The warning about the $F switch concerns a setting to force far calls, what is the equivalent in FPC?

http://www.freepascal.org/docs-html/prog/progsu21.html

And I am not sure that COFF is the correct file type to link against...

yes, it is. the fact that you know in undefined symbol step says it all. Now you will need to provide how those undefined symbols actually defined. They probably occur from external function declaration, which differs from compiler to compiler. For instance:

SPROMEPS_RNBOSPROFORMATPACKET$RB_SPRO_APIPACKET_PTR$WORD$$WORD

is FPC's way to define:

unit SPROMEPS;
...
function RNBOSPROFORMATPACKET(x: RB_SPRO_APIPACKET_PTR; y: WORD): WORD;

which is explained here:
http://www.freepascal.org/docs-html/prog/progsu141.html#x172-1750006.2.2

and the way to modify it, such that you can match with what the object file expects:
http://www.freepascal.org/docs-html/prog/progsu142.html#x173-1760006.2.3

The error message when compiling the source:
DongleTest.lpr(22,1) Error: Undefined symbol:
SPROMEPS_RNBOSPROFORMATPACKET$RB_SPRO_APIPACKET_PTR$WORD$$WORD

In SproMeps.pas:

implementation
FUNCTION RNBOsproFormatPacket( ApiPacket     : RB_SPRO_APIPACKET_PTR;
                               thePacketSize : WORD ) : WORD; STDCALL;
EXTERNAL;

I did not really understand any of teh discussions in the linked articles...

Any idea what to do for this particular functio?
There are 13 in total..

Just guessing, I've no experience with this.

1) Use the converter tool to dump the exported function names from the original .obj
2) look for an exported name which looks like RNBOsproFormatPacket
3) use the name conversion option of the converter tool to map the name you found to SPROMEPS_RNBOSPROFORMATPACKET$RB_SPRO_APIPACKET_PTR$WORD$$WORD (see manual)
4) do this for all 13 functions

Marc

Looks useful. Out of curiosity, how far can the same job be done by invoking the ld linker manually and tweaking its parameters to specify different file formats (-b or --format option)?

What's the output of objconv -dfhs SPROMEPS.coff?

In particular, check the mangled name of RNBOsproFormatPacket and list it here.

Stephano

Thanks very much! This seems to be the way to go!
By creating a coff file from the obj file while aliasing the functions to the long format found in the error messages and using the resulting coff file in the include statement ALL errors concerning the SPROMEPS functions disappeared!

But now I have a list of other errors like this:
Compile Project, Target: DongleTest.exe: Exit code 1, Errors: 10,
Hints: 20
Spromeps.pas(13,2) Note: Ignored compiler switch "$F"
Spromeps.pas(129,4) Hint: Unit "windows" not used in SproMeps
DongleTest.lpr(23,1) Error: Undefined symbol: GetVersion
DongleTest.lpr(23,1) Error: Undefined symbol: GetLastError
DongleTest.lpr(23,1) Error: Undefined symbol: WriteFile
DongleTest.lpr(23,1) Error: Undefined symbol: ReadFile
DongleTest.lpr(23,1) Error: Undefined symbol: DeviceIoControl
DongleTest.lpr(23,1) Error: Undefined symbol: CloseHandle
DongleTest.lpr(23,1) Error: Undefined symbol: GetTickCount
DongleTest.lpr(23,1) Error: Undefined symbol: GetPrivateProfileIntA
DongleTest.lpr(23,1) Error: Undefined symbol: GetPrivateProfileStringA
DongleTest.lpr(23,1) Error: Undefined symbol: CreateFileA

I even added an implementation uses clause "Windows" since I recognized some of these as Windows API names, but it did not work no matter where I put the uses Windows (interface or implementation in SPROMEPS.pas or in the main project file).

Seems like I am almost there except this list of errors....

Care to share the aliasing details?

What's line 23 of DongleTest.lpr?

Stephano

These are used in SPROMEPS.OBJ.

Stephano

I made a batch file with a command like this:
objconv -nu -fcoff @params.txt SPROMEPS.obj SPROMEPS.coff

All arguments are in the params.txt file like this: -ar:RNBOsproFormatPacket:SPROMEPS_RNBOSPROFORMATPACKET$RB_SPRO_APIPACKET_PTR$WORD$$WORD -ar:RNBOsproInitialize:SPROMEPS_RNBOSPROINITIALIZE$RB_SPRO_APIPACKET_PTR$$WORD -ar:RNBOsproGetFullStatus:SPROMEPS_RNBOSPROGETFULLSTATUS$RB_SPRO_APIPACKET_PTR$$WORD -ar:RNBOsproGetVersion:SPROMEPS_RNBOSPROGETVERSION$RB_SPRO_APIPACKET_PTR$POINTER$POINTER$POINTER$POINTER$$WORD -ar:RNBOsproFindFirstUnit:SPROMEPS_RNBOSPROFINDFIRSTUNIT$RB_SPRO_APIPACKET_PTR$WORD$$WORD -ar:RNBOsproFindNextUnit:SPROMEPS_RNBOSPROFINDNEXTUNIT$RB_SPRO_APIPACKET_PTR$$WORD -ar:RNBOsproRead:SPROMEPS_RNBOSPROREAD$RB_SPRO_APIPACKET_PTR$WORD$POINTER$$WORD -ar:RNBOsproExtendedRead:SPROMEPS_RNBOSPROEXTENDEDREAD$RB_SPRO_APIPACKET_PTR$WORD$POINTER$POINTER$$WORD -ar:RNBOsproWrite:SPROMEPS_RNBOSPROWRITE$RB_SPRO_APIPACKET_PTR$WORD$WORD$WORD$BYTE$$WORD -ar:RNBOsproOverwrite:SPROMEPS_RNBOSPROOVERWRITE$RB_SPRO_APIPACKET_PTR$WORD$WORD$WORD$WORD$WORD$BYTE$$WORD -ar:RNBOsproDecrement:SPROMEPS_RNBOSPRODECREMENT$RB_SPRO_APIPACKET_PTR$WORD$WORD$$WORD -ar:RNBOsproActivate:SPROMEPS_RNBOSPROACTIVATE$RB_SPRO_APIPACKET_PTR$WORD$WORD$WORD$WORD$$WORD -ar:RNBOsproQuery:SPROMEPS_RNBOSPROQUERY$RB_SPRO_APIPACKET_PTR$WORD$POINTER$POINTER$POINTER$WORD$$WORD

This is what i saw while running the batch file:

objconv -nu -fcoff @params.txt SPROMEPS.obj SPROMEPS.coff

Input file: SPROMEPS.obj, output file: SPROMEPS.coff Converting from OMF32 to COFF32
Not adding or removing underscores for this filetype Warning 1211: 270 comment records ignored

0 Debug sections removed
0 Exception sections removed
13 Symbol names changed
13 Public symbol names aliased

> What's line 23 of DongleTest.lpr?

That is the closing line of the main lpr file:
end.

So it is probably something that is not really in my code...

patspiper wrote

What's the output of objconv -dfhs SPROMEPS.coff? In particular, check the mangled name of RNBOsproFormatPacket and list it here.

See my reply to patspiper where I listed the main command and the arguments file

Exactly what I had figured out.

SPROMEPS.OBJ calls these functions. I am not sure how to command the linker to treat them accordingly.

Stephano

patspiper wrote

> Seems like I am almost there except this list of errors.... These are used in SPROMEPS.OBJ.

I figured as much, problem is why that works in Delphi but not in FPC/Lazarus? The special functions would of course need the definitions etc, but the WinAPI calls should "just execute", or not?

After thinking a while more I don't really understand the problem... Why are there errors thrown for function calls originating inside the obj file functions?

If the functions inside the obj function are calling Windows API functions, why should that be a problem such that Lazarus throws an error?
It seems like the executable code inside the obj should be able to handle this itself, right?

Maybe someone more knowledgeable with linkers can help better, but I think that the linker cannot know that these functions are in kernel32.dll.

Do you have kernel32.lib (import library) and kernel32.dll? It should be included with the Windows sdk.

http://www.mingw.org/wiki/createimportlibraries shows a way of creating an import library from a dll.

Once you have the import library, try adding -lkernel32.lib to the linker options in the project options and let's see the result.

Stephano

Add the following options to the objconv command line: -nr:GetVersion:_$dll$kernel32$GetVersion
-nr:GetLastError:_$dll$kernel32$GetLastError
-nr:WriteFile:_$dll$kernel32$WriteFile
-nr:ReadFile:_$dll$kernel32$ReadFile
-nr:DeviceIoControl:_$dll$kernel32$DeviceIoControl -nr:CloseHandle:_$dll$kernel32$CloseHandle
-nr:GetTickCount:_$dll$kernel32$GetTickCount
-nr:GetPrivateProfileIntA:_$dll$kernel32$GetPrivateProfileIntA -nr:GetPrivateProfileStringA:_$dll$kernel32$GetPrivateProfileStringA -nr:CreateFileA:_$dll$kernel32$CreateFileA

You might have to add to the project's linker options (-k): -lkernel32

If Lazarus can't locate it, search for libkernel32.a and put it in the project folder to test (you can use the linker option -L to specify the libkernel32.a folder).

Test and let us know what happens :)

Stephano

I did the above

You might have to add to the project's linker options (-k): -lkernel32

Did not do this.

If Lazarus can't locate it, search for libkernel32.a and put it in the project folder to test (you can use the linker option -L to specify the libkernel32.a folder).

Did not have to do this either

Test and let us know what happens :)

I added the -nr lines to my parameters file and re-ran the conversion. Then moved the resulting coff file to the project dir and compiled: Message pane shows:

Compile Project, Target: DongleTest.exe: Success

Seems like my dongle module is now compiled without errors! :) Next task is for me to add the calls to the methods of the object to check if it will actually be able to read the dongle correctly. Something for Monday.

Thanks a bunch for this immensly valuable help!

Great ;)

Next task is for me to add the calls to the methods of the object to check if it will actually be able to read the dongle correctly. Something for Monday.

Pls report your findings. I am curious to see if it will actually work.

I wonder how spromeps.obj communicates with the dongle. Does it have a driver, and if it does how does it communicate with it?

Does it work on Linux with Lazarus?

Stephano

I just made a first test by adding the object to my main form as a private variable. It is created in the form.create event. I added a button and a static text control on the form and in the button event I added the code to initialize the dongle and read its serial number.
When I stepped through the code I reached the first call to the driver via the obj file I get an exception when calling RNBOsproFormatPacket in this function, which is in the SPROMEPS.pas file supplied by SafeNet:

FUNCTION SproInitialize( ApiPacket : RB_SPRO_APIPACKET_PTR ) : WORD;
VAR
    returnVal : WORD;
BEGIN
    returnVal := RNBOsproFormatPacket (ApiPacket,
RB_SPRO_APIPACKET_SIZE);
    IF returnVal  SP_SUCCESS THEN
       SproInitialize := returnVal
    ELSE
       SproInitialize := RNBOsproInitialize (ApiPacket);
END; { SproInitialize }

Exception text:

"Project DongleTest raised exception class
'External: SIGSEGV'."

I wonder how spromeps.obj communicates with the dongle. Does it have a driver, and if it does how does it communicate with it?

Yes, there is a driver involved and I have installed it in Winodws7 and it works just fine with my Delphi applications. How the application communicates with the driver is unknown by me, it is hidden inside the SPROMEPS.obj file....

Does it work on Linux with Lazarus?

I have no idea but I doubt it. There is some support for Linux with GNU C++ on Linux, but I have never used that...
In fact I have never programmed in Linux, except for PHP (web functionality).

It seems like the very first time I call any function towards the driver I get the exception SIGSEGV whatever that may mean...

To clarify:
The error happens when I call RNBOsproFormatPacket, which is the first time any driver interface function is called.

I have googled SIGSEGV and understand that it is a memory access error.
So I followed the ApiPacket handling through the code.

In the class definition file I have this:
const
  ...
   RB_SPRO_APIPACKET_SIZE         = 1028;
  ...
type
  RB_SPRO_APIPACKET = ARRAY [1..1028] OF CHAR;{ Spro API Packet }
  RB_SPRO_APIPACKET_PTR  = ^RB_SPRO_APIPACKET;
  { TSentinel }
  TSentinel = class
    private
      FSentinelPacket : RB_SPRO_APIPACKET;
      ....

Then in the dongle initialization method I have this:

{Check if the key is initialized, then find first key on system}
  status := InitSuperProKey(FSentinelPacket);

InitSuperProKey() looks like this:

function TSentinel.InitSuperProKey(var thePacket: RB_SPRO_APIPACKET):
word;
var
  error : WORD;
begin
  Result := 0;
  error := SproInitialize(@thePacket);
  if error  0 then begin
    Result := error;
    exit;
  end;
  error := SproFindFirstUnit(@thePacket, DeveloperID);
  if error  0 then
    Result := error;
end;

And SproInitialize is shown in my previos post above as:

FUNCTION SproInitialize( ApiPacket : RB_SPRO_APIPACKET_PTR ) : WORD;
VAR
    returnVal : WORD;
BEGIN
  returnVal:=RNBOsproFormatPacket (ApiPacket,RB_SPRO_APIPACKET_SIZE);
    IF returnVal  SP_SUCCESS THEN
       SproInitialize := returnVal
    ELSE
       SproInitialize := RNBOsproInitialize (ApiPacket);
END; { SproInitialize }

So to me it seems strange that there should be a memory access problem since the "packet" is an array of fixed size which is a private member of the object only used by the object itself via the pointer....

Bo Berglund wrote

I just made a first test by adding the object to my main form as a private variable.

Which object? Better show the code.

The 1st thing that comes to mind is that spromeps.obj is 32 bit and your Lazarus/fpc and Windows are most probably 64 bit. But I am not sure how the compiler/linker would react to that.

You had posted previously:
Input file: SPROMEPS.obj, output file: SPROMEPS.coff Converting from OMF32 to COFF32 <-------------------------------- Not adding or removing underscores for this filetype Warning 1211: 270 comment records ignored

Do you have a 64 bit version of spromeps.obj?

Stephano

Here is the current state of the main form where the object is handled:

unit FormMain;
{$mode objfpc}{$H+}
interface

uses
Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls,
ExtCtrls,

  Sentinel;

type
  { TfrmMain }
  TfrmMain = class(TForm)
    btnFindKey: TButton;
    stxSerialNo: TStaticText;
    procedure btnFindKeyClick(Sender: TObject);
    procedure FormClose(Sender: TObject; var CloseAction:
TCloseAction);
    procedure FormCreate(Sender: TObject);
    procedure Timer1Timer(Sender: TObject);
  private
    { private declarations }
    Dongle: TSentinel; <== My private object variable
  public
    { public declarations }
  end;
var
  frmMain: TfrmMain;
implementation
{$R *.lfm}

{ TfrmMain }

procedure TfrmMain.btnFindKeyClick(Sender: TObject);
var
  SerialNo: word;
begin
  //Code to check for the dongle and if found display its contents
  Dongle.InitKey; <= I get the exception here
  Dongle.AppNumber := 1;
  if Dongle.CheckKey then
  begin
    SerialNo := Dongle.SerialNo;
    stxSerialNo.Caption := IntToStr(SerialNo);
  end;
end;
procedure TfrmMain.FormClose(Sender: TObject; var CloseAction:
TCloseAction);
begin
  Dongle.Free; <= Destroying the object
end;
procedure TfrmMain.FormCreate(Sender: TObject);
begin
  Dongle := TSentinel.Create; <= Creating the object
end;
end.

I think I create a 32 bit application, see below.

No, this is legacy code and is only for 32 bit applications. SafeNet has created the driver for both 32 and 64 bit Windows, but the 64 bit driver is still used for 32 bit applications (like mine). Has always worked fine with the Delphi apps (used since end of the 1990:s).

They did not provide a SPROMEPS.obj file for 64 bit Delphi maybe because that does not really exist yet (according to the Embarcadero user forum the newly released 64 bit compiler is not ready for prime time...)

Question:
Could it be that Lazarus is anyway compiling for a 64 bit application since it is installed on a 64 bit Windows 7 laptop? I just assumed that the main application would be 32 bit as is the case for Delphi....

But if I go into Project Options and look at Compiler Options -> Config and Target -> Target-specific options there is a checkbox for "Win32 gui application (-WG)" and it is checked.

So I guess I am creating a Win32 exe as intended...

So the private field you are referring to is an instance of a class that you have created to handle the dongle.

The facts:
- You have 64 bit Windows
- You have Delphi 32 bit compiler that produces 32 bit executables
- The Safenet driver installed on 64 bit Windows works with the Delphi compiled project

Lazarus/fpc is 64 bit as it has been installed through the Windows installer. This the major difference.

This is unrelated to the bitness of the produced executable.

If you don't have a Windows 32 bit OS installation with Lazarus, and no 32 bit cross compiler, I can try to compile the basic code for you if you want in order to test.

Stephano

Il 22/06/2015 10:09, Bo Berglund ha scritto:

Both Win32 and Win64 generate the same compiler option(-WG)

In the same configuration page you should also pick up the right Target CPU family: i386 as opposed to X86_64, in order to generate a 32bit application. This will require the proper 32 bit compiler. If it isn't available or properly configurated you'll get a warning, when you click the Test button on the page.

Giuliano

installer. This the major difference.

At least Lazarus 1.4, AFAIK also 1.2, provides a 32-bit download even for 64-bit Windows, because of problems with libraries that are only solved once FPC 3.0.0 is released (SEH support).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150622/9290af7d/attachment.html>

Thanks:

I found these additional settings and set as follows: Target OS: Win32
Target CPU family: i386
Target processor: Default
Win32 gui application: checked

When I used the Test button I got this:

HINT: using config file
C:\programs\lazarus\fpc\2.6.4\bin\i386-win32\fpc.cfg WARNING: ppu exists twice:
C:\programs\lazarus\fpc\2.6.4\units\i386-win32\fv\dialogs.ppu, C:\programs\lazarus\lcl\units\i386-win32\dialogs.ppu WARNING: ppu exists twice:
C:\programs\lazarus\fpc\2.6.4\units\i386-win32\fv\menus.ppu, C:\programs\lazarus\lcl\units\i386-win32\menus.ppu

I don't know/understand why the latter ppu warnings are shown...

When I run with these new settings I get the exact same error at the exact same place as before.

Correct summary!

Well, I understand that the IDE may be a 64 bit application, what I was wondering about was the target of the build. But I see tha it is a Win32 application so thta should be OK.

I do not understand. I installed Lazarus a week ago from the latest release and it also included the latest fpc. This should be able to create a 32 bit application irrespecxtive of in which Windows it is installed (32/64 bit)....

And I cannot provide the full source because it contains proprietary key information for encrypting the data in the dongle.

I assume the compiler you installed produces 64 bit executables by default. The Win32 GUI (-GW) description in the IDE is not exact. As per fpc help:
-WG: Specify graphic type application (EMX, OS/2, Windows)

Anyway, you can check any of the compiled executables. One simple way (I didn't even try it) is shown in the selected answer in http://superuser.com/questions/358434/how-to-check-if-a-binary-is-32-or-64-bit-on-windows

Sven mentioned a 32 bit download for Windows, which brings up the question as to which one you have downloaded and installed. You can check http://www.lazarus-ide.org/index.php?page=downloads

The following link is for the 32 bit download:
http://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/Lazarus%201.4/lazarus-1.4.0-fpc-2.6.4-win32.exe/download

And I cannot provide the full source because it contains proprietary key information for encrypting the data in the dongle.

You can strip everything except for the initialization call. If this call succeeds then we are on the right track.

But your best bet is to install the 32 bit version and try it yourself.

Stephano

IIRC, these 2 specific warnings are benign.

When I run with these new settings I get the exact same error at the exact same place as before.

Check the bitness of the produced executable.

Stephano

Did a check with the CygWin file command:
D:\Engineering\Projects\Lazarus\LazDongle>file dongletest.exe dongletest.exe: PE32 executable (GUI) Intel 80386, for MS Windows

Seems like my Lazarus produces 32 bit executables by default...

Sven mentioned a 32 bit download for Windows, which brings up the question as to which one you have downloaded and installed. You can check http://www.lazarus-ide.org/index.php?page=downloads

I downloaded and installed from this file:
lazarus-1.4.0-fpc-2.6.4-win32.exe
It was downloaded from:
https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/

> And I cannot provide the full source because it contains proprietary > key information for encrypting the data in the dongle. You can strip everything except for the initialization call. If this call succeeds then we are on the right track.

But your best bet is to install the 32 bit version and try it yourself.

That is what I have already...

patspiper wrote

Check the bitness of the produced executable.

Did a check with the CygWin file command:
D:\Engineering\Projects\Lazarus\LazDongle>file dongletest.exe dongletest.exe: PE32 executable (GUI) Intel 80386, for MS Windows

Seems like my Lazarus produces 32 bit executables by default...

Bo Berglund wrote

> But your best bet is to install the 32 bit version and try it yourself. That is what I have already...

I am out of ideas for now.

You can ask for help on the fpc mailing list. I propose you prepare a minimum working example in an lpr file (no units, just a program which outputs to console using writeln) which only initializes the dongle/driver.

Stephano

Thanks,
I tried to do what you proposed:
File->New Console Application
After filling in some name boxes I started adding the very minimal code:

  { add your program here }
  Writeln('Starting check program');
  Dongle := TSentinel.Create;
  if not Dongle.InitKey then
     Writeln('Dongle Init Failed!')
  else
  begin
    Writeln('SerialNo: ' + IntToStr(Dongle.SerialNo));
  end;
  // stop program loop

But when I compile I get this error:

sentinel.pas(14,3) Fatal: Cannot find unit ExtCtrls used by Sentinel.
Check if package LCLBase is in the dependencies.

It points to the uses clause in the Sentinel.pas file where standard units are mentioned like Forms, ExtCtrls etc...

Before this error it also complained about Forms in the uses clause of the Sentinel.pas file. But then I commented out that in the sentinel.pas file.

None of these complaints were issued when I used the exact same unit in my GUI test application.

How do I "Check if package LCLBase is in the dependencies"? And why is it not picking it up?

I googled this error and was directed to the following: Project->Project Inspector->Required Packages->Add This opened a file open dialog and I typed in LCLBase but tha did not work...

In my experince sigsegv occurs mostly when a field or variable is accessed before initialization.

Try to set a breakpoint in dongle.initkey call. And evaluate the dongle field (open debugger evaluate window)

Look for dongle or one of the tsentinel fields being nil

Liiz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150622/6211e657/attachment-0001.html>

I have already a breakpoint in the on-click event handler for the button. The code is:

procedure TfrmMain.btnFindKeyClick(Sender: TObject);
var
  SerialNo: word;
begin
  //Code to check for the dongle and if found display its contents
  Dongle.InitKey;  <-- Breakpoint here
  Dongle.AppNumber := 1;
  if Dongle.CheckKey then
  begin
    SerialNo := Dongle.SerialNo;
    stxSerialNo.Caption := IntToStr(SerialNo);
  end;
end;

When Lazarus stops and I hover over the Dongle variable (which was created in the form's OnCreate event) I see all fields of the Dongle object and they seem to be normal, except for the FSentinelPacket.

This is supposed to be an array of char [1..1028] but it says FSENTINELPACKET=#0#0#0#0Truncated 1027->1000####

Does this imply that the size of the packet has been initialized erroneously?
It is defined thus: ARRAY [1..1028] OF CHAR;
Can the indexing be a problem? The packet is defined with a starting index of 1 rather than 0...

In the breakpoint do a step into (f7) and ser the exact line that crashes

Luiz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150622/d6e4c616/attachment.html>

Bo Berglund wrote

I tried to do what you proposed: File->New Console Application

That creates a Console application - thus no dependenies on GUI toolkits.

So that means (so often the case with Delphi components) that sentinel.pas depends on a GUI toolkit. Because you created a console application, such dependencies are not allow. Often (but not always) units like that include Forms, Dialogs, Graphics etc in the uses clause, even though they don't actually use them.

For a dongle there shouldn't be any need for a GUI toolkit. Comment out any GUI toolkit units in the sentinel.pas unit and try again.

None of these complaints were issued when I used the exact same unit in my GUI test application.

So surprise, because your GUI application had a dependency on LCL, thus it could find the Forms, Dialogs etc units.

Regards,
- Graeme -

luiz americo pereira camara wrote

In the breakpoint do a step into (f7) and ser the exact line that crashes Luiz

In the pas unit this is the exact line that crashes:

returnVal := RNBOsproFormatPacket (ApiPacket, RB_SPRO_APIPACKET_SIZE);

This is the first call into the drive via the converted obj file. Must be something in error in the conversion.

Graeme Geldenhuys wrote

File->New Console Application That creates a Console application - thus no dependenies on GUI toolkits.

And not support for things like TTimer, Application.QueuAsyncCall, Support for TThread.Queue and TThread.Synchronize needs to be provided by special user code, ...

-Michael

Michael Schnell wrote

And not support for things like TTimer

Not to rehash an old topic... Maybe that is true for TTimer, but it took me all of 10 minutes to implement a multi-threaded console application and implementing a TThread based timer from scratch. All working just fine under FreeBSD. So I really don't see the issue or why you keep harping on this topic.

Regards,
- Graeme -

That is obviously correct, but not "nice".

I do have working code for my long-time-project "ActiveNoGUI" and I will restart working on that as soon I have some spare time.

I was in waiting state until the "*released*" Lazarus comes with an fpc version that supports TThread.Queue, which is a prerequisite for doing an "ActiveNoGUI" Widget Type for Lazarus (that also supports Application.QueueAsyncCall). AFAIK this now is given, but I did not yet check (and don't now how I should check it, as "comes with" is not really defined ).

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150623/421f27da/attachment.html>

Ehm. fpTimer contains just that, it exists since years.

Before your answer, I thought to reply something similar, but some people are obviously beyond help or reason...

Michael.

Michael Van Canneyt wrote

Ehm. fpTimer contains just that, it exists since years.

This of course is a well known fact..

But if this is the recommended way to do timers, why does *any *WidgetType (i.e. TApplication) offer TTimer ?

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150623/bd9fe22e/attachment.html>

Pls don't hijack the thread with your never ending NoGui discussions.

Stephano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150623/ead24912/attachment.html>

Or in the declaration of the parameter types.

patspiper wrote

Pls don't hijack the thread with your never ending NoGui discussions.

Sorry.

But for somebody coming from Delphi it is likely confusing that a NoGUI application needs to be done completely different than an Application that does have a GUI, so I thought a warning would be appropriate.

I did not intend to hijack the thread and come back in an appropriate way later.

Sorry again.
-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150623/a46717cc/attachment.html>

Note that what I am trying to accomplish is porting an application from Delphi to Lazarus where the dongle handling is by way of an interface unit (spromeps.pas) and an include file (spromeps.obj) where the implementation of the API into the SuperPro driver is done.

In Delphi the obj file is used as follows:

implementation
{$L SPROMEPS.OBJ}  { LINK WITH THE SUPERPRO OBJECT FILE }

It has worked just fine since roundabout 2002 in all the Delphi versions we have used including XE5.
The spromeps.pas file declares all the needed functions which we need to use in the driver and calls them as externals via the obj file.

Unfortunately Lazarus/FPC does not handle the obj file so this thread is really about ways to get around that by converting the obj file to coff (or elf) that FPC can handle.
I got tipped off about a tool thta can do this and downloaded objconf from here:
http://www.agner.org/optimize/#objconv

The problem is most likely in the conversion because even the smallest test application throws an exception on the very first call into the driver, the initialization of the Api data interface array.

The function call shown above is the last in a chain starting in the main application by the method Dongle.InitKey. Everything up to this call seems OK on inspection but the actual call to the driver via the converted obj file (now a coff file) fails.

Since the obj file works in Delphi with such disparate versions as Delphi 5 up to Delphi XE5 it cannot be a compiler incompatibility problem, really.
It MUST be the conversion using objconv, which is somehow improperly set up for the task. But it is hard to understand how to set it up since I have no experience in such low-level programming in Windows.

This is where I am now:
No matter what I try there are exceptions generated... :( It would have been nice if FPC could accept linking with a regular OBJ file so I did not have to convert it.

El 23/06/15 a les 17:51, Bo Berglund ha escrit:

The problem is most likely in the conversion because even the smallest test application throws an exception on the very first call into the driver, the initialization of the Api data interface array.

Or in the calling convention

http://freepascal.org/docs-html/prog/progse22.html#x174-1770006.3

you can try and define the external as stdcall or if that fail try cdecl (though I'm not sure the default is different than delphi).

Bye

STDCALL has been there "forever" (since about 2002)...

El 23/06/15 a les 20:38, Bo Berglund ha escrit:

You could try cdecl then (though I doubt it will make a difference).

Bye

Bo Berglund wrote

No matter what I try there are exceptions generated... :( It would have been nice if FPC could accept linking with a regular OBJ file so I did not have to convert it.

You might be better off moving this discussion to the fpc-users mailing list. I believe more FPC and compiler developers lurk there.

Regards,
- Graeme -

Take a look at
https://msdn.microsoft.com/pl-pl/library/vstudio/7dz62kfh(v=vs.110).aspx (it suggests a cvtres.exe tool)

Ask to fpc guru if is possible to use manually an different linker like http://www.digitalmars.com/ctg/optlink.html

In the end, i would try to compile a delphi dll and access it in fpc.

Another try (don't know if is possible) is to use delphi to compile spromeps.pas as a obj in COFF

Luiz

2015-06-23 15:50 GMT-03:00 Luca Olivetti :

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150623/0517a8d6/attachment.html>

I have discovered potential bugs in the 3rd party tool objconv.exe that converts from omf to coff, and most importantly in fpc's internal linker.

I provided Bo Berglund with a workaround for objconv that seems to work, and advised him to use the external linker (-Xe switch). The exception has vanished and basic tests have succeeded. I will file a bug report against fpc's internal linker soon.

Stephano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150624/fa8ef6e1/attachment.html>

I have discovered potential bugs in the 3rd party tool objconv.exe that converts from omf to coff, and most importantly in fpc's internal linker.

I provided Bo Berglund with a workaround for objconv that seems to work, and advised him to use the external linker (-Xe switch). The exception has vanished and basic tests have succeeded. I will file a bug report against fpc's internal linker soon.

Stephano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150624/074b4286/attachment.html>

El 19/06/2015 a las 9:38, Luca Olivetti escribi?:

I think that Luca's code doesn't work on delphi either. He should write
FTimer.OnTimer := OnCheckTimer;
Without the self parameter "self".

If you add the parameter self, delphi would think you call method function called OnChecktimer. As OnCheckTimer is a procedure, not a function, rises error.

If OnTimer wouldn't had parameters, there could a confusion, that IMHO FPC with @ solves in an elegant way. With a parameter there is no ambiguity, that's an error: Assigning to variable the result of procedure.

ALMOST SOLVED (workaround found)
--------------------------------
As patspiper has posted there has been a potential bug discovered in the fpc linker while tracing my problems with porting the Sentinel SuperPro dongle handler class from Delphi to Lazarus/FPC. In order to port it we had to convert an OBJ file from the dongle maker to a format FPC accepts (coff) using a 3rd party tool, which also has some bug in it.
Patspiper will handle the bug reports.

The solution to the actual problem for me was:
1) Convert the OBJ file to COFF and alias the internal identifiers such that FPC can find them. This uses the 3rd party tool objconv. Then replace the include directive for the OBJ file with the COFF file.

2)Use the compiler switch -Xe in order to link externally. Much slower but results in a working application.

Many thanks to patspiper who has spent a lot of time helping me to track down the cause of the problems!

2015-06-24 19:02 GMT-03:00 Bo Berglund :

There's a tool called CVTRES.EXE that comes with Visual Studio that does such conversion. It's an alternative to get a proper coff format

Luiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150625/d343ecc3/attachment.html>

I do have VS installed so I have this tool:

D:\>cvtres
Microsoft (R) Windows Resource To Object Converter Version 7.10.3052.4 Copyright (C) Microsoft Corporation. All rights reserved.

usage: CVTRES [options] [files]

options:

/DEFINE:symbol
/MACHINE:{AM33|ARM|CEF|IA64|M32R|MIPS|MIPS16|MIPSFPU|MIPSFPU16| MIPSR41XX|PPC|PPCFP|SH3|SH3DSP|SH4|SH5|THUMB|X86}
/NOLOGO
/OUT:filename
/READONLY
/VERBOSE
/WINDOWSCE[:{CONVERT|EMULATION}]

Nevet used it though.

When I tried to google it to find a manual or such there were almost nothing but "how to get rid of the cvtres virus"...

Is there a howto or user's manual for this tool?
Specifically I need to verify that it can do OBJ => COFF

El 25/06/2015 a las 21:03, Bo Berglund escribi?:

Hello,

I think the tool is "Editbin", cvtres is to convert resources:

cvtres = "ConVerT RESource"

Also the linker should do it (OMF to COFF):

link -edit thefile.obj