Fastcode AES
Dennis
Prepare yourself for an AES challenge :-)
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/
Regards
Dennis
Dennis
I am currently translating the reference C implementation to Pascal.
Would somebody help me finding the current State of the art implementations
and perhaps compile them into dll's with a Pascal interface unit?
The Brian Gladman Visual C++ version with MMX is often mentioned.
Regards
Dennis
Dennis
Atle Smelvær
implementation
Wolfgang Ehrhardt
On my AES page at <http://home.netsurf.de/wolfgang.ehrhardt> you will
find open source AES Pascal code for TP5-BP7, Delphi 1-7, VP, FPC
units and source code for a DLL etc. Speed is a bit less than
B.Gladman's C++ code (cyles/clock with Pentium 4:
Fun/Bit C++ D3
Enc/128 385 406
Dec/128 376 444
Wolfgang
--
In order to e-mail me a reply to this message, you will have
to remove PLEASE.REMOVE from the address shown in the header
or get it from http://home.netsurf.de/wolfgang.ehrhardt
(Free AES, CRC, Hash, and HMAC source for Pascal/Delphi)
Dennis
I want to validate against the reference implementation. Compiling it into a
dll is one way to do that. Another way is to use C++Builder's capability to
compile Pascal and C in the same project. Currently I use C++Builder to
translate the reference C implementation and validate the Pascal version
against it.
Just picking a given implementation gives me no certainty that it is valid.
Regards
Dennis
Dennis
> On my AES page at <http://home.netsurf.de/wolfgang.ehrhardt> you will
> find open source AES Pascal code for TP5-BP7, Delphi 1-7, VP, FPC
> units and source code for a DLL etc. Speed is a bit less than
> B.Gladman's C++ code (cyles/clock with Pentium 4:
>
> Fun/Bit C++ D3
> Enc/128 385 406
> Dec/128 376 444
>
>
> Wolfgang
Fine. I will check it out. Is it validated against the reference
implementation?
Regards
Dennis
Dennis
I have included the TurboLock version in the B&V
http://sourceforge.net/projects/tplockbox/
Regards
Dennis
Dennis
I need some advice. I have adopted the Turbolock interface for the
encryption function.
procedure EncryptRDL(const Context : TRDLContext; var Block : TRDLBlock);
How do I in the best way align/misalign the Context and Block variables
before calling the function?
I want to benchmark 4, 8 and 16 byte alignments .
The block size is always 128 bit in AES.
Regards
Dennis
Wolfgang Ehrhardt
You cannot validate against a reference implementation, you validate
against published test vectors. If you compile the reference
implementation, you must verify that your compiler works ok by
comparing against the published test vectors! The test vectors
included in for example 'rijndael-dos-refc.tar' are usable only for
the most basic cases, which should be avoided in real applications.
A quote from my page: "Building on these [the basic, we] routines, the
following recommended block cipher modes of operation are implemented:
CBC, CFB128, CTR, ECB, OFB. All chaining modes allow plain and cipher
text lengths that need not be multiples of the block length ...
The zip file contains many test programs which are used to check
compilation processes, the implementation against known test values,
and the code speed."
Wolfgang Ehrhardt
Forget Lockbox for FastCode or serious applications:
There no way to set an explicit IV, it uses pseudo random IVs!!!! It
is incredible slow, has few modes, buffer encryption based on streams
etc ...
Dennis
> You cannot validate against a reference implementation,
Sure I can.
>you validate
> against published test vectors. If you compile the reference
Yes that is a good thing.
> implementation, you must verify that your compiler works ok by
> comparing against the published test vectors! The test vectors
Do you not trust compilers?
If it should be invalid to validate against a reference function things are
going to be very hard. Validating against test vectors is a good thing - if
they are not generated by the reference implementation compiled with a bad
compiler!
If we compile the reference code with one compiler and our own
implementation with another then a compiler bug in either compiler would
make our validation fail and we investigate matters. But ok - would could be
mislead and "fix" our own code to compensate for the compiler bug.
Validating against a reference implementation does not rule out validation
against known good results. I generally do both whereever possible.
Regards
Dennis
Dennis
Thanks for your input. I still have something (a lot!) to learn;-) and
discussing matters is good for learning.
> Forget Lockbox for FastCode or serious applications:
If it is correct then it can be used as a starting point.
> There no way to set an explicit IV, it uses pseudo random IVs!!!! It
What is an IV? This first challenge concentrates on encryption/decryption. I
see round key generation as another challenge (to come). Generation of keys
is still another issue that I have not considered yet.
> is incredible slow, ¨
It does not matter how fast it is because we will optimize it or create our
own new functions. Our functions follow the agreed upon interface and passes
the validation. Everything else is free. So expect to see a lot of SSE2 and
SSE3 code :-)
>has few modes
I am going to include only one mode per challenge. This one is based on CFB
? mode. Feed a key and a block into the encryption function and you got
ciphertext. Put the same key and the cipher text into the decryption
function and you get the plaintext.
>, buffer encryption based on streams etc ...
I see no streams here ;-)
{ Rijndael Cipher }
procedure InitEncryptRDL(const Key; KeySize : Longint;
var Context : TRDLContext; Encrypt : Boolean);
procedure EncryptRDL(const Context : TRDLContext;
var Block : TRDLBlock);
procedure EncryptRDLCBC(const Context : TRDLContext;
const Prev : TRDLBlock; var Block : TRDLBlock);
Does the other modes use these three basic functions as well?
Is the speed of the other modes determined (mostly) by these three core
functions?
> Wolfgang
Regards
Dennis
Johannes Berg
> The Brian Gladman Visual C++ version with MMX is often mentioned.
I'm also aware of a complete i586 asm implementation he wrote.
johannes
Wolfgang Ehrhardt
<maria...@home3.gvdnet.dk> wrote:
[snip]
>What is an IV?
For info about IVs see for example
<http://www.ciphersbyritter.com/GLOSSARY.HTM#IV> and
[snap]
>I am going to include only one mode per challenge. This one is based on CFB
>? mode. Feed a key and a block into the encryption function and you got
>ciphertext. Put the same key and the cipher text into the decryption
>function and you get the plaintext.
That's called ECB not CFB (CFB needs an IV). For and introduction see
<http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation>
This page has a nice "striking example of the degree to which ECB can
reveal patterns in the plaintext."
Recommended:) "Recommendation for Block Cipher Modes of Operation"
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
WE
Dennis
> Forget Lockbox for FastCode or serious applications:
>
> There no way to set an explicit IV, it uses pseudo random IVs!!!! It
> is incredible slow, has few modes, buffer encryption based on streams
> etc ...
Is it version 2.07 you find slow?
http://sourceforge.net/projects/tplockbox/
> Wolfgang
Best Regards
Dennis
Wolfgang Ehrhardt
Yes, it IS slow. Here are some timings, even 16Bit BP7 needs only
about 1/10 of the Lockbox times. Times are in [s] for 128 MB data, 128
bit key, 1.8 GHz P4, Win98
Package/Compiler CTR CFB OFB ECB CBC Rem.
Lockbox/D3 - - - 88.40 121.10 (1)
LibTom094/DJGPP 4.56 4.78 4.40 - - (2a)
LibTom094/MinGW 4.45 4.52 4.39 - - (2b)
LibTom094/VC6 3.03 3.08 2.97 - - (2b)
dcpcrypt2/D6 6.81 7.69 6.75 - 7.74 -
DEC/D3 - - - 2.47 2.64 (3)
WE/D3 2.25 2.04 2.04 1.97 2.25 -
WE/D6 2.31 2.03 2.04 1.98 2.14 -
WE/VPC 2.47 2.47 2.47 2.25 3.13 (4)
WE/FPC GoV2 3.73 3.74 3.68 3.63 4.18 -
WE/BP7 11.75 10.77 10.82 8.95 12.96 -
(1) Turbopower's Lockbox uses stream primitives and random CBC IV
(2a) DJGPP GCC 3.2.2 -O3 -funroll-loops
(2b) MinGW GCC 3.3.1 -O3 -funroll-loops
(2c) MSVC6 SP4 /Ox /DWIN32
(3) Hagen Reddmann's CFB and OFB are 8 bit feedback modes
(4) Version 2.1.279
Get more numbers and links to the third party implementations from the
AES page at <http://home.netsurf.de/wolfgang.ehrhardt>. In the file
CompareSource_2004-06-10.zip you can find the test program for LockBox
and other.
Dennis
> For info about IVs see for example
> <http://www.ciphersbyritter.com/GLOSSARY.HTM#IV> and
A very nice site.
Regards
Dennis
Dennis
Very interesting. Do you know why it is so slow? The code does not look bad
at first sigth and I tried optimize it a little and found nothing especially
bad yet.
I will probably release a preliminary version of the B&V tomorrow. Then we
can investigate matters.
Regards
Dennis
"Henrick Hellström [StreamSec]"
> Forget Lockbox for FastCode or serious applications:
I agree with Wolfgang. The Lockbox API is not appropriate for almost
anything but ECB mode and (of course) compatibility with Lockbox itself.
A minimum requirement is that there is a way to explicitly set the IV
for the mode, if anything but ECB mode is benchmarked.
Furthermore, real life applications will not only encrypt the data, but
also calculate a MAC of it. Having a fast AES implementation does not
necessarily entail that the entire cryptosystem is fast, if the
encryption function and the MAC function are called separately on the
same data.
--
Henrick Hellström
www.streamsec.com
Wolfgang Ehrhardt
<maria...@home3.gvdnet.dk> wrote:
>Hi Wolfgang Ehrhardt and All
>
>Very interesting. Do you know why it is so slow? The code does not look bad
>at first sigth and I tried optimize it a little and found nothing especially
>bad yet.
IMHO, suboptimal design:
1) stream primitive, ie EncryptBuffer uses streams
function TLbCipher.EncryptBuffer(const InBuf; InBufSize : Cardinal;
var OutBuf) : Cardinal;
var
InS, OutS : TMemoryStream;
begin
InS := TMemoryStream.Create;
OutS := TMemoryStream.Create;
try
InS.SetSize(InBufSize);
InS.Write(InBuf, InBufSize);
InS.Position := 0;
EncryptStream(InS, OutS);
OutS.Position := 0;
OutS.Read(OutBuf, OutS.Size);
Result := OutS.Size;
finally
InS.Free;
OutS.Free;
end;
end;
2) Although there is a Setkey method, the first action EncryptStream
performs is a InitEncryptRDL(Key, KeySize, Context, Encrypt)
>I will probably release a preliminary version of the B&V tomorrow. Then we
>can investigate matters.
With a modification favoring LockBox of my test program which uses FAC
times the original buffer size, I get the following results (times in
s, Delphi 3, Pentium 5 1.8GHz, Win98):
FAC ECB CBC
50000 15.6 16.2
10000 15.7 16.4
1000 14.8 15.6
500 14.4 15.2
50 15.1 16.4
5 29.6 35.5
2 51.4 67.1
{ 1 88.4 121.1
D3/WE 1.97 2.25 }
Dennis
Please look in the new thread and continue the discussion there.
Regards
Dennis
Dennis
I am trying to include your basic functions into the challenge.
I have a few problems.
1) warnings "const expression violate bounds". This is your arrays of
longint that you initialize with to big numbers for the signed range of
longint. Should longint be Cardinal in Delphi?
2) I cannot make the decryption validate. I am probably doing something
wrong in the wrapper I have made to copy the block and context into your
types and the result back. (It is still really ugly ;-) and for a speed
comparison it is of course not wanted)
procedure EncryptAES_WE_PAS_1(const Context; var Block);
var
pContext : ^TAESContext;
pBlock : ^TAESBlock;
ctx: TAES_WE_Context;
BI: TAES_WE_Block;
BO: TAES_WE_Block;
I1, I2, RoundKeysSize, RoundKeySize : Integer;
begin
pContext := @Context;
pBlock := @Block;
//Copy roundkeys
for I1 := 0 to AES_WE_MaxRounds do
begin
for I2 := 0 to 15 do
begin
ctx.RK[I1, I2] := pContext.RoundKeys.RK[I1, I2];
end;
end;
//or do it this way
//RoundKeySize := Length(pContext.RoundKeys.RK);
//RoundKeysSize := AES_WE_MaxRounds+1 * RoundKeySize;
//Move(pContext.RoundKeys.RK, ctx.RK, RoundKeysSize);
//not needed ?
//ctx.IV
//ctx.buf
//ctx.bLen
//ctx.Flag
//ctx.IncProc
ctx.Rounds := pContext.Rounds;
ctx.KeyBits := pContext.KeySize * 32;
//Copy block
{for I3 := 0 to 15 do
begin
BI[I3] := pBlock[I3];
end;}
//or with move
Move(pBlock[0], BI, 16);
if pContext.Encrypt then
begin
//ctx.Decrypt := 0;//False;
//procedure AES_Encrypt(var ctx: TAES_WE_Context; const BI:
TAES_WE_Block; var BO: TAES_WE_Block);
AES_WE_Encrypt(ctx, BI, BO);
end
else
begin
//ctx.Decrypt := 1;//True;
//procedure AES_Decrypt(var ctx: TAES_WE_Context; var BI: TAESBlock; var
BO: TAESBlock);
AES_WE_Decrypt(ctx, BI, BO);
end;
{for I4 := 0 to 15 do
begin
pBlock[I4] := BO[I4];
end;}
//Copy result
Move(BO, pBlock[0], 16)
end;
Regards
Dennis
Wolfgang Ehrhardt
<maria...@home3.gvdnet.dk> wrote:
>Hi Wolfgang Ehrhardt
>
>I am trying to include your basic functions into the challenge.
>
>I have a few problems.
>
>1) warnings "const expression violate bounds". This is your arrays of
>longint that you initialize with to big numbers for the signed range of
>longint. Should longint be Cardinal in Delphi?
Could be, but you will loose compatibility. Better use my contruct
{$ifdef D4Plus}
{$warnings off}
{$endif}
.... (tables) ...
{$ifdef D4Plus}
{$warnings on}
{$endif}
or something similar.
>2) I cannot make the decryption validate. I am probably doing something
>wrong in the wrapper I have made to copy the block and context into your
>types and the result back. (It is still really ugly ;-) and for a speed
>comparison it is of course not wanted)
May be you should use the supplied function to turn an encrytion key
to a decryption key:
{---------------------------------------------------------------------------}
procedure MakeDecrKey(var ctx: TAESContext);
{-Calculcate decryption key from encrytion key}
var
i: integer;
p: PLong;
x: longint;
begin
p := PLong(@ctx.RK[1]);
for i:=1 to 4*(ctx.Rounds-1) do begin
x := p^;
p^ := T8[SBox[x shr 24]] xor T7[SBox[x shr 16 and $ff]] xor
T6[SBox[x shr 8 and $ff]] xor T5[SBox[x and $ff]];
inc(p);
end;
end;
[snip}
If you are still using the LockBox-Tables please not that RDL_InvTx
are non-standard (kind of undocumented pre/post processing?)
>
>Regards
>Dennis
>
>
Hope that helps
Dennis
Thanks. Now I know what to do tomorrow ;-)
Can you tell me why the context (roundkeys) has to be changed?
Perhaps you could tweak your code to fit into our challenge? Then the
benchmark results would be fair. There is to much overhead in the wrapper I
made.
Regards
Dennis
Wolfgang Ehrhardt
<maria...@home3.gvdnet.dk> wrote:
>Hi Wolfgang Ehrhardt
>
>Thanks. Now I know what to do tomorrow ;-)
>
>Can you tell me why the context (roundkeys) has to be changed?
My routines use the Equivalent Inverse Cipher (cf AES FIPS 197
<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf> Fig, 15
for Pseudo Code or Brian Gladman's Chap. 5.5
<http://fp.gladman.plus.com/cryptography_technology/rijndael/spec.v311.pdf>
Many implementation I know use this. The key has not to be changed,
you can setup both keys (like David Bartons DCPrijndael.pas in his
dcpcrypt2, <http://www.cityinthesky.co.uk/cryptography.html>). I
think, two keys are wasted space because the most used recommended
block cipher modes (CTR, CFB, OFB) dont use decryption keys/routines.
>Perhaps you could tweak your code to fit into our challenge? Then the
>benchmark results would be fair. There is to much overhead in the wrapper I
>made.
IMHO your V02 source is not the most intuitive one:) and your D6+ non
portable code/small font/large screen setup is far away from my BP7/D3
portable code/large font/small screen development environment.
BUT if you can supply a fairly clear communication spec (or at least
an API description) ...
>
>Regards
>Dennis
Dennis
> My routines use the Equivalent Inverse Cipher (cf AES FIPS 197
> <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf> Fig, 15
> for Pseudo Code or Brian Gladman's Chap. 5.5
>
<http://fp.gladman.plus.com/cryptography_technology/rijndael/spec.v311.pdf>
>
> Many implementation I know use this. The key has not to be changed,
> you can setup both keys (like David Bartons DCPrijndael.pas in his
> dcpcrypt2, <http://www.cityinthesky.co.uk/cryptography.html>). I
> think, two keys are wasted space because the most used recommended
> block cipher modes (CTR, CFB, OFB) dont use decryption keys/routines.
Sorry for being slow to understand ;-)
Is this correct?
I/Lockbox/Rijndael reference use the same key for decryption and encryption.
You use two different keys.
> IMHO your V02 source is not the most intuitive one:)
Have a look at version 0.3. Only few changes. Can you give me some specifics
to improve?
>and your D6+ non
> portable code/small font/large screen setup is far away from my BP7/D3
> portable code/large font/small screen development environment.
You claim support for D6 and D7?
> BUT if you can supply a fairly clear communication spec (or at least
> an API description) ...
Sure. We have one function and a function pointer to it in the B&V. Your
have two functions with almost identical interfaces and the wrapper is very
easy. Look out for release 0.4 today. I will give some better answers later
today. Want to have a cup of coffee in my garden now ;-) The first day with
sunshine for a long time - better use it ;-)
> Wolfgang
Regards
Dennis
Wolfgang Ehrhardt
<maria...@home3.gvdnet.dk> wrote:
After fiddling with your main form from V03 to fit on
my screen I came up with the following changes
=============================================
1. Replace your AESWEUnit.pas with
unit AESWEUnit;
interface
procedure EncryptAES_WE_PAS_1(const Context; var Block);
{-Wrap Dennis/Lockbox API to WE API}
implementation
uses
AESTurboLockUnit, AES_Type, AES_Encr, AES_Decr;
procedure EncryptAES_WE_PAS_1(const Context; var Block);
{-Wrap Dennis/Lockbox API to WE API}
var
ctx: TAES_WE_Context;
begin
with TAESContext(Context) do begin
move(RoundKeys.RK, ctx.rk, sizeof(ctx.RK));
ctx.Rounds := Rounds;
ctx.KeyBits := KeySize * 32;
if Encrypt then AES_WE_Encrypt(ctx, TAES_WE_Block(Block),
TAES_WE_Block(Block))
else begin
MakeDecrKey(ctx);
AES_WE_Decrypt(ctx, TAES_WE_Block(Block), TAES_WE_Block(Block));
end;
end;
end;
end.
2. In aes_decr.pas copy this function declaration to the interface
procedure MakeDecrKey(var ctx: TAES_WE_Context);
{-Calculate decryption key from encrytion key}
=============================================
After this and some time ValidationEdit.Color turns to clGreen
NOTE: calling MakeDecrKey(ctx) every time for decrytion is overkill
because it uses much more time than the decrypt routine itself. If
you include decryption in benchmark test, the driver must call
MakeDecrKey(ctx) only once for a key.
--
Wolfgang
>
>Regards
>Dennis
Wolfgang Ehrhardt
<maria...@home3.gvdnet.dk> wrote:
>Hi Wolfgang Ehrhardt
>
>> My routines use the Equivalent Inverse Cipher (cf AES FIPS 197
>> <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf> Fig, 15
>> for Pseudo Code or Brian Gladman's Chap. 5.5
>>
><http://fp.gladman.plus.com/cryptography_technology/rijndael/spec.v311.pdf>
>>
>> Many implementation I know use this. The key has not to be changed,
>> you can setup both keys (like David Bartons DCPrijndael.pas in his
>> dcpcrypt2, <http://www.cityinthesky.co.uk/cryptography.html>). I
>> think, two keys are wasted space because the most used recommended
>> block cipher modes (CTR, CFB, OFB) dont use decryption keys/routines.
>
>Sorry for being slow to understand ;-)
>
>Is this correct?
>
>I/Lockbox/Rijndael reference use the same key for decryption and encryption.
>You use two different keys.
>
Yes it is correct. The rounds loop processing is "rearranged". A small
quote from Gladman's spec.v311: "The importance of this transformation
is that the structure of the forward cipher allows the round function
to be expressed in an efficient form for implementation. By
transforming the inverse cipher into the same sequence of operations
as the cipher itself, it can be implemented in the same way, thereby
achieving this efficiency."
>> IMHO your V02 source is not the most intuitive one:)
>
>Have a look at version 0.3. Only few changes. Can you give me some specifics
>to improve?
I have included some code in my 15:52 posting. Validation OK,
benchmark works but numbers are not explained.
>>and your D6+ non
>> portable code/small font/large screen setup is far away from my BP7/D3
>> portable code/large font/small screen development environment.
>
>You claim support for D6 and D7?
Yes, did you find anything that did not work (if you use my original
code of course)?
Dennis
> Yes it is correct. The rounds loop processing is "rearranged". A small
> quote from Gladman's spec.v311: "The importance of this transformation
> is that the structure of the forward cipher allows the round function
> to be expressed in an efficient form for implementation. By
> transforming the inverse cipher into the same sequence of operations
> as the cipher itself, it can be implemented in the same way, thereby
> achieving this efficiency."
Can you give me some details about this. It looks like it is a good idea to
have two keys and the B&V should allow this.
Regards
Dennis
Dennis
> >You claim support for D6 and D7?
> Yes, did you find anything that did not work (if you use my original
> code of course)?
No I think it is OK. It just looked to me like you had problems working with
D6/7.
I still do not understand that longint should be the correct datatype for
the boxes and not Cardinal on D6/7.
> Wolfgang
Regards
Dennis
Wolfgang Ehrhardt
Hi Dennis,
Borrowed from FIPS-197 via cut and paste
<quote>
{Pseudo code cipher}
AddRoundKey(state, w[0, Nb-1])
for round = 1 step 1 to Nr-1
SubBytes(state)
ShiftRows(state)
MixColumns(state)
AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])
end for
SubBytes(state)
ShiftRows(state)
AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])
{Pseudo code inverse cipher}
AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])
for round = Nr-1 step -1 downto 1
InvShiftRows(state)
InvSubBytes(state)
AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])
InvMixColumns(state)
end for
InvShiftRows(state)
InvSubBytes(state)
AddRoundKey(state, w[0, Nb-1])
{Pseudo code for the Equivalent Inverse Cipher}
AddRoundKey(state, dw[Nr*Nb, (Nr+1)*Nb-1])
for round = Nr-1 step -1 downto 1
InvSubBytes(state)
InvShiftRows(state)
InvMixColumns(state)
AddRoundKey(state, dw[round*Nb, (round+1)*Nb-1])
end for
InvSubBytes(state)
InvShiftRows(state)
AddRoundKey(state, dw[0, Nb-1])
Given these changes, the resulting Equivalent Inverse Cipher
offers a more efficient structure than the Inverse Cipher...
</quote>
As you can see the sequence of single transformations
in the Equivalent Inverse Cipher is the same as in the
encrypt cipher ("modulo inv" and of course with dw as
roundkeys). That the Equivalent Inverse Cipher seems to
be more efficient is not only stated by "experts", you
can check it using the timings of the challenge.
Wolfgang Ehrhardt
<maria...@home3.gvdnet.dk> wrote:
>Hi Wolfgang Ehrhardt
>
>> >You claim support for D6 and D7?
>> Yes, did you find anything that did not work (if you use my original
>> code of course)?
>
>No I think it is OK. It just looked to me like you had problems working with
>D6/7.
Apart from bloatedness, time consuming start, some more bugs etc
compared with D3 I have no problems with D6/7.
>I still do not understand that longint should be the correct datatype for
>the boxes and not Cardinal on D6/7.
There is nothing wrong with using Cardinal for D4+, you can use both,
the code does not use arithmetic only boolean/shift operations. I use
longint for portability (Cardinal is unsigned 31 bit in VP, unknown in
TP/BP etc, longint is the same for all the comilers). What I dont
understand is, why D4+ do not accept the HEX values without warning
(therefore I turn warnings off at those places); I can unterstand
warnings for decimal longints greater than MaxLongint.
Dennis
Thanks.
Regards
Dennis