twinBASIC Weekly Update

twinBASIC Update: June 2, 2025

Highlights include compiler performance improvements and a kernel-mode mini-filter driver sample project written in twinBASIC.

Mike Wolfe

Jun 2, 2025 • 5 min read

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:

Highlights

Performance Improvements

The two most recent BETAs, 786 and 787, included "many performance improvements to the early stages of the compiler" and a fix for "abnormal CPU usage by the compiler background processes."

Discord Chat Summary

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

twinBASIC Discord Summary: May 27-June 1, 2025

Overview

This week's discussions in the twinBASIC community centered around advanced system programming capabilities, performance optimization challenges, and UI design considerations. A notable highlight was fafalone's demonstration of a kernel-level minifilter driver written in twinBASIC, showcasing the language's potential for systems programming. Community members also explored solutions for UI performance issues and discussed the nuances of API declarations.

Advanced System Programming

fafalone demonstrated what appears to be the first BASIC-written minifilter driver, capable of blocking file execution at the kernel level before programs even start to load, highlighting twinBASIC's capabilities for low-level system programming.
A community member showcased a successful implementation of IOCP (I/O Completion Ports) in twinBASIC, reporting stable operation for over 20,000 seconds and indicating potential for production use.
Discussions around the minifilter driver expanded to potential applications including custom antivirus solutions, service protection tools, and a "virtual on/off switch" for hard drives to prevent unnecessary disk spin-ups.

API Declarations and Parameter Passing

Wayne Phillips clarified how twinBASIC handles parameter passing in variadic functions, explaining that the compiler applies ParamArray rules as if parameters are ByRef Variants before reducing them to their non-Variant types.
When passing to ByRef Variants, values are passed as VT_BYREF only if the argument is directly referencable (a variable name), while expressions or function results are passed ByVal.
Wayne acknowledged that the current implementation of C variadic functions using ByRef/ByVal modifiers was a temporary solution, suggesting a new syntax would be preferable.

UI Performance Considerations

Several members discussed performance issues when populating ListView controls with large datasets (29,000+ items), noting similar slowdowns in both VB6 and twinBASIC.
Wayne suggested using WM_SETREDRAW to toggle rendering during batch operations as a potential solution.
Community members recommended considering alternative approaches like deferred loading of subitems, virtual mode, or custom controls for high-performance scenarios.

Form Designer Features

A discussion about anchoring behavior in the form designer revealed that anchoring was previously honored at design time but was removed based on developer feedback.
Wayne explained that while restoring this functionality is possible, it's not a quick fix due to significant changes in the form designer since then.
Community members suggested a project setting to allow users to choose whether anchors should be applied during design time.

Conclusion

This week demonstrated twinBASIC's versatility across different programming domains, from high-level UI development to low-level system programming. The successful implementation of kernel-level drivers and IOCP showcases the language's growing maturity for serious application development. Meanwhile, ongoing discussions about API declarations and performance optimizations reflect the community's commitment to understanding and leveraging the language's capabilities effectively.

Around the Web

fsMiniFilter

Posted by fafalone in show-and-tell:

My demo of using tB to make kernel mode minifilter drivers is now out!

This type of driver is useful for antimalware, system monitoring, access control, and other tasks, and unlike hardware drivers or others, is actually practical to make and use in twinBASIC, being only roughly as complicated as regular API-heavy projects. My HelloWorldDriver project demonstrated tB could make a driver, now this project serves as a proof of concept that tB can make useful drivers: This project blocks execution of certain programs or access to certain files by name.

The code for this is simple and straightforward. Head on over to the project repository and check it out! Do read through the whole post there though, there's some important caveats around bugs and different/additional techniques compared to my first driver.

twinBASIC has huge potential for bridging the gap between the power of low level- even down to the kernel- and RAD simplicity.

Changelog

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

AI-Generated Changelog Summary

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

Added: New 'Trace RaiseEvent calls and args' option in project Trace settings, allowing developers to monitor event raising during execution [commissioned work]
Improved: Significant performance enhancements to early compiler stages, particularly beneficial for users on slower machines
Fixed: Critical regression (since BETA 782) that caused debug sessions to fail after building EXE/DLL files with errors like 'Failed to create window class named ThunderRT6Main'
Fixed: Public Delegates accessibility issues from packages, improving component-based development
Fixed: Resolved abnormal CPU usage by compiler background processes, improving overall system performance
Updated: Added support for 2 additional language packs (Spanish and Catalan), thanks to community member Marcos LM

WARNING: The following issues are present in BETA builds 623 - 787 (the latest build as of publication):

IMPORTANT: This is an interim/experimental release. It includes significant changes, so some instability is to be expected. [Editor's Note: Rolling back to BETA 622 may be necessary if any of the KNOWN ISSUES below affect your project.]
KNOWN ISSUE: Controls are not being destroyed properly by the form designer, causing big memory leaks (broken in this build)
there are known memory leaks in these versions, so memory usage will be higher than at the Version 1.0 release

BETA 785

added: 'Trace RaiseEvent calls and args' option to the project Trace options [ commissioned work ]
fixed: some edge cases around UC handling of WM_WINDOWPOSCHANGING in MSACCESS [ commissioned work ]
fixed: (regression since BETA 782) after build to EXE/DLL, debug session can fail with 'Failed to create window class named ThunderRT6Main', and form designer failures until compiler restart [ fafalone, discord ]

BETA 786

improved: many performance improvements to the early stages of the compiler, particularly noticeable on slower machines
fixed: Public Delegates were not accessible from packages [ fafalone, discord ]
fixed: further corrections to edge cases around WM_WINDOWPOSCHANGING in MSACCESS AX controls [ commissioned work ]
updated: 2 language packs (Spanish, Catalan)
special thanks to our community members for the new/updated language packs (Marcos LM)

BETA 787

fixed: abnormal CPU usage by the compiler background processes [ fafalone, discord ]