API Call Syntax Question

[Tifcin]

Hello WinBatch Community!

I'm working on a project for Offline Files on Windows 7.  In my case I've worked out several WMI scripts to get information I need but am having a newb lack of experience in Querying an API Interface.

MSDN shows the C++ Code and I've reviewed and worked with all the WMI calls but WMI has no call for what I need and the API Does:

API Link
http://msdn.microsoft.com/en-us/library/windows/desktop/bb530493(v=vs.85).aspx

So what I'm attempting is to gain the Offline Files Current Cache Size Limit which appears contained in the pcblimit of GetDiskSpaceInformation method however, I've no idea how to properly query it syntax wise.  Can someone point me in the correct direction?  Even Any MSDN API Calls that I can look up and translate into example API WBT scripts would be great too.

I'm relatively sure I need to perform an objectcreate to access the method but past that...

Any help would be appreciated.

Thanks,

Tifcin

[Deana]

Unfortunately the Offline API IOfflineFilesCache interface inherits from the IUnknown interface, which rules out COM Automation in WinBatch. WinBatch requires an IDispatch interface.
Reference: http://msdn.microsoft.com/en-us/library/windows/desktop/bb530486(v=vs.85).aspx

Maybe there is some other way to get this data using WinBatch. I will do some research.

[Tifcin]

Thank you - the fact that WinBatch is not capable of querying on IUnknown is helpful in and of itself. 

Tifcin

[Deana]

Is that information possibly stored in this registry key on your Windows 7 system: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CSC\? If so then you could maybe use the Registry function in WinBatch to query that information.

[Tifcin]

Unfortunately no - I wasn't able to find it in the registry.  I did attempt a couple of system snapshots but wasn't able to find any system changes while just manually changing the sliders cache size values. 

Potentially a value might be present in the registry if the size is forced via GPO which is possible, however, policy is currently 'not configured' for the max size.

[koawmfot]

this actually opens a larger question that I have...

how do we call 'interfaces' that DO inherit from IDispatch?  is there any examples of WB code that uses any interface?  I also am not exactly understating how this all works since IDispatch inherits from IUnknown??

for example, how would I write a WB that would use IShellWindows, any method, say 'Register'?

http://msdn.microsoft.com/en-us/library/windows/desktop/cc836570(v=vs.85).aspx

just a quick sample of the WB syntax... it doesn't have to exactly work, just a pointer in the direction.

many many thanks in advance!

[td]

The IUnknown interface is by definition the base interface of all COM interfaces so this whole discussion of IUnknown is really kinda irrelevant.

The COM interface that started this topic is what is known as an "early bind" interface in that it is primarily intended for use in native C++.  MSFT did this by design and the result is evidenced by the fact that the interface pointers are arrange in memory exactly the same way that pointers to C++ object members are arranged in memory.  MSFT does provide marshaling wrapper functionality for dotNet languages like c# through its interop services that do allow languages like c# access to some early bind interface.  Of course you are still just calling the C++ member pointers with the syntactic sugar of the "managed" language papered over the calls.  (There is a way to call COM interfaces using C and other native languages as well, but that requires a little more background so I wont go into it here.)

The other major COM interface type is called a late-binding interface.  This type of COM interface is based on the IDispatch interface and is what you are using when you use the WinBatch COM and dotNet subsystem.  MSFT intended the IDispatch interface for use by scripting languages like WinBatch.

To make things even more interesting many COM interfaces have both an early bind interface and a late binding interface through IDispatch so that can be used by both scripting and non scripting languages.

Of course, the above barely scratches the surface and doesn't even begin to cover things like in-process and out-of-process servers or the COM client/server threading model. 

In short, WinBatch makes use of many early bind interfaces internally and in extenders but does not provide a mechanism  for accessing them from scripts other than through their late bind interfaces via the WinBatch  COM subsystem.  This is primarily because it is an interpreted scripting language and not a 'native' or 'managed' language.