September 2006 - Wine-Devel

Low-level coding
by Aaron Slunt Sept. 13, 2006

Sept. 13, 2006

Hi, I was interested in starting to play with wine and maybe even build a few functions for it...but then I realized that it's low-level coding, something I'm not familiar with (higher level is more of my expertise). Correct me if I'm wrong, I could be looking at the wrong files :S. Does anyone have any good places to go to to learn about low-level coding, and afterwards coding for wine specifically? Thanks. -- Tired of being hammered by spyware, or want to browse the internet in a whole new way? Download Firefox and enjoy a much better internet experience. http://getfirefox.com/

7 8

Re: cabinet: Add breaks to switch statements
by H. Verbeet Sept. 13, 2006

Sept. 13, 2006

On 13/09/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Changelog: > cabinet: Add breaks to switch statements. > > diff -urN a/dlls/cabinet/fci.c b/dlls/cabinet/fci.c > --- a/dlls/cabinet/fci.c 2006-09-12 11:55:48.000000000 +0100 > +++ b/dlls/cabinet/fci.c 2006-09-12 23:29:02.000000000 +0100 > @@ -454,11 +454,12 @@ > switch (cb % 4) { > case 3: > ul |= (((ULONG)(*pb++)) << 16); > + break; > case 2: > ul |= (((ULONG)(*pb++)) << 8); > + break; > case 1: > ul |= *pb++; > - default: > break; > } > csum ^= ul; > diff -urN a/dlls/cabinet/fdi.c b/dlls/cabinet/fdi.c > --- a/dlls/cabinet/fdi.c 2006-05-23 13:47:35.000000000 +0100 > +++ b/dlls/cabinet/fdi.c 2006-09-12 23:29:13.000000000 +0100 > @@ -302,9 +302,15 @@ > } > > switch (bytes & 3) { > - case 3: ul |= *data++ << 16; > - case 2: ul |= *data++ << 8; > - case 1: ul |= *data; > + case 3: > + ul |= *data++ << 16; > + break; > + case 2: > + ul |= *data++ << 8; > + break; > + case 1: > + ul |= *data; > + break; > } > csum ^= ul; > I think that's supposed to fall through.

1 0

RTL language support in usp.dll
by Vijay Kiran Kamuju Sept. 13, 2006

Sept. 13, 2006

Hi, Your patch for RTL support in usp10.dll. http://www.winehq.org/pipermail/wine-patches/2006-September/030571.html Only includes support for Arabic. If you could include for other RTL languages esp Hebrew (other RTL languages are Farsi and Urdu). I think that would be an easy task for you as you know the usp internals. ;) bye, VJ

2 1

Find out which handle corresponds to which window
by David Gümbel Sept. 13, 2006

Sept. 13, 2006

Hi, - I'm almost sure that question has been asked here before, but I can't seem to find the corresponding post: I am trying to debug an application (Net Support Manager) that has trouble displaying a window in fullscreen mode. NSM enables you (among other things) to remotely look onto somebody else's Desktop, a bit like VNC or NX. It's quite annoying not to be able to look onto that remote desktop in fullscreen mode. Anyway, my guess is that it tries to put itself on top of everything in a wierd way that does not work properly under wine. In order to verify or falsify my guess, it would be extremely helpful to find out which handle corresponds to the window showing the symtoms. I've tried my luck with Process Explorer, but that tool doesn't show me the information I need. Any help is greatly appreciated. Cheers, David

2 4

Re: resend: tools[1/2]: wineprefixcreate: create a freedesktop-enabled menu directory
by Alexandre Julliard Sept. 13, 2006

Sept. 13, 2006

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > When creating the wineprefix, create a directory for the menu and a > configuration file that enables this menu in the freedesktop.org menu > structure. As suggested on wine-devel the menu directory is a > subdirectory of ~/.wine, so if the user deletes it, all menu items > created there will be automatically removed. > > Is there something wrong with this patch? That sort of desktop-specific code does not belong in wineprefixcreate. I'm not really convinced that this approach to menus is correct, but even if it is, it should be handled by wineshelllink and friends. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: riched20: move some selection code from message handler to ME_SetSelection
by Alexandre Julliard Sept. 13, 2006

Sept. 13, 2006

"Matt Finnicum" <mattfinn(a)gmail.com> writes: > The special cases handled by EM_EXSETSEL should also be handled by > EM_SETSEL, so this patch moves that code into the common > ME_SetSelection function. Before this patch, sending EM_SETSEL with > any value less than -1 would crash richedit. > > Changelog: move some selection code from message handlers to ME_SetSelection This fails make test: ../../../tools/runtest -q -P wine -M riched20.dll -T ../../.. -p riched20_test.exe.so editor.c && touch editor.ok editor.c:1335: Test failed: EM_EXSETSEL: expected: 18 actual: 17 make: *** [editor.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Christoph Frick Sept. 13, 2006

Sept. 13, 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. --- dlls/winex11.drv/settings.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/dlls/winex11.drv/settings.c b/dlls/winex11.drv/settings.c index 5de07eb..c9bced2 100644 --- a/dlls/winex11.drv/settings.c +++ b/dlls/winex11.drv/settings.c @@ -39,7 +39,8 @@ static LPDDHALMODEINFO dd_modes = NULL; static unsigned int dd_mode_count = 0; static unsigned int dd_max_modes = 0; static int dd_mode_default = 0; -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]); /* pointers to functions that actually do the hard stuff */ static int (*pGetCurrentMode)(void); @@ -62,7 +63,7 @@ LPDDHALMODEINFO X11DRV_Settings_SetHandl TRACE("Resolution settings now handled by: %s\n", name); if (reserve_depths) /* leave room for other depths */ - dd_max_modes = (3+1)*(nmodes); + dd_max_modes = nr_depths*nmodes; else dd_max_modes = nmodes; @@ -111,7 +112,7 @@ void X11DRV_Settings_AddDepthModes(void) int existing_modes = dd_mode_count; DWORD dwBpp = screen_depth; if (dwBpp == 24) dwBpp = 32; - for (j=0; j<3; j++) + for (j=0; j<nr_depths; j++) { if (depths[j] != dwBpp) { @@ -164,8 +165,6 @@ void X11DRV_Settings_Init(void) */ BOOL X11DRV_EnumDisplaySettingsEx( LPCWSTR name, DWORD n, LPDEVMODEW devmode, DWORD flags) { - DWORD dwBpp = screen_depth; - if (dwBpp == 24) dwBpp = 32; devmode->dmDisplayFlags = 0; devmode->dmDisplayFrequency = 0; devmode->dmSize = sizeof(DEVMODEW); -- 1.4.2

1 0

question about storage32.c code and while loop
by EA Durbin Sept. 13, 2006

Sept. 13, 2006

I've mentioned this before but I'm no expert C programmer. Can someone explain why we do the following in storage32.c? if (cbRead > 0) { cbTotalRead += cbRead; resWrite = BlockChainStream_WriteAt(bbTempChain, offset, cbRead, buffer, &cbWritten); if (FAILED(resWrite)) break; cbTotalWritten += cbWritten; offset.u.LowPart += This->smallBlockSize; } } while (cbRead > 0); HeapFree(GetProcessHeap(),0,buffer); if (FAILED(resRead) || FAILED(resWrite)) { ERR("conversion failed: resRead = 0x%08lx, resWrite = 0x%08lx\n", resRead, resWrite); BlockChainStream_Destroy(bbTempChain); return NULL; } in the while loop above while (cbRead > 0); it appears it terminates without doing anything due to the semicolon, is this intentional or is this semicolon not supposed to be there and its supposed to execute the line below it? If it is intentional why is the empty while loop here?

1 1

wine complation fails with latest git
by EA Durbin Sept. 13, 2006

Sept. 13, 2006

I'm not able to compile wine with the latest source from git. gcc-3.4 -c -I. -I. -I../../include -I../../include -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o parser.yy.o parser.yy.c parser.l: In function `parser_lex': parser.l:129: error: `parser_lval' undeclared (first use in this function) parser.l:129: error: (Each undeclared identifier is reported only once parser.l:129: error: for each function it appears in.) parser.l: In function `kw_token': parser.l:342: error: `parser_lval' undeclared (first use in this function) make[2]: *** [parser.yy.o] Error 1 make[2]: Leaving directory `/home/eric/wine/tools/widl' make[1]: *** [widl] Error 2 make[1]: Leaving directory `/home/eric/wine/tools' make: *** [tools] Error 2

2 2

Help with git
by Kapila De Silva Sept. 13, 2006

Sept. 13, 2006

Hi all, Hope this is the right place to post this, if not, my apologies. Im trying to track down an issue that occurred between 0.9.19 and 0.9.20, and am using git bisect to track the issue. In the process of trying to identify the cause of the issue, I would like to be able to get the code up till a certain patch, and then apply patches one by one as well. I have not been able to find out how to do this, despite several web searches and man pages. Can anyone give me any pointers to this please? Thanks in advance Kapila

3 2

State management in D3D
by Ivan Gyurdiev Sept. 12, 2006

Sept. 12, 2006

State management in D3D... is currently kind of a mess. Stefan D. posted a message about this some time ago, but I can't find it right now... - some states are applied immediately (via Set* calls) - some are applied at draw time (like shaders, textures, transforms, ...) - some are recorded into a stateblock structure, and applied when the app says apply(). - the GL code is all over the place, tightly coupled to the d3d code. =============================== There's a number of projects going on at the moment, from what I understand: - Roderick is working on making wined3d -> wgl - Stefan D. has expressed concern about multithreaded d3d (where the D3D device state is shared, but not necessarily the GL one - or can GL contexts be shared between multiple threads?) - I'm trying to get FBOs to work, where the FBO needs to be bound once both the render and stencil target have been assigned (that's 2 calls from the app in any order) - i.e I need those states to be applied in a delayed fashion, before draw - Henri Verbeet wants multiple render target support added to that (meaning the FBO needs to be bound once *all* render targets are assigned in addition to the depth/stencil one). ================================ All of the above have a common theme - better state management is needed, with more encapsulation, and better separation between D3D and GL. So, let's come up with a plan, and try to implement it. How about we redesign the stateblock object like this: - remove deltas. I.E. if a SetLightEnable() command is sent, fetch the light, enable it, then save the light back - store only state, and no deltas. This should make the recording stateblock (updateStateBlock) the same as the initial device stateblock, which stores states - provide a uniform internal interface for accessing states inside the stateblock - like: SetState(stateblock, ID_XYZ, (void*) state_data); GetState(stateblock, ID_XYZ, (void**) state_data); CaptureState(stateblock, ID_XYZ); ApplyState(stateblock, ID_XYZ); ID_XYZ could be an individual state, or a "trigger" keyword, which will refer to a whole group of states. Those would be private functions in addition to the standard interface. - provide a fn pointer table inside the stateblock [ which can be directed to OGL or WGL or AGL ], which, for each ID_XYZ, maps a get and set function using the same interface - move all device.c GL code into those functions - now all device.c Get* and Set* requests will do is: - error checking - recording into updateStateBlock - or writing to stateBlock (which may be applied later, at our discretion). - apply() would just loop through all the IDs and call the corresponding function pointer if the states are marked dirty (we'll keep the 'dirty' field) - capture() would do the same in the get* direction. - new object can be instantiated per device, or per device per thread to address multithreading. It could have an associated glContext, and can be locked as necessary. - it would use ideas from the d3d9 test framework for stateblock, except of course more competently written, and cleaner :)

3 12

Help with shader code
by Kapila De Silva Sept. 12, 2006

Sept. 12, 2006

Hi All, can someone help me understand some code from dlls/wined3d/vertexshader.c please? Im new to shader code, but to me the following looks a bit strange: shader_addline(&buffer, "ADD result.position.x, TMP_OUT.x, PROJECTIONX.w;\n"); shader_addline(&buffer, "ADD result.position.y, TMP_OUT.y, PROJECTIONY.w;\n"); /* Account for any inverted textures (render to texture case) by reversing the y coordinate * (this is handled in drawPrim() when it sets the MODELVIEW and PROJECTION matrices) */ shader_addline(&buffer, "MUL result.position.y, TMP_OUT.y, PROJECTIONY.y;\n"); Am I correct that the last line makes the second line redundant? Wont result.position.y be equal to TMP_OUT.y * PROJECTIONY.y no matter what? Thanks in advance. Kapila.

2 2

Re: comctl32: Remove dead code in tooltips.c (coverity)
by Alexandre Julliard Sept. 12, 2006

Sept. 12, 2006

Detlef Riekenberg <wine.dev(a)web.de> writes: > We return with FALSE at the top of the Function, > when lpToolInfo is NULL. I think that's where the real bug is, we shouldn't always return FALSE in that case. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: X11Drv: move WGL extension code
by Lionel Ulmer Sept. 12, 2006

Sept. 12, 2006

On Fri, Sep 01, 2006 at 01:57:24PM +0200, Roderick Colenbrander wrote: > The way WGL extensions are loaded is different. The old code correctly > advertised the names of available WGL extensions but the wglGetProcAddress > code didn't work correctly. Even if an extension wasn't advertised you could > get a function pointer to the functions. On Windows wglGetProcAddress would > return NULL. Note that (as far as I know), 'wglGetProcAddress' returns NULL on non-existant extensions for all extensions, whether they are GL or WGL ones. This means that our implementation of it is broken (at least on DRI / Mesa) as 'glXGetProcAddress' may return a non-NULL value when querying a non-supported extension. So if we really want to be windows-like, we would need to add a 'function name / extension name' database and check if the extension corresponding to the function is present before actually calling 'glXGetProcAddress'. But as I ever only once got a bug report linked to that, I never took the pain to fix it :-) Lionel (catching up his old mails) PS: I guess that this 'database' may be automatically build by the 'make_opengl' script though so it should not be that hard to do :-) -- Lionel Ulmer - http://www.bbrox.org/

1 0

Storage32 error
by EA Durbin Sept. 12, 2006

Sept. 12, 2006

I've been experiencing an error in several installers and it just appeared lately in installers that used to succeed, such as the battlefield 2 demo installer, this error is causing them to fail. Was this caused by a recent patch? err:storage:Storage32Impl_SmallBlocksToBigBlocks conversion failed: resRead = 0x8003001e, resWrite = 0x00000000 err:storage:Storage32Impl_SmallBlocksToBigBlocks conversion failed: resRead = 0x8003001e, resWrite = 0x00000000 err:storage:Storage32Impl_SmallBlocksToBigBlocks conversion failed: resRead = 0x8003001e, resWrite = 0x00000000

1 0

Re: include: Add new Vista SDK constants, fields and, structures documented at http://ian.joeuser.com/index.asp?AID=738
by Timo Kunze Sept. 11, 2006

Sept. 11, 2006

Alexandre Julliard <julliard(a)winehq.org> writes: > Francois Gouget <fgouget(a)free.fr> writes: >> > @@ -1707,6 +1732,7 @@ typedef struct tagTOOLINFOA { >> > LPSTR lpszText; >> > LPARAM lParam; >> > void *lpReserved; >> > + HBITMAP hbmp; >> > } TTTOOLINFOA, *LPTOOLINFOA, *PTOOLINFOA, *LPTTTOOLINFOA; > > I don't think our code is going to handle this properly. Before > extending the structures we need to fix places that depend on the size > of the old type. This website is absolutely outdated. Take a look at the current (build 5536) Windows SDK headers and you'll see, that e. g. the hbmp member of the TTTOOLINFO struct has been removed again. Regards Timo

1 0

Wineconf this weekend!
by Jeremy White Sept. 11, 2006

Sept. 11, 2006

Hi Folks, So this weekend is Wineconf, which is the mostly annual gathering of Wine developers and afficianodos. Everyone is welcome, although we do intend to run a very technical and developer focused agenda. It will be held in Reading, a bit west of London, in the UK. The formal program starts on Saturday. We have a tentative agenda posted on the Wiki here: http://wiki.winehq.org/WineConf2006 The one don't miss talk will be Alexandre's keynote, which will be at 9:00 am on Saturday. We're still working out the schedule for the other events. There is no charge, although you do have to take care of your own loding and travel. If you are planning to come, though, it would be handy if you could hit the RSVP page (if you haven't already): http://www.winehq.org/site/wineconf/rsvp That way we can make sure our catering counts aren't out of wack. If you are coming, particularly if you reserved a room on campus with me, you *must* sign up for this mailing list: http://www.winehq.org/mailman/listinfo/wineconf or you will miss out on important details, and you'll end up wandering around Reading desperately looking for your key. (And yes, that does mean I'll stop spamming this list, and start spamming that one :-/). Cheers, Jeremy

1 0

Re: dinput: [2/2] Create/destroy hook thread from DirectInput [try 3].
by Alexandre Julliard Sept. 11, 2006

Sept. 11, 2006

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > +static void release_hook_thread(void) > +{ > + LONG ref; > + > + EnterCriticalSection(&dinput_hook_crit); > + ref = --hook_thread_refcount; > + TRACE("Releasing to %ld\n", ref); > + if (ref == 0) SendMessageW(hook_thread_hwnd, WM_DESTROY, 0, 0); WM_DESTROY is supposed to be sent by DestroyWindow, sending it manually is not very nice, you should use a WM_USER message instead. Also you need to clear hook_thread_hwnd first, otherwise there's a race since you don't wait for the thread to finish. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Bug #4510: allowing -ansi for arpa/nameser.h in configure.ac
by Alexandre Julliard Sept. 11, 2006

Sept. 11, 2006

Joel Parker <jjk3(a)msstate.edu> writes: > This patch fixes bug #4510. It allows the use of -ansi when > running ./configure. I'm not sure I see the point, you'd need to fix all the places that use the file too, otherwise it won't compile, and it's not clear that defining BSD_SOURCE all over the place is a good idea. I'd suggest to fix the header instead. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: WINEDOCS: Update regression testing procedure to use Git
by Saulius Krasuckas Sept. 11, 2006

Sept. 11, 2006

* On Mon, 28 Aug 2006, Mike McCormack wrote: > Update regression testing procedure to use Git Any chances this patch gets into the webserver? :) http://marc.theaimsgroup.com/?l=wine-patches&m=115673906004873&w=2

2 1

Re: X11Drv: move WGL extension code
by Alexandre Julliard Sept. 11, 2006

Sept. 11, 2006

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > The patch adds new WGL extension loading code based on code written > by an old opengl32 -> x11drv patch written by Tomas Carnacky. The > code properly advertises WGL extensions and only returns function > pointers when the extension is really available. It would be nicer to declare the extensions as constant variables instead of building everything at run time. Something like: static const struct wglextension swap_control = { "WGL_EXT_swap_control", { { "wglSwapIntervalEXT", X11DRV_wglSwapIntervalEXT }, { "wglGetSwapIntervalEXT", X11DRV_wglGetSwapIntervalEXT }, } }; static void load_extensions(void) { if (glxRequireExtension("GLX_SGI_swap_control")) register_extension( &swap_control ); ... etc. } Then the extension list can simply store a pointer instead of copying the whole thing once more, and you avoid a lot of nasty macros. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: include: Add new Vista SDK constants, fields and structures documented at http://ian.joeuser.com/index.asp?AID=738
by Alexandre Julliard Sept. 11, 2006

Sept. 11, 2006

Francois Gouget <fgouget(a)free.fr> writes: > @@ -1707,6 +1732,7 @@ typedef struct tagTOOLINFOA { > LPSTR lpszText; > LPARAM lParam; > void *lpReserved; > + HBITMAP hbmp; > } TTTOOLINFOA, *LPTOOLINFOA, *PTOOLINFOA, *LPTTTOOLINFOA; I don't think our code is going to handle this properly. Before extending the structures we need to fix places that depend on the size of the old type. -- Alexandre Julliard julliard(a)winehq.org

1 0

Making people aware about appdb and outdated Wine versions.
by killertux killertux Sept. 10, 2006

Sept. 10, 2006

Hello, I have problem... It's know as dublication of effort. Basicly there are sites that "compeate" with appdb it means HOWTOS, test result and everyting else are distributed in few thousands forums, wikis etc... Solution is that Wine should advertice Wine AppDB so people would actully use it rather than unoffical sites. So I would like to see some AppDB "adverticement" in winecfg. Winecfg about section is one good place to inform wonders of appdb but even better would be popup window when starting winecfg(at lest in first run) that informs about appdb. Normal users obtain copy of Wine trought their package manager and that means they do not know about appdb unless they they read it somewhere. This change must be done in order to kill useless stuff like this: http://forums.gentoo.org/viewtopic-t-496836.html Second: Old version of Wine are still quite used because of package managers just offers "stable" Wine versions over the "unstable" ones so I would like to see another popup or warning in winecfg that informs user that their Wine is getting old... so after specific number of days(from release of Wine version X) counter gives some warnings about old Wine version.

3 2

Re: Jonathan Ernst : winecfg: French translation update.
by Frank Richter Sept. 10, 2006

Sept. 10, 2006

On 10.09.2006 10:28, Alexandre Julliard wrote: > - LTEXT "This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.", > + LTEXT "Cette biblioth�que est un logiciel libre�; vous pouvez la redistribuer et/ou la modifier conform�ment aux dispositions de la Licence Publique G�n�rale GNU, telle que publi�e par la Free Software Foundation�; version 2.1 de la licence, ou encore (� votre choix) toute version ult�rieure." > IDC_STATIC,119,44,124,72 It seems that all (L)GPL translations are marked "unofficial" by the FSF. That's why I though it wouldn't be bad to put in a translated "This library is ..." but keep the original English notice as well for the German translation. -f.r.

2 1

Re: Re: Making people aware about appdb and outdated Wine versions.
by killertux killertux Sept. 10, 2006

Sept. 10, 2006

OK, if not popup then fixme or someting like if there is problems they can go to Wine AppDB to get some compatibility help. >> --SNIP-- >> Second: Old version of Wine are still quite used because of package >> managers just offers "stable" Wine versions over the "unstable" ones so I would like >> to see another popup or warning in winecfg that informs user that their Wine is >> getting old... so after specific number of days(from release of Wine version X) >> counter gives some warnings about old Wine version. > >Having a popup (or anything that requires user interaction) could get >really irritating - there are situations where people would use an >older version of wine on purpose. Like if a large organization uses it >to run one specific app, and has a specific version that works >perfectly, they might not have any reason to update. > >How about a fixme when wine is run, informing them that the version >they are running was released X long ago, and that if they have any >issues they should try a newer version? > >It'd be nice, too, if people then reported bugs with that on the top >of the output - it could save a lot of work chasing down already- fixed >issues. > >--Matt >

3 2