Leaderboard

obj := TObject.Create; FreeAndNil(obj); FreeAndNil(obj); ------------------------------ On SO somebody wrote an example like this to prove how unsafe Delphi is: s: String; i: Integer; begin s:= 'four'; for i:= 1 to 1138 do begin write( s[i] ); // What will it access after i=4? end; end; At one point, we should stop talking about how safe the programming language is and start talking about how "unsafe" is the programmer 🙂 🙂

Nice post David S! I had recently to fix a bug in a program that was sending wrong financial reports to a governmental financial institution (equivalent to RSI in America) for 18 years. After 18 years, somebody observed the problem. It ended up that there was not only one bug, like 15. Nobody ever observed the other 14 instances where data was wrong. I was told to shut up and move on. Also, nobody cared that my new program was running 100x faster than the previous one. I told them that probably there were another 100 bugs in there (pascal-like code, no objects, thousands of warnings and hints - at least, there were no pointers!). They wouldn't let me rewrite the program. They said, it now it works, let it as it is. So people, don't blame Delphi for not being totally memory-safe. It is mostly the programmer that dictates the safety of a language. I guess the programmer that wrote that program in Delphi would be able to sneak in some calamities like this also in a language like Rust. __________ Also, many people complained about buffer overflow here. Turn on the damn Range and Overflow checking. It will catch a good bunch of those overflows - unless the devil thought you to use pointers all over the place.

Whatever you program in Delphi, compared with most other languages, it will stay RAD and you can focus on you actual problem instead for example fighting how to put things on the screen. It takes the Online department, with Node, Javascript and pumping JSON files through the internet, with three developers (backend, frontend and HTML/CSS designer) about one week for one screen. They calling Delphi old fashioned while I look to their source and problems as if they still live in the 1980's.

Don't get hooked up on just books. There is a lot of useful visual material on the Net that is targeted at Delphi beginners. Embarcadero's Helpful Resources for New Users has some good links to both books and visual resources.

Creating at run-time is pretty straightforward. You need Owner and Parent, and sometimes setting Align property. You can use any FMX control as those - or at least I have been able to use them without a problem. FFrame := TMyFrameClass.Create(AParent); FFrame.Parent := AParent; FFrame.Align := ... And that is it.

Microsoft has been "increasing the pressure" on non-WinTel32 development for a decade. I remember thinking Embarcadero needed to hurry up and give me an option to target Windows Phone. Then to get serious about WinRT for Windows 8. Etc. Windows on ARM may indeed eventually matter, but I can hardly fault Embarcadero for taking a "wait and see" approach to the latest-and-greatest non-Win32 "pressure increase" from Microsoft.

During the Paint method you have to handle csPaintCopy in ControlState (you can check in Vcl.DBCtrls).

The sources must register to the collector. And unregister when the source does not need the collector anymore. The collector must not be destroyed if there is an active source. This is a little like ARC for interfaces work.

I don't really understand this. I always write the try/finally immediately after the construction, and always bang the Free in immediately. Then I fill out the body. It's just a habit that you form so that you don't make such mistakes. And honestly, this is never one that is hard to debug because you just have a leak. And presumably you use leak detection tools so that you'd always find them immediately. I don't really understand this scenario either. If you have a reference to something that may or may not exist, you would test Assigned() before using it. And when you were finished, you'd set the reference back to nil once you'd destroyed it. The scenario that is tricky is when you have multiple references to an object.

I have it and many of the techniques in it that were great 10-15 years ago are totally unnecessary today and even detrimental with modern CPUs. It's still a good read and even though some techniques are obsolete, knowing them can help solving other similar problems simply because they can make you think about problems differently. Um... Always? There used to be a time, not that long ago, when integer math was far superior to floating point math (see: Hackers Delight). Not so anymore. via https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware The video is a bit long so I haven't watched it yet, but it's LEA: Load Effective Address, "LEAL" is AT&T syntax for LEA (Intel syntax). Here's a good comment on the topic by Peter Cordes: Using LEA on values that aren't addresses / pointers? Before you start replacing all your shifts with LEA you should be aware that it isn't always faster. As with almost everything in modern CPUs it depends on what the CPU is otherwise busy with. https://stackoverflow.com/questions/70316686/assembly-why-is-lea-eax-eax-eaxconst-shl-eax-eax-const-combined-fast

The Zeos Team is proud to announce the availability of Zeos 8.0.0 as a stable release. This is the newest stable version of Zeos. It deprecates Zeos 7.2, and any previous version of Zeos. We urge all people still using older versions of Zeos to upgrade. If you have any problems with Zeos 8.0, please get in contact with us on the forums or on the bugtracker. The most outstanding changes in Zeos 8.0 are Support for Delphi NextGen compilers to support Android, iOS and Mac OS X Two new bridge drivers for OleDB and ODBC A new driver that uses the Firebird interface based API for accessing Firebird versions 2.5 and above A special proxy server and an according driver that can be used to access any Zeos supported database using SOAP over HTTP(S) from (mobile) clients. Propper support for numeic and decimal fields by using TBCDField and TFMTBCDField Nested transactions using savepoints Two new components: TZTransaction and TZMemTable better overall performance and smaller memory footprint Besides these improvements Zeos has seen a ton of other additions and improvements. For an overview of the changes in Zeos 8.0 see the release notes. To download, the new version of Zeos please use this link.

Hello, everybuddy. Recently I made a plug-in for Delphi to use ChatGPT inside the IDE. The main service is ChatGPT but it's actually multi-AI support, you can get responses from three different sources, compare and decide. I hope this can be helpful and accelerate your work. Repository: https://github.com/AliDehbansiahkarbon/ChatGPTWizard Key features: - Free text question form. - Dockable question form. - Inline questions(in the editor). - Context menu options to help you to find bugs, write tests, optimize code, add comments, etc... - Class view. - Predefined Questions for class view. - History to save your tokens on OpenAI ! - Fuzzy string match searches in the history. - Animated letters(Like the website). - Proxy server options. - Supports Writesonic AI (https://writesonic.com) - Support YouChat (https://you.com) Short Video 1: Short Video 2 - Inline Questions: Full Video (ver. 2.0):

That is not correct. Technically, the path component is allowed to be empty in any url, per RFC 3986 sections 3 and 3.3: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> RFC 2616 section 3.2.2 tried to restrict an HTTP url to require a non-empty absolute path if the query component is present: http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] But, RFC 2616 section 5.1.2 does allow the path in an HTTP url to be empty: RFC 7230 sections 2.7.1 and 2.7.2 loosen the restriction to allow the path in HTTP and HTTPS urls to be empty: http-URI = "http:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] https-URI = "https:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] Why would you an inefficient "Pos" check instead of using something like StartsText() instead? Or simply: "if (FPath = '') or (FPath[1] <> '/')" ?

My workmachine is not quite JRE free, due to IBM ACE. But in general, I don't install Java apps if I can avoid it.

However, it might not be permitted to do so in corporate environments.

Fair and with in your right, but let me ask you a simple question When you last time saw Delphi/Pascal code where a function had one letter name like f or g ?... Yesterday i watched this I believe i pasted the link as Stefan put it in the German forum The talk is great and very valuable, and if anyone is not familiar with lecture then know that this dude wrote C++ specification for breakfast, and here it comes write the guide lines for safety, yet when i watched it i saw that he himself with his examples violate a rule that always use expressive naming, and yes there was f and g, this comes from math, and the obsession of C++ developer with math to look cool, everyone looks to Bjarne and his talks and books, yet the beginners will scratch these examples in their brains forever with one letter function as name. Look at this "New Rules" titled in 2020 https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c-core-check/ I think every C and C++ compiler out there does warn about default for a switch, yet that blog post deemed it a must to remind everyone with it, in Rust the code will not compile and C and C++ and in %90 no one will see it because there 458648567 another warning, some of these warnings makes sense but most of them don't, C and C++ are cursed with arrogance and stubbornness and its culture is beyond control, (my opinion) Rollo62 all what i am saying is even with all of this power of C++, it fails be the best language for long term security and safety, they (the most invested companies and teams and i trust they have better insight and view on this subject ) said C/C++ will not cut it and Rust it is. they decided to burn the tower and throw the power tools for better language, that (again) doesn't bring any thing new, on the contrary only remove the ability to use many C++ features, and evidently they see it as success story.

Its not that only. See, we the Delphi programmers used to do things in specific way, this out of the structure of the language of Pascal and by tradition or best practices, it goes like (as example ) automatically without thinking to put try..finally then call free, C++ there is none like this, but i am not saying C++ is incapable of, on contrary it can do more things because it is more powerful, but C++ developers doesn't have the discipline of Pascal's, this is exactly why all these big companies with their top tier developer keep doing or falling with the same traps again and again. When these big companies suggest to switch to different language like Rust not out of powerful of Rust or the lack of the tools in C++, on the contrary they reached to a conclusion that too much power is simply harmful, more limited tools are better fit and more secure. When you say Delphi is not memory safe, yes it is, just like any other language, yet the guide lines for Pascal and Delphi are way simpler and clearer than C++ to produce memory safe code (either bugs or vulnerability) , Rust is similar, its guide lines are harder to break as they incorporated within the language syntax itself. In Delphi if you leave the Overflow Check at on all the time, then you really had to be making big mistakes to breach memory safety for something like accessing index memory or handling managed types, these managed types specially arrays and strings are managed by the compiler in very nice way, in C++ there is hundreds of implementation of such arrays and strings, and they all will depends on some implementation, yet while they are completely safe at the same type coming form the same library, they are useless when it comes to interact with different library or the OS or whatever and here comes the problems of casting and unsafe converting.

I do, and I suspect many others do as well. What I was mostly disappointed about was the statement below. The company promoted in that link and the accompanying webinar was DerScanner. I watched the webinar last September and it intrigued me enough to ask approval to pursue having a small project analyzed and review the results. Their home page had a short form to request a trial. Instead of providing a trial, I received an email that I will share, since it is typical marketing: I responded that I requested a trial from their home page. The reply was that my request for a trial was forwarded and included a whitepaper that "describes the key features of DerScanner". One of the key features was that DerScanner could analyze 36 programming languages, "even obsolete Delphi, COBOL and Visual Basic 6.0". I also noticed that the short form on their home page was changed from a trial request to "Get a Demo". They did provide a trial account and I submitted the project along with a couple third-party libraries (with each vendor's permission). The resulting report contained thousands of incorrect analysis. One of the more prominent and obnoxious was “hardcoded encryption key”, for code such as "ctrlKey := GetKeyState(VK_Control) < 0", and every other line of code that contained these three characters in sequence: k e y, including static text. The analysis that DerScanner provided was a complete joke and a total waste of time. The trial included two scans for free (I only used one), additional scans after the trial were $1,000 per scan. Sure, my employer can say "Yes, we are concerned about security. We had our application analyzed by a third-party that specializes in code analysis. They used a highly sophisticated tool named grep to analyze our code for vulnerabilities." I am particularly disappointed in the recent statement because I had direct contact with Ian regarding my frustrating experience, and the laugh that I had after reviewing the generated report.

Oh how true.....

Sorry, y'all are obviously not reading my mind correctly. I was not referring to simple Pointer Aliases. TL;DR -- Pointer aliases are inconsequential. Pointer math is extremely hazardous. In my experience, companies couldn't care less about making code run faster ... not a "little bit" (minutes saved) nor a "huge amount" (hours saved). Nothing justifies using pointer math in Delphi apps to make apps run faster due to the likelihood of errors that the compilar nor test suites can catch. Desktop apps are far different from real-time process control apps, or even the libraries used in them; NOBODY cares about making them run "a little faster" that a newer faster computer won't fix I was referring to constructs like this (and I may not have even used them properly): ---------------------------------------------------------- var pXyz : pointer; <---- var xyz: integer; pXyz := ^xyz; <---- var i : integer; var myIntAry : array [0..maxVal] of Integer; for i := Min(myIntAry) to Max(myIntAry) do begin // this is an example of what I was referring to that's used frequently in C and C++ ^pXyz := Random(1000); inc(pXyz); end; ---------------------------------------------------------- ((sorry, the insert Code thing isn't working)) Yes, I realize Pointer aliases are used a lot in the VCL source code, but most of that was written in the 1990's and probably hasn't been updated much since then. ("If it ain't broken, don't fix it.") I also realize that Delphi class vars (eg, myClass : TMyClass) are basically pointers treated as references (like C++: TMyClass : &myClass = new(TMyClass); ) The pointers of concern (that use the ^ operator the same way C/C++ uses the * operator) are also the code used any time you have a Record that's allocated from the heap. The thing is, some people still obsess over a few extra instructions that the compiler might generate that can be eliminated using pointers, but I suspect most of them are "old school" programmers from way back in the day when every CPU cycle and byte of memory that could be saved were significant. When programs were 50k, they could be copied to a 128k floppy for distribution, and nobody ever imagined a computer would need more than a few MB of RAM. I was taught that way, but shook off that habit in the 90's. Today, desktop computers ship with 8 GB or more of RAM. (My first HDD was a whopping 10 MB!) The CPUs are multi-core and have hyper-threading, and if you try to out-guess the compiler's optimizer, the code is more likely than not to run slower due to all of the NOPs injected into the instruction cache. All of that hand optimization is likely to work on only ONE CPU (or CPU family) and will need to be revised for every difference in number of cores, instruction cache size, and maybe even data cache size. I know there are always "exceptions". MOST people creating form-based desktop apps that interact with a back-end database using Delphi are NOT writing code like that! They _might_ declare a pointer alias here and there, but they certainly aren't writing code that anybody will notice if it runs 100ms faster. At my last job, I was told to "port' something that was written for use by one specific client. It ran once a day and took a bunch of daily invoices scanned into PDF files at a dozen or so sales offices, with hundreds of pages saved into each PDF. It ran some OCR on each page and attempted to read an Invoice# from each one and then put the pages for each invoice into a separate PDF so the customer could view the pages for each invoice online if they wanted to, with all of the pages for that invoice in a single PDF file. It used a Version 1.0 DLL from an OCR app from 1997 that ran under WIndows 98 when it was released. This was 2018 and the code didn't run properly under Win10. For years, this thing ran in an hour or so. When I got hold of it, it took 8 hours to process a thousand or so invoices daily. I also discovered that it was unable to process about 30% of the invoices it was given and simply skipped over them. I completely rewrote it using a much newer OCR library written in Delphi, and my version ran in about 45 minutes for the same data that took the older one >6 hours. NOT ONE PERSON CARED THAT IT RAN SO MUCH FASTER! NOT EVEN THE CLIENT! In fact, my boss made a note on my annual review that this task took me 2 months to complete while they believed should have taken a week or two. (Never mind that their analysis was totally off-base.) The client rep contacted our support wondering why there were suddenly so many more invoices showing up every day in the process summary. I told our internal support person it was because the old code was not processing about 1/3 of them. When she told the client, they said, "Oh, ok. That's good to know." That was it. In use for over 15 years, they never noticed anything was wrong. This is hardly an isolated experience I've had over the past 25 years writing and maintaining Delphi desktop apps for clients. Nobody really cares about even significant performance issues, and most don't notice small problems. Very few ever audit their data, either. I worked at one place and discovered that medical invoices were being printed out and some separator pages were missing, and so customers were being mailed health records for other people accidentally stuffed into their envelopes, and nobody at our company that did the printing and mailing, nor the client company, ever knew! This should have been treated as a MAJOR HIPAA violation, but I was told to keep my mouth shut and just fix the problem. You guys outside of America might be wondering how this happens, but from my experience, it's quite common. Every job and contract I've had, I've found at least one and sometimes dozens if not hundreds of things that had been operating improperly for years. Some were performance-related, but most were just data integrity problems. Management mostly did not want to hear about it. So I really don't want to hear about all of the exceptions and reasons why it's important to shave 50 ms off of the execution time of some loop you may be working on. The last place I worked printed bills and invoices, stuffed them into envelopes, and sent them out to the US Post Office -- 7 or 8 full 40' semi-trailers EVERY DAY, 7 days a week. They got pissed off if part of a line on an invoice was cut off on a print run of 50,000 invoices; not whether it took an extra 15 minutes to run a given print job, as long as the people who got the materials could read them and they looked "professional". If customers didn't complain, that meant nothing was wrong. Nobody cared what we programmers might find. One thing I've found over the past 15 years is that Management is far more scared of allowing programmers to refactor code than just about anything else. Because trying to shave a few seconds of processing time often leads to bugs that did not exist previously. And yes, that's because they don't have comprehensive test suites (which are notoriously hard to write for form-based Delphi apps).

That's not quite true. Jira Server is EOL in february this year but there's still Jira Data Center which is also on-prem (and extremely expensive). So the question is what "limited" means. Jira is licensed per-user and I'm guessing that they're not going to buy a license for each of their Delphi users. Instead they might be going with Jira Cloud internally and Jira Service Management (JSM, formerly Service Desk) externally. JSM is licensed per agent (internal user) with unlimited externals users (called "external customer" in JSM). I trialed JSM many years ago for external support but back then it was still licensed per external user and didn't really work that well, compared to something like ZenDesk. As far as I know JSM does not allow one external user to see the issues raised by other external users. I.e. it's a support system; There's no interaction between external users. So if JSM is the solution they are going for I don't see it as an improvement. As I customer I don't really care about what goes on behind the curtain. From my POW it seemed to work fine but I guess you point was that it only seemed that way. I wish I could have your admirable optimism.

Finally got some time to get back to my project and completed the goal. Thanks for the hints @Remy Lebeau. Here are the results if anyone needs the hack without modifying TSSLWSocketServer class: procedure TMainForm.SSLServerClientCreate(Sender: TObject; Client: TWSocketClient); var mConn: TClient; begin mConn := Client as TClient; mConn.OnDataAvailable := SSLServerDataAvailable; mConn.mTest := False; end; procedure TMainForm.SSLServerClientConnect(Sender: TObject; Client: TWSocketClient; Error: Word); var mConn: TClient; begin mConn := Client as TClient; mConn.SSLEnable := False; end; procedure TMainForm.SSLServerDataAvailable(Sender: TObject; ErrCode: Word); var mConn: TClient; mPeek: TBytes; mData: String; begin mConn := Sender as TClient; if not mConn.mTest then begin // first read SetLength(mPeek, 2); mConn.PeekData(mPeek, 2); mConn.mTest := True; if (mPeek[0] = 22) and (mPeek[1] = 3) then begin // client hello SetLength(mPeek, 0); mConn.SSLEnable := True; mConn.SSLContext := SSLContext; mConn.AcceptSSLHandshake; Exit; end; SetLength(mPeek, 0); end; mData := mConn.ReceiveStr; end; The only thing I'm worried about is memory leak due to not reading connected socket after data available call. At some point I had experience of that issue in another project. Regards.

If you want to use asynchronous mode for HTTP requests you should use TNetHTTPClient instead of THTTPClient. TNetHTTPClient is a wrapper that implements all the gory details in the background and leaves easy to use API for the developer. https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Net.HttpClientComponent.TNetHTTPClient As far as synchronizing events is concerned, in THTTPClient they will run in the context of the background thread, so you need to synchronize them with main thread if you need to access the UI. TNetHTTPClient has property SynchronizeEvents and depending on its value events will run synchronized with the main thread or not. Default value is True, so events will run in the context of the main thread. If you drop TNetHTTPclient on the form you can use it in asynchronous mode with just few lines: Client.Asynchronous := True; Client.OnRequestCompleted := HTTPRequestRequestCompleted; Client.Get(’http://....’); However, asynchronous mode is hard to debug and control, and I would suggest using simpler approach using background threads or tasks. TTask.Run( procedure var Client: THTTPClient; Response: IHTTPResponse; begin Client := THTTPClient.Create; try Response := Client.Get('...'); finally Client.Free; end; // process response in background thread ... // or pass it to the main thread TThread.Queue(nil, procedure begin Memo.Lines.Add(Response.ContentAsString); end); end);

I solved this thanks to the kind collaboration of the nSoftware assistance service (SecureBlackBox's developer). There were many challenges to solve to achieve the goal and very little can be found online. It is my understanding that this type of security is not used much in the Delphi environment. However I solved by combining several components provided with the SecurityBlackBox suite: TsbxCertificateStorage to read JKS file to reach public key (used to encrypt the request and verify the signed response) and private key (used to sign the request and decrypt the response) TsbxSOAPSigner to sign the SOAP request (to produce a WSSSignature) TsbxXMLEncryptor to embed in the request the encryption key (transported with RSA-OAEP sha1) and to crypt the SOAP request body (with AES128 algorithm) TsbxXMLDecryptor to decrypt the response (two items encrypted in the response: the sign and the body) TsbxSOAPVerifier to verifiy the sign in the response I've injected this encryption/decryption stuff in THTTPRio events, somthing like this; procedure TMultyAssociativeServiceWrapper.SOAPOnBeforeExecute(const MethodName: String; SOAPRequest: TStream); begin // save the original request (created by THTTPRio) for debug purpose SOAPRequest.Seek(0,0); (SOAPRequest as TMemoryStream).SaveToFile(FFileRequestOriginal); // sign and encrypt the original request SBBSoapSignAndEncryptWithJKS(FFileRequestOriginal, FFileRequestToSend, FCertificateFileJKS, OnPasswordNeeded); // ... do some other stuff ? // update the outcoming request with the signed crypted version SOAPRequest.Seek(0,0); (SOAPRequest as TMemoryStream).LoadFromFile(FFileRequestToSend); end; procedure TMultyAssociativeServiceWrapper.SOAPOnAfterExecute(const MethodName: String; SOAPResponse: TStream); begin // save te orginal response arrived from service for debug purpose SOAPResponse.Seek(0,0); (SOAPResponse as TMemoryStream).SaveToFile(FFileResponseOriginal); // decrypt and verify sign of response SBBSoapDecryptAndVerifyWithJKS(FFileResponseOriginal, FFileResponseDecoded, FCertificateFileJKS, OnPasswordNeeded); //... do some other stuff? // update the incoming response with the decrypted data SOAPResponse.Seek(0,0); (SOAPResponse as TMemoryStream).LoadFromFile(FFileResponseDecoded); end; SBBSoapSignAndEncryptWithJKS does sign + encryption stuff. SBBSoapDecryptAndVerifyWithJKS does decrypt and verify sign stuff. I hope this can be helpful for someone else who runs into this need. If you need the code of the two SBB procedures described above please ask me. I've used SecureBlackBox components but I think that same stuff could be reached also with ChilKat library. I did some tests with the demo library, it works at a lower level of SBB but there are several examples online that could be combined to reach the goal.

Its available under All Android 64 Bit, and should be under Release Android 64 Bit as well Did you switch in both Android 32 and 64 to the Application Store ? Did you provide in the Project options provisioning the requred data and verified it ?