Re: Concerning the separate OpenAL32.dll thunk patch and OpenAL winmm driver patch
On Mi, 2006-11-29 at 22:00 -0800, Nick Burns wrote: The patches have been split in 2 one for the thunk and one for the winmm driver. Have these patches been rejected? I have not very much knowledge about Audio, but still some comments: When you compare your Patch with the Size of other Patches, you Patches are still very large. A large Patch is much harder (in complexity and needed motivation) to review and take more time. I Suggest, that you should start with Makefile.in, the spec-file and only DllMain as implemented function. Afterwards, pick one or a small set of Functions for a Patch. Limiting the supported Formats/Version in a Patch and add additional Formats / Versions in the next Patches should also reduce the Patch-Size. (ALC_1_0, AL_1_0, AL*_1_1, ALUT, WaveOut, WaveIn or OPENAL_LIMIT_IN_44100 as examples). Some more hints are here: http://wiki.winehq.org/Developers-Hints There is also dead code in the Patch (#if 0) +static int OpenAL_InitRingMessage(ESD_MSG_RING* mr) You copied code without adapting it. Another Issue mitht be, that there are plans to merge all the audio-drivers in a single driver (dlls/wineaudio) to avoid most of the code/bug - duplication: http://wiki.winehq.org/FlattenDllDirectories I don't know, if wineaudio.drv this is still the way to go, but we have sound crackeling and Buffer-underun Bugs, and adding another copy of the not very well working code might be a no go for Alexandre. -- By by ... Detlef
Re: msi: Add handling for the StartServices action
James Hawkins [EMAIL PROTECTED] writes:
+p = args;
+do
+{
+if ((q = strstrW(p, separator))) *q = '\0';
+
+(*numargs)++;
+vector = msi_realloc(vector, *numargs * sizeof(LPWSTR));
+vector[*numargs - 1] = p;
+} while (q);
This won't work for more than one arg.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: How to embed wine into swt?
Cloudor Pu wrote: Hi, all I am developing an swt app only for gtk. I want to embed IE into this app. I can create a SWT.EMBEDDED composite and get its embededHandle (an integer). Then, how to do next? Thanks in advace! There aren't that many GTK experts that work on Wine, so most of us won't be able to tell you what you need to do. I suggest you find a tutorial for how to embed a plain X11 window from another process using GTK and use that as a basis for embedding a Wine window. If you find that Wine needs to do something to its X11 windows that it currently doesn't do, then email the requirements to this list. -- Rob Shearman
Re: How to embed wine into swt?
On 11/30/06, Robert Shearman [EMAIL PROTECTED] wrote: Cloudor Pu wrote: Hi, all I am developing an swt app only for gtk. I want to embed IE into this app. I can create a SWT.EMBEDDED composite and get its embededHandle (an integer). Then, how to do next? Thanks in advace! There aren't that many GTK experts that work on Wine, so most of us won't be able to tell you what you need to do. I suggest you find a tutorial for how to embed a plain X11 window from another process using GTK and use that as a basis for embedding a Wine window. If you find that Wine needs to do something to its X11 windows that it currently doesn't do, then email the requirements to this list. -- Rob Shearman Look at GtkPlug and GtkSocket, they implement the XEmbed protocol for cross-process widget embedding (which is on fd.o). Damjan
Re: make check_no_exec() work reliable
Peter Beutner wrote: Before starting to make this whole noexecute override behaviour configurable, it first must work reliable. In its current form there is no guarantee that the check_no_exec() function is actually called, because any other installed exception handler might decide to handle the exception itself. And as seen by the number of failing applications, this seems to happen quite a lot. This patch therefore makes check_no_exec() to be called before any other exception handler. --- Any comments what is wrong with this one?
Re: make check_no_exec() work reliable
Peter Beutner [EMAIL PROTECTED] writes: Peter Beutner wrote: Before starting to make this whole noexecute override behaviour configurable, it first must work reliable. In its current form there is no guarantee that the check_no_exec() function is actually called, because any other installed exception handler might decide to handle the exception itself. And as seen by the number of failing applications, this seems to happen quite a lot. This patch therefore makes check_no_exec() to be called before any other exception handler. --- Any comments what is wrong with this one? If the exception is not made visible to the app then there is no point in having one at all, we might just as well turn off the protection right away. What really needs to be done is to investigate the Windows behavior and determine which parts of the app memory should be protected and which shouldn't, depending on the exe flags etc. and then replicate that behavior. -- Alexandre Julliard [EMAIL PROTECTED]
Re: make check_no_exec() work reliable
Alexandre Julliard wrote: Peter Beutner [EMAIL PROTECTED] writes: Peter Beutner wrote: Before starting to make this whole noexecute override behaviour configurable, it first must work reliable. In its current form there is no guarantee that the check_no_exec() function is actually called, because any other installed exception handler might decide to handle the exception itself. And as seen by the number of failing applications, this seems to happen quite a lot. This patch therefore makes check_no_exec() to be called before any other exception handler. --- Any comments what is wrong with this one? If the exception is not made visible to the app then there is no point in having one at all, we might just as well turn off the protection right away. Why should this exception be visible to the application? Plus if you make it visible, you can just forget this whole workaround idea, because it won't work reliable anyways. And remembering the last discussion I thought just turning off the protection wasn't your preferred solution either. What really needs to be done is to investigate the Windows behavior and determine which parts of the app memory should be protected and which shouldn't, depending on the exe flags etc. and then replicate that behavior. Certainly some more testing on windows is needed, but this check_no_exec() workaround was regardless introduced a long time ago. This patch just fixes this workaround. Otherwise it could as well be removed at all.
Re: Concerning the separate OpenAL32.dll thunk patch and OpenAL winmm driver patch
Am Donnerstag 30 November 2006 07:00 schrieb Nick Burns: The patches have been split in 2 one for the thunk and one for the winmm driver. Have these patches been rejected? (I still dont know how to tell that -- other than checking wine-cvs) The best thing is to ask AJ directly why he didn't apply the patches. From my personal experiance it is best to ask him on irc pgpM3o9Mb90Vl.pgp Description: PGP signature
Re: make check_no_exec() work reliable
Peter Beutner [EMAIL PROTECTED] writes: Why should this exception be visible to the application? Plus if you make it visible, you can just forget this whole workaround idea, because it won't work reliable anyways. Well, yes, the workaround is really a hack that should be replaced by a proper fix; I was hoping it would encourage someone to look into it and fix it properly, I can't do it because my box doesn't have noexec support. Certainly some more testing on windows is needed, but this check_no_exec() workaround was regardless introduced a long time ago. This patch just fixes this workaround. Otherwise it could as well be removed at all. Well, yes, it could certainly be removed; I added it mostly to make sure that we generated the exception properly, and to demonstrate how the exception can be handled. The proper fix is clearly more complex than that, but moving that hack into the exception code isn't a step in the right direction IMO. -- Alexandre Julliard [EMAIL PROTECTED]
Re: msi: Add handling for the StartServices action [try2]
James Hawkins wrote: +scm = OpenSCManagerW(NULL, NULL, SC_MANAGER_ALL_ACCESS); This can be just SC_MANAGER_CONNECT instead. -- Rob Shearman
Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch
Ok this is some good feedback... (usually i dont get such a massive response from emails...) -- I was under the impression that RFC was the second to last line of defense (so it appears to be the third) I do not use IRC (unless you count the irc client in Tribes) I can demacroize the patch -- it was written that way to make it small and easy to add to (since 99% of the functions are pure passthru -- one extra line to the macro adds it and all that it needs) Personally I think its cleaner -- but it has the problem of being a macro There not much worse than a macro -- except dare I mention templates (the crowd runs for cover) Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice. Yes my wineopenal patch is not perfect (based on broken code does not help) -- I know that -- but thats why i want to get it into wine -- so other people who know more about audio can add to it and make it better If the audio drivers are going to collapse -- I could wait until then and 'try' add my winmm patch in that realm. - Nick From: Alexandre Julliard [EMAIL PROTECTED] To: Detlef Riekenberg [EMAIL PROTECTED] CC: Nick Burns [EMAIL PROTECTED], wine-devel wine-devel@winehq.org Subject: Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch Date: Thu, 30 Nov 2006 19:58:36 +0100 Detlef Riekenberg [EMAIL PROTECTED] writes: I don't know, if wineaudio.drv this is still the way to go, but we have sound crackeling and Buffer-underun Bugs, and adding another copy of the not very well working code might be a no go for Alexandre. Exactly, we already have 8 sound drivers, and not a single one actually works properly, so I'm pretty reluctant to add yet another copy of the same broken code. The openal dll can certainly go in, but you'll need to clean up the code first, right now it looks like a pretty bad case of macro abuse. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Concerning the separate OpenAL32.dll thunk patch and OpenAL winmm driver patch
On Thursday 30 November 2006 10:58, Alexandre Julliard wrote: Detlef Riekenberg [EMAIL PROTECTED] writes: I don't know, if wineaudio.drv this is still the way to go, but we have sound crackeling and Buffer-underun Bugs, and adding another copy of the not very well working code might be a no go for Alexandre. Exactly, we already have 8 sound drivers, and not a single one actually works properly, so I'm pretty reluctant to add yet another copy of the same broken code. I'm curious about how Wine will handle Windows DirectSound drivers. Apparently Creative is working on a dsound-openal wrapper driver, and with the openal dll, it could take a huge load off of Wine in the dsound department for most people if it could work.
Re: How to embed wine into swt?
Damjan Jovanovic wrote: On 11/30/06, Robert Shearman [EMAIL PROTECTED] wrote: There aren't that many GTK experts that work on Wine, so most of us won't be able to tell you what you need to do. I suggest you find a tutorial for how to embed a plain X11 window from another process using GTK and use that as a basis for embedding a Wine window. If you find that Wine needs to do something to its X11 windows that it currently doesn't do, then email the requirements to this list. -- Rob Shearman Look at GtkPlug and GtkSocket, they implement the XEmbed protocol for cross-process widget embedding (which is on fd.o). Damjan If I get GtkPlug and GtkSocket worked, then how to embed a wine window into GtkPlug? I can embed GVIM into my app easily because it accept a socketId argument, i.e. gvim --socketid 6291501 Does wine accept such an argument as GVIM? cloudor
Re: user32: Factorize graphics driver's WindowCreate and ShowWindowin user32.
Pierre d'Herbemont [EMAIL PROTECTED] wrote: My patch is wrong, but I am not sure we should leave ShowWindow in the driver: It contains only Win32 calls (appart from WINPOS_MinMaximize), and is indeed a wrapper for SetWindowPos. And the exports are needed for CreateWindow, not ShowWindow. What makes me move ShowWindow in user is the call to WINPOS_MinMaximize which is shared with CreateWindow, and this one needs the SetIconicState. The problem is that for top level windows we need to route ShowWindow actions to a Window Manager/Host Windowing System, so that actions like minimize/maximize/restore would be properly handled. We don't do this at the moment, but we need to. -- Dmitry.
