Re: [Groff] Re: grops and grohtml problems on vista (walter harms)

[walter harms]

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