IStream.Read()

[Peter Larsen []]

Hi,

I have a problem using System.Runtime.InteropServices.ComTypes.IStream.

Sample using the Read() method:

if (IStreamObject != null)
{
IntPtr readBytes = IntPtr.Zero;
IStreamObject.Read(buffer, size, readBytes);
Result = readBytes.ToInt32();
}

The above code read data from a stream into a buffer. This works - the
buffer is filled with valid data.
The problem is that the number of bytes read (in readBytes) is always zero.

How am i suppose to know whether the call failed or not, if i dont have the
number of bytes read ?

BR
Peter

 

[Nicholas Paldino [.NET/C# MVP]]

Peter,

If there are no bytes returned (the readBytes parameter is zero) then
that most likely means that you read past the end of the stream. At that
point, you should stop.

If the call fails for some reason, a COMException will be thrown. If
anything other than S_OK is returned as an HRESULT in a call to Read, (or
any method through COM interop, actually), then a COMException is thrown
with the HRESULT returned in the ErrorCode property.

Hope this helps.

 

[Jon Skeet [C# MVP]]

I have a problem using System.Runtime.InteropServices.ComTypes.IStream.

Sample using the Read() method:

if (IStreamObject != null)
{
IntPtr readBytes = IntPtr.Zero;
IStreamObject.Read(buffer, size, readBytes);
Result = readBytes.ToInt32();
}

The above code read data from a stream into a buffer. This works - the
buffer is filled with valid data.
The problem is that the number of bytes read (in readBytes) is always zero.

I don't recall doing interop with IntPtr myself, but the idea is that
you pass in a *pointer* to an int and the data within that pointer is
set by the Read method. You're passing in IntPtr.Zero, i.e. "I don't
care about how many bytes were read".

Try this:

unsafe
{
int readBytes=0;
IStreamObject.Read(buffer, size, new IntPtr(&readBytes));
Result = readBytes;
}

Jon

 

[Willy Denoyette [MVP]]

Hi,

I have a problem using System.Runtime.InteropServices.ComTypes.IStream.

Sample using the Read() method:

if (IStreamObject != null)
{
IntPtr readBytes = IntPtr.Zero;
IStreamObject.Read(buffer, size, readBytes);
Result = readBytes.ToInt32();
}

The above code read data from a stream into a buffer. This works - the
buffer is filled with valid data.
The problem is that the number of bytes read (in readBytes) is always
zero.

How am i suppose to know whether the call failed or not, if i dont have
the number of bytes read ?

BR
Peter

What you are passing as third argument is wrong, you are passing a null
pointer, while the function expects a pointer to an int.
I would expect this to throw an exception, as the underlying COM method
should check all pointers on validity and return an HRESULT =
STG_E_INVALIDPOINTER when one of them is null.
From what stream are you actually reading?

WIlly.

 

[Nicholas Paldino [.NET/C# MVP]]

Read allows the last pointer passed in to be null. From the
documentation for IStream from the Platform SDK:

pcbRead
[out] A pointer to a ULONG variable that receives the actual number of bytes
read from the stream object.
You can set this pointer to NULL. In this case, this method does not
return the number of bytes read.

 

[Willy Denoyette [MVP]]

Read allows the last pointer passed in to be null. From the
documentation for IStream from the Platform SDK:

pcbRead
[out] A pointer to a ULONG variable that receives the actual number of
bytes read from the stream object.
You can set this pointer to NULL. In this case, this method does not
return the number of bytes read.

From the latest greatest Windows SDK docs:

pcbRead
[out] A pointer to a ULONG variable that receives the actual number of bytes
read from the stream object.

and from MSDN:
http://msdn2.microsoft.com/en-us/library/aa380011.aspx

http://msdn2.microsoft.com/en-us/library/system.runtime.interopservices.comtypes.istream.read.aspx

Note this:
For more information, see the existing documentation for
ISequentialStream::Read in the MSDN library.

You see, nothing about NULL to be allowed.

This :
http://msdn2.microsoft.com/en-us/library/ms890697.aspx

effectively talks about NULL to be allowed....
<snip
pcbRead
[out] Pointer to a ULONG variable that receives the actual number of bytes
read from the stream object.
You can set this pointer to NULL to indicate that you are not interested in
this value. In this case, this method does not provide the actual number of
bytes read.
/snip>

but this is about the ole32 implementation for Windows CE.

Willy.

 

[Nicholas Paldino [.NET/C# MVP]]

In this case, I would say that the documentation for the actual .NET
type is superceeded by the documentation for the IStream interface itself,
since the .NET type is nothing more than a representation of the COM
interface, and implementations should stick to the contract (in word and
spirit) defined by the COM interface, not what the .NET documentation
chooses to expose about the IStream interface.

Which brings up an interesting point. I agree, the current
documentation about the COM IStream interface indicates nothing about null
for that parameter. I would argue that the previous documentation trumps
the current documentation here because of the immutability of COM
interfaces. While immutability most certainly applies to the actual
physical structure of the interfaces, I believe it applies to the semantics
(the spirit) of the contract as well.

I can't imagine that MS, a company obsessed with backwards
compatability, suddenly decided, especially for an already published
interface as common as IStream, that all implementations are expected to
perform a null value check on that parameter and error when it was
previously published that they did not have to. I can see it going the
other way (initially saying that all implementations had to check for null,
then saying they could optionally check for null), but it doesn't make sense
in this case.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Read allows the last pointer passed in to be null. From the
documentation for IStream from the Platform SDK:

pcbRead
[out] A pointer to a ULONG variable that receives the actual number of
bytes read from the stream object.
You can set this pointer to NULL. In this case, this method does not
return the number of bytes read.

From the latest greatest Windows SDK docs:

pcbRead
[out] A pointer to a ULONG variable that receives the actual number of
bytes read from the stream object.

and from MSDN:
http://msdn2.microsoft.com/en-us/library/aa380011.aspx

http://msdn2.microsoft.com/en-us/library/system.runtime.interopservices.comtypes.istream.read.aspx

Note this:
For more information, see the existing documentation for
ISequentialStream::Read in the MSDN library.

You see, nothing about NULL to be allowed.

This :
http://msdn2.microsoft.com/en-us/library/ms890697.aspx

effectively talks about NULL to be allowed....
<snip
pcbRead
[out] Pointer to a ULONG variable that receives the actual number of bytes
read from the stream object.
You can set this pointer to NULL to indicate that you are not interested
in this value. In this case, this method does not provide the actual
number of bytes read.
/snip>

but this is about the ole32 implementation for Windows CE.

Willy.

 

[Willy Denoyette [MVP]]

In this case, I would say that the documentation for the actual .NET
type is superceeded by the documentation for the IStream interface itself,
since the .NET type is nothing more than a representation of the COM
interface, and implementations should stick to the contract (in word and
spirit) defined by the COM interface, not what the .NET documentation
chooses to expose about the IStream interface.

Which brings up an interesting point. I agree, the current
documentation about the COM IStream interface indicates nothing about null
for that parameter. I would argue that the previous documentation trumps
the current documentation here because of the immutability of COM
interfaces. While immutability most certainly applies to the actual
physical structure of the interfaces, I believe it applies to the
semantics (the spirit) of the contract as well.

I can't imagine that MS, a company obsessed with backwards
compatability, suddenly decided, especially for an already published
interface as common as IStream, that all implementations are expected to
perform a null value check on that parameter and error when it was
previously published that they did not have to. I can see it going the
other way (initially saying that all implementations had to check for
null, then saying they could optionally check for null), but it doesn't
make sense in this case.

Don't know about the older documentation, I don't have access to the older
platform docs at the moment, all I find is that there is no mention of NULL
to be allowed in the on-line docs, nor on MSDN nor in the current Windows
SDK docs.
The IStream.Read docs in System.Runtime.InteropServices.ComTypes
does not mention NULL to be allowed, now if you do as the remark says (For
more information, see the existing documentation for ISequentialStream::Read
in the MSDN library.),
you end here:
http://msdn2.microsoft.com/en-us/library/aa380011.aspx
, again no trace of NULL to be allowed.

There must be something really wrong here, or the current docs are missing a
clause or the old docs were wrong , or the implementation (of ole32 on
Windows - not CE!!) has changed, or the CLR contains a hack to allow for
null pointers. I'll put together some code to find out what really happens
under the covers, and come back when I found out what.

Willy.

 

[Willy Denoyette [MVP]]

In this case, I would say that the documentation for the actual .NET
type is superceeded by the documentation for the IStream interface itself,
since the .NET type is nothing more than a representation of the COM
interface, and implementations should stick to the contract (in word and
spirit) defined by the COM interface, not what the .NET documentation
chooses to expose about the IStream interface.

Which brings up an interesting point. I agree, the current
documentation about the COM IStream interface indicates nothing about null
for that parameter. I would argue that the previous documentation trumps
the current documentation here because of the immutability of COM
interfaces. While immutability most certainly applies to the actual
physical structure of the interfaces, I believe it applies to the
semantics (the spirit) of the contract as well.

I can't imagine that MS, a company obsessed with backwards
compatability, suddenly decided, especially for an already published
interface as common as IStream, that all implementations are expected to
perform a null value check on that parameter and error when it was
previously published that they did not have to. I can see it going the
other way (initially saying that all implementations had to check for
null, then saying they could optionally check for null), but it doesn't
make sense in this case.

Ok I ran some tests, and I can see why this NULL pointer remark was removed
from the latest docs. It's up to the implementor of ISequentialStream to
accept null or not, so it's part of the interface contract to accept null
for this parameter.
Sure, a check for null is always required, as writing to a null pointer
would AV, but he's free to return an STG_E_INVALIDPOINTER (see
ISequentialStream docs) when he sees fit.

When calling an implementation that returns STG_E_INVALIDPOINTER from .NET,
you will get an:

System.Runtime.InteropServices.COMException (0x80030009): Invalid pointer
error. (Exception from HRESULT: 0x80030009 (STG_E_INVALIDPOINTER)
Note that some implementations are inconsistent in the way they report
conditions, you'll have to check for all possible conditions.

Willy.

 

[Jon Skeet [C# MVP]]

The IStream.Read docs in System.Runtime.InteropServices.ComTypes
does not mention NULL to be allowed, now if you do as the remark says (For
more information, see the existing documentation for ISequentialStream::Read
in the MSDN library.),
you end here:
http://msdn2.microsoft.com/en-us/library/aa380011.aspx
, again no trace of NULL to be allowed.

It depends on what you mean by "the MSDN library". In the offline
version of the MSDN library (which is what I'd certainly look it up in
normally) it *does* specify it.

There must be something really wrong here, or the current docs are missing a
clause or the old docs were wrong , or the implementation (of ole32 on
Windows - not CE!!) has changed, or the CLR contains a hack to allow for
null pointers. I'll put together some code to find out what really happens
under the covers, and come back when I found out what.

My guess is that the docs are wrong/incomplete. I'm surprised at the
difference between the offline and online docs though

 

[Willy Denoyette [MVP]]

It depends on what you mean by "the MSDN library". In the offline
version of the MSDN library (which is what I'd certainly look it up in
normally) it *does* specify it.

I mean both, the on-line MSDN Library (msdn2), this one holds the latest
update, and,
Off-line, the latest MSDN from the subscribers download site (Build date:
2/1/2007), and the version that comes with Orcas Beta1 both have the same
description for both IStream.Read and ISequentialStream - no mention about
null pointers.

My guess is that the docs are wrong/incomplete. I'm surprised at the
difference between the offline and online docs though

Incomplete, I agree, wrong? (take care [1]) possibly, confusing -
certainly....

This is a general complaint of mine, the .NET MSDN docs are produced by
"robots", no longer by humans, they offer not much more than what's actually
documented in the .NET library code, that is the minimum, programmers are no
technical writers and having both is a slow and too expensive process, even
for MSFT , so they expect from us that we add the missing pieces and
possibly correct what's wrong (see the MSDN's Community contents), which is
not a bad idea after all.
[1] Finally it will be the community's fault the docs are wrong ;-).


Willy.

 

[Jon Skeet [C# MVP]]

I mean both, the on-line MSDN Library (msdn2), this one holds the latest
update, and,
Off-line, the latest MSDN from the subscribers download site (Build date:
2/1/2007), and the version that comes with Orcas Beta1 both have the same
description for both IStream.Read and ISequentialStream - no mention about
null pointers.

Odd - I've got the same quote as Nick had in ISequentialStream::Read,
and I'm sure I've been installing all the latest disks... Is there a
decent way of finding the version of any particular file? The URL in
the offline MSDN is
ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.WIN32COM.v10.en/oledb/htm/
oledbisequentialstream__read.htm

My guess is that the docs are wrong/incomplete. I'm surprised at the
difference between the offline and online docs though

Incomplete, I agree, wrong? (take care [1]) possibly, confusing -
certainly....

I think it counts as "wrong" if it's been introduced into the
documentation as if it had always been part of the interface contract,
when older implementations could have legitimately returned the
appropriate error code instead.

This is a general complaint of mine, the .NET MSDN docs are produced by
"robots", no longer by humans, they offer not much more than what's actually
documented in the .NET library code, that is the minimum, programmers are no
technical writers and having both is a slow and too expensive process, even
for MSFT , so they expect from us that we add the missing pieces and
possibly correct what's wrong (see the MSDN's Community contents), which is
not a bad idea after all.
[1] Finally it will be the community's fault the docs are wrong ;-).

Indeed. I'm ashamed to say I haven't found time to contribute to the
MSDN pages, beyond mailing appropriate people when I've spotted
mistakes.

 

[Willy Denoyette [MVP]]

Odd - I've got the same quote as Nick had in ISequentialStream::Read,
and I'm sure I've been installing all the latest disks... Is there a
decent way of finding the version of any particular file? The URL in
the offline MSDN is
ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.WIN32COM.v10.en/oledb/htm/
oledbisequentialstream__read.htm

Hmmm, I see ....
I'm on -
ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.WIN32COM.v10.en/stg/stg/isequentialstream_read.htm
-
see, ISTREAM is part of the "structured storage" interfaces, while you are
at the "oledb programmers reference " stuff, it's not surprising to find
this here, it's old hat that never gest updated in the post OLEDB age ;-),
IMO it doesn't even belong there.

Also take note that I did not install from the distribution, but I install
the latest download available from the MSDN subscribers area, more exactly,
the April 2007 MSDN Library (en_msdn_library_2007_04_dvd_X13-63638.iso
ISO-9660 DVD Image ).

My guess is that the docs are wrong/incomplete. I'm surprised at the
difference between the offline and online docs though

Incomplete, I agree, wrong? (take care [1]) possibly, confusing -
certainly....

I think it counts as "wrong" if it's been introduced into the
documentation as if it had always been part of the interface contract,
when older implementations could have legitimately returned the
appropriate error code instead.

Return values are never part of the contract, a COM interface is carved in
stone, right, that means you cannot change the return type nor the argument
types and number of arguments, but the value returned is not part of the
contract
The documentation specifies the "standard" return values, like S_OK, E_FAIL
etc.., but the implementor of an interface method is free to return what he
sees fit.

Now, when you look at the ISequential::Read method, you'll see that
STG_E_INVALIDPOINTER is one of the values that could "possibly" be returned
from a typical implemetation. If the implementor , requires the pointers to
be valid, it can return STG_E_INVALIDPOINTER when one of them is not. I have
found one implementation that actually does that. So IMO, the parameter
description was too general, in the sense that it makes you fell that null
is valid irrespective the implementaton of the interface.
So, again be prepared to get an exception thrown on you when passing null,
note that this is extremely rare to happen, besides, you should never pass a
null pointer, as it's nearly impossible to know what exactly has been
returned from the callee (0 values is valid data to be returned in the
buffer).
..

This is a general complaint of mine, the .NET MSDN docs are produced by
"robots", no longer by humans, they offer not much more than what's
actually
documented in the .NET library code, that is the minimum, programmers are
no
technical writers and having both is a slow and too expensive process,
even
for MSFT , so they expect from us that we add the missing pieces and
possibly correct what's wrong (see the MSDN's Community contents), which
is
not a bad idea after all.
[1] Finally it will be the community's fault the docs are wrong ;-).

Indeed. I'm ashamed to say I haven't found time to contribute to the
MSDN pages, beyond mailing appropriate people when I've spotted
mistakes.

Same here, but I'm not ashamed ;-)

Willy.

 

[Peter Larsen []]

Thank you for your comments.

Let me try to wrap it up.

The stream points to a file on the local drive - e.g. a *.txt file.

I use the System.Runtime.InteropServices.ComTypes.IStream interface from
dotNet 2.0:

namespace System.Runtime.InteropServices.ComTypes
{
[Guid("0000000c-0000-0000-C000-000000000046")]
[InterfaceType(1)]
public interface IStream
{
void Read(byte[] pv, int cb, IntPtr pcbRead);

etc etc.

The type is an IntPtr, not an ULONG. Also its a bit confusing that there is
no return value.
What should i do to make this work ?

/Peter

 

[Willy Denoyette [MVP]]

Thank you for your comments.

Let me try to wrap it up.

The stream points to a file on the local drive - e.g. a *.txt file.

I use the System.Runtime.InteropServices.ComTypes.IStream interface from
dotNet 2.0:

namespace System.Runtime.InteropServices.ComTypes
{
[Guid("0000000c-0000-0000-C000-000000000046")]
[InterfaceType(1)]
public interface IStream
{
void Read(byte[] pv, int cb, IntPtr pcbRead);

etc etc.

The type is an IntPtr, not an ULONG. Also its a bit confusing that there
is no return value.
What should i do to make this work ?

/Peter

Peter,
The intPtr must point to an int, on return you need to compare the value
pointed to by pcbRead against the value passed in cb.
Here is something to get you started.....

...
// Allocate space to hold an Int32, the pointer returned points to the
allocate Int32
IntPtr pcbRead = Marshal.AllocHGlobal(sizeof(int));
// pass the pointer as third argument
IStreamObject.Read(buffer, size, pcbRead);
// read the int value returned from the Read
int bytesReturned = Marshal.ReadInt32(pcbRead);
// comapre against the size of the buffer
if(bytesReturned == size)
// handle size data and go on reading from the stream...
...
if(bytesReturned < size )
// At end of the stream, bytesReturned is the amount of valid bytes
in the buffer, stop reading from the stream
....
if(bytesReturned == 0)
// no more data to read from the stream
....
// Free the unmanaged memory when done!!!
Marshal.FreeHGlobal(pcbRead);

Willy.

 

[Peter Larsen []]

Ahh, now i understand what you mean.
I will try this and let you know the result.

/Peter

 

[Jon Skeet [C# MVP]]

Thank you for your comments.

Let me try to wrap it up.

The stream points to a file on the local drive - e.g. a *.txt file.

I use the System.Runtime.InteropServices.ComTypes.IStream interface from
dotNet 2.0:

namespace System.Runtime.InteropServices.ComTypes
{
[Guid("0000000c-0000-0000-C000-000000000046")]
[InterfaceType(1)]
public interface IStream
{
void Read(byte[] pv, int cb, IntPtr pcbRead);

etc etc.

The type is an IntPtr, not an ULONG. Also its a bit confusing that there is
no return value.
What should i do to make this work ?

I thought I covered this in another post:

unsafe
{
int readBytes=0;
IStreamObject.Read(buffer, size, new IntPtr(&readBytes));
Result = readBytes;
}

You might want to make it a uint instead of an int, if you're trying to
read more than 2GB at a time...

 

[Willy Denoyette [MVP]]

Thank you for your comments.

Let me try to wrap it up.

The stream points to a file on the local drive - e.g. a *.txt file.

I use the System.Runtime.InteropServices.ComTypes.IStream interface from
dotNet 2.0:

namespace System.Runtime.InteropServices.ComTypes
{
[Guid("0000000c-0000-0000-C000-000000000046")]
[InterfaceType(1)]
public interface IStream
{
void Read(byte[] pv, int cb, IntPtr pcbRead);

etc etc.

The type is an IntPtr, not an ULONG. Also its a bit confusing that there
is
no return value.
What should i do to make this work ?

I thought I covered this in another post:

unsafe
{
int readBytes=0;
IStreamObject.Read(buffer, size, new IntPtr(&readBytes));
Result = readBytes;
}

You might want to make it a uint instead of an int, if you're trying to
read more than 2GB at a time...

This will require 64bit Windows, you can't allocate such large buffer on 32
bit, even 2GB won't work.


Willy.

 

[Willy Denoyette [MVP]]

Thank you for your comments.

Let me try to wrap it up.

The stream points to a file on the local drive - e.g. a *.txt file.

I use the System.Runtime.InteropServices.ComTypes.IStream interface from
dotNet 2.0:

namespace System.Runtime.InteropServices.ComTypes
{
[Guid("0000000c-0000-0000-C000-000000000046")]
[InterfaceType(1)]
public interface IStream
{
void Read(byte[] pv, int cb, IntPtr pcbRead);

etc etc.

The type is an IntPtr, not an ULONG. Also its a bit confusing that there
is
no return value.
What should i do to make this work ?

I thought I covered this in another post:

unsafe
{
int readBytes=0;
IStreamObject.Read(buffer, size, new IntPtr(&readBytes));
Result = readBytes;
}

You might want to make it a uint instead of an int, if you're trying to
read more than 2GB at a time...

This will require 64bit Windows, you can't allocate such large buffer on
32 bit, even 2GB won't work.


Willy.

Actually it won't even work on 64bit Windows as the largest byte[] is
limited to 2GB on the current CLR.

Willy.

 

[Jon Skeet [C# MVP]]

This will require 64bit Windows, you can't allocate such large buffer on 32
bit, even 2GB won't work.

Good catch - so my code was inadvertently okay to start with