Ralph Corderoy schrieb: > 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? >
hi, i do not use win* so if there is someone who knows and is willing to look into that it may be interesting to that there is a function called tmpfile(3), it is ISO,POSIX,... i admit not looking into the groff code. re, wh
