wine-devel July 2007

wine-devel@winehq.org

112 participants
227 discussions

Re: [RFC] winex11.drv: Prepare ChoosePixelFormat() for code rewrite.
by Vitaliy Margolen 16 Jul '07

16 Jul '07

Tomas Carnecky wrote: > This partial rewrite aims at cleaning up the pixelformat code. Windows > sometimes advertises one or more almost identical and completely > compatible pixelformats. These pixelformats differ in attributes like > color-bits, but I suspect the driver developers do that only to work > around buggy applications that don't follow the spec. > This rewrite will also simplify the pixelformat code by removing > redundant blocks and moving the core functionality to a few main functions. > > This is the first patch that simplifies ChoosePixelFormat() by > converting the PFD structure to a list of WGL attributes and then using > a function to choose the pixelformat. This function doesn't do anything > as we support only one pixelformat, but this function will be shared > with wglChoosePixelFormat() once the infrastructure for that is in place. > > I also have a second patch that converts DescribePixelFormat() to use > the same approach, eg. querying the pixelformat attributes using a WGL > attribute list and then copying the values back the the PFD structure. > > --- Few notes: You constructed the array of some attributes which you never use. You don't check if those attributes match anything - the part you removed. When app will ask for something that can't be supported your code will return it to the app - which is plain wrong. And being picky - you using tabs for indentation, please use 4 spaces instead, and no tabs. Vitaliy

2 1

Re: [Resend PATCH 2/2] gdi32: Do not fill in the color tableiflpvBits is NULL
by Dmitry Timoshkov 14 Jul '07

14 Jul '07

"Jeremy White" <jwhite(a)codeweavers.com> wrote: > p.s. While I'm coming clean, *another* failure on my part > was to fail to credit Huw; this is mostly his insight. > I provided the clue, and the hopeless failure to get a clean patch in :-/. Since you are going to resend the patch anyway please add a missing HeapFree call to the test. -- Dmitry.

1 0

Re: programs/winefontcfg: Add winefontcfg (try 3)
by Dan Kegel 14 Jul '07

14 Jul '07

All in all the app looks like it's coming along nicely. I apologize for catching so few problems in each pass, but we'll get there. Is there a way you can get the path to the currently running instance instead of hardcoding it? Then it would work even if winefontcfg isn't on the PATH. + static const WCHAR cmdstr[] = { + 'w', 'i', 'n', 'e', 'f', 'o', 'n', 't', 'c', 'f', 'g', '.', 'e', 'x', 'e', '.', 's', 'o', ' ', You're still using nonstandard C; you can't have initializers on nonstatic arrays. This is the third time I have pointed this out; you should look to make sure you don't do this anywhere in the program. You should make sure the app can build with visual C 6 if you haven't lately, too. +static void TabSelChanged(HWND hTab) +{ + int tab[NUMTAB][MAXOBJPERTAB] = { Say, why is hwndTab static here? I bet that's a cut and paste error: +static HWND InitTab(HWND hdlg, HFONT hf) +{ + static HWND hwndTab; Looks like variable reuse abuse here; maybe you should have a more mnemonic name for the return value of wcstolong: + j = wcstolong(buf); It might be nice to have comments identifying the big hunks of the program, e.g. if all the code for one tab was grouped under a comment with the name of the tab. - Dan

1 1

Should Wine move to LGPL 3?
by Tom Wickline 14 Jul '07

14 Jul '07

Hello, I was wondering if there are any plans in place for Wine to move to the newly revised LGPL 3 licence before the release of 1.0? http://www.gnu.org/licenses/lgpl.html Cheers, Tom Wickline -- Microsoft's patent protection scheme is the equivalent of bailing water with a sieve.

11 12

Re: Should Wine move to LGPL 3?
by Ian Macfarlane 13 Jul '07

13 Jul '07

I've been meaning to ask about this since (L)GPL3 was released. The version 3 of the (L)GPL license has numerous benefits: - It's much more legally sound in the rest of the world (IMO one of the most important factors about the new license) - numerous reasons for this e.g. referencing WIPO rather than US laws. - It has an explicit patent agreement (really an extension of the above - (L)GPLv2 has an implicit patent agreement, but this is only valid in the US) - this means that people who contribute to and/or distribute WINE cannot sue WINE (or WINE users) for patent infringement. - It is compatible with the Apache 2.0 license, meaning that there is an even bigger pool of source code to draw from. - It helps ensure that companies cannot prevent people from modifying the source code by providing them explicit legal rights to change the code in these circumstances, and requiring information to allow users to change it. - For LGPL only, It makes 100% sure that GPL+linking exception and LGPL can be combined legally in all jurisdictions by merging them (which is essentially the only real difference, barring slightly different wording in the v2.1 of LGPL vs v2. of GPL) - It prevents patent agreements where only some people are protected. - It provides a mechanism for first-time accidental violations to be 'cured' more easily - ... and lots of other minor changes to improve the validity of the legal status of the license. There are some points not directly related to the license itself that might be of interest: - Samba has decided to become GPL3+ only, as they want the added protections provided by the license. WINE and Samba seem like projects that may potentially wish to share code (a very quick search brings up articles like this http://www.winehq.org/?issue=272), and if WINE sticks to supporting GPLv2+ rather than GPLv3+, then WINE will no longer be able to integrate Samba code. - Solaris may go GPLv3, another potentially useful repository of code to draw from that would not be possible under GPLv2. So as you can see, (L)GPL version 3 has a lot of benefits. It also has broad support (excluding Linus of course, who I must point out objects only to a single clause in the license that can be resolved by adding an extra permission, as GPLv3 permits), including strong corporate backing (e.g. IBM, Red Hat, MySQL, Sun, even Novell). As one of the projects that Microsoft would most like to destroy, the added protections in this updated version of the license would seem even more valuable. Kind regards, Ian Macfarlane ps: As a last note to Damjan - all GPL versions have been considered both radical and political when they were released. In retrospect, the protections that they provided have been considered invaluable.

4 3

compile wine version 0.9.41
by Renato Astorino 13 Jul '07

13 Jul '07

Dears, As requested in the result of it configures it follows the menssagem: configure: WARNING: io.h: present but cannot be compiled configure: WARNING: io.h: check for missing prerequisite headers? configure: WARNING: io.h: see the Autoconf documentation configure: WARNING: io.h: section "Present But Cannot Be Compiled" configure: WARNING: io.h: proceeding with the preprocessor's result configure: WARNING: io.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## the executed command: #./configure --with-PACKAGE=yes --with-x --disable-win16 #make depend make[1]: Entering directory `/mnt/hd_ext/Softwares/wine-0.9.41/tools' gcc -c -I. -I. -I../include -I../include -I/usr/local/include/freetype2 -I/usr/local/include -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o makedep.o makedep.c In file included from ../include/wine/port.h:42, from makedep.c:23: /usr/local/include/io.h:69: error: expected specifier-qualifier-list before 'TAILQ_ENTRY' /usr/local/include/io.h:75: error: field 'ihdr_queue' has incomplete type /usr/local/include/io.h:76: error: field 'ihdr_parent' has incomplete type /usr/local/include/io.h:120: error: field 'io_ev' has incomplete type make[1]: *** [makedep.o] Error 1 make[1]: Leaving directory `/mnt/hd_ext/Softwares/wine-0.9.41/tools' make: *** [tools/makedep] Error 2 I am using the distribution Slackware 12.0 regards, Renato Astorino _________________________________________________________________ Verificador de Segurança do Windows Live OneCare: combata já vírus e outras ameaças! http://onecare.live.com/site/pt-br/default.htm

1 0

Re: [Resend PATCH 2/2] gdi32: Do not fill in the color table if lpvBits is NULL
by H. Verbeet 13 Jul '07

13 Jul '07

On 13/07/07, Jeremy White <jwhite(a)codeweavers.com> wrote: > --- > dlls/gdi32/dib.c | 14 +++++++++++--- > 1 files changed, 11 insertions(+), 3 deletions(-) > The patch mixes tabs and spaces. Also, in general, I don't think we should include text from MSDN.

2 1

unsuspected success in tests/monthcal?
by Marcus Meissner 13 Jul '07

13 Jul '07

Hi, For some days I now get unexpected successes in dlls/comctl32/tests/monthcal.c. ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so monthcal.c && touch monthcal.ok err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 131073 make[2]: *** [monthcal.ok] Error 1 Does anyone else see them too? Ciao, Marcus

3 2

Re: [msi/tests] Remove the whole directory after the test
by James Hawkins 13 Jul '07

13 Jul '07

On 7/13/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > RemoveDirectory only removes empty directories. > > Changelog > Remove the whole directory after the test > No, this is wrong. The line above, CreateDirectory("msitest\\msitest", NULL); is what needs to be removed. -- James Hawkins

2 1

Re: winedump: Cast-qual warnings fix
by Alexandre Julliard 13 Jul '07

13 Jul '07

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > + const char *iter, *base_type, *catch_unsigned; > + union > + { > + const char *constant; > + char *nonconst; > + } type_str; That's not better than simply casting const away, it's just hiding the problem from the compiler. -- Alexandre Julliard julliard(a)winehq.org

3 2

← Newer
1
...
10
11
12
13
14
15
16
...
23
Older →

Jump to page:

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 July 2007