Rollo62

Hi there, I was looking into the GetTimerTick64 function and see that under Apple products, the mach_absolute_time function is used, to get a precide timer. Unfortunately Apple requires privacy declarations of mach_absolute_time: mach_absolute_time NSPrivacyAPITypes NSPrivacyAccessedAPICategorySystemBootTime For the usual usage of GetTimerTick64(), I would say the 35F9.1 would be most relevant. I would say this is used in any apps using some kind of internal timing or timerticks behaviour, that will fall under these requirements. Regarding such funktion, I think they can easily automatically test for this, if your app uses the function, or not, so it should already give a warning in an automated test from Apple Review. I do not use the absolute boot time, which they claim to be dangerous, but only derived timer ticks informations, which fall under the exception. My questions are: - Does the exception above mean, that you don't need to give such informations in the manifest? Or do you need to put it there anyway, no matter of exception or not, to declare that you make use of the mach_absolute_time() funtion. - Did Delphi already took care of this somehow ( I cannot see any of such entries in any manifest )? - How do you handle this, does anybody include these markers in the manifest? - Is anybody aware of, that Apple was rejecting an App in the Review, because of this? - If yes, how did you solved this with Apple? Perhaps you could share some logs or noted from their review, how they explain such issue to you. This would be interesting to clarify, before tapping into another Apple booby trap.

Oh yes, I have forgotten about this thread, not considering that this is also related to GetTickCount64() & mach_absolute_time() Thanks, then I know which direction to go.

Thanks, I will look into it. Strange, I have never seen such a Transporter issue yet, but time will come Does it clearly tell you the reason of the rejection?

Thanks for the proposals, but again, I'm not looking for QueryPerformanceCounter, but about the Now(); behaviour. Moreover I'm looking for a cross-platform sulution, not Windows alone. I dont need high performance for this task, the 15ms would be fine. It could be even OK, if 1 Sec., if this happens only very very rare ( but I would like to avoid that ). I hope that someone knows exactly where the 1 Sec. comes from and what conditions will make it to show up.

Like said, I know about performance counters, but I want to use Now() and GetTimerTick64() for other tasks, accepting the 15ms tolerances. The question is about, what the Now() 1 Sec. tolerance really means nowadays, is it gone or is it a valid case?

Hi there, sorry for the little joke in the title, but what currently makes me headaches is the fact that after May will be broken. I used iOS as stable debugging platform for many years now, which seems to breakdown hard in a few days. The alternative Android was never that stable for debugging over the same many years, getting better now, but no replacement. The big problem now is, that Apple seems to enfore the use of their latest tools after 01.05.2024, which would make the use of XCode 14.3.1 for releases impossible. For the possible XCode changes and reasons I figured out the following possible facts for my record. Perhaps they were not all correct, maybe only a few, so please feel free to correct me, if you have more insights into the XCode ecosystem. In general, there seems to be a huge change in the new XCode debugging system. Overview of the changes seen in XCode 15: Topic Old (Xcode 14.3.1) New (Xcode 15) Comments Debugging platform partly still 32-bit using 64-bit only The new debugging platform seems to remove older 32-bit code internally completely. Debugging Framework GDB-based LLDB-based New debugging framework based on LLDB, incompatible with older GDB-based framework. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Debugging Libraries libgcc.dylib, libc++.dylib, New debugging libraries, incompatible with the older libraries used by D12.1. libstdc++.dylib libc++abi.dylib Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Symbolication Manual Automatic Xcode 15 introduces automatic symbolication, incompatible with manual symbolication used by D12.1. Debugging Protocol GDB protocol LLDB protocol New debugging protocol, incompatible with the older GDB protocol used by D12.1. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Breakpoint Handling Software breakpoints Hardware breakpoints Uses hardware breakpoints, incompatible with the software breakpoints used by D12.1. Debug Information STABS debug format DWARF debug format New debug information format, incompatible with the older STABS format used by D12.1. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers I would like to know if this huge XCode change is really upcoming soon, and what can we do about it in the near future? Is there any workaround in sight? I'm afraid, that we have to wait for the next Delphi Update or Patch, which maybe changes a lot of the internals ( libraries, PAServer, workflows, ... ). Are there any news from Embarcadero, about this topic, so that we could see any light in the tunnel? Would be great if there is a way, to make XCode 15 compatible with Delphi, or vice versa. My considerations so far: - Use Android for Debugging, even if it not that stable. Perhaps there are ways to improve Android debugging too. - Forget Mobile debugging, rely only on Logging ( the worst case for me ). - Still use XCode 14.3.1 for debugging, while releasing under XCode 15. This is problematic, because I think XCode 14.3.1 dosen't allow to use iOS 17.4, and perhaps two versions cannot switch easily on the macOS host. Are there any tested workflows, like xcode-select --switch /Applications/Xcode14.app/Contents/Developer and xcode-select --switch /Applications/Xcode15.app/Contents/Developer ? That also means, we would possibly need two sorts of devices with iOS 16.x ( DEBUG + Log ) and iOS 17.4 ( RELEASE + Log ) for proper tests ( Permanent upgrade / downgrade is not an option ). - Embarcadero already had worked out a stable Update 2, to simply make iOS 17.4 debuggable and testable. ( The best case for me ). - Any smart hack, to make XCode 14.3.1 producing releases still? Perhaps, setting a build-ID could do the job, but I'm completely unsure about that. When Apple finds such hacks, this may also be considered as infringement and lead in blocking the app in the store, which could be even harder. - Other ideas / news / thoughs, are there any ? Edit: See above table, it seems that Delphi >= Alexandria can already make use of LLDB debugging system: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers

Thanks, but that was already clear. The problem is, that simulators are not behaving exactly like devices, especially with sensors and hardware stuff, this is why I rarely use them.

Python seems most natual to me, since all 3 libraries may support it or have wrapper for that. Moreover is Python maybe also a natural way to use these kind of libraries ( but I'm not a Chemist ), so to put a Delphi UI on top would have a lot of benefits IMHO, while still keeping the full force of Python to C++ underneath. The additional burden to install and requiring Python-Libs for such project seems minor to me. Esspeciall when you think of combining Chemistry with AI features, I think you are already right in the Python world.

I'm still testing porting from 10.3.1 to 10.3.2 In one FMX project for Macos, when just opening and compiling the working project, I've got some messages when compiling under Macos64 (Of coarse it works well under all other platforms). 1.) This message is strange, because the Imports folder is not there at all, not even the 20.0\ folder, because I installed the IDE under d:\Prj\... Under d:\Prj\Embarcadero\Studio\20.0\Imports I have that folder (which is almost empty, just a subfolder with one VCL related file "\Idl\StdVCL.idl". 2.) Its strange because of the reference to kernel32.-dll I have searched my settings, compiler, linker, deployment, registry, but I'm not lucky and couldn't find where these locations are maybe set. My BDSCOMMONDIR environment variable points to a folder close: C:\Users\reg_w\OneDrive\Dokumente\Embarcadero\Studio\20.0, but thats working at all other platforms. Then I decided to completely migrate via an new, empty project, like I described here: Create new FMX app, removed orignal unit1 and added my units from the old project. So now I got a more informative message, but still similar: compiling OK, linking failed The empty project runs, but when I add my units, something went wrong. I'm not recalling to have anything affecting linking in my code, but I haven't checked that yet. Which screw could I turn to remove this linker error, I hope somebody has a clue ? Edit: As usual, just when I prepare and sended a thread, it hits me in the face what this could be. The folder seems to be related to Spring4D .. To get Spring4D compiled, I used the following addition to switch to PUREPASCAL, which seemed to compile fine. I'M using the development branch, from not too long ago (2 weeks), haven't checked for changes. {$I Spring.inc} {$IFDEF MACOS64} // <--Addition {$DEFINE PUREPASCAL} {$ELSE} {.$DEFINE PUREPASCAL} {$ENDIF MACOS64} unit Spring.Events; So probably I have to c heck what happens with Spring4D in my Macos64 tests ... How can I switch S4D to Macos64 in the right way ?

This topic has nothing to do with Macos, FMX, Spring4D, Kastri or whatsever. This error was caused by a region, which was a leftover from Copy-Paste code from Windows, which I shouldn't do in the first place. The Region {$REGION 'Windows helper functions'} function SetThreadExecutionState(esFlags: EXECUTION_STATE): EXECUTION_STATE; stdcall; external 'kernel32.dll'; was hiding this Windows-Kernel related kernel reference, which was never used anywhere, but this one line never showed up as an error at this point. This tells me, that using regions to hide code, may also hide code to spot obvious failures sometimes.

Yes, but not because its irrelevant. But that's because even the last snoozer has realised that by now.

@Kas Ob. Yes, I have read about CloudFlare a lot of positive things, but I'm not yet an active user. Your proposal will add additional cost, I think minimum 5$ per month, right? My question would be, how far do I get with their free tier service? As far as I understand, this will be an unlimited, somehwhat protected DNS server, perhaps thats already solving such issues. Is the free tier usable for a commercial server, with not too wild traffic?

Hard to say. One effective approach could be behavior-based rate limiting rather than relying solely on IP tracking. Since these hackers are making two requests at a time from each IP and cycling through thousands of addresses, you could analyze request patterns to flag suspicious behavior. For example: - Track request timing and frequency per IP: Legitimate users rarely hit your site with precise, repetitive timing (e.g., two requests exactly every 24 hours). You could set a threshold where IPs making requests in a tight, unnatural cadence (say, under a second apart) get temporarily soft-blocked (e.g., delayed responses or a 429 Too Many Requests status) without affecting users with more organic patterns. - Fingerprinting beyond IP: Use a lightweight client-side fingerprinting technique (e.g., based on HTTP headers like User-Agent, Accept-Language, or even subtle timing differences in TCP handshakes). If the same fingerprint appears across multiple IPs in a short window, it’s a strong signal of VPN rotation from a single source. You could then throttle or block those requests without needing a CAPTCHA. - Perhaps you need only a few countries, so you could block most of all other country requests - or something like Fail2Ban https://github.com/fail2ban/fail2ban

@Anders Melander I found an older case of yours, here at DevExpress. https://supportcenter.devexpress.com/ticket/details/t812550/an-av-occurs-if-the-spell-checker-whose-usethreadedload-property-is-set-to-true-reloads Which speaks against FreeAndNil too.

Thanks, that sounds like I would never consider this in the first place. This is why I am asking for a simple, generic example to better understand why this would probably make sense. Do you know a specific place in the VCL/FMX code, where it is used like that?

Ok, you both are right, but I still wonder why its used in so many places, if its that unnecessary. The "reduce" was intended as fast fix, if you have no other choice to complete rework or repair anything in time, but you have to ship an update fast, used more or less like as a debugging tool. There must be at least one real use-case, where FAN makes perfectly sense. Yes, I already mentioned this use-case, so is this the only one? Why are there so many places using FAN during Create/Destroy, without any lazy injection? I only can think of critical timing or race-condition protection somehow.

Thanks, its clear then, how the capture of anonymous methods work. We came from the question how FreeAndNil might be helpful here, in this kind of situations, right? Aren't there any situations where FAN can be useful, perhaps with an Assigned( FVar ) guard, were everybody can agree on? I can see much use of FAN in Delphi RTL, Spring4D and all many places all around, but at the same time everybody disagrees on its usefulness & better to avoid it, thats strange ... Where and why is it useful then, if not in situations where I want to check and mark the validity of a lazy Field or the like, for example by Assigned()? I cannot think of much use-cases, where I would ever need this. - If I use it in the case where I inject an object to a class, not by DI, but by method or property, then this would make sense to protect a Field by FAN, IMHO. - In a use case where I purely manage a Field myself by Create/Destroy, it doesn't make much sense if there is no possibility of delayed access to it. So maybe somebody has a clean example, to show where it makes sense?

Sorry, if this was misunderstanding as an advice. It was searching for use cases of FreeAndNil, to help debugging such issues. And sometimes I have to solve problems which comes unexpected, by external influences, where I have little information and influence about. Ok, maybe there are ways to identify and encapsule these issues better, but most of the time they came a little out of the blue.

I just find some time to present an alternative solution, without FreeAndNil, as example with an cancellation token, it could probably look like this, which is more work to do. But the basic problem stays the same, that the cause of the blocking cannot be cancelled. It cannot be allowed to wait forever, after free, so the destroy must compromise somehow. I am not sure, if touching the cancellation token variable on a freed object causes the same issues, I would guess. Perhaps the interfaced token variable preserves the handle accessible, so that it will be safe to touch it within the freed class, but I won't bet on this. So in which places a FreeAndNil should be used then, only in global variables ( don't shoot the messenger ) 🙂 There must be good use cases for FreeAndNil anywhere. type ICancellationToken = interface ['{8C3A7E13-7C12-4F4F-92F5-DA1111111111}'] function GetCancelled: Boolean; procedure Cancel; property Cancelled: Boolean read GetCancelled; end; TCancellationToken = class(TInterfacedObject, ICancellationToken) private FCancelled: Boolean; public function GetCancelled: Boolean; procedure Cancel; end; function TCancellationToken.GetCancelled: Boolean; begin Result := FCancelled; end; procedure TCancellationToken.Cancel; begin FCancelled := True; end; ... type TMyClass = class private FCancellationToken: ICancellationToken; public constructor Create; destructor Destroy; override; procedure StartAsyncTask; end; constructor TMyClass.Create; begin inherited Create; FCancellationToken := TCancellationToken.Create; end; destructor TMyClass.Destroy; begin // Signal the cancellation FCancellationToken.Cancel; // Perhaps a wait mechanism implementation here, if needed, but exactly this is not always possible ??? inherited Destroy; end; procedure TMyClass.StartAsyncTask; begin TTask.Run( procedure begin // Example: Loop until cancellation while not FCancellationToken.Cancelled do begin // Simulation of blocking, regularily checking for cancellation. Exactly this might not alwys be possible. Sleep(100); end; if FCancellationToken.Cancelled then begin // Task is cancelled Exit; end; TThread.Synchronize(nil, procedure begin // Callback-Code Writeln('Task finished gracefully.'); end); end); end;

Ok, I'm open for your proposals If you got very sporadic AV on some customers devices and you are not able to reproduce that or to find any hints .... Sometimes a fast solution is needed, when a complete rewrite is currently not possible in time and you're unsure about the root cause. Of course I like to solve things once and forever too, and I only try to find possible use cases for the FreeandNil, which I have seen before.

Yes, but from my experience, this helps to REDUCE the risk of AV's, in case of async processes, where you cannot safely cancel such async operation, because its not directly under your control. Another example could be a call inside from an anonymous method, how can you canel that, if the class it freed?

To make this discussion less academic: I like to use FreeAndNil in places, where Async callbacks may occur. For example like this (roughly hacked example, excuse typos): type TMyClass = class private FMyVar : TStringList; // The problematic object FMyCallback : TProc; public constructor Create; destructor Destroy; override; procedure Conf_Callback(const AProc: TProc); procedure DoOnCallback; end; constructor TMyClass.Create; begin inherited Create; FMyVar := TStringList.Create; FMyCallback := nil; end; destructor TMyClass.Destroy; begin FreeAndNil( FMyVar ); // Free the object and prevent further calling it FMyCallback := nil; inherited Destroy; end; procedure TMyClass.Conf_Callback(const AProc: TProc); begin FMyCallback := AProc; end; procedure TMyClass.DoOnCallback; begin if not Assigned(FMyVar) then begin DoLogThisIssue; // Logging the rare problem Exit; //<== GUARD end; FMyVar.Add( 'Hello'); // Using an existing object, which is protected by FreeAndNil end; In cases where TMyClass is already freed, but pending async functions might still call the DoOnCallback function. If this happens, the guard may REDUCE THE RISK of an sporadic AV, probably. I know, the arguments against this are, that this should never happen and I should rewrite the code calling DoOnCallback in the first place. But in reality, I see these things might happen, especially in highly async, undetermined, not well testable situations, which will result in unwanted AV's, but where this situation only happens very rarely of system dependent. In that case I prefer to have at least an AV prevention, over having some kind of other issues in the app ( this is of course not a banking app ). At least I'm able to debug or log these rare situations in the guard. I would think of like these two categories: # High critical apps: Either you need a perfect stable, reliable and high-security app ( like banking, high security authentication, database, airplane control, etc. ) # Uncritical apps : Or you have an relative uncritical app, where its more important to not annoy customers by rare crashes, where you can try to catch such issues by logging.

Unfortunately, they wont use Delphi, do they?

Thanks for the info. From what I understood, these components came as binary package only, which would be a no-go for me. Can you confirm this, or am I interpreting their specs falsely?

I usually look into market surveys, which phones or brands were selling best https://www.heise.de/news/Smartphone-Markt-hat-sich-2024-erholt-chinesische-Marken-legen-zu-10241291.html#nav_marktanteile__1 Then you have a chance that you are testing on whats your clients are using most. Google Pixel is perhaps the best, most modern and best supported Android phone, which helps to be state-of-the-art, but its market share is quite low still.