twinBASIC Update: August 4, 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

LLVM Progress Update

It's a bit of a good news/bad news situation this week.

GOOD NEWS: Wayne has LLVM working to the point that it can compile the massive PhotoDemon VB6 codebase:

More details from Wayne:

The main observation is the clean build times. For PhotoDemon:

• 5m20s for an optimized build (-O3), weighing in at 15.7MB exe
• 2m30s for an unoptimized build (-O0) weighing in at 37.5MB exe
• 4s for the current non-LLVM unoptimized build weighing in at 21MB exe

The codegen pipeline is currently single-threaded, so there's much room for improvement here, plus there'll be an LLVM-cache in place so that a full build like this will be rarely needed.

BAD NEWS: The LLVM release date looks to be slipping slightly from the original August 7 planned release date. From Wayne in Discord:

[LLVM support] will likely be a few days delayed. The caching of the optimized codegen is taking a little longer than expected, but it's a worthwhile wait as it makes things much more tolerable.

Discord Chat Summary

^{* Auto-generated via Claude Sonnet 5}

Overview

This week's discussion centered heavily on LLVM compilation performance, with waynephillipsea sharing significant milestones including PhotoDemon successfully compiling under the new LLVM backend. A deep technical discussion emerged around how On Error Resume Next/Resume statements fundamentally limit compiler optimizations, sparking practical workarounds from the community. Additional threads covered Git client preferences, VB6 IDE add-ins, and a brief delay to the anticipated release date.

LLVM Compilation Progress

• waynephillipsea announced PhotoDemon is now fully compiling and running with LLVM, providing benchmark comparisons: 5m20s for optimized (-O3) builds (15.7MB exe), 2m30s for unoptimized (-O0) builds (37.5MB exe), versus 4s for the current non-LLVM build (21MB exe).
• waynephillipsea noted the codegen pipeline is currently single-threaded with room for improvement, and an LLVM cache will reduce how often full rebuilds are needed.
• For comparison, a VB6 build of the same project took roughly 56s-3m20s depending on network drive conditions, per waynephillipsea's testing.
• waynephillipsea confirmed the next release will likely slip a few days past the previously announced August 7 date, citing extra time needed to properly implement optimized codegen caching.

Error Handling & Optimization Tradeoffs

• waynephillipsea explained that On Error Resume Next/Resume statements severely limit LLVM optimizations because every statement becomes a potential jump target, effectively isolating statements from cross-boundary optimizations.
• waynephillipsea clarified that On Error Goto X alone is fine—it's specifically Resume/Resume Next support that causes the optimizer difficulty.
• Community members (deletedewd, dr.bobby) explored workarounds, including substituting Resume Next with explicit GoTo patterns that achieve the same debugging behavior without the optimization penalty.
• yereverluvinunclebert_49972 reported actively removing/replacing On Error Resume Next instances across their codebase in preparation for the optimizer, noting only 12 occurrences needed review.

String & Array Performance Techniques

• waynephillipsea confirmed BSTR string handling is largely unaffected by LLVM since it relies on OS calls, though future optimizations (e.g., batching concatenations) may improve this.
• waynephillipsea noted loop performance can improve significantly under LLVM, especially with array bounds checks and integer overflow checks disabled.
• deletedewd shared a technique for overlaying an integer array on top of a string to perform in-place character replacements (e.g., converting Base64 to Base64Url) without reallocating memory, with accompanying code sample.
• waynephillipsea confirmed that in later tB versions, the compiler will automatically recognize and upgrade inefficient string concatenation patterns without requiring source changes.

Type System & Language Features

• fafalone asked about safety of using property accessors with CType and VarPtr tricks for overlaying types like LARGE_INTEGER; waynephillipsea confirmed this approach should be fine.
• wartale asked whether code has been separated from the project file yet; fafalone clarified this isn't implemented besides packages but remains planned for v1.0, which waynephillipsea confirmed.

Community Tools & Ecosystem

• Discussion of Git GUI client preferences included GitHub Desktop, SourceTree, and TortoiseGit, with bclothier recommending TortoiseGit for its patch feature and transparent command visibility.
• bclothier shared a link to an interactive Git branching tutorial for community members still building their DVCS mental model.
• alpal3478 asked about the VB6IDEFix package for mouse wheel scrolling; datinex_54872 shared an alternative add-in archive.
• kiwichick noted that XYplorer's 64-bit file manager is built on twinBASIC, but HTML scripting doesn't currently work; glevz speculated this fix likely won't land before tB v2.

Conclusion

This week showcased tangible progress on the LLVM backend with a real-world application (PhotoDemon) now compiling successfully, alongside candid discussion of current performance tradeoffs and future optimization plans. The deep dive into Resume statement behavior gave the community actionable guidance for preparing existing codebases ahead of the optimizing compiler's arrival. With a short release delay confirmed for better caching implementation, momentum remains strong as the community continues refining both technical understanding and practical migration strategies.

Around the Web

First Class Support for twinBASIC in KeyNub

From keynub.com:

KeyNub is a next-generation USB-C software license dongle for professional software. Your customers plug in a hardware key; the license cannot be copied, because the private key never leaves the chip. The price works even in small quantities.

The website currently shows only a single product page. And the product itself appears to be pre-launch still. The product page has no pricing information, just a contact form and a one-page PDF spec sheet:

The top right corner of the PDF spec sheet shows that it is revision 1.0 and is dated August 2026:

So why am I telling you all this?

Because twinBASIC is one of the 25 programming languages that KeyNub supports:

There is even a dedicated twinBASIC info page with more than just generic, programming language-agnostic twaddle. Here's an excerpt (understandably, the context is that the twinBASIC support is similar to VB6 with some key differences):

The two differences that matter

Bitness. twinBASIC can build 64-bit, so register the 64-bit KeyNub.dll for a 64-bit build. VB6 is 32-bit only, so a project that targets both needs both registered.

twinBASIC implements CDecl properly. That means you could skip COM and call the flat C API directly with Declare ... CDecl, which VB6 cannot do. The SDK documents that route with its trade-offs: you give up the automatic close on dropped reference, you give up Err.Description, you handle the two-call buffer convention yourself, and the code stops compiling in VB6.

There is a consequence worth knowing if you maintain both: a green twinBASIC build does not prove the VB6 build works, precisely because twinBASIC gets CDecl right where VB6 silently does not. Test the VB6 target in VB6.

The upshot is that an established company (AB Tools GmbH, founded in 1999) launched a new hardware-based software licensing tool aimed at developers and included twinBASIC support as part of their initial launch.

It's not exactly a spot on the TIOBE index, but it is anecdotal evidence that twinBASIC is beginning to establish a foothold as a programming language for serious commercial usage.

DroneAttack: Military Drone Simulation

Posted by Birk in the show-and-tell channel:

I've made a TwinBasic app that simulates piloting 2 military drones. I used Claude to write all the code (well almost all) and that is a story in itself. I've got the code to a point where I'd like some feedback on how well it works and how realistic the simulation is. I'll attach an annotated screenshot of how the app looks now. I'll be happy to share with anyone who's interested the EXE file and a 3-page Word file explaining how the app works - just let me know where to send the files. Thanks.

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.
• The next planned release is LLVM support, now expected "a few days" after August 7.