dummzeuch

I just tried to install Delphi 10.2 (Tokyo) on Windows XP. The ESD-Installer refused to run. The one from the ISO started and the installation finished successfully. But on the first start, a browser window opens to http://installers.embarcadero.com/tamper?Version=25.0.29899.2631&Code=00409116 which times out. That's it. Not quite what I was expecting.

Wasn't there an option now to have the embedded form designer on one screen and put an undocked secondary editor window on a second screen? I seem to remember reading a blog post about this.

The constant also exists in Delphi 6, value is 14. Older versions don't have it.

Hm, I thought I had fixed that particular issue by restricting the allowed values for that setting. Need to look at this code again.

Unlikely.

There are the CompilerVersion and RtlVersion constants, but they are not the values you would want to display.

I'm afraid even that is probably just coincidence. I also get this error once in a while. Unfortunately I was never able to find the actual cause. The assertion message is just a side effect. The issue is that the resources that assertion checks for, are not freed. The easiest "fix" would be to remove the assertion. Fortunately it only happens when exiting the IDE, so it's mostly a nuisance.

After looking into general spin locks I now had a closer look at TCriticalSection and the internally used TRtlCriticalSection record with associated API functions. One thing I didn't know about is the SetCriticalSectionSpinCount API function which allows to adjust the SpinCount of a CriticalSection, in theory that is: My tests on my computer with Windows 10 have shown that using SetCriticalSectionSpinCount after initializing a TRtlCriticalSection with InitializeCriticalSection has no effect at all. It only works if either InitializeCriticalSectionEx (Windows 7 and later) or InitializeCriticalSectionAndSpinCount (also available in Windows XP) is used for initializing it. The SetCriticalSectionSpinCount will only then actually change the SpinCount. I couldn't find anything about this in the documentation, but maybe I wasn't looking hard enough. Also, apparently Microsoft has changed what InitializeCriticalSectionEx does. If has a Flag parameter which according to the documentation can be set to CRITICAL_SECTION_NO_DEBUG_INFO to prevent debug information to be generated. But my tests show that this has no effect at all on Windows 10. To get debug information, one has to specify the undocumented flag RTL_CRITICAL_SECTION_FLAG_FORCE_DEBUG_INFO. Again, maybe that's documented somewhere but I didn't find it. Something else I learned is, that a Delphi RTL's TCriticalSection also has a TryEnter method which calls the TryEnterCriticalSection API function. Somehow I missed that for all those years. The test results are also interesting on how different SpinCounts affect the general throughput for different numbers of threads. The default (which seems to be 2000 but I am not sure about this, as it is set dynamically by Windows and may depend on the hardware and the system load) is generally OK but using 100 gives a much better throughput in all my tests with different numbers of threads. Simple+Sleep is a "spinlock" that only checks for access and then calls Sleep(1) TdzCritSectTest uses a TRtlCriticalSection initialized with InitializeCriticalSection TdzCritSectTestInit100 uses TRtlCriticalSection initialized with InitializeCriticalSectionAndSpinCount to SpinCount of 100 But these tests are very synthetic: I have n + m threads running in an endless loop until aborted: The n writers execute this code: procedure TLockTest.doWrite; var i: Integer; Value: Integer; begin AcquireLock; Value := Random(100); for i := 0 to Length(FDataToSafguard) - 1 do FDataToSafguard[i] := Value; ReleaseLock; end; FDataToSaveguard is an array of 10 integers. The m Checkers execute this code: procedure TLockTest.doCheck; var i: Integer; Value: Integer; begin AcquireLock; Value := FDataToSafguard[0]; for i := 1 to Length(FDataToSafguard) - 1 do if FDataToSafguard[i] <> Value then InterlockedIncrement(FErrors); ReleaseLock; end; So they not only read the data but also check that it is correct (that's why I call these "checkers" rather than "readers"). The reason for this code is that I wanted to make sure that the array is actually being protected because this test was also meant for my homegrown spinlock code. I'm not sure what to make of this regarding real world code because it's very rarely that it doesn't matter which thread gets executed how often. E.g. if there is one or more writers filling a queue of some kind and one or more readers emptying it, it can happen that readers become idle if writers don't get access to the queue. In that scenario a high "throughput" as measured by my test program won't be a good thing. I guess I'll have to come up with a better test. If you want to look at the code, it's in my dzlib repository on OSDN: https://svn.osdn.net/svnroot/dzlib-tools/dzlib/trunk TdzRtlCriticalSection is in src\u_dzCriticalSection, the test is in tests\SpinLockTest. (Yes, I should probably have made this a blog post....)

None at all, this was purely out of curiosity. Thanks for the links.

That's just coincidence. The changes only applied to forms using TStringgrid with custom drawing and an error that occurred when registering GExperts via rundll32. All those only apply to the Delphi 10.4 version, that's why I didn't try to compile other versions and overlooked the missing unit.

Ooops, yes, I forgot to add the new unit to the other projects.

Fixed in revision #3450. Thanks.

Another option would have been to use the stand alone ExpertManager. That's what I did and it worked. I just used it to uninstall GExperts and tried your way. I got the same error, but only after the command line window seemed to hang and I closed it.

They would abandon Delphi for good in that case. There is no way Embarcadero would start that tool from scratch.

We have been using our inhouse Delphi (2007, XE and lately 10.2) applications almost exclusively via remote Desktop since the start of the Corona pandemic without any problems at all. There is a bug in the Delphi 2007 VCL which can cause an AV when switching between local display and Remote Desktop. After I found and fixed it several years ago (don't remember the specifics), everything just worked. Also, I have been using Delphi 2007, XE2 and 10.2 (and sometimes other versions) via Remote Desktop for years. No problem either. So, my guess would be that this is just marketing. If I had to guess: A Remote Desktop friendly program does not create too many redraws. So: Use double buffering.

The following function raises an Access Violation when compiled with Delphi 2007 with optimization turned on, but works fine with optimization turned off: function TryInterlockedMask(var _Destination: LongWord; _AndMask, _OrMask: LongWord): Boolean; var OldValue: LongWord; NewValue: LongWord; CurValue: LongWord; begin {$IFDEF DEBUG} Assert(IsAlignedOn32bitBoundary(@_Destination), 'Destination is not aligned to a 32 bit boundary'); {$ENDIF} OldValue := _Destination; NewValue := OldValue and _AndMask or _OrMask; CurValue := InterlockedCompareExchange(_Destination, NewValue, OldValue); Result := (OldValue = CurValue); end; Can you see any problems with it? It has been used for many years in a program which was always compiled with debug settings where optimization was turned turned off. Now I have created release settings for the project with optimization turned on (and changed some other compiler options but I verified that it is optimization that causes the problem) and all of a sudden it bombed out. After turning optimization off for this function only, it works fine again.

No, not yet.

No, it's a (actually the only) field in an object, so it should always be 32 bits aligned. Also, the assertion in the code checks for that condition and was active in all my tests and never failed.

I am reinventing the wheel again (yes, I like doing that). Can you see anything wrong with these SpinLock functions? (for Win32 only) ///<summary> /// simple spin lock function, Lk must have been initialized with 0 before first use </summary> procedure doLock(var _Lk: Integer); asm mov edx, eax mov ecx, 1 @Loop: mov eax, 0 lock cmpxchg dword ptr [edx], ecx jnz @Loop end; ///<summary> /// simple spin unlock function, Lk must have been initialized with 0 before first use </summary> procedure doUnLock(var _Lk: Integer); asm lock dec dword ptr[eax]; end; ///<summary> /// simple spin trylock function, Lk must have been initialized with 0 before first use /// @returns True if the lock could be acquired, False otherwise </summary> function doTryLock(var _Lk: Integer): Boolean; asm mov edx, eax mov ecx, 1 mov eax, 0 lock cmpxchg dword ptr [edx], ecx setz al end; doLock and doUnlock are taken from https://vitaliburkov.wordpress.com/2011/10/28/parallel-programming-with-delphi-part-ii-resolving-race-conditions/ doTryLock is based on doLock and uses the setz opcode to return a boolean rather than looping. I have done tests and they seem to work, but it's always difficult to actually test multi threaded code.

Since I just wrote one myself, here you go: program AlignedOn32BitBoundaryTest; {$APPTYPE CONSOLE} uses SysUtils; {$IF not declared(UIntPtr)} type {$IF SizeOf(Pointer)=4} UIntPtr = UInt32; {$ELSE} UIntPtr = UInt64; {$IFEND} {$IFEND} function IsAlignedOn32bitBoundary(_Ptr: Pointer): Boolean; begin Result := ((UIntPtr(_Ptr) and $3) = 0); end; procedure CheckAlignedOn32BitBoundary(const _s: string; _Ptr: Pointer); begin if IsAlignedOn32bitBoundary(_Ptr) then WriteLn(_s + ' is aligned on a 32 bit boundary') else WriteLn(_s + ' is not aligned on a 32 bit boundary') end; type TSomeRect = packed record SomeByte: byte; SomeCardinal: Cardinal; end; var SomeRect: TSomeRect; begin CheckAlignedOn32BitBoundary('SomeByte', @SomeRect.SomeByte); CheckAlignedOn32BitBoundary('SomeCardinal', @SomeRect.SomeCardinal); WriteLn('press enter'); ReadLn; end.

Thanks. I understood what the bug report said. I just can't reproduce it on my computer. That doesn't mean that I will ignore it. @merijnbs workaround, while it probably works, is not really one I would like to implement.

Odd, this doesn't happen on my 10.4.2 test installation (and also not on my 10.4.1 installation). What does happen, is that the editor window loses focus. No idea where it goes. But that's not limited to GExpert's Open File and Delphi 10.4., it also happens without GExperts and e.g. on Delphi 10.2.

Damn, I never get the name of that setting right.

How long do you want to argue about this? Until I cede that it's useless? Ok: it's useless. You win.

You either need to add those prefixes to all units or alternatively add them to the name space prefixes list of the packages. I'd probably go for the latter. But on the other hand I wonder why those packages don't already contain them. These prefixes have been around for ages.