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

Re: Stub DDE interface for Progman.exe

by Jeremiah Flerchinger

On Fri, 2009-02-06 at 10:41 +0000, Rob Shearman wrote: > 2009/2/5 Jeremiah Flerchinger <jeremiah.flerchinger(a)gmail.com>: > > On Thu, 2009-02-05 at 18:12 +0000, Rob Shearman wrote: > > Is explorer always running in Wine? I know "wine explorer" does not run > > ShellDDEInit when it starts. I thought most people were against > > additional processes, but I want to see the Progman DDE interface > > working for the different ways of calling it. > > Try running a simple winelib app with WINEDEBUG=+process set and see > for yourself. OK, an explorer process is always running, but it does not run ShellDDEInit when it starts & it probably should. > > ShellDDEInit didn't exist before Win 2000 and was in Shdocw.dll and not > > shell32.dll. Do we want to call ShellDDEInit in shell32 when Wine starts > > (and ends) then? > > I'm not sure if there is a desire to allow native shell32 to be used > in Wine. However, if there is it would be simple to use GetProcAddress > with appropriate checks on the shell32 module that has been loaded. I don't know if there is any desire for a native shell32 either. I think I agree with Dmitry that the built-in explorer should call ShellDDEInit. As it stands, for the built-in explorer, it is never called and the respective DDE interfaces are never registered. > > It is supposed to be called only by the process that is > > acting as the shell when it registers itself as a DDE host for the > > shell. I don't think anything else would ever call it then. > > I can't work out what you mean by this. Perhaps you can rephrase it or > describe in more detail what you mean. ShellDDEInit is supposed to be called by the process that is acting as the shell (progman.exe, explorer.exe, etc) when it starts & begins handling the DDE interface for the shell. The built-in explorer process should call this when it starts, so it starts handling the appropriate calls. It should call ShellDDEInit(1) when it starts and ShellDDEInit(0) when it terminates. I'm not familiar enough with the explorer code currently to know where.

Feb. 6, 2009

Re: New Wine Gecko package

by Austin English

On Fri, Feb 6, 2009 at 1:11 AM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > On Fri, Feb 6, 2009 at 3:48 AM, Dan Kegel <dank(a)kegel.com> wrote: >> James Mckenzie wrote: >>> It depends on the timeline for the 1.2 release. >>> If this is a long way off, it may be worth the effort. >> >> I don't know. The 1.1 branch has are lots of improvements >> people want; what's so special about Gecko? >> IMHO we should leave the 1.0 branch alone, >> and just get on with 1.2. > > I agree. The potential security issues that have been fixed would > (from what I understood) specifically target Wine. Targeting Wine > 1.0.1 would be... pretty restricted. I don't think it's worth > investing time for something like this when 1.2 is coming soon. It doesn't really matter if 1.2 is coming soon or not. 1.0.1 is meant to be stable, and backporting gecko 0.9.1 and it's necessary infrastructure doesn't constitute a 'stable' fix/patchset. -- -Austin

Feb. 6, 2009

[Fwd: WINE: suspected bug in change to winealsa.drv/waveout.c]

by Deomid Ryabkov

Maarten didn't reply, widening to wine-devel@ summary: looks like a bug was introduced into WaveOut queue management back in october that causes sound to skip and stutter. -------- Original Message -------- Subject: WINE: suspected bug in change to winealsa.drv/waveout.c Date: Sun, 25 Jan 2009 03:46:09 +0000 From: Deomid Ryabkov <myself(a)rojer.pp.ru> To: m.b.lankhorst(a)gmail.com hi, Maarten. i'm a complete noob in WINE, this is the first time i delved in the source, so please bear with me if i'm wrong, but i believe i traced a specific problem i've been having with sound in Heroes of Might and Magic III to a change you made couple months ago to the ALSA waveout driver. the regression manifests itself as rather annoying audio skipping and stuttering. having spent some time tracing and looking at the code, i believe that the problem was introduced by this change to dlls/winealsa.drv/waveout.c made on Oct 4: http://source.winehq.org/git/wine.git/?a=commitdiff;h=717df5b2972b3cb998ca5… specifically, this line + wwo->dwPlayedTotal += lpWaveHdr->reserved - wwo->dwPlayedTotal; advances the dwPlayedTotal watermark when i believe it shouldn't. fundamentally, only DSP can report how much has been played, updating this pointer after reporting that a sample has been played makes no sense. DSP has reported that it has played up to a certain point that covers the sample in question, we are reporting this back and removing the sample. we should *not* be changing the value DSP sent us. i don't know what was the specific issue you were addressing with the patch in question, but i'd like you to take one more look at it, because removing this one line fixes skipping and stuttering for me. if you need any more information, please feel free to ask. -- Deomid Ryabkov aka Rojer myself(a)rojer.pp.ru rojer(a)sysadmins.ru ICQ: 8025844 -- Deomid Ryabkov aka Rojer myself(a)rojer.pp.ru rojer(a)sysadmins.ru ICQ: 8025844

Feb. 6, 2009

RE: Stub DDE interface for Progman.exe

by Rolf Kalbermatter

Jeremiah Flerchinger [mailto:jeremiah.flerchinger(a)gmail.com] wrote: > ShellDDEInit didn't exist before Win 2000 and was in > Shdocw.dll and not shell32.dll. Actually it is supported back to at least Win98 in shdocw and most probably even Win95 since that did support the progman interface too. > Do we want to call ShellDDEInit in shell32 when Wine starts (and > ends) then? It is supposed to be called only by the process that > is acting as the shell when it registers itself as a DDE host for > the shell. I don't think anything else would ever call it then. If you want Wine explorer to potentially run on Windows systems too you would probably call the export in shdocw instead which dynamically forwards to shell32 in Wine. Once the shell32 DDE server does actually something useful I think it would be a good idea to initialize it in the first explorer process that gets started. Maybe ShellDDEInit even should protect itself from being called multiple times to start up the server. Rolf Kalbermatter

Feb. 6, 2009

RE: Stub DDE interface for Progman.exe

by Rolf Kalbermatter

Rolf Kalbermatter > -----Original Message----- > From: Jeremiah Flerchinger [mailto:jeremiah.flerchinger(a)gmail.com] > Sent: Thursday, February 05, 2009 7:33 PM > To: Rolf Kalbermatter > Cc: wine-devel(a)winehq.org > Subject: RE: Stub DDE interface for Progman.exe > > On Thu, 2009-02-05 at 18:58 +0100, Rolf Kalbermatter wrote: > > "Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote: > > > > > The shell32.dll DDE callback isn't always initialized & handling > > > Progman calls for all apps. I've seen Progman calls pass > through the > > > DDE_client and DDE_server of user32.dll instead and never > go through > > > shell32.dll. > > > > That would IMHO only be possible if the shell executable, which > > normally is just explorer creating the actual desktop view had been > > replaced by a different executable that does not initialize > the shell > > DDE interface properly. > > > > Rolf Kalbermatter > > > DdeConnect, DDeInitialize, and DDeDisconnect can be called > directly by including Windows.h and importing the calls from > user32 > (http://msdn.microsoft.com/en-us/library/ms648745(VS.85).aspx) . DDE calls can then be made with SendMessage or PostMessage. > > I found a couple apps that appear to do this. Wine does not > automatically start explorer.exe or initialize the shell DDE > interface, nor does it route the DdeConnect routine in > user32.dll to the DdeConnect routine in the shell32.dll. The > DDE interface in shell32 and user32 will need to call the > same set of routines from either method for full > functionality of DDE calls, including those to Progman. Maybe I'm not understanding you here but you seem to mix the actual and generic DDE support in user32 and the progman DDE server support in shell32. All DDE applications (server and clients) have to use the the DDE functions from user32. Shell32 implements a DDE server that supports the progman interface among other things. Explorer or any properly operating shell desktop replacement will call the according shell32 export that initializes that server. If the progman DDE interface is not available under Windows you are not running any proper shell desktop process. Much like in Windows 3.1 days where you could replace the progman.exe with your own executable too but unless it implemented the progman DDE interface too, no progman DDE was available. Now if you want to add support for the progman DDE server to Wine you will have to improve the stubs in shell32/dde.c. The ShellDDEInit() function is already there and the initialization for the "progman", "shell" and "folder" service too, but it is missing the implementation for all the DDE operations on these services. Rolf Kalbermatter

Feb. 6, 2009

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/smbsrv/ndl/

by Luke Kenneth Casson Leighton

holy cow. opensolaris appears to have its own smb server / idl compiler: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/tools/ndrgen/ CDDL licensed, unfortunately (listed as incompatible with GPL. darn). but... dang :)

Feb. 6, 2009

Re: http://wiki.winehq.org/NamedPipes

by Luke Kenneth Casson Leighton

> Funny enough, the Samba project codenamed "franky" > (http://wiki.samba.org/index.php/Franky) will be doing all of this. It's not > quite there yet, but after some nice work done in the Samba3 smbd by Volker > Lendecke and some more work in the Samba4 "samba" daemon by Stefan > Metzmacher, Jelmer Vernooij and some overall effort by other folks from the > Samba Team, franky is coming along quite well. http://wiki.samba.org/index.php/Franky/Notes_20080508 how veery iiinteresting. i see that the justification for adding proper named pipe break-out isn't to do with inter-project cooperation, at all - it's to provide a samba3 - samba4 migration path, utilising components from each. by fortunate coincidence, it so happens that the exact same reasons and near-exact same architecture as required for samba3-samba4 interoperability is exactly what's required for every other project that also wants to use samba as a service not as _the_ be-all-and-end-all service. just make sure you add an SMB SetNamedPipeHandleState function to the list of callbacks / capabilities, not just createpipe, readpipe, writepipe, transactnamedpipe and closepipe. in samba, the _only_ operation you will ever see on-wire, is SetNamedPipeHandleState to 0x3 (PIPE_MESSAGE_READ | PIPE_MESSAGE_WRITE). but other systems will want to use franky-breakout read, franky-breakout write, franky-breakout transactnamedpipe in NON-message-mode. and also make sure that the namedpipestate flag on the initial SMBcreateX is also passed over to the franky-breakout-create-pipe function. oh, and a franky-breakout-get-namedpipe-state too. which probably maps to an SMB IPC$ ioctl somewhere. needs analysis. rob, you'll want to put these on your list of things to keep an eye on: 1) franky-create-pipe receives PIPE_MESSAGE_MODE flags on/off 2) franky-set-namedpipe_handle_state function exists 3) franky-get-namedpipe-handle-state function has to exist somewhere. all of them will be necessary for the "existing" wine apps to work correctly over-the-wire because that's what wine presently only supports: non-message-moded named pipes. l.

Feb. 6, 2009

Re: Fixing AppDB once and for all

by Zachary Goldberg

Alright, this is on for tonight at 6PM EST. If you've any interest or opinion of how the AppDB rating system should be upgraded I encourage you to attend and/or check the wiki afterwards to see what was decided. --Zach

Feb. 6, 2009

Re: [patch] rpcrt4_conn_np_read needs to expect and accept ERROR_MORE_DATA

by Luke Kenneth Casson Leighton

On Fri, Feb 6, 2009 at 12:35 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi Luke, > > @@ -382,7 +382,14 @@ static int rpcrt4_conn_np_read(RpcConnection *Connection, > Style nit: it would be simpler to do: > DWORD bytes_read; > ret = ReadFile(npc->pipe, buf, bytes_left, &bytes_read, NULL); > + if (!ret && GetLastError() == ERROR_MORE_DATA) > + ret = TRUE; > if (!ret || !bytes_read) > break; > > Don't you think? ... oh yeah :) well, i wanted to know what was going on, so i added the TRACE. rob, this is clearly much better. oh - the nice thing that you should find is that given that the current wine NtReadFile() implementation never returns ERROR_MORE_DATA, is that all checks that you add to treat ERROR_MORE_DATA as "not actually an error but actually to be expected" should have _zero_ impact. until NamedPipes messagemode gets fixed, of course. l.

Feb. 6, 2009

Re: Use environment variable WINE_NO_MENU_ENTRIES to prevent menu icon and menu entry creation.

by Christoph Korn

Thank you. I have fixed it and resent the patch to wine-patches. Also I have shortened the environment variable to WINENME. Christoph Korn Detlef Riekenberg schrieb: > On Do, 2009-02-05 at 18:02 +0100, Christoph Korn wrote: >> int PASCAL WinMain (HINSTANCE hInstance, HINSTANCE prev, LPSTR >> cmdline, int show) >> { >> + if(getenv("WINE_NO_MENU_ENTRIES")) >> + { >> + return 0; >> + } >> + >> LPSTR token = NULL, p; > > Declaring a variable after code is C99 and not allowed in Wine. >

Feb. 6, 2009