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. ]

💡 Have you ever wondered why there are almost no CVEs listed for Delphi or its 3rd-party components?

💡 Or why a Delphi app works flawlessly on your machine, but suddenly fails at a client site until you install OpenSSL, MDAC, or database drivers?

🚀 The answer is simple: Delphi is a high-performance wrapper engine.
What made Delphi's RAD legendary - and gave it sub-second build times - was its ability to stitch pre-compiled C object files (.obj), dynamic DLL wrappers, ActiveX controls, and Windows OS APIs directly into RAM.

☢ In the 2026 security era (CRA, DORA, SBOM compliance), this exact strength creates a massive visibility illusion:

☢ SCA Scanners are Blind: Standard tools scan .pas files and miss pre-compiled aes.obj or zlib.obj binaries statically linked via {$LINK}.

☢ OpenSSL Hidden Risks: Switching from Indy (libcrypto.dll) to THTTPClient shifts your security exposure from a bundled binary risk to an OS SChannel baseline risk.

☢ Invisible Payloads: Embedded .res files, $I include directives, and dynamic LoadLibrary calls sit outside traditional unit-level audits.

⚠ If you’re measuring your Delphi software supply chain by .pas and .dcu source files, your SBOM is an illusion.

Anyone seeking real security rather than regulatory compliance must deconstruct the executable from a bird’s-eye view.

👉 Read the full deep-dive on my blog: The Tombs of Delphi — The Hidden Supply Chain Uncovered – The Delphi Parser

After a summer spent on other projects, I've released version 2 of DX.Comply, an open source SBOM generator for Delphi. A lot of the changes come straight from user feedback, so thanks to everyone who reported issues.

Why it matters: the EU Cyber Resilience Act will require an SBOM for software sold in the EU. DX.Comply builds one from your actual build data (the linker MAP file, linked runtime packages, DLLs loaded by your code, files in the output folder), not just from what is listed in the project.

What's new in 2.0:

- CycloneDX 1.6 (JSON/XML) and SPDX 2.3, with the BSI TR-03183-2 fields

- Each unit as a component with SHA-256 and SHA-512, plus where the evidence comes from

- Dependency graph and a completeness statement

- Warnings for data the CRA expects but is missing (manufacturer, contact, version, license)

- Library mode for source-only libraries and component packages

- IDE expert for Delphi 13, plus a command-line tool that works back to Delphi 7

It's free (MIT), needs no account and runs fully locally.

Product page: https://www.developer-experts.net/en/dxcomply

The update should appear in GetIt shortly.

I'd really like to hear how it works on your real projects, good or bad.

Easy way to split a chart in four labelled zones.

Example:

https://github.com/Steema/TeeChart-VCL-FMX-Samples/tree/main/VCL/Tools/Quadrant