October 2007 - Wine-Devel - list.winehq.org

Re: "typos" on some include files

by Marcos Gutiérrez Batz

I'll try to find the correct files to add the stub and then send the patch for that! Dmitry Timoshkov wrote: > "Marcos Gutiérrez Batz" <sacrom(a)gmail.com> wrote: > >> $ diff -up liboleaut32.def /usr/lib/wine/liboleaut32.def >> --- liboleaut32.def 2007-08-23 16:15:48.000000000 +0200 >> +++ /usr/lib/wine/liboleaut32.def 2007-10-15 00:48:35.000000000 >> +0200 >> @@ -366,7 +366,6 @@ EXPORTS >> OleCreatePictureIndirect(a)16 @419 >> OleCreateFontIndirect(a)12 @420 >> OleTranslateColor(a)12 @421 >> - OleLoadPictureFile(a)12 @422 >> OleLoadPicturePath(a)24 @424 >> VarUI4FromI8(a)12 @425 >> VarUI4FromUI8(a)12 @426 > > Also you can't just add an entry to the .def file, it's auto generated. > You have to add a stub to the source file, and change the 'stub' entry > in the .spec file. >

Oct. 24, 2007

Re: "typos" on some include files

by Marcos Gutiérrez Batz

I hope it to be OK now! Dmitry Timoshkov wrote: > "Marcos Gutiérrez Batz" <sacrom(a)gmail.com> wrote: > >> Attached is the "patch" file (diff -up) regarding the bug: >> >> http://bugs.winehq.org/show_bug.cgi?format=multiple&id=10156 > > The patch is reversed, please change the source/dest, rediff > and resend. > $ diff -up /usr/include/wine/windows/tapi.h tapi.h --- /usr/include/wine/windows/tapi.h 2007-10-15 00:48:25.000000000 +0200 +++ tapi.h 2007-08-23 16:15:48.000000000 +0200 @@ -589,9 +589,9 @@ typedef struct linedevstatus_tag { DWORD dwOpenMediaModes; DWORD dwNumActiveCalls; DWORD dwNumOnHoldCalls; - DWORD dwNumOnHoldPendingCalls; + DWORD dwNumOnHoldPendCalls; DWORD dwLineFeatures; - DWORD dwNumCallCompletion; + DWORD dwNumCallCompletions; DWORD dwRingMode; DWORD dwSignalLevel; DWORD dwBatteryLevel; $ diff -up /usr/include/wine/windows/oleidl.idl oleidl.idl --- /usr/include/wine/windows/oleidl.idl 2007-10-15 00:48:24.000000000 +0200 +++ oleidl.idl 2007-10-04 14:12:40.000000000 +0200 @@ -333,7 +333,7 @@ interface IOleItemContainer : IOleContai OLECONTF_EMBEDDINGS = 1, OLECONTF_LINKS = 2, OLECONTF_OTHERS = 4, - OLECONTF_OLNYUSER = 8, + OLECONTF_ONLYUSER = 8, OLECONTF_ONLYIFRUNNING = 16 } OLECONTF; $ diff -up /usr/include/wine/msvcrt/signal.h signal.h --- /usr/include/wine/msvcrt/signal.h 2007-10-15 00:48:25.000000000 +0200 +++ signal.h 2007-08-23 16:15:48.000000000 +0200 @@ -39,7 +39,15 @@ typedef void (*__sighandler_t)(int); #define SIG_IGN ((__sighandler_t)1) #define SIG_ERR ((__sighandler_t)-1) +#ifdef __cplusplus +extern "C" { +#endif + __sighandler_t signal(int sig, __sighandler_t func); int raise(int sig); +#ifdef __cplusplus +} +#endif + #endif /* _WINE_SIGNAL_H */

Oct. 24, 2007

Re: "typos" on some include files

by Dmitry Timoshkov

"Marcos Gutiérrez Batz" <sacrom(a)gmail.com> wrote: > $ diff -up liboleaut32.def /usr/lib/wine/liboleaut32.def > --- liboleaut32.def 2007-08-23 16:15:48.000000000 +0200 > +++ /usr/lib/wine/liboleaut32.def 2007-10-15 00:48:35.000000000 +0200 > @@ -366,7 +366,6 @@ EXPORTS > OleCreatePictureIndirect(a)16 @419 > OleCreateFontIndirect(a)12 @420 > OleTranslateColor(a)12 @421 > - OleLoadPictureFile(a)12 @422 > OleLoadPicturePath(a)24 @424 > VarUI4FromI8(a)12 @425 > VarUI4FromUI8(a)12 @426 Also you can't just add an entry to the .def file, it's auto generated. You have to add a stub to the source file, and change the 'stub' entry in the .spec file. -- Dmitry.

Oct. 24, 2007

Re: "typos" on some include files

by Dmitry Timoshkov

"Marcos Gutiérrez Batz" <sacrom(a)gmail.com> wrote: > Attached is the "patch" file (diff -up) regarding the bug: > > http://bugs.winehq.org/show_bug.cgi?format=multiple&id=10156 The patch is reversed, please change the source/dest, rediff and resend. -- Dmitry.

Oct. 24, 2007

Re: dlls/rpcrt4/rpc_server.c initiale variable

by Gerald Pfeifer

On Wed, 24 Oct 2007, Robert Shearman wrote: > It's a false positive, probably coming from the compiler not picking > up that it is set when the exception variable is false and that when > exception is true it is set earlier in the function. Ah, thanks for the analysis. I couldn't convince myself that was the case. ;-) > If you're going to change the code at all, then at least keep to the > coding convention used in the rest of the function and use NULL here. Fair point! Updated patch below. Gerald Index: dlls/rpcrt4/rpc_server.c =================================================================== RCS file: /home/wine/wine/dlls/rpcrt4/rpc_server.c,v retrieving revision 1.85 diff -u -3 -p -r1.85 rpc_server.c --- dlls/rpcrt4/rpc_server.c 22 Aug 2007 11:24:40 -0000 1.85 +++ dlls/rpcrt4/rpc_server.c 24 Oct 2007 12:32:18 -0000 @@ -167,7 +167,7 @@ static void RPCRT4_process_packet(RpcCon RpcServerInterface* sif; RPC_DISPATCH_FUNCTION func; UUID *object_uuid; - RpcPktHdr *response; + RpcPktHdr *response = NULL; void *buf = msg->Buffer; RPC_STATUS status; BOOL exception;

Oct. 24, 2007

Re: oleaut32 [2/2]: Use widl to generate oaidl_p.c

by Alexandre Julliard

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This patch sets up the oleaut32 Makefile and shuffles some files > around so we can use widl to generate oaidl_p.c. The patch is *very* > large since it contains a diff for all of oaidl_p.c (which was > removed), and also two for oaidl.idl (which was moved). That's ugly, we need to make this work without having to rename the public headers. -- Alexandre Julliard julliard(a)winehq.org

Oct. 24, 2007

Re: dlls/rpcrt4/rpc_server.c initiale variable

by Robert Shearman

Gerald Pfeifer wrote: > It seems there are some code paths (in the error case?) which may > leave this unitialized. At least the compiler thinks so, and I > could not convince myself otherwise reading this code for a while. > It's a false positive, probably coming from the compiler not picking up that it is set when the exception variable is false and that when exception is true it is set earlier in the function. > - RpcPktHdr *response; > + RpcPktHdr *response = 0; > > If you're going to change the code at all, then at least keep to the coding convention used in the rest of the function and use NULL here. -- Rob Shearman

Oct. 24, 2007

Re: Anything wrong with my patch from 16.10. about w32x86 and win40creation?

by Jan Zerebecki

On Wed, Oct 24, 2007 at 01:29:03PM +0200, Jan Zerebecki wrote: > On Tue, Oct 23, 2007 at 02:53:19PM +0200, Stefan Dösinger wrote: > > This is how your mail arrived at the mailing list archive as far as I can see: > > http://www.winehq.org/pipermail/wine-patches/2007-October/045287.html > > It seems that is a problem with pipermail. It displays fine with > mutt (from local archives) and also gmane: > http://article.gmane.org/gmane.comp.emulators.wine.patches/42763/ > > I suppose it was rejected by AJ based on the patch content. > > The 3rd try is worse as its attachment has a mime-type of > application/octet-stream instead of text/plain: > http://article.gmane.org/gmane.comp.emulators.wine.patches/43071/ Sorry I missed that the 2nd try had "Content-Transfer-Encoding: quoted-printable" which works fine with mutt and gmane but some tools probably don't support it (I guess the git tools may have problems with emails that have their patch attached in that format). The best way to test if your mail is in the correct format is by trying to apply it with git (the whole mail as mbox, not only the attachment). Jan

Oct. 24, 2007

Re: Anything wrong with my patch from 16.10. about w32x86 and win40creation?

by Jan Z.

On Wed, Oct 24, 2007 at 01:29:03PM +0200, Jan Zerebecki wrote: > On Tue, Oct 23, 2007 at 02:53:19PM +0200, Stefan Dösinger wrote: > > This is how your mail arrived at the mailing list archive as far as I can see: > > http://www.winehq.org/pipermail/wine-patches/2007-October/045287.html > > It seems that is a problem with pipermail. It displays fine with > mutt (from local archives) and also gmane: > http://article.gmane.org/gmane.comp.emulators.wine.patches/42763/ > > I suppose it was rejected by AJ based on the patch content. > > The 3rd try is worse as its attachment has a mime-type of > application/octet-stream instead of text/plain: > http://article.gmane.org/gmane.comp.emulators.wine.patches/43071/ Sorry I missed that the 2nd try had "Content-Transfer-Encoding: quoted-printable" which works fine with mutt and gmane but some tools probably don't support it (I guess the git tools may have problems with emails that have their patch attached in that format). The best way to test if your mail is in the correct format is by trying to apply it with git (the whole mail as mbox, not only the attachment). Jan

Oct. 24, 2007

Re: Anything wrong with my patch from 16.10. about w32x86 and win40creation?

by Jan Zerebecki

On Tue, Oct 23, 2007 at 02:53:19PM +0200, Stefan Dösinger wrote: > This is how your mail arrived at the mailing list archive as far as I can see: > http://www.winehq.org/pipermail/wine-patches/2007-October/045287.html It seems that is a problem with pipermail. It displays fine with mutt (from local archives) and also gmane: http://article.gmane.org/gmane.comp.emulators.wine.patches/42763/ I suppose it was rejected by AJ based on the patch content. The 3rd try is worse as its attachment has a mime-type of application/octet-stream instead of text/plain: http://article.gmane.org/gmane.comp.emulators.wine.patches/43071/ Our pipermail also has it as 0 bytes long: http://www.winehq.org/pipermail/wine-patches/2007-October/045650.html Btw. a very nice feature of gmane is to get archived mail in a raw form (although it ran through gmanes mail to news filter, but that shouldn't remove any information) by adding /raw to the url: http://article.gmane.org/gmane.comp.emulators.wine.patches/42763/raw Jan

Oct. 24, 2007