#fseek() rets -1
8 messages in this thread
James, I had a similar problem with lseek. After I RTFM I found the
SetFilePointer function. This works on file handles, not file pointers. Once
I switched to SetFilePointer, everything worked fine on NT. Haven't test yet
on Win32s on 3.1. If you can use the NT file functions, give it a try. -Paul
There are 2 Replies.
You know, we haave our code working to a point under NT. That point being it
works well enough for out sales force to take the code out to a customer with
the idea of showing them we are working on an NT port and this is what we have
so far. Well it works that well unfer under NT but when we try it under Win32s
file problems happen. Bad file handles, bad file pointers, file stat_buf data
bad. We are also using a beta of XVT/NT which may or may not have problems in
this area. Well back to the code.
James
There are 2 Replies.
I can't remember exactly what I wrote to you before. However, fstat always
seems to return -1 and the stuff in the struct is garbage. I have noticed that
Windows specific API calls seem to work with a lot more reliability, robustness
and so forth…
KQ
>>>You know, we haave our code working to a point under NT. That point being
it works well enough for out sales force to take the code out to a
customer with the idea of showing them we are working on an NT port and
this is what we have so far. Well it works that well unfer under NT but
when we try it under Win32s file problems happen. Bad file handles, bad
file pointers, file stat_buf data bad. We are also using a beta of XVT/NT
which may or may not have problems in this area. Well back to the code.
The debug builds of both Windows 3.1 and Win32s may come in very handy in
these cases, in tracking down what is failing. Make sure that you set your
Win32s debug flags to include messages about unthunked messages and APIs.
Lee
>>>James, I had a similar problem with lseek. After I RTFM I found the
SetFilePointer function. This works on file handles, not file pointers.
Once I switched to SetFilePointer, everything worked fine on NT. Haven't
test yet on Win32s on 3.1. If you can use the NT file functions, give it
a try. -Paul
You had lseek fail on Windows NT? Did you report that in this forum so that
we could fix the bug?
Lee
There is 1 Reply.
>You had lseek fail on Windows NT? Did you report that in this forum so that
>we could fix the bug?
Lee, I did have llseek fail on NT. The reason I didn't report it is that I
don't consider it a bug (more like a documentation deficiency). I opened the
file using CreateFile which returns a HANDLE but llseek expects an HFILE
handle. GetLastError reported an invalid file handle. So I dug deeper into
the Win32 docs. Unfortunately (for me) the Beta docs aren't cross referenced
very well. I found no references to the function SetFilePointer in the
descriptions for CreateFile or ReadFile. I couldn't readily find a list of all
file functions (by category, type, etc.) but eventually stumbled across a
reference to it somewhere. Nowhere did I see anything that said "don't call a
function with a bad argument or bad things will happen". Oops, I hope the
county's product liability lawyers are'nt lurking about.
So the fault is really my own, since I have 8 gigapiles of manuals, books &
cheat sheets open at any given time. I often use the Win16 SDK texts since
they are in separate books (yes, this has caused me some grief (time to stock
up on Grief Release <g> or pray for updated manuals).
Thanks for the concern – Paul
There are 2 Replies.
>> Unfortunately (for me) the Beta docs aren't cross referenced very well. >> I
found no references to the function SetFilePointer in the descriptions >> for
CreateFile or ReadFile.
Paul,
I find all the good indexing in the online help and really like the overviews
and "function groups". Sometimes though to find the overviews I first go into
a functions I know (CreateFile() in the case) and then press the buttons to go
"up" to the overview.
I rarely use the books, and most are still in their plastic "shrink wrap"
covers.
Stawsh
>>>So the fault is really my own, since I have 8 gigapiles of manuals, books
& cheat sheets open at any given time. I often use the Win16 SDK texts
since they are in separate books (yes, this has caused me some grief
(time to stock up on Grief Release <g> or pray for updated manuals).
Well, as Stan pointed out, the online manuals are very handy. The Full Text
Searching available in the final release of the Online manuals makes them
even more useful. In addition, there are updated manuals (for those who paid
for them) in the final update. (FWIW, I rarely have any open desk space
either, which is one reason I use the on-line manuals nearly exclusively.
The only reason that my manuals aren't still in shrinkwrap is that I took it
off as I put them on my bookshelf.)
Lee