twinBASIC Weekly Update

twinBASIC Update: September 16, 2024

Highlights include support for the .Image property on Form/PictureBox/MDIForm objects, two new static analysis warnings, and inline assembly language support.

Mike Wolfe

Sep 16, 2024 • 6 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

Image Property Support

As of BETA 602, support for the .Image property has been added to the following objects:

Form
PictureBox
MDIForm

Two New Static Analysis Warnings

TB0024: "unused local variable" (defaults to IGNORE)
TB0025: "unused procedure parameter" (defaults to IGNORE)

Preliminary Inline Assembly Support

I'll be honest, this topic is way over my head. For full details, check out the associated GitHub issue: Support inline asm (separate from static linking)

Here's an AI-generated summary of the above link (via Claude-3.5-Sonnet-200k):

Here's a summary of the key points from the GitHub issue discussion about inline assembly support in twinBASIC:

The issue was opened by @fafalone proposing native syntax support for inline assembly in twinBASIC, suggesting it could be implemented within functions using a syntax like "@ASM" to begin and "@End ASM" to end assembly blocks.
Several community members expressed support for inline assembly as an important feature for twinBASIC, considering it essential for a language aiming to cover both high and low-level applications.
@wqweto suggested implementing an Emit(b1, b2, b3, ..., bn) intrinsic as a simpler alternative to full inline assembly support. This would allow directly emitting instruction bytes in the code generation process.
Wayne Phillips (@WaynePhillipsEA), the primary twinBASIC developer, implemented the Emit() function in Beta 605, allowing users to insert raw machine code bytes into their twinBASIC functions.
Further refinements were made in Beta 607, introducing EmitAny() and StackOffset() functions. EmitAny() infers the output length from the datatype, while StackOffset() helps determine stack offsets for local variables or parameters.
Wayne provided several code examples demonstrating how to use these new functions for tasks like doubling a value and retrieving the CPU's processor brand string using the CPUID instruction.
Important notes were shared about using Emit() within regular twinBASIC procedures, including tips on register usage and preserving non-volatile registers.
The discussion highlighted that while this implementation doesn't provide full inline assembly support, it offers a powerful low-level mechanism for inserting machine code directly into twinBASIC programs.

In conclusion, while full inline assembly support isn't yet implemented, twinBASIC has made significant progress in providing low-level code insertion capabilities through the Emit(), EmitAny(), and StackOffset() functions, allowing advanced users to incorporate machine code directly into their twinBASIC programs when necessary.

Discord Chat Summary

^{* Auto-generated via Claude-3.5-Sonnet-200k on poe.com}

Here's a summary of the key points from the twinBASIC Discord chat transcript for September 7-16, 2024:

The twinBASIC project continues to make progress with new features, bug fixes, and community discussions. Here are the main highlights from the past week:

• A memory leak bug in the twinBASIC IDE was acknowledged in the current release notes. While concerning, it appears to primarily affect the IDE rather than compiled programs.

• There were discussions about implementing an Object Browser similar to VB6. The developers confirmed this feature is planned for release before version 1.0.

• The compiler experienced some crashing issues when building certain projects. The development team requested minimal examples to reproduce and fix these problems.

• Inline assembly support was discussed, with confirmation that it will be delivered in the v1.xx cycle, though not in the initial v1 release.

• Static linking capabilities were expanded, with new support for SQLite integration. However, some users experienced issues with different calling conventions and compiler versions.

• A new warning (TB0025) for unused procedure parameters was introduced. The developers plan to refine this in the next release to reduce false positives for interface implementations and event handlers.

• The team is working on improving the Emit() function for inline assembly, including a new StackOffset() intrinsic to help determine variable offsets for use with Emit().

• Debugging capabilities for Office COM/VBE/Automation add-ins within the twinBASIC IDE were requested, though this remains a significant feature request for future development.

In conclusion, twinBASIC continues to evolve with a focus on enhancing compatibility with VB6 while introducing modern language features. The community remains actively engaged in testing and providing feedback, helping to shape the language's development. The addition of more advanced features like improved inline assembly support and static linking options demonstrates twinBASIC's commitment to becoming a powerful alternative for both legacy VB6 developers and those seeking a modern BASIC-like language.

Around the Web

JuanJo Luna Presents twinBASIC at Upcoming AEK

The world's largest in-person Microsoft Access conference–Karl Donaubauer's German-language AEK conference–will include a presentation on twinBASIC from Access MVP JuanJo Luna.

Here's an excerpt from the announcement on AccessForever.org:

twinBASIC, tBA and Access (Juanjo Luna)

incl. world premiere: an early version of twinBASIC for Applications (tBA)

The conference will be held in Nuremberg, Germany, on October 19 and 20.

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.5-Sonnet, sorted in order of its opinion of "most impactful changes."}

Here's a concise summary of the notable updates in twinBASIC, focusing on significant new features and improvements:

Added: Inline Assembly Support
- New Emit() and EmitAny() functions allow injecting assembled code directly into the codegen
- Naked procedure attribute removes implicit prolog/epilog for use with Emit()
- StackOffset() function helps determine ESP/RSP offsets for variables and parameters
Improved Form and Control Functionality
- Added support for Image property on Forms, PictureBoxes, and MDIForms
- Fixed issues with control arrays, visibility, and form unload-load cycles
- Improved Shape control rendering and visibility in the designer
Enhanced Compatibility and Performance
- PictureDpiScaling property now defaults to False for better compatibility
- Fixed regression in popup menu functionality
- Resolved issues with IOleObject::GetMiscStatus implementation
New Developer Warnings
- Added warnings for unused local variables (TB0024) and unused procedure parameters (TB0025)

These updates significantly enhance twinBASIC's low-level programming capabilities while also improving form design and control functionality.

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

there are known memory leaks in these versions, so memory usage will be higher than normal

BETA 602

fixed: controlArray.Count property would not keep in-sync after a form Unload-Load cycle [ commissioned work ]
fixed: controlArray.LBound/UBound poperties do not update after a form Unload-Load cycle [ commissioned work ]
fixed: Visible property of runtime added controls not always defaulting to False [ commissioned work ]
fixed: Shape control was completely invisible in the form designer when Visible property was set to False [ commissioned work ]
fixed: Shape control BackStyle = Transparent was being ignored in some instances [ commissioned work ]
fixed: graphics Line method was not correctly rendering box-filled lines to the outermost right/bottom pixels [ commissioned work ]
added: support Image property (Form, PictureBox, MDIForm) [ commissioned work ]
fixed: Picture property (Form, PictureBox) edge cases when property is set to a bitmap that is already selected into a HDC [ commissioned work ]
fixed: FileListBox.Pattern matching was case-sensitive [ commissioned work ]
fixed: some edge cases when Form.AutoResize is toggled at runtime [ commissioned work ]

BETA 603

fixed: CommandButton Cancel/Default button being True would cause Form to crash if loaded more than once

BETA 604

fixed: (regression) Popup menus not working in recent releases [ https://github.com//issues/1868 ]

BETA 605

added: experimental support for [_HiddenModule].Emit() for injecting pure assembled code into the codegen [ https://github.com/twinbasic/lang-design/issues/65#issuecomment-2348608088 ]
added: support for 'Naked' procedure definitions for use with Emit(), allowing to remove the implicit codegen prolog/epilog [ https://github.com/twinbasic/lang-design/issues/65#issuecomment-2348608088 ]

BETA 606

improved: PictureDpiScaling property on Image/Form/PictureBox etc now defaults to False for better general compatibility (e.g. VBCCR FrameW)
fixed: (regression) IOleObject::GetMiscStatus implementation was broken in recent builds, causing problems with ActiveX controls not being recognized as containers and other similar issues

BETA 607

added: EmitAny() intrinsic function, similar to Emit() but allows for outputting other sized values (currently Integers, Longs and LongLongs), with size inferred from the passed in value type
added: StackOffset(var) intrinsic function for allowing to determine the ESP/RSP offset of a particular local variable or parameter

BETA 608

added: warning TB0024 "unused local variable" (defaults to IGNORE)
added: warning TB0025 "unused procedure parameter" (defaults to IGNORE)