September 2006 - Wine-Devel

Award for solving bug 6183
by Mirek Sept. 28, 2006

Sept. 28, 2006

There is bug in wine, which prevents me to play NFS MW with sound (and even Call of Duty). I would like to offer some money for solving this bug. I dont know how much will be good and i can give you all info from my system to solve this (debug, system info). If you are interested in just reply on my email address. Thanks, Mirek

1 0

Re: msi: Implement MsiDatabaseImport [try2]
by Alexandre Julliard Sept. 28, 2006

Sept. 28, 2006

"James Hawkins" <truiken(a)gmail.com> writes: > +static LPWSTR msi_read_text_archive(LPCWSTR path) > { > - FIXME("%p %s %s\n", db, debugstr_w(folder), debugstr_w(file) ); > + HANDLE file; > + LPSTR data = NULL; > + DWORD read, size = 0; > + > + file = CreateFileW( path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL ); > + if (file == INVALID_HANDLE_VALUE) > + return NULL; > + > + size = GetFileSize( file, NULL ); > + data = msi_alloc( size + 1 ); > + if (!data) > + return NULL; > + > + if (!ReadFile( file, data, size, &read, NULL )) > + return NULL; > + > + data[size] = '\0'; > + return strdupAtoW( data ); > +} You're leaking both the file and the ascii string. -- Alexandre Julliard julliard(a)winehq.org

1 0

Coverity coverage of Wine
by Paul Vriens Sept. 28, 2006

Sept. 28, 2006

Hi, the latest run (with report) on the Coverity site seems to be from July 21st. It appears that the main page is updated though (not for the lines of code but for the errors fixed). Does anybody know more about the why? I've tried to contact Coverity for the last month and my last email (where I've requested a read-receipt, shame on me) was deleted without being read. Cheers, Paul.

2 5

Re: Route WGL font code through gdi32.dll
by Huw Davies Sept. 28, 2006

Sept. 28, 2006

On Thu, Sep 28, 2006 at 08:01:00AM +0200, Roderick Colenbrander wrote: > As mentioned by Huw, I forgot to attach the gdi32.spec changes :( > This is (hopefully) a full patch. > > --- dlls/opengl32/opengl32.spec 2006-09-25 23:15:35.000000000 +0200 > +++ dlls/opengl32/opengl32.spec 2006-09-27 23:09:11.000000000 +0200 > @@ -396,5 +396,5 @@ > @ stdcall wglSwapLayerBuffers(long long) > @ stdcall wglUseFontBitmapsA(long long long long) > @ stdcall wglUseFontBitmapsW(long long long long) > -@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) > -@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) > +@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) gdi32.wglUseFontOutlinesA > +@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) gdi32.wglUseFontOutlinesW You're still forwarding the wrong set of UseFont functions here. Your patch moved wglUseFontBitmaps to gdi32, so you should forward those not wglUseFontOutlines. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: oleaut32 1/2: [RESEND 2] Implements function varformat:VarWeekdayName
by Alexandre Julliard Sept. 28, 2006

Sept. 28, 2006

"Benjamin Arai" <me(a)benjaminarai.com> writes: > + if (fAbbrev) > + if (iFirstDay == 0) > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 5) % 7); > + else > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); > + else > + if (iFirstDay == 0) > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 5) % 7); > + else > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); iFirstDay == 0 is supposed to mean system default, but that is locale-dependent, you can't simply hardcode it. -- Alexandre Julliard julliard(a)winehq.org

1 0

wined3d base GLX requirement
by Ivan Gyurdiev Sept. 28, 2006

Sept. 28, 2006

The current base GLX requirement for wined3d seems to be v1.3. It won't compile otherwise... I wrote a patch for pbuffers, which adds proper extension support for SGIX_PBUFFER and SGIX_FBCONFIG, but: - even with the patch there's additional offenders in directx.c that prevent a compile with glx < 1.3 [ more FBCONFIG dependencies ] - there's comments in the source saying ATI supports pbuffers, but only advertises GLX_VERSION_1_3, without the appropriate extensions. So - should GLX 1.3 be considered a base requirement for wined3d, or should I send patches to clean up pbuffer dependencies?

5 6

Linklint results for winehq
by Tom Wickline Sept. 28, 2006

Sept. 28, 2006

Hello, I ran our linklint script on winehq and here's the results. I will try and fix as many errors as possible over the next couple weeks. Tom --- Processing ... writing files to linklint wrote 25 txt files wrote 23 html files wrote index file index.html found 1 default index found 476 cgi files found 3 html files found 17 image files found 208 other files found 3833 http links found 5 https links found 20 ftp links found 54 mailto links found 15 news links found 2 unknown links found 2658 named anchors ----- 766 ignored files ----- 3 actions skipped ----- 125 files skipped warn 3 warnings ERROR 1 missing image file ERROR 3 missing other files ERROR 99 missing named anchors Linklint found 705 files and checked 500 html files. There were 4 missing files. 13 files had broken links. 103 errors, 3 warnings. real 5m58.972s user 0m6.960s sys 0m0.320s checking 3833 urls ...

1 1

Re: Patchwork (was Re: Governance revisited)
by Ge van Geldorp Sept. 28, 2006

Sept. 28, 2006

> From: Alexandre Julliard <julliard(a)winehq.org> > > If you expect > anything to happen, you'll need to make much more concrete > suggestions, and provide examples to make us understand how > what you are suggesting would work in practice Fair enough. Some disclaimers upfront: I'm basically thinking out loud, I have no idea what your typical workflow looks like. I'm also not restrained by any knowledge of emacs and what can be done in its plugins, macro's, user-defined commands or whatever they're called. But I know I could code the proposal below in e.g Perl or C, so I guess it should be possible in Lisp also. Who's going to code that is a different matter altogether, let's first see if we can think of a solution which would work. Let's assume a patch is submitted to wine-patches. A bot would receive it and store it in a database (Patchwork already seems to do a fine job on this). The bot could do some simple checks, like does it apply cleanly, no C++ comments, whatever automatic checks we can come up with. If one of the checks fails, the status would be set to RFC (Request For Change, I'm using the Patchwork statuses here) and the author would receive an automatic email explaining what's wrong, otherwise the status would be set to New. Note that this should save you some time, weeding out "obviously" wrong patches. On to your workflow. You'd issue a Meta-Ctrl-Shift-whatever emacs command. Behind the scenes, this would send a request to the webserver which would reply with a list of queued patches. This list could be sorted by a score. Authors who consistently submit good patches would get a higher score than, well, me. This score could be computed as the number of accepted patches minus the number of rejected patches. A patch already reviewed (and recommended) by a subsystem maintainer could get a real big score boost so it ends up near the top of the list. Patches which have been in the queue for a few days could get extra points. Patches with RFC status wouldn't be shown at all or get a very low score. Anyway, you end up with a list of patches on your screen with the least problematic near the top. This should help ensure that these get through pretty quickly. So you select a patch which is then retrieved from the server. It could be automatically applied, a build started, whatever suits you best. Comments made on it by other developers could be shown to you. After testing is complete, you issue a "decision" command. You can decide to accept the patch, that would send an "accept" message to the webserver and perhaps it could be comitted to your git repo. If the patch needs more work, you'll be prompted for a message. That message will be mailed to the author with a copy to win-devel and it will be sent to the webserver which will change the patch status to RFC. If you think the patch is beyond hope it can be rejected outright (again with a message to author and wine-devel). Or you can decide not to decide on it today and sleep on it for a night. Then the patch will just show up in the list of pending patches again tomorrow, with a little bit higher priority (since it has been in the queue longer). Back to the list of pending patches, repeat. > and how it would be different from what we are doing now. It would make sure the author always receives some kind of feedback (either from the bot, other developers or yourself) and would make sure patches don't get lost (patches are automatically entered into the system and only leave the system when the author withdraws them or when you make a final decision). Ge van Geldorp.

6 6

Re: [PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Vitaliy Margolen Sept. 28, 2006

Sept. 28, 2006

Christoph Frick wrote: > hi > > would someone please comment on that patch? this is a nearly unchanged > version of my previous attempt - but this time against current git. > > -static const unsigned int depths[] = {8, 16, 32}; > +static const unsigned int depths[] = {8, 16, 32, 24}; > +static const unsigned int nr_depths = sizeof(depths) / sizeof(depths[0]); > Can you make a test that demonstrates presence of 24-bit color depth on native? I have checked winnt40, win2k, winxp and none offering 24-bit. Also I seen some programs and games that will crash if you tell them that we really in 24-bit (as most X users are). Vitaliy.

1 0

Re: Problem with NtReadVirtualMemory and wine server connection
by Juan Lang Sept. 28, 2006

Sept. 28, 2006

Hi Peter, I'm guessing the fact that no one has replied means that no one has a strong opinion, or no one feels qualified to answer, or that AJ would prefer to see a patch first. I'll give my opinion in the hope of stimulating discussion, as I think it's important. > 1. allocate a temporary buffer in NtReadVirtualMemory, read server > answer to this buffer, and then inside a try / catch block copy to > application memory This would be my preference, for two reasons: 1. This would allow the test to pass, that is, we could successfully return STATUS_ACCESS_VIOLATION in this case. 2. The server protocol appears to be robust enough, as it crashes the client, not the server. The problem is mapping the fault to an NTSTATUS, and recovering from it. The disadvantage may be that each server request would have to be checked whether it could fail in the same way. Any other opinions? --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

How hard is Uniscribe's ScriptLayout() to implement?
by Dan Kegel Sept. 27, 2006

Sept. 27, 2006

See http://bugs.winehq.org/show_bug.cgi?id=5772 Quicktime 6.5.x, Eclipse 3.2, Word XP, and other apps crash because usp10.ScriptLayout() isn't implemented. How hard would it be to fix this? - Dan

2 4

Re: Route WGL font code through gdi32.dll
by Huw Davies Sept. 27, 2006

Sept. 27, 2006

On Wed, Sep 27, 2006 at 11:34:35PM +0200, Roderick Colenbrander wrote: > Hi, > > This patch routes the WGL font code through gdi32.dll. The patch depends on the other routing patch which routed the WGL context code through gdi32.dll. > --- dlls/opengl32/opengl32.spec 2006-09-25 23:15:35.000000000 +0200 +++ dlls/opengl32/opengl32.spec 2006-09-27 23:09:11.000000000 +0200 @@ -396,5 +396,5 @@ @ stdcall wglSwapLayerBuffers(long long) @ stdcall wglUseFontBitmapsA(long long long long) @ stdcall wglUseFontBitmapsW(long long long long) -@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) -@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) +@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) gdi32.wglUseFontOutlinesA +@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) gdi32.wglUseFontOutlinesW You want to forward the wglUseFontBitmaps functions here since that's what the rest of your patch touches ;-) You also forgot to include the changes to gdi32.spec. Huw.

1 0

re: oleaut32 2/2: [RESEND] Conformance test for varformat:VarWeekdayName
by Dan Kegel Sept. 27, 2006

Sept. 27, 2006

Alexandre wrote: > How will this test work in non-English locales? How about if it calls SetThreadLocale(LOCALE_INVARIANT)?

3 2

Re: start.exe: Implement /D option, add new wine specific feature allowing to specify the shell operation name (resend)
by James Hawkins Sept. 27, 2006

Sept. 27, 2006

On 9/26/06, Paul Chitescu <paulc(a)voip.null.ro> wrote: > Changelog: start.exe: Implement /D option, add new wine specific feature > allowing to specify the shell operation name. > > The new /O[peration] command line option allows to specify a shell operation > other than "open". This is very valuable for testing or implementing actions > from shell scripts. > > It is also possible to pass a NULL operation by specifying the empty string > '' (or whatever looks like in your preferred shell). > > Examples: > wine start /d 'c:\' notepad.exe > wine start /o print README.txt > Only submit one fix per patch. Please read the WineHQ patch guidelines: http://winehq.org/site/sending_patches Why are you adding a new switch? This isn't provided by native start.exe, so we shouldn't add it. -- James Hawkins

2 2

Re: localspl: [1/3] Build the Importlib
by Alexandre Julliard Sept. 27, 2006

Sept. 27, 2006

Detlef Riekenberg <wine.dev(a)web.de> writes: > We need the importlib for the tests It doesn't seem that we should have an importlib, there isn't one in the SDK either. The tests can always use GetProcAddress. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Stefan Dösinger Sept. 27, 2006

Sept. 27, 2006

Hi, > would someone please comment on that patch? this is a nearly unchanged > version of my previous attempt - but this time against current git. Not so sure about it. I am afraid I do not completely understand the color depth issue, but it appears to me that a patch like that rather hides the problem than fixing it. It is not possible to chance the depth on the fly on X11, so we may want a solution for all color depths.

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Dmitry Timoshkov Sept. 27, 2006

Sept. 27, 2006

"Thomas Weidenmueller" <wine-patches(a)reactsoft.com> wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. Then it should be changed to 'ULONG' or 'unsigned LONG' for compatibility with Win64. -- Dmitry.

2 2

Re: oleaut32 2/2: [RESEND] Conformance test for varformat:VarWeekdayName
by Alexandre Julliard Sept. 27, 2006

Sept. 27, 2006

"Benjamin Arai" <me(a)benjaminarai.com> writes: > +void test_VarWeekdayName(void) > +{ > + WCHAR day_LongFormat[][10] = > + { > + {'S','u','n','d','a','y',0}, > + {'M','o','n','d','a','y',0}, > + {'T','u','e','s','d','a','y',0}, > + {'W','e','d','n','e','s','d','a','y',0}, > + {'T','h','u','r','s','d','a','y',0}, > + {'F','r','i','d','a','y',0}, > + {'S','a','t','u','r','d','a','y',0} > + }; How will this test work in non-English locales? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: clusapi: Implements stub dll for clusapi
by Alexandre Julliard Sept. 27, 2006

Sept. 27, 2006

"Benjamin Arai" <me(a)benjaminarai.com> writes: > Fixes bug http://bugs.winehq.org/show_bug.cgi?id=6265 > > The application for bug 6265 checks if clusapi.dll exists and attempts > to call clusapi:GetNodeClusterState from it. This patch adds a stub > implementation for the DLL clusapi and GetNodeClusterState. You need to add a DLL_WINE_PREATTACH handler when adding a stub dll. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wintrust.h: add missing defines
by Paul Vriens Sept. 27, 2006

Sept. 27, 2006

On Tue, 2006-09-26 at 22:08 -0700, Juan Lang wrote: > #define WTD_UI_ALL 1 > #define WTD_UI_NONE 2 > @@ -115,6 +118,42 @@ > DWORD dwUIContext; > } WINTRUST_DATA, *PWINTRUST_DATA; > > +#define WTD_UI_ALL 1 > +#define WTD_UI_NONE 2 > +#define WTD_UI_NOBAD 3 > +#define WTD_UI_NOGOOD 4 > + > +#define WTD_REVOKE_NONE 0 > +#define WTD_REVOKE_WHOLECHAIN 1 > + > +#define WTD_CHOICE_FILE 1 > +#define WTD_CHOICE_CATALOG 2 > +#define WTD_CHOICE_BLOB 3 > +#define WTD_CHOICE_SIGNER 4 > +#define WTD_CHOICE_CERT 5 Hi Juan, these ones you've added are already in (see also first line in the excerpt from your email). Cheers, Paul.

2 1

Re: H. Verbeet : wined3d: Add support for native NPOT textures.
by Frank Richter Sept. 27, 2006

Sept. 27, 2006

On 27.09.2006 10:46, Alexandre Julliard wrote: > @@ -765,6 +768,12 @@ #undef USE_GL_FUNC > > gl_info->max_sampler_stages = max(gl_info->max_samplers, gl_info->max_texture_stages); > > + /* We can only use NP2_NATIVE when the hardware supports it. */ > + if (wined3d_settings.nonpower2_mode == NP2_NATIVE && !gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO]) { > + WARN_(d3d_caps)("GL_ARB_texture_non_power_of_two not supported, falling back to NP2_NONE NPOT mode.\n"); > + wined3d_settings.nonpower2_mode = NP2_NONE; > + } > + FYI, ATI r300+ hardware has some limited support for NP2 textures - that is, 2D textures without mipmaps and repeat mode CLAMP. But since that does not fulfill the ARB_tnpot requirements this extension isn't published. Still, maybe you can exploit that feature somehow... -f.r.

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Michael Stefaniuc Sept. 27, 2006

Sept. 27, 2006

Thomas Weidenmueller wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. Won't work on Win64. long is 32bits on Win32 and Win64. On Linux64 long is 64bits. bye michael > ------------------------------------------------------------------------ > > Index: dlls/rpcrt4/rpc_server.c > =================================================================== > RCS file: /home/wine/wine/dlls/rpcrt4/rpc_server.c,v > retrieving revision 1.58 > diff -u -r1.58 rpc_server.c > --- dlls/rpcrt4/rpc_server.c 30 Jun 2006 19:16:38 -0000 1.58 > +++ dlls/rpcrt4/rpc_server.c 27 Sep 2006 12:38:00 -0000 > @@ -1008,7 +1008,7 @@ > /*********************************************************************** > * RpcMgmtSetServerStackSize (RPCRT4.@) > */ > -RPC_STATUS WINAPI RpcMgmtSetServerStackSize(unsigned int ThreadStackSize) > +RPC_STATUS WINAPI RpcMgmtSetServerStackSize(unsigned long ThreadStackSize) > { > FIXME("(0x%x): stub\n", ThreadStackSize); > return RPC_S_OK; -- 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

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Paul Vriens Sept. 27, 2006

Sept. 27, 2006

On Wed, 2006-09-27 at 14:40 +0200, Thomas Weidenmueller wrote: > FIXME("(0x%x): stub\n", ThreadStackSize); Shouldn't that be (0x%lx) then ? Cheers, Paul.

1 0

some wineconference pictures
by Marcus Meissner Sept. 27, 2006

Sept. 27, 2006

Hi, Some Wine conference pictures from David and myself: http://gallery.kuschelt.net/main.php?g2_view=core.ShowItem&g2_itemId=100617 Ciao, Marcus

2 1

Governance revisited
by Robert Lunnon Sept. 27, 2006

Sept. 27, 2006

I note the recent flamefest, where some of this list seared yet another contributor (Roland Kaeser) Since this particular very old, very shrivelled chestnut. is one of my personal favourites (thanks to Colin Wright for the chestnut thing...). I'd like to repeat my observations about this. Feel free to flame away since I have donned my asbestos suit and have long since decided my viewpoint. The problem is that code gets rejected that is *** NOT *** Hacky because there is a, single point of review - a single opinion of what constitutes a hack, and no appeal process. For example I once submitted code to implement cpu.c using the x86 cpuid instruction directly on all x86 platforms. This was NO hack. But the code was rejected. This code replaces the OS specific code for several x86 cases with generic code. The way I see it this code removes hacks (since I consider any OS specific code fragment a hack). This just shows that opinions differ about what a hack is. This code now sits in my patch-kit, never to see the light of day on wine-hq, but happily runs in every copy of wine for Solaris for the last 4 years with ZERO issues. No hacks should not be an objective, by my definition wine already has more hacks than just about any other open source package out there. Linuxisms continue to contaminate wine every month (I can vouch for it). What we need is management, balance between function and beauty delivered by peer review. Necessary functional hacks should be allowed unless they have severe side-effects. Even application specific work-arounds can be permitted if the work around adds significant functionality per the objectives of the project, the scope of the work-around is suitably confined, and assuming the code can be maintained over time. Wine needs process... The issue is not code, It's governance. Governance to establish balance, balance between beauty and function. Bob

24 55