[VB6] Modern Shell Interface Type Library - oleexp.tlb

[fafalone]

I have it... no idea how to get it compile. Every version of midl I've tried has failed.

There's a number of things I don't like about the definitions and that would require manual editing. First, tons of APIs are inexplicably commented out. The APIs that aren't commented out, the flag sets aren't even converted to enums, much less associated with their api, unless they were that way in the header. Some descriptions are incorrect. I do the Unicode thing different: provide W, DeclareWide W, and sometimes A...

That's why I had wanted to convert from tbShellLib rather than use an existing API TLB along these lines. Spent a ton of time cleaning them up.

[VanGoghGaming]

while I would not suggest that my TLB is perfect, (I only maintained Unicode, since the beginning of time I was an ANSI Denier). the source (in IDL) could help you if you are interested.

If the guy says he has maintained that Unicode TLB over the years then it logically follows that compiling it shouldn't be all that complicated. I have never compiled a TLB myself, mind you, I am just trying to understand why your MIDL fails to compile your TLB while others don't seem to have any problems... However you're right to wait for TwinBasic to export TLBs rather than pulling your hair with the current version.

[xiaoyao]

Microsoft Win32 API Loader
WIN32API.TXT
how to cange WIN32API.TXT to api.db?
but it's access 2000 or access97 format? i can't open it by office2013,who can upload access2000 or 2003 format mdb file?

Can it be directly converted into a WIN32ApI.TLB file, including all declarations, structures, and APIs? Or is there a ready-made one on the Internet?

[fafalone]

If the guy says he has maintained that Unicode TLB over the years then it logically follows that compiling it shouldn't be all that complicated. I have never compiled a TLB myself, mind you, I am just trying to understand why your MIDL fails to compile your TLB while others don't seem to have any problems... However you're right to wait for TwinBasic to export TLBs rather than pulling your hair with the current version.

There's problems with one very specific issue: When you need to redefine certain low-level COM/OLE stuff for VB compatibility. midl doesn't allow redefinitions, MKTYPLIB does. The main difference *may* be the renaming of interfaces in the hardcore VB typelib; he renames everything IVB____. I'm not willing to do that. I don't have any problems using midl when I'm not trying to redefine low level COM/OLE stuff. I didn't spend all that much time trying to compile it as-is; only did for reference after adapting it's techniques failed to see if it was just oleexp.


But actually... I probably could take the apis from the decompiled typelib, though it won't have the same unicode standards or immense effort put into making enums for everything.

[VanGoghGaming]

Now that you mentioned it, I did see some IVB interfaces defined in Bruce McKinney's TLB, for example IVBStream. I saw that it was working as intended so I didn't think much of it that it has a different name...

[fafalone]

From the end-user perspective the name wouldn't matter, but it would be a huge compatibility issue at this point (or even a couple years ago when I seriously looked at compiling a 64bit version), since me and many others have large codebases with the actual names.

But no matter, I anticipate tB supporting TLB export within the next year or so... it's waited this long. If you like having a massive set of APIs at your fingertips, I recommend upgrading to twinBASIC and using tbShellLib (although fair warning, as beta software, there's issues like *serious* performance issues with something the size of tbShellLib).

A final option might be; tB chokes on compiling the full project as an active-x DLL, but if I could make a separate one... I might be able to pull the APIs from it. Didn't know predeclared APIs were in this high demand for oleexp.

[SaschaT]

Hi fafalone,

Three points:

1. I always recompile the tlb. One reason is the declarations dealing with PROPVARIANTs. In most cases you declare the parameters (e.g in IPropertyStore.GetValue) as VARIANT*. This leads into trouble if the Vartype is incompatible with Visual Basic. I modify all those to PROPVARIANT* and it works. (Made an extended app derived from your Set Default Device sample -> GetValue throws an error if the value param is of type Variant here.)

2. There are some null length odl files in the source folder. Although they are not included in oleexp.old I wonder what they are good for? Especially dsound.odl would be nice to be filled in as it would make the use of my own tlb unnecessary.

3. For the definition of GUIDs you deliver those additional modules. This is somehow laborious. My approach is to define GUIDs as string consts in type libraries and then a.) use a loader function in apps that enumerates those consts (ITypeInfo-> members, get names, filter,...) and store them in a dictionary, b.) have a general function to get the UUIDs from this dictionary per IIDFromString using the GUID names as keys.

Again many thanks for your endless support of this type library!

[fafalone]

1) I've found there's more problems that arise dealing with the struct like that; not all types are 4 bytes, for instance, VB has a lot of features to make handling Variants easy, you just need to, as mentioned, be careful with the typing. If you only deal with simple numbers, the struct is appealing, but if you're dealing with pointers, it's a lot less convenient to dereference or allocate manually. I've got routines to manage that I use; like if it's an unsigned long, I have a VariantSetType function to overwrite the first 2 bytes with VT_I4, making it into a compatible signed long. I'd need to see an example of the problem with GetValue there, as VARIANT and PROPVARIANT aren't actually different... they differ only in the types of data they officially support; but the memory layout is 100% identical. Note that like VB, other apps get crashy if the format isn't *exactly* what they're expecting.

2) In most cases these are stubs for future work, to remind myself 'hey you wanted to add this'... for example dsound.odl has been renamed exp_dsound.odl, is nearly finished, and will be in the next release

3) That sounds *a lot* more laborious. I have a tool that autogenerates those GUID functions. All I have to do is copy/paste the whole ODL file into a textbox, click, and copy/paste the result. It took a couple hours to make the tool, but it's saved the thousands of hours that would have otherwise taken. Then typing IID_IFoo is no more trouble than a dictionary lookup.

[fafalone]

Project Updated - Version 6.4

I'm planning on releasing the simplest Ribbon demo as a VB project (currently tB only), the oleexp version of the interfaces had bugs.

• Added Sensor API and Location API. Sensor pkeys added to mPKEY.
• Added IStorageProviderHandler
• Added DirectSound8, courtesy of The trick/mossSOFT DSVBLib
• Added Distributed Transaction Manager basic interfaces
• Bug fix: Ribbon interfaces were not Implements-compatible and one used a custom UDT instead of a Variant.

[SaschaT]

1) I've found there's more problems that arise dealing with the struct like that; not all types are 4 bytes, for instance, VB has a lot of features to make handling Variants easy, you just need to, as mentioned, be careful with the typing. If you only deal with simple numbers, the struct is appealing, but if you're dealing with pointers, it's a lot less convenient to dereference or allocate manually. I've got routines to manage that I use; like if it's an unsigned long, I have a VariantSetType function to overwrite the first 2 bytes with VT_I4, making it into a compatible signed long. I'd need to see an example of the problem with GetValue there, as VARIANT and PROPVARIANT aren't actually different... they differ only in the types of data they officially support; but the memory layout is 100% identical. Note that like VB, other apps get crashy if the format isn't *exactly* what they're expecting.

2) In most cases these are stubs for future work, to remind myself 'hey you wanted to add this'... for example dsound.odl has been renamed exp_dsound.odl, is nearly finished, and will be in the next release

3) That sounds *a lot* more laborious. I have a tool that autogenerates those GUID functions. All I have to do is copy/paste the whole ODL file into a textbox, click, and copy/paste the result. It took a couple hours to make the tool, but it's saved the thousands of hours that would have otherwise taken. Then typing IID_IFoo is no more trouble than a dictionary lookup.

1) Ok. Dont know what I did. Maybe some projects (dsound/mediafoundation) that were made with older versions of oleexp (that I recompiled) now are incompatible with v6.3. Even VarType(varFromvarProp) raised the error "Type unsupported by VB".

2) Out already! I have to inspect if you've also transferred some mistakes I found meanwhile... (e.g. GetObjectInPath for CaptureBuffer -> *DSGUID)

3.) Anyway. I attach a small demo on how I accomplish this. The module inside has to be modified for every other project. GetIID() has the advantage that you can select the IID from the enumeration parameter. Pitfall: The TLB has to be stored beside the project and/or .exe.

[fafalone]

I'm not sure why older projects would be incompatible... nothing old was touched besides the ribbon interfaces. VarType I think has to be used on an actual variant, not the PROPVARIANT udt. Could you be more specific with what happened?

[Semke]

This Type Library includes a Lot of Interfaces, Some Which i have never heard of and some which sound quite interesting (i have not been using interfaces so much).

is there a place which i can read up on these interfaces, i am sure that once i (or anybody else) know more about them, we can make major use out of them.

[fafalone]

Just search for their name on Google etc, that will bring up Microsoft's documentation and usually lots of other info and examples.

Of course the 55 example projects on the first post in this thread cover a lot too, most of them have a list in small italicized font of what interfaces they're demonstrating.

[SaschaT]

I'm not sure why older projects would be incompatible... nothing old was touched besides the ribbon interfaces. VarType I think has to be used on an actual variant, not the PROPVARIANT udt. Could you be more specific with what happened?

Sorry, I am not able to recreate the situation where I had the errors. One had happend with your sample app for setting the default sound devices which I altered slightly. Maybe when trying to find out which other device property keys work besides DeviceFriendly name. (Enumeration over IPropertyStore.GetCount()/.GetAt()). Some properties give back arrays, some other binary structs. PropVariantToVariant then resulted a in variant type that is unsupported by VB.
The other situation was when experimenting with mediafoundation capturing video streams (based on a sample from TheTrick) - long ago...

...the problem with GetValue there, as VARIANT and PROPVARIANT aren't actually different... they differ only in the types of data they officially support; but the memory layout is 100% identical.

Well, PROPRVARIANT has three additional dwReserved members between vt and value. So I guess it's not 100%.
I disassembled propsys.dll (IDA) and looked into the routine for PropVariantToVariant. It spreads over about 300 lines. I think this would not be the case if the two types were identical?

But let's stop this academical discussion -your implemention works and mine also. If I am the only one that had those issues then there is absolutely no need to find out the 'real way'.

[fafalone]

VARIANT also has those reserved members.

typedef /* [wire_marshal] */ struct tagVARIANT VARIANT; struct tagVARIANT { union { struct __tagVARIANT { VARTYPE vt; WORD wReserved1; WORD wReserved2; WORD wReserved3; union { LONGLONG llVal; LONG lVal; BYTE bVal; SHORT iVal; FLOAT fltVal; DOUBLE dblVal; VARIANT_BOOL boolVal; VARIANT_BOOL __OBSOLETE__VARIANT_BOOL; SCODE scode; CY cyVal; DATE date; BSTR bstrVal; IUnknown *punkVal; IDispatch *pdispVal; SAFEARRAY *parray; BYTE *pbVal; SHORT *piVal; LONG *plVal; LONGLONG *pllVal; FLOAT *pfltVal; DOUBLE *pdblVal; VARIANT_BOOL *pboolVal; VARIANT_BOOL *__OBSOLETE__VARIANT_PBOOL; SCODE *pscode; CY *pcyVal; DATE *pdate; BSTR *pbstrVal; IUnknown **ppunkVal; IDispatch **ppdispVal; SAFEARRAY **pparray; VARIANT *pvarVal; PVOID byref; CHAR cVal; USHORT uiVal; ULONG ulVal; ULONGLONG ullVal; INT intVal; UINT uintVal; DECIMAL *pdecVal; CHAR *pcVal; USHORT *puiVal; ULONG *pulVal; ULONGLONG *pullVal; INT *pintVal; UINT *puintVal; struct __tagBRECORD { PVOID pvRecord; IRecordInfo *pRecInfo; } __VARIANT_NAME_4; } __VARIANT_NAME_3; } __VARIANT_NAME_2; DECIMAL decVal; } __VARIANT_NAME_1; } ;

struct tagPROPVARIANT { union { #endif struct tag_inner_PROPVARIANT { VARTYPE vt; PROPVAR_PAD1 wReserved1; PROPVAR_PAD2 wReserved2; PROPVAR_PAD3 wReserved3; /* [switch_is] */ /* [switch_type] */ union { /* [case()] */ /* Empty union arm */ /* [case()] */ CHAR cVal; /* [case()] */ UCHAR bVal; /* [case()] */ SHORT iVal; /* [case()] */ USHORT uiVal; /* [case()] */ LONG lVal; /* [case()] */ ULONG ulVal; /* [case()] */ INT intVal; /* [case()] */ UINT uintVal; /* [case()] */ LARGE_INTEGER hVal; /* [case()] */ ULARGE_INTEGER uhVal; /* [case()] */ FLOAT fltVal; /* [case()] */ DOUBLE dblVal; /* [case()] */ VARIANT_BOOL boolVal; /* [case()] */ VARIANT_BOOL __OBSOLETE__VARIANT_BOOL; /* [case()] */ SCODE scode; /* [case()] */ CY cyVal; /* [case()] */ DATE date; /* [case()] */ FILETIME filetime; /* [case()] */ CLSID *puuid; /* [case()] */ CLIPDATA *pclipdata; /* [case()] */ BSTR bstrVal; /* [case()] */ BSTRBLOB bstrblobVal; /* [case()] */ BLOB blob; /* [case()] */ LPSTR pszVal; /* [case()] */ LPWSTR pwszVal; /* [case()] */ IUnknown *punkVal; /* [case()] */ IDispatch *pdispVal; /* [case()] */ IStream *pStream; /* [case()] */ IStorage *pStorage; /* [case()] */ LPVERSIONEDSTREAM pVersionedStream; /* [case()] */ LPSAFEARRAY parray; /* [case()] */ CAC cac; /* [case()] */ CAUB caub; /* [case()] */ CAI cai; /* [case()] */ CAUI caui; /* [case()] */ CAL cal; /* [case()] */ CAUL caul; /* [case()] */ CAH cah; /* [case()] */ CAUH cauh; /* [case()] */ CAFLT caflt; /* [case()] */ CADBL cadbl; /* [case()] */ CABOOL cabool; /* [case()] */ CASCODE cascode; /* [case()] */ CACY cacy; /* [case()] */ CADATE cadate; /* [case()] */ CAFILETIME cafiletime; /* [case()] */ CACLSID cauuid; /* [case()] */ CACLIPDATA caclipdata; /* [case()] */ CABSTR cabstr; /* [case()] */ CABSTRBLOB cabstrblob; /* [case()] */ CALPSTR calpstr; /* [case()] */ CALPWSTR calpwstr; /* [case()] */ CAPROPVARIANT capropvar; /* [case()] */ CHAR *pcVal; /* [case()] */ UCHAR *pbVal; /* [case()] */ SHORT *piVal; /* [case()] */ USHORT *puiVal; /* [case()] */ LONG *plVal; /* [case()] */ ULONG *pulVal; /* [case()] */ INT *pintVal; /* [case()] */ UINT *puintVal; /* [case()] */ FLOAT *pfltVal; /* [case()] */ DOUBLE *pdblVal; /* [case()] */ VARIANT_BOOL *pboolVal; /* [case()] */ DECIMAL *pdecVal; /* [case()] */ SCODE *pscode; /* [case()] */ CY *pcyVal; /* [case()] */ DATE *pdate; /* [case()] */ BSTR *pbstrVal; /* [case()] */ IUnknown **ppunkVal; /* [case()] */ IDispatch **ppdispVal; /* [case()] */ LPSAFEARRAY *pparray; /* [case()] */ PROPVARIANT *pvarVal; } ; } ; #ifndef MIDL_PASS DECIMAL decVal; }; };

Variant is in oaidl.h, propvar in propidlbase.h


That's what VB's Variant looks like behind the scenes.

They're identical in *memory layout*... not in officially supported types. PropVariantToVariant attempts to convert the extra types a PROPVARIANT supports into a data type allowed in a VARIANT. The union contains a longer list of data types in a propvar, that's it (and none of them alter the total size or alignment under either x86 or x64).

[xiaoyao]

Very good. Thank you for your effort

[SaschaT]

2) Out already! I have to inspect if you've also transferred some mistakes I found meanwhile... (e.g. GetObjectInPath for CaptureBuffer -> *DSGUID)

Indeed. For the next release please change to:

Interface IDirectSoundCaptureBuffer8 : IDirectSoundCaptureBuffer {
	HRESULT GetObjectInPath([in] UUID* rguidObject, [in] long dwIndex, [in] UUID* rguidInterface, [out, retval] IUnknown** ppObject);

...although one will rarely use those effects while recording...

[xiaoyao]

If IsEqualIID(tCF, GUID_ContainerFormatJpeg) Then mCodec = WFF_JPG
can it check is webp format?
webp file header:

RIFF ?  WEBPVP8X

==============
question 2:how to change webp img file to jpg or png without hdc?

'cWICImage 0.2
'Windows Imaging Component Basic Usage Demo

it's use hdc:
Public Function OpenFile(sFile As String, ToHDC As Long, x As Long, y As Long, Optional nFrame As Long = 0&, Optional hWnd As Long) As Boolean

[Crapahute]

Hi,

All the demos of ucShellBrowse don't work on my PC with Windows 11. (I think it work on my old PC with Windows 7).
I have to comment the line :

' RtlFreeUnicodeString strUnicode

in the function

Private Function FindFirstFileNt(ByVal strDirectory As String, bytBuffer() As Byte) As Long

Is it a problem if I don't use RtlFreeUnicodeString ?

Thank you for your help.

[fafalone]

It will cause a small memory leak as strings aren't freed until app exit but I don't believe it will cause further problems. If for some reason it does, that routine is part of the high performance loader, to disable: in the Properties in the form designer for the control, set HighPerformanceMode to False. The performance difference is negligible until you reach thousands of files in a folder, and then only more then 2-3s when you reach the tens of thousands.

I'll look into this issue, thanks for letting me know.

[Crapahute]

Thank you for your help.

It is the same behaviour with HighPerformanceMode = False. The IDE closes when the program reaches the Function FindFirstFileNt where RtlFreeUnicodeString strUnicode occurs.

[fafalone]

That's extremely odd; do you have the most recent version (and of the VB6 version right, not the tB version?), and can you do me a favor and look at the beginning of LVLoadFolder, and verify this line hasn't been altered or commented out?

If (mHighPerfMode = True) And (mExtColPreload = False) Then

and that the property for that is ok?

Public Property Get HighPerformanceMode() As Boolean: HighPerformanceMode = mHighPerfMode: End Property
Public Property Let HighPerformanceMode(bVal As Boolean): mHighPerfMode = bVal: End Property

FindFirstFileNt is only called from LVLoadFolderEx, and LVLoadFolderEx is only called from within that block requiring mHighPerfMode to be True; something more serious is afoot if something is causing it to jump into that without being called-- or it's been modified somehow and you should update it. I've checked against the version posted in this thread and the tB x64 version on GitHub, neither enter FindFirstFileNt when HighPerformanceMode = False for me. One little thing just to make sure; you saved before you hit run, right? Or if you're not running from the IDE, check if it's happening in both IDE and compiled?

Finally if nothing in this post is the issue, let me know your exact Windows 11 version so I can spin up a VM and check it out in there.

[darjeeling]

Hi fafalone,
I confirm that on all the demos the IDE leaves immediately on Win10 and Win11.

This doesn't appear on Win7

[fafalone]

Just quits with no error? Is this also about ucShellBrowse? Definitely haven't seen or heard this before, likely something specific about your system.

Oh and for both of you, OCX or .CTL? And impacting .exe too?

[Crapahute]

I have only tested the .CTL

' * ucShellBrowse v11.2                                                          *
' * Shell Browser Control                                                        *
' *                                                                              *
' * Released: 18 Jun 2022                                                        *

This line is not commented:

If (mHighPerfMode = True) And (mExtColPreload = False) Then

These lines are ok.

Public Property Get HighPerformanceMode() As Boolean: HighPerformanceMode = mHighPerfMode: End Property
Public Property Let HighPerformanceMode(bVal As Boolean): mHighPerfMode = bVal: End Property

Now I have changed this line to False :

Private Const mDefHighPerfMode As Boolean = False

This time, it's ok. The last time, I had'nt set mDefHighPerfMode to False but quickly changed the properties directly to False. Something like that :

Public Property Get HighPerformanceMode() As Boolean: HighPerformanceMode = False: End Property
Public Property Let HighPerformanceMode(bVal As Boolean): mHighPerfMode = False: End Property

Now with mDefHighPerfMode=False, it's working.

So if I don't set mDefHighPerfMode to False, the IDE crashes, but if mDefHighPerfMode = True, when I compile, the .exe works. Good to know.

Thanks

[fafalone]

No problem, glad it's working now. I'll still definitely check out what the IDE issue with in on 11; odd that it would crash there but not in the compiled exe. Although IIRC I did have some issues with RtlDosPathNameToNtPathName_U, the original way of initializing that string, similarly crashing some Windows versions.

[darjeeling]

-Quits with no error.
-ucShellBrowse
-CTL

And there is nothing sprecial in my systems.

[darjeeling]

@ Crapahute

Congratulations !
Private Const mDefHighPerfMode As Boolean = False

All it's OK.
Thank you so much.

[Crapahute]

Maybe I will make mDefHighPerfMode a variable :

'Private Const mDefHighPerfMode As Boolean = True
Private mDefHighPerfMode As Boolean

and use IsIDE to set its value.

Private Sub UserControl_Initialize()

If IsIDE = True Then
    mDefHighPerfMode = False
Else
    mDefHighPerfMode = True
End If

...

[fafalone]

Looking into this further, it appears RtlFreeUnicodeString should be removed.

MSDN states "The RtlFreeUnicodeString routine releases storage that was allocated by RtlAnsiStringToUnicodeString or RtlUpcaseUnicodeString."

So it looks like it's a mistake that was harmless on previous versions of Windows, but causing problems now; potentially a double-free, or use-after-free. The call is safe to comment out; it won't cause a memory leak as it turns out it just points to the existing string, and doesn't allocate anything itself. VB will free the string.

Embarrassingly, it appears I found that out a while ago and forgot, because the RtlFreeUnicodeString has already been removed from v12.0 (VB6 version unreleased, but available for twinBASIC).

[darjeeling]

Hi fafalone,

You're right "RtlFreeUnicodeString " must be removed.
I replace Private Const mDefHighPerfMode As Boolean = False by True
and removed RtlFreeUnicodeString sub and the line RtlFreeUnicodeString strUnicode
Now it works

Regards