Rollo62

With the default IDE settings. I usually work with the intended settings, without changing too much. This is for getting valid support answers. If someone changes everything and then something odd happens, he cannot expect to get reasonable answers from people which use the default settings. I assume the default settings are what the Embarcadero developers use too.

Exactly thats the code what I dislike, then better to have pointer math. But of coarse I have to use like that a lot too.

Thanks Remy, yes I'm aware of that fact. But dislike the 1-based approach very much (maybe from my old C/C++ background), and it leads always to headaches. I also try to avoid the {$ZEROBASEDSTRINGS ON} to keep everything most compatible. Especially I dislike mixing of 0- and 1-based in string and array access, so thats why I try to keep everything at 0-based, if possible, not to have the need for two different mindsets in place. Moreover the elegant index checking via Cardinal, as @Marat1961 described here (this was the one) is not possible in 1-based, which I use a lot, but rarely on 1-based strings for obvious reasons. The missing SetChars method is really annoying, because that means I would have to mix 0- and 1-based stuff in the String[] / Chars itself to gain read and write access, which I dislike even more.

I'm afraid the roadmap is delayed by the Coro.... !!#\-?§?/&§ Oh fuck, not again this phrase.

@David Heffernan Your're spot-on, I think thats the explanation. Moreover this thought leads to the safety on consts string objects.

Hi there, I want to use the TRestClient components mainly under mobile platforms (iOS, Android), and I want to enhance and ensure the security concept for a new app. So far that means I need to verify the certifications under all conditions, same like browsers do. Since I have seen issues with apps which doesn't check certificates properly, but since Rx10.2.2 there should be all the events in place now. The client throws an event OnValidateCertificate, which could be used to verify a certificate, I think that is the right one, not really the OnNeedCertificate event, as noted in the blog from Marco above. This event returns certain infos in the TCertificate object, which are helpful to identify and verify the certificates: TCertificate = record CertName: string; SerialNum: string; Expiry: TDateTime; Start: TDateTime; Subject: string; Issuer: string; ProtocolName: string; AlgSignature: string; AlgEncryption: string; KeySize: Integer; function IsEmpty: Boolean; end; Unfortunately there is no real simple way to check the certificate status provided, e.g. from a test-site like BadSsl.com. It seems that this can be achieved only by heavy OpenSSL and touching the OCSP protocol, maybe then the app can be able to check the full status correctly and completely. While on the other side the native browsers can do this easily, as a side-effect more or less. From my understanding of the System.Net libraries, their basic idea is to use the underlying OS SSL systems, which works well for the HTTPS connection part. But I cannot really find any simple way to make use of the underlying OS for checking certifications, even if everything for checking certificates, like OpenSSL, should be in place in the OS. So I think about using the browsers of the OS, which have such support integrated, and should be perfect candidate to check the status (Safari, Chrome). But there is also no easy way to get data from the browsers from an app either, or is there any documented way I haven't seen yet ? Moreover, even if there would be a way to get that data: Would the access to the system browser be considered as "safe", from a high security standpoint ? There could be still a man-in-the-middle attack taken place, although the risk is IMHO quite low. Is there any simple Delphi/FMX "certification checker" out there which I haven't seen yet, or do I have to re-invent the wheel ? Maybe some security experts have tips to flatten the way, to reach a high security certification of the apps.

Yes sorry for that, you're absolutely right. "check" is a too sloppy term for all these processes. What I meant by "check" was the whole process itself, including obvious steps, like expiry, and not so obvious tasks, like validation, revokations, ... all that you pointed out. Of coarse "expiry" check is an easy one, but parsing the revokation list is highly tricky. SecureBlackBox seems to be a good choice, since it supports all platforms I'm interested in Even if such thing is possible it is highly unrecommended, and in my opinion this is wrong.  I was afraid somebody would say so Well, I would not have expected that, but your opinion sounds reasonable. I usually look after the modern approach, when choosing a new techology. Indy is still around everywhere, thats fine too, but with HTTPS it always stood behind the new System.Net components, needed to carry all that OpenSSL stuff in the baggage. Not that I need to stick to TRestClient, but it looked to me more modern and I was very happy to see something like System.Net to ease such basic tasks, especially on mobile platforms. So also Indy and ICS could be the right choice too for making the connections, but isn't this in the end exchangeable, after the certificates were validated ? Then after validation the connection session is, and stays, safe ( of course not counting any TRestClient issues here ). Yes, thanks a lot. Unfortunately much to consider I always think, if security is so important and all want this, why the hell must it be that obfuscated ? I have to look into those options more deeply and check them out. Anyway, are there maybe any other configurations outside of Delphi, that might help ? Probably server-based security measures, with JWT access-token, separate authentication server, a 3rd party microservice or the like. Or specialized libraries from the local mobile platforms itself ? Yes also the server certificates itself may be compromized, but don't have all the cloud and service providers similar problems, when offering REST services to an app without a secure browser ? I think the cloud providers will have to force their users to close all security gaps, also to provide damage from themselves. Would the access-token and key exchange something that could ease or replace the whole security process, when moving to a more self-signed approach, like you described ? I think I could omit the CA root references at the moment, not sure if I will need them in a later scenario. If I consider an access-token as "small certificates", but without the overhead and easy to validate. I'm afraid then when I cannot rely on the HTTPS transfer, and need my own encryption in the transfer, also thats no easy path.

<OT> Have I ever noticed how silly "BING BING BING !" would sound </OT>

Yes, but also names might change over time, so thats no real benefit over numbers. All right, numbers have a higher risk of being re-ordered, but in principle: "enums might change over time". Thats on reason why I prefer the conversion logic nearby, in enum's class helper itself. There I have only one point of logic, where I could even do some conversion corrections from different enum-type versions.

Yes, but that may happen too when you insert a new value in a consts list, and re-order their values to make it ordered more nicely. Exactly such cases I handle in the enum itself by class helpers ToXxx and FromXxx. Working with number ranges inside an enum, I can even implement a "poor man's grouping", like enum 0 ... 99 ==> Isgroup1 enum 100 ... 199 ==> Isgroup2 All this well supported by class helpers, with least memory footprint.

Interesting philosophical discussion. I like and use enums heavily, always with full scope and "T"-named for safety reasons (to avoid cases as in the start of this thread). Of course I know some people like the "non-prefixed" version of everything, this I think leads to many issues. On the other hand, the record proposal from @Marat1961 is worth considering too, as a good 2nd alternative. Maybe they can nicely coexist both, with their pros and cons, I won't fell disturbed too much. I see also one very practical benefit that speaks for enums nowadays: They can use class helpers. From that I make also heavy use, leading to focus code where it belongs to. I'm not 100% sure, since I never checked that, but I think class helpers won't work on consts.

Hi there, I'm considering to install npm, node.js VsCode in my VmWare 11.5.6, Windows-10 guest, same where Delphi is installed. Usually I try to keep my VM's clean, but I would like to install that because of its more convenient. Now I see that it seems to require WindowsBuildTools, or a version manager or other package manager, which are maybe conflicting with the Delphi Windows Platform SDK Tools or other parts. That should not affect my builds for Windows, IOS and Android, via ms-make, c-make, etc. I think the last time when I installed this on another VM, it was still a usuall EXE, not requiring additional build tools from MS. This might have changed now, and I'm a little hesitating installing such core build tools from MS, as a usual VS installation changes so much under the hood, that its not a normal PC afterwards. There are so many options, I think Chocolatey was my lat time favorite, but thíngs are changing so rapidly, is this still a good choice ? Does anybody has experience with installing those tools altogether, with least memory footprint and least issues ? Should I install it together with Delphi, or better in a separate VM ?

Yes, but Alexa ASK CLI seems using all this, and VsCode is part of that usually too. I will try how far I get with the protable versions, but I have read some time ago that the portable stuff doesn't register everything, as it should. Npm is mainly interesting for loading everything, and I think there were some issues when loading other packages.

Is NA some kind of reserved word or math function, have you tried with .Whatever too ?

Exactly, this I'm afraid of. To install an ecosystem, like the Alexa ASK CLI, this notes very many references, like NPM, NODE, GIT, Python, etc. in place, and seem to prefer to re-build everything from sources as the proposed setup. I'm afraid that a portable version is not integrated that well, and causes other issues with the tools. Maybe this problem arises from Windows, which has not the basic build-tools available, while other "...nix" based OS have them on-board in every standard installation. I have to check further, what combination is probably best on Windows, with least impact. Maybe I try some tests in a snapshot of my Delphi VM, and check whats changed and going on, before I confirm it.

I use a structure like this, not only for variants, but also for Updates Packages\Rx1040\PrjVariant1 Packages\Rx1040\PrjVariant2 Packages\Rx1040\PrjVariant3 Packages\Rx1041\PrjVariant1 Packages\Rx1041\PrjVariant2 Packages\Rx1041\PrjVariant3 Src\ Src contains all common units. PrjVariantX contains only the different .dproj, .dpr in the best case, but may also contain certain bug-fixes to system units or other special units needed ONLY under that specific configuration.

Hi there, I'm sure most of you were aware of @Dave Nottage and his very helpful (live-saving) Kastri(Free) projects. Now with the presentation of the Memorizer, there are certain discussions about issues in the cross-platform world. Same as Dave I try to postpone permission requests to the bitter end, just before touching the hardware. For camera, sensors, etc. thats usually no issue. The problems may start when using local notifications, or related permissions, like Bluetooth and location. The local notifications permissions are fired right at startup, and thats annoying. You can imagine if you need a few permissions at startup, then they all will appear, and the user has to click them away before showing any useful screen. But for local notifications permission this might be maybe the right way too, because in mobile you also can run in foreground or background. So I would like to discuss the possibilities and pros and cons we have, for the permission settings from a users point-of-view. 1. Ask permission right after startup (as is now) - this is annoying to the user, especially if several requests appear one after the other - works in all cases, also for background mode, as it forces the user to decide - its a little like the old "Android way", permit all before use anything, but Androids style has changed meanwhile (for good reasons) - sometimes the app runs in background, and has no other chance to notify, than by local notification So the local notification permission shall be given at startup, to ensure this works. 2. Ask permission short before usage (in foreground) - thats what I like too, users shall decide each function before they use it. - but when moving to background w/o giving permission before, this might fail. A user cannot give permission while in background mode, the function simply fail or crash. 3. Ask permission short before going to background - this is not possible, because the app cannot do much when changing the states, especially no long-lasting alerts. 4. Allow permission in a special setup dialog - This is the "windows" setup philosophy, I think very much out of fashion in mobile: Force the user to visit setup first. - This will solve the issue in 2.), but I really try to to avoid this forcing of "setup" style design. Are there any other ideas or use-cases ? So far I think 1.) (as is) has its need too, and its not easy to cover all use-cases with one solution in mobile, there are too many options. Beside that, Android and iOS might have different philosophies as well, howto get them all under one umbrella ?

Thats what was proposed in some places, it seems to me that they want to prefer compilation over setup.

@Dave Nottage Hi Dave, thanks for your nice article about a major problem in the Apple environment. Yes, Apple always keeps us busy with such unnecessary work. Since I had fallen into such nasty boobie trap in some older version before, I changed my way howto deal with these updates. So I may provide another (pseudo)-solution to this topic: Solution 3: ( prerequisites before starting any update ) Use your XCode environment for development in a VM virtual machine, like VmWare Fusion Make a backup of your VM image, BEFORE any update of the VM (if you prefer snapshots, thats fine too, if you cleanup later, but I prefer to make complete, FULL clones of the whole VM) In the VM backup also the current SDK's are backed up of course, if you ever need them again later With these FULL clones you can switch fast and easy between older and newer XCode, SDK and PAServer setups That doesn't solve the basic problem, of course, but makes it much easier to handle different SDK environments, in case of any "crash" might happen wit the new version.

Not yet working , but I haven't tried again. Im working on a real Mac Machine right now, But Ive downloaded VMware 12 already, and will try soon. Sometimes such issues disappear suddenly, I hope...

Yes, right. type UIntPtr = NativeUInt;

Wouldn't be the NativeInteger the right cast for a pointer ? Matching the right bitness on 32- and 64-Bit machines, to the same pointer bitness ?

I'm afraid you had the ESP8862 in mind, as far as I know the ESP32 boards lay around 5$. But you never know what quality to expect from different suppliers ...

Hi there, I need to choose a basic type for caching and manipulating binary data, which is mostly represented as String, but could be also pure Byte data. The problem is that I need to analyse, chop, copy, append, re-combined to this buffer into several places, and finally the data will be string in most times. The original source is TBytes, so my first consideration is to keep TBytes as buffer data type. While the original data mostly contains ANSI strings, but in some cases maybe also contains binary (Byte) data, 0 ... 255. In short, the basic question is maybe: With original source data as TBytes - Keep TBytes for buffer manipulations, and convert in different places maybe later convert parts to string, or - Immediately convert all TBytes to e.g. String, and use string for manipulating data, even if maybe some of the data may be binary. TBytes: But from my gut feeling I would say that TBytes is probably not the most efficient data type for handling data, since its dynamic handling is not supported very well from the compiler. There needs to be done a lot of pointer tricks and memory move's to make that efficient. String: Strings on the other hand are very efficient and optimized, using all tricks like copy-on-write to make them fast and easy. I use them in many paces and they behave always very good and very efficient. But the drawback is that Strings are Char-based, which should double the memory footprint compared to Byte. What will be the right codepage for the encoding then ? RawByteString: The alternative RawByteString is not recommended, only as replacement for older AnsiStrings with codepage issues. So they have clearly another use-case: AnsiString: (without specific codepage) I could take AnsiString without codepage as base class, which would possibly reach the same efficieny as strings, but as AnsiString was deprecated and removed once from modern platforms, this leaves a bad taste. It seems that I came back only on massive complaints from the community. So my current decision tends more to use pure String as base class: type BufferType = String; var FBuffer : BufferType; ... //<== Single point of source data procedure SourceData( AData : TBytes ); begin FBuffer := EncodeAsASCII( AData ); // use no specific codepage, or DOS-like, to simply use Byte (0 ... 255) as elements ... // FBuffer copy, move, indexof, concat, ... //<== Further processing on FBuffer with effective string routines end; Is that the right decision, ignoring the doubled footprint in favor of speed ? So which option to choose from, A., B., C., or maybe I have overseen even another possible option ? I hope that you can help me with that decision.

I agree on the ugliness, but what if type extension is too hard to get ... What else is on the roadmap ?