twinBASIC Update: September 15, 2026

Highlights include a peek behind the scenes at Wayne's workflow as the LLVM release sees its shadow once more.

Mike Wolfe

Sep 15, 2026 • 8 min read

On April 23, 2021, I helped Wayne Phillips introduce the world to twinBASIC at the Access DevCon Vienna conference. I boldly predicted that twinBASIC (along with the Monaco editor) would replace VBA and its outdated development environment by 2025. (And I was oh so close...) With that goal in mind, this weekly update is my attempt to keep the project fresh in the minds of the VBA development community.

Every ~~Sunday~~ ~~Monday~~ week, I will be providing updates on the status of the project, linking to new articles discussing twinBASIC, and generally trying to increase engagement with the project. If you come across items that should be included here, please leave a comment below.

Here are some links to get involved with the project:

Custom twinBASIC IDE Installation Guide
twinBASIC Discord Server (chat about the project)
twinBASIC Documentation (list of new features not in VBx)
GitHub Issue Tracker (report bugs)

Highlights

Behind the Scenes: Local AI Auditor

As programmers increasingly integrate AI into their daily workflows, Wayne has taken a more measured approach.

To be clear, I'm basing these insights on what Wayne has shared publicly, mainly on the twinBASIC Discord server. So some of this is inference on my part. And if you work with AI these days, you know that usually inference comes with a healthy dose of confident hallucination. I expect my insights will be no different.

With that said, here's exactly how Wayne is working with AI these days:

No cloud-based AI has ever seen any part of the twinBASIC compiler's codebase.
No cloud-based AI will ever see any part of the twinBASIC compiler's codebase.
Wayne has made moderate investments in hardware to run local AI models (I say "moderate" here because you can spend STUPID amounts of money for a good local AI setup).
That hardware executes long-running (and slow) automated auditing tests of the codebase, looking for bugs, logging them, and--in some cases--offering potential solutions.
Wayne reviews the bug reports, confirms or dismisses them, reviews the proposed fix and/or writes the fix by hand, and submits the fix to the codebase.
The local AI auditor reviews the fix and marks the issue resolved.

Those local AI models are not rivaling the speed and capability of the latest state-of-the-art (SotA) models from frontier labs. But what they lack in speed and capability they more than make up for in privacy and efficiency.

Here's Wayne in the ai-talk channel:

"...we've now got a 256GB unified VRAM system. Honestly, it's amazing. Being able to run DeepSeek V4 Flash 0731 at full 1 million context is exactly what we needed to parse the full tB C++ codebase, and include cross referencing all the tB packages, bug reports, and much more. We're not using it to do any code changes, but as an continuous autonomous auditor it's really proving itself. They are not speedy. That's not what they're good for. What they are really, really good for things you can leave running 24/7 that don't need instant results - they're also very efficient for this purpose (vs a high spec GPU) ."

A reader mentioned that he couldn't justify such a large investment when current subscriptions provide more value (mostly via heavy subsidization from AI companies trying to secure market share):

"I'd struggle to justify the cost of a rig powerful enough to do decent local inference - I've got the Claude Max 20x sub (£200/month) and never ever hit limits, despite some huge workflows that can eat 10 million tokens at a time."

Wayne acknowledged the tradeoff:

"For this use case, anything cloud based is out of the question. Yes they are expensive, but they're going to essentially be doing the job of another employee... Like an intern: keen to learn and happy to work 24 hours a day. Makes some mistakes, but provided you've got guardrails in place, it's manageable (just like an employee). From a business perspective, it makes absolute sense, for us."

But noted the value is definitely there:

"Our AI auditor has been running for a full week now 24/7.... 254 findings reports so far. 20 since disproved, 98 fully resolved, 45 awaiting resolved verification, 20 currently being worked on by me, 71 remaining. Of the 71 remaining, most are just extreme edge case hardening and or documentation inaccuracies that can wait. All in all, our AI auditor is working very well indeed!"

Discord Chat Summary

^{* Auto-generated via Claude Sonnet 5}

Overview

This week's general channel discussion centered heavily on the philosophy and timeline of the v1 release, with waynephillipsea offering extended commentary on why twinBASIC targets near-100% VB6 compatibility rather than settling for an early, narrowly-scoped release. Alongside this philosophical debate, the community tackled several concrete technical issues, including a rendering "white flash" bug report, SQLite static-linking limitations, and some deep dives into tB's robust keyword/identifier parsing. Engagement remained strong throughout the week, spanning both serious technical discussion and lighter community banter.

v1 Release Philosophy & VB6 Compatibility

waynephillipsea reaffirmed the project's direction: "Nothing has changed with regards to that direction. We are still aiming for 100% backward compatibility, and I have no doubts we'll eventually get there."
He explained the reasoning for not narrowing scope to pure VB6 parity: "If we were only aiming for exact parity with VB6, and nothing else, then what would be the point of the project, since VB6 still works?"
Wayne set expectations for v1: "The reality is we'll probably get to 99% compat in v1. And then the remaining 1% over the next decade, as the real edge cases appear," adding that reported bugs will continue to be fixed post-release.
Community members debated whether a narrower "VB6-only" v1 could have shipped sooner, but general consensus (echoed by ubehage and bclothier) was that perfecting compatibility while building new features simultaneously is more efficient than trying to bolt on modernization later.

Rendering & Bug Reports

twixydon reported a "white flash" rendering issue where controls with an hWnd briefly render as blank white rectangles during form load, especially noticeable on forms with many controls, and shared a minimal repro project.
The issue remains open for investigation as tB continues refining its rendering pipeline ahead of v1.

SQLite & Static Library Integration

yereverluvinunclebert asked about sourcing 64-bit/32-bit SQLite .obj files for static import testing; krool5045 clarified the experimental package already includes a 64-bit .obj, though it has a known issue.
A brief mix-up over SQLite versioning was resolved: krool5045 confirmed the experimental package uses SQLite 3.53.4, the current release, not the older 3.29 initially referenced by glevz.
A key current limitation was noted: the IMPORT statement and static object linking only work within the .twinproj/.twin file structure — external OBJ references outside the project aren't yet supported, something users are looking forward to seeing addressed by v1.

Language Syntax & Parser Robustness

Discussion around square-bracket ([ ]) syntax highlighted several under-documented uses in tB/VB-style code: escaping keywords as identifiers, defining empty/space-containing enum members, and referencing hidden interface methods (e.g., obj.[_NewEnum]).
wqweto demonstrated tB's parser is notably more context-aware than legacy VB, showing a working example where If, Debug, and Print are all reused as identifiers without conflict — behavior that would break in VB6.
fafalone and bclothier noted that while tB handles keyword-as-identifier usage gracefully (useful when matching SDK field names exactly), this was historically inconsistent and error-prone in classic VB.

UserControls & Third-Party Component Ecosystem

waynephillipsea confirmed Property Pages are supported for custom UserControls, though he cautioned this likely won't resolve transparency issues with PNG-based Picture properties, which require windowless controls — an area with some current limitations.
braja_07733 expressed interest in tB eventually supporting native, non-ActiveX packages for commercial third-party components; fafalone noted this is possible today via open-source packages or standard DLLs (as Windows does with common controls), with Wayne having mentioned compiled packages as a potential future feature.

Conclusion

The week's conversations reflect a community balancing patience with anticipation as v1 approaches, with waynephillipsea reinforcing that full backward compatibility remains the north star even as the timeline stays flexible. Parallel technical progress continues on rendering fidelity, static library integration, and parser robustness, while forward-looking discussions about a native package ecosystem hint at tB's ambitions beyond simple VB6 parity. Overall, the tone remains supportive and forward-momentum focused, with contributors actively surfacing edge cases to help sharpen the path to a stable v1 release.

Around the Web

WinDevLib Bug Fix for Direct 2D Crash

Posted by fafalone in the WinDevLib Updates channel:

Direct 2D Crashing If your app uses Direct2D and has been crashing on startup with no apparent cause in recent WDL versions, please update to the latest version.

General crash on startup There's a major current bug where any code reference to a function returning an alias of an alias causes a crash on startup (even if the function isn't called). D2D1_COLOR_F was the major one that's now been fixed (by making it a single-level alias), but I haven't yet searched for others. If you're experiencing crashes on startup when using WDL, look for an alias-of-alias and let me know, I'll get an immediate fix out.

Example of cause:
Public Alias D2D_COLOR_F As D3DCOLORVALUE 'D3DCOLORVALUE is a standard Public Type. Public Alias D2D1_COLOR_F As D2D_COLOR_F 'Alias-of-alias: Any code calling a function returning this would crash on startup.

Another AI-Based Business Mentions twinBASIC Support

I will make no comment on the claims made by the above website. And–to be abundantly clear–my linking to it from this page is by no means an endorsement (for all I know, it's a full-blown scam–though the terms require you to warrant you own the software in question, which is a good sign it's legitimate).

Scam or not, there is market signal in the fact that the service lists twinBASIC among the project types it claims to be able to recover:

We decompile compiled Visual Basic programs back into editable source code — rebuilt as a real project you can open, fix and ship again. Our specialty is native-compiled VB6, the hardest case in the business. We also handle VB1 to VB6 Native/P‑Code 16‑bit/32‑bit, .NET, QuickBASIC 4.5 and twinBASIC.

Beyond that, it includes a dedicated twinBASIC sample page with original vs. recovered source code:

A twinBASIC EXE has no VB header, no P-Code, no VB runtime import — it is native x86 with the runtime statically linked in. But the compiler leaves its own metadata in the image, so forms, controls, menus, procedures — and even parameter names — come back exactly as written.

Changelog

Here are the updates from the past week. You can also find this information by visiting the GitHub twinBASIC Releases page.

Nothing new this week.
Yes, it's been a while.
Wayne is aware 😂: