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.

I am a software architect based in Italy since 1993. I cut my teeth on the golden age of Delphi, working extensively from Delphi 1 all the way to version 6. Life and career took me to other fields for a while, but recently, I came back home: between 2023 and 2024, I spent a solid year working heavily on Delphi Alexandria 11.1. I love this ecosystem.

But right now, I am not coding. I am fighting for my physical survival. For over 20 years, alongside my job, I have been fighting a massive battle against systemic bureaucratic injustice and institutional corruption in Italy.

On March 17, 2026, I officially filed a 201-page application to the European Court of Human Rights (ECtHR) against the Italian State. Since that international filing, the local retaliation has been absolute. I have been completely isolated. They are essentially trying to silence me through starvation. Today, I have no income. I have a temporary roof over my head only because I cook and clean the apartment for the owner in exchange for a bed. But I have run out of resources to buy daily food.

I am reaching out to the global tech community because I am completely alone in my home country (Italy). Here is what I am looking for:

1. A Remote Delphi Job: I am a skilled dev, I know Alexandria 11.1, and I work well remotely. I just want to earn my living with dignity and get out of this engineered poverty. If your company needs a remote Delphi developer, please give me a chance.
2. Media/NGO Connections: If any of you have connections to international investigative journalists or human rights NGOs, please point them to my case. The complete, documented 20-year timeline is available at my reddit profile info.
3. *Immediate Survival: Because I need to eat today while I look for a job or wait for the Court, I was forced to open a temp GoFundMe some days ago.

Best,

Thank you for reading this. I’m 57 today. Over the years, I’ve started seeing fellow programmers pass away, while against all odds, Delphi is still alive and well. If Delphi refuses to die, so do I. Keep coding, and don't take your freedom for granted.

July Summer Sale! Special Starters editon for Delphi Parser SBOM Analyzer 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)
✔ 30-Days license for a single workstation.

✔100% Upgrade Credit for Annual License.

https://thedelphiparser-fhix1gvbc7.live-website.com/product/delphi-parser-sbom-analyzer-starter-compliance-1-million-lines-30-days/

🏛️ For years, there’s been a bizarre kind of "shame" in the enterprise software world around Delphi. Companies running massive, highly profitable, and rock-solid systems (especially in Retail POS, ERP, and Banking) often hid their code stack under the rug to look more "modern" to investors and new hire.

🏛️ But the European Cyber Resilience Act (CRA) and DORA are about to change the game entirely.

🏛️ You can’t hide a monolith when the regulator demands a comprehensive SBOM (Software Bill of Materials).

🏛️ Pretty soon, Europe is going to experience the biggest outing of Delphi-based applications in history. As Billions of lines of code get scanned and mapped, regulatory desks will be absolutely flooded with SBOMs proudly displaying legacy Delphi framework, legacy VCL components, BPLs, and legacy 3rd party libraries that have been quietly running the backbone of the economy since 1995...

🏛️ The regulator won't be able to stop it. They’ll just have to look at the sheer volume of the market and say: "OK, I get it. It works, it's alive, just scan your code and hand me the SBOM report (I will file it somewhere...) - and BTW make sure it's secure."

🏛️ It's time for Delphi developers to step out of the shadows. The "FDA of software" isn't killing legacy tech - it's giving it a passport to the modern regulatory compliance era.

Cheer up! The CRA & DORA are the best news for the Delphi community that ever happened.

Full sources, using TeeChart, TeeGrid and accurate algorithms

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/

Time is Running out... New CRA & SBOM Reporting obligations start 11 September 2026. Worth starting now, to be ready on time, but do you really know what SBOM for legacy Delphi codebase means?

Don't worry, it is simpler than it looks...

Delphi is the Best. But let’s be honest for a second. Most of us chose Delphi because it’s a tank. It’s compiled, it’s fast, and we have legacy codebases that have been running critical systems for 10, 20, or even 30 years without breaking a sweat.

Those were the good old days...most of us are still stuck in the 2000's but it's time to wake up, and move on to the new era in software developement.

As of 2026 - a massive storm is hitting the software industry right now, and its name is the Cyber Resilience Act (CRA).

If you are selling software or systems into the EU (or dealing with enterprise clients globally who do), you’re probably getting frantic emails from your compliance officers or CISOs asking for one thing: An SBOM (Software Bill of Materials).

Here is the terrifying truth about the unknown: The auditors don't care that your app is built on Delphi. They want a standard CycloneDX SBOM mapping out every single 3rd-party library, wrapper, and dependency in your ecosystem. And if you try to run standard modern scanning tools (the ones built for Node.js or Python) on a 20-year-old Delphi matrix with custom .bpl structures, third-party libraries like JEDI, Spring4D, or madExcept—those tools will either crash, freeze, or output useless garbage.

You literally cannot afford to get locked out of the market or face massive regulatory fines because of a compliance blind spot.

If you’ve been losing sleep over this, wondering how you're going to manually map millions of lines of Delphi code before the axe falls — there is a very quick painkiller.

The new Delphi Code Analyzer v3.0 was built specifically for this headless, complex task.

• 100% Air-Gapped & Local: It runs on your own machines (no sending your proprietary code to some sketchy cloud).
• Ultra-Fast Quick Scan: Heavy RAM and CPU optimizations in v3.0 mean you can scan massive codebases in minutes, not hours.
• Zero Integration Headache: Built to drop directly into your CI/CD pipelines (like FinalBuilder, Continua, Jenkins) as a silent CLI.
• Compliant Outputs: Instantly spits out the exact CycloneDX JSON audit reports the regulators are demanding.

Stop trying to hack together manual spreadsheets or hoping the auditors won't notice your Delphi legacy core. They will.

Get the tool, run the scan, hand them the SBOM, and go back to sleep.

Download free Delphi SBOM Generator: https://thedelphiparser-fhix1gvbc7.live-website.com/product/delphi-parser-sbom-analyzer-free-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://blog.marcocantu.com/blog/2026-july-kai-updates.html

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.

https://blog.synopse.info/?post/2026/07/06/Object-Pascal-Is-Still-a-Serious-Contender-for-High-Performance-REST-Servers

Hey everyone,

With the upcomin CRA regulation & SBOM requirement, I have been running the latest Delphi Code Analyzer on a very large legacy Delphi code, and we were puzzled.

I’ve been doing an architectural audit on a massive enterprise system lately - millions of lines of code, decades of history, heavily relying on old 3rd-party components and compiled binary files, with customized system files, as well as 3rd-party components.

The project compiles perfectly, the IDE is happy, and the system runs. But the deeper I look into the dependencies and unmapped binaries, the more I get this creeping, uneasy feeling: We don't actually know everything that is running behind the code.

It looks like the customized system files & other 3rd-party source files, although been changed, doesn't compile, as well as having syntax errors - that shouldn't or wouldn't compile!

It feels like working on read-only system & library files...

Do you also deal with old compiled DCU files, DLLs, BPLs, where you have the original source code, but you afraid to touch it, because it is unsupported for more than 20+ years - you realize you're deploying a black box to production.

Do you also share this feeling?

https://holgerscode.com/blog/2026-07-06

Hi,

I was curious to see if anyone has used PaddleOCR with Delphi that is deployable on dekstop and mobile. I saw the video of using PyTorch on Android, but there was a server developed for training the model and I was looking to use an existing model instead just for OCR with Paddle as opposed to the Tessaract?

Thank you!

https://blogs.embarcadero.com/kai-1-0-1-is-now-available/