Darian Miller

Technically, yes. If they want to put your code on GitHub for free, they can. That was the obvious overall intent of that paragraph.

"Everybody you give the binary"... to all your customers is indeed the intent. And that is considered 'public' to many commercial software vendors. If you only have 10 customers, then perhaps not. But there are also no restrictions placed on those that receive your code. They can put your code on GitHub and make it freely available to everyone in the world. So if you use GPL code in your commercial app, your code can deemed to be 'publicly available' by nearly any standard.

Yeah, I was excited for SuperCore with IOCP years back. I eventually wrote my own IOCP server but I never put it on production as my first few versions complicated the heck out of a simple server. My simple tests were easy enough to see huge throughput but when it was time to port an existing server over, it simply didn't turn out to be worth it. Given today's news with FastMM5, maybe you should get an Indy 12 professional ready to go and release it GPL or Commercial. That would throw some extra wrinkles into Embarcadero's bedsheets... Delphi has certainly leaned heavily on Indy for a number of years now.

If you distribute applications that includes some GPL code, then all the code to your application must be made publicly available. Commercial software makers typically stay far away from GPL. Now, if you are actually making money on the software you make and distribute, then it makes sense to pay Pierre for a commercial license, bypassing the GPL issue. It's a real line in the sand for FastMM5. Perhaps Embarcadero will negotiate with Pierre a nice big fee to get a redistributable commercial licensed version of FastMM5... or they will simply keep shipping Delphi with FastMM4. They certainly won't be shipping a GPL version of FastMM5 with Delphi.

I notice the license has changed to $99/dev. "FastMM 5 is dual-licensed. You may choose to use it under the restrictions of the GPL v3 licence at no cost to you, or you may purchase a commercial licence. A commercial licence includes all future updates. " I assume forks like this one will be excluded from FastMM5+ changes: https://github.com/maximmasiutin/FastMM4-AVX @Pierre le Riche what happens with Delphi and FastMM in Delphi 10.4 and beyond? Will it be frozen at the current version of FastMM4?

Interesting! Any plans for Indy server-side usage?

"Work is underway" Is there any projected timeframe?

Economics is a factor, but when the roadmap only includes items from 2013 and 2014 then it certainly feels like an abandoned product so expectation of future support is also a factor. https://www.nexusdb.com/mantis/roadmap_page.php

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