Hi Boudewijn,
> I just tried StraceNT, here is part of the output generated when grops
> encounters 'x init'
>
> [T5140] CreateFileA(34f818, c0000000, 3, 22fcd0, ...) = 104
Based on WINE, CreateFileA is almost the same as CreateFileW which is
HANDLE WINAPI CreateFileW(LPCWSTR filename, DWORD access, DWORD sharing,
LPSECURITY_ATTRIBUTES sa, DWORD creation,
DWORD attributes, HANDLE template)
So we have access = 0xc0000000 and sharing = 3. So access is READ |
WRITE:
#define GENERIC_READ 0x80000000
#define GENERIC_WRITE 0x40000000
and sharing is READ | WRITE:
#define FILE_SHARE_READ 0x00000001L
#define FILE_SHARE_WRITE 0x00000002L
#define FILE_SHARE_DELETE 0x00000004L
> I don't think the c0000000 is correct, in every other call to
> CreateFileA the second parameter is 80000000.
That sounds fine; most of the other files are only being opened for
reading, GENERIC_READ. The trace continues
> [T5140] GetFileType(104, 0, 0, 1065, ...) = 1
> [T5140] SetFilePointer(104, ffffffff, 0, 2, ...) = ffffffff
> [T5140] GetLastError(ffffffff, 22fd2c, 22fcf8, 77122b19, ...) = 83
0x104 is what CreateFileA returned. SetFilePointer is
http://source.winehq.org/source/dlls/kernel32/file.c#L936
and the 2 being passed is FILE_END with 0xffffffff = -1 the `distance'.
It returns INVALID_SET_FILE_POINTER = ~0 and GetLastError is returning
0x83 = ERROR_NEGATIVE_SEEK.
That then ripples through the next set of trace.
> [T5140] GetLastError(ffffffff, 3, 770ee2d4, 770f4fe0, ...) = 83
> [T5140] FlsGetValue(3, ffffffff, 3, 770ee2d4, ...) = 3407d8
> [T5140] SetLastError(83, ffffffff, 3, 770ee2d4, ...) = 0
> [T5140] GetLastError(ffffffff, 16, 770ea9c5, 770f4ff3, ...) = 83
> [T5140] FlsGetValue(3, ffffffff, 16, 770ea9c5, ...) = 3407d8
> [T5140] SetLastError(83, ffffffff, 16, 770ea9c5, ...) = 0
> [T5140] GetLastError(ffffffff, 22fd2c, 770ee2d4, 77122b28, ...) = 83
> [T5140] FlsGetValue(3, ffffffff, 22fd2c, 770ee2d4, ...) = 3407d8
> [T5140] SetLastError(83, ffffffff, 22fd2c, 770ee2d4, ...) = 0
> [T5140] LeaveCriticalSection(340a80, 22fd48, 7713db33, 3, ...) = 0
> [T5140] GetLastError(3, 34f818, 770ea9c5, 420229, ...) = 83
> [T5140] FlsGetValue(3, 3, 34f818, 770ea9c5, ...) = 3407d8
> [T5140] SetLastError(83, 3, 34f818, 770ea9c5, ...) = 0
> [T5140] GetLastError(0, 1, 770ea9c5, 77127c1a, ...) = 83
> [T5140] FlsGetValue(3, 0, 1, 770ea9c5, ...) = 3407d8
> [T5140] SetLastError(83, 0, 1, 770ea9c5, ...) = 0
> [T5140] OutputDebugStringA(77144cc0, 10001, 770ee31e, 22fadc, ...)
> Invalid parameter passed to C runtime function.
> = 22f168
Dont' know if that helps any. I'd back the hunch of others in that the
mode of the file that's opened by the Windows kernel doesn't match the
later request to the C library with fdopen(). This `negative seek'
could just be a red-herring. What happens for the `init x' on the case
where there's no problems; the dvi one?
Cheers,
Ralph.
