Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 17 of 17 total
Thread 2.06 Build 2 - Access Violation TEDBQuery in 64-bit
Tue, Dec 6 2011 1:05 PMPermanent Link

Jose Pascoa

Avatar

On Mon, 5 Dec 2011 17:27:28 -0500, "Tim Young [Elevate Software]"
<timyoung@elevatesoft.com> wrote:

>Jose,

Finally, (I don't want to bug more), all the ASM in DBISam is also not
suitable for 64-bit.

JP
Tue, Dec 6 2011 8:34 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jose,

<< You need to remove the ASM from edbcommon.pas in 64-bit. >>

It sounds like you're using 2.06 B1:

http://www.elevatesoft.com/incident?action=viewrep&category=edb&release=2.06&incident=3512

The interlocked functions were replaced in edbcommon.pas in Build 2:

http://www.elevatesoft.com/incident?action=viewrep&category=edb&release=2.06&incident=3512

However, I looked at the source code in our distributions, and for some
reason the asm still is present in the source units.  So, I'm going to have
to figure out what is going on.  There appears to be an issue with the build
system.

In general, the code should look like this:

function LockedCompareExchange(var TargetValue: Integer;
                              ExchangeValue: Integer;
                              CompareValue: Integer): Integer;
{$IFDEF CLR}
begin
  Result:=Interlocked.CompareExchange(TargetValue,ExchangeValue,CompareValue);
{$ELSE}
{$IFDEF FPC}
begin
  Result:=InterlockedCompareExchange(TargetValue,ExchangeValue,CompareValue);
{$ELSE}
{$IFDEF WIN64}
begin
  Result:=Windows.InterlockedCompareExchange(TargetValue,ExchangeValue,CompareValue);
{$ELSE}
asm
  XCHG EAX, ECX
  LOCK CMPXCHG [ECX], EDX
{$ENDIF}
{$ENDIF}
{$ENDIF}
end;

procedure LockedIncrement(var TargetValue: Integer);
{$IFDEF CLR}
begin
  Interlocked.Increment(TargetValue);
{$ELSE}
{$IFDEF FPC}
begin
  InterlockedIncrement(TargetValue);
{$ELSE}
{$IFDEF WIN64}
begin
  Windows.InterlockedIncrement(TargetValue);
{$ELSE}
{$IFDEF D6ORHIGHER}
asm
  LOCK INC [EAX]
{$ELSE}
begin
  Windows.InterlockedIncrement(TargetValue);
{$ENDIF}
{$ENDIF}
{$ENDIF}
{$ENDIF}
end;

procedure LockedDecrement(var TargetValue: Integer);
{$IFDEF CLR}
begin
  Interlocked.Decrement(TargetValue);
{$ELSE}
{$IFDEF FPC}
begin
  InterlockedDecrement(TargetValue);
{$ELSE}
{$IFDEF WIN64}
begin
  Windows.InterlockedIncrement(TargetValue);
{$ELSE}
{$IFDEF D6ORHIGHER}
asm
  LOCK DEC [EAX]
{$ELSE}
begin
  Windows.InterlockedDecrement(TargetValue);
{$ENDIF}
{$ENDIF}
{$ENDIF}
{$ENDIF}
end;

--
Tim Young
Elevate Software
www.elevatesoft.com
Tue, Dec 6 2011 8:35 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jose,

<< Finally, (I don't want to bug more), all the ASM in DBISam is also not
suitable for 64-bit. >>

This is the same issue with the builds - the source code is updated, but for
some reason the distributed source code is not:

procedure V123EncryptBuffer(var Buffer; NumBytes: Integer;
                           Key1: Byte; Key2: Byte);
{$IFDEF D15ORHIGHER}
var
  I: Integer;
{$ENDIF}
begin
  {$IFDEF D15ORHIGHER}
  I:=0;
  while (I < NumBytes) do
     begin
     (pByte(@Buffer)+I)^:=((pByte(@Buffer)+I)^ xor Key1);
     (pByte(@Buffer)+I)^:=((pByte(@Buffer)+I)^ xor Key2);
     Inc(Key1);
     Dec(Key2);
     Inc(I);
     end;
  {$ELSE}
  asm
     PUSH     EDI
     PUSH     EBX
     XOR      ECX,ECX
     MOV      ECX,NumBytes
     JCXZ     @@Done
     XOR      EBX,EBX
     MOV      BL,Key1
     MOV      BH,Key2
     MOV      EDI,Buffer
  @@Loop1:
     XOR       EAX,EAX
     MOV       AL,[EDI]
     XOR       AL,BL
     XOR       AL,BH
     MOV       [EDI],AL
     INC       BL
     DEC       BH
     INC       EDI
     LOOP      @@Loop1
  @@Done:
     POP       EBX
     POP       EDI
  end;
  {$ENDIF}
end;

procedure V123DecryptBuffer(var Buffer; NumBytes: Integer;
                           Key1: Byte; Key2: Byte);
{$IFDEF D15ORHIGHER}
var
  I: Integer;
{$ENDIF}
begin
  {$IFDEF D15ORHIGHER}
  I:=0;
  while (I < NumBytes) do
     begin
     (pByte(@Buffer)+I)^:=((pByte(@Buffer)+I)^ xor Key2);
     (pByte(@Buffer)+I)^:=((pByte(@Buffer)+I)^ xor Key1);
     Inc(Key1);
     Dec(Key2);
     Inc(I);
     end;
  {$ELSE}
  asm
     PUSH     EDI
     PUSH     EBX
     XOR      ECX,ECX
     MOV      ECX,NumBytes
     JCXZ     @@Done
     XOR      EBX,EBX
     MOV      BL,Key1
     MOV      BH,Key2
     MOV      EDI,Buffer
  @@Loop1:
     XOR      EAX,EAX
     MOV      AL,[EDI]
     XOR      AL,BH
     XOR      AL,BL
     MOV      [EDI],AL
     INC      BL
     DEC      BH
     INC      EDI
     LOOP     @@Loop1
  @@Done:
     POP      EBX
     POP      EDI
  end;
  {$ENDIF}
end;

--
Tim Young
Elevate Software
www.elevatesoft.com
Tue, Dec 6 2011 9:12 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jose,

Okay, I found out the issue.  Our build system "strips" the engine source
code for distribution, meaning that it scans through it and removes any
non-applicable code for a given OS, platform, language, etc.  The build
system wasn't doing this properly for the 64-bit code because it was missing
a compiler define for "Win64".  This would also apply to DBISAM, and would
be why everything seemed to be "off" and none of the 64-bit bugs fixed.
Unfortunately, this also affects the object code that we distribute since
the .dcus and .bpls are also built from this "stripped" code.

I will be uploading new builds later this week that correct this issue.  My
apologies for the confusion.

--
Tim Young
Elevate Software
www.elevatesoft.com
Wed, Dec 7 2011 5:32 AMPermanent Link

Jose Pascoa

Avatar

On Tue, 6 Dec 2011 21:12:43 -0500, "Tim Young [Elevate Software]"
<timyoung@elevatesoft.com> wrote:

>Jose,
>

>a compiler define for "Win64".  This would also apply to DBISAM, and would

Tim,

Delphi uses
CPUX64 not Win64.

Do you have a fixed 2.06 Build 2 now, or is better to wait for B3?

JP
Wed, Dec 7 2011 8:23 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jose,

<< Delphi uses
CPUX64 not Win64. >>

It also uses Win64 in XE2:

http://docwiki.embarcadero.com/RADStudio/en/Conditional_compilation_(Delphi)

<< Do you have a fixed 2.06 Build 2 now, or is better to wait for B3? >>

You'll have to wait for B3.  I'm still held up on new builds right now due
to an issue with our code-signing certificate.

--
Tim Young
Elevate Software
www.elevatesoft.com
Wed, Dec 7 2011 10:10 AMPermanent Link

Jose Pascoa

Avatar

On Wed, 7 Dec 2011 08:23:29 -0500, "Tim Young [Elevate Software]"
<timyoung@elevatesoft.com> wrote:

>Jose,
>
><< Delphi uses
> CPUX64 not Win64. >>
>
>It also uses Win64 in XE2:
>
>http://docwiki.embarcadero.com/RADStudio/en/Conditional_compilation_(Delphi)
>

You are right. But System.pas uses CPUX64 from top to bottom and only
once Win64.

JP
« Previous PagePage 2 of 2
Jump to Page:  1 2
Image