DelphiUdIT

Here some posts about that (read ALL). The referring page is: https://github.com/IndySockets/Indy/wiki/Updating-Indy Take care: by now, the Indy github version is not full compatible with Embarcadero distribution. I should change some things inside (in the posts are indicated, but still confusing ... sorry for that). One for all: don't use the automatic procedure !!!😞 After the changes of Indy "clear cmd" about some files that should not be deleted, in my system they are deleted instead ... use manual mode like I indicated in my posts. Unfortunately I am not familiar with github and so making a replica of the Indy repository with the necessary corrections is difficult for me. Furthermore it is necessary to copy and compile some sources provided by Embarcadero, which obviously I am not authorized to distribute and I can only indicate how to proceed. Some of these fixes are correctly rejected by the Indy team because they are only planned for the next release (11), and so those are not in the Github repo. Bye P.S.: with those actions you'll have the ability use of TLS1_3 and the OpenSSL library 3.1.4 (I use those) and OAuth2 (not tested by me). I'll try to create a repo and put all things inside with a readme.

Hallo, i tried to update the standard distribution of Indy with the github version (ssl-oauth + PR), like for 12.0 version and all is working, also for LivePreview for FMX. The only exception is the package "Embarcadero RAD Server Edge Components" that which causes an AV closing the RAD STUDIO. By disabling this package (which I don't use) the problem does not arise. I recompile a bunch of working project with Indy and all is OK

I don't develop this kind of analysis for mobile and I don't know if there are math libraries that do that on those devices, but for example on IOS you have this function: https://developer.apple.com/documentation/coreimage/cirectanglefeature But I really don't know if it's exposed on FMX. For Android I don't know ....

@shineworld use the last link ...

Try to use PasLibVlc ... can play whatever you want and it's fast (you should have installed VLC). You have the full control on the stream media. https://prog.olsztyn.pl/paslibvlc/

Like exe, the DLL have a field in the IMAGE_OPTIONAL_HEADER64 - DllCharacteristics that enable or not the ASLR. In effect lot of DLLs are not ALSR compatible (especially the old ones). And they should works whenever ASLR is ON or OFF. https://learn.microsoft.com/it-it/windows/win32/api/winnt/ns-winnt-image_optional_header64 Security things a part of course. Some my customer more then 10 years ago explicity want the ASLR flags On and DEP too in my applications. And that works because some libraries that the customer forced me to use were not ALSR compatible (and neither was the application obviously ). Some years ago also ASLR HE was imposed, and all worked well. For this I asked the full compatibility of ASLR (HE) of C++ DLL.

I don't have links, the discussion was in one webinar where I post some questions about C++, one of them was about ASLR, since they introduce set on by default (I used them before that with the PEFLAG settings). And the answer was the they are not sure about use the ASLR with Delphi and a C++ DLL. I used them before, I used them now and I had only a little problem with third part library (ASLR HE cause AV). Of course, like @David Heffernan said these is only meaning that the code is not write in the correct way ... but if those is about the C++ base environment, you cannot do nothing about, only try to "stem" the problem. I don't want to create alarms. only report what it's said about that. But for sure if ASLR create problems, some parts of the code are bad written. Another point is that Windows does not impose (force) the use of ASLR by default and that the same ASLR exclusion options are present in the Delphi project. This means that it is absolutely known that incompatibilities with ASLR exist (perhaps with legacy software) and that the exclusion of this option, even if it is a last resort, is possible.

http://docwiki.embarcadero.com/RADStudio/Athens/en/64-bit_Windows_Data_Types_Compared_to_32-bit_Windows_Data_Types

I agree with you on what you say, the pointer problem is indeed a problem, and obviously needs to be solved. But the incompatibility with 64-level DLLs and ASLR is well known: at one of the webinars, following a direct question of mine on this very topic (we were talking about DLLs with C++ and Delphi), it was confirmed that full compatibility between 64-level DLLs and ASLR could not be guaranteed when developed with C++ (Embarcadero). We talked about this a few months ago. Whether the problem is with the C++ libraries (perhaps some still 32-bit pointers?) or something else has never been clarified. However, I correctly use 64-bit DLLs developed in C++ Embarcadero with ASLR and ASLR HE without any problems.

I think the problem is the project options: in the new 11.3 (like 12) environment the additional setting about ASLR are ON, try to deselect them.

@pcoder, @Stefan Glienke I think he wants to try a general function, also for others rounding modes (he inserts other masks to the function). But you are right, there are also other native CPU instructions that do that specif works (like that you exposed).

But use the "grep" tool on command line to check where the unit are related, in all files (in all disk if necessary 😉) ?

But is not forbidden:

If you must use NEW (so create a new variable), why don't declare it like a normal variable or a typed pointer? If you refer a record variable you don't need to allocate memory. If you need to reference a pointer, this normally means that it's already assigned and you can cast without NEW or DISPOSE. Another suggestion: in Delphi you don't need to "defererence" a typed pointer, the compiler do it for you: var LPointer : Pointer; begin New(PMyRec(LPointer)); PMyRec(LPointer).Int := 200; PMyRec(LPointer).Str := 'Blah'; Dispose(PMyRec(LPointer)); end; var LPointer : PMyRec; begin New(LPointer); LPointer.Int := 200; LPointer.Str := 'Blah'; Dispose(LPointer); end;

I don't understand what is bad here. "FloattoJson" means transform a float value in Json reppesentation ... and this means that should be ".x" in the case that there are not "." or "E" symbol. This is true and not questionable, but the real meaning to know if that Json format is a "standard" float or a currency is in this phrase: So, I can write this values: (1) <- May be a integer, but you can read it like "base 10", binary, hex, octal .... (1E0) <- May be a integer, but also a float (and I saw the scientific notation generally is taken like a float) and yes it's "base 10" (1.0) <- It's a float "base 10" or currency ? (1.00) <- It's float "base 10" or currency ? But all this representations are subjective to Json ....

Most often this happens if you use third-party components. Try uninstalling add-ons (such as those installed by GETIT) one at a time to find which one might be generating the AV (assuming it depends on the added components).

May the be graph attached in that post ? https://en.delphipraxis.net/topic/10229-unit-dependency-viwer/?do=findComment&comment=81286

It wasn't for you my reply. You are from TeamB and an MVP Embarcadero, I have nothing to explain, signaling some issue may be but sure not explain to you. The post was for @Adam and for other readers.

UseLatestCommonDialogs: Boolean = True; MsgDlgIcons: array[TMsgDlgType] of TMsgDlgIcon = (TMsgDlgIcon.mdiWarning, TMsgDlgIcon.mdiError, TMsgDlgIcon.mdiNone, TMsgDlgIcon.mdiNone, TMsgDlgIcon.mdiNone); This is how they delete the standard dialogs (MessageBox) icons, except for Warning and Error.

To be more "simple: 1) You can refer in the "requires" section simple with IndyProtocols for example, but the library (bpl) used will be with "290" ... or the new extension for Delphi 11 or Delphi 13 ....; 2) So in every component will you refer in the future you'll refer ALWAYS to with "IndyProtocols" and depending of IDE version will linked to the correct BPL version (280, 290, 300, ....); This require the changes the name of the DPK/DPROJ files, the changes of the "requires" sections and the use of $LIBSUFFIX = AUTO (in the DPK and in the DPROJ files). In the past that was done using LIBSUFFIX (for example) with "290" instead of AUTO. The libraries in RAD STUDIO are related without suffix "290" but the BPL still have those suffix (for example you refer to RTL in the DPK files not RTL290). "NEW" WAY "OLD" WAY Bye

I would said that there are some tickets "open" and others "closed" about that.

There are a lot of github repo to OpenCV for Delphi, this is another one: https://github.com/gidesa/ocvWrapper46

This is right if you want maintain the full compatibility with Embarcadero and all third parts packages. But this is not all, you must set also the $LIBSUFFIX to "AUTO", because the BPL packages should be named with "290" version. Indy packages in the repo are not set for this, there are some "ticket" open (and "closed") about this. I wrote some posts about substitute the original Indy and restore the compatibility with Embarcadero environment, but after last changes in Indy repository I will rewrite again a full post with all steps in simply mode including openssl indy repo and ssl-oauth indy repo, possibly via script.

I compiled the new Indy package (https://github.com/IndySockets/Indy/tree/sasl-oauth) in Android platform too with success. Three issues found: 1) In the IDHL7.PAS, after the implementation section two uses files do not exists. Comment out there will be no apparent issue. In the Embarcadero release IDHL7.PAS is not present. 2) In the IdCompilerDefines.inc there is a $DEFINE (HAS_getifaddrs): I had undefined that since one records that will be used if that define is in use in Android platform is never delclared. 3) One settings on Embarcadero Rad Studio path is wrong, should be Android not OSX - this is for both Android 32 and Android 64: After those modifies, I was able to compile the Indy for Android. I try also an old Android project with IdSMTP protocol (with SSL) without any issue.

I used the last update branch (SASL-OAuth) yesterday night.