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.)
----- Original Message -----
From: Bo Berglund via fpc-pascal <fpc-pascal@lists.freepascal.org>
To: fpc-pascal@lists.freepascal.org <fpc-pascal@lists.freepascal.org>
Sent: Tuesday, March 21, 2023, 23:49:30
Subject: [fpc-pascal] Converting Delphi7 code to FreePascal with interfacing to
protection key?
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?
--
Bo Berglund
Developer in Sweden
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
