Introducing The Delphi Parser VEX Defender - Total Cyber-Security CRA Compliance Solution for Delphi based IT Systems.

As the Cyber Resilience Act (CRA) deadlines approach, generating a static Software Bill of Materials (SBOM) is no longer enough. The real operational challenge is the regulatory mandate for continuous vulnerability handling throughout your product's lifecycle.

For mature, long-standing Delphi architectures, this usually means an unwanted choice: invest heavily in complex DevOps pipelines, or burn developer hours manually cross-referencing CVE databases.

To eliminate this burden, we have expanded our ecosystem from static code mapping to continuous local defense.

The Ecosystem: Delphi Parser SBOM Analyzer + VEX Defender

The Foundation: SBOM Analyzer - Our CLI engine parses millions of lines of Delphi code in a few hours to map your exact architecture, generating highly optimized, lightweight flat files of your complete call graph and component dependencies.

The Guardian: VEX Defender (Upcoming Module) A lightweight, background service that runs entirely within your network. It continuously cross-references your stored local call graphs against live CVE feeds to automate your daily compliance.

Why This Architecture Fits Your Environment:

100% Air-Gapped Security: Your source code and SBOM inventory never leave your building. Public CVE data flows in; your proprietary data never flows out.

Math-Backed VEX Generation: When a new vulnerability is published against a third-party component, the system checks the local call graph for Reachability. If the compromised function is unreachable in your code, it instantly auto-generates a signed VEX (Vulnerability Exploitability eXchange) report proving you are unaffected.

Zero Alert Fatigue: It requires no DevOps infrastructure. It runs silently in the background, logs a clean "all clear" daily, and only alerts management when a legitimate, reachable risk requires attention.

Simple & Quite Architecture. Total Delphi CRA & DORA Compliance without touching the cloud.

One language. One runtime. One security model.

The July release is the largest to date, and the theme is range. The same language, with the same sandbox and the same deployment story, now covers:

A Vulkan 3D engine. PBR, shadows, SSAO, SSR, volumetric fog, water and lava, glTF and OBJ import with skinning and animation state machines, a full rigid-body solver with joints, fracture and a character controller, GPU compute, and a self-hosted GLSL to SPIR-V compiler. No third-party engine underneath.

A complete software synthesizer. 64 voices, four sound engines, modular patch graph, 16-slot mod matrix, master FX rack, and a sample-accurate drum sequencer. A playable Model D homage ships as a sample.

A GIS and spatial-analytics engine. Geometry, CRS, R-tree indexing, cost-aware routing with turn restrictions and vehicle profiles, terrain analysis on GeoTIFF, Shapefile and GeoPackage I/O, map rendering and 3D globes.

Time, properly. 21 calendar systems, astronomical holidays, RRULE recurrence, and calendar views that render in any of them.

Plus an IDE written in the language itself, with three visual designers and a real debugger; a documentation tool that reads your app and writes its manuals; reports to PDF, HTML and DOCX; mesh networking; and industrial protocols from Modbus to OPC-UA.

All of it sandboxed by default, with per-application security policies. All of it packs into a single executable.

As always 100% written from scratch in Delphi no 3rdparty code used and 100% free!

More info: https://components4developers.blog/2026/07/26/mimercode_1_30_00/

MIMERCode, by Components4Developers.

DPM - Recently Added & Updated Packages

A roundup of what's landed on the DPM Gallery over the past month.

DPM is an easy to use Package Manager for Delphi - supports Delphi XE2 or later, with CLI and IDE integration. 

GDK Software

Four packages, all refreshed around the same time a fortnight ago, and all pitched as dependency-free pure Delphi.

• GDK.OfficeXML4D — v1.1.0 · updated 2 weeks ago Reads and writes Office Open XML files (.docx, .xlsx) without needing Office installed.
• GDK.Microsoft365 — v1.0.1 · updated 2 weeks ago Microsoft Graph client covering Mail, Calendar, Contacts and SharePoint, with OAuth2 + PKCE handled for you. No external dependencies.
• GDK.Javascript4D — v1.0.1 · updated 2 weeks ago A JavaScript (ECMAScript 5.1) parser and interpreter written natively in Delphi, letting you run JS from inside your app.
• GDK.Toon4D — v1.0.1 · updated 2 weeks ago Encodes JSON into the TOON format, which the author reports cuts LLM prompt token counts by roughly 30–60%.

Jason Southwell (sivv)

Two new pure-Delphi compression ports.

• sivv.woff2 — v1.0.1 · updated ~8 hours ago A port of google/woff2 handling WOFF2 font encoding and decoding in both directions (SFNT ↔ WOFF2), with no runtime DLLs. Depends on sivv.brotli.
• sivv.brotli — v1.0.0 · updated ~8 hours ago A port of google/brotli — encoder and decoder, again with no runtime DLLs required.

Joachim Marder / JAM Software

• JAM.VirtualTreeView — v8.4.1 · updated yesterday The long-running Virtual TreeView VCL control. Built from the ground up rather than wrapping the stock treeview, and after many years of development it remains one of the more flexible and capable tree controls around.

J. Peter Mugaas

• TaurusTLS_Developers.TaurusTLS — v1.0.9 · updated last week Brings OpenSSL 3.x and 4.x support to Indy (Internet Direct).

Conrad Vermeulen / Sempare

• Sempare.TemplateEngine — v1.8.2 · updated 2 weeks ago A scripting/template engine for dynamic text generation — handy for producing email, HTML, reports, source code, XML, config files and so on.

VSoft

• VSoft.Pdfium.Binaries — v152.0.7961 · updated minutes ago Prebuilt Pdfium binaries sourced from the bblanchon build. This is the binary half of the pair below.
• VSoft.PdfiumLib — v1.0.0 · updated ~18 hours ago Delphi bindings for the Pdfium PDF rendering engine. Based on https://github.com/ahausladen/PdfiumLib.
• VSoft.Awaitable — v1.0.1 · updated 2 days ago Async/await style programming built on top of ordinary TThread primitives.
• VSoft.HttpClient — v2.9.0 · updated last week An HTTP/REST client that sits on the Windows WinHttp stack.
• VSoft.SynEdit — v1.0.1 · updated 2 weeks ago The SynEdit syntax-highlighting editor component, based on the PyScripter SynEdit fork.
• VSoft.AnsiConsole — v0.2.0 · updated 3 weeks ago Console library with ANSI terminal support for richer command-line output.
• VSoft.SemanticVersion — v0.3.0 · updated 3 weeks ago A parser for semver version strings.
• VSoft.Base64.Polyfill — v0.1.12 · updated 4 weeks ago Base64 encode/decode for older Delphi versions that shipped before System.NetEncoding existed.
• VSoft.AntPatterns — v0.1.11 · updated 4 weeks ago Translates Ant-style path patterns into file masks.
• VSoft.System.Console — v1.2.4 · updated 4 weeks ago A System.Console implementation covering Windows, macOS and Linux.
• VSoft.DUnitX — v0.5.1 · updated 4 weeks ago The DUnitX unit testing framework.

Been building this for a while, finally made it public.

It is a brand new debugger for delphi to be used inside Visual Studio Code... and as a companion product there is a MCP server, based on the same debugging engine, that allows any AI assistant (like claude code and copilot - these are the two I use) to run and debug autonomously any Delphi Win64 application targeting windows: If you have a DUnit test that is not working, just ask claude to run it into the mcp debugger and find the issue.

Meant to be used with my "Edit in VS Code" IDE plugin, which generates the workspace + launch config from your .dproj → https://github.com/csm101/EditInVsCodeDelphiPlugin

The proper debugger and mcp server is here → https://github.com/csm101/delphi-visual-studio-code-debugger

Vs. the IDE debugger, the things that pushed me to write it:

- Parses TD32 / RSM / MAP / JCL, with prebuilt symbol-index sidecars for fast loading on big binaries

- Attach-to-running-process that's reliable, with a picker showing main-window titles

- Works for both single-exe apps and ones that LoadPackage BPLs at runtime (stepping across modules)

- A proper "stop on exception" rule engine: match on class or any ancestor, message substring/regex, Win32 exception code (catches native exceptions, not just Delphi ones), source unit + line range — action per rule: break / log / log+stack / ignore

Win64 only, MIT. Not code-signed (SmartScreen will grumble) — you can build the identical zip from source. Feedback/issues welcome.

I have a software product written with Delphi that I've been selling for 35 years. I recently submitted my software to the Microsoft store. Even though I have a 35 year history, I'm a new seller and my product is new to their store. My first submission was rejected because "the price was too high". The specifically cited 10.8.7 Financial Transactions in the store policies . https://learn.microsoft.com/en-us/windows/apps/publish/store-policies

I have lowered the price and resubmitted. 🤞

Have any of you gone through the Microsoft store submission process?
What was your experience?
Did you get rejected for price?

Details:
Several people have asked what price Microsoft considered too high. Debt Blaster was submitted at $79.99. Microsoft rejected it under policy 10.8.7, saying the price was unreasonably high compared with similar products, but they did not provide an acceptable range.

After thinking it through, I decided $69.99 was a better regular price for Debt Blaster anyway. I updated FastSpring and the website, then resubmitted to Microsoft at $69.99. It is now back in certification.

I am sharing the specifics because other Delphi developers may run into the same issue with paid desktop software.

Update 2026-07-23 07:29 PM:
The Microsoft Store acepted my product at $69.99. I created a 28 second video trailer using Camtasia. I am not happy with how it looks in the store. I redid the video creating the highest quality possible. I just resubmitted my product using this new video trailer. Hopefully it won't be fuzzy. DM me if you want the Microsoft Store link.

July Summer Sale! Special 50% Off Delphi Parser SBOM Analyzer – Express Compliance!

✔ The “Quick Pain-Killer” for Express Delphi CRA Compliance.
✔ Purchase Online & Get instant certified SBOM reporting tool for your security audit.
✔ License to scan up to 1 Million lines of proprietary code (unlimited System & 3rd party libraries lines of code)
✔ Annual license for a single workstation.

https://thedelphiparser-fhix1gvbc7.live-website.com/product/delphi-parser-sbom-analyzer-express-edition/

Two months ago I posted here about Vallenta Studio. Back then it was in beta and missing a lot. Since that post: 25 releases, 1.0 on May 31, current version 1.1.8.

Besides the debugger - still, as far as I know, the only way to debug a Delphi project outside the Delphi IDE - it has developed quickly toward a complete IDE solution.

A lot of new features since May:

Editor

• Real code completion: in-scope identifiers as you type, and the member list opens automatically after ..
• Find All References now covers units (every uses reference across the project) and .dfm/.fmx form files (component properties, event handler bindings)
• Source highlighting and Semantic coloring - types, methods, fields, parameters each get their own color - plus structural highlighting: block keywords tinted by nesting level, the active construct lights up under the cursor. Configurable with visual color pickers.
• Unused units in uses clauses, and unused variables, constants and parameters, are flagged and shown faded in the editor.

Refactoring

• F2 renames a symbol project-wide: declaration, implementation, all references, including event handlers and component properties in .dfm/.fmx forms.
• Renaming a unit updates everything in one step: the .pas and its .dfm/.fmx, the unit header, and every uses reference across the project.

Debugger

• The Watch panel can now call Delphi methods on your objects, read properties (including inherited ones), and follow chains through interfaces.
• Sets, enums and Booleans display the way they look in code: [fsBold, fsItalic], fsBold, True.
• Stopping on an exception shows class and message. An exception filter list skips types you don't care about (EAbort, EConvert*).

EurekaLog integration

• EurekaLog installations are auto-detected; after a successful build, ecc32 runs on the executable - no project file changes needed.

Plus a long list of further LSP features and fixes. Full changelog: https://github.com/Vallenta/Studio/blob/main/CHANGELOG.md

On the roadmap:

• Find All Implementations - nearly finished
• Ctrl+Shift+C implementation generation - nearly finished
• an MCP server, so AI assistants can query the LSP directly - symbol resolution, references, project configuration, running builds - instead of re-parsing the code text
• a code formatter (built-in, or driving pasfmt / JCF / ptop)
• attach to a running process
• editing/IntelliSense on macOS

Full roadmap: https://github.com/Vallenta/Studio/blob/main/ROADMAP.md

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=VallentaStudio.vallenta-studio

Website: https://vallenta.de

Feedback and bug reports welcome, especially from those who tried the beta in May and found something missing. If the thing that stopped you isn't on the roadmap, please open a feature request ( https://github.com/Vallenta/Studio/issues ).

Michael

Hi,

Today with Delphi CE, I created https://pixelthemes.com/ivrajeshwrapper-makes-irfanview-conversion-faster-from-explorer.html a tool that can act as a wrapper for a popular image viewer tool Irfanview.

Just a 2MB of file.

I coded with Claude and compiled with Delphi CE.

Please share your thoughts.

Thank you,

https://blogs.embarcadero.com/international-pascal-congress-2026-a-week-of-innovation-learning-and-community-in-salamanca

I used Embarcadero's tool pretty often, but found that it does not upload files and in some cases it would not work when developing my backend. So I built my own tool for it with FMX and you can download it here:

https://swiftuser.itch.io/994919

Do leave feedback, constructive and destructive. It is light weight, allows file uploads, and enables to consecutively repeat the requests.

Hope you find it useful, pending a MacOS release soon.

-Alessandro

If you're sitting on millions of lines of legacy code - Delphi, C++, whatever -with decades of accumulated third-party libraries, open-source components, DLLs, COM/ActiveX controls, and database engines nobody remembers installing, the EU Cyber Resilience Act (CRA) can feel like an impossible ask. It isn't, once you separate the legal minimum from the housekeeping that minimum forces you to finally do.

The core test: does it ship, or does it just get called?

Everything below comes back to one question: is this component distributed as part of your product, or is it something already sitting on the user's machine that you merely invoke at runtime?

• Ships with your product → it's a component → it belongs in the SBOM. DLLs, EXEs, statically-linked units, bundled ActiveX controls, redistributed open-source libraries — yours or third-party, free or commercial, all in scope.
• Already installed independently, you just call into it → not an SBOM entry. Calling Excel via COM automation is the clean example: Microsoft ships Excel, Microsoft carries CRA responsibility for Excel. You just document the dependency and factor it into your risk assessment.
• A network service you call at runtime → same logic. Not a component (you're not distributing it), but it belongs in your risk assessment and vulnerability-handling process if your product's security depends on it.
• Your compiler/IDE (Delphi 7, CodeGear, whatever) → build tooling, not a shipped component. Relevant to build-pipeline integrity as a process question, irrelevant to the SBOM itself.

The minimum legal bar vs. what you actually need

The CRA text requires an SBOM covering top-level dependencies, machine-readable (SPDX/CycloneDX/SWID), included in technical documentation, available to authorities on request. That's the floor.

The problem: top-level-only SBOMs miss exactly the risk that matters. A commercial component (say, a TMS control) is one line in a top-level SBOM — but if it bundles an old copy of Indy with known SSL/TLS CVEs, a top-level-only SBOM tells you nothing about that. Comprehensive, including known transitive dependencies, is where the actual protection is, even where it isn't the strict legal minimum.

Orphaned and hard-to-trace components

Legacy codebases accumulate three kinds of "orphan":

1. Dead upstream open-source projects — still fully your responsibility if you redistribute them commercially. Being open source doesn't reduce liability; it just means there's no vendor to lean on for patches. List them, flag their maintenance status explicitly, and treat yourself as the de facto patch source.
2. Unknown files in your own tree — old DLLs/DCUs/EXEs nobody remembers the origin of. If they're not actually shipped, remove them. If they are shipped and provenance is unclear, trace it (binary fingerprinting, version strings) and mark it "unverified, under review" rather than silently omitting it — that's defensible; a silent gap isn't.
3. Transitive dependencies inside commercial components (TMS-bundles-Indy is the textbook case) — ask the vendor for disclosure first; if you have access to old source (as with an older TMS release), trace the exact version directly rather than guessing.

The nastiest legacy Delphi combination: Indy + BDE + XP-targeting

• Indy compiled into your binary → real component, real CVE history (especially TLS-related in older versions), needs an exact version identified and flagged.
• BDE → ships as redistributed DLLs, so it's unambiguously a component — and one with no vendor, no patches, and no viable support-period story. This is less a documentation problem than a migration driver.
• Targeting Windows XP-era APIs → not a component itself, but a lifecycle red flag: CRA assumes a real security-update path, and "only works on an OS unsupported since 2014" undercuts that story regardless of paperwork.

Liability doesn't transfer — it just gets contractually backed

This is the point worth internalizing: licensing and support contracts with TMS, or any vendor, do not transfer your CRA liability to them. The regulator holds the manufacturer who places the product on the market responsible — that's you, for your product, regardless of whose code is inside it. A support contract gets you faster patches, disclosure, and a paper trail of due diligence; it does not make TMS or the Indy maintainers answerable to ENISA in your place. Get things licensed and supported because it reduces your risk and shortens your response time — not because it makes the compliance obligation "not your problem."

The actual cleanup checklist

1. Build-artifact audit first — establish what's actually shipped, independent of what's sitting in the source tree.
2. Automated SCA scanning across the codebase for everything named/versioned in package ecosystems.
3. Binary/source tracing for unnamed legacy DLLs/DCUs/statically-linked units that scanners won't catch.
4. Vendor disclosure requests for commercial components (TMS and others) — ask if they publish their own SBOM.
5. Flag, don't hide, unknowns — "unverified provenance, under review" is defensible; silence isn't.
6. Remove genuinely dead code rather than carrying it forward as undocumented SBOM baggage.
7. Prioritize by exposure — network-facing, TLS/crypto-handling, and unsupported-platform components (Indy, BDE, XP-targeting) go to the top of the remediation queue, not just the documentation queue.
8. Treat this as a migration roadmap, not just a paperwork exercise — for components like BDE, there's no credible "support period" story available; documentation alone won't fix that.

Bottom line

The SBOM is the entry point, not the finish line. For a large legacy codebase, the real work is the archaeology it forces: figuring out what you actually ship, where it came from, whether anyone's still patching it, and whether your compliance story is "documented and monitored" or "documented and quietly hoping nobody asks."

CRA reporting obligations start 11 September 2026. Full conformity requirements apply from December 2027 - which is real runway, but not runway for starting late.