Lars Fosdal

Have any of you used this old lib in 64-bit? It works fine in 32-bit, but I get Project MyProject.exe raised exception class EDCP_cipher with message 'Unable to allocate sufficient memory for hash digest'. when running as 64-bit. Curious to know if anyone has worked around this issue already.

No argument there from me, as I didn't write the code.

Spinoff QP entry. https://quality.embarcadero.com/browse/RSP-42133 Warning when a pointer is cast of a different size integer Consider the following code procedure Indata(const InData); var X: array[0..1] of DWord; begin x[0]:= PDWord(@InData)^; x[1]:= PDWord(LongWord(@InData)+4)^; This works well in 32-bit, but when you switch to 64-bit, LongWord is still 32-bit, and and casting a pointer to LongWord will then strip the upper 32-bits of the 64-bit pointer and the PDWord pointer will be wrong; Ideally, the compiler should spot when the integer being cast to a pointer is of a different size (32 vs 64) than the integer type and issue a warning.

Circular Reference - See Reference, Circular Reference, Circular - See Circular Reference Joke aside, simplified it means that you have a UnitA using UnitB, and UnitB using UnitA.

The visibile link is correct, but the underlying link points to this thread 🙂

I decided to test switching one my 32-bit apps to 64-bit, to see how it would behave. It uses an encryption algorithm called TwoFish from an old encryption lib - DCPCrypt2 by David Barton- which seems to no longer be maintained, and to my dismay, the encryption failed with a access violation. Project ConsoleTest.exe raised exception class $C0000005 with message ‘c0000005 ACCESS_VIOLATION’. that was eaten by an exception handler in the lib - which presented a different error message EDCP_cipher: Unable to allocate sufficient memory for hash digest It fails on the first half of this expression in the code below; x[1]:= PDWord(longword(@InData)+4)^ xor SubKeys[INPUTWHITEN+1]; i.e. PDWord(longword(@InData)+4)^ Question: Longwords and DWords are supposedly the same in both 32-bit and 64-bit, so why does the pointer arithmetic fail in 64-bit? Below is the original method that works well in 32-bit, but blows up in 64-bit. In the DCPtwofish.pas unit: procedure TDCP_twofish.EncryptECB(const InData; var OutData); var i: longword; t0, t1: DWord; X: array[0..3] of DWord; begin if not fInitialized then raise EDCP_blockcipher.Create('Cipher not initialized'); x[0]:= PDWord(@InData)^ xor SubKeys[INPUTWHITEN]; x[1]:= PDWord(longword(@InData)+4)^ xor SubKeys[INPUTWHITEN+1]; // <- 64-bit Access Violation! x[2]:= PDWord(longword(@InData)+8)^ xor SubKeys[INPUTWHITEN+2]; x[3]:= PDWord(longword(@InData)+12)^ xor SubKeys[INPUTWHITEN+3]; i:= 0; while i<= NUMROUNDS-2 do begin t0:= sBox[0,(x[0] shl 1) and $1fe] xor sBox[0,((x[0] shr 7) and $1fe)+1] xor sBox[2,(x[0] shr 15) and $1fe] xor sBox[2,((x[0] shr 23) and $1fe)+1]; t1:= sBox[0,((x[1] shr 23) and $1fe)] xor sBox[0,((x[1] shl 1) and $1fe)+1] xor sBox[2,((x[1] shr 7) and $1fe)] xor sBox[2,((x[1] shr 15) and $1fe)+1]; x[3]:= (x[3] shl 1) or (x[3] shr 31); x[2]:= x[2] xor (t0 + t1 + SubKeys[ROUNDSUBKEYS+2*i]); x[3]:= x[3] xor (t0 + 2*t1 + SubKeys[ROUNDSUBKEYS+2*i+1]); x[2]:= (x[2] shr 1) or (x[2] shl 31); t0:= sBox[0,(x[2] shl 1) and $1fe] xor sBox[0,((x[2] shr 7) and $1fe)+1] xor sBox[2,((x[2] shr 15) and $1fe)] xor sBox[2,((x[2] shr 23) and $1fe)+1]; t1:= sBox[0,((x[3] shr 23) and $1fe)] xor sBox[0,((x[3] shl 1) and $1fe)+1] xor sBox[2,((x[3] shr 7) and $1fe)] xor sBox[2,((x[3] shr 15) and $1fe)+1]; x[1]:= (x[1] shl 1) or (x[1] shr 31); x[0]:= x[0] xor (t0 + t1 + SubKeys[ROUNDSUBKEYS+2*(i+1)]); x[1]:= x[1] xor (t0 + 2*t1 + SubKeys[ROUNDSUBKEYS+2*(i+1)+1]); x[0]:= (x[0] shr 1) or (x[0] shl 31); Inc(i,2); end; PDWord(longword(@OutData)+ 0)^:= x[2] xor SubKeys[OUTPUTWHITEN]; PDWord(longword(@OutData)+ 4)^:= x[3] xor SubKeys[OUTPUTWHITEN+1]; PDWord(longword(@OutData)+ 8)^:= x[0] xor SubKeys[OUTPUTWHITEN+2]; PDWord(longword(@OutData)+12)^:= x[1] xor SubKeys[OUTPUTWHITEN+3]; end; The answer came from a fellow developer elsewhere: It fails because pointers are not longwords in 64 bit and casting to longword clips the upper 32 bits, so the cast of a pointer to a longword is not the way to do it. Instead - the correct way would be to change the expression to PDWord(UIntPtr(@InData)+4)^ After some fiddling in the debugger, I thought - why not try a cleaner approach to the pointer casts, and this is what I came up with - and it works as intended in both 32-bit and 64-bit, without the explicit offset calculations. type ArrDWord = array[0..3] of DWord; pArrDWord = ^ArrDWord; procedure TDCP_twofish.EncryptECB(const InData; var OutData); var i: longword; t0, t1: DWord; X: array[0..3] of DWord; begin if not fInitialized then raise EDCP_blockcipher.Create('Cipher not initialized'); x[0]:= PArrDWord(@InData)[0] xor SubKeys[INPUTWHITEN]; x[1]:= PArrDWord(@InData)[1] xor SubKeys[INPUTWHITEN+1]; x[2]:= PArrDWord(@InData)[2] xor SubKeys[INPUTWHITEN+2]; x[3]:= PArrDWord(@InData)[3] xor SubKeys[INPUTWHITEN+3]; i:= 0; while i<= NUMROUNDS-2 do begin t0:= sBox[0,(x[0] shl 1) and $1fe] xor sBox[0,((x[0] shr 7) and $1fe)+1] xor sBox[2,(x[0] shr 15) and $1fe] xor sBox[2,((x[0] shr 23) and $1fe)+1]; t1:= sBox[0,((x[1] shr 23) and $1fe)] xor sBox[0,((x[1] shl 1) and $1fe)+1] xor sBox[2,((x[1] shr 7) and $1fe)] xor sBox[2,((x[1] shr 15) and $1fe)+1]; x[3]:= (x[3] shl 1) or (x[3] shr 31); x[2]:= x[2] xor (t0 + t1 + SubKeys[ROUNDSUBKEYS+2*i]); x[3]:= x[3] xor (t0 + 2*t1 + SubKeys[ROUNDSUBKEYS+2*i+1]); x[2]:= (x[2] shr 1) or (x[2] shl 31); t0:= sBox[0,(x[2] shl 1) and $1fe] xor sBox[0,((x[2] shr 7) and $1fe)+1] xor sBox[2,((x[2] shr 15) and $1fe)] xor sBox[2,((x[2] shr 23) and $1fe)+1]; t1:= sBox[0,((x[3] shr 23) and $1fe)] xor sBox[0,((x[3] shl 1) and $1fe)+1] xor sBox[2,((x[3] shr 7) and $1fe)] xor sBox[2,((x[3] shr 15) and $1fe)+1]; x[1]:= (x[1] shl 1) or (x[1] shr 31); x[0]:= x[0] xor (t0 + t1 + SubKeys[ROUNDSUBKEYS+2*(i+1)]); x[1]:= x[1] xor (t0 + 2*t1 + SubKeys[ROUNDSUBKEYS+2*(i+1)+1]); x[0]:= (x[0] shr 1) or (x[0] shl 31); Inc(i,2); end; PArrDWord(@OutData)[0] := x[2] xor SubKeys[OUTPUTWHITEN]; PArrDWord(@OutData)[1] := x[3] xor SubKeys[OUTPUTWHITEN+1]; PArrDWord(@OutData)[2] := x[0] xor SubKeys[OUTPUTWHITEN+2]; PArrDWord(@OutData)[3] := x[1] xor SubKeys[OUTPUTWHITEN+3]; end; Here is the test code: uses DCPtwofish, DCPsha1; const CRYPT_KEY = 'TheVØryBÆDSecretStr.ing'; function EncryptTwofish(const s: string; Key: string = CRYPT_KEY) : string; var Cipher : TDCP_twofish; begin Result:=''; Cipher := TDCP_twofish.Create(nil); try Cipher.InitStr(AnsiString(Key), TDCP_sha1); Result := string(Cipher.EncryptString(AnsiString(s))); finally Cipher.Free; end; end; procedure TestEncrypt; begin Writeln(EncryptTwoFish('Keep this text a secret')); end;

I figured it out, but I need to do some more checking to figure out why it didn't fail in 32-bit.

Writing your own VPN software in Delphi. Would you write your own Firewall too? Just say no. You don't need the liability.

You need to load the JSON structures in memory, and then feed them row by row to your memtable. Here is an example: https://stackoverflow.com/questions/55766112/importing-json-into-tfdmemtable

Precisely.

Captures problems can be easy to miss.

@FLDelphi Use your favorite git tool (I prefer GitKraken) and clone the OTL main branch to the folder of your liking. If you use components, build and install them. Use the git tool periodically to check for / pull updates.

Not sure if you missed my edit?

That sounds like a bug? There should be a MouseUp event? Edit: The "modal window" may be receiving the event instead of the parent form.

One could measure the time between the events to decide if they should be coupled - but ... lots of extra work. IMO, the Alt should normally be pressed BEFORE the click, and released AFTER the click-release - although you could interpret it as the Alt status only being required/captured at the time of the initial click, and only use the click-release as completion event.

@Mustafa E. Korkmaz Does this setting have any effect? https://support.microsoft.com/en-us/windows/auto-color-management-in-windows-11-64a4de7f-9c93-43ec-bdf1-3b12ffa0870b Edit: What is the color resolution of the system that Windows 11 runs on? Is there a way to optimize the image palette to match the default 256 color Windows palette?

https://quality.embarcadero.com/browse/RSP-41961 The process of cleaning up circular references can be quite challenging, as we today have no good tool to discover and track the unit interdependcy. "Blatant" circular references are explicitly forbidden, but since we can include units both in the interface and the implementation section - it is quite easy to circumvent this rule. Another challenge is when you inadvertently drag in a massive collection of units into your project, because someone needed a structure or function from a specific unit - which again uses other units, which uses others again - and so forth. The discovery of where this unit is included, and when in the compilation it is parsed, would be significantly helped by a simple build log. A sequential log of the compilation of each unit in the application - indicating where it first was necessary to compile another unit to complete the current unit. I suggested it could look something like this - more comments in the QP issue. Pls vote/comment if you find it interesting. unit1 compiling... unit2 compiling... unit3 compiling... unit3 compiled (lines, warnings, hints) unit2 compiled (lines, warnings, hints) unit1 compiled (lines, warnings, hints)

Does this code still work? https://stackoverflow.com/questions/23410377/delphi-active-window-screenshot Once you capture the window as a bitmap, then you can print.

Is it a service you are trying to debug?

Among other things. See comments in issue. It has also been said that dealing with circularity is increasingly challenging for the compiler.

Does using field name 'loginid' instead of 'login' have any effect? I am merely guessing here now - I have not used PG much.

> pk_test_table" PRIMARY KEY ("login", ticket) Why is login quoted, but not ticket?

In my experience, list separators tend to follow the locale - hence the question.

What was the solution?

I saw an example that added IndexDefs.Clear; before IndexDefs.Add... Edit: Another thing - are you certain that the field list is semi-colon delimited?