dummzeuch

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.

I don't quite agree that it's useless, but it could definitely be much more useful if it did get restored on an IDE restart.

Because I could. It started out as a simple test whether it was possible to create additional dock windows which were themselves not docked in the IDE. When it turned out that it's possible, I added it as an expert in the hope that it might be useful to somebody.

It's not very high on my to-do list, as I only know of only two people who use this feature, and I'm not one of them. But as always, I'll accept patches.

Yes, but the IDE doesn't know anything about these additional docking windows and there seems to be no way to make it aware of them.

There are also several firewall apps for Android which should allow checking for this, but I have never actually used one. Given, that Google knows about everything about me due to me using an Android phone, GMail and being constantly logged into my Google account while surfing the web, I don't really see a need to check whether any of the other Google tools submits any more information. If I ever find a usable replacement for GMail, I might make an effort though.

The additional Dock Window implementation does not support saving and restoring for now.

Google Authenticator is a One Time Password Generator. There are several alternatives that work the same way and are open source, e.g. FreeOTP is the one I use. These apps use the current time and a shared secret (with the server) to generate a 6 digit number. They all generate the same number given the same input, so you could use it to authenticate with your own app. The number is only valid for login for about 30 seconds. Of course Google Authenticator could use the data you add into it and the information about when you use it to log into which service for Googles purposes. But since it does not need an internet connection to fulfill its purpose, you could simply check whether it phones home or not. If it does, it's doing something it doesn't need to do and probably shouldn't do. Or, if you want to be 100% sure, use an open source solution and compile it yourself. (There are other methods to generate One Time Passwords, see e.g. Wikipedia for that.)

I offered to help out and even submitted pull requests with updates for them, but they were ignored for several months. Then I gave up.

If I remember correctly, it was added in Delphi 10.4, so it won't help much if you develop for multiple Delphi versions.

re 1: Then I probably need to repeat these tests on a system where the Delphi IDE hasn't run (yet), because I am not sure whether it had been running before the tests or not. re 2/3: There are lots of discussions on the web about Sleep(0) vs. Sleep(1) vs. SwitchToThread and there seems to be no definite answer which one to use in a spin lock. It all depends on the circumstances. re 4: Again, this depends on the circumstances. With a small protected section and low contention a spin lock might be way faster than a critical section. I was trying to find out whether that might solve some issues I had with a particular program. It turned out that it didn't (but again, I need to repeat the test taking into account what I have learned in the meantime), but this had started me into the topic.

Hm, shouldn't the assertion go into a constructor?

I read somewhere (when I was searching for 'Yield'), that Yield doesn't exist on Arm processors and there simply translates to NOP. Not sure whether I understood that correctly because at the time I wasn't really interested in Arm.