We have a number of old Delphi7 applications which are in need of porting over to FreePascal. I have successfully done a number of these ports in the last few years...
But now I am up against a bit of a problem regarding software we have protected using an USB connected hardware key originally bought from Rainbow, a company that has been bought up in several steps and is now named THALES.

Anyway, our software interfaces to the SuperPro protection keys is via a Windows driver from THALES and they have provided a software integration kit way back when we started using the keys.
It consist of a Delphi unit basically containing a list of definitions of available API functions into the driver looking like this:

------
{ Force FAR calls }
{$F+}

INTERFACE
CONST
 { SuperPro API error codes }
 SP_SUCCESS                     = 0;
 <snip>
 SPRO_MAX_QUERY_SIZE            = 56;
TYPE
RB_SPRO_APIPACKET      = ARRAY [1..1028] OF CHAR;  { Spro API Packet }
RB_SPRO_APIPACKET_PTR  = ^RB_SPRO_APIPACKET;
FUNCTION SproInitialize( ApiPacket : RB_SPRO_APIPACKET_PTR   ) : WORD;
FUNCTION SproGetExtendedStatus( ApiPacket : RB_SPRO_APIPACKET_PTR ) : WORD;
<snip>
IMPLEMENTATION
USES
   Windows;
{$L SPROMEPS.OBJ}  { LINK WITH THE SUPERPRO OBJECT FILE }
{ External functions }
FUNCTION RNBOsproFormatPacket( ApiPacket     : RB_SPRO_APIPACKET_PTR;
                               thePacketSize : WORD ) : WORD; STDCALL; EXTERNAL;
FUNCTION RNBOsproInitialize( ApiPacket : RB_SPRO_APIPACKET_PTR ) : WORD;
STDCALL; EXTERNAL;
<snip>
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 }

<snip a lot of other API functions>

BEGIN
END.
------

Obviously being from the time when it was received the OBJ file SPROMEPS.OBJ to be linked in is a 32 bit type, so the ported programs need to be compiled/linked into a 32 bit exe file on Windows.

Questions:
----------

1) How should I go about translating the above to current FreePascal syntax?

This involves:
{ Force FAR calls }
{$F+}

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

2) Is there a way to translate/convert the 32 bit Windows SPROMEPS.OBJ file into a 64 bit one such that it could be used for a 64 bit fpc compiler? It is the interface to the protection key driver on the Windows system...

It does work for our 32 bit Delphi7 programs on Windows 10 x64, so there must be some 32<->64 bit handling in Windows maybe?

You can normally skip this.

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

This can be problematical, since you need to know it is in the correct format for the linker.

2) Is there a way to translate/convert the 32 bit Windows SPROMEPS.OBJ file into a 64 bit one such that it could be used for a 64 bit fpc compiler? It is the interface to the protection key driver on the Windows system...

I doubt this can be done.

It does work for our 32 bit Delphi7 programs on Windows 10 x64, so there must be some 32<->64 bit handling in Windows maybe?

I do not think there is special handling. 64 bit windows simply runs 32-bit windows programs.

Basically, due to the .OBJ file, I think you're stuck with compiling 32-bit programs if you require that .obj file.

Maybe the THALES company has a 64-bit version of the .OBJ file.

Michael.

There will surely be better responses than mine, but imho there is an inconsistency in your code: Near/Far calls are a relict of the 16-bit DOS/Win3.x era. The {$F+} switch should be completely obsolete for both Win32 and Win64 executables.

.obj files are compiled code (pieces) which are not yet linked together. I cannot imagine that there is a chance to convert a 32-bit .obj file into a .64-bit .obj file without recompilation (i.e. having the sources). So I'd assume that you are stuck to the 32-bit architecture or you might try to obtain a 64-bit .obj from the manufacturer. Maybe he's even released a complete library with a documented API in the meantime? (Even though the hardware key is old it could still be supported as part of the driver series of the manufacturer's current hardware.)

Bo Berglund via fpc-pascal schrieb am
Di., 21. März 2023, 23:54:

These won't be a problem. Both Delphi and FPC (for non-i8086) will skip the $F directive as it's not necessary on 32- or 64-bit systems.

The object file won't be a problem for FPC on i386-win32 because it will be a COFF file which is the default.

Aside from asking the company for a 64-bit variant or reverse engineering the object file, no. How large is that object file? Maybe it's only a relatively simple interface to the driver...

It does work for our 32 bit Delphi7 programs on Windows 10 x64, so there must be some 32<->64 bit handling in Windows maybe?

Are you really sure there's a driver involved? When you install it is there a driver binary for both 32- and 64-bit? Cause 64-bit Windows *can not* load 32-bit drivers.

Regards,
Sven

Michael Van Canneyt wrote

Maybe the THALES company has a 64-bit version of the .OBJ file.

OK, I will try and get some answers from them.
Problem is that they seem to have concentrated on Microsoft dev tools so lat time I looked there was not much for Delphi and none for FreePascal.

There really should be some generic interface to use independent of dev environment nowadays when there are so many systems in use (C-sharp, C++, Python etc etc).

I will have to open a support ticket.

OK, so I don't have to modify this part then.

The object file won't be a problem for FPC on i386-win32 because it will be a COFF file which is the default.

When you say "on i386-win32" does that mean a 32 bit version of Windows as the host system for building the programs?

If I have fpc 3.2.2 inbstalled on Windows 10 x64 I assume it is a 64 bit target exe which will be the output, right?

If that is the case will the obj file work when building the exe?

Is it possible to check if the obj file is of the "COFF" type? Note that the timestamp of the obj file is 2003-05-29...

Size = 39330 bytes

Maybe it's only a relatively simple interface to the driver..

The accompanying pas file I quoted from declares 12 different API calls into the driver, which we have used to create our own interface functions for the key handling. This was done about 20 or so years ago...

THALES has supplied a dedicated driver for Windows, which we use on all s/w installations. It is a rather big (2945376 bytes) installer file named "Sentinel System Driver Installer 7.6.0.exe"
So, yes I am sure it is needed, whithout it the s/w cannot read the protection key.
The driver has changed over the years as Windows progressed and we now use version 7.6.0

I guess I have to just create a simple program which reads the key data and does nothing else to check if the handling will actually work... Or convert a small tool we already have from Delphi7 to Lazarus/FPC and see what happens..

Il 22/03/2023 11:18, Bo Berglund via fpc-pascal ha scritto:

If I have fpc 3.2.2 inbstalled on Windows 10 x64 I assume it is a 64 bit target exe which will be the output, right?

If in Project Options -> Config and Target ->Target OS you specify Win32, you'll get a 32 bit exe (which is what Delphi does, I presume, if it links a 32 bit object).

Giuliano

Now I created a new program and set it to mode Delphi. The syntac check Run/Quick_Compile works OK but then when I use the Run/Compile function this is what I get:

Compile Project, Target: DongleTest.exe: Exit code 1, Errors: 1 DongleTest.lpr(24,1) Error: Illegal COFF Magic while reading D:\Engineering\Projects\Subversion\PC\DongleTest\SPROMEPS.OBJ

Sigh...
I guess it is a problem regarding 32 vs 64 bit application code here...

Is there a settinmg in FPC which will make it produce a 32bit Windows exe?

Or do I have to install a complete set of 32 bit Lazarus/FPC on my 64 bit Windows 10?
Or even worse: do I have to create a virtual Windows 10 32 bit computer to do the build on? It might not work there too.

I changed target to Win32 then when I closed the dialog an error message popped up:

The current FPC has no config file. It will probably miss some units. Check your installation of fpc.
[OK] [Ignore]

My installation was done using a full Lazarus/FPC installer from SourceForge: lazarus-2.2.4-fpc-3.2.2-win64.exe

So both Lazarus and Fpc come from the same installer and it installs an isolated environment so one can have several versions installed at the same time.

What to do now?
And what is the problem?

I changed target to Win32 then when I closed the dialog an error message popped up:

--------------------------------------------------------- The current FPC has no config file. It will probably miss some units. Check your installation of fpc.
[OK] [Ignore]
---------------------------------------------------------

When I hit [OK] I got this pop-up:

----------------------------------------------------------- The project uses target OS=win32 and CPU=x86_64.
The system.ppu for this target was not found in the FPC binary directories.
Make sure fpc is installed correctly for this target and the fpc.cfg contains the right directories.
[OK]
------------------------------------------------------------

My installation was done using a full Lazarus/FPC installer from SourceForge: lazarus-2.2.4-fpc-3.2.2-win64.exe

So both Lazarus and Fpc come from the same installer and it installs an isolated environment so one can have several versions installed at the same time.

What to do now?
And what is the problem?

Bo Berglund via fpc-pascal schrieb am
Mi., 22. März 2023, 13:57:

You need to download the Win32 addon for Lazarus from the same location, install that and then set operating system to Win32 and platform to i386.

Regards,
Sven

Bo Berglund via fpc-pascal schrieb am
Mi., 22. März 2023, 11:18:

I mean a variant of FPC that targets the i386 platform together with the compiled units for i386-win32.

No.

Is it possible to check if the obj file is of the "COFF" type? Note that the timestamp of the obj file is 2003-05-29...

You could use the objdump utility provided with FPC (call it as "objdump -x <file>"). If it doesn't print any errors then it's a COFF file.

That mean there's quite a bit of code in there, so it isn't trivially to reverse engineer...

Then you should ask them for a suitable 64-bit object file (I assume that they'll provide the one for C which they probably also did for you back then and then you might need to adjust the import unit a bit to be usable with x86_64-win64; as long as they also provide a C header that should be doable).

Regards,
Sven

I looked at the FPC Wiki on cross-compilation and tried to install the cross for win32 into my Lazarus 2.2.4.
https://wiki.freepascal.org/Cross_compiling#From_win64_to_win32

But it seems like the wiki instructions are missing something because it does not even find what is needed to switch to target win32... See separate thread about cross-compile.

Back here again after I raised a ticket with Thales and got a response! I think they provide something that will work with Delphi rather than for C.

The reply from THALES is linking to no less than 7 different archive files for various use of the keys.

In one of these I found an example for *Delphi 10*, which contained an updated interface file and a 32 bit object file:
spromeps.pas
superpro.obj

(I do not think I even ever had Delphi 10...)

I copied these to my project and disabled the old versions.

Then I tried to cross-compile to Win32 on Lazarus 2.2.4 and Fpc 3.2.2.

Syntax check (Run/Quick_Compile) finishes successfully.

But the Compile does not, it fails like this:

---------------------
Compile Project, Mode: Default, OS: win32, CPU: i386, Target: DongleTest.exe: Exit code 1, Errors: 1
DongleTest.lpr(28,1) Error: Illegal COFF Magic while reading D:\Engineering\Projects\Subversion\PC\DongleTest\superpro.obj ---------------------

The same happens if I set the target to default everywhere so going for 64 bit. In tyhis case I had to switch to the spromeps.pas superpro.obj files from the same archive but for 64 bit applications.
Here the error when I try to compile:

----------------------
Compile Project, Mode: Default, Target: DongleTest.exe: Exit code 1, Errors: 1 DongleTest.lpr(28,1) Error: Failed reading coff file, illegal reloctype $000A while reading D:\Engineering\Projects\Subversion\PC\AgiDongleTest\superpro.obj ----------------------

So again I have the problem with the obj file(s) which are now more recent than the old single one.

How can I check the obj file for "type"?

I have asked this before here but now cannot find if I got an answer or not...

Is there some command I can use to check what kind of an obj file I have?

Is it possible to find anything by looking at the interface file spromeps.pas, which is the interface from the main application towards the obj file?

ThHis pretty much looks like the old file to me except it has more available API calls and also some defines for MSWINDOWS and LINUX respectively in the implementation part defining all the API calls into the driver.

My problem is that I do not have any Delphi on my new (from 2019) laptop except Delphi-7...

So I guess I have to check if my test app can be opened in Delphi7 using the supplied obj file and if it works there, how do I proceed?

TIA

Dennis Lee Bieber wrote

I'd expect trying to link a 32-bit object file into a 64-bit application to result in all sorts of possible errors.

That is not the case here, they have supplied two obj files, one is 32 and the other 64 bit.
The problem seems to be that neither is a valid COFF file according to my Fpc (or Lazarus) in any case. Both generate the COFF error when reaching the linker step.

And in the case of the 32 bit version of the obj file I have set my Lazarus to target a 32 bit Win application for the i386 processor (I have installed the 32 bit cross compiler found at SourceForge for this). https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Lazarus%202.2.6/

Bo Berglund wrote

The problem seems to be that neither is a valid COFF file according to my Fpc (or Lazarus) in any case. Both generate the COFF error when reaching the linker step.

32-bit objs for delphi are typically OMF, 64-bit are typically coff (for AMD64).

I'd suggest trying to switch to external linking (for both versions) - that might help...

Tomas

Could you be more specific?

I have never heard of such, I am just a long time user of Lazarus/Fpc but not in the deep understanding of how it all works. I have always focused on my applications and not how they were screwed together behind the scenes by Fpc...

Is there a setting to use something other than Fpc to link after compiling? How is that done?

Bo Berglund wrote

On Thu, 30 Mar 2023 10:02:49 +0200, Tomas Hajny via fpc-pascal wrote:

.
.

I don't know where it is configured in Lazarus, but you need to use the -Xe parameter when using command-line compilation.

Tomas

[...] I don't know where it is configured in Lazarus, but you need to use the -Xe parameter when using command-line compilation.

Project / Project Options / Compiler Options / All Options

Mattias