[RESOLVED] VB6 project not working "quite" right in tB (can't find the root cause)

[VanGoghGaming]

I have made an exact tB copy of my VB6 Image Metadata project posted in the VB6 Codebank Forum. I did not use the import feature but rather copied all module code manually and recreated the form design to see if I could match it as closely as possible.

While the project runs flawlessly in VB6 all the time, in tB it only runs "sometimes" (for lack of a better word) and when it runs, the list of metadata properties is incomplete. The other times it just crashes with access violation. Not even going to mention that the image is incorrectly displayed upside down (this doesn't happen in VB6), since this can be categorized as an overlook rather than a bug!



The fact that the list of metadata properties is incomplete (compared to the VB6 version) leads me to believe that not all async operations make it to the finish line and there may be some sort of "race condition" happening in the tB version. In VB6 all async operations are completed all the time, even if not always in the same order but they all finish without exceptions and without crashes.

I'd appreciate it if Wayne or some else more knowledgeable than me could take a look at the project:

MetaDataProperties.zip - contains both VB6 and tB versions (without the test image shown above since that exceeds the forum attachment size limit!)

* Later Edit: here's the link for the test image.

[yereverluvinuncleber]

I've had a problem in one of my apps where TB, when reading an image from a RC collection, the image was inverted. I raised a github issue for it.

It may be entirely unrelated but the issue is here: https://github.com/twinbasic/twinbasic/issues/1939

[VanGoghGaming]

The problem with the inverted image is probably related to the BITMAPINFOHEADER structure where the general consensus is the biHeight member should be negative so that the image is scanned top to bottom instead of bottom to top. So the solution is likely to be as simple as correcting the sign.

The other issue is a lot more complicated. Most WinRT methods are asynchronous in nature so they are running in their own thread and then they call back into the main thread to communicate their results. The order in which these async operations finish is non-deterministic. I am amazed how VB6 with its 30 years old COM technology is able to properly "serialize" or "queue" these callbacks so that they don't step on each other's toes. I think this has some merit to be looked into.

[jangle]

Problems like these are the reason I decided not to switch to tB. A complex and rare bug in the compiler can ruin your entire project. The main thing in a compiler is reliability and predictability, for this reason I stayed with VB6.

[fafalone]

When nothing is more important, yeah it might make sense to avoid projects in Beta. Beta is prerelease testing; bugs are a way of life. But you should check it out again when it's released as stable; the bugs are rapidly disappearing.

With VBScript now on the way out and increasing hostility towards VBA making it more and more painful to use, it's a mistake to think that long term you won't need alternatives to VB6... and even if the compilers for other languages are more 'stable', you'd introduce far more bugs by human or AI error trying to port your project.

[Zvoni]

*snip* you'd introduce far more bugs by human *snip* error trying to port your project.

Which boils down to insufficient knowledge in both languages: Your "source"-language and your "target"-language.

[wqweto]

Problems like these are the reason I decided not to switch to tB. A complex and rare bug in the compiler can ruin your entire project. The main thing in a compiler is reliability and predictability, for this reason I stayed with VB6.

There are bugs in VB6 compiler we often hit. Just today had to deal with OOM during compilation of one of our projects. It's your codebase not big enough to feel the pain.

Btw, there are bugs in gcc and clang too. Every sufficiently large codebase has to deal with bugs in their compilers and/or 3-rd party deps -- it's inevitable.

cheers,
</wqw>

[VanGoghGaming]

The latest tB version fixed the image orientation. Still no luck on the access violation when enumerating the metadata properties:



The VB6 version enumerates exactly 120 properties every time.

[WaynePhillipsEA]

The latest tB version fixed the image orientation. Still no luck on the access violation when enumerating the metadata properties:



The VB6 version enumerates exactly 120 properties every time.

The problem is due to this code:

Private Function GetString(This As tHSTRING, sString As String) As HRESULT
    SysReAllocString VarPtr(sString), WindowsGetStringRawBuffer(This.hString, 0&)
End Function
`

This procedure is being vtable swapped for the IStringLightWeight::GetString member, defined as:
`HRESULT __stdcall GetString([out, retval] BSTR* out)`

The problem here is, that VB ByRef semantics are not a perfect match for OUT-only parameters. For an OUT parameter, the caller can legitimately give you any invalid value on input and you're not meant to use or interpret it, only overwrite it with a result. But in your implementation, by passing sString to SysReAllocString, the input value IS being used, (and freed). The thing to remember is: ByRef is equivalent to [in, out] semantics, not [out].

To correct the problem, do this:

Private Function GetString(This As tHSTRING, sString As String) As HRESULT
    PutMemPtr VarPtr(sString), vbNullPtr
    SysReAllocString VarPtr(sString), WindowsGetStringRawBuffer(This.hString, 0&)
End Function
`

BTW, we dealt with this exact issue a lot in the tB ActiveX implementations, as many AX controls are C++ based and will (legitimately) pass junk/uninitialized values on input to OUT-only params.

[wqweto]

Why not just sString = vbNullString instead of calling PutMemPtr? I mean it looks like PutMemPtr leaks a BSTR or is it on purpose?

Edit: Oh, my bad. I thought it was a problem at callsite (not clearing out params before calling the method) but we are dealing with GetString *implementation* which does not clear its own [out] only parameter properly but insist on deallocating it as a BSTR whatever junk is passed in there.

Yes, this is not something any VBx implementation/devs deal with often (or at all).

cheers,
</wqw>

[VanGoghGaming]

Outstanding sleuthing, cheers Wayne, I wouldn't have figured this one out in a million years!

I'm still not clear why this works in VB6 without the additional call to "PutMemPtr" though. I was under the impression that all function parameters are initialized with zero by default so there shouldn't have been any "junk" pointer in "sString" to begin with... Maybe this is a key difference between VB6 and tB where VB6 does sanitize function parameters before using them?

In any case, I've rewritten the "GetString" function as follows in order to eliminate the overhead introduced by the additional call to "PutMemPtr":

Private Function GetString(This As tHSTRING, pStr As LongPtr) As HRESULT
    pStr = SysAllocString(WindowsGetStringRawBuffer(This.hString, 0&))
End Function

It seems to work great so I'm a happy camper once again!

[VanGoghGaming]

I went ahead and tested this theory just for my own edification:

Private Function GetString(This As tHSTRING, sString As String) As HRESULT
    If StrPtr(sString) Then
        Debug.Print "Junk pointer!"
        PutMemPtr VarPtr(sString), vbNullPtr
    End If
    SysReAllocString(VarPtr(sString), WindowsGetStringRawBuffer(This.hString, 0&))
End Function

"Junk pointer!" is printed all the time in tB while VB6 never does it. So I guess this falls under the "99% compatibility" case between tB and VB6!

I agree with wqweto though, this shouldn't be encountered very often in the wild. I suppose VB6 is going the extra mile with making sure the memory is zeroed out before use even though this "extra safety" comes at the cost of additional overhead.

I'm happy with the solution so I've marked this thread as "Resolved" now.

[WaynePhillipsEA]

It will depend on how the compiler temp variables get issued/reused as to whether the value will contain junk or not. AFAIK VB6 does not guarantee that the out-only param is zeroed at the callsite - though it may happen to do so in this particular case. Ultimately the COM contract denotes that we don't need to zero it, and so it is better not to do so, which allows for better optimization opportunities (for when we turn on LLVM optimizations fully).

FWIW, we could easily add an advanced compiler option to switch the behaviour ON/OFF for zeroing out params at the callsite.

[wqweto]

> AFAIK VB6 does not guarantee that the out-only param is zeroed at the callsite

If it's a typelib declared interface with [out] only param AFAIR VB6 does make sure ref types (String, Variant, Object) are cleared at callsite as not to leak temp values lurking in there.

The problem is when a manually converted typelib erroneously marks these params as [in, out] in which case VB6 does not clear anything and leaks might occur.

cheers,
</wqw>

[fafalone]

VB6 does not allow use of Implements with any interface containing an out-only parameter. That's why it's frequently changed, not by mistake. Issues from this change are rare and can be worked around, so it's not worth making a separate version for everywhere it's used.

[wqweto]

I mean calling methods with [out] only params e.g. ID3D11Device::GetImmediateContext when it's declared to void GetImmediateContext([out] ID3D11DeviceContext **ppImmediateContext) in the typelib.

This code

    Dim pDevice As ID3D11Device
    Dim pContext As ID3D11DeviceContext
    
    pDevice.GetImmediateContext pContext

. . . compiles to this

0040191E 8D 4D E4             lea         ecx,[pContext]  
00401921 E8 1A F8 FF FF       call        ___vbaFreeObj (401140h)  
00401926 8D 45 E4             lea         eax,[pContext]  
00401929 50                   push        eax  
0040192A 8B 45 E8             mov         eax,dword ptr [pDevice]  
0040192D 8B 00                mov         eax,dword ptr [eax]  
0040192F FF 75 E8             push        dword ptr [pDevice]  
00401932 FF 90 A0 00 00 00    call        dword ptr [eax+0A0h]

. . . i.e. pContext receiving variable is explicitly cleared at callsite for the [out] only parameter.

cheers,
</wqw>