Disclosure: I develop StreamSec Tools, a commercial security library for Delphi (TLS, SSH, X.509/PKIX, CMS, HTTP). Version 4.1.5.362 came out on 26 October and adds QUIC and HTTP/3. The QUIC part is written from scratch in Object Pascal, not wrapped around MsQuic or OpenSSL.

What's in it

• An RFC 9000 transport: packet protection, loss recovery, NewReno with pacing, connection migration, ECN, key updates, resumption and opt-in 0-RTT, on the library's own TLS 1.3 and crypto.
• Cross-platform: Win32/Win64, macOS, Linux64, iOS and Android, Delphi XE3 to 13 Florence (Linux from 10.3 Rio, mobile from 10.4 Sydney). IOCP, epoll and kqueue underneath.
• An HTTP/3 server on the same request router as the HTTP/1.1 and HTTP/2 servers, so existing handlers answer HTTP/3 unchanged, and an HTTP/3 client that finds a server's endpoint through Alt-Svc.

How fast is it?

Two Windows PCs over Wi-Fi, each library sending bulk data to each, 8 interleaved rounds per combination, medians. These are the runs sending to a StreamSec or MsQuic receiver:

So ahead of OpenSSL on throughput and at 82-95% of MsQuic, with CPU cost in OpenSSL's range. MsQuic is still far more CPU-efficient than either.

The OpenSSL bug

During interop testing, OpenSSL's QUIC client stalled against our server in every run. The cause: when the packet carrying an OpenSSL receiver's latest MAX_STREAM_DATA is lost, OpenSSL doesn't send the update again unless that packet also carried data for the stream. RFC 9000 section 13.3 says it must. With a short request and a long response, the download can stall for good.

We reproduced it with 3.5.7 and 3.5.9, with OpenSSL at both ends through a relay dropping 5% of the client's packets: 6 of 13 runs stalled unpatched, and 13 of 13 completed with a two-place patch. It's reported with the reproducer and the patch, and OpenSSL has triaged it as a bug on 3.5 through 4.1 and master: https://github.com/openssl/openssl/issues/33373 (the OpenSSL numbers above are with that patch applied).

Happy to answer questions about the implementation.

• Announcement, with the change log and SBOM: https://support.streamsec.net/forum/?cmd=viewtopic&section_id=4&topic_id=16
• HTTPS, HTTP/2 and HTTP/3: https://www.streamsec.com/strsecivhttps.php
• TLS: https://www.streamsec.com/strsecivtls.php
• Evaluation builds: https://www.streamsec.com/downloadstrseciv.php

The recent wave of high-profile supply chain exploits and PHP vulnerabilities is a warning shot for the entire software industry. As AI-driven vulnerability discovery accelerates, interpreted web stacks and cloud-native services face an unprecedented crisis of trust.

When cloud exposure becomes a liability, the pendulum will inevitably swing back toward sovereign, lightning-fast local native applications operating over truly secured channels. In that space, Delphi remains the undisputed King.

However, security through obscurity is eroding fast.

For 30 years, Delphi’s power lay in RAD - wrapping complex third-party libraries, legacy DLLs, and OS APIs into convenient components. But AI models don't care about shiny controls; they scan binaries for decades-old memory safety flaws and hidden buffer overflows hidden inside third-party dependencies.

Compounding this threat is the new wave of global cyber-security regulations (such as Europe's Cyber Resilience Act and expanding SEC disclosure rules). Regulators now demand total supply-chain transparency, mandatory SBOMs (Software Bill of Materials), and strict liability for unpatched legacy code. Saying "it won't happen to us" or relying on unmaintained controls is no longer just a technical risk - it’s a regulatory compliance violation.

To ensure Delphi applications serve as the ultimate secure fortresses of tomorrow, we must act:

Audit and modernize dependencies: Stop blindly wrapping legacy DLLs. Know exactly what code is executing underneath your components.

Integrate deep binary security: Implement strict memory checks, continuous audits, and zero-trust principles at the local architectural level.

Harden the infrastructure: Prepare your stack to meet modern regulatory compliance before the mandates force your hand.

The web era promised total connectivity, but native architecture delivers total resilience. Let's harden our ecosystem, eliminate the hidden vulnerabilities, and show the world why Delphi is built to last.

I’m looking for a small group of Delphi developers who use Macs and would be willing to beta test Debt Blaster, my Delphi FireMonkey application for macOS.

I’ve been developing Windows software for about 35 years, but this is my first serious macOS release, so I’ve been learning quite a bit along the way.

The current build is a notarized Universal app supporting both Intel and Apple Silicon. I recently moved the macOS build to Metal, which resolved the Retina/HiDPI rendering problems I had been chasing.

At this point I’d like to test it on a wider variety of Macs, macOS versions, Retina displays, and external monitors before submitting the final build to the Mac App Store.

I’m looking for perhaps 10 to 20 testers. If you’re interested, please DM me with your Mac model, processor, and macOS version.

Debt Blaster: https://debtblaster.com

Thanks.

Your code reviewer would quit on the spot. But does the compiler care? 😈

Which of these compile?

A) Naming things is hard

``` var

&begin, &end, &if: Integer;

begin

&begin := 1;

&end := 2;

&if := &begin + &end;

Writeln(&if);

end. ```

B) The forbidden keyword

``` label Again;

var

Count: Integer;

begin

Count := 0;

Again:

Inc(Count);

if Count < 3 then

goto Again;

Writeln('Dijkstra is crying');

end. ```

C) Semicolon enthusiast

``` begin

;;;;;;;;;;

end. ```

D) Commitment issues

if True then else Writeln('Huh?'); `

E) Wrong language, buddy

Writeln("Hello from C#!");

Answers below. Be honest, how many did you think were illegal? 😂

Hello,

I'd like to introduce NativeMirror, my latest open-source project written in Delphi 12.

NativeMirror brings PE-sieve functionality to Object Pascal. It can inspect running processes, detect modified or injected code, identify suspicious PE modifications, dump PE images and generate detailed scan reports.

The project includes:

- A reusable Delphi library

- Standalone command-line scanners for Win32 and Win64

- A PE-sieve compatible DLL

- JSON reporting and integration tests

- Integration with my NativePE library and optional NativeASM support

One of the most interesting parts is the HollowsHunter integration.

You can replace the original PE-sieve DLL with the Delphi-built NativeMirror DLL and run HollowsHunter using the Delphi implementation. An integration test for HollowsHunter 0.4.1.1 (Win64) is already included.

NativeMirror is an independent Object Pascal implementation based on the excellent PE-sieve project by hasherezade, with full credit to the original author and contributors.

The project is open source under the BSD-2-Clause license.

GitHub: https://github.com/habanada/NativeMirror

For anyone interested in Windows internals, reverse engineering, malware analysis or low-level development with Delphi, feel free to take a look.

Enjoy! :)

I’m troubleshooting a Delphi 11.3 FMX Universal macOS build and would like to know whether anyone else has seen this behavior.

Toolchain: Delphi 11.3 using the macOS 12.1 SDK through PAServer. The final app is a Universal build containing both arm64 and x86_64.

Here is what I’m seeing.

Apple Silicon:

• Native ARM64 launch works correctly.
• On my Apple Silicon Mac mini, the downloaded Universal build runs normally.
• If I use Get Info → Open using Rosetta, forcing the same app to run its x86_64 slice, it crashes.

There was also something interesting the first time I tried running the app under Rosetta.

The sequence was:

1. Get Info → checked Open using Rosetta
2. Double-clicked the app
3. macOS prompted me to install Rosetta
4. I installed Rosetta
5. macOS then displayed a separate message referring to Debt Blaster

I tried to expand/read that second message and it disappeared before I could capture the exact wording. It has never appeared again on subsequent Rosetta launches, even after downloading a fresh copy of the app.

If anyone recognizes that first-run behavior or knows where macOS stores the exact text of that message, I’d be very interested.

Actual Intel Macs:

• Intel MacBook Pro running Big Sur: downloaded Universal build fails at startup with Runtime error 217.
• Intel MacBook Pro running Monterey: same downloaded Universal build also fails with Runtime error 217.

Here is the part that has me puzzled:

If I target my old Intel Big Sur Mac directly from Delphi using PAServer, the Intel build runs correctly.

So the x86_64 application code is capable of running on that Intel Mac. The failure appears to occur with the distributed/signed Universal build.

When I force the Universal build to run under Rosetta, macOS Console records:

CODE SIGNING: vm_map_log_codesign_violation(7): curprot cannot be write+execute. failing

The signed Mac App Store build currently has:

com.apple.security.app-sandbox
com.apple.security.files.user-selected.read-write
com.apple.security.print

It does not currently have:

com.apple.security.cs.allow-unsigned-executable-memory

I’m trying to determine whether this is:

• a Delphi 11.3 x86_64 runtime issue under Hardened Runtime,
• something related to using the macOS 12.1 SDK,
• a missing executable-memory entitlement,
• an older Delphi or third-party component,
• or something introduced during Universal packaging/signing.

Has anyone seen a Delphi Universal macOS app where ARM64 works, x86_64 fails with Runtime Error 217, but the Intel build works when deployed directly through PAServer?

I’m particularly interested in anyone who has encountered the curprot cannot be write+execute Console message with a Delphi application, or who recognizes the one-time macOS/Rosetta message described above.

Delphi Brain Teasers – Round 2 🧠

Round 1 went great (and Remy humbled me on #5 😅), so here's round 2. This time I actually ran everything in Delphi 12, I promise 😄 Same rules: no compiler, gut feeling only, answers in the comments.

1) Captured!

``` var

Procs: array[0..2] of TProc;

I, J: Integer;

begin

I := 0;

while I < 3 do

begin

Procs[I] := procedure

begin

Write(I, ' ');

end;

Inc(I);

end;

for J := 0 to 2 do

Procs[J]();

end. ```

What gets printed?

2) Twins that aren't twins

``` var

S1, S2: string;

A1, A2: TArray<Integer>;

begin

S1 := 'Hello';

S2 := S1;

S2[1] := 'J';

A1 := [1, 2, 3];

A2 := A1;

A2[0] := 99;

Writeln(S1, ' ', A1[0]);

end. ```

Output?

3) Tiny string, big surprise

Writeln(Length('😀'));

1? 2? 4? 🤔

4) Will it even compile?

``` var

X: Integer;

begin

X := 10 / 2;

Writeln(X);

end.

5) Who gets called?

function Check: Boolean;

begin

Write('Check ');

Result := True;

end;

begin

if (False and Check) or Check then

Writeln('Yes');

end. ```

How many times do you see "Check"?

Score yourself honestly 😄 And if you've got a good one for round 3, drop it below!

Is the elevatesoft.com (ElevateDB and DBISAM) down?

I just had my Debt Blaster app rejected by the Mac App Store after six days in review.

It is built with Delphi 11.3 / FireMonkey.

Apple rejected it under 2.1.0 Performance: App Completeness (macOS) and said:

The app exhibited one or more bugs that would negatively impact App Store users.

Bug description: We were unable to use the core feature, because when clicking on any field, app UI gets covered by random boxes.

Apple tested it on a 14-inch MacBook Pro running macOS 27.2.

Their screenshots show the UI looking dramatically oversized, roughly 4x the size I normally see, with large gray/white rectangular areas appearing over the interface after clicking into fields.

The exact same build works correctly on my Mac mini connected to a standard 1920x1080 non-Retina display.

The submitted app has:

NSHighResolutionCapable = true

That has me wondering whether this is an FMX HiDPI/Retina rendering problem.

I found this older DelphiPraxis thread describing severe FMX scaling/rendering problems with NSHighResolutionCapable=true, where setting it to false reportedly fixed the issue:

https://en.delphipraxis.net/topic/2729-nshighresolutioncapable-true-scaling-problems-on-macos-1013/

Embarcadero documentation:

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Version_Info

Apple High Resolution documentation:

https://developer.apple.com/library/archive/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html

I am now preparing a controlled test using the exact App Store binary Apple reviewed:

• Test A: NSHighResolutionCapable=true
• Test B: same app, same executable, same entitlements, but NSHighResolutionCapable=false

Both will be signed and notarized, then tested on the same Retina MacBook Pro.

Before I go further, I would really appreciate hearing from anyone who has shipped Delphi FMX macOS apps:

• Have you seen this type of rendering corruption on Retina/HiDPI displays?
• Have you used NSHighResolutionCapable=false in a production Mac App Store app?
• Are there known Delphi 11.3 FMX issues with Retina scaling that I should be looking at instead?

I’v attached Apple’s rejection screenshots because it shows the problem much better than I can describe it.

Hey Delphi folks 👋

Got a few quick brain teasers for you. No compiler, no Googling, just gut feeling 😏 Drop your answers in the comments and I'll post the real ones tomorrow.

1) Exit vs finally

function Magic: Integer;

begin

Result := 1;

try

Exit(2);

finally

Result := 3;

end;

end;

What does Writeln(Magic) print? 1, 2 or 3?

2) The object that never dies

type

TFoo = class(TInterfacedObject)

destructor Destroy; override;

end;

destructor TFoo.Destroy;

begin

Writeln('Bye!');

inherited;

end;

procedure Test(const I: IInterface);

begin

end;

begin

Test(TFoo.Create);

Writeln('Done');

end.

Does "Bye!" ever show up?

3) Good old "with"

var

P: TPoint;

X: Integer;

begin

X := 0;

P := Point(0, 0);

with P do

X := 42;

Writeln(X, ' ', P.X);

end.

What's the output? (If you love "with", you might not after this one 😅)

4) Negative math

Writeln(-7 div 2, ' ', -7 mod 2);

Python people, please sit this one out 🤫

5) Poor little Byte

var

B: Byte;

begin

B := 255;

Inc(B);

Writeln(B);

end.

Default project settings. Exception, 256, or something else?

Be honest about how many you got without cheating 😄 And if you've got a nastier one, share it. Maybe it'll show up in round 2!

Hi,

I just published the Python4Pascal project at GitHub.

Python4Pascal is based in the Python4Delphi project made by Kiriakos Vlahos (PyScripter).

It uses Python 3.15, 3.14, 3.13, 3.12, 3.11 and 3.10, and it supports Windows, Linux, macOS and Android.

Python4Pascal was developed and tested on Delphi 13.2, Delphi XE2, Delphi 7 and Lazarus 4.8/FPC 3.2.2.

The most important Python4Pascal features:

• Supports the latest version of Python 3.15
• Python4Pascal handles the Python objects lifetime automatically.
• Fully documented in XML code comments, CHM and HTML files.
• Imports more than 1200 Python library functions and types.
• Includes many helper classes to handle all Python objects with Delphi/Lazarus types as arguments whenever it's possible.
• Demos for Windows , Linux, macOS and Android.
• It's possible to create Python modules and module extensions.
• Python4Pascal can handle Python objects with variant types or using Delphi wrappers.

Python4Pascal has a few things in common with Python4Delphi but many other things are much different. Some Python4Delphi features are not included, for example RTTI and the assembler code to convert the callbacks.

I still have to write some tutorials in the Wiki.

I have posted two updates to my Codebot Library that now include IDE theming and Windows Shell controls packages:

Themes allow Lazarus to be altered using a JSON file to add custom styling and fonts to the IDE. It works on both Windows and Linux. Windows shell brings a selection of controls and components for replicating Windows file explore in your Lazarus applications on Windows. It is based on my old Codebot shell library, but bring about many improvements.

Brief videos are hosted on the two pages above demonstrating these packages.

I also have a dynamic package supporting FPC and Lazarus available for download that includes all these features and more, along with dynamic package loading and unloading.

And 26 bugfixes: https://www.steema.com/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&chfield=resolution&chfieldfrom=2026-05-27&chfieldto=2026-10-19&chfieldvalue=FIXED&list_id=11011&order=Importance&product=FireMonkey%20TeeChart&product=VCL%20TeeChart&query_format=advanced&resolution=FIXED

Delphi should have a personal edition for under $100 with a perpetual license and commercial use allowed for individual developers.

Some people just want to build native desktop applications with a visual designer without spending a fortune.

When .NET WinForms and WPF are free Delphi's pricing makes no sense. I know there's a Community Edition but its restrictions aren't a replacement for an affordable license.

What exactly does Embarcadero gain from this? They're just pushing potential developers toward other tools and once those people move they're unlikely to come back.

Delphi is still a good development environment, but its pricing and management seem stuck in another era. It's hard to grow an ecosystem when you make it so unattractive for new developers to join.

🏛 Delphi Forever! Get Your Free Delphi Deep Code Analysis for Total Clarity and Regulatory Peace of Mind!

🏛 Don't Panic! Even if regulators are knocking on your door with strict SBOM, CRA, and DORA compliance mandates - and traditional scanners don't even understand native Delphi code - your legacy stack is saved.

🏆 Stay Strong! Your Pascal code, your VCL 3rd-party components, and Delphi’s blazing-fast binary execution still work remarkably well. You shouldn't have to abandon the core tech that powers your business.

🥇 Service to the Delphi Community: Unlike vendors driving up subscription fees, we are offering our Analyzer for FREE to the global Delphi developer community.

🔥 Full Deep Scan with Zero Code Limits: Deeply analyze your compiled Delphi binaries, exposing all hidden DCUs, DLLs, embedded resources, and binary footprints regardless of project size.

🔍 Uncover the Blind Spots: Visually map statically linked C object engines (.obj), embedded resource payloads (.res), database drivers, and runtime "LoadLibrary" calls executing in process memory.

💥 Expose Hidden CVEs: See exactly what traditional source-code scanners (SAST) miss inside the native wrapper engine.

✔ No code limits.
✔ No analysis depth caps.
✔ No subscription fees.

👉 Keep calm & keep coding in Delphi, and let us cover your back beneath the hood.

Download your free Delphi Deep Code Analyzer today (link in first comment)

[ Removed by Reddit on account of violating the content policy. ]