Re: [1/5] richedit: Implemented ITextHost for windowed richedit controls.
On Tue, Jan 20, 2009 at 12:41 AM, Dylan Smith wrote: > I plan on implementing windowless richedit controls by refactoring out > the references the richedit controls hWnd into an ITextHost > implementation. This way windowless richedit controls can be > implemented using the same code by using the ITextHost implementation > provided to the CreateTextServices function. > > This patch mostly aims to provide an implementation of ITextHost that > can be created and used in the windowed richedit control. Later patches > will use the ITextHost interface to avoid using the richedit controls > hWnd. Once the existing code is able to properly handle to the case > where hWnd is NULL by using ITextHost, then ITextServices can be > implemented using the existing richedit code. > --- > dlls/riched20/Makefile.in |1 + > dlls/riched20/editor.c| 71 +++-- > dlls/riched20/editor.h| 49 +++ > dlls/riched20/editstr.h |7 + > dlls/riched20/txthost.c | 726 > + > include/textserv.h| 40 --- > 6 files changed, 830 insertions(+), 64 deletions(-) > create mode 100644 dlls/riched20/txthost.c > > > > I just wanted to thank Dylan for all his work on riched, and also for his explanation on his work when submitting patches. While I don't always know what he's fixing, it makes it easier to get an idea what it is he's doing because of his clear explanations on each patchset. -- -Austin
Re: fix commit 3fe5d80512ec5dbfbb2ee7dbb426be7d582e262e
On Sun, 18 Jan 2009 18:33:44 +0100 (CET) Francois Gouget wrote: [...] > However, I think it would be clearer to do it in the else branch of the > test for teh xxx-config tool. So something like this: > > > if test "$gphoto2_devel" != "no" -a "$gphoto2port_devel" != "no" > then > ... > else > ac_gphoto2_libs="-lgphoto2" > fi > ...From b06d8981ff587e8195942f872bf9fb0b54eacd4f Mon Sep 17 00:00:00 2001 thank you for reviewing. yeah, sane things had a bit difference. but i don't know how handle about wine's sources and structure ... i'd like to make more clear like that about other 3 libs. >From b06d8981ff587e8195942f872bf9fb0b54eacd4f Mon Sep 17 00:00:00 2001 From: Shunichi Fuji Date: Tue, 20 Jan 2009 15:24:46 +0900 Subject: [PATCH] configure: set default libs if ***-config is missing. Signed-off-by: Shunichi Fuji --- configure.ac |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 72f93b7..70f5fc1 100644 --- a/configure.ac +++ b/configure.ac @@ -1012,6 +1012,8 @@ then esac done CPPFLAGS="$CPPFLAGS $ac_gphoto2_incl" +else +ac_gphoto2_libs="-lgphoto2" fi AC_CHECK_HEADER(gphoto2-camera.h, [AC_CHECK_LIB(gphoto2,gp_camera_new, @@ -1059,6 +1061,8 @@ then then ac_freetype_incl=`$ft_devel --cflags` ac_freetype_libs=`$ft_devel --libs` +else +ac_freetype_libs="-lfreetype" fi WINE_CHECK_SONAME(freetype,FT_Init_FreeType,[ft_lib=yes],[ft_lib=no],[$ac_freetype_libs]) if test "$ft_lib" = "yes" @@ -1140,6 +1144,8 @@ then done ac_esd_libs=`$ESDCONFIG --libs` CFLAGS="$CFLAGS $ac_esd_incl" +else +ac_esd_libs="-lesd" fi AC_CHECK_HEADER(esd.h, [AC_CHECK_LIB(esd,esd_open_sound, -- 1.6.1
Re: wineg++ compile error
On Tue, Jan 20, 2009 at 2:23 AM, Stefan Dösinger wrote: >> Yeah, it looks like there's some conflict with iostream and msvcrt: >> http://www.mail-archive.com/wine-devel@winehq.org/msg08834.html >> >> I'm trying to follow the recommendations, but without much luck. > Maybe try to use the iostream implementation from msvcrt(not sure how to do > that, though - I never used winelib myself) > > Is there any reason why you have to compile the app using winelib? Unless > you want to link against Linux libraries in your app there is no advantage > over compiling the application as a PE .exe file(same performance, same > runtime requirements etc). If you compile it as native .exe you avoid all > the issues where Linux headers collide with Windows headers. > I thought that Wine's msvcrt didn't have any iostreams yet (#11910, #6457)? Damjan
Re: OpenAL back-end: repost for reconsideration
On Monday 19 January 2009 9:33:26 am Stefan Dösinger wrote: > The problem with the openal32.dll -> libopenal.so wrapper was that it broke > some games, and we never debugged why. If anyone wants to continue this > development I think this wrapper library is something that would be highly > welcome. In Linux, I'd imagine it's because the old Linux lib wasn't coded very well. However, newer versions of OpenAL on Linux are based off the same code the Windows version is derived from (the original Windows version was LGPL, then was closed up; the recent Linux versions were ported and enhanced from the LGPL code). I don't really know how well the OSX version of OpenAL works for this purpose, though. > As for the winmm driver, Roderick pretty much said it. We don't need > another half baked sound backend, the effort should instead be put into > making sure we have one properly working one for each platform(Alsa for > Linux, coreaudio on the mac, not sure about *BSD and Solaris) Yeah, a WinMM driver pretty much won't work well. A better idea would be wrapping DirectSound around OpenAL, and I have code that does that; but it's not perfect yet, and it would have to be ported to C from C++ for any hope of inclusion in Wine (it's currently a real native DLL, cross-compiled with MinGW, depending on the aforementioned OpenAL DLL thunk). IIRC, most of the problems surrounding the DLL thunk were two things: 1) The original patches used a lot of macros to do the function thunks. Alexandre didn't like that and wanted it expanded. This part I've done, though the thunks are missing TRACEs. 2) The functions returned by al[c]GetProcAddress also need to be wrapped. Although the Linux and Windows version use the same calling convention (cdecl), AJ says this can break on OSX. To do this, we'll likely need some kind of script like opengl32 uses (luckilly not too many extensions provide functions, so the needed wrappers will be minimal compared to opengl; but I've been lazy in setting that up). There's probably some other things that need to be done, but those two are the big ones I remember. I've attached a patch with the latest version I have.. it's a little broken on OSX currently because it's not checking for the OpenAL framework, and I'm not sure how to do that properly. 0002-Add-an-OpenAL32-DLL-thunk.patch.gz Description: GNU Zip compressed data
Re: AppDB: Rating / Patching
2009/1/20 :
> Hi,
>
> here are, from an obvious user perspective, my 0.02$ on the issue.
>
> - Platinum: app works "out of the box" -- without changing any
> settings -- *and* as well as on MS-Windows. That means no feature is
> missing: music plays, graphics look similar on both plattforms, the
> perceived speed or responsiveness is similar, ...
> (Question: does the need to install thrid party SW like codecs or
> Quicktime preclude "platinum" because it's not "out of the box"?)
3rd-party software like codecs or Quicktime do not ship as part of
Windows, they ship as part of the software that depends on them. I
cover this again further down.
> For anything below platinum, I don't want AppDB to ask users to
> compare with MS-Windows. Users either don't care about MS-Windows or
> don't have the time to perform a dual installation or don't even have
> a MS-Windows machine!
This appears to defeat your argument, since the appdb is maintained
and updated by users. If users "don't care about" or "don't have the
time" for Windows, then you'll end up never getting a platinum rating
with this qualification.
> Yet to gain platinum rating, I concede that the additional effort to
> test the application's behaviour on MS-Windows is valuable to detect
> discrepancies between the two ("hey, I didn't know before that the
> application would play background music!").
Yes, it is valuable, however it's not practical, as you pointed out
earlier. It's also implying that you need a copy of Windows to use
Wine to its fullest. We shouldn't assume that *anyone* using Wine has
a copy of Windows too.
> - Garbage: nobody knows how to make this app work with that version of
> wine. Don't buy it, you are likely wasting your time & money.
Wine does not only run commercial applications. Instructing users to
not buy products in the rating definitions is, again, assuming far too
much about what the users are trying to do.
In some cases, there are apps that are impossible to make functional
in Wine. Your suggested description implies that there are no such
cases, and that some future version of Wine will be able to handle it.
> Anything else gets a rating above garbage, no matter how ugly the fix
> or patch is. What counts is that there's a known way to make it work.
>
> - Bronze: the application shows a "promise" that some additional fixes
> and patches may make it work well.
Wow, this is completely unsuitable as a rating description without a
detailed definition of what a "promise" means. It also disqualifies
cases of "it runs, but not well" where no known patches or "fixes"
make it run better.
> I'm opposed to the idea that a given AppDB version should only
> denote an unpatched wine in test results. Consider how Dan Kegel
> recently recommended distributors not to distribute 1.1.12. E.g. a
> hypothetical future Ubuntu package "1.1.12" may contain the official
> 1.1.12 plus the three patches that Dan Kegel recommends.
I thought you just said Dan was recommending distributors NOT distribute 1.1.12!
Also note that WineHQ distributes its own packages of Wine for Ubuntu.
Technically, we should only support these packages, and not those
shipped by Ubuntu.
> Users would likely not know nor notice.
This is the problem. If a user doesn't know what patches have been
applied to their Wine that make their application work, then the AppDB
will have blatantly incorrect information. AppDB implies that *no
patches* were applied to Wine when the apps were tested. Saying we
only want test data from unpatched Wine releases makes the implication
explicit instead. This is a good thing.
> Typically, distributors add whatever
> patches they feel right to the upstream releases.
> So it does not seem practical to have the need for a patch prevent
> ratings above garbage (or bronze), as some people suggested here.
It's more impractical to allow users to submit test data from patched
Wines. What happens if the patches aren't specified in the test data,
or if the patches are something the user has written but hasn't made
public?
> To me, 1.1.12 plus N patches (N "small") is still 1.1.12 as far as the
> AppDB is concerned. However N>0 might preclude platinum, as defined above
> (except for Ubuntu users).
You have to define what "small" is. Even then, it doesn't help,
because you could have one really big patch, or one really small (as
in one-line) patch that violently changes the behaviour of Wine.
To me, and I would guess to most Wine developers, 1.1.12 means 1.1.12
as accessible from upstream. So if you go to Wine's directory on
ibiblio.org and download a tarball, you get the exact source used to
compile that version of Wine.
Note that some common patches, like the CoD/3DMark patch, break more
apps than they fix. In your opinion, should there be any criteria on
what patches should be allowed in test data for appdb?
> Similarly, AppDB might prevent Gold or Silver ratings depending on
> qualitative aspects of the steps needed to mak
RE: wineg++ compile error
> Yeah, it looks like there's some conflict with iostream and msvcrt: > http://www.mail-archive.com/wine-devel@winehq.org/msg08834.html > > I'm trying to follow the recommendations, but without much luck. Maybe try to use the iostream implementation from msvcrt(not sure how to do that, though - I never used winelib myself) Is there any reason why you have to compile the app using winelib? Unless you want to link against Linux libraries in your app there is no advantage over compiling the application as a PE .exe file(same performance, same runtime requirements etc). If you compile it as native .exe you avoid all the issues where Linux headers collide with Windows headers.
Re: widl: fix a compiler error
2009/1/19 Austin English : > diff --git a/tools/widl/widltypes.h b/tools/widl/widltypes.h > index e6b0369..0851d2b 100644 > --- a/tools/widl/widltypes.h > +++ b/tools/widl/widltypes.h > @@ -539,6 +539,7 @@ static inline enum type_type > type_get_type_detect_alias(const type_t *type) > default: > assert(0); > } > +return 0; > } > > #define STATEMENTS_FOR_EACH_FUNC(stmt, stmts) \ Please put the return statement in the default case. -- Rob Shearman
Re: gdi32: Implement QueryFontAssocStatus
2009-01-19 (Mon), 09:40 +0900, Byeongsik Jeon wrote: > QueryFontAssocStatus() is the undocumented function. > This is a base patch for bug#16325. > > http://bugs.winehq.org/show_bug.cgi?id=16325 > Hmm... What is the problem of this patch? > --- > dlls/gdi32/font.c| 12 +++ > dlls/gdi32/freetype.c| 66 > ++ > dlls/gdi32/gdi32.spec|2 +- > dlls/gdi32/gdi_private.h |1 + > dlls/gdi32/tests/Makefile.in |2 +- > dlls/gdi32/tests/font.c | 63 > include/wingdi.h |1 + > 7 files changed, 145 insertions(+), 2 deletions(-) >
AppDB: Rating / Patching
Hi,
here are, from an obvious user perspective, my 0.02$ on the issue.
- Platinum: app works "out of the box" -- without changing any
settings -- *and* as well as on MS-Windows. That means no feature is
missing: music plays, graphics look similar on both plattforms, the
perceived speed or responsiveness is similar, ...
(Question: does the need to install thrid party SW like codecs or
Quicktime preclude "platinum" because it's not "out of the box"?)
For anything below platinum, I don't want AppDB to ask users to
compare with MS-Windows. Users either don't care about MS-Windows or
don't have the time to perform a dual installation or don't even have
a MS-Windows machine!
Yet to gain platinum rating, I concede that the additional effort to
test the application's behaviour on MS-Windows is valuable to detect
discrepancies between the two ("hey, I didn't know before that the
application would play background music!").
- Garbage: nobody knows how to make this app work with that version of
wine. Don't buy it, you are likely wasting your time & money.
Anything else gets a rating above garbage, no matter how ugly the fix
or patch is. What counts is that there's a known way to make it work.
- Bronze: the application shows a "promise" that some additional fixes
and patches may make it work well.
I'm opposed to the idea that a given AppDB version should only
denote an unpatched wine in test results. Consider how Dan Kegel
recently recommended distributors not to distribute 1.1.12. E.g. a
hypothetical future Ubuntu package "1.1.12" may contain the official
1.1.12 plus the three patches that Dan Kegel recommends. Users would
likely not know nor notice. Typically, distributors add whatever
patches they feel right to the upstream releases.
So it does not seem practical to have the need for a patch prevent
ratings above garbage (or bronze), as some people suggested here.
To me, 1.1.12 plus N patches (N "small") is still 1.1.12 as far as the
AppDB is concerned. However N>0 might preclude platinum, as defined above
(except for Ubuntu users).
Similarly, AppDB might prevent Gold or Silver ratings depending on
qualitative aspects of the steps needed to make an app work:
- need for known distributable third party libraries (e.g. codecs, Quicktime)
(not provided with the application's installer)
- complexity of settings (winecfg vs. *.reg vs. environment variable vs. ...)
- nocd or not copy-protected executables
- patch to source, requiring compilation of wine
E.g. Recompilation would prevent Gold?
Would you agree that any application in need of a nocd would
necessarily rate one level below another one not "equipped" with copy
protection?
Or does only the result count, and e.g. "Gold" is perfectly describing an
application that works flawlessly "out of the box", except you need to
replace the .exe with the nocd one between install and run? (So far I
have handled it like this, a patch is not enough reason to drop a rating
to garbage, this does not effectively describe the user experience.)
Regards,
Jörg Höhle
Re: wineg++ compile error
Yeah, it looks like there's some conflict with iostream and msvcrt:
http://www.mail-archive.com/wine-devel@winehq.org/msg08834.html
I'm trying to follow the recommendations, but without much luck.
On Mon, Jan 19, 2009 at 11:42 AM, Stefan Dösinger
wrote:
> It looks like you include two headers that define the same type in a
> differnet way. Ie, a typdef from a Linux header collides with a windows
> typedef from a Wine header.
>
>> -Original Message-
>> From: wine-devel-boun...@winehq.org [mailto:wine-devel-
>> boun...@winehq.org] On Behalf Of Rino Farina
>> Sent: Monday, January 19, 2009 3:46 PM
>> To: wine-devel@winehq.org
>> Subject: wineg++ compile error
>>
>> Hi All,
>>
>> I'm completely new to wine, and am having trouble compiling code
>> before it ever gets to the linker. Can anyone point me in the right
>> direction?
>>
>> BaseGameEntity.h:
>>
>> #include
>>
>> class BaseGameEntity
>> {
>> private:
>> int m_ID;
>> static int m_iNextValidID;
>>
>> void SetID(int val);
>>
>> public:
>> BaseGameEntity(int id)
>> {
>> SetID(id);
>> }
>>
>> virtual ~BaseGameEntity(){}
>>
>> virtual void Update()=0;
>> virtual bool HandleMessage(const long& msg)=0;
>>
>> int ID()const{return m_ID;}
>> };
>>
>> BaseGameEntity.cpp:
>>
>> #include "BaseGameEntity.h"
>> #include
>>
>> int BaseGameEntity::m_iNextValidID = 0;
>> void BaseGameEntity::SetID(int val)
>> {
>> assert ( (val >= m_iNextValidID) && ": invalid
>> ID");
>>
>> m_ID = val;
>>
>> m_iNextValidID = m_ID + 1;
>> }
>>
>>
>> Console:
>>
>> make all
>> wineg++ -c -mno-cygwin -I. -o BaseGameEntity.o BaseGameEntity.cpp
>> In file included from
>> /usr/lib/gcc/i386-redhat-
>> linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52,
>> from
>> /usr/lib/gcc/i386-redhat-
>> linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47,
>> from
>> /usr/lib/gcc/i386-redhat-
>> linux/4.3.0/../../../../include/c++/4.3.0/bits/char_traits.h:47,
>> from
>> /usr/lib/gcc/i386-redhat-
>> linux/4.3.0/../../../../include/c++/4.3.0/string:47,
>> from BaseGameEntity.h:12,
>> from BaseGameEntity.cpp:1:
>> /usr/include/wchar.h:62: error: conflicting declaration 'typedef
>> unsigned int wint_t'
>> /usr/include/wine/msvcrt/stdio.h:109: error: 'wint_t' has a previous
>> declaration as 'typedef short unsigned int wint_t'
>> In file included from
>> /usr/lib/gcc/i386-redhat-
>> linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52,
>> from
>> /usr/lib/gcc/i386-redhat-
>> linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47,
>> from
>> /usr/lib/gcc/i386-redhat-
>> linux/4.3.0/../../../../include/c++/4.3.0/bits/char_traits.h:47,
>> from
>> /usr/lib/gcc/i386-redhat-
>> linux/4.3.0/../../../../include/c++/4.3.0/string:47,
>> from BaseGameEntity.h:12,
>> from BaseGameEntity.cpp:1:
>> /usr/include/wchar.h:527: error: expected initializer before '*' token
>> /usr/include/wchar.h:534: error: '__FILE' was not declared in this
>> scope
>> /usr/include/wchar.h:534: error: '__fp' was not declared in this scope
>> /usr/include/wchar.h:534: error: expected primary-expression before
>> 'int'
>> /usr/include/wchar.h:534: error: initializer expression list treated
>> as compound expression
>> /usr/include/wchar.h:534: error: expected ',' or ';' before 'throw'
>> /usr/include/wchar.h:541: error: 'int fwprintf' redeclared as
>> different kind of symbol
>> /usr/include/wine/msvcrt/stdio.h:214: error: previous declaration of
>> 'int fwprintf(FILE*, const wchar_t*, ...)'
>> /usr/include/wchar.h:541: error: '__FILE' was not declared in this
>> scope
>> /usr/include/wchar.h:541: error: expected primary-expression before
>> '__restrict__'
>> /usr/include/wchar.h:542: error: expected primary-expression before
>> 'const'
>> /usr/include/wchar.h:542: error: expected primary-expression before
>> '...' token
>> /usr/include/wchar.h:553: error: declaration of C function 'int
>> swprintf(wchar_t*, size_t, const wchar_t*, ...)' conflicts with
>> /usr/include/wine/msvcrt/stdio.h:223: error: previous declaration 'int
>> swprintf(wchar_t*, const wchar_t*, ...)' here
>> /usr/include/wchar.h:559: error: 'int vfwprintf' redeclared as
>> different kind of symbol
>> /usr/include/wine/msvcrt/stdio.h:226: error: previous declaration of
>> 'int vfwprintf(FILE*, const wchar_t*, char*)'
>> /usr/include/wchar.h:559: error: '__FILE' was not declared in this
>> scope
>> /usr/include/wchar.h:559: error: expected primary-expression before
>> '__restrict__'
>> /usr/include/wchar.h:560: error: expected primary-expression before
>> 'const'
>> /usr/include/wchar.h:561: error: expected primary-expression before
>> '__arg'
>> /usr/include/wchar.h:575: error: declaration of C function 'int
>> vswprintf(wchar_t*, size_t, const wchar_t*, char*)' conflicts with
>> /usr/include/wine/msvcrt/stdio.h:227: error: previou
RE: msi/tests: Make tests pass for Windows Installer 3.0 [2/3]
> From: Austin English [mailto:austinengl...@gmail.com] > > Just do as we do in other tests: > ok(GetLastError == Error1 /* Win9X */ || > Error2 /* Win2K */ || > Error3 /* WinXP */... Not possible like that in this case since the error checking is done by a helper function which takes the expected value as a parameter. Since the conscensus seems to be that we do need to check the values, I'll throw in a couple of new helper functions. Gé.
Re: kernel32: fix cpu detection on NetBSD
On Sun, Jan 18, 2009 at 11:40 AM, Francois Gouget wrote: > On Sat, 17 Jan 2009, Austin English wrote: > [...] >> bash-3.2$ make thread.ok >> ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p >> kernel32_test.exe.so thread.c && touch thread.ok >> err:process:__wine_kernel_init boot event wait timed out >> assertion "thread->pt_blockgen == thread->pt_unblockgen" failed: file >> "/home/builds/ab/netbsd-4-0-1-RELEASE/src/lib/libpthread/pthread_lock.c", >> line 195, function "pthread_spinlock" >> assertion "thread->pt_blockgen == thread->pt_unblockgen" failed: file >> "/home/builds/ab/netbsd-4-0-1-RELEASE/src/lib/libpthread/pthread_lock.c", >> line 195, function "pthread_spinlock" >> *** Error code 1 >> >> Stop. >> make: stopped in /home/austin/wine-git/dlls/kernel32/tests >> >> Haven't found a fix for that one yet. They've got a patch in their >> port to use use wine-kthread by default, but doesn't seem to help. > > Ok. That looks like another issue. Does anything run at all on NetBSD? > > > > -- > Francois Gouget http://fgouget.free.fr/ > The last time religion ruled, it was called the dark ages. > Also works fine on OpenBSD (compile at least). Would you go ahead and submit it? It'll be a couple days before I can setup 5.0. -- -Austin
Re: msi/tests: Make tests pass for Windows Installer 3.0 [2/3]
On Mon, Jan 19, 2009 at 3:22 AM, Ge van Geldorp wrote: > Hi James, > >> From: James Hawkins [mailto:trui...@gmail.com] >> >> On Sun, Jan 18, 2009 at 3:38 PM, Ge van Geldorp wrote: >> > I see different estimated size values for Windows Installer 2.x and >> > 3.0 compared to 3.1 and later. >> > >> >> Please don't remove the check. It is set, and that's what >> we're testing. If the value is different on different >> platforms, then do like we do for other tests and add them to >> the check. > > Would it be ok then to check just for the existence of the value, not the > value itself? If you look at > http://test.winehq.org/data/1608cb99b5beb50e1b3f680c832be47944270730/xp_fg-w > inxp-sp1/msi:install.html and > http://test.winehq.org/data/1608cb99b5beb50e1b3f680c832be47944270730/xp_gvg- > wxpprosp2/msi:install.html you'll note that e.g. the test at install.c:2500 > can return at least 3 different values, so I really don't think it makes > sense to check the value itself. I do see your point about checking for the > existence. > > Ge. > > > > Just do as we do in other tests: ok(GetLastError == Error1 /* Win9X */ || Error2 /* Win2K */ || Error3 /* WinXP */... -- -Austin
Re: OpenAL back-end: repost for reconsideration
On Mon, Jan 19, 2009 at 11:33 AM, Stefan Dösinger wrote: > The problem with the openal32.dll -> libopenal.so wrapper was that it broke > some games, and we never debugged why. If anyone wants to continue this > development I think this wrapper library is something that would be highly > welcome. > > As for the winmm driver, Roderick pretty much said it. We don't need another > half baked sound backend, the effort should instead be put into making sure > we have one properly working one for each platform(Alsa for Linux, coreaudio > on the mac, not sure about *BSD and Solaris) > Solaris was libaudioauio, but they're moving toward Boomer, which is supposed to be OSS compatible. *BSD, I'm not sure off, I'll look around. -- -Austin
Re: libs/wine/Makefile.in: replace `wine` with @PACKAGE_NAME@
В сообщении от 18 января 2009 Austin English написал(a): > On Sat, Jan 17, 2009 at 12:31 PM, Vitaly Lipatov wrote: > > В сообщении от 17 января 2009 Paul Chitescu написал(a): > >> > For changing "Wine" to wine", you can pipe through 'tr "W" "w"', > >> > when every supported system has a working "tr". > >> > >> What about using the standard @PACKAGE_TARNAME@ which is by default > >> normalized (spaces removed, converted to lowercase, some other unsafe > >> characters converted) by autoconf in AC_INIT? > > > > It is a good idea to use PACKAGE_TARNAME, but only if we need tarname in > > wine --version output :) > > Does anyone know what is wine --version purpose if not for human read? > > Again, can be used in scripts, many of which aren't public. I guess it is mythical task to check wine version if a new version released every two week. Well, I think I have to fill a bugreport about incorrect output for --version option. A normal program prints version information, not tarball name as wine does. An example: $ dosbox --version DOSBox version 0.72, copyright 2002-2007 DOSBox Team. DOSBox is written by the DOSBox Team (See AUTHORS file)) DOSBox comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain condition. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru
Re: request for packagers - icon for builtin wine internet explorer
On Mon, Jan 19, 2009 at 7:23 AM, Jacek Caban wrote: > Hi Steven, > > Steven Edwards wrote: >> Hi, >> Do you guys that package Wine mind adding Wine Internet Explorer to >> your Wine program group? I think it would be nice to encourage more >> users install gecko and test builtin IE rendering and having the >> shortcut would save them a bit of trouble. >> > > I don't like this idea. Wine builtin iexplore.exe is far from being > usable for users and improving it is low priority. We have enough > problems with apps using IE to render HTML that we should take care of. > > Jacek > > > Agreed. It will just lead to a flood of bug reports that think it's the 'real' IE, then when that doesn't work, people will complain. Maybe in the future when IE rendered apps all work, and we're testing for obscure bugs in our IE implementation, but not now. -- -Austin
RE: wineg++ compile error
It looks like you include two headers that define the same type in a
differnet way. Ie, a typdef from a Linux header collides with a windows
typedef from a Wine header.
> -Original Message-
> From: wine-devel-boun...@winehq.org [mailto:wine-devel-
> boun...@winehq.org] On Behalf Of Rino Farina
> Sent: Monday, January 19, 2009 3:46 PM
> To: wine-devel@winehq.org
> Subject: wineg++ compile error
>
> Hi All,
>
> I'm completely new to wine, and am having trouble compiling code
> before it ever gets to the linker. Can anyone point me in the right
> direction?
>
> BaseGameEntity.h:
>
> #include
>
> class BaseGameEntity
> {
> private:
> int m_ID;
> static int m_iNextValidID;
>
> void SetID(int val);
>
> public:
> BaseGameEntity(int id)
> {
> SetID(id);
> }
>
> virtual ~BaseGameEntity(){}
>
> virtual void Update()=0;
> virtual bool HandleMessage(const long& msg)=0;
>
> int ID()const{return m_ID;}
> };
>
> BaseGameEntity.cpp:
>
> #include "BaseGameEntity.h"
> #include
>
> int BaseGameEntity::m_iNextValidID = 0;
> void BaseGameEntity::SetID(int val)
> {
> assert ( (val >= m_iNextValidID) && ": invalid
> ID");
>
> m_ID = val;
>
> m_iNextValidID = m_ID + 1;
> }
>
>
> Console:
>
> make all
> wineg++ -c -mno-cygwin -I. -o BaseGameEntity.o BaseGameEntity.cpp
> In file included from
> /usr/lib/gcc/i386-redhat-
> linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52,
> from
> /usr/lib/gcc/i386-redhat-
> linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47,
> from
> /usr/lib/gcc/i386-redhat-
> linux/4.3.0/../../../../include/c++/4.3.0/bits/char_traits.h:47,
> from
> /usr/lib/gcc/i386-redhat-
> linux/4.3.0/../../../../include/c++/4.3.0/string:47,
> from BaseGameEntity.h:12,
> from BaseGameEntity.cpp:1:
> /usr/include/wchar.h:62: error: conflicting declaration 'typedef
> unsigned int wint_t'
> /usr/include/wine/msvcrt/stdio.h:109: error: 'wint_t' has a previous
> declaration as 'typedef short unsigned int wint_t'
> In file included from
> /usr/lib/gcc/i386-redhat-
> linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52,
> from
> /usr/lib/gcc/i386-redhat-
> linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47,
> from
> /usr/lib/gcc/i386-redhat-
> linux/4.3.0/../../../../include/c++/4.3.0/bits/char_traits.h:47,
> from
> /usr/lib/gcc/i386-redhat-
> linux/4.3.0/../../../../include/c++/4.3.0/string:47,
> from BaseGameEntity.h:12,
> from BaseGameEntity.cpp:1:
> /usr/include/wchar.h:527: error: expected initializer before '*' token
> /usr/include/wchar.h:534: error: '__FILE' was not declared in this
> scope
> /usr/include/wchar.h:534: error: '__fp' was not declared in this scope
> /usr/include/wchar.h:534: error: expected primary-expression before
> 'int'
> /usr/include/wchar.h:534: error: initializer expression list treated
> as compound expression
> /usr/include/wchar.h:534: error: expected ',' or ';' before 'throw'
> /usr/include/wchar.h:541: error: 'int fwprintf' redeclared as
> different kind of symbol
> /usr/include/wine/msvcrt/stdio.h:214: error: previous declaration of
> 'int fwprintf(FILE*, const wchar_t*, ...)'
> /usr/include/wchar.h:541: error: '__FILE' was not declared in this
> scope
> /usr/include/wchar.h:541: error: expected primary-expression before
> '__restrict__'
> /usr/include/wchar.h:542: error: expected primary-expression before
> 'const'
> /usr/include/wchar.h:542: error: expected primary-expression before
> '...' token
> /usr/include/wchar.h:553: error: declaration of C function 'int
> swprintf(wchar_t*, size_t, const wchar_t*, ...)' conflicts with
> /usr/include/wine/msvcrt/stdio.h:223: error: previous declaration 'int
> swprintf(wchar_t*, const wchar_t*, ...)' here
> /usr/include/wchar.h:559: error: 'int vfwprintf' redeclared as
> different kind of symbol
> /usr/include/wine/msvcrt/stdio.h:226: error: previous declaration of
> 'int vfwprintf(FILE*, const wchar_t*, char*)'
> /usr/include/wchar.h:559: error: '__FILE' was not declared in this
> scope
> /usr/include/wchar.h:559: error: expected primary-expression before
> '__restrict__'
> /usr/include/wchar.h:560: error: expected primary-expression before
> 'const'
> /usr/include/wchar.h:561: error: expected primary-expression before
> '__arg'
> /usr/include/wchar.h:575: error: declaration of C function 'int
> vswprintf(wchar_t*, size_t, const wchar_t*, char*)' conflicts with
> /usr/include/wine/msvcrt/stdio.h:227: error: previous declaration 'int
> vswprintf(wchar_t*, const wchar_t*, char*)' here
> /usr/include/wchar.h:582: error: 'int fwscanf' redeclared as different
> kind of symbol
> /usr/include/wine/msvcrt/stdio.h:216: error: previous declaration of
> 'int fwscanf(FILE*, const wchar_t*, ...)'
> /usr/include/wchar.h:582: error: '__FILE' was not declared in this
> scope
> /usr/include/wchar.h:582
RE: OpenAL back-end: repost for reconsideration
The problem with the openal32.dll -> libopenal.so wrapper was that it broke some games, and we never debugged why. If anyone wants to continue this development I think this wrapper library is something that would be highly welcome. As for the winmm driver, Roderick pretty much said it. We don't need another half baked sound backend, the effort should instead be put into making sure we have one properly working one for each platform(Alsa for Linux, coreaudio on the mac, not sure about *BSD and Solaris)
wineg++ compile error
Hi All,
I'm completely new to wine, and am having trouble compiling code
before it ever gets to the linker. Can anyone point me in the right
direction?
BaseGameEntity.h:
#include
class BaseGameEntity
{
private:
int m_ID;
static int m_iNextValidID;
void SetID(int val);
public:
BaseGameEntity(int id)
{
SetID(id);
}
virtual ~BaseGameEntity(){}
virtual void Update()=0;
virtual bool HandleMessage(const long& msg)=0;
int ID()const{return m_ID;}
};
BaseGameEntity.cpp:
#include "BaseGameEntity.h"
#include
int BaseGameEntity::m_iNextValidID = 0;
void BaseGameEntity::SetID(int val)
{
assert ( (val >= m_iNextValidID) && ": invalid ID");
m_ID = val;
m_iNextValidID = m_ID + 1;
}
Console:
make all
wineg++ -c -mno-cygwin -I. -o BaseGameEntity.o BaseGameEntity.cpp
In file included from
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52,
from
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47,
from
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/char_traits.h:47,
from
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/string:47,
from BaseGameEntity.h:12,
from BaseGameEntity.cpp:1:
/usr/include/wchar.h:62: error: conflicting declaration 'typedef
unsigned int wint_t'
/usr/include/wine/msvcrt/stdio.h:109: error: 'wint_t' has a previous
declaration as 'typedef short unsigned int wint_t'
In file included from
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52,
from
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47,
from
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/char_traits.h:47,
from
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/string:47,
from BaseGameEntity.h:12,
from BaseGameEntity.cpp:1:
/usr/include/wchar.h:527: error: expected initializer before '*' token
/usr/include/wchar.h:534: error: '__FILE' was not declared in this scope
/usr/include/wchar.h:534: error: '__fp' was not declared in this scope
/usr/include/wchar.h:534: error: expected primary-expression before 'int'
/usr/include/wchar.h:534: error: initializer expression list treated
as compound expression
/usr/include/wchar.h:534: error: expected ',' or ';' before 'throw'
/usr/include/wchar.h:541: error: 'int fwprintf' redeclared as
different kind of symbol
/usr/include/wine/msvcrt/stdio.h:214: error: previous declaration of
'int fwprintf(FILE*, const wchar_t*, ...)'
/usr/include/wchar.h:541: error: '__FILE' was not declared in this scope
/usr/include/wchar.h:541: error: expected primary-expression before
'__restrict__'
/usr/include/wchar.h:542: error: expected primary-expression before 'const'
/usr/include/wchar.h:542: error: expected primary-expression before '...' token
/usr/include/wchar.h:553: error: declaration of C function 'int
swprintf(wchar_t*, size_t, const wchar_t*, ...)' conflicts with
/usr/include/wine/msvcrt/stdio.h:223: error: previous declaration 'int
swprintf(wchar_t*, const wchar_t*, ...)' here
/usr/include/wchar.h:559: error: 'int vfwprintf' redeclared as
different kind of symbol
/usr/include/wine/msvcrt/stdio.h:226: error: previous declaration of
'int vfwprintf(FILE*, const wchar_t*, char*)'
/usr/include/wchar.h:559: error: '__FILE' was not declared in this scope
/usr/include/wchar.h:559: error: expected primary-expression before
'__restrict__'
/usr/include/wchar.h:560: error: expected primary-expression before 'const'
/usr/include/wchar.h:561: error: expected primary-expression before '__arg'
/usr/include/wchar.h:575: error: declaration of C function 'int
vswprintf(wchar_t*, size_t, const wchar_t*, char*)' conflicts with
/usr/include/wine/msvcrt/stdio.h:227: error: previous declaration 'int
vswprintf(wchar_t*, const wchar_t*, char*)' here
/usr/include/wchar.h:582: error: 'int fwscanf' redeclared as different
kind of symbol
/usr/include/wine/msvcrt/stdio.h:216: error: previous declaration of
'int fwscanf(FILE*, const wchar_t*, ...)'
/usr/include/wchar.h:582: error: '__FILE' was not declared in this scope
/usr/include/wchar.h:582: error: expected primary-expression before
'__restrict__'
/usr/include/wchar.h:583: error: expected primary-expression before 'const'
/usr/include/wchar.h:583: error: expected primary-expression before '...' token
/usr/include/wchar.h:636: error: '__FILE' was not declared in this scope
/usr/include/wchar.h:636: error: expected primary-expression before
'__restrict__'
/usr/include/wchar.h:637: error: expected primary-expression before 'const'
/usr/include/wchar.h:638: error: expected primary-expression before '__arg'
/usr/include/wchar.h:638: error: initializer expression list treated
as compound expression
/usr/include/wchar.h:692: error: 'wint_t fgetwc' redeclared as
diffe
Re: OpenAL back-end: repost for reconsideration
> After STALKER: Clear Sky failed to generate viable sound output using > the existing drivers (in GIT head as of a few days back), I started > looking for solutions and stumbled over this thread: > http://www.nabble.com/RFC:-OpenAL-Winmm-driver-and-OpenAL32.dll-thunk-was-Re:-OpenAL-and-DirectSound-td7476795.html > > I brought the patch up to speed with current Wine to the best of my > knowledge and pasted it here: http://pastebin.com/f2a559a22 > > It appears to make sound work flawlessly in at least one OpenAL-based > game, and I suspect there may be more. > > In case this driver adds too much of a support/code overhead, would it > be possible to add it as a band-aid, until the problem that prevents the > other back-ends from working with Clear Sky is fixed? > > Thanks for your comments. > > --feep > > PS: No I'm not running Pulseaudio :) There is nothing really wrong with a openal32 -> libopenal wrapper but a winmm openal driver isn't that useful. The reason is that since openal in general just uses oss and alsa (yes on creative cards there is a decent backend) which illustrates that our current oss/alsa plugins can offer similar performance. It is just that various parts aren't very optimal at the moment and adding a winmm openal driver is a workaround and leads to another half baked solution (like esd, jack, nas ..). Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
Re: urlmon/tests: Fix protocol tests when proxy is configured
Hi Jacek, > From: Jacek Caban > Subject: Re: urlmon/tests: Fix protocol tests when proxy is configured > > Ge van Geldorp wrote: > > There is a large amount of proxy configurations possible on > > Windows (WPAD, proxy.pac, fixed proxy values), which might behave > > differently on a second run of the protocol test compared to the > > first run. These configurations influence when/how > > IInternetProtocolSink methods are called. For example, > > with a standard, direct connection you'll get the following > > ReportProgress notifications during the https test: > > BINDSTATUS_FINDINGRESOURCE > > BINDSTATUS_CONNECTING > > BINDSTATUS_SENDINGREQUEST > > BINDSTATUS_ACCEPTRANGES > > BINDSTATUS_MIMETYPEAVAILABLE > > However, when you run the protocol test for the second time > > on a machine with a fixed proxy server configured, you'll only > > get these notifications: > > BINDSTATUS_SENDINGREQUEST > > BINDSTATUS_ACCEPTRANGES > > BINDSTATUS_MIMETYPEAVAILABLE > > > > When a proxy is used, the BINDSTATUS_FINDINGRESOURCE and > > BINDSTATUS_CONNECTING notifications report the hostname/ip > > address of the proxy server, not the end destination. > > I can't see this behavior in tests results, where do you see > them? Which IE version is it? This started when investigated the failures reported here: http://test.winehq.org/data/8b10dd2a8daed738527f92aa89104c8647e4535c/2003_gv g-w2k3r2sesp2/urlmon:protocol.html. This is a Windows 2003 R2 Standard Edition SP2 machine with IE6. The status 32 shown there is BINDSTATUS_PROXYDETECTING. It turns out that on this particular machine "Automatically detect settings" (aka WPAD) was activated. The full sequence of of ReportProtress notifications for the https test was: BINDSTATUS_FINDINGRESOURCE BINDSTATUS_CONNECTING BINDSTATUS_PROXYDETECTING BINDSTATUS_CONNECTING BINDSTATUS_SENDINGREQUEST BINDSTATUS_ACCEPTRANGES BINDSTATUS_MIMETYPEAVAILABLE I then started experimenting on that machine with various proxy settings. I found that this sequence happens on the first run with WPAD configured but no wpad.mydomain.mytld available. On a second run it seems the info that no wpad was available was cached, I got "standard" behavior. If I configured a wpad.mydomain.mytld domain the sequence would also revert back to "standard" on the first run (whether there was a wpad.dat file available from that host or not didn't seem to matter, there just needs to be a wpad.mydomain.mytld DNS entry). When a proxy was indeed configured via WPAD, the BINDSTATUS_FINDINGRESOURCE and BINDSTATUS_CONNECTING notifications reported the hostname/ip address of the proxy server. Next I experimented with "Use automatic configuration script" (aka proxy.pac). I found that in that case the "standard" notification sequence was used, but still with the proxy server hostname/ip address. Finally I set a manual proxy server. In that case, the first time I run the test I get the "standard" sequence, but on the second (and later) runs I see the very minimal sequence mentioned in my original post. So most of the behavior was seen in one-off experimentation. If you want, I can set up some machines to report some of the behaviors to test.winehq.org. > Also, you have to make sure that each SET_EXPECT is followed by > CHECK_CALLED (or CLEAR_CALLED if you want to ignore that function was > not called). Ok, thanks, I'll take care of that. Ge.
OpenAL back-end: repost for reconsideration
After STALKER: Clear Sky failed to generate viable sound output using the existing drivers (in GIT head as of a few days back), I started looking for solutions and stumbled over this thread: http://www.nabble.com/RFC:-OpenAL-Winmm-driver-and-OpenAL32.dll-thunk-was-Re:-OpenAL-and-DirectSound-td7476795.html I brought the patch up to speed with current Wine to the best of my knowledge and pasted it here: http://pastebin.com/f2a559a22 It appears to make sound work flawlessly in at least one OpenAL-based game, and I suspect there may be more. In case this driver adds too much of a support/code overhead, would it be possible to add it as a band-aid, until the problem that prevents the other back-ends from working with Clear Sky is fixed? Thanks for your comments. --feep PS: No I'm not running Pulseaudio :) ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: d3dxof: Fix object files size limitation
Christian Costa writes: > commit 2ddacc839326d96f6508e8e431308160979c7082 > Author: Christian Costa > Date: Mon Jan 19 12:04:09 2009 +0100 > > Fix object files size limitation. If you need to parse such large files using a file mapping would be better than reading it into a buffer. -- Alexandre Julliard julli...@winehq.org
Re: request for packagers - icon for builtin wine internet explorer
Hi Steven, Steven Edwards wrote: > Hi, > Do you guys that package Wine mind adding Wine Internet Explorer to > your Wine program group? I think it would be nice to encourage more > users install gecko and test builtin IE rendering and having the > shortcut would save them a bit of trouble. > I don't like this idea. Wine builtin iexplore.exe is far from being usable for users and improving it is low priority. We have enough problems with apps using IE to render HTML that we should take care of. Jacek
RE: [7/7] d3d9: test table fog and exp fog in the shader fog test
> > -0x005fa000, 0x0040bf00, 0x0020df00, 0xff00, 0xff00}}, > > + 0x005fa000, 0x0040bf00, 0x0020df00, 0xff00, > 0xff00}}, > Any reason for changing the indentation here? I could understand > changing it for consistency, but that's not really the case here. Not really, no. Thanks for catching that, I'll blame my Windows editor(wrote that patch on windows)
RE: [1/7] WineD3D: Don't single-allocate new gl shaders
> -Original Message- > From: wine-devel-boun...@winehq.org [mailto:wine-devel- > boun...@winehq.org] On Behalf Of Henri Verbeet > Sent: Monday, January 19, 2009 12:48 PM > To: wine-devel@winehq.org > Subject: Re: [1/7] WineD3D: Don't single-allocate new gl shaders > > 2009/1/19 Stefan Dösinger : > > +shader->shader_array_size += max(1, old_size * 0.5); > I don't know for sure if the compiler is able to get rid of the > floating point multiplication, but wouldn't a right shift or divide by > 2 work at least as well? I once looked at the assembly, I think it does get rid of the floating point multiplication. A divide by 2 sounds better though. > > +shader->gl_shaders = HeapReAlloc(GetProcessHeap(), 0, > old_array, > > + (shader- > >shader_array_size + 1) * sizeof(*shader->gl_shaders)); > This looks more complicated than it has to be. It's easier to just > change "old_size <= shader->num_gl_shaders" into "old_size < > shader->num_gl_shaders" and drop the +1 here. Also note that > "old_array" isn't particularly useful here, you overwrite > shader->gl_shaders regardless of whether the allocation fails or > succeeds. Actually I wanted to use it to restore the array in the case of a failure, apparently that got lost somewhere; "old_array" is shorter than "shader->gl_shaders" so I used it in the call. I'll resend the patch wave without all the "use this instead" patches after AJ applied todays patches
RE: [4/7] WineD3D: Put vertex shader duplication infrastructure in place
> 2009/1/19 Stefan Dösinger :
> > @@ -1860,14 +1861,19 @@ static void
> shader_arb_destroy(IWineD3DBaseShader *iface) {
> > This->shader_array_size = 0;
> When did this line get added? It's not in 1/7.
It should be in the updated version, at least for PixelShaders. (obviously
vertexshaders don't have the duplication code in 1/7 yet). Still the updated
patch didn't appear in my inbox, so something apparently went wrong
Re: urlmon/tests: Fix protocol tests when proxy is configured
Hi, Ge van Geldorp wrote: > There is a large amount of proxy configurations possible on Windows (WPAD, > proxy.pac, fixed proxy values), which might behave differently on a second > run of the protocol test compared to the first run. These configurations > influence when/how IInternetProtocolSink methods are called. For example, > with a standard, direct connection you'll get the following ReportProgress > notifications during the https test: > BINDSTATUS_FINDINGRESOURCE > BINDSTATUS_CONNECTING > BINDSTATUS_SENDINGREQUEST > BINDSTATUS_ACCEPTRANGES > BINDSTATUS_MIMETYPEAVAILABLE > However, when you run the protocol test for the second time on a machine > with a fixed proxy server configured, you'll only get these notifications: > BINDSTATUS_SENDINGREQUEST > BINDSTATUS_ACCEPTRANGES > BINDSTATUS_MIMETYPEAVAILABLE > > When a proxy is used, the BINDSTATUS_FINDINGRESOURCE and > BINDSTATUS_CONNECTING notifications report the hostname/ip address of the > proxy server, not the end destination. > > I can't see this behavior in tests results, where do you see them? Which IE version is it? Also, you have to make sure that each SET_EXPECT is followed by CHECK_CALLED (or CLEAR_CALLED if you want to ignore that function was not called). Jacek
Re: mshtml: Implement IHTMLDocument5 createComment (try 3)
HI Alistair,
Alistair Leslie-Hughes wrote:
> Hi,
> Removed unused variables.
>
> Changelog:
> mshtml: Implement IHTMLDocument5 createComment
+else
+{
+win_skip("Could not get IHTMLDocument5, probably too old IE\n");
+}
There is no need for skip here. These tests will be skipped in
create_document call if IHTMLDocument5 is not available anyways.
Jacek
Re: [4/7] WineD3D: Put vertex shader duplication infrastructure in place
2009/1/19 Stefan Dösinger :
> @@ -1860,14 +1861,19 @@ static void shader_arb_destroy(IWineD3DBaseShader
> *iface) {
> This->shader_array_size = 0;
When did this line get added? It's not in 1/7.
Re: [7/7] d3d9: test table fog and exp fog in the shader fog test
Since you're going to resend this one anyway: > From: unknown Your From: line is broken. > -0x005fa000, 0x0040bf00, 0x0020df00, 0xff00, 0xff00}}, > + 0x005fa000, 0x0040bf00, 0x0020df00, 0xff00, 0xff00}}, Any reason for changing the indentation here? I could understand changing it for consistency, but that's not really the case here.
Re: [1/7] WineD3D: Don't single-allocate new gl shaders
2009/1/19 Stefan Dösinger :
> +shader->shader_array_size += max(1, old_size * 0.5);
I don't know for sure if the compiler is able to get rid of the
floating point multiplication, but wouldn't a right shift or divide by
2 work at least as well?
> +shader->gl_shaders = HeapReAlloc(GetProcessHeap(), 0, old_array,
> + (shader->shader_array_size + 1)
> * sizeof(*shader->gl_shaders));
This looks more complicated than it has to be. It's easier to just
change "old_size <= shader->num_gl_shaders" into "old_size <
shader->num_gl_shaders" and drop the +1 here. Also note that
"old_array" isn't particularly useful here, you overwrite
shader->gl_shaders regardless of whether the allocation fails or
succeeds.
The typical way to do this would be:
if (shader->num_gl_shaders >= shader->shader_array_size)
{
UINT new_size;
struct ps_compiled_shader *new_array;
if (shader->gl_shaders)
{
new_size = shader->shader_array_size << 1;
new_array = HeapReAlloc(GetProcessHeap(), 0,
shader->gl_shaders, new_size * sizeof(*new_array));
}
else
{
new_size = 1;
new_array = HeapAlloc(GetProcessHeap(), 0, new_size *
sizeof(*new_array));
}
if (!new_array)
{
ERR("Out of memory\n");
return 0;
}
shader->shader_array_size = new_size;
shader->gl_shaders = new_array;
}
This applies to 4/7 as well.
Re: crypt32(4/4): Add a localized name for the TrustedPublisher store
"Juan Lang" writes: > Actually, this doesn't depend on the others. My mistake. It breaks the tests: ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so protectdata.c && touch protectdata.ok protectdata.c:200: Test failed: Description not empty make: *** [protectdata.ok] Error 1 -- Alexandre Julliard julli...@winehq.org
RE: [4/7] WineD3D: Put vertex shader duplication infrastructure in place
Please don't apply this patch and the following ones yet. They break device::reset because they don't delete old gl shaders properly in this case. I'll try to get a fixed patch asap. Patches 1-3 should still be ok > -Original Message- > From: wine-patches-boun...@winehq.org [mailto:wine-patches- > boun...@winehq.org] On Behalf Of Stefan Dösinger > Sent: Monday, January 19, 2009 11:49 AM > To: wine-patc...@winehq.org > Subject: [4/7] WineD3D: Put vertex shader duplication infrastructure in > place >
request for packagers - icon for builtin wine internet explorer
Hi, Do you guys that package Wine mind adding Wine Internet Explorer to your Wine program group? I think it would be nice to encourage more users install gecko and test builtin IE rendering and having the shortcut would save them a bit of trouble. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
RE: msi/tests: Make tests pass for Windows Installer 3.0 [2/3]
Hi James, > From: James Hawkins [mailto:trui...@gmail.com] > > On Sun, Jan 18, 2009 at 3:38 PM, Ge van Geldorp wrote: > > I see different estimated size values for Windows Installer 2.x and > > 3.0 compared to 3.1 and later. > > > > Please don't remove the check. It is set, and that's what > we're testing. If the value is different on different > platforms, then do like we do for other tests and add them to > the check. Would it be ok then to check just for the existence of the value, not the value itself? If you look at http://test.winehq.org/data/1608cb99b5beb50e1b3f680c832be47944270730/xp_fg-w inxp-sp1/msi:install.html and http://test.winehq.org/data/1608cb99b5beb50e1b3f680c832be47944270730/xp_gvg- wxpprosp2/msi:install.html you'll note that e.g. the test at install.c:2500 can return at least 3 different values, so I really don't think it makes sense to check the value itself. I do see your point about checking for the existence. Ge.
Re: Debian packages of Wine
Ben Klein wrote: > > I've also been playing around with -Zlzma. I can only get my packages > down to about 11MB, even with dev headers removed. Is there anything > else you can think of that you've done differently or specially? Nope. You can look at the source package if you like, it's possible something is being deleted or not built (wine test?) -Scott Ritchie
