Converting to Delphi 64 bit? - delphi

Question

OgUtil.pas in onguard I want to porting to 64 bit
Delphi 64 bit not allow to use ASM with pascal Can I convert this function to work with delphi 64 bit
function LockFile(Handle : THandle;
FileOffsetLow, FileOffsetHigh,
LockCountLow, LockCountHigh : Word) : Boolean;
var
Error : Word;
begin
asm
mov ax,$5C00
mov bx,Handle
mov cx,FileOffsetHigh
mov dx,FileOffsetLow
mov si,LockCountHigh
mov di,LockCountLow
int $21
jc ##001
xor ax,ax
##001:
mov Error,ax
end;
Result := Error = 0;
end;
can convert this code to completely pascal
function UnlockFile(Handle : THandle;
FileOffsetLow, FileOffsetHigh,
UnLockCountLow, UnLockCountHigh : Word) : Boolean;
var
Error : Word;
begin
asm
mov ax, $5C01
mov bx,Handle
mov cx,FileOffsetHigh
mov dx,FileOffsetLow
mov si,UnLockCountHigh
mov di,UnLockCountLow
int $21
jc ##001
xor ax, ax
##001:
mov Error, ax
end;
Result := Error = 0;
end;
Delphi 64 bit not allow to use ASM with pascal Can I convert this function to work with delphi 64 bit
Please help to converting this code to pascal

Answer 1

You are calling the old DOS LockFile and UnlockFile functions via the interruption 21h, you can update and replace these calls by the LockFile and UnlockFile WinApi methods, which are defined in the Windows unit.
function LockFile(hFile: THandle; dwFileOffsetLow, dwFileOffsetHigh: DWORD;
nNumberOfBytesToLockLow, nNumberOfBytesToLockHigh: DWORD): BOOL; stdcall;
function UnlockFile(hFile: THandle; dwFileOffsetLow, dwFileOffsetHigh: DWORD;
nNumberOfBytesToUnlockLow, nNumberOfBytesToUnlockHigh: DWORD): BOOL; stdcall;

Answer 2

The Delphi x64 compiler does indeed support inline assembler. There is nothing to stop you writing inline assembler for the x64 compiler.
However, this is 16 bit code, and you cannot port it to either the 32 bit or 64 bit compiler. I suspect that what you have here is that OnGuard supports both 16 bit and 32 bit code. And it uses conditional compilation in places where there needs to be different implementation for 16 and 32 bit code. I bet that the OnGuard assumes that anything that is not 32 bit code is 16 bit code.
So there will likely be a {$IFDEF WIN32} test somewhere. And the code will not define LockFile and UnlockFile if that condition evaluates to True because the functions are defined in the Windows API now. And when that condition evaluates to False, the code assumes 16 bit and defines the functions. But since you are trying to support x64, the {$IFDEF WIN32} check evaluates False and the code attempts to compile 16 bit code, obviously doomed to fail.
Frankly, the best thing you can do is to remove all of the 16 bit code from this library. That will help you see the wood from the trees. I expect there will be other places in the code which attempt to use the 16 bit code simply because Win32 is not defined in the 64 bit compiler.
Update
And a quick check of the OnGuard repo reveals this code, just as I suspected:
{$IFNDEF Win32}
function LockFile(Handle : THandle; FileOffsetLow, FileOffsetHigh,
LockCountLow, LockCountHigh : Word) : Boolean;
function UnlockFile(Handle : THandle; FileOffsetLow, FileOffsetHigh,
UnLockCountLow, UnLockCountHigh : Word) : Boolean;
function FlushFileBuffers(Handle : THandle) : Boolean;
{$ENDIF}
And there are plenty more tests of Win32 which assume that the lack of that define means that the code is 16 bit. Truly this is 20th century code!
You need to look through the library for all uses of the Win32 conditional. Each and every one that you find will present a porting problem for x64.
The basic strategy you must adopt is that you want to use the Win32 variant for both 32 bit and 64 bit. So if I were you I would simply hunt down every Win32 conditional and remove the conditional. Leave behind the Win32 branch of the conditional.