December 2004 - Wine-Devel - list.winehq.org

Re: out-of-process COM design

by Bill Medland

On December 17, 2004 11:18 am, Mike Hearn wrote: Thanks Mike > On Fri, 17 Dec 2004 10:49:45 -0800, Bill Medland wrote: > > Does anyone know anything about this? e.g. when starting a new thread > > where does the apartment get initialized? > > It's supposed to get initialized in the call to CoInitialize[Ex] however > the _LocalServerThread never calls this as it's an internal implementation > detail of out of process DCOM. > > This looks like we haven't got the design quite right here, the > LocalServerThread doesn't exist in native DCOM as far as I can tell > so it may need to be replaced by something else. > > The code in StdMarshalImpl is correct, the problem is that the local > server thread is violating the COM laws by using CoMarshalInterface before > entering an apartment. > > For now, does this patch help? > Well, it gets me past the illegal memory reference; I can start looking at what else failed now. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 17, 2004

Re: out-of-process COM design

by Mike Hearn

On Fri, 17 Dec 2004 10:49:45 -0800, Bill Medland wrote: > Does anyone know anything about this? e.g. when starting a new thread where > does the apartment get initialized? It's supposed to get initialized in the call to CoInitialize[Ex] however the _LocalServerThread never calls this as it's an internal implementation detail of out of process DCOM. This looks like we haven't got the design quite right here, the LocalServerThread doesn't exist in native DCOM as far as I can tell so it may need to be replaced by something else. The code in StdMarshalImpl is correct, the problem is that the local server thread is violating the COM laws by using CoMarshalInterface before entering an apartment. For now, does this patch help? Index: dlls/ole32/compobj.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/compobj.c,v retrieving revision 1.113 diff -u -p -r1.113 compobj.c --- dlls/ole32/compobj.c 14 Dec 2004 15:28:58 -0000 1.113 +++ dlls/ole32/compobj.c 17 Dec 2004 19:13:22 -0000 @@ -102,6 +102,7 @@ typedef struct tagRegisteredClass DWORD connectFlags; DWORD dwCookie; HANDLE hThread; /* only for localserver */ + APARTMENT *apt; /* owning apartment */ struct tagRegisteredClass* nextClass; } RegisteredClass; @@ -1107,6 +1108,13 @@ _LocalServerThread(LPVOID param) { TRACE("Starting threader for %s.\n",debugstr_guid(&newClass->classIdentifier)); + /* we need to enter the apartment of the thread which registered + * the class object to perform the next stage + */ + + assert( newClass->apt ); + NtCurrentTeb()->ReservedForOle = newClass->apt; + strcpy(pipefn,PIPEPREF); WINE_StringFromCLSID(&newClass->classIdentifier,pipefn+strlen(PIPEPREF)); @@ -1219,6 +1227,12 @@ HRESULT WINAPI CoRegisterClassObject( if ( (lpdwRegister==0) || (pUnk==0) ) return E_INVALIDARG; + if (!COM_CurrentApt()) + { + ERR("COM was not initialized\n"); + return CO_E_NOTINITIALIZED; + } + *lpdwRegister = 0; /* @@ -1240,6 +1254,7 @@ HRESULT WINAPI CoRegisterClassObject( newClass->classIdentifier = *rclsid; newClass->runContext = dwClsContext; newClass->connectFlags = flags; + newClass->apt = COM_CurrentApt(); /* * Use the address of the chain node as the cookie since we are sure it's * unique.

Dec. 17, 2004

out-of-process COM design

by Bill Medland

Is there any chance of help here, please. For one reason or another I need to help get the ole32/oleaut32/rpcrt4 working for our application (the REG_EXPAND_SZ issue means that we don't work with wine after 200409 because of the mix of native dlls we use) I just tried running with the native ole32/oleaut32/rpcrt4 and the first thing I tripped over was (what I presume is) an out-of-process COM problem. The actual stack dump is that: _LocalServerThread (compobj.c) calls StdMarshalImpl_MarshalInterface (...) which has mid.oxid = COM_CurrentApt()->oxid; which throws a memory error because COM_CurrentApt is null because, presumably the thread hasn't yet initialised an apartment. Does anyone know anything about this? e.g. when starting a new thread where does the apartment get initialized? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 17, 2004

Re: MFC app and WineLib

by Serge S. Spiridonoff

The makefile is attached. Yes, it was originally generated by winemaker (20041019 release) winemaker --dll --nobackup --nomfc . Then I manually added several -D, -I, -l options to the makefile. I suspect the I have to pass '--dll' to winebuild instead of '--debug', right? Is there anything else wrong in my makefile? Serge begin 666 Makefile.dat M(R,C($=E;F5R871E9"!B>2!7:6YE;6%K97(*"@I34D-$25(@(" @(" @(" @ M(" @(" @/2 N"D1,3%,@(" @(" @(" @(" @(" @(" ](&UF8RYD;&P*15A% M4R @(" @(" @(" @(" @(" @(#T*"@H*(R,C($-O;6UO;B!S971T:6YG<PH* M0T585%)!(" @(" @(" @(" @(" @(#T(a)+6UN;RUC>6=W:6X*0UA815A44D$@ M(" @(" @(" @(" @(#T(a)7 H)"2UM=VEN9&]W<R!<"@D)+6UN;RUC>6=W:6X@ M7 H)"2U7;F\M9&5P<F5C871E9"!<"@D)+69M<RUE>'1E;G-I;VYS(%P*"0DM M9FYO+69O<BUS8V]P92!<"@D)+41?04987U!/4E1!0DQ%(%P*"0DM1%]&3U)# M14Y!345,15-354Y)3TX(a)7 H)"2U$7T%&6%].3U]$04]?4U504$]25"!<"@D) M+41?04987TY/7T1(5$U,7U-54%!/4E0(a)7 H)"2U$7T%&6%].3U]/3$5$0E]3 M55!03U)4(%P*"0DM1%]!1EA?3D]?0U1,,T1?4U504$]25"!<"@D)+41?0498 M7TY/7T1!3U]355!03U)4(%P*"0DM1%]!1EA?3D]?4T]#2T547U-54%!/4E0@ M7 H)"2U$7T%&6%]#3U)%7TE-4$P(a)7 H)"2U$7T%&6%]/3$5?24U03"!<"@D) M+41?04987T1"7TE-4$P(a)7 H)"2U$35E-1D-?3D]?4DE#2$5$251?5DE%5R!< M"@D)+41-64U&0U]-24Y?3T-#7U-54%!/4E0(a)7 H)"2U$24-/35]54T5?0T]- M7TE.5$521D%#15]!5%1224)55$4(a)7 H)"2U$5TE.,S(@7 H)"2U$7U=)3C,R M(%P*"0DM1%]!1EA$3$P(a)7 H)"2U$7TU4(%P*"0DM1%]$3$P(a)7 H)"2U$7U=) M3D1,3 HC"0DM1%]-0D-3( HC"0DM:7-Y<W1E;2 D*%=)3D5?24Y#3%5$15]2 M3T]4*2]M<W9C<G0*(PD)+6ES>7-T96T@)"A724Y%7TE.0TQ51$5?4D]/5"DO M=VEN9&]W<PHC"0DM1%]!1EA?3D547TE-4$P*(PD)+41?04987TY/7U))0TA% M1$E47U-54%!/4E0*(PD)+41?04987TY/7T]#0U]355!03U)4"@I20T585%)! M(" @(" @(" @(" @(" @/2!<"@D)+41?04987TU/3D],251(24,@7 H)"2U$ M4D5,14%310H*24Y#3%5$15]0051((" @(" @(" @(#T(a)7 H)"2U)+B!<"@D) M+4DN+B\N+B]A=&PO:6YC;'5D92!<"@D)+4DN+B]I;F-L=61E"@I$3$Q?4$%4 M2" @(" @(" @(" @(" @/0I,24)205)97U!!5$@@(" @(" @(" @/0I,24)2 M05))15,@(" @(" @(" @(" @/0H*"B,C(R!M9F,N9&QL('-O=7)C97,@86YD M('-E='1I;F=S"@IM9F-?9&QL7TU/1%5,12 @(" @(#T@;69C+F1L; IM9F-? M9&QL7T-?4U)#4R @(" @(#T*;69C7V1L;%]#6%A?4U)#4R @(" ](%P*"0D) M869X86)O<G0N8W!P(%P*"0D)869X87-E<G0N8W!P(%P*"0D)869X8W)I="YC M<' @7 H)"0EA9GAD8F-S+F-P<"!<"@D)"6%F>&EN;#$N8W!P(%P*"0D)869X M:6YL,BYC<' @7 H)"0EA9GAI;FPS+F-P<"!<"@D)"6%F>&UE;2YC<' @7 H) M"0EA9GAS=&%T92YC<' @7 H)"0EA9GAT;',N8W!P(%P*"0D)869X=')A8V4N M8W!P(%P*"0D)87!P,V0N8W!P(%P*"0D)87!P,V1S+F-P<"!<"@D)"6%P<&-O M<F4N8W!P(%P*"0D)87!P9&QG+F-P<"!<"@D)"6%P<&=R87DN8W!P(%P*"0D) M87!P:&5L<"YC<' @7 H)"0EA<'!H96QP>"YC<' @7 H)"0EA<'!I;FET+F-P M<"!<"@D)"6%P<'!R;G0N8W!P(%P*"0D)87!P=&5R;2YC<' @7 H)"0EA<'!U M:2YC<' @7 H)"0EA<'!U:3$N8W!P(%P*"0D)87!P=6DR+F-P<"!<"@D)"6%P M<'5I,RYC<' @7 H)"0EA<F-C;W)E+F-P<"!<"@D)"6%R8V5X+F-P<"!<"@D) M"6%R8V]B:BYC<' @7 H)"0EA<F-S=')M+F-P<"!<"@D)"6%R<F%Y7V(N8W!P M(%P*"0D)87)R87E?9"YC<' @7 H)"0EA<G)A>5]O+F-P<"!<"@D)"6%R<F%Y M7W N8W!P(%P*"0D)87)R87E?<RYC<' @7 H)"0EA<G)A>5]U+F-P<"!<"@D) M"6%R<F%Y7W<N8W!P(%P*"0D)875X9&%T82YC<' @7 H)"0EB87)C;V]L+F-P M<"!<"@D)"6)A<F-O<F4N8W!P(%P*"0D)8F%R9&QG+F-P<"!<"@D)"6)A<F1O M8VLN8W!P(%P*"0D)8F%R<W1A="YC<' @7 H)"0EB87)T;V]L+F-P<"!<"@D) M"6-C9&%T82YC<' @7 H)"0EC;61T87)G+F-P<"!<"@D)"6-T;&-A8VAE+F-P M<"!<"@D)"6-T;&-O;FXN8W!P(%P*"0D)8W1L8V]R92YC<' @7 H)"0EC=&QD M871A+F-P<"!<"@D)"6-T;&5V96YT+F-P<"!<"@D)"6-T;&9O;G0N8W!P(%P* M"0D)8W1L9G)A;64N8W!P(%P*"0D)8W1L:6YL+F-P<"!<"@D)"6-T;&EN<&QC M+F-P<"!<"@D)"6-T;&QI8RYC<' @7 H)"0EC=&QM;V1U;"YC<' @7 H)"0EC M=&QN;W=N9"YC<' @7 H)"0EC=&QO8FHN8W!P(%P*"0D)8W1L<&)A9RYC<' @ M7 H)"0EC=&QP:6-T+F-P<"!<"@D)"6-T;'!P9RYC<' @7 H)"0EC=&QP<F]P M+F-P<"!<"@D)"6-T;'!R;W!X+F-P<"!<"@D)"6-T;'!S970N8W!P(%P*"0D) M8W1L<'-T9RYC<' @7 H)"0EC=&QP<W1M+F-P<"!<"@D)"6-T;'%U:6-K+F-P M<"!<"@D)"6-T;')E9FPN8W!P(%P*"0D)8W1L<F5G+F-P<"!<"@D)"6-T;'1R M86-K+F-P<"!<"@D)"6-T;'9I97<N8W!P(%P*"0D)9&)C;W)E+F-P<"!<"@D) M"61B9FQT+F-P<"!<"@D)"61B;&]N9RYC<' @7 H)"0ED8G)F>"YC<' @7 H) M"0ED8G9A<BYC<' @7 H)"0ED8G9I97<N8W!P(%P*"0D)9&-M971A+F-P<"!< M"@D)"61C<')E=BYC<' @7 H)"0ED;&=C;'(N8W!P(%P*"0D)9&QG8V]M;2YC M<' @7 H)"0ED;&=C;W)E+F-P<"!<"@D)"61L9V1A=&$N8W!P(%P*"0D)9&QG M9FEL92YC<' @7 H)"0ED;&=F;&]A="YC<' @7 H)"0ED;&=F;G0N8W!P(%P* M"0D)9&QG9G(N8W!P(%P*"0D)9&QG<')N="YC<' @7 H)"0ED;&=P<F]P+F-P M<"!<"@D)"61L9W1E;7!L+F-P<"!<"@D)"61L;&EN:70N8W!P(%P*"0D)9&]C M8V]R92YC<' @7 H)"0ED;V-K8V]N="YC<' @7 H)"0ED;V-K<W1A="YC<' @ M7 H)"0ED;V-M87!I+F-P<"!<"@D)"61O8VUG<BYC<' @7 H)"0ED;V-M=6QT M:2YC<' @7 H)"0ED;V-S:6YG;"YC<' @7 H)"0ED;V-T96UP;"YC<' @7 H) M"0ED=6UP8V]N="YC<' @7 H)"0ED=6UP9FQT+F-P<"!<"@D)"61U;7!I;FET M+F-P<"!<"@D)"61U;7!O=70N8W!P(%P*"0D)97AC97!T+F-P<"!<"@D)"69I M;&5C;W)E+F-P<"!<"@D)"69I;&5F:6YD+F-P<"!<"@D)"69I;&5L:7-T+F-P M<"!<"@D)"69I;&5M96TN8W!P(%P*"0D)9FEL97-H<F0N8W!P(%P*"0D)9FEL M97-T+F-P<"!<"@D)"69I;&5T>'0N8W!P(%P*"0D)9FEL97(a)N8W!P(%P*"0D) M9FEX86QL;V,N8W!P(%P*"0D);&ES=%]O+F-P<"!<"@D)"6QI<W1?<"YC<' @ M7 H)"0EL:7-T7W,N8W!P(%P*"0D);6%P7W!P+F-P<"!<"@D)"6UA<%]P=RYC M<' @7 H)"0EM87!?<V\N8W!P(%P*"0D);6%P7W-P+F-P<"!<"@D)"6UA<%]S M<RYC<' @7 H)"0EM87!?=V\N8W!P(%P*"0D);6%P7W=P+F-P<"!<"@D)"6UT M8V]R92YC<' @7 H)"0EM=&5X+F-P<"!<"@D)"6]B:F-O<F4N8W!P(%P*"0D) M;V-C9&1X+F-P<"!<"@D)"6]C8V1D>&8N8W!P(%P*"0D);V-C;6=R+F-P<"!< M"@D)"6]L96%S;6]N+F-P<"!<"@D)"6]L96)A<BYC<' @7 H)"0EO;&5C;&DQ M+F-P<"!<"@D)"6]L96-L:3(N8W!P(%P*"0D);VQE8VQI,RYC<' @7 H)"0EO M;&5C;G9R="YC<' @7 H)"0EO;&5C;VYN+F-P<"!<"@D)"6]L961A=&$N8W!P M(%P*"0D);VQE9&ES<#$N8W!P(%P*"0D);VQE9&ES<#(N8W!P(%P*"0D);VQE M9&QG<S$N8W!P(%P*"0D);VQE9&QG<S(N8W!P(%P*"0D);VQE9&QG<S,N8W!P M(%P*"0D);VQE9&QL+F-P<"!<"@D)"6]L961O8FHQ+F-P<"!<"@D)"6]L961O M8FHR+F-P<"!<"@D)"6]L961O8S$N8W!P(%P*"0D);VQE9&]C,BYC<' @7 H) M"0EO;&5D;V-C;"YC<' @7 H)"0EO;&5D;V-I<"YC<' @7 H)"0EO;&5D;V-O M8BYC<' @7 H)"0EO;&5D;V-T9RYC<' @7 H)"0EO;&5D;V-V=RYC<' @7 H) M"0EO;&5D<F]P,2YC<' @7 H)"0EO;&5D<F]P,BYC<' @7 H)"0EO;&5E;G5M M+F-P<"!<"@D)"6]L969A8W0N8W!P(%P*"0D);VQE:6YI="YC<' @7 H)"0EO M;&5I<&9R;2YC<' @7 H)"0EO;&5L:6YK+F-P<"!<"@D)"6]L96QO8VLN8W!P M(%P*"0D);VQE;6ES8RYC<' @7 H)"0EO;&5M;VXN8W!P(%P*"0D);VQE;7-G M9BYC<' @7 H)"0EO;&5P<V5T+F-P<"!<"@D)"6]L97)E9RYC<' @7 H)"0EO M;&5S=')M+F-P<"!<"@D)"6]L97-V<C$N8W!P(%P*"0D);VQE<W9R,BYC<' @ M7 H)"0EO;&5T<W9R+F-P<"!<"@D)"6]L971Y<&QB+F-P<"!<"@D)"6]L975I M,2YC<' @7 H)"0EO;&5U:3(N8W!P(%P*"0D);VQE=6YK+F-P<"!<"@D)"6]L M979A<BYC<' @7 H)"0EO;&5V87(Q+F-P<"!<"@D)"6]L979E<F(N8W!P(%P* M"0D)<&QE>"YC<' @7 H)"0EP<&=C;VQO<BYC<' @7 H)"0EP<&=F;VYT+F-P M<"!<"@D)"7!P9W!I8W0N8W!P(%P*"0D)<'!G<W1O8VLN8W!P(%P*"0D)<W1R M8V]R92YC<' @7 H)"0ES=')E>"YC<' @7 H)"0ET:')D8V]R92YC<' @7 H) M"0ET:6UE8V]R92YC<' @7 H)"0ET;V]L=&EP+F-P<"!<"@D)"71R8VMR96-T M+F-P<"!<"@D)"79A;&ED861D+F-P<"!<"@D)"79I97=C;6XN8W!P(%P*"0D) M=FEE=V-O<F4N8W!P(%P*"0D)=FEE=V5D:70N8W!P(%P*"0D)=FEE=V9O<FTN M8W!P(%P*"0D)=FEE=W!R978N8W!P(%P*"0D)=FEE=W!R;G0N8W!P(%P*"0D) M=FEE=W-C<FPN8W!P(%P*"0D)=VEN8G1N+F-P<"!<"@D)"7=I;F-O<F4N8W!P M(%P*"0D)=VEN8W1R;#$N8W!P(%P*"0D)=VEN8W1R;#(N8W!P(%P*"0D)=VEN M8W1R;#,N8W!P(%P*"0D)=VEN8W1R;#0N8W!P(%P*"0D)=VEN8W1R;#4N8W!P M(%P*"0D)=VEN8W1R;#8N8W!P(%P*"0D)=VEN8W1R;#<N8W!P(%P*"0D)=VEN M9G)M+F-P<"!<"@D)"7=I;F9R;3(N8W!P(%P*"0D)=VEN9G)M>"YC<' @7 H) M"0EW:6YG9&DN8W!P(%P*"0D)=VEN9V1I>"YC<' @7 H)"0EW:6YH86YD+F-P M<"!<"@D)"7=I;FUA:6XN8W!P(%P*"0D)=VEN;61I+F-P<"!<"@D)"7=I;FUE M;G4N8W!P(%P*"0D)=VEN;6EN:2YC<' @7 H)"0EW:6YO8V,N8W!P(%P*"0D) M=VEN<W!L:70N8W!P(%P*"0D)=VEN<W1R+F-P<"!<"@D)"7=I;G5T:6PN8W!P M(%P*"0D);V-C8V]N="YC<' @7 H)"0EO8V-D;&<N8W!P(%P*"0D);V-C979E M;G0N8W!P(%P*"0D);V-C;&]C:RYC<' @7 H)"0EO8V-S:71E+F-P<"!<"@D) M"6]L96-A;&PN8W!P"B,@3F\@1$%/("8(a)3TQ%($1"('-U<'!O<G0*(PD)"61A M;V-O<F4N8W!P"B,)"0ED86]D9G(a)N8W!P"B,)"0ED86]V:65W+F-P< HC"0D) M=FEE=V]L960N8W!P"B,@3F\@0U)I8VA%9&ET5FEE=PHC"0D)=FEE=W)I8V(a)N M8W!P"B,@3F\@26YT97)N970@)B!)4T%020HC"0D):6YE="YC<' *(PD)"6EN M971C86QL+F-P< HC"0D):7-A<&DN8W!P"B,)"0EI<V%P:6UI>"YC<' *(R!. M;R!S;V-K971S"B,)"0ES;V-K8V]R92YC<' *(R!.;R!(5$U,"B,)"0EV:65W M:'1M;"YC<' *(R!.;W0@;F5E9&5D(&9O<B!$3$P*(PD)"6%P<&UO9'5L+F-P M<" *(PD)"6YO;&EB+F-P< HC"0D)9&QL;6]D=6PN8W!P"B,)"0ED=6UP<W1A M:RYC<' *(PD)"6]L965X<"YC<' *"@IM9F-?9&QL7U)#7U-20U,@(" @(#T@ M;69C9&QL+G)C"FUF8U]D;&Q?3$1&3$%'4R @(" @/2 M;6YO+6-Y9W=I;@IM M9F-?9&QL7T1,3%]0051((" @(#T@"FUF8U]D;&Q?1$Q,4R @(" @(" @/2!< M"@D):V5R;F5L,S(@7 H)"75S97(S,B!<"@D)9V1I,S(@7 H)"6%D=F%P:3,R M(%P*"0EC;VUD;&<S,B!<"@D)8V]M8W1L,S(@7 H)"7-H96QL,S(@7 H)"6]D M8F,S,B!<"@D);VQE,S(@7 H)"6]L96%U=#,R(%P*"0EO;&5D;&<@7 H)"7=I M;G-P;V]L(%P*"0EU<FQM;VX(a)7 H)"75U:60(a)7 H)"6US=F-R= IM9F-?9&QL M7TQ)0E)!4EE?4$%42#T@"FUF8U]D;&Q?3$E"4D%22453(" @/2 *"FUF8U]D M;&Q?3T)*4R @(" @(" @/2 D*&UF8U]D;&Q?0U]34D-3.BYC/2YO*2!<"@D) M"20H;69C7V1L;%]#6%A?4U)#4SHN8W!P/2YO*2!<"@D)"20H;69C7V1L;%]2 M0U]34D-3.BYR8STN<F5S*0H*"@HC(R,@1VQO8F%L('-O=7)C92!L:7-T<PH* M0U]34D-3(" @(" @(" @(" @(" @(#T@)"AM9F-?9&QL7T-?4U)#4RD*0UA8 M7U-20U,@(" @(" @(" @(" @(#T@)"AM9F-?9&QL7T-86%]34D-3*0I20U]3 M4D-3(" @(" @(" @(" @(" @/2 D*&UF8U]D;&Q?4D-?4U)#4RD*"@HC(R,@ M5&]O;',*"D-#(#T@=VEN96=C8PI#6%@@/2!W:6YE9RLK"E)#(#T@=W)C"E=) M3D5"54E,1" ]('=I;F5B=6EL9 H*"B,C(R!'96YE<FEC('1A<F=E=',*"F%L M;#H@)"A$3$Q3.B4])2YS;RD@)"A%6$53.B4])2YS;RD*"B,C(R!"=6EL9"!R M=6QE<PH*+E!(3TY9.B!A;&P(a)8VQE86X@9'5M;7D*"B0H4U5"1$E24RDZ(&1U M;6UY"@E 8V0@)$ @)B8@)"A-04M%*0H*(R!);7!L:6-I="!R=6QE<PH*+E-5 M1D9)6$53.B N8W!P("YR8R N<F5S"D1%1DE.0TP@/2 D*$E.0TQ51$5?4$%4 M2"D@)"A$149)3D53*2 D*$]05$E/3E,I"@HN8RYO.(a)H))"A#0RD(a)+6,@)"A# M1DQ!1U,I("0H0T585%)!*2 D*$1%1DE.0TPI("UO("1 ("0\"@HN8W!P+F\Z M"@DD*$-86"D(a)+6,@)"A#6%A&3$%'4RD@)"A#6%A%6%1202D@)"A$149)3D-, M*2 M;R D0" D/ H*+F-X>"YO.(a)H))"A#6%@I("UC("0H0UA81DQ!1U,I("0H M0UA815A44D$I("0H1$5&24Y#3"D(a)+6\@)$ @)#P*"BYR8RYR97,Z"@DD*%)# M*2 D*%)#1DQ!1U,I("0H4D-%6%1202D@)"A$149)3D-,*2 M9F\D0" D/ H* M(R!2=6QE<R!F;W(@8VQE86YI;F<*"D-,14%.7T9)3$53(" @(" ]("HN9&)G M+F,@>2YT86(N8R!Y+G1A8BYH(&QE>"YY>2YC(%P*(" @(" @(" @(" @(" @ M(" @8V]R92 J+F]R:6<@*BYR96H(a)7 H@(" @(" @(" @(" @(" @("!<7%PC M*EQ<7",@*GX@*B4(a)+EQ<7",J"@IC;&5A;CHZ("0H4U5"1$E24SHE/24O7U]C M;&5A;E]?*2 D*$585%)!4U5"1$E24SHE/24O7U]C;&5A;E]?*0H))"A232D@ M)"A#3$5!3E]&24Q%4RD@)"A20U]34D-3.BYR8STN<F5S*2 D*$-?4U)#4SHN M8STN;RD@)"A#6%A?4U)#4SHN8W!P/2YO*0H))"A232D@)"A$3$Q3.B4])2YD M8F<N;RD@)"A$3$Q3.B4])2YS;RD*"B0H4U5"1$E24SHE/24O7U]C;&5A;E]? M*3H(a)9'5M;7D*"6-D(&!D:7)N86UE("1 8" F)B D*$U!2T4I(&-L96%N"@HD M*$585%)!4U5"1$E24SHE/24O7U]C;&5A;E]?*3H(a)9'5M;7D*"2UC9"!@9&ER M;F%M92 D0& @)B8@)"A232D@)"A#3$5!3E]&24Q%4RD*"B,C(R!487)G970@ M<W!E8VEF:6,@8G5I;&0@<G5L97,*"B0H;69C7V1L;%]-3T153$4I+F1B9RYC M.B D*&UF8U]D;&Q?0U]34D-3*2 D*&UF8U]D;&Q?0UA87U-20U,I"@DD*%=) M3D5"54E,1"D(a)+6\@)$ @+2UD96)U9R M0R0H4U)#1$E2*2 D*&UF8U]D;&Q? M0U]34D-3*2 D*&UF8U]D;&Q?0UA87U-20U,I"@HD*&UF8U]D;&Q?34]$54Q% M*2YS;SH@)"AM9F-?9&QL7TU/1%5,12DN9&)G+F\@)"AM9F-?9&QL7T]"2E,I M"@DD*$-86"D@("0H;69C7V1L;%],1$9,04=3*2 M;R D0" D*&UF8U]D;&Q? M3T)*4RD@)"AM9F-?9&QL7TU/1%5,12DN9&)G+F\@)"AM9F-?9&QL7TQ)0E)! M4EE?4$%42"D@)"A,24)205)97U!!5$@I("0H;69C7V1L;%]$3$Q3.B4]+6PE >*2 D*&UF8U]D;&Q?3$E"4D%22453.B4]+6PE*0H* ` end

Dec. 17, 2004

Re: [dplobby.h] Define DirectPlayLobbyCreate with respect unicode

by Vincent Béron

Le ven 17/12/2004 à 11:20, Peter Berg Larsen a écrit : > > There might be a better way but I dont know it. > > Changelog: > Defines DirectPlayLobbyCreate to be either the W or A version depending > on the UNICODE. Needed for warzone 2100. > > Peter > > diff -u -r wine-20041201-org/include/dplobby.h wine-20041201/include/dplobby.h > --- wine-20041201-org/include/dplobby.h 2004-10-05 06:38:15.000000000 +0200 > +++ wine-20041201/include/dplobby.h 2004-12-12 11:45:00.000000000 +0100 > @@ -342,7 +342,11 @@ > > } DPAPPLICATIONDESC, *LPDPAPPLICATIONDESC; > > - > +#ifdef UNICODE > +# define DirectPlayLobbyCreate DirectPlayLobbyCreateW > +#else > +# define DirectPlayLobbyCreate DirectPlayLobbyCreateA > +#endif > > extern HRESULT WINAPI DirectPlayLobbyCreateW(LPGUID, LPDIRECTPLAYLOBBY*, IUnknown*, LPVOID, DWORD ); > extern HRESULT WINAPI DirectPlayLobbyCreateA(LPGUID, LPDIRECTPLAYLOBBYA*, IUnknown*, LPVOID, DWORD ); Use #define DirectPlayLobbyCreate WINELIB_NAME_AW(DirectPlayLobbyCreate) after the W and A declarations. That's the standard way in Wine of doing it. Vincent

Dec. 17, 2004

Re: Possible bug in Wine 20041201

by Vincent Béron

Le ven 17/12/2004 à 10:30, Vincent Béron a écrit : > Le ven 17/12/2004 à 09:41, Ira Krakow a écrit : > > I did a fresh install of Wine from the Winehq CVS > > repository. I got the following message during the > > install: > > > > fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS > > version 1.0, please report!! > > Does the included patch help? In case it does help, this patch should be committed instead. Changelog: Better detect a dll's Windows version. Vincent

Dec. 17, 2004

Re: Possible bug in Wine 20041201

by Vincent Béron

Le ven 17/12/2004 à 09:41, Ira Krakow a écrit : > I did a fresh install of Wine from the Winehq CVS > repository. I got the following message during the > install: > > fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS > version 1.0, please report!! Does the included patch help? Vincent

Dec. 17, 2004

Re: Problems unveiled by the last version.c patch

by Rein Klazes

On Fri, 17 Dec 2004 14:51:15 +0100 (CET), you wrote: > Hi Rein, > > > SHGetPathFromIDList seems to be the wrong one here (looking at native > > shell32.dll from Win2K and Win98), it should be synonymous for > > SHGetPathFromIDListA. > > > > Can you try attached patch? > > > > Rein. > > > > This fixes my problem. I've cross-checked and indeed SHGetPathFromIDList > should be synonymous for SHGetPathFromIDListA. OK, I will send it to wine-patches. > > Can we expect to have more 'failures' due to the fact that the new > version.c returns more OS's then before? You could and can still set the OS version in your config file (globally and per application). But since the config file is not automatically created anymore, there will be quite some users testing another OS version soon. It is nice that you have uncovered a bug that required to revert to 'win98', which some applications do not like. > I'm for one seeing a lot more > messages: > > fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 1.0, please > report !! Hmm, it does not seem a good idea to set the OS version to Windows 1.0. Rein.

Dec. 17, 2004

Re: Possible bug in Wine 20041201

by Vincent Béron

Le ven 17/12/2004 à 09:41, Ira Krakow a écrit : > I did a fresh install of Wine from the Winehq CVS > repository. I got the following message during the > install: > > fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS > version 1.0, please report!! Are you using any Win95 native dlls? If so, which one(s)? Vincent

Dec. 17, 2004

Possible bug in Wine 20041201

by Ira Krakow

I did a fresh install of Wine from the Winehq CVS repository. I got the following message during the install: fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 1.0, please report!! I checked bugzilla and didn't see that this bug is tracked. So I'm following instructions, and reporting it. The Wine version is 20041201. My computer is a Dell Dimension 4100 Pentium 3. I'm running Fedora Core 2. Is this a bug? If so, is there a patch for it? Should this be tracked? Ira Krakow ikrakow_1999(a)yahoo.com

Dec. 17, 2004

Re: Advapi32/service.c fix

by Dmitry Timoshkov

"Ivan Leo Puoti" <puoti(a)inwind.it> wrote: > - if( strcmpiW( lpDatabaseName, SERVICES_ACTIVE_DATABASEW ) == 0 ) > + if( (strcmpiW(lpDatabaseName, SERVICES_ACTIVE_DATABASEW)==0) || (lpDatabaseName[0]==(INT)NULL)) It's much simpler to use either !lpDatabaseName[0] or lpDatabaseName[0] == 0 instead of several levels of casting. -- Dmitry.

Dec. 17, 2004

Re: Build problems with GL_VERSION_1_2

by Bill Medland

On December 17, 2004 12:10 am, Raphael wrote: > On Friday 17 December 2004 01:01, Bill Medland wrote: > > (Jason?) > > > > Currently (after many weeks without concentrating) wine doesn't build; it > > fails in dlls/wined3d/drawprim.c line 594 with GL_TEXTURE0 undefined. > > > > That's because of the definition of GL_MULTITEXCOORD... in > > wined3d_private.h for the non-GL_VERSION_1_3 case. > > > > I can see a linguistically obvious fix that gets me thorugh the > > compilation but since I haven't the faintest idea about d3d and GL I > > don't know if it is correct, so I won't submit it. > > Hi Bill, > > can you try with this patch ? Yes, that is the linguistically obvious patch and it allows compilation > > Regards, > Raphael -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 17, 2004

Re: Problems unveiled by the last version.c patch

by Paul Vriens

Hi Rein, > SHGetPathFromIDList seems to be the wrong one here (looking at native > shell32.dll from Win2K and Win98), it should be synonymous for > SHGetPathFromIDListA. > > Can you try attached patch? > > Rein. > This fixes my problem. I've cross-checked and indeed SHGetPathFromIDList should be synonymous for SHGetPathFromIDListA. Can we expect to have more 'failures' due to the fact that the new version.c returns more OS's then before? I'm for one seeing a lot more messages: fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 1.0, please report !! Thanks, Paul.

Dec. 17, 2004

Re: MFC app and WineLib

by Shachar Shemesh

Serge S. Spiridonoff wrote: >I expected that answer :( > >Anyway, I've managed to compile MFC source but got stuck at linking... > >1) The output file is mfc.dll.EXE.so which doesn't seem right. Oviously I >have to pass some extra switches to either wineg++ or winebuild but I can't >figure out the correct ones. > >2) I suspect I need a .spec file too, right? Is it possible to generate it >from mfc42.def that goes with MFC source? >What about C++ name mangling? > >Serge > > Something is wrong with your makefile. You are calling winegcc with the wrong flags. Care to send the list your makefile? Was it generated with a fairly recent winemaker? If so, did you use "--dll"? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Dec. 17, 2004

Re: Problems unveiled by the last version.c patch

by Rein Klazes

On Fri, 17 Dec 2004 12:04:46 +0100 (CET), you wrote: > Hi Dmitry, > > > <pvriens(a)xs4all.nl> wrote: > > > >> trace:shell:SHELL_GetPathFromIDListA -- F:\temp, 0x00000000 > > ... > >> trace:shell:SHGetPathFromIDListW -- L"F:\\temp", 0x00000000 > >> > >> The main difference (apart from the A/W) is that SHGetPathFromIDListW > >> returns an extra backslash compared to the A-counterpart. > > > > If you mean a double backslash in the 2nd line of the above quote > > then it's just the escaping which debugtsr_w() performs. > > > > -- > > Dmitry. > > > > > > I think the problem lies in the fact the some of the procedures use > Unicode depending on the version and some don't care (or use some > default). Going to the traces I can see: > > Call shell32.SHBrowseForFolder(3de5f760) ret=01003c8d > ... (always calls SHBrowseForFolderA) > trace:shell:SHBrowseForFolderA > Ret shell32.SHBrowseForFolder() retval=77e30fc0 ret=01003c8d > ... > Call shell32.SHGetPathFromIDList(77e30fc0,0100b720) ret=01003c99 > trace:shell:SHGetPathFromIDListAW > ... (checking the version) > trace:shell:SHGetPathFromIDListW > ... > Ret shell32.SHGetPathFromIDList() retval=00000001 ret=01003c99 > ... > Call kernel32.lstrcpyA(0100a360,0100b720 "F") ret=01003ca9 > > So you see, we are mixing A and W now: > - SHBrowseForFolderA > - SHGetPathFromIDListW > - lstrcpyA > > In this case does it mean we (I ?) have to implement SHBrowseForFolderAW > or is that the wrong path (as many calls don't do this and all of them > have to be checked/corrected)? SHGetPathFromIDList seems to be the wrong one here (looking at native shell32.dll from Win2K and Win98), it should be synonymous for SHGetPathFromIDListA. Can you try attached patch? Rein.

Dec. 17, 2004

Re: TopLevelWindow Maximize

by Dmitry Timoshkov

"Katia Maculan" <katia.maculan(a)isis-papyrus.com> wrote: > + switch (message) > + { > + case WM_SHOWWINDOW: > + case WM_SIZE: > + DefWindowProc(hWnd, message, wParam, lParam); > + PostMessage (hWnd, WM_PAINT, 0, 0); If you wish to schedule a WM_PAINT message you have to invalidate a window. -- Dmitry.

Dec. 17, 2004

Re: Problems unveiled by the last version.c patch

by Paul Vriens

Hi Dmitry, > <pvriens(a)xs4all.nl> wrote: > >> trace:shell:SHELL_GetPathFromIDListA -- F:\temp, 0x00000000 > ... >> trace:shell:SHGetPathFromIDListW -- L"F:\\temp", 0x00000000 >> >> The main difference (apart from the A/W) is that SHGetPathFromIDListW >> returns an extra backslash compared to the A-counterpart. > > If you mean a double backslash in the 2nd line of the above quote > then it's just the escaping which debugtsr_w() performs. > > -- > Dmitry. > > I think the problem lies in the fact the some of the procedures use Unicode depending on the version and some don't care (or use some default). Going to the traces I can see: Call shell32.SHBrowseForFolder(3de5f760) ret=01003c8d ... (always calls SHBrowseForFolderA) trace:shell:SHBrowseForFolderA Ret shell32.SHBrowseForFolder() retval=77e30fc0 ret=01003c8d ... Call shell32.SHGetPathFromIDList(77e30fc0,0100b720) ret=01003c99 trace:shell:SHGetPathFromIDListAW ... (checking the version) trace:shell:SHGetPathFromIDListW ... Ret shell32.SHGetPathFromIDList() retval=00000001 ret=01003c99 ... Call kernel32.lstrcpyA(0100a360,0100b720 "F") ret=01003ca9 So you see, we are mixing A and W now: - SHBrowseForFolderA - SHGetPathFromIDListW - lstrcpyA In this case does it mean we (I ?) have to implement SHBrowseForFolderAW or is that the wrong path (as many calls don't do this and all of them have to be checked/corrected)? Cheers, Paul.

Dec. 17, 2004

Re: Build problems with GL_VERSION_1_2

by Raphael

On Friday 17 December 2004 01:01, Bill Medland wrote: > (Jason?) > > Currently (after many weeks without concentrating) wine doesn't build; it > fails in dlls/wined3d/drawprim.c line 594 with GL_TEXTURE0 undefined. > > That's because of the definition of GL_MULTITEXCOORD... in > wined3d_private.h for the non-GL_VERSION_1_3 case. > > I can see a linguistically obvious fix that gets me thorugh the compilation > but since I haven't the faintest idea about d3d and GL I don't know if it > is correct, so I won't submit it. Hi Bill, can you try with this patch ? Regards, Raphael

Dec. 17, 2004

Re: Problems unveiled by the last version.c patch

by Dmitry Timoshkov

<pvriens(a)xs4all.nl> wrote: > trace:shell:SHELL_GetPathFromIDListA -- F:\temp, 0x00000000 ... > trace:shell:SHGetPathFromIDListW -- L"F:\\temp", 0x00000000 > > The main difference (apart from the A/W) is that SHGetPathFromIDListW > returns an extra backslash compared to the A-counterpart. If you mean a double backslash in the 2nd line of the above quote then it's just the escaping which debugtsr_w() performs. -- Dmitry.

Dec. 16, 2004

Re: Hang in usr1_handler (ptrace issue?)

by Jesse Allen

On Fri, Dec 10, 2004 at 05:11:34PM +0000, Mike Hearn wrote: > When it hangs (at 100% on the loading screen) get a backtrace using > winedbg, eg: > > winedbg --command 'bt all' > > and post the results here. > > thanks -mike Well, I've had no luck at reproducing the situation. It may have been the version of wine cvs I was running at the time. But it is failing at the cd check like it was originally (2.6.10-rc3). I'll try to figure out what it's doing now. Jesse

Dec. 16, 2004

Re: MFC app and WineLib

by Serge S. Spiridonoff

I expected that answer :( Anyway, I've managed to compile MFC source but got stuck at linking... 1) The output file is mfc.dll.EXE.so which doesn't seem right. Oviously I have to pass some extra switches to either wineg++ or winebuild but I can't figure out the correct ones. 2) I suspect I need a .spec file too, right? Is it possible to generate it from mfc42.def that goes with MFC source? What about C++ name mangling? Serge

Dec. 16, 2004

Build problems with GL_VERSION_1_2

by Bill Medland

(Jason?) Currently (after many weeks without concentrating) wine doesn't build; it fails in dlls/wined3d/drawprim.c line 594 with GL_TEXTURE0 undefined. That's because of the definition of GL_MULTITEXCOORD... in wined3d_private.h for the non-GL_VERSION_1_3 case. I can see a linguistically obvious fix that gets me thorugh the compilation but since I haven't the faintest idea about d3d and GL I don't know if it is correct, so I won't submit it. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 16, 2004

Re: Problems unveiled by the last version.c patch

by Ivan Leo Puoti

> The main difference (apart from the A/W) is that SHGetPathFromIDListW > returns an extra backslash compared to the A-counterpart. > > Any idea where to look next ? It appears that patch 14894 has uncovered a bug in SHGetPathFromIDListW, that's probably where you would want to look next. Ivan.

Dec. 16, 2004

Problems unveiled by the last version.c patch

by pvriens＠xs4all.nl

Hi, just started with a fresh wine install from CVS. I've tried to install vc6redistsetup_enu.exe and was not able to select a directory via the browse dialog. Some regression testing and debugging showed: before patch http://cvs.winehq.org/patch.py?id=14894 : trace:shell:BrsFolderDlgProc hwnd=0x1002e msg=0082 0x00000000 0x00000000 trace:shell:SHGetPathFromIDListAW (pidl=0x63f4f5b8,0x100b720) trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:shell:SHGetPathFromIDListA (pidl=0x63f4f5b8,0x100b720) -------- pidl=0x63f4f5b8 [0x63f4f5b8] size=0020 type=1f attr=0x00000000 name="{20d04fe0-3aea-1069-a2d8-08002b30309d}" ((null),(null)) [0x63f4f5cc] size=0025 type=23 attr=0x00000000 name="F:\" ("F:\\",(null)) [0x63f4f5e5] size=0020 type=31 attr=0x00000010 name="temp" ("temp","") trace:pidl:_ILIsValue (0x63f4f5b8) trace:pidl:_ILIsFolder (0x63f4f5b8) trace:pidl:_ILGetGUIDPointer 0x63f4f5b8 trace:pidl:_ILGetGUIDPointer pdata->type 0x001f trace:pidl:_ILIsMyComputer (0x63f4f5b8) trace:pidl:ILGetNext 0x63f4f5b8 trace:pidl:ILGetNext -- 0x63f4f5cc trace:pidl:_ILIsSpecialFolder (0x63f4f5cc) trace:pidl:ILGetNext 0x63f4f5cc trace:pidl:ILGetNext -- 0x63f4f5e5 trace:shell:PathAddBackslashA ("F:\\") trace:pidl:_ILIsSpecialFolder (0x63f4f5e5) trace:pidl:ILGetNext 0x63f4f5e5 trace:pidl:ILGetNext -- 0x63f4f5f9 trace:shell:SHELL_GetPathFromIDListA -- F:\temp, 0x00000000 after the patch : trace:shell:BrsFolderDlgProc hwnd=0x1002e msg=0082 0x00000000 0x00000000 trace:shell:SHGetPathFromIDListAW (pidl=0x77e2dbe8,0x100b720) trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:shell:SHGetPathFromIDListW (pidl=0x77e2dbe8,0x3f0472b4) -------- pidl=0x77e2dbe8 [0x77e2dbe8] size=0020 type=1f attr=0x00000000 name="{20d04fe0-3aea-1069-a2d8-08002b30309d}" ((null),(null)) [0x77e2dbfc] size=0025 type=23 attr=0x00000000 name="F:\" ("F:\\",(null)) [0x77e2dc15] size=0020 type=31 attr=0x00000010 name="temp" ("temp","") trace:pidl:_ILIsValue (0x77e2dbe8) trace:pidl:_ILIsFolder (0x77e2dbe8) trace:pidl:_ILGetGUIDPointer 0x77e2dbe8 trace:pidl:_ILGetGUIDPointer pdata->type 0x001f trace:pidl:_ILIsMyComputer (0x77e2dbe8) trace:pidl:ILGetNext 0x77e2dbe8 trace:pidl:ILGetNext -- 0x77e2dbfc trace:pidl:_ILIsSpecialFolder (0x77e2dbfc) trace:pidl:ILGetNext 0x77e2dbfc trace:pidl:ILGetNext -- 0x77e2dc15 trace:shell:PathAddBackslashW (L"F:\\") trace:pidl:_ILIsSpecialFolder (0x77e2dc15) trace:pidl:ILGetNext 0x77e2dc15 trace:pidl:ILGetNext -- 0x77e2dc29 trace:shell:SHELL_GetPathFromIDListW -- L"F:\\temp", 0x00000000 trace:shell:SHGetPathFromIDListW -- L"F:\\temp", 0x00000000 The main difference (apart from the A/W) is that SHGetPathFromIDListW returns an extra backslash compared to the A-counterpart. Any idea where to look next ? Cheers, Paul.

Dec. 16, 2004

Re: PATCH: dlls/oleaut32/tests/vartype.c

by Robert Shearman

Marcus Meissner wrote: >Hi, > >This fixes the currently last gcc4 problem. > >I had to split up MSVC / non-MSVC cases since glibc/sprintf >and msvcrt/sprintf disagree on how to print out 64bit integers. > > If you don't use the macro then you can use wine_dbgstr_longlong and not have to worry about compiler differences. Rob

Dec. 16, 2004

Re: MFC app and WineLib

by Kuba Ober

On czwartek 16 grudzień 2004 12:06 am, Serge S. Spiridonoff wrote: > Hi, > > When porting an MFC app to Linux using WineLib is it really necessary to > recompile the MFC DLL from source? > Can I take MFC42.dll from Windows and use it "as is" with an application > compiled with WineLib? No :( MFC42.dll is a C++ library DLL that was compiled with VC++ which is binary incompatible with everything else, including the compiler you use for winelib compilations. Cheers, Kuba

Dec. 16, 2004

Re: <<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

by Shachar Shemesh

Kuba Ober wrote: > >I wouldn't be so sure about that. On win98, in "MS-DOS Prompt" I can type > >edit \\server\myhome\file.txt > >And it opens it just fine. > >Similarly, I can type > >dir "\\server\shared files" > >I'm sure the DOS utilities just use long file name APIs and those "simply >work". It should be the same for win32 apps. > >This is networking stuff, though. Now as far as virtual namespaces go, I have >no idea. > Try to go to the temporary internet files folder. Under explorer you see the shortcuts and their location. From dos (do "dir /a") you see just "Content.IE5" and "Desktop.ini" (which is what makes this folder a shell extension). >This involved some {guid} stuff in the name, but I sure doubt that CreateFile >would dig that. > It won't. This is a *shell* extension. >Maybe the unix stuff can go under \\__unix\something ? > That's an interesting idea, actually. I actually don't think that we need to change anything in wine. mkdir -p ~/.wine/dosdevices/unc/__unix ln -s / ~/.wine/dosdevices/unc/__unix/root That should give you a link to the files the way you want them. I'm too out of touch of the thread to figure out whether that solves our problems. If it does, we can just have wineprefix create create this link.... >Cheers, Kuba > > Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Dec. 16, 2004

Re: Stubs in PE build

by Jon Griffiths

--- Alexandre Julliard <julliard(a)winehq.org> wrote: > I certainly don't want to add 5000 auto-generated stubs. Now if you > want to use winedump to help you write stubs for the cases that are > really necessary (like ordinal exports) sure, but each stub needs > to > be reviewed to make sure the return value etc. are correct. For shlwapi there are 174 ordinal exports (currently stubs) that need to be present in order for msvc's link.exe to generate a correct dll. Its going to take a very long time to verify all of them, but I'll see if I can make a start. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

Dec. 16, 2004

Re: <<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

by Kuba Ober

> >>What's wrong with additional APIs? The browse folder API isn't COM based > >>anyway. > > > >It would be much better to use the API provided to create a namespace for > > the Unix filesystem. The Control Panel and Network Neighborhood are good > > examples of this. Quite a few third party apps create a virtual namespace > > for things like CVS so I don't see why we can't work in the existing API > > to do this with the Unix fs. > > It's been a LONG while since I messed with shell extensions. However, if > my memory serves me right, you cannot pass virtual namespaces to > "CreateFile" and friends. The only one who knows how to work with > virtual namespaces is explorer. I wouldn't be so sure about that. On win98, in "MS-DOS Prompt" I can type edit \\server\myhome\file.txt And it opens it just fine. Similarly, I can type dir "\\server\shared files" I'm sure the DOS utilities just use long file name APIs and those "simply work". It should be the same for win32 apps. This is networking stuff, though. Now as far as virtual namespaces go, I have no idea. This involved some {guid} stuff in the name, but I sure doubt that CreateFile would dig that. Maybe the unix stuff can go under \\__unix\something ? Cheers, Kuba

Dec. 16, 2004

Re: Definition of IMessageFilter in objidl.h

by Dmitry Timoshkov

"Serge S. Spiridonoff" <sss(a)corbina.net> wrote: > Well, I've just noticed the following record in the ChangeLog... > > * include/objidl.h, include/objidl.idl: > Jake Hamby <jhamby(a)anobject.com> > IMessageFilter::HandleInComingCall() should be HandleIncomingCall(). > > Also, http://cvs.winehq.org/patch.py?id=12310 > > So I'm a bit confused now!? Since I'm new to Wine I'd like someone more > experienced to judge this collision. Apparently the patch above is wrong since microsoft headers have it in different case. The patch should be reverted. If you could send a patch which just reverts the above change that would be great. -- Dmitry.

Dec. 16, 2004

Re: dlls/gdi/tests/metafile.c warning about test_mf_PatternBrush

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Should we have a 'skip_wine()' that would skip the enclosed tests > altogether if the platform is Wine? > > This way we could at least make sure that the test passes on all > Windows platforms which is to compare to the current situation where > the test author is probably the only one to have run the test and he > probably did not have access to all Windows platforms. skip_wine()' > would also provide something to grep for rather than the various > workarounds used currently. I don't think there are enough cases to make this necessary. Making all tests behave properly can be tricky which is why we have todo_wine, but it's fairly easy to fix the code to at least avoid crashing, so IMO there's no need to a special infrastructure to handle that. -- Alexandre Julliard julliard(a)winehq.org

Dec. 16, 2004

Re: Stubs in PE build

by Alexandre Julliard

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > So will you accept patches to do this (add empty stubs)? winedump has > had the capacity to auto-generate these functions for _ages_. I certainly don't want to add 5000 auto-generated stubs. Now if you want to use winedump to help you write stubs for the cases that are really necessary (like ordinal exports) sure, but each stub needs to be reviewed to make sure the return value etc. are correct. -- Alexandre Julliard julliard(a)winehq.org

Dec. 16, 2004

MFC app and WineLib

by Serge S. Spiridonoff

Hi, When porting an MFC app to Linux using WineLib is it really necessary to recompile the MFC DLL from source? Can I take MFC42.dll from Windows and use it "as is" with an application compiled with WineLib? Thanks, Serge

Dec. 15, 2004

Re: dlls/gdi/tests/metafile.c warning about test_mf_PatternBrush

by Francois Gouget

On Thu, 9 Dec 2004, Walt Ogburn wrote: > Hi Gerald, > > It's commented out because the test currently crashes under Wine. I > submitted one patch earlier, but the metafile records weren't the same as > the correct Windows values and it didn't get committed. Now that there's > a test I'll work on another patch. Should we have a 'skip_wine()' that would skip the enclosed tests altogether if the platform is Wine? This way we could at least make sure that the test passes on all Windows platforms which is to compare to the current situation where the test author is probably the only one to have run the test and he probably did not have access to all Windows platforms. skip_wine()' would also provide something to grep for rather than the various workarounds used currently. One might argue that this would encourage writing tests without fixing Wine but I would argue that the current situation encourages not putting such tests in Wine at all which is even worse. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Dec. 15, 2004

Re: Definition of IMessageFilter in objidl.h

by Serge S. Spiridonoff

> Yes. Please send a patch. Well, I've just noticed the following record in the ChangeLog... * include/objidl.h, include/objidl.idl: Jake Hamby <jhamby(a)anobject.com> IMessageFilter::HandleInComingCall() should be HandleIncomingCall(). Also, http://cvs.winehq.org/patch.py?id=12310 So I'm a bit confused now!? Since I'm new to Wine I'd like someone more experienced to judge this collision. Serge

Dec. 15, 2004

Re: Should we get rid of the wine-license list?

by Vincent Béron

Le mar 14/12/2004 à 23:49, Dimitrie O. Paun a écrit : > On Tue, Dec 14, 2004 at 08:35:26PM -0800, Scott Ritchie wrote: > > Looking at the archives it appears that wine-license has had very little > > traffic, to the point where a lot of it is probably not being read when > > it comes up, since people like me are not subscribed to that list. > > Yeah, I think it we should get rid of it. It was a dead list from > the very beginning, and it hasn't seen any significant traffic in > a long while. Besides, licensing discussions are rather pointless > now, we can't change from LGPL. What about a future LGPL -> GPL conversion maybe? :) (Yes, I'm not serious. Seriously.) Vincent

Dec. 15, 2004

Re: Definition of IMessageFilter in objidl.h

by Dmitry Timoshkov

"Serge S. Spiridonoff" <sss(a)corbina.net> wrote: > IMessageFilter::HandleInComingCall is defined as HandleIncomingCall in > include/wine/windows/objidl.h (.idl) > Note the capital 'C' in 'InComing' in MS headers. > Is it a misprint? Yes. Please send a patch. -- Dmitry.

Dec. 15, 2004

Definition of IMessageFilter in objidl.h

by Serge S. Spiridonoff

Hi, IMessageFilter::HandleInComingCall is defined as HandleIncomingCall in include/wine/windows/objidl.h (.idl) Note the capital 'C' in 'InComing' in MS headers. Is it a misprint? Thanks

Dec. 15, 2004

Re: Should we get rid of the wine-license list?

by Mike Hearn

On Wed, 15 Dec 2004 14:14:48 -0500, Dimitrie O. Paun wrote: > Keep the archives, they are still reachable via Google, and people > may have links to them. But I think we should remove the reference > to the list from the Mailing Lists/Forums page, it simply clutters > it for no good reason. I think it should remain - reading these archives was how I learned the context behind the TransGaming fork. At the very least there should be a link from the FAQ to these threads.

Dec. 15, 2004

Re: Should we get rid of the wine-license list?

by Dimitrie O. Paun

On Wed, Dec 15, 2004 at 09:27:45AM -0600, Jeremy Newman wrote: > OK, I'll take it down. Shall I remove the archives as well? Or simply > leave them for historical type purposes? Keep the archives, they are still reachable via Google, and people may have links to them. But I think we should remove the reference to the list from the Mailing Lists/Forums page, it simply clutters it for no good reason. -- Dimi.

Dec. 15, 2004

Re: Should we get rid of the wine-license list?

by Ivan Leo Puoti

> OK, I'll take it down. Shall I remove the archives as well? Or simply > leave them for historical type purposes? IMHO we should keep the archives. Ivan. ____________________________________________________________ Regala e regalati Libero ADSL: 3 mesi gratis, navighi veloce e scarichi a 1.2 Mega. Abbonati subito senza costi di attivazione su http://www.libero.it

Dec. 15, 2004

Re: Should we get rid of the wine-license list?

by Jeremy Newman

On Tue, 2004-12-14 at 23:35 -0700, Brian Vincent wrote: > On Tue, 14 Dec 2004 23:49:41 -0500, Dimitrie O. Paun <dpaun(a)rogers.com> wrote: > > On Tue, Dec 14, 2004 at 08:35:26PM -0800, Scott Ritchie wrote: > > > Looking at the archives it appears that wine-license has had very little > > > traffic, to the point where a lot of it is probably not being read when > > > it comes up, since people like me are not subscribed to that list. > > > > Yeah, I think it we should get rid of it. It was a dead list from > > I'll second the motion. Newman? OK, I'll take it down. Shall I remove the archives as well? Or simply leave them for historical type purposes? > Of course, Murphy's law says FSF will soon finish their work on GPL v3 > and maybe a new LGPL. Then we can have the license discussion all > over again. Damn that Murphy.

Dec. 15, 2004

State of the Msi

by Aric Stewart

Hi all, Long time no post :) I just wanted to give an update that Mike M. and I have done alot of msi work over the first few weeks of December which caused a few significant changes to particularly action.c where we eliminated many of the static buffers for file paths and replaced them with dynamic buffers. Vitaly Lipatov's patchs reminded me that i should probably give you all a heads up about that. We where going to break them down and start submitting them but then Mike went off and got married and is on his Honeymoon. So when he gets back we are going to either break the changes down into smaller patches or try to get Alexandre to approve a big one. I will start trying to get some of the smaller ones broken down and submitted in the meantime. Vitaly Lipatov's patchs do not directly conflict with anything so we are just fine there. I will work them into our tree so that i can be sure they are not lost. But if anyone else is also doing msi work you may want to check in here so that we can make sure it all fits together ok. Thanks, -aric

Dec. 15, 2004

Re: VERSION_GetLinkedDllVersion bug fix

by William Lahti

Upon further review, the patch works. Stupid me. William

Dec. 15, 2004

Re: Stubs in PE build

by Jon Griffiths

Hi, > Is there anyway we could add some magic to msvcmaker to do this? It > seems to me that if we need to have the stubs defined in a source > file on msvc we can have msvcmaker parse the spec files and > generate a extra source file when its making the makefiles. If Alexandre will accept patches to add the stubs as dummy functions, we won't need to do this, I will generate + submit the stubs. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com

Dec. 15, 2004

Re: Stubs in PE build

by Jon Griffiths

Hi, > The solution is not to start building a .spec.c > file for MSVC, it's to fix our spec files so that they can work on > Windows without generating extra code. This means replacing the > stubs by real functions. So will you accept patches to do this (add empty stubs)? winedump has had the capacity to auto-generate these functions for _ages_. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com

Dec. 15, 2004

Re: Include file cleanup : dce.h

by Alexandre Julliard

Rémi Assailly <remi.assailly(a)free.fr> writes: > I noticed that in gdi.h PC_SYS_MAPPED is unused and PC_SYS_RESERVED is > only used in dlls/x11drv/palette.c > I think we can remove PC_SYS_MAPPED and move PC_SYS_RESERVED to > dlls/x11drv/palette.c I don't think you want to move just one flag, these are used together in the same variable so they have to be declared together too, otherwise someone might add a new flag without noticing that the same value is already used in another file. -- Alexandre Julliard julliard(a)winehq.org

Dec. 15, 2004

Re: [winelib] Can't figure out a Winemaker error

by Michael Jung

Scott, On Wednesday 15 December 2004 06:32, Scott Ritchie wrote: > Global symbol "%directories" requires explicit package name > at /usr/bin/winemaker line 423. > Global symbol "%directories" requires explicit package name > at /usr/bin/winemaker line 441. > Execution of /usr/bin/winemaker aborted due to compilation errors. > > What's going on here? Did I screw something up, or was this broken in > that release? This is with the December release. This is a problem, which seems to have been introduced in the december release and which is already fixed in cvs. If you don't want to use cvs you can just patch the winemaker script: Move the "my %directories" global variable declaration (somewhere around line 1060) above the "get_directory_contents" function declaration (ca. line 400). Ciao, Michael

Dec. 15, 2004

Re: [winelib] Can't figure out a Winemaker error

by Brian Vincent

On Tue, 14 Dec 2004 21:32:26 -0800, Scott Ritchie <scott(a)open-vote.org> wrote: > As part of my effort to create a successful demonstration of how to port > something, I tried out winelib. Unfortunately, I can't seem to get it > working at all. I get this error whenever I run winemaker: > > Global symbol "%directories" requires explicit package name > at /usr/bin/winemaker line 423. Are you running this on Windows? I thought Steven Edwards posted a patch for that a while back. -Brian

Dec. 15, 2004

Re: Should we get rid of the wine-license list?

by Brian Vincent

On Tue, 14 Dec 2004 23:49:41 -0500, Dimitrie O. Paun <dpaun(a)rogers.com> wrote: > On Tue, Dec 14, 2004 at 08:35:26PM -0800, Scott Ritchie wrote: > > Looking at the archives it appears that wine-license has had very little > > traffic, to the point where a lot of it is probably not being read when > > it comes up, since people like me are not subscribed to that list. > > Yeah, I think it we should get rid of it. It was a dead list from I'll second the motion. Newman? Of course, Murphy's law says FSF will soon finish their work on GPL v3 and maybe a new LGPL. Then we can have the license discussion all over again. -Brian

Dec. 15, 2004