TwinBasic

Quote:

---

Originally Posted by Niya

I can answer at least some of these. I haven't really played around in TwinBASIC since my clock example and there have been a lot of changes since so I'll just talk about what I know for a fact.



I know for a fact there is a LongPtr type that adjusts to "bitness" of the binary. It works just like the IntPtr type in .Net. It's 32 bits wide in 32 bit binaries and 64 bits wide in 64 bit binaries. I don't know if there first class support for Decimal and I'm not 100% sure but I believe there is a LongLong type.



Multithreaded is implemented but not yet supported by language features. That's how it was back when I was testing it heavily. I don't know if that has changed since then but based on a couple comments I saw in the GitHub recently, I don't the status of multi-threading support has changed. As I understand it, the meat and bones of it is fully there, there's just no way to access it from the language as of yet. My guess is the community has to decide exactly what an interface into this system should look like. I know from personal experience that when it comes to deciding how things should work, it can cause a lot of chaos. It's very hard to get everyone to agree on what the best way to do something is. I'm just speculating though. Perhaps Wayne himself will talk about this in more detail. I think he monitors this thread.



I saw a recent update where it was stated that TwinBASIC can now build standard DLLs.



What do you mean by this? Like Redim Preserve?

---

Yeah a LongPtr that the compiler handles as either 4 or 8 bytes is fantastic; but I meant unsigned like ushort being 0-65535 instead of VB's Integer which is -32,768-32,767.

CreateThread is an API; and it supports calling APIs from what I've seen. So what happens when you call CreateThread to create a new thread? Because of the runtime, there's extremely little you can do in VB6 without elaborate hacks, even calling APIs from the new thread is only possible if they're in a TLB, because Declare statements are late-bound and handled by the runtime. And those hacks aren't going to work in TB because they call undocumented runtime APIs and play with VB exe headers.

For arrays, many APIs return or pass a variable sized array, but they're not a SAFEARRAY so you have to a) declare a sufficiently large buffer that is fixed size, or b) use CopyMemory from the address of a placeholder single variable.
Consider an API like TdhGetEventInformation; out of the outputs is a structure with the following member:
EVENT_PROPERTY_INFO EventPropertyInfoArray[ANYSIZE_ARRAY];

Since VB uses a SAFEARRAY behind the scenes, but the API does not, you can't define the member as a variable length array. The number of EVENT_PROPERTY_INFO structures returned varies. So how do you call this API in VB6? You need to either figure out what the maximum possible is and pass a fixed length array, since VB makes an exception in that case and doesn't use a SAFEARRAY, e.g.

Code:

---

Private Type MyUDT
a As Long
b(0 to 3) As Long

---

behind the scenes, b is 16 contiguous bytes starting at VarPtr(MyUDT) + 4 and has a total size of 20 bytes, but

Code:

---

Private Type MyUDT
a As Long
b() As Long

Dim MyUDTVar As MyUDT
ReDim MyUDTVar.b(0 To 3)

---

has a total size of only 8 bytes; because b is a pointer to a SAFEARRAY, which contains *another* pointer, and that's where the 16 bytes of the array data are located.

But the API is returning a regular array, so you'll wind up with gibberish or access violations if you try to use it with an API like TdhGetEventInformation.

So, you either figure out the maximum possible (which becomes a memory problem if it's large and called frequently), or instead of an array, just declare the member as a long, then since another parameter tells you the size, you can use CopyMemory to read that memory starting from the placeholder long.

I downloaded the latest beta, multithreading works, at least as far as a simple hello world test. Haven't tested much yet, it worked from the IDE too but I didn't try debugging.

Code:

---

Class Form1
    Private Declare Function GetCurrentThreadId Lib "kernel32" () As Long

    Private Declare Function CreateThread Lib "kernel32" ( _
                            ByRef lpThreadAttributes As Any, _
                            ByVal dwStackSize As Long, _
                            ByVal lpStartAddress As LongPtr, _
                            ByRef lpParameter As Any, _
                            ByVal dwCreationFlags As Long, _
                            ByRef lpThreadId As Long) As LongPtr

    Private Declare Function WaitForSingleObject Lib "kernel32" ( _
                            ByVal hHandle As LongPtr, _
                            ByVal dwMilliseconds As Long) As Long
    Sub New()
    End Sub
   
    Private Sub Command1_Click() Handles Command1.Click
        Dim lTID As Long
        Dim lCurTID As Long
        Dim hThreadNew As LongPtr
        lCurTID = GetCurrentThreadId()
        hThreadNew = CreateThread(ByVal 0&, 0&, AddressOf TestThread, ByVal 0&, 0&, lTID)
        Label1.Caption = "Thread " & lCurTID & " is waiting on thread " & lTID
        Dim hr As Long
        hr = WaitForSingleObject(hThreadNew, 30000&)
        Label1.Caption = "Wait end code " & CStr(hr)
    End Sub
    Private Sub TestThread()
        MsgBox "Hello thread"
    End Sub
End Class

---

:D


It does appear that TB replicates how arrays in UDTs function in providing a standard array in UDTs declared as fixed. I was excited when it allowed ReDim, but then it errored when trying to use the expanded array. So not sure how it will work with APIs, will have to test.

Thanks for taking a look at tB, fafalone! I've used your TaskDialog in the past, which was very useful.

Multithreading should work OK, but you're right that we haven't got integral language support for it yet.

The [GLOBALS] error is known about and can be ignored (and will be muted in the IDE soon).

If you create a UI based EXE with tB, the linker currently pulls in all the implementations for every control, even if they're not used. All those implementations are written and compiled in tB, and so are currently compiled unoptimized until the optimizing compiler becomes available. Unoptimized compiled code can be significantly larger than regular optimized code. If you create a non-GUI based EXE, the final EXE size starts off tiny (about 8kb if I remember correctly). The 'Hello World' sample is an example that doesn't use forms, and just a MsgBox.

For the dynamic-sized contiguous arrays, I would suggest making a GitHub issue for it, citing a few API examples:
https://github.com/twinbasic/twinbasic

To answer the other couple of questions;

Unsigned types are planned, see https://github.com/twinbasic/twinbasic/issues/81
Adding support for unsigned types is not particularly difficult, but writing the many thousands of tests to ensure they work properly in all scenarios is what will take some time.

Finally, yes, using tB generated code in kernel mode should be fine.

Awesome.

Oh a couple more questions; is there any automatic structure alignment? VB6 aligns at 4 bytes.

Fairly low priority, but I might make a feature request for an implementation of #pragma pack(n) too.

Also, for COM interfaces, can typelib-defined interfaces returning an HRESULT be implemented as functions, to return a value, rather than subs? Would save a ton of vtable swapping calls for where that's mandatory.

Structure alignment is same as VBx. I think having an attribute to allow overriding it would be useful, so that would be a good feature request.

For HRESULTs you might want to look at `Err.LastHResult` and `Err.ReturnHResult' new properties, so that you can read and manipulate the HRESULTs without needing to change definitions.

Also of note, is that you can completely define your interfaces directly in tB. E.g.:

Code:

---

[ InterfaceId("12345678-1234-1234-1234-123456789123") ]
Interface ISomething Extends stdole.IUnknown
  Sub DoSomething()
End Interface

---

Oh that's useful.

Defining the interfaces in TB like that, they work the same way as in TLBs, i.e. I can get an IShellFolder from SHGetDesktopFolder as well as implement it in shell extensions? Is there support for creating them a la coclass, like define IFileDialog Extends stdole.IUnknown, IFileOpenDialog Extends IFileDialog, and have an equivalent to

Code:

---

[ uuid(DC1C5A9C-E88A-4dde-A5A1-60F82A20AEF7) ]
coclass FileOpenDialog {
        interface IFileOpenDialog;
}

---

somehow?

Yes the interfaces defined in tB will match ones created in a type library.

RE coclass; Not at the moment, but again that's a good idea.

You should be able to do something like this (air code):

Code:

---

Function NewFileOpenDialog() As IFileOpenDialog
  Return CreateObject ("new:{DC1C5A9C-E88A-4dde-A5A1-60F82A20AEF7}")
End Function

---

Ok, just one more question for now; you mentioned running in kernel mode shouldn't be an issue... how does one specify the necessary compiler flags? In VB6 the .vbp file can be modified with the undocumented

Code:

---

[VBCompiler]
LinkSwitches= /ENTRY:DriverEntry /SUBSYSTEM:NATIVE /FIXED:NO

---

Ah sorry, I forgot that we've not exposed the SUBSYSTEM switch, and you need to override the entry point. I'll get that added for an upcoming release. (edit: not the next release as there's a few tests needed ;)

That would be fantastic. Perhaps something like a textbox in the compiler section to specify switches, to expose the functionality without spending tons of times making options to automatically create a rare project type.

Oh one other question for that-- in VB6, API Declare statements are late-bound, handled by the runtime; except if in TLBs, so all APIs must go in typelibs for VB6 kernel mode drivers. Are they late bound in TB, and if so, does it at least follow the early-bound if in typelib model? btw, I added a formal feature request like the other items we discussed to track this.

---

And new question... self-subclassing in Forms, class modules, and UserControls... possible? I think so, without hacks-- I didn't even notice my multithreading test shouldn't have worked... TestThread was a private sub in a Form. I added a standard module, put a Public Sub TestThread in it, and the AddressOf operator supplied the address of the private one on the form. This is different behavior than VB6-- it will error with 'invalid use of addressof operator' if you use in on a private sub when there's no public one in a module or when there's a conflict.

I was able to use the public version, but I had to specify MyModule.TestThread. This is how I wish VB6 worked, but this will break compatibility-- but only on VB6 code that would cause an error. So I'm not sure whether this should be considered a bug. Especially since it keeps with the VB priority system, where it will call a Private Sub A in the Form before Public Sub A in a module if you don't specify.

Will test subclassing tomorrow.

---

Also-- I added a reference to my oleexp.tlb typelib, and noticed this:

Attachment 185335

That's one of many, many coclasses in oleexp... the difference with this one is that uses dispinterface and source keyword;

Code:

---

    [
        uuid(9BA05971-F6A8-11CF-A442-00A0C90A8F39), // CLSID_ShellFolderViewOC
        helpstring("Shell Folder View Events Router.")
    ]
    coclass ShellFolderViewOC
    {
        [default]        interface    IFolderViewOC;
        [default, source] dispinterface DShellFolderViewEvents;
    }

---

I'm not sure what to make of this. It might be a bug, especially since placing one on the form results in an error in ActiveXExtender.twin->PrepareOLEInterfaces (0x80004002 E_NOINTERFACE on Set Me.ClientObject_IViewObject = Me.ClientObject).

For the API declares, I know that we not long ago started binding them at runtime like VB6 does. I can't remember off the top of my head whether we excluded type library APIs from that change. I will check that, and if not fix it, and I'll also introduce a project flag for allowing binding project declared APIs via the import table too (which is how we used to do it in earlier BETAs of tB).

Allowing AddressOf on class members is a new feature in tB. Provided all 'good' (i.e. compile-able) code from VB6 works as expected in TB, we wouldn't classify what you describe as something that breaks backwards compatibility. The only thing to be aware of with the AddressOf on class members, is that the generated stub functions are only valid whilst you keep the class instance alive, since the stubs contain weak references to the class instance. This is usually fine, since you'll typically have the class instance itself do the teardown of the subclassing before being destroyed, and so the stub function would no longer be needed.

For the ShellFolderViewOC issue, it appears that the coclass has got the `Control` flag set on it (or at least it has in the registry entry), so tB is picking that up as an ActiveX control.

How exactly does TB exe work behind the scenes-- does it really have dependencies? Because I created an empty project;

Code:

---

Module MyModule

        ' add your procedures here
    Sub main()
           
    End Sub
End Module

---

and that's it (I set sub main as the startup object).

In VB6, the only dependency of such an exe is msvbvm60.dll (which is then removed for drivers).

The TwinBasic version lists dependencies on comctl32.dll, ole32.dll, and kernel32.dll. I unchecked the default included COM Type Library/Active-X reference, and enabled native subsystem flag.

An empty standard DLL depends on those three plus advapi32, oleaut32, and user32.

Does it actually depend on these, or are they superfluous references that can be removed? A kernel mode driver cannot import from anything besides ntoskrnl.exe. So if those references are unavoidable, that would unfortunately prevent this.

---

self-subclassing does not appear to be practical as 'AddressOf on class members is limited to subs'... which severely limits it.

Will proceed with testing traditional subclassing though... I thought a fun test would be to port over my event tracer, since it's virtually all API and native code besides the basic form, and will put multithreading to the test as a lot is done in both threads and there's heavy use of critical sections.

The default entry point in tB sets up COM and a few other bits, but once you're able to override the entry point, the linker won't pull in those dependencies, and so the import table will be initially empty.

Apologies, I'd forgotten about the Sub restriction on AddressOf class members. I will open an issue for that, since it would make it much more useful to allow Functions.

I'm looking forward to seeing your event tracer in action :)

Going to post this here rather than spam new issues.

I got the Event Tracer working; due to the last issue, it needs to have the 'Override high dpi settings' option enabled, with Scaling performed by system. I kept a log of problems with missing features and bugs encountered during the process. The self-subclassing was replaced with standard subclassing. The multithreading module was replaced with a direct call to CreateThread. Noticed VarPtr supports use on arrays when replacing ArrPtr (VarPtr variation).
This first test was just making it as close as possible to the original. Next I'm going to go through and change all the necessary Long types to LongPtr and attempt an x64 compile. I used TB modules and copy pasted code, rather than import/use .bas modules.

Design time
(FEATURE NEEDED) -Lack of support for control arrays means OptionButton logic had to be coded manually
(FEATURE NEEDED) -The options to automatically space controls equally in VB6 are *huge* time savers when you're creating many controls, hopefully they're coming to TB.
(FEATURE NEEDED) -PictureBox (missing from TB) is quite often used as a container control; Image can't be, so is more important than meets the eye.
(FEATURE NEEDED) -CommandButton missing 'Default' property.
(FEATURE NEEDED) -TextBox missing Alignment option
(BUG) -Paste in properties does not work
(BUG)-Checkbox needs BS_MULTILINE and BS_VCENTER styles to match VB
(FEATURE NEEDED) -App object missing numerous items, even title
(FEATURE NEEDED) -No Form.ScaleWidth
(FEATURE NEEDED) -Extensive re-working needed to work around lack of practical self-subclass (too many things need to return values); many projects use these hacks so it's fairly important to support.

Compile note: Exe size is 268kb from VB6, 1460kb from TwinBasic.

Runtime
(BUG) -Visible lag on startup; controls are drawn one at a time, taking several seconds. This doesn't happen with VB6 exes, even projects with 10x as many controls on the form.
(BUG) -There is some kind of measurement/positioning problem. The top frames are 180px tall, the ListView is created as y=204px, but it's drawn halfway up the frame.
Further investigation revealed, via GetClientRect, the top frames were in fact 270px, which matches the scale factor I'm using; however the manifest is not marking it DPI aware, so it should not be behaving this way; VB6 does not.
It appears that Windows is not applying system default scaling, despite the exe not being marked DPI aware. Forcing system scaling via compatibility options resolves the issue, but produces a further bug: Frame fonts revert to the system fallback font.

---

Attachment removed, see final x64-compatible version at

[twinBASIC] x64-compatible port of Event Tracing for Windows File Activity Monitor

There's also the x86-only first test version in a comment, with the DPI issue manually corrected so you don't have to play with properties.

Thanks @fafalone, I'm glad to hear you got it working. Most of those issues/missing-features are known, some have GitHub issues, and thanks for opening those bug reports. With regards the DPI, yes that is a known issue with tB currently calling SetProcessDpiAwareness in the form engine, instead of leaving it to the manifest.

The EXE size will be higher than VB6 due to the form engine and controls implementations all being included in the EXE, but once we've got the optimizing compiler enabled, the size will reduce probably by about 50%.

I'm hoping to give this a try tomorrow; thanks for sharing.

twinBASIC IDE BETA 82 is now available.

Download from here... https://github.com/WaynePhillipsEA/twinbasic/releases

• Click on "Assets" for the latest release
• Download and Extract the ZIP file into a local folder
• Then run the twinBASIC.exe from that local folder.

If you haven't installed twinBASIC before you will need the WebView2 Runtime.
When you run the IDE it will show a message if the WebView2 Runtime isn't installed.
If you're using Windows 11 it should already be installed.
Some products, including Office 365, now pre-install WebView2 for you, so you might not need this step.
You can download and install the WebView2 Runtime (32-bit) here: https://tinyurl.com/twinbasicwebview2runtime
(in case of difficulty download from here: https://developer.microsoft.com/en-u...wnload-section
- you want "Evergreen Standalone Installer" > "x86")

twinBASIC status update:

twinBASIC Update: July 24, 2022

Highlights include implementation of the form Controls collection, initial publication of the twinBASIC Guiding Principles, and the potential to write device drivers with tB.

https://nolongerset.com/twinbasic-update-july-24-2022/

twinBASIC IDE BETA 83 is now available.

Download from here... https://github.com/WaynePhillipsEA/twinbasic/releases

• Click on "Assets" for the latest release
• Download and Extract the ZIP file into a local folder
• Then run the twinBASIC.exe from that local folder.

If you haven't installed twinBASIC before you will need the WebView2 Runtime.
When you run the IDE it will show a message if the WebView2 Runtime isn't installed.
If you're using Windows 11 it should already be installed.
Some products, including Office 365, now pre-install WebView2 for you, so you might not need this step.
You can download and install the WebView2 Runtime (32-bit) here: https://tinyurl.com/twinbasicwebview2runtime

Quote:

---

added: project setting of 'Override Entry Point (ADVANCED)' for overriding the DLL entry point in kernel mode builds.
added: project setting of 'Runtime Binding Of DLL Declares (ADVANCED)' to allow binding DLL declares through the IAT
improved: when 'Native Subsystem' project setting is enabled, the linker will report any DLL imports that are not to the NTOSKRNL dll during building

---

Sweet. This will be fun.

twinBASIC IDE BETA 84 is now available.

Download from here... https://github.com/WaynePhillipsEA/twinbasic/releases

• Click on "Assets" for the latest release
• Download and Extract the ZIP file into a local folder
• Then run the twinBASIC.exe from that local folder.

twinBASIC IDE BETA 85 is now available.

Download from here... https://github.com/WaynePhillipsEA/twinbasic/releases

• Click on "Assets" for the latest release
• Download and Extract the ZIP file into a local folder
• Then run the twinBASIC.exe from that local folder.

twinBASIC IDE BETA 86 is now available.

Download from here... https://github.com/WaynePhillipsEA/twinbasic/releases

• Click on "Assets" for the latest release
• Download and Extract the ZIP file into a local folder
• Then run the twinBASIC.exe from that local folder.

[twinBASIC] x64-compatible port of Event Tracing for Windows File Activity Monitor

:D

Quote:

---

Originally Posted by fafalone

[twinBASIC] x64-compatible port of Event Tracing for Windows File Activity Monitor

:D

---

Very impressive that you have migrated VBEventTrace to twinBASIC :D

It does look like at last we have a successor to VB6 :)

twinBASIC IDE BETA 87 is now available.

Download from here... https://github.com/WaynePhillipsEA/twinbasic/releases

• Click on "Assets" for the latest release
• Download and Extract the ZIP file into a local folder
• Then run the twinBASIC.exe from that local folder.

twinBASIC IDE BETA 88 is now available.

Download from here... https://github.com/WaynePhillipsEA/twinbasic/releases

• Click on "Assets" for the latest release
• Download and Extract the ZIP file into a local folder
• Then run the twinBASIC.exe from that local folder.

Quote:

---

Originally Posted by fafalone

Going to post this here rather than spam new issues.

I got the Event Tracer working; due to the last issue, it needs to have the 'Override high dpi settings' option enabled, with Scaling performed by system. I kept a log of problems with missing features and bugs encountered during the process. The self-subclassing was replaced with standard subclassing. The multithreading module was replaced with a direct call to CreateThread. Noticed VarPtr supports use on arrays when replacing ArrPtr (VarPtr variation).
This first test was just making it as close as possible to the original. Next I'm going to go through and change all the necessary Long types to LongPtr and attempt an x64 compile. I used TB modules and copy pasted code, rather than import/use .bas modules.

Design time
(FEATURE NEEDED) -Lack of support for control arrays means OptionButton logic had to be coded manually
(FEATURE NEEDED) -The options to automatically space controls equally in VB6 are *huge* time savers when you're creating many controls, hopefully they're coming to TB.
(FEATURE NEEDED) -PictureBox (missing from TB) is quite often used as a container control; Image can't be, so is more important than meets the eye.
(FEATURE NEEDED) -CommandButton missing 'Default' property.
(FEATURE NEEDED) -TextBox missing Alignment option
(BUG) -Paste in properties does not work
(BUG)-Checkbox needs BS_MULTILINE and BS_VCENTER styles to match VB
(FEATURE NEEDED) -App object missing numerous items, even title
(FEATURE NEEDED) -No Form.ScaleWidth
(FEATURE NEEDED) -Extensive re-working needed to work around lack of practical self-subclass (too many things need to return values); many projects use these hacks so it's fairly important to support.

Compile note: Exe size is 268kb from VB6, 1460kb from TwinBasic.

Runtime
(BUG) -Visible lag on startup; controls are drawn one at a time, taking several seconds. This doesn't happen with VB6 exes, even projects with 10x as many controls on the form.
(BUG) -There is some kind of measurement/positioning problem. The top frames are 180px tall, the ListView is created as y=204px, but it's drawn halfway up the frame.
Further investigation revealed, via GetClientRect, the top frames were in fact 270px, which matches the scale factor I'm using; however the manifest is not marking it DPI aware, so it should not be behaving this way; VB6 does not.
It appears that Windows is not applying system default scaling, despite the exe not being marked DPI aware. Forcing system scaling via compatibility options resolves the issue, but produces a further bug: Frame fonts revert to the system fallback font.

---

This seems like an excellent item for a new thread. I'd like to see multiple threads going on TwinBasic in the Other Basic forum. We could start with a prefix for [TwinBasic] (people can do that manually, for now). If there was enough interest, as it seems like there ought to be, improvements to that approach could be made. My point to all this is to show more 'chatter' around the subject. Just a suggestion, though. People can do as they feel like on this.

Quote:

---

Originally Posted by Shaggy Hiker

If there was enough interest, as it seems like there ought to be, improvements to that approach could be made. My point to all this is to show more 'chatter' around the subject.

---

Oh it's picking up steam. I've been seeing a lot of "new faces" over at TwinBASIC's GitHub page. Most of the discussion is over there.

Quote:

---

Originally Posted by Niya

Oh it's picking up steam. I've been seeing a lot of "new faces" over at TwinBASIC's GitHub page. Most of the discussion is over there.

---

And on Discord too. There is certainly a lot of interest.

twinBASIC IDE BETA 89 is now available.

Download from here... https://github.com/WaynePhillipsEA/twinbasic/releases

• Click on "Assets" for the latest release
• Download and Extract the ZIP file into a local folder
• Then run the twinBASIC.exe from that local folder.

People should post more in the CodeBank too. I think a lot of people would be interested if they saw just how far along tB is... showing off complex code samples would help that.

Here is the progress of my project in Tb without modification compared to VB6 (except adaptation for the lacks).
Main lack: picturebox, image on buttons, indexed objects (Labels, TextBox), scaling.
But I'm patient, Wayne is a rocket ship.

Attachment 185420

twinBASIC status update

twinBASIC Update: July 31, 2022

Highlights include improved support for building device drivers, initial support for keyboard menu navigation, and a milestone for the twinBASIC project.

https://nolongerset.com/twinbasic-update-july-31-2022/

How To's and other articles about the twinBASIC language...

https://nolongerset.com/tag/twinbasic/

Quote:

---

Originally Posted by VB6 Programming

How To's and other articles about the twinBASIC language...

https://nolongerset.com/tag/twinbasic/

---

I was just reading this page, and I realized something I didn't even think of before. I've known from the start TwinBASIC didn't have a runtime like VB6 but I never really thought about what that meant until now. Where does TwinBASIC get functions like Len/LenB, AscW, VarPtr etc from? I cannot believe I have never thought to ask that until now.

twinBASIC IDE BETA 90 is now available.

Download from here... https://github.com/WaynePhillipsEA/twinbasic/releases

• Click on "Assets" for the latest release
• Download and Extract the ZIP file into a local folder
• Then run the twinBASIC.exe from that local folder.

:confused: