wine-devel December 2006

wine-devel@winehq.org

112 participants
190 discussions

usp10/tests: Testing of EnumLanguageGroupLocalesA
by Paul Vriens 17 Dec '06

17 Dec '06

Hi, usp10/tests/usp10.c contains a test for EnumLanguageGroupLocalesA. The test that uses this function is not using any other functions. EnumLanguageGroupLocalesA is a kernel32 function and Win98 and NT4 don't have this function. The question now is should I change the usp10.c tests to check for the availability of EnumLanguageGroupLocalesA or just move the complete test to the kernel32 ones (where the availability is already tested). Cheers, Paul.

2 1

Re: WineD3D: paletted texture emulation using fragment shaders
by Chris Robinson 17 Dec '06

17 Dec '06

On Saturday 16 December 2006 13:24, Roderick Colenbrander wrote: > Hi, > > This patch adds 8-bit paletted texture emulation support using a fragment > shader. Won't this break for programs that attempt to use paletted textures and fragment shaders itself? If you need to emulate paletted textures, IMHO, a better option would be to hold the palette and 8-bit image in RAM, and just convert it to RGB(A) when either's changed. Though hardware has dropped native support for paletted textures, so, also IMHO, that should be done on the ddraw side, instead of making all d3d apps think paletted textures are available.

3 3

Re: [1] WineD3D: Add the state dirtification infrastructure
by Stefan Dösinger 17 Dec '06

17 Dec '06

Am Freitag 15 Dezember 2006 18:31 schrieb Stefan Dösinger: > This patch adds the dirty list infrastructure. A dirty marker consists of a > DWORD containing the state it marks dirty, and the list structure to build > the list. > > The wined3ddevice has 3 new members: > dirtyStateList: The list of dirty states. This will be moved to a > per-context stucture once we add multithreading support > freeListElems: A list containing unused dirty markers to avoid unnecessary > HeapAlloc/HeapFree calls. I have seen D3D games spending 15% cpu time in > the Heap code, we don't want to increase that. > dirtyStates: An array that tells if a state is dirty. It is used to avoid > double dirtification. I do not use the stateblock->changed.XXXX[] array > because this is used for different purposes in the stateblock code. Ivan, > do we still need it? Vitaly asked me on irc why I use a linked list instead of an array or bitmap. Well, my original plan was indeed an array, but after discussing it with Henri I decided to got for a list. See http://www.winehq.org/pipermail/wine-devel/2006-October/051868.html and following posts. The main arguments for a list were: * The shader constant code uses it too. It keeps the code somewhat simmilar * memory usage. An array has a fixed sizeof(DWORD) * STATE_HIGHEST mem usage, while a list has sizeof(DWORD) + 2*sizeof(void *) * number of dirty states memory usage. well, that was the idea In fact, the initial dirtification kills the memory usage argument. However, instead of dirtifying all the elements I could set the recording flag in the device on before initializing the initial stateblock and later apply the states instead of dirtifying them. When there are multiple contexts those can share the list of the free dirty markers. The way dirtification is done and the rest of the code are independent from each other, so it can be changed easilly when we decide to do so. I prefer to get the state management running first, and then move the initial opengl setup to Init3D().

2 2

Re: winsock.h undefined symbols ___wine_ulong_swap ___wine_ushort_swap
by Pierre d'Herbemont 16 Dec '06

16 Dec '06

> Pierre's fix regarding use of hton and ntoh functions on Big Endian > when including from winsock2.h did not > completely resolve compilation errors. Sanjay, it did fix the compilation error, but it seems, looking at your diff, that you're wine sources are mangled : you have mixed the first patch and the second one that were sent to wine-patches. > diff -urN /Darwine/winesrc/wine-0.9.27/include/winsock.h /Darwine/ > winesrc/wine-0.9.27_compiled/include/winsock.h > --- /Darwine/winesrc/wine-0.9.27/include/winsock.h 2006-12-08 > 16:34:42.000000000 -0500 > +++ /Darwine/winesrc/wine-0.9.27_compiled/include/winsock.h > 2006-12-15 16:14:59.000000000 -0500 > @@ -516,12 +516,14 @@ Looking at the way you diff, I think you shouldn't send your patch against version release, git [1] would be more appropriate, and won't have let you send a patch that cannot be applied. [1] http://www.winehq.org/site/git http://www.winehq.org/site/sending_patches Pierre.

1 0

Re: setupapi: add SPFILENOTIFY_TARGETNEWER support to SetupDefaultQueueCallback
by Alexandre Julliard 16 Dec '06

16 Dec '06

Robert Reif <reif(a)earthlink.net> writes: > Index: dlls/setupapi/queue.c > =================================================================== > RCS file: /home/wine/wine/dlls/setupapi/queue.c,v > retrieving revision 1.24 > diff -p -u -r1.24 queue.c > --- dlls/setupapi/queue.c 14 Nov 2006 11:15:45 -0000 1.24 > +++ dlls/setupapi/queue.c 15 Dec 2006 16:38:56 -0000 > @@ -1379,6 +1379,28 @@ UINT WINAPI SetupDefaultQueueCallbackA( > case SPFILENOTIFY_NEEDMEDIA: > TRACE( "need media\n" ); > return FILEOP_SKIP; > + case SPFILENOTIFY_TARGETNEWER: > + TRACE( "target newer? Source: %s Target: %s\n", > + debugstr_a(paths->Source), debugstr_a(paths->Target) ); > + { > + WIN32_FILE_ATTRIBUTE_DATA Source, Target; > + > + if (GetFileAttributesExA(paths->Source, GetFileExInfoStandard, &Source)) > + { > + if (GetFileAttributesExA(paths->Target, GetFileExInfoStandard, &Target)) > + { > + TRACE( "Target = 0x%08x%08x, Source = 0x%08x%08x\n", > + Target.ftCreationTime.dwHighDateTime, Target.ftCreationTime.dwLowDateTime, > + Source.ftCreationTime.dwHighDateTime, Source.ftCreationTime.dwLowDateTime ); > + > + if (CompareFileTime(&Target.ftCreationTime, &Source.ftCreationTime) == 1) > + return TRUE; > + > + return FALSE; > + } > + } > + } That doesn't make sense to me. At this point the file is known to be newer from the version info, why would you want to check creation time and overwrite a newer file? -- Alexandre Julliard julliard(a)winehq.org

1 0

Call to all packagers (especially Debian)
by Vitaliy Margolen 16 Dec '06

16 Dec '06

It seems there is no end to how far will packagers go to brake Wine by trying to make it better I thought it's been fixed a long time ago, but it seems not. Wine packages for Debian split important Wine parts into separate packages: - wine - fonts, few not essential programs, symlinks and _premade_ content of ~/.wine directory (with ~/.wine/c as default c: drive)!!! - libwine - all the builtin dlls - wine-utils:(explorer, winecfg, winepath, cmd.exe, iexplore, winedbg) and many other packages. Also as default it's using "winelauncher" instead of standard "wine" binary. That makes it that much more complicated to troubleshoot any problems that users might have. So in case anyone having problems with Debian or Debian based distro, please check that all the "*wine*" packages installed. Also is there a way we can request packagers to follow some standard to how they package Wine? Can we ask packagers to package all parts of Wine into one single package? If they prefer, they can package optional sound drivers separately (arts, esd, jack, nas). Same for documentation, and development headers. However everything else is essential to Wine and most programs that ran under it. Also can packagers keep default method of starting Wine the same without using any additional scripts for starting Wine? And of course, if any alterations has been made, state so in the distro specific readme file. Of course I realize that this is open source and anyone can do whatever they pleased. But please, that's make it more supportable. It's such a huge PITA to waste several hours trying to find the reason why something doesn't work to realize that person doesn't have explorer. Needless to say that lots of things won't work right. Vitaliy.

6 6

Cast-qual warnings: current status
by Andrew Talbot 16 Dec '06

16 Dec '06

Hi, Apart from any oversights, I have completed my run of cast-qual fixes for the "dlls" and "dlls/tests" directories. The one file that most distorts the picture when -Wcast-qual is applied is "unicode.h", since its wide-string functions are inlined and it is included quite widely. I have posted a patch (dated 16 Dec 2006, entitled "include: Cast-qual warnings fix using const_cast macro") that, if not accepted, you can apply locally, if you want to build with "-Wcast-qual" to see the extent of the remaining problem. For the places where we still must use casts, I propose the introduction of a macro that takes on the role of the "const_cast" in C++. My attempt at that is as follows. #ifdef __cplusplus #define const_cast(t, e) const_cast<t>(e) #else #define const_cast(t, e) (t)(ULONG_PTR)(e) #endif This will make its purpose stand out from those of other casts. So, for example, the definition of strchrW() would become: extern inline WCHAR *strchrW( const WCHAR *str, WCHAR ch ) { do { if (*str == ch) return const_cast(WCHAR *, str); } while (*str++); return NULL; } The positive point of aiming to add -Wcast-qual universally - I would argue - is that it lets the compiler watch out for inadvertent introductions of fresh violations, so I become redundant, and you proper programmers can concentrate on more interesting things. :) I invite you, please, to debate the above issues, so we can determine the way forward concerning this issue. Meanwhile, I shall move on to the few "programs" and "server" files that generate cast-qual warnings. Thanks, -- Andy.

1 0

Re: [5/5] usp10: remote todo_wine
by James Hawkins 16 Dec '06

16 Dec '06

On 12/14/06, Clinton Stimpson <cjstimpson(a)utwire.net> wrote: > Hi, > > Part 5 of 5. > Remove many todo_wine's from the tests, now that the functions are > implemented. > You have to remove the todo_wine's in the same patch that fixes the tests, or the tests will fail for at least one commit. Patches have to be atomic and error free, and a failing test is an error. -- James Hawkins

3 4

Re: [AppDB] Add generic sound help (resend)
by Chris Morgan 16 Dec '06

16 Dec '06

Is it ok if we link to this entry in the Wine documentation instead: http://winehq.org/site/docs/wineusr-guide/config-wine-main#AEN282 Chris On Friday 15 December 2006 12:27 pm, Alexander Nicolaysen Sørnes wrote: > (I assume this was overlooked.) > > Add a paragraph about sound problems on the bottom of the generic help page > (as most sound problem reports are due to incorrect configurations). > > Also update the outdated usage of --debugmsg. > > > Regards, > > Alexander N. Sørnes

1 0

Re: msi: Enable cab compression and delete any resulting cabs using SHFileOperation
by Alexandre Julliard 15 Dec '06

15 Dec '06

"James Hawkins" <truiken(a)gmail.com> writes: > +static void delete_cab_files(void) > +{ > + SHFILEOPSTRUCT shfl; > + CHAR path[MAX_PATH]; > + > + lstrcpyA(path, CURR_DIR); > + lstrcatA(path, "\\*.cab\0"); > + > + shfl.hwnd = NULL; > + shfl.wFunc = FO_DELETE; > + shfl.pFrom = (LPCSTR)path; > + shfl.pTo = NULL; > + shfl.fFlags = FOF_FILESONLY | FOF_NOCONFIRMATION | FOF_NORECURSION | FOF_SILENT; > + > + SHFileOperation(&shfl); > +} If you are going to delete files with wildcards, you need to create a temp dir and do everything inside it, otherwise you risk deleting files that are not part of the test. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
19
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2006