Delphi 5 to 2010

Question

I used same function ( OneWayEncrypt(edit1.Text) ) in Delphi 5 and 2010.
Why the results are different? (Or how can I give the same results from Delphi 2010?)

uses Sysutils, Windows, Dialogs, classes;

function OneWayEncrypt(AStr: string): string;
PROCEDURE CalcCRC32 (p:  pointer; ByteCount:  DWORD; VAR CRCvalue:  DWORD);

implementation

const 
  table:  ARRAY[0..255] OF DWORD = 
  (
    //table consts are here
  );

PROCEDURE CalcCRC32(p: pointer; ByteCount: DWORD; VAR CRCvalue: DWORD);
VAR
  i: DWORD;
  q: ^Byte;
BEGIN
  q := p;
  FOR i := 0 TO ByteCount - 1 DO
  BEGIN
    CRCvalue := (CRCvalue SHR 8) XOR table[q^ XOR (CRCvalue AND $000000FF)];
    INC(q);
  END
END;

function OneWayEncrypt(AStr: string): string;
var
  dwCrc: DWORD;
  s: string;
begin
  dwCrc := $FFFFFFFF; 
  s := 'X' + AStr + '7F';
  CalcCRC32(Addr(s[1]), Length(s), dwCrc);
  result := IntToHex(dwCrc, 8);
end;

Answer 1

D2010 (and D2009) use Unicode strings (widestrings), so the character size is different (bytes). Try switching all references of string to AnsiString.

Answer 2

Are you aware that string refers to a Unicode string in D2010, while it refers to AnsiString in versions < D2009? That should be the source of your problem.

So you have two choices:

• You could replace all appearances of string with AnsiString. This should give you the same results as in D5, of course without Unicode support
• You could refactor your code. I guess that the pointer-"hacking" is the crucial part here. But I have to admit, I didn't take the time to fully understand the code ;-) (It could very well be that your code can't be used with Unicode anyways, due to the 255 consts = ISO8859?)

Answer 3

Minimal port, one line change:

  // old code:
  CalcCRC32(Addr(s[1]), Length(s), dwCrc);

  // delphi 2010 code:
  CalcCRC32( PAnsiChar(AnsiString(s)), Length(s), dwCrc);

Please be aware that any unicode content in the unicode "String" will be lost, but any ANSI (A-Z, 1,3,4, you know) codepoints you used before, for example "Hello", should work just like before. Since this is a CRC32 algorithm, it could do a CRC32 on a UTF8 encoding of the string too, easily.