TwinBasic

[fafalone]

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.

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

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.