Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 02/29/24 in Posts

  1. Stefan Glienke

    What new features would you like to see in Delphi 13?

    Niklaus Wirth just turned over in his grave about this proposal.
  2. Attila Kovacs

    What new features would you like to see in Delphi 13?

    it will also be enough if QP is operational by the time D13 arrives
  3. Anders Melander

    What new features would you like to see in Delphi 13?

    Nonsense. Windows developers have been able to create professionally looking applications that for decades without the aid of layout controls. The main reason for amateurish looking applications is amateurish developers. The DevExpress layout control is tightly coupled to the rest of their library but even if it had been possible to separate it from the rest then it would be a terrible idea. Embarcadero does not have the resources or expertise to maintain and evolve something as complex as TdxLayoutControl. Just look at the state of the 3rd party libraries they already have incorporated into Delphi. I wouldn't mind a rudimentary layout control as a part of the VCL but if they can't even get something as simple as TGridPanel to work properly then I think it's better they not even try.
  4. Thanks to Ethea S.r.l. who commissioned Luca Minuti to write a Delphi implementation of SAML protocols/libraries and make it available Open-Source to the entire Delphi community. The project has now been completed also for the 64-bit platform as well. The project is available on Git-Hub at this address: https://github.com/EtheaDev/Delphi-SAML
  5. David Heffernan

    What new features would you like to see in Delphi 13?

    Delphi produces native code, and therefore is fast
  6. This is nothing new - it's called Eytzinger Layout.
  7. HTML Library / SQL framework: 0.33s. Zero lines of code)
  8. Der schöne Günther

    Delphi and "Use only memory safe languages"

    For those interested, here is the very recent Secure by Design: Google's Perspective on Memory Safety (research.google) (March, 4th)
  9. Kas Ob.

    Delphi and "Use only memory safe languages"

    I mentioned or to be exact dreamed about more evolved Pascal enhancement, mentioned it here at once as i recall, but really can't remember any comments or any discussions. So will write it here as it is relevant for memory safety. My suggestion is to introduce new modifier(s) to managed (and non managed) variables, this include classes/objects, the new main modifier is "Auto", example procedure Test(aFileName: string); var SList: TStringList; auto; // the compiler will ensure calling the default constructor and destructor begin //SList := TStringList.Create; // should stop the compiler with specific Error, you are not allowed to create an auto SList.LoadFromFile(aFileName); //SList.Free // should stop the compiler with specific Error, you are not allowed to destreuct/free an auto end There is also similar modifier like "init/create" and "free" these will only their part and the compiler will ensure you can't abuse the memory layout or use after free. This also can be applied to fields in TObject/Class, the compiler will put the default constructor and destructor in their right position and will stop compiling when the code is trying to call constructor and destructor. But one could say using "auto" for the fields in classes will make initializing slower, no it will not as sooner or later it will initialized or used (except other usage, will follow down), will this cause degradation in performance?, no, not really, after all there is a price for pay. Another modifier which i can argue will be very helpful, is "delayed" or "onuse".., this one is for places when you don't know if that class will be needed or not, so the compiler will not auto create it !, but will initialize it to 0 (nil), and will check against that nil on every first usage with in the current scope then call the constructor in-place, guaranteeing its readiness, while will enforce calling the destructor in every scope it mentioned (referenced) but again if it is nil then nothing to do. With "delayed" modifier there is a performance hit for sure but it is merely "if assigned(x)" and as i mentioned above at the first usage in the current scope, so when in doubt i will leave to the compiler but when i am sure i will need that delayed to be ready for lets say a loop, then i can call specific function on it or just touch it in any code so the following code will not have to have the check for creation, of course if such delayed var is used in a loop then the compiler will put the constructor before entering the loop (at the loop limit preparing code) Also to mention how clean the code will become not just eliminating user after free or use non initialized. as for compiler: Delphi compiler is already equipped and has the ability to do that so minimal adjusting is needed, it does the same with all managed types (strings, arrays..) for the suggested modifiers above it will be close to this Currently the compiler does the same with strings and arrays as seen here ( though this is my XE8 so not sure about the latest versions) for combining the suggested "delayed" with the above the compiler could check for referencing one to another and adjust or rearrange the creation and destruction order. Anyway, this i this another short by me to reach a discussion about this enhancement or call it evolution, also this is the right evolution toward more memory safety. There is also can be a suggestion for different modifier "secure" "mute" (or something), with this one the compiler will allow any assigning to referencing (or double referencing), in other words and as example, X is a class, no code such Y := X is allowed, you need X (the object in X) you have to use it where is it which is X, This will ensure specific design and will limit pointer miss using, you want to load a bunch of the like of that X in an array then either declare them there with in the array and use them there, or, custom and precise steps should be done as guarantee to the compiler that this is well thought of, otherwise we need to write better code and design the structure better, another example ; X is secure object and it is a field in the non secure Z, the compiler will not allow to use X out side the scope of this current scope and/or outside the Z, meaning, the compiler will not allow passing X as parameter to a procedure, but will allow Z, X and its value is not allowed to be used in any direct assigning ":=", still we have the ability to introduce assign as operator that will ship or duplicate X fields, but not X itself or its pointer, that pointer should not be reached or allowed to be accessed by the compiler, and when i say compiler i mean the new language constraints for these suggestions.
  10. Stefan Glienke

    Delphi and "Use only memory safe languages"

    With the exception that ARC is one of the worst ways of doing that - here are some reasons.
  11. shineworld

    2 seperate installs of Indy in the one IDE?

    I'm used to using a different Indy version in some programs. I've left the official Indy of Delphi installation and I don't touch it. In a project I add a sources\Indyxx path with the desired Indy version source code. Usually this is a modified version of the current GitHub because I need to manage some base mechanism to adapt it to my embedded devices. In the program options I added this path to Search Path: Obviously I don't use IDE to place Indy components onto form but I've to create them programmatically. At now building exe Delphi uses .\sources\Indy10 version file instead of Delphi native Indy.
  12. David Heffernan

    Delphi and "Use only memory safe languages"

    That doesn't help if you have multiple variables that refer to the same instance which I guess is a more likely scenario for double free.
  13. Dave Nottage

    How to rearrange projects in projects group file?

    Select a project in Project Manager, use Ctrl-Up or Ctrl-Down to move it up/down the list
  14. DelphiUdIT

    TLS v1.3

    Update on the use of the TLS1_3 protocol in Indy (NOT OFFICIAL FROM Indy Team). This is an indication coming from the undersigned, who has carried out exactly what is described and verified that there are no problems either with the IDE or with the existing projects by recompiling and executing them. Conditions: - Rad Studio Athens 12.0 patch 1 (or Delphi); - Dowloaded Last GitHub repository Indy source: https://github.com/IndySockets/Indy/archive/refs/tags/Indy-10.6.3.zip - Donwloaded PR299 (aka NewOpenSSL_PR x OpenSSL 1.1.1): https://github.com/mezen/Indy/archive/refs/heads/NewOpenSSL_PR.zip Now you need to uninstall Indy from Rad Studio IDE, components and binaries included. YOU DO NOT NEED TO DELETE THE ORIGINAL INDY SOURCES. This is the official link explaining how update Indy: https://github.com/IndySockets/Indy/wiki/Updating-Indy ATTENTION: Do not use THE AUTOMATIC PROCEDURE in the instructions indicated in the previous link. It deletes files that do not belong to the Indy environment. You have to do what is indicated by hand, but when you get to the REMOVE THE FILES procedure, stop!!!! Instead, perform these steps: 1) Using Windows Explorer, go to the RAD STUDIO installation BIN directory (normally "C:\Program Files (x86)\Embarcadero\Studio\23.0\bin") and delete the following files: Then go to the BIN64 directory and delete the following files: Now you need to go to the LIB directory and list all the ID* files of the subdirectories (use the pane at the top right of the explorer to search). I recommend listing the files by NAME. The list includes a series of files (more than 10000) that will need to be deleted, BUT FROM THIS LIST YOU MUST UNSELECT (i.e. THE FILES SHOULD NOT BE DELETED) the following files: - all files starting with "FMX", should be 16; - all files starting with "Vcl", should be 8; - all files starting with "play", should be 4; - the "idoc.dcu" files should be 4; - the "idispids.dcu" files should be 4; The procedure indicated in the link (Update Indy) would have deleted these last 8 files. Now that you have deleted the files you will need to open the IDE. Errors will be generated: - package "dclemsedge290.bpl" could not be loaded, ignore and select not to reload again. - the "livepreview290.bpl" package, ignore and select not to reload again. Other packages may give errors, this depends on the fact that you have components registered in the IDE and that use Indy. You can ignore them and allow them to be reloaded the next time you restart the IDE. If you want to do a clean job, you should go to TOOL/OPTIONS/LANGUAGE/DELPHI/LIBRARY and from the "Browsing Path" item you will have to eliminate the Indy references (Core, System and Protocol) IN ALL PRESENT PLATFORMS. Now Indy is no longer present in Delphi. If you followed my initial instructions you should have downloaded the two zip files indicated. Unzip the first one (Indy-10.6.3.zip) into a directory. This directory will be the one containing Indy and will be used for all your applications. Now from the second ZIP file (NewOpenSSL_PR.zip) EXTRACT ONLY the OPENSSL directory found in "Indy/Lib/Protocols" and add it to the directory you created in the previous step, always under Lib/Protocols (so at the end there will be a directory plus, Lib/Protocols/OpenSSL). You will now have Indy with TLS1_3 enabled and with usable OpenSSL 1.1.1 (and also partially OpenSSL 3.1.x). Continue with the "Build and Install" paragraph of the link indicated initially. After finishing, you need to add two paths to Delphi's LIBRARY PATH to follow the ones you entered as in the instructions: "Lib\Protocols\OpenSSL" "Lib\Protocols\OpenSSL\Dynamic" You will now need to recompile (and reinstall) all of your IDE components that use Indy and your projects. For now the TLS1_3 can only be configured in code (therefore in RUNTIME), not in DesignTime as the IDE components have not been updated. All your projects however will remain perfectly functional and will use the old TLS1_2 standard and the old OPENSSL 1.0.2 DLLs until you modify the source to include the new standard. It's late and I'm going to eat now... UPDATE A note for those who use Indy to develop 64 bit or mixed 32 bit and 64 bit (even if you already know this): after having compiled and installed the Indy components (therefore 32 bit), delete the dcu files from the directories (where you unzipped Indy). You can safely delete ALL *.dcu files. If you leave them, when you go to compile your 64 bit project it will give you an error because the "dcu" are 32 bit. By deleting the dcu, you will force the recompilation (in your project) of the Indy libraries. Also remember that in the options of your project a valid path is indicated in the "Unit output directory", this will allow the compiler to generate all the dcu of the project within that directory.
  15. Der schöne Günther

    Delphi 12 : Encoding Unicode strange behaviour

    Your life will be much easier if you rely on Strings and Chars for text manipulation, not bytes. Convert to bytes when your text manipulation is done, not before that.
  16. DelphiUdIT

    What's the general opinion on v12?

    Apart from the fact that we are in the section: nothing else.
  17. Darian Miller

    What's the general opinion on v12?

    Check out the What's New page: https://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New But RAD Studio 12 does have some rough edges. See my wiki page for a few regressions: https://github.com/ideasawakened/DelphiKB/wiki/D29.ATHENS.12.0.0.0 Patch 1 (https://github.com/ideasawakened/DelphiKB/wiki/D29.ATHENS.12.0.0.1) fixes some of those, but some important ones remain. Update 1 was released 6 months after RS 11. So playing a guessing game...since RS 12 was released in early November, April might be a good guestimate for RS 12 Update 1 where most of the rough edges should be worked out.
  18. This will only change the TField array item, but not the local variable FieldX as expected. A const or var array of TField is no replacement for a couple of var par: TField parameters. As soon as you construct that array parameter, the addresses of the local variables are gone, while their current content (which may be undefined here) is copied to the array item. Perhaps this may be a better approach (didn't try as I am too lazy to create a fake dataset with these fields): procedure ConnectFields(Query: TDataSet; const Fields: TArray<^TField>; const Names: TArray<string>); begin Assert(Length(Fields) = Length(Names), 'Number of fields and number of names must match'); for var ix := 0 to Length(Fields) - 1 do begin Fields[ix]^ := Query.FindField(Names[ix]); if not Assigned(Fields[ix]^) then raise Exception.Create(Format('Field %s not found.', [Names[ix]])); end; end; procedure Test; var Field1, Field2, Field3, Field4: TField; begin ConnectFields(Query, [ @Field1, @Field2, @Field3, @Field4], ['Field1', 'Field2', 'Field3', 'Field4']); ... end;
  19. David Heffernan

    Delphi and "Use only memory safe languages"

    No it's not. Not really the point if a government agency will only accept work using tools that meet certain criterion. You can either follow the specification and have a chance of getting the work. Or argue about the specification and be completely ignored. That's just reality.
  20. Vincent Parrett

    Do I really need a certificate?

    Yeah the filezilla download page is a bit disengeneous with that download button, it does however say (much smaller than the button) "This installer may include bundled offers. Check below for more options." which leads to this page https://filezilla-project.org/download.php?show_all=1 where you can download an installer that doesn't trigger windows defender or malwarebytes
  21. Ian Branch

    What new features would you like to see in Delphi 13?

    Case on Strings. i.e. case myStringVariable of 'A': do something; 'Test': do something; etc end;
  22. Fred Ahrens

    What new features would you like to see in Delphi 13?

    I don't need any new features. I just need that the existing features work as intended. And there are many areas where existing features need to be made usable again (e.g. refactoring, code formatting, HighDPI). OK, one new feature would be nice: compiling for Raspberry Pi. But fixing the existing features needs to be done first.
  23. Dalija Prasnikar

    Delphi and "Use only memory safe languages"

    I hate to be the one saying this... but ARC compiler was a step in that direction. You cannot have memory safety without automatic memory management.
  24. Angus Robertson

    ICS V9.1 Highlights

    ICS V9.1 is almost ready for release. Although there are no new components, there are many other SSL/TLS changes that will affect existing applications, but make ICS easier to use and support for the future. Before the final release in a week or two, I'd appreciate some feedback from user installing V9.1 using the new packages, and update one or more old SSL/TLS applications, it may help future users if I can improve the documentation. Please read readme9.txt and these note about V9.1 carefully when upgrading existing applications, you may get build errors that need minor code changes. But new applications should need be easier to create. 1 - Delphi 10.4 and later now use the same install groups and packages, IcsInstallFmx, IcsInstallVcl and IcsInstallVclFmx, making support a lot easier. Version specific groups remain for Delphi 10.3 and earlier, with new groups D(X)InstallVcl for VCL only replacing the old OverbyteIcs(X) groups, again to simplify support. 2 - The old samples directory has gone and many of the older and little used samples have been archived to a separate download. The active samples used to test and demonstrate all ICS components are now split into the following paths, in the ICS root directory: demos-delphi-vcl - 45 VCL samples for Windows. demos-delphi-extra - four VCL samples that need third party components to build. demos-delphi-fmx - seven FMX samples for Windows, not yet tested on MacOS. demos-cpp-vcl - all old C++ samples that have not been tested for 10 years, need help. demos-data - data files for samples, such as web pages. All these samples can now be built for Win32 and Win64 platforms. 3 - To ease development, linking and future support, some new units have been added by splitting existing units with multiple components, unfortunately this means many existing projects will need one or more of the new units adding to their uses section. Apologies for the pain, but this should have been done a long time ago. The main change is splitting out much of the SSL/TLS related code from the massive OverbyteIcsWSocket unit to a new unit OverbyteIcsSslBase. 4 - Distribution of the ICS OpenSSL files has changed. Earlier ICS versions required the OpenSSL DLLs to be distributed with applications, and a root CA bundle file to verify SSL/TLS connections, and these needed to be loaded using code. There was little standardisation over where the OpenSSL DLLs were located, applications tended to keep their own copies alongside other executables, leading to multiple DLL copies and needing the public variable GSSL_DLL_DIR set to a specific directory before OpenSSL was loaded. Likewise, root CA bundle directories had to be distributed with applications and loaded with code. ICS V9.1 allows five different ways of loading OpenSSL: 1 - DLLs linked into application as resource files 2 - DLLs loaded from common directory C:\ProgramData\ICS-OpenSSL\ 3 - OpenSSL DCU linked into application using commercial YuOpenSSL 4 - DLLs loaded from location specified in public variable GSSL_DLL_DIR 5 - DLLs loaded according to path, may be found anywhere on PC Which method ICS uses to load OpenSSL depends upon several defines in the .\Source\Include\OverbyteIcsDefs.inc file, please see the readme9.txt file for details. ICS currently includes resource files for three different OpenSSL releases, 3.0`13. 3.1.5 and 3.2.1, which version is linked is controlled by a define. If the OpenSSL DLLs are linked into the application, they are extracted to a version subdirectory, ie C:\ProgramData\ICS-OpenSSL\3012\ so different applications can use different OpenSSL versions. This happens only once if the files have not already been extracted. When updating existing projects without using any new defines, the ICS old behaviour of methods 3, 4 and 5 above remain with no changes needed. 5 - A common IcsSslRootCAStore component is now created at application start-up, to avoid different components needing their own CA stores to verify SSL/TLS certificates, and for applications to load those stores. The three different CA stores included with ICS are now supplied as resource files, with a define determining which is linked into applications. Another define causes OpenSSL and this store to be loaded at application startup, so OpenSSL is available for all components, without it needing to be loaded again, perhaps repeatedly. Without new defines, a CA Store can be loaded manually into IcsSslRootCAStore. The ICS servers use CA Stores now use IcsSslRootCAStore and no longer load any files specified. 6 - All SSL/TLS servers need a certificate and private key to start, even when testing. Previously ICS supplied some self signed certificates for testing, and also created such certificates automatically if they were missing or if the server was about to order a Let's Encrypt certificate. Accessing such servers for testing using browsers raised various warnings. ICS now has it's own SSL root certificate 'ICS Root CA' and two intermediates, 'ICS Intermediate' and 'ICS Intermediate Short', the last of which includes a private key so can be used to automatically sign new certificates by ICS server applications, rather than just self signed certificates as before. If the 'ICS Root CA' certificate is installed in the Window Store and browser stores, it should stop certificate warnings appearing. ICS applications automatically trust the ICS root, so will give no warnings. The short intermediate has a maximum 100 day expiry, so new versions will be issued regularly. There is a single function CreateSelfSignCertEx that created signed certificates, and another IcsInstallIcsRoot that installs the ICS root into the Windows Store, so easy to use. It is possible to replace the ICS root with your own private root certificate and have servers create their own certificates against that root, for internal networks. 7 - The TSslHttpRest component now allows TRestParams to be created as content type 'Form-Data Body' to create MIME multipart/form-data parameters that may include new TParamType of RPTypeFile that specifies a file name whose binary content will be added to the parameters as a file upload, allowing multiple files and extra parameters. TRestParams are now built into a TStream rather than a string to allow larger parameter sizes, tested up to 8GB. The ICS web server samples have improved MIME decoding to accept massive uploads. 8 - Several client and server components have a new property NoSSL which if set will prevent those components using SSL/TLS for HTTPS or FTPS, even if the application is linked with OpenSSL code. Beware the IcsSslRootCAStore component must not be initialised by the application. 9 - Updating projects to V9.1: Applications that have TSslContext on a form will need to be opened so the new unit OverbyteIcsSslBase is automatically added to the users clause. Units that reference TX509Base or TX509List mostly for the OnSslHandshakeDone event, may need OverbyteIcsSslBase adding manually if they don't also have TSslContext. The other new units are OverbyteIcsHtmlUtils (for TextToHtmlText, IcsHtmlValuesToUnicode, IcsFindHtmlCharset, IcsFindHtmlCodepage, IcsContentCodepage and IcsHtmlToStr), OverbyteIcsDnsHttps (for TDnsQueryHttp and IcsDomNameCacheHttps) and OverbyteIcsSslUtils (for TOcspHttp). Applications that use IcsExtractURLEncodedValue, ExtractURLEncodedParamList or GetCookieValue may need OverbyteIcsUrl adding to projects. When updating projects using a TSslContext component, setting the new property UseSharedCAStore to True causes the properties CAFile, CALines and CAPath to be ignored, and the new IcsSslRootCAStore component will be used instead, being automatically initialised if not done at program start-up. Don't use UseSharedCAStore for server components. High level ICS components such as TSslHttpRest that have an internal TSslContext component all set UseSharedCAStore and ignore properties like SslRootFile to load a root CA bundle. If a specific bundle is required, it may be loaded to IcsSslRootCAStore. With V9,1, the global variables GSSLEAY_DLL_IgnoreNew and GSSLEAY_DLL_IgnoreOld are ignored since only different minor versions of OpenSSL 3 are supported. V9.1 can be downloaded from SVN at https://svn.overbyte.be/svn/icsv9/ or the overnight zip at https://wiki.overbyte.eu/wiki/index.php/ICS_Download Angus
  25. Dalija Prasnikar

    Delphi and "Use only memory safe languages"

    Delphi is not memory safe language. But, at the end it all depends on the kind of code you write.
×