November 2006 - Wine-Devel - list.winehq.org

Re: winhelp: add preliminary *.cnt file support (parser)
by Kirill K. Smirnov Nov. 19, 2006

Nov. 19, 2006

В сообщении от 19 ноября 2006 10:37 вы написали: > 1/ you forgot to include the changes (at least) to hlpfile.h Thanks! I've messed a little. > 2/ internal function definitions > > > +static BOOL HLPFILE_ReadCntFile(HLPFILE*); > > +static void HLPFILE_FreeCnt(HLPFILE_CNT*); > > I think those two functions are not correctly designed... I'd more > likely see something like: > > +static HLPFILE_CNT* HLPFILE_ReadCntFile(const char*); > +static void HLPFILE_FreeCnt(HLPFILE_CNT*); > > this makes the two functions consistent in what they depend on (either > both of them are passed a HLPFILE* or none of them), and also allows to > return the newly created HLPFILE_CNT which you never store in HLPFILE I messed here too... Also, I stumbled upon the following problem: HLPFILE_FreeCnt is never called! There is something bad with hlpfile->wRefCount - it's 4 (!) instead of 1 after just opening and closing file. --Kirill K. Smirnov

2 1

Re: winhelp: add preliminary *.cnt file support (parser)
by Eric Pouech Nov. 19, 2006

Nov. 19, 2006

Kirill K. Smirnov a écrit : > ChangeLog: > Add preliminary *.cnt file support (parser) > Hi Kirill, good to see someone enhancing winhelp!! a few comments though about your patch 1/ you forgot to include the changes (at least) to hlpfile.h 2/ internal function definitions > +static BOOL HLPFILE_ReadCntFile(HLPFILE*); > +static void HLPFILE_FreeCnt(HLPFILE_CNT*); > I think those two functions are not correctly designed... I'd more likely see something like: +static HLPFILE_CNT* HLPFILE_ReadCntFile(const char*); +static void HLPFILE_FreeCnt(HLPFILE_CNT*); this makes the two functions consistent in what they depend on (either both of them are passed a HLPFILE* or none of them), and also allows to return the newly created HLPFILE_CNT which you never store in HLPFILE 3/ don't use C++ comments in C code > + if (cur->level == entry->level) // level exists > + { > + entry->parent = cur->parent; > + cur->next = entry; > + } > + else // entry on new level > A+

1 0

Re; Solidworks 2006
by Kartik Thakore Nov. 19, 2006

Nov. 19, 2006

I added the bug to winehq here is the link thank you for the help I made it a little better to run: http://bugs.winehq.org/show_bug.cgi?id=6723 -- -------- Kartik Thakore 250313003 kthakore(a)uwo.ca 1st year engineering

1 0

Re; Solidworks 2006
by Kartik Thakore Nov. 18, 2006

Nov. 18, 2006

I added the bug to winehq here is the link thank you for the help I made it a little better to run: http://bugs.winehq.org/show_bug.cgi?id=6723 -- -------- Kartik Thakore 250313003 kthakore(a)uwo.ca 1st year engineering

1 0

Wine Version String
by Robert Lunnon Nov. 18, 2006

Nov. 18, 2006

Somewhere between Version 0.9.23 and Version 0.9.25 the version string format changed from Wine X.X.X to wine-X.X.X Can we please decide on a version string format and stick to it so packaging can be reasonably automated. Bob

2 1

oleaut32 tests and VarAdd(VT_DISPATCH, ...)
by Dan Kegel Nov. 18, 2006

Nov. 18, 2006

Alex Villacís Lasso wrote: >BTW, I see many attempts of VarAdd(VT_DISPATCH, ...) tested. All of them >are expected to fail. However, the tax app does just that >(VarAdd(VT_DISPATCH, ...)) and fails to display a print preview because >of this. I think that native oleaut32 fails these tests, not because it >does not support VarAdd(VT_DISPATCH) at all, but because these >VT_DISPATCHs are incorrectly formed (as in, just zeroing the variant, >then assigning VT_DISPATCH as variant type). I need to confirm this with >a test program. Yes, if you can improve the variant tests for oleaut32, please do! - Dan

1 0

CD-ROM access via "\\\\.\\Cdrom0"
by Pavel Roskin Nov. 18, 2006

Nov. 18, 2006

Hello! I've tried to figure out why some programs working with CD and DVD drives work only if the emulated version is set to Windows NT 4, but not Windows 2000 or XP. I used DVDDecrypter 3.5.4.0 with the current Wine from git. DVDDecrypter is configured to use SPTI, which is the default. Fixing ASPI would be a separate topic. If NT4 is emulated, the program scans all drives by letters and then opens drive H: (which is the DVD drive on my system). Here's an excerpt from the log produced by WINEDEBUG=+file,+cdrom,+ntdll,+kernel,+aspi wine DVDDecrypter.exe trace:file:CreateFileW L"\\\\.\\H:" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\H:",0x7d6b75b0,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\\\.\\H:" 520 0x7d6b7314 (nil)) trace:ntdll:NtCreateFile handle=0x7d6b75b8 access=c0000000 name=L"\\??\\H:" objattr=00000040 roo t=(nil) sec=(nil) io=0x7d6b75a8 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000050 ea=(nil).0x00000000 trace:file:get_dos_device L"H:" -> "/dev/scd0" trace:file:CreateFileW returning 0x8c And that's what the same command would produce with win2k emulation: trace:file:CreateFileW L"\\\\.\\Cdrom0" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WR ITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\Cdrom0",0x7d6b25b0,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\\\.\\Cdrom0" 520 0x7d6b2314 (nil)) trace:ntdll:NtCreateFile handle=0x7d6b25b8 access=c0000000 name=L"\\??\\Cdrom0" objattr=00000040 root=(nil) sec=(nil) io=0x7d6b25a8 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000050 ea=(nil).0x00000000 warn:file:CreateFileW Unable to create file L"\\\\.\\Cdrom0" (status c0000034) trace:file:CreateFileW returning 0xffffffff trace:file:CreateFileW L"\\\\.\\Cdrom1" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WR ITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\Cdrom1",0x7d6b25b0,(nil),(nil)) The program cycles like this to Cdrom63 and then gives up. I think it would be great if Wine adds supported for opening CD-ROMs by number. Better yet if it enumerated CD-ROMs an other drives automatically. I have make a proof-of-concept patch that allows DVDDecrypter to find the CD-ROM drive under win2k emulation. I had to create a link from .wine/dosdevices/cdrom0 to /dev/scd0 manually. This is not the right fix, but it shows that it can be done. diff --git a/dlls/ntdll/path.c b/dlls/ntdll/path.c index e4af89a..2ca5883 100644 --- a/dlls/ntdll/path.c +++ b/dlls/ntdll/path.c @@ -316,6 +316,7 @@ DOS_PATHNAME_TYPE WINAPI RtlDetermineDos ULONG WINAPI RtlIsDosDeviceName_U( PCWSTR dos_name ) { static const WCHAR consoleW[] = {'\\','\\','.','\\','C','O','N',0}; + static const WCHAR cdromW[] = {'\\','\\','.','\\','C','D','R','O','M',0}; static const WCHAR auxW[3] = {'A','U','X'}; static const WCHAR comW[3] = {'C','O','M'}; static const WCHAR conW[3] = {'C','O','N'}; @@ -372,6 +373,12 @@ ULONG WINAPI RtlIsDosDeviceName_U( PCWST if (strncmpiW( start, comW, 3 ) && strncmpiW( start, lptW, 3 )) break; if (*end <= '0' || *end > '9') break; return MAKELONG( 4 * sizeof(WCHAR), (start - dos_name) * sizeof(WCHAR) ); + case 11: + if (*(end - 1) <= '0' || *(end - 1) > '9') break; + case 10: + if (*end <= '0' || *end > '9') break; + if (strncmpiW( start, cdromW, 9 )) break; + return MAKELONG( (end - start + 1) * sizeof(WCHAR), (start - dos_name) * sizeof(WCHAR) ); default: /* can't match anything */ break; } -- Regards, Pavel Roskin

2 3

Re: [3/5] wined3d: Make the offscreen render mode a registry setting
by Ivan Gyurdiev Nov. 17, 2006

Nov. 17, 2006

This flag needs to be per adapter - should be added to device.c like the shader mode.

2 7

Bug in MapAndLoad function
by Adam Connell Nov. 17, 2006

Nov. 17, 2006

Greetings, While investigating why a game (Kasparov's Chessmate) didn't work, I think I found a bug in the implementation of imagehlp.dll in the the MapAndLoad function located in dlls/imagehlp/access.c lines 165-167. The function looks like it tries to open an uninitialized string szFileName instead of the passed file name "pszImageName". I think there has been a bug filed already (Bug 6099 Alien Shooter needs imagehlp.dll override) and I think this explains it. Wine version 0.9.25 /*********************************************************************** * MapAndLoad (IMAGEHLP.@) */ BOOL WINAPI MapAndLoad( LPSTR pszImageName, LPSTR pszDllPath, PLOADED_IMAGE pLoadedImage, BOOL bDotDll, BOOL bReadOnly) { CHAR szFileName[MAX_PATH]; HANDLE hFile = NULL; HANDLE hFileMapping = NULL; HMODULE hModule = NULL; PIMAGE_NT_HEADERS pNtHeader = NULL; TRACE("(%s, %s, %p, %d, %d)\n", pszImageName, pszDllPath, pLoadedImage, bDotDll, bReadOnly); /* PathCombine(&szFileName, pszDllPath, pszImageName); */ /* PathRenameExtension(&szFileName, bDotDll?:"dll":"exe"); */ /* FIXME: Check if the file already loaded (use IMAGEHLP_pFirstLoadedImage) */ if(!(hFile = CreateFileA( szFileName, GENERIC_READ, 1, /* FIXME: FILE_SHARE_READ not defined */ NULL, OPEN_EXISTING, 0, NULL))) { SetLastError(ERROR_FILE_NOT_FOUND); goto Error; } Cheers, Adam

4 4

Re: [2/5] wined3d: Fix depth buffer formats to use actual depth textures
by Ivan Gyurdiev Nov. 17, 2006

Nov. 17, 2006

That's still missing runtime check for GL_ARB_DEPTH_TEXTURE extension. I don't like "developers only" and "registry key" - feature should be complete or not in the tree. > The trouble with the current setup is that we can't use different formats based on what extensions are present. Then the setup should be fixed, rather than adding dependent code without extension checks. I might have mentioned before that statically initialized tables are evil.... ======== Btw, good job, I am glad you're working on this.... does it make Battlefield 2 work?

1 0