September 2009 - Wine-Devel

Fixing shell32:shlexec

by Greg Geldorp

Hi Damjan, > From: Damjan Jovanovic > > Can you not change the application type to GUI at runtime using > MSVCRT's __set_app_type() function? Or does that do something > different? No, unfortunately that won't work for two reasons. First, it only affects how MSVCRT displays error messages (message box versus printing to stderr). Second, since it would be a runtime change there would still be a race condition. Thanks, Ge.

Sept. 30, 2009

Re: Modifying Subsystem in Winelib executables

by Damjan Jovanovic

On Tue, Sep 29, 2009 at 3:01 PM, Greg Geldorp <ggeldorp(a)vmware.com> wrote: >> From: Paul Vriens [mailto:paul.vriens.wine(a)gmail.com] >> >> Can't we just compile shell32 tests as a GUI app? > > I don't think that will work, but I'll look into it. Wine tests expect > to have access to stdout. At the very least you won't see output when > running the test manually on Windows. Not sure if it would affect > running from winetest.exe. > >> What other changes are needed to fix the errors on Vista+? (I know that >> we have popups now) > > Yeah, there are basically two problems with shell32:shlexec on Vista+. > First is that there appears to be no way to suppress the popups that you > get when there's no registered handler for a filename extension. I've got > that one more or less under control, by detecting this condition and > compensating for it when it first occurs and skipping similar tests > afterwards. I can submit a patch for that right now if it helps. > > The second problem is when using DDE. My guess is the ShellExecuteEx() code > for that looks something like this (at least, that's how I would write > it :-)): > > try_establish_dde_connection(); > if (no_connection) > { > CreateProcess(); > WaitForInputIdle(); > retry_establish_dde_connection(); > } > > The child app is supposed to do something like this: > > WinMain() > { > setup_dde_server(); > while (GetMessage()) > { > ... > } > } > > The WaitForInputIdle() in the parent should wait for the child to setup its > DDE > server, so when retry_establish_dde_conection() is called the DDE server is > up > and running. Except that this doesn't work for console apps. A console app > can > of course still have a message loop, but WaitForInputIdle() returns > immediately > for console apps. That means if the standard DDE setup is used you'll have a > race condition when the child app is a console app, there's a good chance > the > childs setup_dde_server() won't have finished by the time the parent calls > its > retry_establish_dde_connection() function. For the shlexec test, the child > launched can really only be shell32_test.exe, which hits this problem > because > that is a console app. > > There's a pretty cool hack in shlexec.c to work around this, I wish I would > have thought of it myself :-). The idea is that the parent sets up the DDE > server. That DDE server will decline the first attempt to establish a DDE > connection. That will cause ShellExecuteEx() to launch the child process, a > second copy of shell32_test.exe that will only check for correct parameters > but > will not try to do any DDE related stuff. In the mean time, we still have > the > DDE server in the parent running and when the parent calls > retry_establish_dde_connection() its own DDE server responds and accepts the > connection. The DDE server in the parent then checks the DDE conversation. > Problem solved, except it doesn't work anymore on Vista+... > > At first I thought maybe ShellExecuteEx() will refuse to talk to a DDE > server > in its own process, but now I don't believe that's the problem. I do see the > DDE server being probed for the initial connection which it refuses. It's > just > that no second connect request is received by the DDE server. Spying on > messages sent by the parent makes me think that in > retry_establish_dde_connection() it will only send WM_DDE_INITIATE messages > to > new windows (windows which were not present during the initial > try_establish_dde_connection() call). That kind of makes sense, if a window > didn't want to establish a conversation on a specific app/topic before it > probably doesn't want to have that conversation at all, so there's no use in > asking again. It breaks our hack though. > > I'm still trying to figure out a solution for this. Would be nice if the > child > could simply be a GUI app so WaitForInputIdle() would work as intended, but > I don't see a way to make that happen. Another idea is to hook > WaitForInputIdle > and don't return until the child has set an event, indicating its DDE server > is > up and running. And obviously I'm open to other ideas. > Can you not change the application type to GUI at runtime using MSVCRT's __set_app_type() function? Or does that do something different? > Ge. > > > > Damjan Jovanovic

Sept. 30, 2009

Re: firefox build success on visual c++ 2005 on wine!

by André Hentschel

Dan Kegel schrieb: > On Thu, Sep 24, 2009 at 9:46 PM, Dan Kegel <dank(a)kegel.com> wrote: >> Now that AJ fixed http://bugs.winehq.org/show_bug.cgi?id=19783, >> the firefox build procedure runs all the way through >> to the end (at least in release mode; debug builds still fail). > > And the resulting firefox works in wine, too! I'm using it to > post this message in gmail. > > It does hang on exit, > and it does seem to output these two lines entirely too often: > > fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented > fixme:advapi:SetNamedSecurityInfoW L"C:\\users\\dank\\Application > Data\\Mozilla\\Firefox\\Profiles\\v80k2mcj.default\\sessionstore.js" 1 > 536870916 (nil) (nil) 0x17569c (nil) > > and it renders < as [unicode char 003C], > but other than that it seems fine. Even plays youtube ok. > - Dan > > Woot! Thats really cool. Of course it would be even more cool if it would be a winelib port, but that seems to be impossible atm. Great Effort! -- Best Regards, André Hentschel

Sept. 30, 2009

Re: [2/5] WineD3D: Start replacing dxVersion with create flags

by Stefan Dösinger

Am 30.09.2009 um 16:47 schrieb Henri Verbeet: > 009/9/30 Stefan Dösinger <stefandoesinger(a)gmx.at>: >> Are the patches ok with you in that case? Otherwise I'll just fix >> bug 19365 >> with the old dxVersion hack and implement whatever properly >> designed setup >> you prefer the next time I have a few hours to kill(read: On my 16 >> hour >> flight to the google mentor summit later next month) >> > Just fix 19365 with a dxVersion check I'd say, that bug has been in > its current state long enough. OK that still leaves the question how to get rid of dxVersion in the long run open We could use the global flags as my patches here do. (I attached the full set for reference) Or we could use API specific flags that are placed close to where the difference occurs(ie, a CreateVertexBuffer flag(or a classic usage flag that is filtered by d3d8/9). Easy for 4, 5, 8, 9, but is more tricky for 2, 3 and 6(flag has to be set during object creation) 4 and 9 could be handled in the client lib as well. For patch 9 we'd have to duplicate the stateblock logic in ddraw (or d3d8+d3d9) to make GetViewport work correctly during BeginStateblock() - SetRenderTarget - EndStateblock.

Sept. 30, 2009

Re: [2/5] WineD3D: Start replacing dxVersion with create flags

by Henri Verbeet

009/9/30 Stefan Dösinger <stefandoesinger(a)gmx.at>: > Are the patches ok with you in that case? Otherwise I'll just fix bug 19365 > with the old dxVersion hack and implement whatever properly designed setup > you prefer the next time I have a few hours to kill(read: On my 16 hour > flight to the google mentor summit later next month) > Just fix 19365 with a dxVersion check I'd say, that bug has been in its current state long enough.

Sept. 30, 2009

Re: [2/5] WineD3D: Start replacing dxVersion with create flags

by Stefan Dösinger

Am 30.09.2009 um 16:22 schrieb Henri Verbeet: >> I prefer that all d3d version specific behaviors in wined3d(ie, >> those that >> can't be handled by the client lib alone) are controlled by one >> wined3d >> parameter. I don't feel strongly about this though. I could as well >> make >> them a parameter of CreateVertexBuffer if you prefer this. >> > I think it might make more sense there, although I suppose there's > something to say for keeping the differences centralised as well. Are the patches ok with you in that case? Otherwise I'll just fix bug 19365 with the old dxVersion hack and implement whatever properly designed setup you prefer the next time I have a few hours to kill (read: On my 16 hour flight to the google mentor summit later next month) > Is there any reason you're not sending these mails to wine-devel as > well? Apparently because the "reply" button in Apple Mail doesn't do the same as the "reply" button in kmail. Apparently because there's no "reply to mailing list" either.

Sept. 30, 2009

Re: [1/2] richedit: Added test to show that handle to parent is cached.

by Paul Vriens

On 09/30/2009 03:56 PM, Dylan Smith wrote: > --- > dlls/riched20/tests/editor.c | 26 ++++++++++++++++++++++++++ > 1 files changed, 26 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Dylan, Could you change SetWindowLongPtrW to the A-variant to cope with 9x/Me? -- Cheers, Paul.

Sept. 30, 2009

Re: ws2_32: Ignore EINTR poll result code in WS_select

by Alexandre Julliard

Dmitriy Anisimkov <anisimkov(a)ada-ru.org> writes: > Changelog: > - Ignore EINTR result code from poll call in WS_select. Your timeout computation is still wrong. -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2009

Re: sti [2/2]: add stubs for the IStillImageW interface

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > I'm pretty sure you do need a separate IUnknown interface if the > object aggregates, which it does on Windows (tests will follow). > > IIRC msxml3 does the same in node.c ... I think it's nicer with a single table, but the COM book apparently recommends two, so I guess I'll just have to get used to it... But please make the real one the main lpVtbl, and the inner unknown a secondary one, that makes things easier to follow. -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2009

Re: sti [2/2]: add stubs for the IStillImageW interface

by Damjan Jovanovic

On Wed, Sep 30, 2009 at 2:21 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > >> +static const struct IUnknownVtbl internal_unk_vtbl = >> +{ >> + Internal_QueryInterface, >> + Internal_AddRef, >> + Internal_Release >> +}; >> + >> +static const struct IStillImageWVtbl stillimagew_vtbl = >> +{ >> + stillimagew_QueryInterface, >> + stillimagew_AddRef, >> + stillimagew_Release, >> + stillimagew_Initialize, >> + stillimagew_GetDeviceList, >> + stillimagew_GetDeviceInfo, >> + stillimagew_CreateDevice, >> + stillimagew_GetDeviceValue, >> + stillimagew_SetDeviceValue, >> + stillimagew_GetSTILaunchInformation, >> + stillimagew_RegisterLaunchApplication, >> + stillimagew_UnregisterLaunchApplication, >> + stillimagew_EnableHwNotifications, >> + stillimagew_GetHwNotificationState, >> + stillimagew_RefreshDeviceBus, >> + stillimagew_LaunchApplicationForDevice, >> + stillimagew_SetupDeviceParameters, >> + stillimagew_WriteToErrorLog >> +}; > > You don't really need a separate vtbl for IUnknown. I'm pretty sure you do need a separate IUnknown interface if the object aggregates, which it does on Windows (tests will follow). IIRC msxml3 does the same in node.c ... > -- > Alexandre Julliard > julliard(a)winehq.org > Damjan Jovanovic

Sept. 30, 2009