twinBASIC Update: June 30, 2026

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

Ye Olde Age-Old How's-it-Sold? Licensing Discussion

At some point in the recent past, Wayne started offering a "Personal" license for twinBASIC that sits between the free Community edition and the paid Professional edition.

The Personal edition is just under half the cost of the Professional edition and is aimed at serious hobbyists and project supporters. The Personal edition removes the 5-second splash screen for 64-bit compilation, allows for LLVM-optimized builds (when that feature lands in the near future), but–importantly–does NOT allow for use in commercial projects. That last restriction is notable given that the free Community edition explicitly allows for use in commercial projects.

For details, check out the twinBASIC Licensing page.

And speaking of twinBASIC licensing, that most common of discussion topics made its way into the Discord server yet again this week, with one commenter voicing the concern thusly:

Since VB6 is essentially free while tB isn't, I think it's perfectly reasonable to expect that the migration itself shouldn't be painful.

okaso (lead contributor to the recently overhauled CI/CD pipeline project that is docs.twinbasic.com) pushed back on the statement's premise:

VB6 isn't exactly free, not in real terms. Dealing with the legacy VB6 takes real effort and time. IMHO it's anything but free.

In response, the original poster replied:

I don't think you should have to pay an annual subscription for VB6. Even if you decide to buy it from somewhere instead of using one of the many installer packages available online, it's still a one-time cost rather than a significant recurring yearly subscription.

A different commenter pointed out that the cost of paying ongoing licensing costs for a language typically dwarfs the investment of time made in that language (emphasis added):

If I could have continued to pay MS for VB6, I would have. Anything to keep it going was small potatoes compared to the programmer time we put into the programs we wrote with it. ... The only way to keep the language alive and growing is for its users to support it, one way or another. Personally, I want Wayne to get filthy rich.

But not to worry. Wayne promises not to forget us little folk when the money starts pouring in...

The whole exchange reminded me of my very first public presentation of twinBASIC, when I rolled out this beauty to the Access DevCon Vienna crowd back in 2021:

The above photo was the exclamation point at the end of "My Bold Prediction", which went like this:

My Bold Prediction

• 1999: VBA6 => COM Add-in support
• 2010: VBA7 => 64-bit support
• 2025: VBA8 => twinBASIC

Wayne gets paid

Yes, I predicted that Microsoft would pay Wayne for the rights to twinBASIC and that would become the replacement language for VBA in the Office suite. That was way back when I was naive enough to believe that Microsoft would invest even a single red cent in the VBA ecosystem. As if they would actively undermine their own cloud-first, subscription-everywhere pivot away from desktop applications and developers.

Discord Chat Summary

^{* Auto-generated via Claude Sonnet 5}

Overview

This week's discussion centered on the philosophy of achieving VB6 compatibility, with nolongerset's "asymptotic curve" analogy sparking a thoughtful discussion about why the final stretch toward v1.0 is disproportionately difficult. Community members also debated the subscription pricing model versus VB6's "free" legacy cost, while technical contributors showed off advanced WinDevLib capabilities including WinRT reflection and a kernel-mode ETW driver. Engagement was high throughout the week, mixing serious roadmap concerns with lighthearted banter about monitors and Wayne's hypothetical private island.

VB6 Compatibility & Migration Philosophy

• nolongerset opened the week with a widely-discussed analogy: tB hit 90% VB6 compatibility roughly halfway through development, but "the last 10% is exponentially harder to achieve than the first 90%," while public perception shifts harshly once v1.0 ships and any remaining incompatibility becomes a dealbreaker rather than a "beta" excuse.
• sokinkeso, the addins authority, pushed back on concerns about compatibility, asserting that syntax-level VB6 compatibility is essentially complete and that most projects compile without rewriting.
• ubehage echoed this, noting that syntax compatibility is largely a solved problem and the remaining challenge is behavioral: making programs run "in exactly the same way it did on VB6."
• Wayne Phillips explained that the automatic type conversion handling in the compiler wasn't conceptually difficult, but getting edge cases right—particularly around Declares with implicit ANSI conversions—took significant time; wqweto added that VB6's heavy COM basis let it delegate much of this work to APIs like VariantChangeType.

Licensing & Business Model

• A debate emerged over whether a tB subscription is reasonable compared to VB6's "free" status; fafalone argued the yearly cost is modest next to historically buying successive VB6 editions, and noted Wayne has confirmed licenses will continue to work even without future updates.
• Community members like coachja and lm3548 voiced strong support for paying to sustain development, with coachja framing subscriber support as "the only way to keep the language alive and growing."
• dinyaz offered a more skeptical market view, estimating the addressable VB6 developer base at roughly 378,000 worldwide and arguing that true compatibility plus reasonable pricing could win over that community, but that painful migration costs (e.g., missing standard controls) would be unacceptable given VB6's low up-front cost.
• erice1234 confirmed with fafalone that GitHub release builds of tB are not time-limited, reassuring users considering it for long-term production use.

Feature Development & WinDevLib

• deletedewd demonstrated a proof-of-concept cCallByName class capable of calling WinRT Runtime Class members by string name (similar to VB6's CallByName), later expanding it to walk an object's full interface tree—finding over 500 members on a simple TextBox control.
• fafalone showcased a kernel-mode file-activity ETW tracer built with a tB-authored minifilter driver, solving a real problem where the system's built-in kernel logger often misreports the process ID tied to file events.
• fafalone also pointed users toward the existing ucWebView2 OCX wrapper project for embedding WebView2 controls in VB6 via tB, though he noted it needs updating for current WebView2 versions.
• Ongoing rendering flicker issues were discussed for DirectX/GDI-heavy projects (Desktop Duplication, VBTixyLand); deletedewd suggested replacing the DirectX-to-GDI bitmap pipeline, while fafalone noted the same code runs flicker-free under VB6 p-code, pointing to a tB rendering path issue rather than the sample code itself.

IDE Improvements & Release Timeline

• Wayne Phillips shared a humorous "twinBASIC Command Centre" multi-monitor setup screenshot, drawing strong community reaction.
• fafalone clarified that the optimized 64-bit LLVM compiler is not yet implemented but is Wayne's current focus and expected "any day now," with edition-based options for optimization still to be added.
• In response to concerns about the v1.0 timeline slipping from its original December 2025 target, fafalone acknowledged the delay but defended it: "better to have something solid than something rushed."
• Wayne fixed a reported UI bug where the licensing page's purchase popup on twinbasic.com didn't allow scrolling to reach the submit button.

Community Support & Highlights

• A lengthy thread litigated whether replacing a legacy DBGrid control in a migrated app constitutes a "rewrite"; sokinkeso clarified that swapping one control isn't comparable to rewriting an entire application, and fafalone reinforced that porting to a new language entirely is far more costly than working around tB's remaining beta issues.
• fafalone helped a user (erice1234) considering tB for a VB6-based grid-heavy application, noting most UI issues stem from default visual styles rather than deeper incompatibilities.
• Long-time members shared nostalgic reflections on early BASIC computing (including a Sega SC-3000 photo) and joked about VB6's abandonment timeline, with Wayne noting he still knows a customer even older than the community's self-reported "oldest" member.
• The week closed with lighthearted banter about ultrawide monitors and Wayne's running joke about retiring to a private island, generating some of the highest community reaction counts of the week.

Conclusion

This week balanced philosophical reflection on tB's compatibility journey with tangible technical progress, from WinRT reflection tricks to a genuinely novel kernel-mode ETW tracer built entirely in tB. While the community continues to negotiate expectations around pricing, timelines, and remaining beta rough edges, the tone remained largely optimistic, with contributors like sokinkeso and fafalone reinforcing that tB's VB6 compatibility is fundamentally solid and that its long-term trajectory looks far from a "hobby project." The v1.0 timeline slip drew some frustration, but the broader sentiment favored patience in exchange for a more polished release.

Around the Web

A Better ProcMon?

fafalone dropped this teaser in the Discord chat:

Sneak preview of a project i've been working on...

Appears to be an event tracer for file activity right... well surely my existing one is much nicer, so what's the deal?

This project comes with an event provider that's running from a kernel mode filter driver.

It's an actual useful project, not just a proof of concept. From kernel mode we can get better info, the system kernel logger so often provides the wrong process ID linked to a file. This solves the problem.

I don't know much about the internals of ProcMon, but somehow I doubt it's incorporating a [...checks notes...] kernel mode filter driver in its implementation.

Leave it to fafalone...

Changelog

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

Releases · WaynePhillipsEA/twinbasic

Contribute to WaynePhillipsEA/twinbasic development by creating an account on GitHub.

GitHubWaynePhillipsEA

• No new releases this week.