twinBASIC Update: August 11, 2026
Highlights include a progress update on LLVM implementation along with tB drop-in replacements for the VBScript.RegExp and Scripting.FSO libraries.
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 Development Hits a Performance Snag
If you've been following along with my twinBASIC weekly updates, you already know that the big LLVM Beta release was originally scheduled for August 7, though it was later delayed for "a few days" past that date.
Based on this comment from Wayne this past week, I wouldn't be surprised if a few days turns into a week or more.
Huge monolithic procedures are causing LLVM some bother. I'm encountering some 5000+ line length procedures that are each taking over 15mins to compile (and using gigabytes of RAM to do so). The good news is that the compilation does eventually complete, and it does then get cached... but wow this is much longer than I expected. Some work will likely be needed to make our output easier for LLVM to digest. We're currently still using LLVM16, so we could potentially upgrade to see if that helps.
That doesn't sound like fun.
Brief check-in on Wayne's subconscious right now (probably):
Write a programming language, they said. It'll be fun, they said. Make it 100% backwards compatible with an existing language so you don't even have to make decisions about the syntax, they said. Optimize the compiled executables using the same open-source compiler project that major programming languages like Rust and Swift use because how hard can it be, really, if niche software organizations like Google and Apple have the resources to make it work, they said.
How Wayne has managed to maintain his sanity throughout this project I will never know.
Discord Chat Summary
* Auto-generated via Claude Sonnet 5
Overview
This week's discussion centered heavily on LLVM compiler performance, with waynephillipsea flagging significant slowdowns on monolithic procedures, alongside a cluster of confirmed bugs spanning UDT properties, environment variable handling, and form designer ID management. Serial communication emerged as a major community topic, driven by legacy MSComm32 limitations and a standout real-world throughput win using tB's native file system approach. Engagement remained strong across technical debugging, async/threading design discussions, and lighter community exchanges.
LLVM Compiler Performance
- waynephillipsea reported that 5000+ line procedures are causing severe LLVM compilation slowdowns — over 15 minutes and multiple gigabytes of RAM per procedure — though compilation does eventually succeed and gets cached; the team is still on LLVM16 and may evaluate an upgrade.
- bclothier suggested such oversized procedures represent an opportunity for developers to refactor into modules for better scoping and maintainability.
- waynephillipsea clarified the LLVM DLLs are compiler-only dependencies (23MB 32-bit / 28MB 64-bit), not required at runtime, keeping tB in the "portable" category without needing an installer.
Bug Fixes
- waynephillipsea confirmed a bug where
Tag(0)is unrecognized when usingReDiminside a UDT Property Get, despite working correctly in a Class. - waynephillipsea confirmed that
Environ$("COMSPEC")crashes the IDE and silently kills the compiled EXE once more than 255 environment variables are present; twixydon worked around it using direct API calls, and fafalone noted Environ$ is expected to be Unicode-safe in tB. - fafalone detailed a FormDesignerId bug: duplicate IDs across
.tbformfiles produce no compile error but silently cause only one form to ever load. The correct fix is to duplicate the form, assign a new GUID to both the.tbformand the[FormDesignerId()]attribute in code, then restart the compiler (not the full IDE). - fafalone noted that dynamically adding ActiveX controls (e.g., WebBrowser) currently requires at least one static instance already on the form; this is expected to be resolved by v1.0.
Serial Communication
- Extended discussion on legacy MSComm32.ocx limitations kicked off after erice1234 shared official and archived download links; wqweto pointed out MSComm32 cannot open COM10 and beyond, a major limitation with modern USB-to-serial adapters.
- fafalone confirmed TBComm is largely functional, though replicating VB6's ability to modify buffer size/contents mid-operation remains an open gap due to lack of test hardware.
- deletedewd repeatedly recommended the WinRT
Windows.Devices.SerialCommunicationnamespace (SerialDevice, DataReader, DataWriter) as a modern, dependency-free alternative already usable in tB. - jimdrew shared a standout real-world result: switching from MSComm32 to tB's native file system/console approach for serial I/O let him hit 4Mb/s throughput, a first for his projects.
Async & Threading Patterns
- yereverluvinunclebert_49972 asked about the multi-threading syntax roadmap; fafalone confirmed no formal proposals currently exist.
- fafalone outlined an interim non-blocking pattern using
RegNotifyChangeKeyValuecombined with a timer pollingWaitForSingleObject(hEvent, 0). - deletedewd offered an alternative via the RT
SignalNotifierStatics.AttachToEventobject, which triggers a callback on signaled events without any polling loop. - The group also compared this to JavaScript/TypeScript's single-threaded async/await event-loop model as a possible reference point for future tB async design.
Community & Roadmap
- waynephillipsea reaffirmed that the v1.0 release target remains "this year" in response to a community timeline question.
- fafalone highlighted a community blog feature on KeyNub, an upcoming hardware project with first-class twinBASIC support, plus a military drone simulation app built in tB.
- glevz worked through FormDesignerId duplication issues from mass form-copying, ultimately guided by fafalone toward proper unique-GUID practices.
- Lighter moments included twixydon's hand-painted WinUI 3-style interface experiment and a nostalgic revisit of VB6's 255-controls-per-form limit.
Conclusion
The week highlighted both the growing pains and growing polish of twinBASIC's LLVM backend, with performance tuning on large procedures identified as a key area for future optimization. Several long-standing bugs around UDTs, environment variables, and form designer management were confirmed and clarified, reinforcing active maintenance ahead of the v1.0 target reaffirmed by waynephillipsea. Meanwhile, the serial communication conversation and jimdrew's real-world throughput results underscored tB's growing practical viability for hardware-facing applications, rounding out a technically rich and highly engaged week.
Around the Web
VBScript RegExp Drop-in Replacement
Posted by GCUser99 in show-and-tell:
Until we get a native replacement - wraps sihlfall's pure-VBA regular expressions engine (https://github.com/sihlfall/vba-regex).
100% backward compatible with (now deprecated) VBScript version plus a few new features/capabilities.
It's currently available from the twinBASIC package server - look for "Regular Expressions Object - Replacement for VBScript.RegExp".
Details can be found here: https://github.com/GCuser99/tbRegExp
GCuser99
Modern replacement for Scripting.FSO
Posted by GCUser99 in show-and-tell:
Near-backward compatibility withScripting.FileSystemObjectwith many new features - auto-encoding detection beyond Scripting.FSO's UTF-16/ANSI being one of the most important.
Available from the twinBASIC Package Server (File System Tools - Modern Replacement for FSO).
More info here: https://github.com/GCuser99/tbFileSysTools
GCuser99A twinproj/twinpack (un)packing tool
Posted by GCUser99 in show-and-tell:
.Based on twinBASIC's Import/Export tool (https://docs.twinbasic.com/Features/Packages/Import-Export-Tool).
Unpack .twinproj/twinpack files into text file directory tree, optionally modify, and then pack back into .twinproj/twinpack files. Useful for GitHub version control and code-management automation from the twinBASIC IDE. I used this to generate multiple twinBASIC projects of different types from a single development copy. For an example see: https://github.com/GCuser99/tbFileSysTools
Available in twinBASIC's Package Server as "Project (Un)Packer for .twinproj and .twinpack Files".
For more info see: https://github.com/GCuser99/tbProjPacker
GCuser99Changelog
Here are the updates from the past week. You can also find this information by visiting the GitHub twinBASIC Releases page.
WaynePhillipsEA- No new releases this week.
- The next planned release is LLVM support, likely stalled while Wayne works through performance issues on very large procedures (see dedicated section above).
