November 2008 - Wine-Devel - list.winehq.org

Re: (try 5) comdlg32/tests: Windows XP+ cannot do a CreateViewWindow2 twice in rapid seccesion. handle this error.

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -182,19 +182,26 @@ static UINT CALLBACK create_view_window2_hook(HWND dlg, UINT msg, WPARAM wParam, > > hr = IShellView2_GetCurrentInfo(shell_view2, &folder_settings); > ok(SUCCEEDED(hr), "GetCurrentInfo returned %#x\n", hr); > - ok(folder_settings.ViewMode == FVM_LIST, "view mode is %d, expected %d\n", folder_settings.ViewMode, FVM_LIST); > + ok(folder_settings.ViewMode == FVM_DETAILS, "view mode is %d, expected %d\n", folder_settings.ViewMode, FVM_DETAILS); > > hr = IShellView2_DestroyViewWindow(shell_view2); > ok(SUCCEEDED(hr), "DestroyViewWindow returned %#x\n", hr); > > - view_params.pvid = &VID_Details; > + folder_settings.ViewMode = FVM_LIST; > + folder_settings.fFlags = 0; > + view_params.pvid = NULL; > hr = IShellView2_CreateViewWindow2(shell_view2, &view_params); > - ok(SUCCEEDED(hr), "CreateViewWindow2 returned %#x\n", hr); > + /* > + * Windows XP is unable to recreate the ViewWindow2 returning > + * A Catastrophic failure error > + */ So why can't it recreate it? Do you need to clean up something else beforehand? -- Alexandre Julliard julliard(a)winehq.org

Nov. 4, 2008

Re: user32: handle GetMenuItemCount returning -1 (coverity 229)

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > diff --git a/dlls/user32/mdi.c b/dlls/user32/mdi.c > index fe70b80..1404436 100644 > --- a/dlls/user32/mdi.c > +++ b/dlls/user32/mdi.c > @@ -393,7 +393,8 @@ static LRESULT MDISetMenu( HWND hwnd, HMENU hmenuFrame, > */ > static LRESULT MDI_RefreshMenu(MDICLIENTINFO *ci) > { > - UINT i, count, visible, id; > + UINT i, visible, id; > + INT count; This shouldn't happen since the menu has just been validated. And if you really want to handle that case you have to treat it as an error, not just ignore it. -- Alexandre Julliard julliard(a)winehq.org

Nov. 4, 2008

Re: Wine support for win64

by Roderick Colenbrander

This summer Maarten Lankhorst did some basic work on win64 support but for the rest no work has been done it for a long time. I'm not sure what Maarten exactly did but but there is a lot of work to be done before it will run even a basic app. Roderick > Hi, i'd like to know if anyone knows the current status of wine's support > fro > win64. I've tried to build a git checkout with --enable-win64 configure > switch. It has taken some tinkering to make it build, but after that i'm > not > able to run anything and ti seems that wineboot cannot start. Any > suggestion? > > Alessandro Pignotti > -- > Vi Veri Veniversum Vivus Vici > -Dr. Faustus - Marlowe > Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net > Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 > Encrypted mails are welcome -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Nov. 4, 2008

Re: wininet: let automated testers force all DNS lookups to return localhost

by Kai Blin

On Friday 31 October 2008 16:11:58 Hans Leidekker wrote: > On Friday 31 October 2008 15:52:43 James Mckenzie wrote: > > >What happened to your /etc/hosts proposal? It has the > > >advantage that we don't need changes to Wine source code. > > > > This would not work on Macs as /etc/hosts is locked to admins only and > > would be a problem to implement. > > That's true for Unix in general, but I think we require admin rights > already because the services need to bind ports below 1024 for example. That's where the Samba style socket wrapper would help. The tricky part is that this would have to be implemented in winsock, so it wouldn't necessarily port to windows too well. On the other hand, binding to low ports isn't that big of a problem on windows, and we require administrator privileges for the tests anyway. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Nov. 4, 2008

Wine support for win64

by Alessandro

Hi, i'd like to know if anyone knows the current status of wine's support fro win64. I've tried to build a git checkout with --enable-win64 configure switch. It has taken some tinkering to make it build, but after that i'm not able to run anything and ti seems that wineboot cannot start. Any suggestion? Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome

Nov. 4, 2008

Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes

by Roderick Colenbrander

I made some progress. As I mentioned last time a .msstyles theme is just a resource file wrapped into a dll. Windows tools try to edit real themes or create themes by injecting resource data into a blank dll. In order to obtain a resource file I used a tool called resource hacker to retrieve one from a GPLed clearlooks theme (most windows theme tools only provide binaries or some usefuless xml files). A msstyles file contains various section which contain the msstyles version (PACKTHEM_VERSION), the different color version of the theme (COLORNAMES). The real info is burried inside 'ini files' which are stored inside the 'TEXTFILES' section of the file (the names of the ini files correspond to FILERESNAMES). Each ini file contains a bunch of sections for buttons, textboxes and all other controls. There's also a generic 'SysMetrics' section which contains some classic properties like ActiveCaption and others. The control specific ones are the most important and they contain the dimensions of lets say a button, where to position text, what DPI to use and more. Initially my idea was to create a sample .msstyles project but this looks like a huge task as I would need to fill in every attribute of each control. If I would provide an incomplete theme (which might be legal not sure) the current theming code in Wine will fail as it expects theme info to be around. As everyone is aware of big improvements are needed to the comctl32 theming code and other places which need to draw using themes. For example in case of a button the current drawing code calculates the position for drawing text iself while it should get this info from the theme. The same for other controls. Roderick > For fun I looked a bit at the format. An msstyles file is just a win32 > resource file. It contains various sections each containing strings, colors or > bitmaps. Colors are just stored in a text file. Uxtheme parses this text > file and loads the colors 1:1 from this section into the registry. > > The main issue is creating a resource file it can either be compiled using > wrc or it could an empty file could be created from a program and then > updated using UpdateResource and friends. The first solution is the nicest way > but not everyone might install wrc. > > Anyway desktops will never move to this microsoft format. I think both gtk > and qt are now moving to xml based formats. We could define our own spec > for that but I doubt they will move to this. They attempted before to use > the same theme format but it didn't work out well. > > Roderick > > > On Sun, Nov 2, 2008 at 3:01 PM, Dan Kegel <dank(a)kegel.com> wrote: > > > FWIW, my opinion is that any deep integration > > > is going to be hard, and that for the moment > > > we should go with something much simpler: > > > simply support mstheme files well, and provide > > > themes that look like the default themes on > > > Ubuntu / OpenSuse / Fedora. > > > > I agree. I simply think any outside tools we develop should be used in > > conjunction with a proposed formal standard. If the MS formats are > > open there is no reason we cannot propose the usage of them, or a > > variation on them as part of FreeDesktop making Wine play nicer with > > everyone (mono and moonlight prove MS standards and formats can be of > > use for Linux). I'll spend some of the copious amounts of free-time I > > have at work researching for formats and we can continue the propose > > standard discussion off list later in the week. > > > > -- > > Steven Edwards > > > > "There is one thing stronger than all the armies in the world, and > > that is an idea whose time has come." - Victor Hugo > > > > -- > Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten > Browser-Versionen downloaden: http://www.gmx.net/de/go/browser > -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Nov. 3, 2008

Re: wininet: let automated testers force all DNS lookups to return localhost

by Dan Kegel

On Mon, Nov 3, 2008 at 1:50 PM, Detlef Riekenberg <wine.dev(a)web.de> wrote: >> > This approach won't help users of the Wine conformance >> > tests running on Windows, >> >> Sure it would; just make the test server setup script run on cygwin properly. > > require an installed cygwin is broken by design. > winetest.exe is a standalone application. It wouldn't be required. You'd only need to run the script if you wanted to avoid relying on winehq.org. I prefer servers built into wine's conformance test suite. But if we're going to keep using external servers, we should at least document which ones we use, and how to set them up. >> > We should instead rewrite any existing tests that >> > use a public server to instead use a server started >> > by the Wine test code (see dlls/wininet/tests/http.c:server_thread). > > I prefer to have a winetest.dll for that. > A winetest.dll / winetest.sys allow us to create even more tests. > (Global Hooks and Device Drivers as examples) Go for it... - Dan

Nov. 3, 2008

Re: wininet: let automated testers force all DNS lookups to return localhost

by Detlef Riekenberg

On So, 2008-11-02 at 10:58 -0800, Dan Kegel wrote: > > This approach won't help users of the Wine conformance > > tests running on Windows, > > Sure it would; just make the test server setup script run on cygwin properly. require an installed cygwin is broken by design. winetest.exe is a standalone application. > > We should instead rewrite any existing tests that > > use a public server to instead use a server started > > by the Wine test code (see dlls/wininet/tests/http.c:server_thread). > Yes, absolutely. That will add a lot of code. Add a local_server.c for every dll that need it is another Idea. I prefer to have a winetest.dll for that. A winetest.dll / winetest.sys allow us to create even more tests. (Global Hooks and Device Drivers as examples) -- By by ... Detlef

Nov. 3, 2008

RE: [1/5] d3d9: Use the correct AddRef and Release Macros

by Stefan Dösinger

> > But I think if we have at > > least name-specialized macros for each interface we should use the > one that > > matches the object we have > No. Why not?

Nov. 3, 2008

Re: [1/5] d3d9: Use the correct AddRef and Release Macros

by Henri Verbeet

2008/11/3 Stefan Dösinger <stefan(a)codeweavers.com>: >> I don't think this patch makes sense. > Well, it doesn't do much - IUnknown_AddRef is litterally the same as > IDirect3DDevice9Ex_AddRef(or at least it can be). Yes, which is why I don't think the patch makes sense. > But I think if we have at > least name-specialized macros for each interface we should use the one that > matches the object we have No.

Nov. 3, 2008