Leaderboard

I think that number is probably underestimated as many of the XP machines aren't connecting to the internet. Just busy running 24x7 on a factory floor somewhere, in a kiosk, or cash register. (Not to mention all the Windows XP still in use by government and military)

Interesting, I hadn't seen this before (and I thought I had seen every delphi package manager!). Can't really make heads or tails of it though - not quite sure how it works. The docs are a little out of date - the project is still actively being worked on (source code here) - I'm currently working on project group support, resolving package conflicts between projects - anyone familiar with nuget would understand where I am heading This is what working with an individual project looks like 🤣 thought you were talking about package managers, not a promotional vehicle. I'm skipping D11 so no pain this time - but I am working hard to get DPM usable for everyone - that said, I have a day job that takes most of my time, so contributions and collaboration is welcomed 😉

Yet another way to look at it: Wow! Many folks still use Delphi and are eager to use the newest release as well. So.... not dead! EoD.

https://quality.embarcadero.com/browse/RSP-35511?jql=project %3D RSP AND resolution %3D Unresolved AND affectedVersion %3D "11.0 Alexandria" ORDER BY priority DESC%2C updated DESC 546 issues registered for Alexandria as of now. It is not ready for use, IMO. Waiting for Update 1.

Done. Also, there was a problem with the last update where I failed to upload a recent change in Img32.pas which caused problems in Img32.Layers. That's now fixed too. I've also made a minor update to the Layers301 sample application. https://sourceforge.net/projects/image32/files/

Two new zips for Win32 and Win64 versions of OpenSSL 3.0.0 can now be downloadable from the Wiki at: http://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/ma?g?ics.asp . ICS V8.67 from SVN or the overnight zip is required to use 3.0 and later, due for final release in a few days. The ICS distribution will continue to include OpenSSL 1.1.1 for a while until 3.0 becomes better tested. Beware the ICS Jose unit currently gives errors with the Win64 platform, being investigated, Win32 plafform is ok. OpenSSL 3.0 is a major new release, primarily a lot of internal changes to ease long term support. There is an optional FIPS module with 3.0 but not available here since our DLLs are not built to standards required for certification. The old engines for special extensions are replaced by new more versatile providers of which the FIPS module is one, a provider legacy.dll contained in the distribution has obsolete ciphers and hash digests that most applications no longer need and which needs to loaded by the application. For details of the changes in 3.0.0, see the release notes at: https://www.openssl.org/news/openssl-3.0-notes.html Highlights are: * Implemented support for fully "pluggable" TLSv1.3 groups * Added support for Kernel TLS (KTLS), Linux only * Changed the license to the Apache License v2.0. * Moved all variations of the EVP ciphers CAST5, BF, IDEA, SEED, RC2, RC4, RC5, and DES to the legacy provider. * Moved the EVP digests MD2, MD4, MDC2, WHIRLPOOL and RIPEMD-160 to the legacy provider. * Added convenience functions for generating asymmetric key pairs. * X509 certificates signed using SHA1 are no longer allowed at security level 1 or higher. * Added a Certificate Management Protocol (CMP, RFC 4210) implementation. * Added a proper HTTP client. * Changed our version number scheme, major, minor, patch, so 3.0.0 (no patch letter) * SSL 3, TLS 1.0, TLS 1.1, and DTLS 1.0 only work at security level 0. * TLS 1.3 FFDHE key exchange support added Angus

HTML Component Library, HTML Editor Library and HTML Report Library version 4.5 released. What's new: 1. RAD Studio 11 Alexandria support. 2. New THtMarkdownPanel component for displaying Markdown documents. 3. Improved Markdown support (tables, links, etc.) 4. Improved rending or large SVG images 5. Improved Flex support. 6. Improved handling of incorrect markup (tag order). 7. Added THtPanel.OnShowResizeHint event. 8. Added THtDocument.EmbedAllImages method for embedding images into document. 9. Added THtPanel.Script property for storing common scripts. 10. Added PrintScale parameter to Print method for scaling pages. 11. Added SplitBlocktoRoot method for splitting nested blocks (f.e. citation in emails). 12. Support for disablet attribute in inputs. 13. Added HighlightCheckedNodes property in THtVirtualXMLTree. 14. Improved scrolling of page with many input controls. 15. Added PNG encoding of pasted images for FMX. 16. New Editor event OnSurrogatePair. This event is called on second (low surrogate) char and when it returns true, default char processing is skipped. 17. SVG: added support for preserveAspectRatio with values none, meet and slice. 18. Faster rendering of large break-all blocks. 19. Support for type="number" in inputs. 20. Added Remove method to JQuery. 21. Addes support for attr!=value selector 22. Added support for summary and details elements. 23. DOCX to HTML conversion is now supported in Delphi 5 - 7. Fixed issues: https://delphihtmlcomponents.com/fixed45.html https://delphihtmlcomponents.com/

Hi there, I want to wave goodbye to Delphi 10.4.2. This was for me one of the most stable versions in the past, maybe only XE8 was similar stable and less critical for me. Yes, it had its hickups here and there, but nothing too annoying at all. It accompanied me in the last 12 months as true friend, so I wish you luck in the afterlife. Looking forward to see Rx11 as stable as its older brother, and to give me another 12 months cycle of convenient Life. The start looks very promising, lets see ...

Sure. You can also click it to quickly check out some other branch/tag. I haven't tried the VS Code integration in Delphi 11 yet, maybe that makes it even more appealing.

To be fair, VSCode has 5k+ open issues 🙂

I think the "problem" with Package Manager is that is has to be widely adopted by the community to be very useful. Because the key is that relevant libraries and 3rd parties are available in the package manager. "Unfortunately" Embarcadero is pushing GetIt so it's unlikely we will have a different one being widely adopted, I guess.

The reality is that most people don't modify packages, they just use them. As for packages being global, well that's one of my pet peeves - because I work on different projects or versions of projects that use different versions of a package - can't do that is packages are global - at least not without a lot of hassle. That's something I working to resolve in my package manager. The cool thing about any package manager is that it's optional - you can choose to use it or not, or use it for some packages and reference others manually like before.

Maybe the function ThemeServices in unit Themes is what you are looking for.

I'm not sure this can be solved truly lock-free. Even if you make the low-part of the counter thread-local to avoid a lock, you still have the high-part of the counter to deal with to track rollovers, and that will have to be protected from concurrent access, either with a lock, or atomic access, etc. I really don't know if that will work or not. I think the entire counter needs to be global, so that new threads will start with the latest accumulated value properly. I'm thinking something like the following, based on ideas I've seen in other implementations: var TickCount64: UInt64 = 0; function GetTickCount64Emu: UInt64; var OrigValue, NewValue, TmpValue: UInt64; CurrTicks: UInt32; begin OrigValue := TInterlocked.Read(TickCount64); repeat CurrTicks := Windows.GetTickCount; NewValue := (OldValue and $FFFFFFFF00000000) + CurrTicks; if CurrTicks < UInt32(OrigValue and $FFFFFFFF) then Inc(NewValue, $100000000); TmpValue := TInterlocked.CompareExchange(TickCount64, NewValue, OrigValue); if OrigValue = TmpValue then Break; if TmpValue > NewValue then Exit(TmpValue); OrigValue := TmpValue; until False; Result := NewValue; end; Yes, that would be required no matter what. Oh yeah, I forgot about that. Well, then just call GetProcAddress() manually at startup (or first call) instead of using 'delayed'. This is what Indy does.

Just tried the Image32's SVG viewer, the rendering result is almost perfect in my eyes! You've done a great job Angus!

Just updated to version 3.2 https://sourceforge.net/projects/image32/

Alas, no. The tick rollover could happen at any time, so even short-running apps are not protected. Moreover, the issue isn't exclusive for 24/7 servers only because of hibernation. I personally prefer to hibernate my PCs (both work and personal) when I leave so I have uptimes counting weeks and months.

For all who want to try to get the DDevExtensions Delphi IDE plugin to work with Delphi 10.4 can now clone the DDevExtensions git repository. It contains the project files for Delphi 10.2 and 10.3. I'm not able to help with any Delphi 10.4 issues, so you are on your own. GitHub repository: https://github.com/ahausladen/DDevExtensions

I am with @Anders Melander - If you need XP compatible software, you need to use an older Delphi. Cutting technical debt is vital to simplify any system.

I watched the sneak peak webinar and Marco mentioned that apps would no longer run on XP and also described the workaround in the original post here. So yes, this is intentional, and submitting a QP report would be kind of pointless. However, if you want there to be one you could do it yourself, rather than ask somebody else to do it.

But using GetTickCount64 in fact is a must for their code in the Threading unit which internally uses the milliseconds counter. As you know, the counter overflows every 49 or so days and some threads in your server application just hang waiting until the condition TThread.GetTickCount > FLastSuspendTick.Value + TThreadPool.SuspendInterval is fulfilled... I got hit by this myself. Of course, it mostly matters for the applications that run 24/7, but anyway using the 64 bit counter is a wise decision.

@mitzi Thanks a lot. This could make some backed up WinXP VMs with old XP projects obsolete, if we can compile them in current Rx11 too. Lets utilize the free'd disk-space with some new, astonishing and modern FMX project's

Support for older versions of Windows doesn't come for free. Official support means that they need to test against those versions and that they can't use the APIs of newer versions. Given the minimal market share of XP it hardly seems worth using resources to support it. If support for XP is required then use a version of Delphi that supports XP instead. I myself am on Windows 7 and if (when) that breaks Delphi then I will only blame myself.

There's too many "should run" in there. Neither the IDE, nor the produced Win32 binaries are intended to be run on Windows XP, MS-DOS or Enigma. Is there a guarantee it will run on those platforms, just by not importing GetTickCount64? That just doesn't sound safe enough to promise my customers the same.

They explicitly don't want to keep on supporting these old versions. Why? Emba have done all this intentionally.