December 2005 - Wine-Devel - list.winehq.org

Re: Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to

by Eric Pouech

I do think all the recent changes to winecfg are going into the wrong direction. First of all, allowing the devices to be opened more than once without having the devices ready for that is a ready bad idea. Basically, windows drivers come in two flavors: - single instance (they can be loaded only once in memory) - multiple instance (they can be loaded several times in memory) For the second type, a specific init string (gotten from the registry, and usually dealing with the HZ resources involved) is passed to the driver. In the wine implementation, we don't get anything from the registry, we just let the device (from the unix interface it uses) return as many audio/midi... ports it finds. This is typically the behavior expected from single instance drivers. Among the issues we'll face here are dual open of the same unix resource (contention) for several instances, overwriting of internal data and structures (they are not prepared for that). Therefore, the multiple open patch has to be reverted. Secondly, I do think it's a bad idea to reconstruct in winecfg most the driver management. It's not done correctly (the DRV_INIT, DRV_ENABLE and DRV_LOAD messages are not correctly passed). If it works today, it's by chance as the configure message is never handled (we just put out a message box), but it doesn't access the internal structures. To do it, we need the DRV_ messages sent. Finally, I'm not sure that presenting all the drivers, and the ports available is really meaningful for most users. Some drivers return just potential entries (esound for example). Even with the caps, most users won't tell the difference between alsa and oss entries. Lately, the available drivers button is not really useful. We shouldn't present non available drivers to the users, and just let him/her choose among the available ones (or just to mark the ones which are not available). -- Eric Pouech

Dec. 7, 2005

Re: tests for LoadLibraryA [resend, 2nd]

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > Hello, > > this tests exhibit a problem of Wiso Sparbuch 2006 (german tax program). The > tests are verified against Win2k > > ChangeLog > --------------- > test loading an executable with LoadLibraryA It doesn't really test that; and actually loading an executable works fine. winhlp32 is a special case because it's a symlink to a different executable, and that doesn't quite work. I don't think it warrants a regression test, because it's not really supposed to work that way. What we need is to provide a real winhlp32.exe. -- Alexandre Julliard julliard(a)winehq.org

Dec. 7, 2005

Re: RpcServerListen and RpcMgmtWaitServerListen

by Robert Shearman

Phil Lodwick wrote: >Hi, > >I have a program that basically does: > > RpcServerUseProtseqEp > RpcServerRegisterIf > RpcServerListen(DontWait=FALSE) > >On Windows this will block until another thread calls >RpcMgmtStopServerListening. > >This does not appear to be the case with Wine's implementation. Before I >start to dig in and investigate, I was wondering if this is already a >well-known problem. > > This was a known problem to me, but not one I was intending to fix any time soon. The bug is in RpcMgmtWaitServerListen. It should wait on some synchronisation object, which RpcMgmtStopServerListening should signal. -- Rob Shearman

Dec. 7, 2005

Re: Shell32 File Property Dialog

by Mike McCormack

Johannes Anderwald wrote: > @@ -1185,6 +1185,7 @@ BOOL SHELL_execute( LPSHELLEXECUTEINFOW > static const WCHAR wFile[] = {'f','i','l','e',0}; > static const WCHAR wHttp[] = {'h','t','t','p',':','/','/',0}; > static const WCHAR wExplorer[] = {'e','x','p','l','o','r','e','r','.','e','x','e',0}; > + static const WCHAR wProperties[] = {'p','r','o','p','e','r','t','i','e','s',0}; > static const DWORD unsupportedFlags = > SEE_MASK_INVOKEIDLIST | SEE_MASK_ICON | SEE_MASK_HOTKEY | > SEE_MASK_CONNECTNETDRV | SEE_MASK_FLAG_DDEWAIT | SEE_MASK_FLAG_NO_UI | > @@ -1275,7 +1276,11 @@ BOOL SHELL_execute( LPSHELLEXECUTEINFOW > sei->hInstApp = (HINSTANCE) 33; > return TRUE; > } > - > + if (sei_tmp.lpVerb) > + { > + if (!strcmpW(sei_tmp.lpVerb,wProperties)) > + return SH_ShowPropertiesDialog(sei_tmp.lpFile); > + } I should have pointed out earlier that this is not the right way to activate a properties dialog. This will show the same properties dialog for all shell objects, which is wrong. You should create a handler for the properties verb in the IContextMenu interface of the shell object that you're showing the dialog for. You need to modify both ->QueryContextMenu and ->InvokeCommand. I have implement IContextMenu for the ShellLink object (shelllink.c). Perhaps try extending that code to make a properties dialog for the ShellLink object first. The rest looks better though. Mike

Dec. 7, 2005

Re: Fix dll_count in mis.c

by Mike McCormack

Christian Gmeiner wrote: > I think that we need to init dll_count with 0 to get DllCanUnloadNow > working correctly. > -static LONG dll_count; > +static LONG dll_count = 0; Static variables should be initialized to zero by default. Mike

Dec. 7, 2005

RpcServerListen and RpcMgmtWaitServerListen

by Phil Lodwick

Hi, I have a program that basically does: RpcServerUseProtseqEp RpcServerRegisterIf RpcServerListen(DontWait=FALSE) On Windows this will block until another thread calls RpcMgmtStopServerListening. This does not appear to be the case with Wine's implementation. Before I start to dig in and investigate, I was wondering if this is already a well-known problem. Thanks, Phil

Dec. 7, 2005

Re: resend: [d3d] rearrange switch statement to have FIXMEs for unhalded query types - d3d guru help requested

by Christoph Frick

On Wed, Dec 07, 2005 at 01:10:49PM +0100, Alexandre Julliard wrote: > > the fixme in the current CVS version is not executed for the unhandled > > defines (hence the break before default:) > There's another FIXME just after the switch that's executed in all > cases. yeah right - i just checked against my cvs-tree and saw, that this is still open. the problem here (and some d3d guru might jump in here) is that i think, that the comment about the lieing and the last fixme is misleading/wrong? first of all we no longer lie (only occlusion-query is handled the rest not). second this is no stub - it works like advertised (ppQuery==NULL is for checking only). following now a patch that hopefully fixes the whole thing and give reasonable messages for user/developer. -- cu Index: dlls/wined3d/device.c =================================================================== RCS file: /home/wine/wine/dlls/wined3d/device.c,v retrieving revision 1.103 diff -u -r1.103 device.c --- dlls/wined3d/device.c 3 Dec 2005 18:34:46 -0000 1.103 +++ dlls/wined3d/device.c 7 Dec 2005 12:48:23 -0000 @@ -1094,8 +1094,14 @@ if (NULL == ppQuery) { /* Just a check to see if we support this type of query */ HRESULT hr = D3DERR_NOTAVAILABLE; - /* Lie and say everything is good (we can return ok fake data from a stub) */ switch(Type) { + case WINED3DQUERYTYPE_OCCLUSION: + TRACE("(%p) occlusion query\n", This); + if (GL_SUPPORT(ARB_OCCLUSION_QUERY) || GL_SUPPORT(NV_OCCLUSION_QUERY)) + hr = D3D_OK; + else + WARN("Unsupported in local OpenGL implementation: ARB_OCCLUSION_QUERY/NV_OCCLUSION_QUERY\n"); + break; case WINED3DQUERYTYPE_VCACHE: case WINED3DQUERYTYPE_RESOURCEMANAGER: case WINED3DQUERYTYPE_VERTEXSTATS: @@ -1109,16 +1115,11 @@ case WINED3DQUERYTYPE_PIXELTIMINGS: case WINED3DQUERYTYPE_BANDWIDTHTIMINGS: case WINED3DQUERYTYPE_CACHEUTILIZATION: - break; - case WINED3DQUERYTYPE_OCCLUSION: - TRACE("(%p) occlusion query\n", This); - if (GL_SUPPORT(ARB_OCCLUSION_QUERY) || GL_SUPPORT(NV_OCCLUSION_QUERY)) - hr = D3D_OK; - break; + FIXME("(%p) Unsupported query type %d\n", This, Type); + break; default: - FIXME("(%p) Unhandled query type %d\n",This , Type); + FIXME("(%p) Unhandled query type %d\n", This, Type); } - FIXME("(%p) : Stub request for query type %d returned %ld\n", This, Type, hr); return hr; }

Dec. 7, 2005

josystick driver layer and support of multiple devices of one kind

by Christoph Frick

hiho i did recently some patches to mostly make joystick_linuxdinput.c handle things more like joystick_linux.c. the main thing, that i dont like on this work, is the fact, that i am just copy-and-paste code from one end to another. i assume someone started back then the joystick_linuxdinput part and if there where changes at either one of them they where not done (or not all the time) also in the other file. also if i have understood this correctly there is no support for multiple joysticks of one kind at least in the joystick_linuxdinput part (i can not confirm this, because i had for now a js-joystick and a event-wheel - but a event-joystick is on the way). for many game-types it is much likely, that the users want to use more than one input-device (e.g. use the wheel and the pedals from two different manufactures, use the pedals from your wheel with your flight stick, use two gamepads, ...) and its most likely that such a device is nowadays a usb device poping up in /dev/input. if the current implementation works fine with more than one js/event-driven joystick - so let me know; my windows/dinput knowledge ist zero and i have not the hardware to test it yet. so my point: i want to make the joystick_... interface to be more abstract. so to bring the code, that is common for the js and event into one common part and then utilize implementations of a interface for each js and event based joysticks. with this step it would make sense to also allow the "driver" (i call it that way now) to report the joysticks that are available and so have support for multiple joysticks. a split like this would also allow an easier integration of e.g. joystick support for OSX or other opteration systems that handle joysticks in another way then unix/linux does. so my questions: - i this an approach, that would be acceptablefor wine? so if i start on something like this, is there a chance it would be submitted to the tree - or is there a problem in terms of "wine does not work like this and we would ignore such an approach" - is the sound-system of wine with its lots of implementations a place to get ideas for such a change; or is this totally off, because the user only chooses one driver to use (instead of: only build the driver if appropriate and then let each driver search for hardware) -- cu

Dec. 7, 2005

winecfg: add options to switch between "installed" directx versions

by Christian Gmeiner

Hi all. I wanted to install "Need for Speed - Most wanted" under wine and the setup told me, that directx is not installed. So i think we need a way to set installed/used directx version in winecfg. Do you think its worth to start developing a patch in this direction? Thanks -- Christian Gmeiner - student of computer science http://dxr3plugin.sf.net http://itb04.ath.cx

Dec. 7, 2005

Re: winecfg: add options to switch between "installed" directx versions

by Tom Wickline

On 12/7/05, Christian Gmeiner <christian.gmeiner(a)students.fh-vorarlberg.ac.at> wrote: > Hi all. > > I wanted to install "Need for Speed - Most wanted" under wine and the > setup told me, that directx is not installed. So > i think we need a way to set installed/used directx version in winecfg. > Do you think its worth to start developing a patch in this direction? > > Thanks > > -- > Christian Gmeiner - student of computer science A quick and easy work around is to edit AutoRun/autorun.cfg and remove DirectXVersion=9.0c Tom

Dec. 7, 2005