Issues with API function ReadFile

[Ketchup]

Hello everyone,

I have been stuck with this problem for quite some time now. I am working in VB.NET, using framework 1.0. I have to keep the compatibility down to the original .NET framework as much as possible. I am forced to use API calls for several functions, one of which is ReadFile. The reason is because the framework seems to use ANSI versions of all API functions, limiting the MAX_PATH for filenames to about 260 chars for everything in System.IO. API Wide functions (Unicode) do not have this limitation.

I am having issues implementing the ReadFile function. I seem to only get various exceptions whenever I try to use it. It's declared as follows:

<DllImport("kernel32", EntryPoint:="ReadFile", CharSet:=CharSet.Unicode, SetLastError:=True, _
ExactSpelling:=True, CallingConvention:=CallingConvention.StdCall)> _
Shared Function ReadFile(ByVal hFile As Integer, ByRef lpBuffer As Object, _
ByVal nNumberOfBytesToRead As Integer, ByRef lpNumberOfBytesRead As Integer, _
ByRef lpOverlapped As OVERLAPPED) As Integer

End Function

I believe the issue is with the lpBuffer arguement. It's an <out> arguement that basically populates a buffer with the bytes read from the file. In C++ its declared as a long void pointer.

I have tried various ways of using this function, passing various types of variables to it. There is always an exception though. For example, this implementation throws an System.ExecutionEngineException exception.

Dim cBuff(4096) as Char
for i = 0 to cBuff.Length -1
cBuff(i) = " "
Next
iRetVal = ReadFile(hFlHandle, cBuff, 100, iBytesRead, OL)

OL, iBytesRead, and hFlHandle are all declared eariler. The hFlHandle is valid.

When I use a string for the buffer, I get the "System.Runtime.InteropServices.InvalidOleVariantTypeException: Specified OLE variant is invalid" exception.

Dim sBuffer as String = space(100)
iRetVal = ReadFile(hFlHandle, sBufferPtr, sBuffer.Length, iBytesRead, OL)

I am not entirely sure what the problem is. I must be missing something. Has anyone used the ReadFile function (or anything that requires an LPVOID passed to it) in VB.NET? Can anyone shine some light on this?

Thanks,

Dmitry

 

[mayayana]

This group (winapi) is for VB (mainly v. 5 and 6). Your post
is about VB.Net. VB and VB.Net are entirely different, so a
VB answer would leave you even more confused. The winapi
group should be dropped from your postings.

For VB.Net you can also try the groups below, or any other
group with "dotnet" or "vsnet" in the name. If it doesn't
include "dotnet" then it's not .Net.

microsoft.public.dotnet.general
microsoft.public.dotnet.languages.vb
microsoft.public.vsnet.general

 

[Tom Dacon]

This group (winapi) is for VB (mainly v. 5 and 6).

You new here?

Tom Dacon
Dacon Software Consulting

 

[Ken Halter]

You new here?

More like the OP's new here. He's the one crossposting between languages.

 

[Ketchup]

Tom,

You are a genius! Switching the Object type to an array of Bytes and
passing it ByVal instead of ByRef worked like a charm.

Thank you!

dmitry

P.S. I didn't know that framework used W functions. It really would be
nice if MS expanded support to the 32k char MAX_PATH of NTFS.

 

[Cor Ligthert[MVP]]

Ken,

We disagree, I find the crossposting from the OP complete correct when I
had read his question.
It could not have been better.

Luckily Tom could help him. I don't know from what newsgroup, as Tom is
active in more than one.

jmo

Cor

 

[David Thompson]

...

P.S. I didn't know that framework used W functions. It really would be
nice if MS expanded support to the 32k char MAX_PATH of NTFS.

They would like to. Here is what they have been thinking.

http://blogs.msdn.com/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx

http://blogs.msdn.com/bclteam/archi...-of-3-long-path-workarounds-kim-hamilton.aspx

http://blogs.msdn.com/bclteam/archive/2008/06/10/long-paths-in-net-part-3-of-3-kim-hamilton.aspx

Regards,

David

 

[Ketchup]

David, thanks for the links. I hadn't realized that there are such issues
with the Windows API. I am guessing the MAX_PATH limitation is a throw
back to FAT file system days. In the computer forensics world, we can't
alter the original paths and must preserve all of the metadata. This is
why I am having to revert to API calls for most of my System.IO needs. At
this point, I am getting pretty comfortable with it and enjoying it as well


The idea of moving away from string paths is interesting, as long as we will
still be able to produce a report with string paths that exceed the 260 char
limit. I guess I will wait an see.

thanks again!

 

[mayayana]

We disagree, I find the crossposting from the OP complete correct when I
had read his question.
It could not have been better.

microsoft.public.dotnet.languages.vb is fine
but the group microsoft.public.vb.winapi is a VB
(VB6 and lower) group. It doesn't matter that
it's an API question. VB and VB.Net are different
where the API is concerned, just as they're
different in other aspects. You're a regular on
the .Net groups. You should know which groups
are .Net and which are not.

 

[Ketchup]

Tom, thank you again. I saw that at first, but I was so excited to get
ReadFile working, that I didn't even give a try. After looking at your
example, I see the benefits of doing it the way you suggested. One issue
I have is that SafeHandle seems to be introduced in framework 2.0. I am
working in 1.0. That shouldn't stop this approach from working however.
I should be able to use IntPtr as a handle to the file. There are 9
versions of the constructor for FileStream, several of which accept a IntPtr
for the handle.

I think that I will rewrite my code to use the System.IO.FileStream classes.
Error handling is much easier with the framework.

thanks again!

 

[Ketchup]

Yep, it works with a plain IntPtr! Excellent. Thanks everyone!

 

[Thorsten Albers]

We disagree, I find the crossposting from the OP complete correct when I

had read his question.
It could not have been better.

Luckily Tom could help him. I don't know from what newsgroup, as Tom is
active in more than one.

As far as I can see Tom knows it better and has removed
microsoft.public.vb.winapi from the list of recipients of the answer which
seem to talk about. The only posting from Tom which made its way through to
m.p.vb.winapi is his "You new here?" question...

 

[Cor Ligthert[MVP]]

Yea I am sure that Tom knows,

However why should Ketchup knows it, not everybody is as good as you.

Bye

Cor