February 2007 - Wine-Devel - list.winehq.org

Re: [msvcrt] properly align struct _stati64's st_size

by Dmitry Timoshkov

"Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > In wine's struct _stati64, st_size has an offset of 20 bytes from the > beginning of the struct, unlike mingw's and Window's 24. This breaks > Java 1.4.x pretty badly, it dies on startup complaining about a > truncated class file (#2953). Using #include <pshpack8.h> and #include > <pshpop8.h> around the struct didn't help, so a padding field was used > instead. Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to align the Size field help? #include <pshpack8.h> typedef struct _WIN32_STREAM_ID { DWORD dwStreamId; DWORD dwStreamAttributes; LARGE_INTEGER DECLSPEC_ALIGN(8) Size; DWORD dwStreamNameSize; WCHAR cStreamName[ANYSIZE_ARRAY]; } WIN32_STREAM_ID, *LPWIN32_STREAM_ID; #include <poppack.h> > +static void test_stat( void ) > +{ > + int offset = offsetof(struct _stati64, st_size); > + ok(offset == 24, "struct _stati64's st_size is misaligned, got %d, expected 24\n", offset); > +} This should be a part of auto generated header tests. Have a look at dlls/*/tests/generated.c files. -- Dmitry.

Feb. 3, 2007

Re: Getting Fallout 2 to work well

by Mirek

Sorry, my mistake :) How can I download wine from your tree? Yes, your latest patches from 26.1.2007 fixed this regression, great work! Mirek Stefan Dösinger napsal(a): > Am Freitag 02 Februar 2007 17:15 schrieb Mirek: >> Getting Fallout 2 to work well >> Hi, for me Flatout 2 works perfect with latest CVS wine and some Stefan >> patches from 26.1.2007 > > Not the same game. Fallout 2 is an old ddraw game, Flatout 2 is a Direct3D9 > game afaik. > > Did you do a regression test to localize the Flatout 2 performance regression? > I suspect my StretchRect patch, and I have a fix for it in my tree.

Feb. 3, 2007

Re: Getting Fallout 2 to work well

by Stefan Dösinger

Am Freitag 02 Februar 2007 17:15 schrieb Mirek: > Getting Fallout 2 to work well > Hi, for me Flatout 2 works perfect with latest CVS wine and some Stefan > patches from 26.1.2007 Not the same game. Fallout 2 is an old ddraw game, Flatout 2 is a Direct3D9 game afaik. Did you do a regression test to localize the Flatout 2 performance regression? I suspect my StretchRect patch, and I have a fix for it in my tree.

Feb. 3, 2007

Re: [lostwages] Update download-deb page with better information, error fixes

by Scott Ritchie

On Sat, 2007-02-03 at 00:06 -0700, Vitaliy Margolen wrote: > Detlef Riekenberg wrote: > > On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: > >> + > >> +<p>While there is currently no Wine package explicitly designed for > >> the 64-bit version > >> +of Ubuntu, there are several hacks that can be used to install the > >> 32-bit package > >> +into the 64-bit distribution and have it function normally. See > >> +<a href="https://wiki.ubuntu.com/I386WineInAmd64">this page on the > >> Ubuntu wiki</a> > >> +for more details.</p> > > > > IMHO, a link to our own Wiki should be placed on the download-deb page > > > > http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964c… > > > > > > And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and > > https://help.ubuntu.com/community/WineForAMD64 > > > > The provided automatic installation script includes the sidenet-script. > > Please include a BIG WARNING, that this is never supported by winehq > > and the users need a clean wine, before they ask for help on #winehq > > or wine-users(a)winehq.org > > > > > > You mention sidenet on that page: > > "If you followed the manual instructions you need to install the Sidenet > > script" > > This is wrong. Please remove that line! > > > > Even, when the sidenet-script might help some users to run an app, > > "you need to install the Sidenet script" is wrong! > > I still see that information listed on the mentioned page. I was hopping > we could get some useful information for Ubuntu-64 users. > I guess not. I will discourage anyone from referring to the above > mentioned page because it has sedenet script as a "requirement". It's > the same stuff as winetools and _brakes_ default Wine configuration. > > > Vitaliy I just fixed it to make it better. I have half a mind to delete all mention of sidenet from the page entirely. I'll change the link to a page on our wiki with the same info and resend. Thanks, Scott Ritchie

Feb. 3, 2007

Re: [lostwages] Update download-deb page with better information, error fixes

by Vitaliy Margolen

Detlef Riekenberg wrote: > On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: >> + >> +<p>While there is currently no Wine package explicitly designed for >> the 64-bit version >> +of Ubuntu, there are several hacks that can be used to install the >> 32-bit package >> +into the 64-bit distribution and have it function normally. See >> +<a href="https://wiki.ubuntu.com/I386WineInAmd64">this page on the >> Ubuntu wiki</a> >> +for more details.</p> > > IMHO, a link to our own Wiki should be placed on the download-deb page > > http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964c… > > > And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and > https://help.ubuntu.com/community/WineForAMD64 > > The provided automatic installation script includes the sidenet-script. > Please include a BIG WARNING, that this is never supported by winehq > and the users need a clean wine, before they ask for help on #winehq > or wine-users(a)winehq.org > > > You mention sidenet on that page: > "If you followed the manual instructions you need to install the Sidenet > script" > This is wrong. Please remove that line! > > Even, when the sidenet-script might help some users to run an app, > "you need to install the Sidenet script" is wrong! I still see that information listed on the mentioned page. I was hopping we could get some useful information for Ubuntu-64 users. I guess not. I will discourage anyone from referring to the above mentioned page because it has sedenet script as a "requirement". It's the same stuff as winetools and _brakes_ default Wine configuration. Vitaliy

Feb. 3, 2007

Re: winetest: add support for http_proxy environment variable

by Detlef Riekenberg

On So, 2007-01-14 at 15:13 +0100, Németh Márton wrote: Welcome to wine. I have some comments about your Patch: > diff -u -r wine-0.9.29.orig/ChangeLog wine-0.9.29/ChangeLog > --- wine-0.9.29.orig/ChangeLog 2007-01-09 16:42:47.000000000 +0100 > +++ wine-0.9.29/ChangeLog 2007-01-14 15:02:31.000000000 +0100 The changelog will be updated during a release with the Informations from the subject. > + > + http_proxy = getenv("http_proxy"); > + if (http_proxy) { > + /* Proxy configuration found */ > + memset(&regex, 0, sizeof(regex)); > + retval = regcomp(&regex, The Idea to support a http-proxy is good, but the Programm must run on Windows. 1. I never saw an environment-variable "http_proxy" on Windows. Most Windows-Applications use the Proxy-Data from IE (Get the settings from there) 2. "regcomp" and friends are posix, but not available on windows Thanks for helping wine. -- By by ... Detlef

Feb. 2, 2007

Re: [PATCH] ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps.

by John Morris

On 2/2/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > John Morris wrote: > > I'm resubmitting the patch without the changelog entry. > > > > > > ------------------------------------------------------------------------ > > > > From 4c51e49d432eb8342cadb71a3d539b2e8574849b Mon Sep 17 00:00:00 2001 > > From: John Morris <mailjohnmorris(a)gmail.com> > > Date: Fri, 2 Feb 2007 13:20:34 -0600 > > Subject: ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps. > > > > --- > > dlls/ole32/ole32.spec | 1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > > index d775556..3ae0240 100644 > > --- a/dlls/ole32/ole32.spec > > +++ b/dlls/ole32/ole32.spec > > @@ -76,6 +76,7 @@ > > @ stub CoUnloadingWOW > > @ stdcall CoUnmarshalHresult(ptr ptr) > > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > > @ stdcall CreateAntiMoniker(ptr) > > @ stdcall CreateBindCtx(long ptr) > > @ stdcall CreateClassMoniker(ptr ptr) > > > > > > ------------------------------------------------------------------------ > > > > > Hi, > > I thought we use: > > @ stub CoWaitForMultipleHandles > > for functions that should be exported and are not implemented at all, and use > > @ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > > where we at least have something in a *.c file (although that could be a simple > return): > > HRESULT WINAPI CoWaitForMultipleHandles(<stuff>) { > FIXME("unimplemented stub!\n"); > return E_FAIL; <or something alike> > } > > Isn't the first one a stub and the second one a semi-stub, or have I mixed up > things? > > Cheers, > > Paul. > > > It appears to be implemented in dlls/ole32/compobj.c

Feb. 2, 2007

Re: [PATCH] ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps.

by Paul Vriens

John Morris wrote: > I'm resubmitting the patch without the changelog entry. > > > ------------------------------------------------------------------------ > > From 4c51e49d432eb8342cadb71a3d539b2e8574849b Mon Sep 17 00:00:00 2001 > From: John Morris <mailjohnmorris(a)gmail.com> > Date: Fri, 2 Feb 2007 13:20:34 -0600 > Subject: ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps. > > --- > dlls/ole32/ole32.spec | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > index d775556..3ae0240 100644 > --- a/dlls/ole32/ole32.spec > +++ b/dlls/ole32/ole32.spec > @@ -76,6 +76,7 @@ > @ stub CoUnloadingWOW > @ stdcall CoUnmarshalHresult(ptr ptr) > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > @ stdcall CreateAntiMoniker(ptr) > @ stdcall CreateBindCtx(long ptr) > @ stdcall CreateClassMoniker(ptr ptr) > > > ------------------------------------------------------------------------ > > Hi, I thought we use: @ stub CoWaitForMultipleHandles for functions that should be exported and are not implemented at all, and use @ stdcall CoWaitForMultipleHandles(long long long ptr ptr) where we at least have something in a *.c file (although that could be a simple return): HRESULT WINAPI CoWaitForMultipleHandles(<stuff>) { FIXME("unimplemented stub!\n"); return E_FAIL; <or something alike> } Isn't the first one a stub and the second one a semi-stub, or have I mixed up things? Cheers, Paul.

Feb. 2, 2007

Re: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to W indows apps.

by John Morris

Sorry, I misunderstood the sending patches guideline on the winehq page. It sounds like it is instructing me to include a changelog entry. I'll resubmit it. Thanks, John On 2/1/07, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Hello John, > > thanks for the patch. > You do not need to add the entry to the ChangeLog file. That is done > automaticly using the git changelog entries during the release of a new > Wine version. Would you mind resubmitting the patch without that? > > bye > michael > > John Morris wrote: > > From 79b3a4ba86ec3ddbd4b8be7c04bb350d78c78bfa Mon Sep 17 00:00:00 2001 > > From: John Morris <mailjohnmorris(a)gmail.com> > > Date: Wed, 31 Jan 2007 17:38:04 -0600 > > Subject: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to Windows apps. > > > > --- > > ChangeLog | 5 +++++ > > dlls/ole32/ole32.spec | 1 + > > 2 files changed, 6 insertions(+), 0 deletions(-) > > > > diff --git a/ChangeLog b/ChangeLog > > index 658036c..ce545d0 100644 > > --- a/ChangeLog > > +++ b/ChangeLog > > @@ -1,3 +1,8 @@ > > +2007-01-31 John Morris <mailjohnmorris(a)gmail.com> > > + > > + * dlls/ole32/ole32.spec: > > + ole32: Add CoWaitForMultipleHandles to spec file so it will be visible to windows apps. > > + > > 2007-01-24 Vitaliy Margolen <wine-patches(a)kievinfo.com> > > > > * server/token.c: > > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > > index d775556..3ae0240 100644 > > --- a/dlls/ole32/ole32.spec > > +++ b/dlls/ole32/ole32.spec > > @@ -76,6 +76,7 @@ > > @ stub CoUnloadingWOW > > @ stdcall CoUnmarshalHresult(ptr ptr) > > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > > @ stdcall CreateAntiMoniker(ptr) > > @ stdcall CreateBindCtx(long ptr) > > @ stdcall CreateClassMoniker(ptr ptr) > > > > > > ------------------------------------------------------------------------ > > > > > > > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart >

Feb. 2, 2007

Re: comdlg32-colordlg fix bgcolor

by Dmitry Timoshkov

"Ivan Sinitsin" <ivan(a)etersoft.ru> wrote: > This line obviously sets color (considering the current scheme), it transfers > as a background current system color of the scheme for display of a > background of elements of management. Has checked up, at change of color > schemes - dialogue is displayed correctly. My concern is why do you change GCLP_HBRBACKGROUND (a system setting) at all? Should the painting code be changed instead to use explicit background color in CC_PaintTriangle? -- Dmitry.

Feb. 2, 2007