twinBASIC Update: October 21, 2025

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. 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 Wiki (list of new features not in VBx)
• GitHub Issue Tracker (report bugs)
• twinBASIC/VBx LinkedIn Group

Highlights

PtrSafe Keyword Made Optional

BETA 894 included the following change:

changed: error missing PtrSafe [TB5129] to a warning [TB0029], defaulting to IGNORE state [ wqweto, discord ]

This simple note belied the intense debate that preceded the change. Here's an AI summary of the debate, along with the eventual outcome:

^{Generated by Claude-Sonnet-4.5}

wqweto initiated a lengthy discussion requesting that twinBASIC support VB6-style Declare statements without the PtrSafe keyword for x64 targets.

His use case: maintaining a single codebase that compiles in both VB6 (using the Enum LongPtr hack) and twinBASIC x64 without duplicating hundreds of API declarations. The current requirement forced him to maintain separate PtrSafe and non-PtrSafe versions of every declare, differing only by that single keyword.

The community engaged in vigorous debate over competing priorities:

VBA7 Compatibility Advocates (fafalone, waynephillipsea) argued that:

• PtrSafe serves as a signal that developers must consider x64 compatibility
• twinBASIC should follow VBA7x64 standards for cross-compatibility
• The keyword helps prevent blindly copying 32-bit declares to 64-bit projects
• A simple find/replace operation makes duplication trivial

VB6 Forward Compatibility Advocates (wqweto, eduardovb) countered that:

• PtrSafe is "useless ceremony" that doesn't actually validate pointer safety
• VB6's codebase likely exceeds VBA7's, making VB6 compatibility valuable
• The restriction is an "artificial limitation" since LongPtr already works in old-style declares
• Reducing friction helps VB6 developers migrate to twinBASIC

bclothier provided crucial middle ground, noting that VBA7 actually does support LongPtr in non-PtrSafe declares for 32-bit mode, and that the real migration challenge is converting Long to LongPtr for pointer types—something PtrSafe doesn't help with anyway.

The discussion reached a turning point when wqweto offered to purchase a VIP Gold Lifetime License to sponsor the feature. waynephillipsea acknowledged that while the change didn't fully align with current direction, it "wouldn't be considerably detrimental" and agreed to implement it.

The result: BETA 894 downgraded missing PtrSafe from a hard error (TB5129) to a warning (TB0029) with default IGNORE state. This means:

• Developers can now use VB6-style declares in x64 projects without modification
• Those wanting VBA7 compatibility can still use PtrSafe (and should)
• The warning can be enabled for projects that need strict VBA7 compliance
• For most users, the impact is negligible—modern code should use PtrSafe anyway, and the change primarily benefits the niche case of maintaining shared VB6/twinBASIC codebases

The discussion exemplified the twinBASIC community's thoughtful approach to balancing competing compatibility goals, with wqweto's willingness to financially support the feature demonstrating the real-world value of reduced migration friction for VB6 developers.

NOTE: For what it's worth, I come down on the side of the "VBA7 Compatibility Advocates". I think the PtrSafe keyword plays an important role in conveying semantic meaning (i.e., as a signal that's meant to say, "I have reviewed this code for 64-bit compatibility and can confirm that any required adjustments from Long to LongPtr have been made). That said, I sympathize with the "VB6 Forward Compatibility Advocates" who rightly point out that large classes of developers "converted" their 32-bit only code to 64-bit by simply doing a find on every Declare keyword in an API declare and replacing it with Declare PtrSafe. If you don't know why that won't work, check out the deep dive I wrote on converting from 32-bit VBA to 64-bit VBA:

32-bit vs. 64-bit VBA: Deep Dive

A deep dive into the past, present, and future of the transition from 32-bit VBA to 64-bit VBA.

No Longer SetMike Wolfe

Discord Chat Summary

^{* Auto-generated via Claude-Sonnet-4.5}

Overview

This week's discussions centered on VB6 legacy and community nostalgia, with members exploring the original VB6 development team and debating IDE user experience improvements. Significant conversations emerged around warning message handling, diagnostic panel visibility, and how to make twinBASIC more approachable for newcomers while maintaining power-user features. The community also tackled practical implementation questions around COM ports, package diagnostics, and antivirus false positives.

VB6 Legacy & Community History

• Community members investigated the original VB6 development team, discovering easter eggs containing developer credits and MIDI files in VB6.EXE
• waynephillipsea noted potential VB6 developer lurkers in the Discord community, expressing interest in connecting with original team members for insights
• Discussion highlighted concerns about the future of Win32 development expertise, with younger developers largely avoiding legacy Windows technologies
• Members debated Microsoft's ongoing dependency on COM/Win32 despite attempts to modernize with WinRT and managed code

IDE User Experience & Warnings

• Extended discussion about warning visibility sparked by VB6 users encountering 35+ warnings when importing packages like Krool's VBCCR controls
• bclothier emphasized that VB6 users lack familiarity with compiler warnings since the VB6 IDE never displayed them, making twinBASIC's warnings feel like errors
• Community consensus emerged that package warnings should be hidden by default, with an option to enable for package authors
• waynephillipsea acknowledged the need to better distinguish warnings from errors, noting the clickable colored diagnostic counters may not be obvious enough
• Proposed solutions included tooltip explanations on first hover, hiding diagnostics panel by default for beginners, and suppressing warnings from consumed packages

Language Features & Implementation

• Discussion of variable-sized UDT members revealed current limitations requiring SAFEARRAY workarounds rather than C-style flexible array members
• fafalone noted ongoing challenges standardizing WinDevLib's approach to variable-length structures across different API patterns
• bclothier explained the core issue: twinBASIC needs syntax to tell the compiler how to iterate pointer-based arrays like C does automatically
• Community confirmed generics work in packages for most cases, though specific type combinations still have bugs

Development Tools & Workflow

• Serial communication questions led to recommendations for using Windows API (CreateFile/ReadFile/WriteFile) over the legacy MSComm control
• fafalone highlighted that API calls would actually be faster than MSComm since the control wraps the same APIs
• Antivirus false positives on compiled executables addressed with standard recommendation to exclude project folders from scanning
• wqweto and others recommended organizing all projects under a single root folder (e.g., C:\Projects) for easier exclusion management

Conclusion

The week demonstrated twinBASIC's unique position bridging VB6 veterans and modern development practices. The extensive UX discussion around warnings revealed important insights about user expectations and led to concrete proposals for improving the newcomer experience without sacrificing advanced features. The community's willingness to investigate VB6's original development team shows deep appreciation for the language's heritage while actively building its future. Progress continues on practical implementation details like package diagnostics filtering and better attribute discoverability.

Around the Web

reddit: Is Visual Basic still a thing in 2025?

A couple of mentions of twinBASIC in the comments for the reddit post below:

CfmOS on twinBASIC

Posted by gaouser in show-and-tell:

A port of CfmOS; my mobile OS for MCUs, to twinBASIC
Lets me try stuff easily on VB6/tB before on C for MCUs

Has:
- An UI engine
- 240x320 RGB888 display
- A Bytecode interpreter
- A BASIC-VB hybrid interpreter (deprecated!)
- App format
- Android-ish UI

Planned:
- VFS
- App Store
- Tiny Win32 Subset

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

AI-Generated Changelog Summary

^{* Auto-generated via Claude-Sonnet-4.5, sorted in order of its opinion of "most impactful changes."}

New IDE Feature: Code Reindenting

• Added editor commands to reindent selected code or entire documents with associated menu entries (contributed by Nikos Kesoglidis)
• Note: Currently doesn't work correctly for Interface blocks

Improved VB6/VBA Compatibility

• Out-only parameters are now zero-filled during code generation to match VB6/VBA behavior and work around third-party component bugs (related to Scripting.Dictionary lookup issues)
• Changed missing PtrSafe declaration from an error to a warning that defaults to ignore state, reducing friction when migrating legacy code

UI Control Fixes

• Resolved Label control flickering issue when AutoRedraw is enabled
• Fixed mouse event propagation for lightweight controls—events now properly bubble to parent controls when child controls are disabled

These updates focus on improving compatibility with legacy VB6/VBA code while enhancing the IDE experience with new formatting capabilities.

WARNING: The following issues are present in each of the releases below:

• IMPORTANT: This is an interim/experimental release. It includes significant changes, so some instability is to be expected.
• KNOWN ISSUE: Controls are not being destroyed properly by the form designer, causing big memory leaks (broken in this build)

BETA 893

• fixed: Label flickering with AutoRedraw ON [#2245]
• improved: out-only params are now zero-filled in codegen to match VBx behaviours and mitigate third-party bugs [#2248]

BETA 894

• added: IDE commands 'tbEditor_ReindentSelection' and 'tbEditor_ReindentDocument', and associated menu entries [ donated by Nikos Kesoglidis (sokinkeso) ]
• NOTE: Reindent feature does not currently work correctly for Interface blocks
• changed: error missing PtrSafe [TB5129] to a warning [TB0029], defaulting to IGNORE state [ wqweto, discord ]

BETA 895

• fixed: mouse events on a lightweight control would not propagate to the parent when the control is in a disabled state [ axisdj, discord ]