twinBASIC Update: September 8, 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

Major Reductions in IDE Memory Usage and Leaks...

From Wayne in Discord on September 2 (emphasis added):

A little progress update: BETA 874 will bring major reductions in IDE memory usage, especially on the 32-bit compiler where large projects can be challenging to run. Expect overall IDE/compiler RAM usage to drop by roughly 20–25%. More importantly, everyday code editing now has virtually no memory leaks. Memory usage will still fluctuate significantly because partial recompiling isn’t active yet, but it now remains far more stable during longer editing sessions.

...Delayed Only a Few More Days

And about 24 hours later:

Sorry, everyone - the release tentatively scheduled for [September 4] has been delayed by a few more days.

The codebase has undergone significant structural changes, and I’m not comfortable releasing until we’ve completed a much deeper, more comprehensive round of validation than our normal release testing. I want to be confident this is a solid release.

Thanks for your patience! It will be worth the wait.

Discord Chat Summary

^{* Auto-generated via Claude Sonnet 5}

This week centered heavily around performance improvements ahead of a major beta release, along with an active debate about WinDevLib's growing API footprint and its impact on project load times. Community members also spent considerable time troubleshooting IntelliSense quirks, Unicode/ANSI declaration mismatches, and IDE terminate failures while migrating VB6 projects to twinBASIC. Engagement remained strong, with waynephillipsea's development updates driving the most enthusiastic community response.

IDE Performance & Release Timeline

• waynephillipsea announced that the upcoming beta build will bring major reductions in IDE memory usage, especially on the 32-bit compiler, with overall RAM usage expected to drop 20-25% and everyday code editing showing virtually no memory leaks (though usage will still fluctuate until partial recompiling is active).
• The originally scheduled release was delayed by several days; waynephillipsea explained that significant structural changes to the codebase required a deeper validation pass before shipping, emphasizing he wants to be confident in a solid release.
• Community members largely supported the delay, favoring stability over a rushed release, though some jokingly lobbied for an immediate ship date.

WinDevLib Expansion & Optimization Debate

• fafalone noted that only about 10% of the platform SDK is currently covered in WinDevLib, with recent additions focusing on legacy telephony/RAS APIs that include thousands of lines of Windows-version-gated declarations.
• fafalone described his workflow for adding new APIs: custom string-parsing tools for constants/enums/structs, combined with AI (primarily Claude) for declares and interfaces, each manually verified due to recurring AI mistakes.
• Concerns were raised about project load/restart performance as WinDevLib grows; suggestions included conditional compilation flags to strip exotic APIs, or splitting into a "Lite" core library versus an "Exotica" package for rarely-used definitions.
• fafalone confirmed project-setting compilation constants don't yet apply to packages, but extending that support is planned, alongside longer-term namespace support post-1.0.

Bug Reports & Troubleshooting

• yereverluvinunclebert reported intermittent Terminate button failures; waynephillipsea helped diagnose the issue as a mismatch in elevation levels between the tB IDE and an already-running VB6-launched executable.
• A misleading IntelliSense tooltip ("This variable was generated due to option explicit being off") was traced to unrelated LLVM-assembly-view messaging, appearing even with Option Explicit correctly enabled; deletedewd confirmed it's reproducible and likely a benign bug worth reporting.
• Migrating an ANSI GetPrivateProfileString declaration to WinDevLib's Unicode (DeclareWide) version caused runtime mismatches; fafalone advised explicitly calling the ANSI-suffixed version (GetPrivateProfileStringA) as a workaround.
• twixydon reported recurring "ghost" duplicate modules appearing in the module list during VB6-to-tB code migration; deletedewd suggested switching from imported .bas modules to native twin modules to avoid the issue.

COM/Registry Internals & Development Clarifications

• bclothier asked whether classes without an explicit IID or CLSID get a new ID generated on every build; waynephillipsea confirmed that CLSID, IID, and event IID are all auto-generated unless explicitly set.
• bclothier noted this behavior may be leaving orphaned registry entries for older projects lacking those attributes, suggesting a diagnostic warning could help developers catch this proactively.

Community Support

• fafalone advised isrealmatthew that duplicating forms requires updating the FormDesignerId property and matching class attribute to avoid loading the original form by mistake.
• timbald asked for clarification on ADO support scope; fafalone confirmed it matches the ADO support in the intrinsic Data control (toolbox), while external ADO library references not using the Data control should already function independently.

Conclusion

The week's biggest news was the promised memory and stability improvements coming in the next beta, tempered by a short release delay for extra validation—a tradeoff the community broadly welcomed. Parallel discussions about WinDevLib's long-term scalability highlight growing pains as the library matures toward broader Windows API coverage, with namespace support flagged as a key post-1.0 goal. Meanwhile, hands-on migration troubleshooting from active VB6 conversions continues to surface useful edge-case bugs, reinforcing the value of real-world testing as twinBASIC approaches a more mature release.

Around the Web

Calm Before the Storm

An eerie quiet settled over the twinBASIC community as the LLVM release approached.

The virtual windows had been boarded up; the electronic sandbags filled. With preparations complete, developers could do nothing but wait for LLVM to make landfall.

So complete was their readiness, so disciplined their radio silence, that, to the untrained eye, it was indistinguishable from absolutely nothing happening.

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.
• Expect the next release any day now. Per Wayne Phillips on 2026-09-03, "the release tentatively scheduled for tomorrow has been delayed by a few more days."