Darian Miller

The problem with NQS is lack of updates. The latest release is 1.63 from April 5, 2019. One minor version before that on Jan 8, 2019, two versions in 2017, and then it jumps to 2015. My renewal is due but it hasn't been updated since I purchased it so I haven't pulled the trigger on renewal. I originally purchased the TurboPower version many years ago and always preferred it over AQTime. The pricing for AQTime has always been higher and is now $1,900 per concurrent user. You can get a cheaper version at $600 but they don't allow you to run it on a VM. So the best price by far is NQS at about $310, especially if you can time it with a nice discount code.

I did use your example but didn't see any corruption when looking at it flash by. I put the TickCount back and changed the WmStatusOut to if StrToIntDef(PChar(Msg.WParam),-1) = -1 then begin OutputDebugString(PChar(Msg.wParam)); end; And there are indeed a few that show up in the messages window over time. However, they display as normal looking numbers. Since StrToIntDef is failing I assume there's something amiss....? WM_USER. Simply in the habit of always using WM_USER + something, usually a constant.

@David Heffernan I was testing Ander's assertion "I can guarantee that you will see corrupted output" I tested and didn't see it, at least in a limited time window. But there were many thousands of iterations and no corruptions detected. It was simply something interesting to test...

I ran your code and didn't see any corrupted output after letting it run for a few minutes. After my eyes glazed over concentrating on the debugger messages flashing by, so I tweaked it a bit to only output if the string value is different. See attached. Perhaps this just needs to run overnight to eventually see the issue. Your explanation seems very plausible but the string allocation mechanics must allow this to work (at least the vast majority of the time.) Tested on a 4 virtual core, fairly speedy VM with Windows 10 and Delphi 10.3.3. StringCorruptionTest.pas StringCorruptionTest.dfm

I don't know if there's enough info provided to solve this. But, this is what I'd do with this small bit of info: First, comment out the lines in the method: TSequence.StatusOut. Do the AV's persist? If so, then look elsewhere. Then comment out one line at a time in procedure StatusOut until the AV's stop. Is the problem in LogWrite() or frmMain.memStatus.Lines.Add()? I have to imagine you are assuming the problem is the memo. If so then why is LogWrite in the example code? Since we're all just guessing here, my guess is that Application.ProcessMessages was leading to a StackOverflow error, which was trapped/muted and led to a different exception elsewhere. (As when there's one ProcessMessages call, there's likely more.) Use ProcessMessages as often as you use the With statement....as little as possible.

I posted a blog article on this topic yesterday: https://www.ideasawakened.com/post/name-your-threads-even-the-ones-auto-created-by-delphi I'm curious how many others do this sort of thing. I think it really comes in handy sometimes. I also went looking for the reasons behind each of the Delphi-created threads, other than the main message loop. Do you have any info on that? I could swear I read an article on it years ago, but couldn't find it.

That works. I actually started this code as part of some internal thread management plumbing that I'm building. I separated it out for the blog article but I used something similar to it in an initialization section for at least a decade prior at a previous job. I no longer have access to that code to know if it added any delays or other tweaks. I doubt it did knowing that I wrote it a very long time ago.

I hadn't seen this yet - Set/Get thread description available since Windows 10 1607 (Anniversary Update) and Windows Server 2016 https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription

I don't know of any quick tricks to get the current thread name, perhaps someone will share that if it's available.

I imagine it could certainly happen - but I haven't witnessed that I recall in any debugging session using this type of code over quite a few years. Do you have knowledge of all native threads created and what they are used for?

This was posted on Reddit the other day and there are now 23 votes on this idea. SonarSource provides support for 26 languages, but currently not Delphi/Pascal. Please vote to improve the odds of adding support: https://community.sonarsource.com/t/add-delphi-language-support/5492 These are the languages currently supported: https://www.sonarsource.com/products/codeanalyzers/ With the current ruleset for each language: https://rules.sonarsource.com/

If hackers are in your memory space, the game is over anyway. If they are using plaintext now, the focus should be on encrypting the data at rest and ensuring it's protected in transit. Some discussion about Delphi specific solutions: https://stackoverflow.com/questions/8621441/what-protection-scheme-for-my-passwords For securing strings in memory: https://medium.com/@svanas/creating-a-securestring-type-for-delphi-part-1-e7e78ed1807c

I had some similar issues with 10.3.3 and GExperts so I uninstalled it. I couldn't reproduce the issue but haven't after uninstalling GExperts I haven't experienced the hanging IDE. Could be coincidental as it was seemingly random hangs.

I've been using VMWare for a number of years and haven't noticed a difference in runtime performance from split or monolithic virtual disks. Split disks do have the benefit of much quicker defragmenting, which is a common task that I do to increase performance. So I would say it indirectly increases performance.

10.3.3 (I haven't checked when this was introduced) System.Net.HttpClient procedure THTTPClient.CreateFormFromStings(const ASource: TStrings; const AEncoding: TEncoding; const AHeaders: TNetHeaders; var ASourceStream: TStream; var ASourceHeaders: TNetHeaders); Its used ten times in two units. (twice in System.Net.HttpClientComponet) As it's a public method, they would break backwards compatibility to fix it, but I suggest they fix it... https://quality.embarcadero.com/browse/RSP-27358 Did I miss a conversation on this? I didn't see any references.

And... RSP-27358 is back open again. Minor victory! Thanks Bruneau Babet and those that commented on this and https://quality.embarcadero.com/browse/RSP-27412

Not sure I agree with this closure https://quality.embarcadero.com/browse/RSP-27358 with "Yes, too late, we'll live with it" "Method CreateFormFromStings spelling mistake" You should be able to fix spelling mistakes of public methods from a recently published version...backwards compatibility is not 100% written in stone

Ah yes, I neglected to mention ARC removal in my summary. I guess I assumed that one was well known as coming in 10.4

I've collected some info on 10.4 here: https://github.com/ideasawakened/DelphiKB/wiki/D27.Next.10.4.0.0 Specifically, managed records was pushed off for 10.4: http://blog.marcocantu.com/blog/2018-november-deferring-managed records.html And it was confirmed recently as coming in 10.4: https://community.idera.com/developer-tools/b/blog/posts/get-ready-for-the-10-4-beta-with-update-subscription That's all I've seen specifically for language enhancements in 10.4.0 but they may surprise us. I'm looking forward ti VCL Styles + High DPI improvements in 10.4. The language server protocol will likely open up a new set of tooling for the IDE, which might be cool if it works. Beta should start 'very soon' - supposedly sometime in March.

For what it's worth, here's a few different responses: One answer is keeping up to date with changes to Microsoft Windows... for example HighDPI support. Does your software work well with Windows 10 high dpi systems? Delphi is getting much better with this particular issue. Hopefully 10.4 finally fixes some of the issues with VCL Styles and High DPI. Another answer is compliance related - some compliance certifications require your tooling be kept up to date with all available patches/updates. If you aren't under third party audits, this is less of an issue but for security in general keeping current is wise. (Do you have the buffer overflow fix for Delphi in place?) Another answer is business risk / insurance related - It may bite you later on any future insurance claims that you knew you were out of date but didn't upgrade to fix any potential problems. Are you going to milk this thing as it is until it dies, or are you ever going to add new features? If you are going to add features, staying current may make future features easier, especially keeping up with fast changing technologies like AWS/Azure. If you are using any third party components, eventually they will drop support for older versions of Delphi. You have to assume most of the new activity in third party components surround the new releases. With more and more new language features becoming available (like inline variables) that devs really like to use which aren't backwards compatible, the rate of third party components dropping support for old versions will probably increase over the next few years. This is obviously one of the prime goals of Embarcadero - and they will keep hammering at. It's in their best interest to introduce new non-backwards compatible language features and this approach will succeed over time. Finally, the longer you wait, the harder it becomes to ever bring it back up to date. It's just delaying the cost today for higher costs tomorrow. If they are in it for the long term, they should act like it. If you are a one or two-man shop then it's certainly much harder to justify the ongoing costs due to the ever increasing price (which I assume will keep getting worse), but if you are making a decent living with the Delphi products then it only makes sense to keep them current.

I put a few more items into this repo today: - Alternative implementation from https://www.helpandmanual.com/downloads_delphi.html - Newer Hunspell en_US dictionary from SCOWL (2019.10.06) - Newer Win32 version of libhunspell.dll , built today from 2019.11.12 source, along with two small PDF docs. I have a TFrame descendant that has the spell check functionality built-in, initially built for use with TMS components. TMS has an ISpell based spell checker component that hooks into their TAdvMemo component. It's pretty easy to replace their ISpell integration with a Hunspell integration using the CCR Hunspell unit. There are a lot of recently updated dictionaries available for use with Hunspell. ASpell as another option, with a lot of current dictionaries and there's also a spell checker API in WIndows 8+ as mentioned on StackOverflow, but I haven't investigated this much..

Chris Rolliston's MPL source from Code Central is now on GitHub. You can help make it as active as you like. : ) https://github.com/darianmiller/Delphi-Hunspell

I did get a response out of Glenn Crouch @ AddictiveSoftware. Apparently still pumping out manual updates for the latest Delphi release.

I was just looking at that. Along with Rolliston's code: https://cc.embarcadero.com/item/27428 https://delphihaven.wordpress.com/2010/02/06/compiling-a-hunspell-dll-step-by-step/

If you want to build web applications with Delphi, you'll probably want IIS.