October 2008 - Wine-devel - list.winehq.org

re: [RFC] Fixes to allow developing Windows apps on Wine
by Dan Kegel 24 Oct '08

24 Oct '08

Kai wrote: > [Should we fix bug 11965 so winsock properly requires > WSAStartup() before it agrees to work?] I think so. I would certainly like Wine to be a good Win32 development environment. > we'd have to start tracking WSADATA structures per thread. Please submit a conformance test first demonstrating whether this is tracked per process or per thread. I'm betting it's per-process. Alexandre will probably pipe up then. - Dan

1 0

Re: [2/2] A nicer icon for "folder" in shell32
by Juan Lang 24 Oct '08

24 Oct '08

Hi Herve, sorry that I'm misspelling your name, the proper accent didn't show up on the mailing list archive. I didn't see patch 1/2. Perhaps it just didn't make it through moderation? --- a/dlls/shell32/Makefile.in +++ b/dlls/shell32/Makefile.in @@ -64,6 +64,7 @@ SPEC_SRCS16 = shell.spec EXTRA_OBJS = authors.o SVG_SRCS = folder_open.svg +SVG_SRCS = folder.svg This can't work, the second assignment of SVG_SRCS overwrites the first. You need something like: SVG_SRCS = \ folder_open.svg \ folder.svg instead. > It's a nicer icon for "folder" in shell32. Comments on this work are welcome (even if you dislike it) ! Any reason the icon is slightly right of center? Does Wine support the alpha channel in icons? --Juan

1 0

Re: ole32: implement IEnumFORMATETC_Next_Proxy (1/2) try 2
by Huw Davies 24 Oct '08

24 Oct '08

On Fri, Oct 24, 2008 at 04:45:46AM -0500, Austin English wrote: > diff --git a/dlls/ole32/usrmarshal.c b/dlls/ole32/usrmarshal.c > index b8487c3..dba69ca 100644 > --- a/dlls/ole32/usrmarshal.c > +++ b/dlls/ole32/usrmarshal.c > @@ -2398,8 +2398,11 @@ HRESULT CALLBACK IEnumFORMATETC_Next_Proxy( > FORMATETC *rgelt, > ULONG *pceltFetched) > { > - FIXME(":stub\n"); > - return E_NOTIMPL; > + ULONG fetched; > + if (!pceltFetched) > + pceltFetched = &fetched; > + return IEnumFORMATETC_RemoteNext_Proxy(This, > + celt, rgelt, pceltFetched); That's still not right. It gives the impression that the 'return' is part of the 'if' block. The 'return' line should be indented by four spaces not eight. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: ole32: implement IEnumFORMATETC_Next_Stub (2/2)
by Rob Shearman 24 Oct '08

24 Oct '08

2008/10/23 Austin English <austinenglish(a)gmail.com>: > - FIXME(":stub\n"); > - return E_NOTIMPL; > + > + HRESULT hr; > + *pceltFetched = 0; > + hr = IEnumFORMATETC_Next(This, > + celt, > + rgelt, > + pceltFetched); > + if (hr == S_OK) *pceltFetched = celt; > + return hr; This file uses 4-space indentation. -- Rob Shearman

1 1

Re: ole32: implement IEnumFORMATETC_Next_Proxy (1/2)
by Huw Davies 24 Oct '08

24 Oct '08

On Thu, Oct 23, 2008 at 01:35:55PM -0500, Austin English wrote: > diff --git a/dlls/ole32/usrmarshal.c b/dlls/ole32/usrmarshal.c > index b8487c3..be9ebff 100644 > --- a/dlls/ole32/usrmarshal.c > +++ b/dlls/ole32/usrmarshal.c > @@ -2398,8 +2398,13 @@ HRESULT CALLBACK IEnumFORMATETC_Next_Proxy( > FORMATETC *rgelt, > ULONG *pceltFetched) > { > - FIXME(":stub\n"); > - return E_NOTIMPL; > + ULONG fetched; > + if (!pceltFetched) > + pceltFetched = &fetched; > + return IEnumFORMATETC_RemoteNext_Proxy(This, > + celt, > + rgelt, > + pceltFetched); There's some strange indentation going on here. Could you make it all 4-space based? Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

2 1

Re: gdi32: Add EMR_GDICOMMENT to the list of records producing output.
by Huw Davies 24 Oct '08

24 Oct '08

On Thu, Oct 23, 2008 at 09:32:43PM +0900, Dmitry Timoshkov wrote: > This completely fixes the print previews generated by MS Access in a Win9x > mode. Access has a custom handler for an EMR_GDICOMMENT record, and GDI APIs > it calls from it don't work properly due to wrong DC mapping. > --- > dlls/gdi32/enhmetafile.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdi32/enhmetafile.c b/dlls/gdi32/enhmetafile.c > index e998c60..22451d2 100644 > --- a/dlls/gdi32/enhmetafile.c > +++ b/dlls/gdi32/enhmetafile.c > @@ -692,6 +692,7 @@ static BOOL emr_produces_output(int type) > case EMR_LINETO: > case EMR_ARCTO: > case EMR_POLYDRAW: > + case EMR_GDICOMMENT: > case EMR_FILLRGN: > case EMR_FRAMERGN: > case EMR_INVERTRGN: Maybe it's time to rename this function to something like emr_updates_transform() since EMR_GDICOMMENT clearly doesn't produce any output. Huw. -- Huw Davies huw(a)codeweavers.com

2 2

Experience with msvcmaker and building wine core and test dlls with VC9
by Reece Dunn 24 Oct '08

24 Oct '08

Hi, I have been using msvcmaker to generate project files to build the various wine test programs with VC9 and have since started to look at getting code dlls to work. I have successfully built cabinet.dll locally on VC9, doing the following: 1. add the following to dlls/cabinet/Makefile.in: EXTRADEFS = -DCOM_NO_WINDOWS_H this is needed to prevent the __WINESRC__ including windows.h error (but not in all cases). 2. run tools/winapi/msvcmaker to generate the dsw/dsp project files. 3. import those files into VC9 and let VC9 convert them. 4. change interlocked_xchg_add to InterlockedExchangeAdd in libs/wine/debug.c. 5. in the include project, set the option not to compile mlang.idl, amvideo.idl and activdbg.idl - these still have problems building with the VC9 midl tool. 6. in the include project, set it to be a Utility project; this is because as a library the dependent projects try to pull in include.lib which does not exist. 7. build the cabinet project and its dependencies. Some projects (e.g. comctl32, shell32 and shlwapi) produce a ^\.lib dependency, which prevents them being loaded by the VC9 IDE when opening the converted solution files. The test projects don't seem to be handling rc (needed by the user32 tests, for example) and idl (needed by the oleaut32 tests, for example) targets correctly, but the projects for the wine dlls generate these correctly. - Reece

1 0

[RFC] Fixes to allow developing Windows apps on Wine
by Kai Blin 23 Oct '08

23 Oct '08

Hi folks, Austin just checked if bug #11965 [1] was still alive. I know it's still an issue, and I wonder if we would want to fix this sort of thing. Ok, actually the question is if Alexandre wants to have it fixed, I'd be happy to provide a patch. In short, the issue is that for people developing and testing Windows software in Wine, Wine will gladly do networking without anybody calling WSAStartup(), so this won't show up in tests. If you forget the WSAStartup call, the app will break on Windows. In order to fix this, we'd have to start tracking WSADATA structures per thread. Comments? 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.

1 0

Winelib and static-build
by Alan Nisota 23 Oct '08

23 Oct '08

I have a project (http://code.google.com/p/coreavc-for-linux) which is a linux executable which provides access to Windows DirectShow filters (despite its name, the program should work with many Directshow Video codecs). Currently, it builds against a forked version of mplayer's 'loader' library, but there are stability problems with this solution (the 'loader' library many hacks to provide just enough infrastructure to the codec, and debugging issues is difficult due to the binary nature of the filter) I found that building against winelib works quite well (once I found that I needed to define __MINGW__) and the stability is much better (in fact the program seems rock-solid now). The problem is that I normally provide a static binary so that users on x86-64 can install it easily without needing a 32bit build environment and without me needing to provide packages for every distribution. The host app (Mythtv, mplayer, xine), can still be 64bit, since I use shared-memory and semaphores to communicate, and this works fine between 32bit and 64bit apps. It seems that wine is available for most 32 and 64bit distros (built in a 32bit chroot in the x86-64 case). My question is, is it possible to do a static-compile of my winelib app that will run properly on multiple distros and interface with wine correctly? I'd be building against a fixed version of wine, (say 1.1.6 or 1.0, or whatever) but would want compatibility with whatever version the user's distro happens to provide (within reason). Is this possible? Sorry if this doesn't exactly belong on the dev list, it didn't seem to fit the user list either, and I couldn't find a better place.

1 0

Re: Wine & MS protocol help?
by Andrew Bartlett 23 Oct '08

23 Oct '08

On Thu, 2008-10-23 at 11:25 -0600, Brian Vincent wrote: > I thought someone might have posted this by now. Andrew Bartlet wrote > this: > > http://people.samba.org/people/abartlet/a-year-since-microsofts-appeal-fail… > > quote: > > "Microsoft has also answered dozens of documentation queries on the > cifs-protocol mailing list and in private email from PFIF members (the > PFIF is the umbrella organization that signed the WSPP agreement on > behalf of the Samba Team)." > > "However, the WSPP program and Microsoft's new protocol documentation > is not just about 'Samba' things - the protocols covered are any that > a windows client uses to talk to a windows server. Many other Free > Software projects can and should take advantage of the new > documentation and clarification process." > > "In might be reasonable to ask why Microsoft is putting such a strong > effort into making the WSPP agreement a success. Obviously the ongoing > EU legal appeal regarding the fines levied against Microsoft by the EU > could be a motivating factor, but regardless of that motivation the > individual engineers we are working with are responding with > enthusiasm." > > Reading on, it seems Samba got access to internal MS conformance tests > among other things. It seems like it's probably worth a few emails > the Andrew for details and a few calls to Microsoft to see if there's > anything that might help out with things besides CIFS. The trick is to find protocols in this list: http://msdn.microsoft.com/en-us/library/cc197979.aspx The other protocols you can access the 'community support' for (as Kai Blin has found out on the forums), but you can't do the e-mail or phone based stuff. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.

1 0