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

[VanGoghGaming]

I've just encountered another case that makes a perfect example of such API functions with UDT parameters. Many WinRT methods use a DateTime structure which is defined as Int64. At first I thought that is compatible with VB6's Date type but that quickly turned up not to be the case so I had to use Currency instead. That needs to go through a bunch of conversions to make a usable Date out of it:

Private Declare PtrSafe Function FileTimeToSystemTime Lib "kernel32" (lpFileTime As Any, lpSystemTime As Any) As BOOL
Private Declare PtrSafe Function SystemTimeToTzSpecificLocalTimeEx Lib "kernel32" (lpTimeZoneInformation As Any, lpUniversalTime As Any, lpLocalTime As Any) As BOOL
Private Declare PtrSafe Function SystemTimeToVariantTime Lib "oleaut32" Alias "#184" (lpUniversalTime As Any, pvVariantTime As Any) As BOOL

Private Function ToDate(cDate As Currency) As Date
Dim SysTime As SYSTEMTIME
    If FileTimeToSystemTime(cDate, SysTime) Then If SystemTimeToTzSpecificLocalTimeEx(ByVal vbNullPtr, SysTime, SysTime) Then SystemTimeToVariantTime SysTime, ToDate
End Function

Declaring everything As Any is very handy here.

P.S. I've written another lengthy reply on the previous page (at the bottom)!

[-Franky-]

-(Bug fix) PROPVARIANT should have an additional 4 bytes for some data types (split as 2 Longs now instead of 1)

Thanks. Works perfectly.

[wqweto]

> Of course tB can work around this restriction but VB6 is still stuck in the stone age so if you want compatibility you don't have much choice.

Btw, in TB if you have Private Declare Function MyDeclare (MyParam As UDT1) As Long you can pass VarPtr(MyUDT2) instead i.e. a LongPtr to an instance of *other* UDT2 (as a consequence of the only pointer in the language LongPtr being typeless void *).

cheers,
</wqw>

[fafalone]

It's a lot more often than you think or I wouldn't have brought it up. Obviously UDTs are the main offenders and not just GUID (that was just an example), there are tons of other UDTs suffering from this affliction. Not to mention that declaring them as pointers overcomes VB6's pesky ANSI conversion.

Then there's also the problem of rewriting UDTs in different ways (such as a GUID as 4 Longs so that they could be easily passed ByVal). A pointer doesn't care how you rewrite your UDTs as long as the size is a match.

There's absolutely no time spent looking up the type of arguments since that is always inferred from their names (rIID, lpSomeStruct, etc). I know CopyMemory doesn't take much time (both in writing the code and execution time) but I think it's a silly workaround and I just don't want to use it unless absolutely necessary.

I used to reference winu.tlb a lot in the past but I gave it up since it always comes short when you need something like you already mentioned. By now I got a lot of APIs already declared and it's rare that I stumble over a new one. Also many of them have WinRT object equivalents since I don't care about supporting anything below Windows 10.

I would have written my own TypeLib by now but I am reluctant to delve into the intricacies of MIDL and IDL language since I don't have your years of experience with that. Also I much prefer the VB-friendly syntax of tB over IDL syntax. So far I've seen that an ActiveX DLL can export interfaces, public types and public enums in its TypeLib. It'll have to do for now.

If you scroll a few pages back in this thread, we've already discussed tlb exporting in tB, and that was more than two years ago. Not even interfaces were supported at that time. It may be implemented some time in the future but the timeframe is just too long.

Maybe an easier workaround to implement would be adding another attribute to the Declare statement like this:

Declare PtrSafe Export Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

Then tB would know you want to export this API in the TypeLib. Just thinking out loud.

Unless you're suggesting I lack experience with the Win32 api, I think I know exactly how often it comes up. I can name thousands of standard cases for every exception you point out, which is the point. I've redone close to 3000 interfaces and 9000 APIs myself from the SDK by hand for WDL, trust me when I say that no, it is absolutely not always true you can infer the type from the name. Thousands of pointers are just pSomething with no hint. Your own example; there's nothing to suggest to anyone who doesn't already know those are UDTs for FILETIME and SYSTEMTIME vs the other things plausible.

I tabbed over to an open project, 3 APIs in, ByRef NewState As ...? I'll give you $100 if you tell me how you know the UDT without guessing or me telling you the API and you've already memorized it. It's pure guesswork that it even is a udt instead of Long, Enum, etc.

I'm sure both of us could sit here and rattle off exceptions all day, but they remain exceptions. There's still 100+ times you want the real type/struct for every one you don't.


Btw you're doing a great job building up a WinRT tlb. Not a fan of using it where there's alternatives but increasingly there's not-- would love to see you expand it for general purpose use. Tip: Preserve LongPtr equivalents with typedef [public] long LongPtr; that way it's easy for both your typelib and code using it to be updated to native tB for x64 support.
If you want it, I have a function that strips the offset and size of comments from tB's typelib to native syntax view to make copying out of a tlb easier.

[fafalone]

> Of course tB can work around this restriction but VB6 is still stuck in the stone age so if you want compatibility you don't have much choice.

Btw, in TB if you have Private Declare Function MyDeclare (MyParam As UDT1) As Long you can pass VarPtr(MyUDT2) instead i.e. a LongPtr to an instance of *other* UDT2 (as a consequence of the only pointer in the language LongPtr being typeless void *).

cheers,
</wqw>

If the UDTs are equivalent, no VarPtr needed.

    Type fizz
        a As Long
        b As Long
        c As Integer
    End Type
    Type buzz
        d As Long
        e As Long
        f As Integer
    End Type
    Sub fizz(b As buzz)
        
    End Sub
    Sub test()
        Dim f As fizz
        fizz f
    End Sub

tB is smart enough to allow that.

[wqweto]

> tB is smart enough to allow that.

Btw, VB6 allows this with same UDTs from different typelibs (sometimes) which probably is a bug in the compiler: https://github.com/twinbasic/twinbasic/issues/1219

cheers,
</wqw>

[fafalone]

Seems like the same guid is key there? or does it work when they're not associated with a guid?

If it's only when same GUID, I'd say design over bug... that's supposed to uniquely identify a type, moreso than a name.

[smileyoufu]

Hello Fafalone!
I've been using your oleexp.tlb and thank you for your dedication to the excellent work.

Excuse me:
1. Can WinDevLib.tlb be used in VB6?
2. Does oleexp.tlb contain the definition of 8500 APIs?

If WinDevLib.tlb is not available in VB6, it is recommended to add 8500 APIs to oleexp.tlb for easy use in VB6.

After all, twinBASIC has not yet been officially released and cannot be used as a development tool for actual production projects. My current development relies heavily on VB6.
Thank you very much!

[fafalone]

1) It's not a type library it's a twinBASIC Package, so, no

In addition to the APIs and COM interfaces it has all the addin packages built in plus hundreds more inlined functions, macros, and small API-related helpers.

2) No, they mostly have the same COM interfaces (maybe a dozen or so aren't in oleexp, but they're obscure), but for a long time I preferred doing my own APIs per project, so never added them to oleexp. There's only about 1000 and a good fraction of those are obsolete olelib stuff for Win9x or W/A variants I exclude from the WDL count (with them it's over 12,000), and an even smaller fraction of related UDT coverage.


As mentioned I was considering whether I could apply some automation to the JSON representation tB generates to covert it back to ODL for oleexp, but that's missing some important info that would make it a much more involved project than I care to take on (specifically, is interface? has ANSI<->Unicode disabled? PreserveSig disabled?)... lots of things I want to do, little time. Plus there's now hundreds of overloads I'd have to fix manually since VB6 has no support for it.

tB isn't quite production ready yet but it's getting closer all the time (and there is some commercial production use; publicly XYPlorer now has frequent twinBASIC builds, for example)... in the mean time I'd advise writing all new code with 64bit in mind (LongPtr where applicable, oleexp defines it), and if you plan to use WDL in the future, pull your API defs from there. You'll need to make some minor adjustments sometimes, but it's largely compatible.

[VanGoghGaming]

Btw you're doing a great job building up a WinRT tlb. Not a fan of using it where there's alternatives but increasingly there's not-- would love to see you expand it for general purpose use. Tip: Preserve LongPtr equivalents with typedef [public] long LongPtr; that way it's easy for both your typelib and code using it to be updated to native tB for x64 support.
If you want it, I have a function that strips the offset and size of comments from tB's typelib to native syntax view to make copying out of a tlb easier.

It's a tB ActiveX DLL, I can't put any "typedef" in it, but it can be compiled as both 32-bit and 64-bit. I just reference it "as is" in VB6 when I need to use it but vbForums doesn't allow DLLs in attachments so I had to extract the tlb resource from it when I posted these WinRT sample projects. I guess for tB it could be made into a package instead of an ActiveX DLL.

[fafalone]

It's a tB ActiveX DLL, I can't put any "typedef" in it, but it can be compiled as both 32-bit and 64-bit. I just reference it "as is" in VB6 when I need to use it but vbForums doesn't allow DLLs in attachments so I had to extract the tlb resource from it when I posted these WinRT sample projects. I guess for tB it could be made into a package instead of an ActiveX DLL.

Oh thought you were going the other way.

#If Win64 = 0 Then
Public Enum LongPtr: [_]: End Enum
#End If


should preserve it when you build a tlb for vb6.

I'm hoping tB gets Alias support soon... only that, dispinterface, and a couple other little things would bring it to feature parity with what it supports via TLB and completely eliminate the need for them.

[VanGoghGaming]

This is the only way I know how to make a tlb. Everything is already declared as LongPtr, tB automatically changes it to Long for 32-bit and LongLong for 64-bit at compile time.

[fafalone]

Right but it shouldn't if you use that enum instead, the local definition supersedes the outside type.

If you can figure out that WinRT stuff it would take you 10min to figure out a tlb via mktyplib/midl though.

[VanGoghGaming]

I am not using the ActiveX DLL outside VB6. It is not referenced in tB. If I need something from it in tB, I can just include the corresponding "twin" file with interface definitions. That's why I said it could be made into a package. Maybe I could publish one if you want to take a look at it.

You are probably right, it shouldn't take long to figure out mktyplib/midl but I'm still reluctant to start from scratch and I'm definitely not a fan of IDL syntax which is prone to so many errors. It is a lot more convenient to write interface definitions in the tB IDE (with all its quirks) using familiar VB-friendly syntax. tB will tell you in real time if you made a typing mistake or what interfaces still need to be declared. When there are no more errors in the immediate panel then you can be sure everything is ready to be compiled for testing.

WinRT stuff is definitely not hard to figure out once you overcome an initial learning curve that is inevitable when you are not familiar with .NET concepts. For example, each async method returns an IAsyncOperation of the desired type and in turn that invokes its corresponding IAsyncOperationCompletedHandler that can be implemented in VB/tB.

Also, Arrays are called Vectors, each Vector has a corresponding VectorView interface that is read-only and implements a pair of IIterable/IIterator interfaces that are used for enumerating the Vector (this is the "For Each..." syntax in .NET). All these interfaces have the same methods, just the parameter type is different and therefore they have a different GUID for each parameter type (Vector of strings, integers, booleans, objects, etc).

Exactly the same thing applies for a collection (which is called Map) where each element is a KVP (KeyValuePair) with the key always of type string and the value of whatever type you want to have in the collection.

Once you have figured this out, it all becomes just a tedious grind of copy-pasting interfaces and looking up GUIDs...

[tmighty2]

You have this:

Function GetClassNameW(hwnd As Long, lpClassName As String, nMaxCount As Long) As Long
    Member of oleexp.user32

Shouldn't it rather be

Public Declare Function GetClassNameW Lib "user32" _
    (ByVal hwnd As Long, ByVal lpClassName As Long, ByVal nMaxCount As Long) As Long

?

[wqweto]

Object Browser in IDE does *not* show ByVal/ByRef param type on methods from typelibs and normal projects too.

Btw, you can use vbNullString to pass NULL to an As String parameter.

cheers,
</wqw>

[fafalone]

And to further clarify, VB supports Unicode Strings in typelibs.

[tmighty2]

I mean Long vs. String. I thought that W requires a String pointer. I am asking because in my projects I have a lot of multiple declares, and I am just trying to consolidate them.

[SaschaT]

Hi Jon,
it starts to confuse me: this thread slightly tends to be more and more a tB thread. Although the work for oleexp is the base for both universes they are not the same. I am not using tB (besides some experiments) but extensively use olexep.tlb in my VB6 projects. So I have to sort out here which posts are refering VB6 and which tB. IMO theese should be devided into two separate threads.
Another example for this is your github rep. The source for oleexp is included there but not updated to the current version(s). So it makes no sense for me to collaborate on github.
Background: At the moment I am working on a DirectShow project. I decided to switch back to DS from MF because it is not supported in the same way as DS was. For more advanced tasks it is much easier to develop using DS - MF is a nightmare here. (I constantly watch the blog posts on alax.info). So I found several missing DS components in oleexp (e.g. IMediaSeeking, IMediaParamInfo, IMediaParams, DMO parts, ...) and expanded ext_dshow.odl myself to make my own TLB. Works now but it is cumbersome to update this include component in every new version of oleexp you publish.
If the oleexp source would reside on github I could participate instead of always doing my private work. But only if it was separate from tB. Sure I could post my modifications to ext_dshow.odl here in the thread but it would be more comfortable to make changes on github (commited by you). You called it an opensource project, so github would be the right way. Your opinion?

[fafalone]

I mean Long vs. String. I thought that W requires a String pointer. I am asking because in my projects I have a lot of multiple declares, and I am just trying to consolidate them.

Not if the declare is in a typelib and typed right, and it's an input. If it's not in a typelib, such as Declare statements in .frm, .bas etc, then yes you need Long/StrPtr in VB6. tB you can use DeclareWide instead of Declare to disable ANSI conversion and use String for _WSTR/WCHAR* Unicode arguments.

[fafalone]

Hi Jon,
it starts to confuse me: this thread slightly tends to be more and more a tB thread. Although the work for oleexp is the base for both universes they are not the same. I am not using tB (besides some experiments) but extensively use olexep.tlb in my VB6 projects. So I have to sort out here which posts are refering VB6 and which tB. IMO theese should be devided into two separate threads.
Another example for this is your github rep. The source for oleexp is included there but not updated to the current version(s). So it makes no sense for me to collaborate on github.
Background: At the moment I am working on a DirectShow project. I decided to switch back to DS from MF because it is not supported in the same way as DS was. For more advanced tasks it is much easier to develop using DS - MF is a nightmare here. (I constantly watch the blog posts on alax.info). So I found several missing DS components in oleexp (e.g. IMediaSeeking, IMediaParamInfo, IMediaParams, DMO parts, ...) and expanded ext_dshow.odl myself to make my own TLB. Works now but it is cumbersome to update this include component in every new version of oleexp you publish.
If the oleexp source would reside on github I could participate instead of always doing my private work. But only if it was separate from tB. Sure I could post my modifications to ext_dshow.odl here in the thread but it would be more comfortable to make changes on github (commited by you). You called it an opensource project, so github would be the right way. Your opinion?

Apart from followups to specific comments I always say 'in tB' or similar. It's not exactly the same but it's in the sense of VB3 is still the same language; it's de facto VB7, albeit in a beta stage of the kind Microsoft doesn't do publicly. So there's just too much overlap to fully sequester the two, especially since WinDevLib is the official follow-up to oleexp, suggested to use in place of oleexp in tB, and oleexp is the base for its interfaces and I try to keep them reasonably compatible (also APIs, lots of work adding overloads for oleexp compat).

I know some people don't use tB yet and some projects aren't compatible yet, but I'm not going to pretend it's like I'm here talking about Python, .NET, or some other off topic different language. oleexp.tlb adds LongPtr to VB6 and the code differences range from none to minor such that I consider tB code a perfectly serviceable response to questions... this is my hobby not my job.

The copy of oleexp in the WDL repo is purely for reference; you'll find no links to it anywhere and I haven't even mentioned it. Definitely not meant as the main source or for editing; it's not even complete, no addon bas files or compiled tlbs.

I've been keeping my VB6 projects to the VB6 CodeBank... but even with tB I'm still a bit of a luddite with git for my hobby projects... when someone submits a PR I just manually merge it into my local source by copy/paste from the diff, source has no automatic sync ability.

If you've expanded DirectShow I'd be excited to include it in the main source and credit you for it (I've recently started some expansion too); but are the changes so much more than exp_show.odl that you couldn't just attach it here? Then i'll make sure the new releases are in sync with the latest file posted here (and yes you don't care but they'll also appear in WDL first, signatures matched with your version).

If the changes involve a bunch of files yeah I guess github makes more sense; let me know if that's the case and I'll make a dedicated git repo so it's easier for you.

[SaschaT]

Ok, understood.
No, in summary there are not so much modifications and additions I did to the source. As for you VB6 is just a hobby and I spend most of my time with python. Unfrequently I stumble upon an interesting topic and launch VB6 because there is no faster way for me to develop some routines.
But I really forgot all the places where I added or altered the source, so I will have to do a text comparison to the orginals and extract them. Will post them here - probably along with a graph based DirectShow demo similar to this one: https://www.vbforums.com/showthread....=1#post5612190
(BTW: I can reveal that I change most lpwstr/bstr parameters I find to long . There a still many places.)

[VanGoghGaming]

(BTW: I can reveal that I change most lpwstr/bstr parameters I find to long . There a still many places.)

Long is king, he just doesn't want to admit it!

[fafalone]

It's a compatibility issue. Probably 99% of lpwstr use is from the original olelib base... In a ton of commonly used stuff so I didn't want to just break large amounts of existing code .. still don't.. can merge additions as is, or if there's an lpwstr*, but can't just break everything...
BSTR is another matter though. That's the exact type of String VB6 uses, length prefix and all. So I don't see a good reason to change that.

This project was never updated to midl because midl prohibits redefinitions-- important for this. If you *always* want them as Long you should be able to simply redefine in typedef.odl

typedef long LPWSTR;
typedef long BSTR;

then the individual instances don't need to be modified and you can compile a custom version easily.

[SaschaT]

It's a compatibility issue. Probably 99% of lpwstr use is from the original olelib base... In a ton of commonly used stuff so I didn't want to just break large amounts of existing code .. still don't.. can merge additions as is, or if there's an lpwstr*, but can't just break everything...

Well that's the reason I began to change it. Several projects didn't compile after I updated from oleexp V4.xx to 6.xx or so: Type mismatch. Had to modify all the places from String to StrPtr().
Retrieving a pointer only may be also a (small) performance advantage in some cases: depending on a function result I use the pointer (SysAllocString) or not.

If you *always* want them as Long you should be able to simply redefine in typedef.odl

typedef long LPWSTR;
typedef long BSTR;

then the individual instances don't need to be modified and you can compile a custom version easily.

Good hint!

[wqweto]

Btw, if you mark these typedefs [public] you'll get type hints in VBIDE the way you see OLE_COLOR and similar Long aliasing types.

cheers,
</wqw>

[smileyoufu]

err delete

[xiaoyao]

Function CreateCoreWebView2EnvironmentWithOptions(browserExecutableFolder As LongPtr, UserDataFolder As LongPtr, environmentOptions As ICoreWebView2EnvironmentOptions, environmentCreatedHandler As ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler) As Long
can't use browserExecutableFolder
can it use bstr (browserExecutableFolder as string)
or ?browserExecutableFolder as long?

webview sdk :109.0.1518.78 x86 fixed,i can't set by browserExecutableFolder
only can use by install ,and write to reg key:

[HKEY_CURRENT_USER\Software\Microsoft\EdgeUpdate\ClientState\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}]
"EBWebView"="C:\\Users\\admin\\AppData\\Local\\Microsoft\\EdgeWebView\\Application\\109.0.1518.7 8"
"pv"="109.0.1518.78"

maybe need make 2 tlb:x86 oleexp.tlb,x64 oleexp.tlb?

Sub Navigate(URI As Long)
oleexp.ICoreWebView2 ???

can it use URI AS STRING?


Public Function DocumentTitle() As String
DocumentTitle = GetBstr(webA.DocumentTitle)
End Function

[fafalone]

-Use StrPtr(str) where you see a ByVal Long and need to pass a String. If it's ByRef Long or function return, use a helper like LPWSTRtoStr found in most of my

-oleexp.tlb will always be x86 only. For x64, my package "Windows Development Library for twinBASIC" (WinDevLib) should be used instead. It covers 100% of oleexp.tlb plus far, far more, including more recent WebView2 updates.

[fafalone]

I'm officially deprecating oleexp into maintenance mode.


MAINTENANCE MODE: oleexp will no longer receive feature updates, only bug fixes, as I've moved to twinBASIC, the backwards compatible true successor to VB6. There, oleexp is superseded by my Windows Development Library for twinBASIC (WinDevLib) project, which contains 100% of oleexp plus 10,000+ APIs and an increasingly large number of interfaces not available in this tlb, all with x64 support.

[VanGoghGaming]

[voxy]

Thanks for the past and for the future!

[fafalone]

Project Updated - Version 6.8

With the project going into maintenance mode, I'm releasing all previously completed work and pending bug fixes as a new version.

NOTE: The ridiculous attachment size constraints have once again caused the need to rearrange files: oleexp68-core.zip now only contains oleexp.tlb and mIID.bas. mPKEY and oleexpimp.tlb are now in oleexp68-addons.zip.

Changelog:

(oleexp 6.8 - Released 06 November 2025)
- **BREAKING CHANGE** :: Shell functions taking pidl arrays were inconsistently defined. Some took
  ByVal and some took ByRef (VarPtr(pidls(0)) vs just pidls(0)). For the sake of consistency, 
  correctness, and WDL API standards, SHCreateShellItemArray, SHCreateShellItemArrayFromIDLists, SHCreateDataObject,  
  SHCreateFileDataObject, and IDefaultFolderMenuInitialize::Initialize have now been changed to 
  use the more correct ByRef semantics. Where you passed VarPtr(pidls(0)) you'll need to change
  that to just pidls(0). 
-Added basic Direct3D 10 coverage
-IWICImageEncoder methods now use proper ID2D1Image type.
-ID2D1DeviceContext::CreateBitmapFromDxgiSurface, IWICBitmapDecoder::GetFrame, IWICImagingFactory::CreateFormatConverter last param to retval to match The trick's typelib and WinDevLib.
-Added additional Media Foundation interfaces/APIs from wmcontainer.h (100%)
-Added DirectShow BDA  
-(API Standards) Changed numerous byte array inputs typed as Byte to As Any to conform with standard.
-(Bug fix) OleCreatePropertyFrameIndirect incorrect alias.
-(Bug fix) WICImageParameters improperly substituted Long for D2D1_PIXEL_FORMAT (now used).
-(Bug fix) PROPVARIANT should have an additional 4 bytes for some data types (split as 2 Longs now instead of 1)
-(Bug fix) ISubItemCallback, IPropertyValue had incorrect methods.
-(Bug fix) ISecurityInformation::GetSecurity missing argument

[nebeln]

Just wondering, was CoClass for ShellFolderShortCut added?
When I realized that was missing I did hint you about that for a time ago. (CLSID_FolderShortCut).

[fafalone]

Yes it was added as FolderShortcut

[uuid(0afaced1-e828-11d1-9187-b532f1e9575d)
]
coclass FolderShortcut {
    [default] interface IShellLinkW;
    interface IPersistFile;
};

[Daniel Duta]

Hi fafalone, I noticed that your project link, "List of New Interfaces In OLEEXP (as of v5.01)", lists many interfaces exposed from WIC. I'm specifically interested in the IWICFormatConverter class, so I downloaded the latest version you suggested (v6.8). However, after referencing the library in my IDE, I wasn't able to find the class. Have you removed some classes in this latest version, or am I missing something? Thanks!

[fafalone]

It's there. VB6 has a bug where if an interface is the default for a coclass (an object you can create with New ...), only the coclass name is visible in the Object Browser and intellisense/autocomplete for Dim. But you can still declare a variable with it; Dim pFC As IWICFormatConverter and then you'll see the members come up in intellisense when you type pFC. etc.

[Daniel Duta]

It's there. VB6 has a bug where if an interface is the default for a coclass (an object you can create with New ...), only the coclass name is visible in the Object Browser and intellisense/autocomplete for Dim. But you can still declare a variable with it; Dim pFC As IWICFormatConverter and then you'll see the members come up in intellisense when you type pFC. etc.

Wow, you’re right. I’ve never seen anything like this before. Even though some of the classes are hidden, once they’re declared and referenced, all their methods become visible. A bit weird. Many thanks, fafalone!

[xiaoyao]

Maybe it's time to get a.net TLB wrapper that wraps common functions.

oleexp.tlbDnetExp. TLB, it can even cross platforms. It also provides XML and JSON format type library interfaces

[fafalone]

VanGoghGaming is doing that with WinRT, e.g. here..

Though I'm sure you'll be horrified that like oleexp.tlb the WinRT TLB is also several MB.