date:20050120

On Thu, 2005-01-20 at 22:21, Mike Hearn wrote:
> On Thu, 2005-01-20 at 20:32 +0100, Paul Vriens wrote:
> > Sorry, didn't help.
> > 
> > I'm going to try Rob's suggestions now.
> 
> This patch fixes it for me.
> 
> Mike Hearn <[EMAIL PROTECTED]>
> Fix heap corruption in quartz server registration, add
> some whitespace, break out of loop if out of memory
> 
> --- dlls/quartz/regsvr.c  (revision 109)
> +++ dlls/quartz/regsvr.c  (local)
> @@ -577,7 +577,6 @@ static HRESULT register_filters(struct r
>  IFilterMapper2* pFM2 = NULL;
>  
>  CoInitialize(NULL);
> -
>  hr = CoCreateInstance(&CLSID_FilterMapper2, NULL, CLSCTX_INPROC_SERVER, 
> &IID_IFilterMapper2, (LPVOID*)&pFM2);
>  
>  if (SUCCEEDED(hr)) {
> @@ -585,6 +584,7 @@ static HRESULT register_filters(struct r
>   REGFILTER2 rf2;
>   REGFILTERPINS2* prfp2;
>   int i;
> +
>   for (i = 0; list->pins[i].flags != 0x; i++) ;
>   rf2.dwVersion = 2;
>   rf2.dwMerit = list->merit;
> @@ -598,6 +598,7 @@ static HRESULT register_filters(struct r
>   REGPINTYPES* lpMediatype;
>   CLSID* lpClsid;
>   int j, nbmt;
> +
>   for (nbmt = 0; list->pins[i].mediatypes[nbmt].majortype; 
> nbmt++) ;
>   /* Allocate a single buffer for regpintypes struct and clsids */
>   lpMediatype = (REGPINTYPES*) 
> CoTaskMemAlloc(nbmt*(sizeof(REGPINTYPES) + 2*sizeof(CLSID)));
> @@ -627,10 +628,17 @@ static HRESULT register_filters(struct r
>   prfp2[i].clsPinCategory = NULL;
>   }
>  
> + if (FAILED(hr)) {
> + ERR("failed to register with hresult 0x%lx\n", hr);
> + break;
> + }
> +
>   hr = IFilterMapper2_RegisterFilter(pFM2, list->clsid, list->name, 
> NULL, list->category, NULL, &rf2);
>  
> - while (i--)
> + while (i) {
>   CoTaskMemFree((REGPINTYPES*)prfp2[i-1].lpMediaType);
> + i--;
> + }
>   CoTaskMemFree(prfp2);
>   }
>  }
> 
Let's hear it for Mike !!

Works here as well. I don't get any ERR output so I presume it's just
the change of the while() that already fixed it? 

Cheers and thanks,

Paul.

Fix heap corruption in quartz server registration

On Thu, 2005-01-20 at 20:32 +0100, Paul Vriens wrote:
> Sorry, didn't help.
> 
> I'm going to try Rob's suggestions now.

This patch fixes it for me.

Mike Hearn <[EMAIL PROTECTED]>
Fix heap corruption in quartz server registration, add
some whitespace, break out of loop if out of memory

--- dlls/quartz/regsvr.c  (revision 109)
+++ dlls/quartz/regsvr.c  (local)
@@ -577,7 +577,6 @@ static HRESULT register_filters(struct r
 IFilterMapper2* pFM2 = NULL;
 
 CoInitialize(NULL);
-
 hr = CoCreateInstance(&CLSID_FilterMapper2, NULL, CLSCTX_INPROC_SERVER, 
&IID_IFilterMapper2, (LPVOID*)&pFM2);
 
 if (SUCCEEDED(hr)) {
@@ -585,6 +584,7 @@ static HRESULT register_filters(struct r
REGFILTER2 rf2;
REGFILTERPINS2* prfp2;
int i;
+
for (i = 0; list->pins[i].flags != 0x; i++) ;
rf2.dwVersion = 2;
rf2.dwMerit = list->merit;
@@ -598,6 +598,7 @@ static HRESULT register_filters(struct r
REGPINTYPES* lpMediatype;
CLSID* lpClsid;
int j, nbmt;
+
for (nbmt = 0; list->pins[i].mediatypes[nbmt].majortype; 
nbmt++) ;
/* Allocate a single buffer for regpintypes struct and clsids */
lpMediatype = (REGPINTYPES*) 
CoTaskMemAlloc(nbmt*(sizeof(REGPINTYPES) + 2*sizeof(CLSID)));
@@ -627,10 +628,17 @@ static HRESULT register_filters(struct r
prfp2[i].clsPinCategory = NULL;
}
 
+   if (FAILED(hr)) {
+   ERR("failed to register with hresult 0x%lx\n", hr);
+   break;
+   }
+
hr = IFilterMapper2_RegisterFilter(pFM2, list->clsid, list->name, 
NULL, list->category, NULL, &rf2);
 
-   while (i--)
+   while (i) {
CoTaskMemFree((REGPINTYPES*)prfp2[i-1].lpMediaType);
+   i--;
+   }
CoTaskMemFree(prfp2);
}
 }

Re: Regression : tools/wineinstall fails with an X Error

On Thu, 2005-01-20 at 20:32 +0100, Paul Vriens wrote:
> Sorry, didn't help.
> 
> I'm going to try Rob's suggestions now.

Right, Alexandre just clued me in that anonymous mmaps are always zerod.
Nice theory, but no cigar this time. I've been able to reproduce the bug
(sometimes) and am narrowing it down now. Let's see who gets there
first! ;)

Re: Regression : tools/wineinstall fails with an X Error

On Thu, 2005-01-20 at 20:17, Mike Hearn wrote:
> On Thu, 20 Jan 2005 19:36:27 +0100, Paul Vriens wrote:
> > When I do the same change now, the X Error is gone as well. Does this
> > give you a clue?
> 
> Could you try this patch please?
> 
> --- dlls/ntdll/thread.c  (revision 109)
> +++ dlls/ntdll/thread.c  (local)
> @@ -73,6 +73,7 @@ static TEB *alloc_teb( ULONG *size )
>  teb->Peb   = &peb;
>  teb->StaticUnicodeString.Buffer= teb->StaticUnicodeBuffer;
>  teb->StaticUnicodeString.MaximumLength = 
> sizeof(teb->StaticUnicodeBuffer);
> +teb->ReservedForOle= NULL;
>  return teb;
>  }
> 
> thanks -mike
> 
> 
> 
Sorry, didn't help.

I'm going to try Rob's suggestions now.

Paul.

Re: Regression : tools/wineinstall fails with an X Error

2005-01-20 Thread Robert Shearman

Paul Vriens wrote:
On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
 

If it's heap corruption then it could well depend on the order of 
allocations, so it could be timing dependent.
I've attached a patch that poisons the apartment structure after when it 
is freed so that hopefully any use-after-free will become more obvious. 
Could you apply it and see what the results are? Does the X Error stop? 
Do we now get warnings about accessing a handle of 0x (run with 
warn+all for this)?

Rob
   

I can remember having a conversation with Christian Costa for the same kind of error. 

That was after he added some extra filter registration in quartz/regsvr.c. I 
just played
around with the CoInitialize in register_filters.
I changed CoInitialize(NULL) into CoInitializeEx(NULL,
COINIT_MULTITHREADED) and the error was gone.
When I do the same change now, the X Error is gone as well. Does this
give you a clue?
 

Not much I'm afraid. When using an MTA the window isn't created, so 
there is no chance of an X Error during its destruction.
There is something you could try though. Can you move the "if (apt->win) 
DestroyWindow(apt->win);" line in COM_ApartmentRelease to after the 
LIST_FOR_EACH_SAFE list iteration? If the apartment pointer is bad then 
we should easily die in the list iteration (the iteration will only end 
once it finds a pointer back to the original list, which is very 
unlikely if we are using a bad apartment pointer).
I also noticed in the log that you are getting a few heap warnings. 
Could you try scattering a few of these debug statements throughout the 
devenum self-registration code (particularly around any COM calls):
if (!HeapValidate(GetProcessHeap(), 0, NULL)) DebugBreak();
This should then dump you to the debugger close to where the heap 
corruption occurred. If you can narrow it down to one line in devenum 
(i.e. it succeeds before the call, fails after) then can you let me know 
which line that is and that should be a big clue to finding out what is 
going wrong.

Thanks,
Rob

Re: Regression : tools/wineinstall fails with an X Error

On Thu, 20 Jan 2005 19:36:27 +0100, Paul Vriens wrote:
> When I do the same change now, the X Error is gone as well. Does this
> give you a clue?

Could you try this patch please?

--- dlls/ntdll/thread.c  (revision 109)
+++ dlls/ntdll/thread.c  (local)
@@ -73,6 +73,7 @@ static TEB *alloc_teb( ULONG *size )
 teb->Peb   = &peb;
 teb->StaticUnicodeString.Buffer= teb->StaticUnicodeBuffer;
 teb->StaticUnicodeString.MaximumLength = sizeof(teb->StaticUnicodeBuffer);
+teb->ReservedForOle= NULL;
 return teb;
 }

thanks -mike

Re: wined3d updates

2005-01-20 Thread Ann and Jason Edmeades

Hi Oliver,

D3DRESOURCETYPE WINAPI IWineD3DCubeTextureImpl_GetType(IWineD3DCubeTexture
*iface) {
-return IWineD3DResourceImpl_GetType((IWineD3DResource *)iface);
+return IWineD3DResource_GetType((IWineD3DResource *)iface);
 }

This is wrong (and others) - you'll end up in an infinite loop. You must
calls the impl type if you are effectively casting the interface into one of
the types it inherits from

I haven't got chance to review the rest yet - I'm heading away for the
weekend. I'll look at the rest on Mon if you want any comments.

Jason

Re: Regression : tools/wineinstall fails with an X Error

On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
> If it's heap corruption then it could well depend on the order of 
> allocations, so it could be timing dependent.
> I've attached a patch that poisons the apartment structure after when it 
> is freed so that hopefully any use-after-free will become more obvious. 
> Could you apply it and see what the results are? Does the X Error stop? 
> Do we now get warnings about accessing a handle of 0x (run with 
> warn+all for this)?
> 
> Rob
I can remember having a conversation with Christian Costa for the same kind of 
error. 

That was after he added some extra filter registration in quartz/regsvr.c. I 
just played
around with the CoInitialize in register_filters.
I changed CoInitialize(NULL) into CoInitializeEx(NULL,
COINIT_MULTITHREADED) and the error was gone.

When I do the same change now, the X Error is gone as well. Does this
give you a clue?

Paul.

Re: Font selection logic defective?

2005-01-20 Thread Bill Medland

On January 20, 2005 07:37 am, Bill Medland wrote:
> On January 20, 2005 03:31 am, Huw D M Davies wrote:
> > On Wed, Jan 19, 2005 at 05:58:59PM -0800, Bill Medland wrote:
> > > On January 18, 2005 03:00 pm, Huw D M Davies wrote:
> > > > On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
> > > > > (Huw?)

> However your settings for the xlldrv section didn't seem to make a
> difference.
>

My sincerest apologies, Huw.  xlldrv is not quite the same as x11drv, is it?
(I haven't the faintest idea how I mis-spelled it!!!)

BTW, Would adding Postscript handling handle pfb, pfa and pcf files?  (I don't 
know font formats.)

-- 
Bill Medland
mailto:[EMAIL PROTECTED]
http://webhome.idirect.com/~kbmed

Re: Regression : tools/wineinstall fails with an X Error

On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
> If it's heap corruption then it could well depend on the order of 
> allocations, so it could be timing dependent.
> I've attached a patch that poisons the apartment structure after when it 
> is freed so that hopefully any use-after-free will become more obvious. 
> Could you apply it and see what the results are? Does the X Error stop? 
> Do we now get warnings about accessing a handle of 0x (run with 
> warn+all for this)?
> 
> Rob
see my previous email for the warn+err piece. 

I now did a warn+all,+ole trace and checked for warn:heap messages,
there are a lot of them. I don't know if they are 'normal' warnings or
related to the problem I'm seeing:

trace:ole:COMPOBJ_DLLList_Add
trace:ole:WINE_StringFromCLSID
0x57bbc254->{083863F1-70DE-11D0-BD40-00A0C911CE86}
trace:ole:WINE_StringFromCLSID
0x57bbbf84->{1B544C20-FD0B-11CE-8C63-00AA0044B51E}
trace:ole:WINE_StringFromCLSID
0x57bbc224->{4315D437-5B8C-11D0-BD3B-00A0C911CE86}
trace:ole:CoGetClassObject
CLSID:  {4315d437-5b8c-11d0-bd3b-00a0c911ce86},
IID:{0001---c000-0046}
trace:ole:COMPOBJ_DLLList_Add
trace:ole:CreateBindCtx (0,0x1036d808)
trace:ole:BindCtxImpl_Construct (0x6d940bd0)
trace:ole:BindCtxImpl_QueryInterface (0x6d940bd0,0x1036d7b4,0x1036d808)
trace:ole:BindCtxImpl_AddRef (0x6d940bd0)
trace:ole:__CLSIDFromStringA {083863F1-70DE-11D0-BD40-00A0C911CE86} ->
0x1036d7a8
trace:ole:WINE_StringFromCLSID
0x1036d7a8->{083863F1-70DE-11D0-BD40-00A0C911CE86}
trace:ole:BindCtxImpl_Release (0x6d940bd0)
trace:ole:BindCtxImpl_ReleaseBoundObjects (0x6d940bd0)
trace:ole:BindCtxImpl_Destroy (0x6d940bd0)
trace:ole:WINE_StringFromCLSID
0x57bbbf84->{1B544C20-FD0B-11CE-8C63-00AA0044B51E}
warn:heap:HEAP_IsRealArena Heap 0x6d8d: block 0x690077 is not inside
heap

btw. adding the +ole made the X Error go away as before.

Cheers,

Paul.

Re: Regression : tools/wineinstall fails with an X Error

On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
> Paul Vriens wrote:
> 
> >On Thu, 2005-01-20 at 11:47, Paul Vriens wrote:
> >  
> >
> >>On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
> >>
> >>
> >>>Paul Vriens <[EMAIL PROTECTED]> writes:
> >>>
> >>>  
> >>>
> and part of a trace:
> 
> 0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460,
> oxid 80009
> 
> 
> >>>Looks like some sort of heap corruption, the apartment pointer is
> >>>suspiciously similar to the bad contents of the x11drv window
> >>>structure.
> >>>
> >>>  
> >>>
> If you want a better trace, let me know.
> 
> 
> >>>Yes I'd be interested to see the whole trace.
> >>>  
> >>>
> >>All seems to point to patch http://cvs.winehq.org/patch.py?id=15392
> >>
> >>I'm not a 100% convinced as I have some trouble with the regression
> >>testing. I started with a clean installed Wine upto this patch and I get
> >>the XError. If I go one patch back I don't see the problem.
> >>
> >>Paul.
> >>
> >>
> >Ok, I'm convinced that the mentioned patch gives the X Error. But while
> >I was investigating the following happened:
> >
> >I ran "wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall
> >128 wine.inf" from within the tools directory. This gives the X Error.
> >
> >I did this several times after each other with the same result.
> >
> >I than ran "WINEDEBUG=+ole wine rundll32.exe
> >setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf" and the
> >error is gone !?!?
> >
> >The registry is now filled with all the default data.
> >
> >Any ideas how to proceed ? Is there a timing issue ?
> >  
> >
> 
> If it's heap corruption then it could well depend on the order of 
> allocations, so it could be timing dependent.
> I've attached a patch that poisons the apartment structure after when it 
> is freed so that hopefully any use-after-free will become more obvious. 
> Could you apply it and see what the results are? Does the X Error stop? 
> Do we now get warnings about accessing a handle of 0x (run with 
> warn+all for this)?
> 
> Rob
> 
> __
> Index: dlls/ole32/compobj.c
> ===
> RCS file: /home/wine/wine/dlls/ole32/compobj.c,v
> retrieving revision 1.129
> diff -u -p -r1.129 compobj.c
> --- dlls/ole32/compobj.c  20 Jan 2005 10:35:46 -  1.129
> +++ dlls/ole32/compobj.c  20 Jan 2005 17:16:37 -
> @@ -329,6 +329,9 @@ DWORD COM_ApartmentRelease(struct apartm
>  
>  DeleteCriticalSection(&apt->cs);
>  CloseHandle(apt->thread);
> +/* fill memory with invalid data to try and make us crash if we reuse
> + * it */
> +memset(apt, 0xcc, sizeof(*apt));
>  HeapFree(GetProcessHeap(), 0, apt);
>  }
>  
Hi Rob,

these are the last lines of the warn+all:

warn:file:wine_nt_to_unix_file_name L"quartz.dll" not found in
/home/paul/.wine/dosdevices/z:/data/install/linux/wine-src/wine/tools
warn:file:wine_nt_to_unix_file_name L"quartz.dll" not found in
/home/paul/.wine/dosdevices/z:/data/install/linux/wine-src/wine/tools
warn:file:wine_nt_to_unix_file_name L"quartz.dll" not found in
/home/paul/.wine/dosdevices/c:/windows/system
warn:file:wine_nt_to_unix_file_name L"quartz.dll" not found in
/home/paul/.wine/dosdevices/c:/windows
warn:heap:HEAP_ValidateInUseArena Heap 77de: invalid in-use arena
magic for 77e5b948
warn:heap:HEAP_ValidateInUseArena Heap 77de: invalid in-use arena
magic for 77e5b948
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x77de0060
  Serial number of failed request:  107
  Current serial number in output stream:  113

there is no message regarding a accessing a handle of 0x

Cheers,

Paul.

Re: Wine threads and TRY/CATCH macros and DCE threads and TRY/CATCH macros

On Thu, Jan 20, 2005 at 08:49:27AM -0800, Juan Lang wrote:
> Hi Luke, I don't know is this is useful, but the TRY/CATCH stuff in
> particular is declared here:
> http://source.winehq.org/source/include/wine/exception.h
> and the Wine exception handling code is implemented here:
> http://source.winehq.org/source/dlls/ntdll/exception.c
> 
> As Mike said, the Wine threading stuff is pretty complicated.  Native
> applications unfortunately rely on things being exactly in the right place
> in the TEB, and DCE threads are unlikely to give us this.  Peruse if you
> like
> http://source.winehq.org/source/include/thread.h
> and
> http://source.winehq.org/source/dlls/ntdll/thread.c
 
 well if the stuff is "exact" and cannot be changed, then
 at least it may be possible to go the other way round - port
 dcethreads to run on wine instead.

 l.

Re: RpcImpersonateClient (and ImpersonateNamedPipeClient)

On Thu, Jan 20, 2005 at 09:08:27AM -0800, Juan Lang wrote:
> Hi Luke, you said:
> > that's where you'd need the cooperation of samba / samba tng:
> > it's got "SIDs" behind it, and "SIDs" means a SAMR server
> > and a NETLOGON server and an LSARPC server (and in the
> > case of windows 2000 interoperability, access to an Active
> > Directory Server).
> 
> Another possibility is that we implement our own version of a SAM.  Right
> now we just return a fake Administrator SID every time we're asked for
> one.  But if we absolutely needed to, we could implement a local version
> and it needn't even be a separate process.  The NT SAM registry is pretty
> well reverse engineered here:

> http://neworder.box.sk/files/nullak_ntsecurity/index.php

 hah, col!  that's so hilarious.

 okay, yep - the bit here:

\HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\%RID%\V
(variable length, 424+)

 that's just a SAMR_USER_INFO_21 structure - been there, done that.

 see here:

http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/include/rpc_samr.h?rev=1.18&content-type=text/vnd.viewcvs-markup

 by the way - does anyone understand the SamrQueryAliasMembers function
 and the SamrQueryUserAliases function?

 these are the _weirdest_ functions i ever heard about and i really
 haven't understood them well.

> > you can always still implement RpcImpersonateClient as a stub.
> 
> Yah.  I think that's more likely than that we go whole-hog on it.  

 _great_ because if you do that, i'm likely to rip that off whole-sale
 for use behind a DCE/RPC interface - using samr.idl (from which samr.h
 has been generated) - see:

 http://hands.com/~lkcl/samr

> From
> experience, it's often more important to get things like parameters and
> error codes just the way Windows programs expect than it is to make a
> function "really work."  By implementing a stubbed or local-only version,
> we can figure out all this stuff, and maybe make a full-blown version
> later.

 see below, because if you implement "stub" versions, and
 the intercommunications (in this case DCE/RPC), it will be
 possible to "drop in" a replacement like samba tng's services
 or even if the samba team will cooperate, a samba 3 or even
 a samba 4 server.

 at run-time.

 because that's what DCE/RPC gives you: binary-level separation and
 network-defined interface points.

 it's just so utterly cool.

> and later,
> > it _does_ mean careful design because i doubt very much whether people
> > will be happy to have samba tng as a dependency on Wine.
> 
> Agreed.  The focus for the Wine folks is generally, does this get my app
> to work?  Unless it's fixing an app, not too many folks are likely to get
> real excited by anything.
> 
> Feel free to point out what we've been missing.  Patches speak louder than
> anything here :)

 would you be _really_ ready for a couple of hundred thousand lines of
 code??? virtually the _entire_ samba tng project _and_ the freedce
 project???

 *lol* :)

 no, but seriously, as you can see by the thing sparked off by
 rob's RpcImpersonateClient question, there's a whole _truck_
 load of code needed that sort of "hangs together".

 combine that with the fact that you (wine) _must_ conform
 _exactly_ to the required APIs at both a header-file level,
 IDL file level, binary level, pretty-much-everything level,
 if one group implements one part (behind, say, samr.h to
 produce samr.dll) then that's _exactly_ what's needed for
 samba tng.

 and also the corrolololorary is that if you can get the
 rpcrt4.dll working _properly_ - i.e. wire-compatible with
 DCE/RPC / MSRPC, then you won't _need_ to do any work on
 producing a samr dll, you can just communicate directly with
 samba tng's samr server.

 plus various other combinations along the same lines that
 would do everyone's heads in to enumerate.

 l.

Re: Regression : tools/wineinstall fails with an X Error

2005-01-20 Thread Robert Shearman

Paul Vriens wrote:
On Thu, 2005-01-20 at 11:47, Paul Vriens wrote:
 

On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
   

Paul Vriens <[EMAIL PROTECTED]> writes:
 

and part of a trace:
0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460,
oxid 80009
   

Looks like some sort of heap corruption, the apartment pointer is
suspiciously similar to the bad contents of the x11drv window
structure.
 

If you want a better trace, let me know.
   

Yes I'd be interested to see the whole trace.
 

All seems to point to patch http://cvs.winehq.org/patch.py?id=15392
I'm not a 100% convinced as I have some trouble with the regression
testing. I started with a clean installed Wine upto this patch and I get
the XError. If I go one patch back I don't see the problem.
Paul.
   

Ok, I'm convinced that the mentioned patch gives the X Error. But while
I was investigating the following happened:
I ran "wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall
128 wine.inf" from within the tools directory. This gives the X Error.
I did this several times after each other with the same result.
I than ran "WINEDEBUG=+ole wine rundll32.exe
setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf" and the
error is gone !?!?
The registry is now filled with all the default data.
Any ideas how to proceed ? Is there a timing issue ?
 

If it's heap corruption then it could well depend on the order of 
allocations, so it could be timing dependent.
I've attached a patch that poisons the apartment structure after when it 
is freed so that hopefully any use-after-free will become more obvious. 
Could you apply it and see what the results are? Does the X Error stop? 
Do we now get warnings about accessing a handle of 0x (run with 
warn+all for this)?

Rob
Index: dlls/ole32/compobj.c
===
RCS file: /home/wine/wine/dlls/ole32/compobj.c,v
retrieving revision 1.129
diff -u -p -r1.129 compobj.c
--- dlls/ole32/compobj.c	20 Jan 2005 10:35:46 -	1.129
+++ dlls/ole32/compobj.c	20 Jan 2005 17:16:37 -
@@ -329,6 +329,9 @@ DWORD COM_ApartmentRelease(struct apartm
 
 DeleteCriticalSection(&apt->cs);
 CloseHandle(apt->thread);
+/* fill memory with invalid data to try and make us crash if we reuse
+ * it */
+memset(apt, 0xcc, sizeof(*apt));
 HeapFree(GetProcessHeap(), 0, apt);
 }

Re: RpcImpersonateClient (and ImpersonateNamedPipeClient)

2005-01-20 Thread Juan Lang

Hi Luke, you said:
> that's where you'd need the cooperation of samba / samba tng:
> it's got "SIDs" behind it, and "SIDs" means a SAMR server
> and a NETLOGON server and an LSARPC server (and in the
> case of windows 2000 interoperability, access to an Active
> Directory Server).

Another possibility is that we implement our own version of a SAM.  Right
now we just return a fake Administrator SID every time we're asked for
one.  But if we absolutely needed to, we could implement a local version
and it needn't even be a separate process.  The NT SAM registry is pretty
well reverse engineered here:
http://neworder.box.sk/files/nullak_ntsecurity/index.php

> you can always still implement RpcImpersonateClient as a stub.

Yah.  I think that's more likely than that we go whole-hog on it.  From
experience, it's often more important to get things like parameters and
error codes just the way Windows programs expect than it is to make a
function "really work."  By implementing a stubbed or local-only version,
we can figure out all this stuff, and maybe make a full-blown version
later.

and later,
> it _does_ mean careful design because i doubt very much whether people
> will be happy to have samba tng as a dependency on Wine.

Agreed.  The focus for the Wine folks is generally, does this get my app
to work?  Unless it's fixing an app, not too many folks are likely to get
real excited by anything.

Feel free to point out what we've been missing.  Patches speak louder than
anything here :)

--Juan



__ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

Re: Running dxdiag

2005-01-20 Thread Steven Edwards

--- Mike [EMAIL PROTECTED]:
> Well, if the little stub is overwritten by a correct native DLDLLhen 
> there is no problem at all. If some install overwrites it with an older 
> version than what apps expect (or Wine provides) then that might be a 
> problem, but that's just the generic DLDLLell the windows library design 
> implies.

Windows XPXPas this nice new feature of Side-by-Side AsAssemblieshat is a .Net 
concept. It
combined with Windows File Protection has in effect ended DLDLLell. Maybe we 
should look at
implementing some sort of side-by-side system in Wine.

Thanks
Steven



__ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

Re: Regression : tools/wineinstall fails with an X Error

On Thu, 2005-01-20 at 11:47, Paul Vriens wrote:
> On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
> > Paul Vriens <[EMAIL PROTECTED]> writes:
> > 
> > > and part of a trace:
> > > 
> > > 0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460,
> > > oxid 80009
> > 
> > Looks like some sort of heap corruption, the apartment pointer is
> > suspiciously similar to the bad contents of the x11drv window
> > structure.
> > 
> > > If you want a better trace, let me know.
> > 
> > Yes I'd be interested to see the whole trace.
> All seems to point to patch http://cvs.winehq.org/patch.py?id=15392
> 
> I'm not a 100% convinced as I have some trouble with the regression
> testing. I started with a clean installed Wine upto this patch and I get
> the XError. If I go one patch back I don't see the problem.
> 
> Paul.
Ok, I'm convinced that the mentioned patch gives the X Error. But while
I was investigating the following happened:

I ran "wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall
128 wine.inf" from within the tools directory. This gives the X Error.

I did this several times after each other with the same result.

I than ran "WINEDEBUG=+ole wine rundll32.exe
setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf" and the
error is gone !?!?

The registry is now filled with all the default data.

Any ideas how to proceed ? Is there a timing issue ?

Paul.

Re: Wine threads and TRY/CATCH macros and DCE threads and TRY/CATCH macros

2005-01-20 Thread Juan Lang

Hi Luke, I don't know is this is useful, but the TRY/CATCH stuff in
particular is declared here:
http://source.winehq.org/source/include/wine/exception.h
and the Wine exception handling code is implemented here:
http://source.winehq.org/source/dlls/ntdll/exception.c

As Mike said, the Wine threading stuff is pretty complicated.  Native
applications unfortunately rely on things being exactly in the right place
in the TEB, and DCE threads are unlikely to give us this.  Peruse if you
like
http://source.winehq.org/source/include/thread.h
and
http://source.winehq.org/source/dlls/ntdll/thread.c

--Juan



__ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com

Re: Running dxdiag

Juan Lang wrote:
This isn't enough for new installers, either :(  I have an MSI-based
InstallShield installer that's looking for shdocvw.dll to see if IE6 is
installed.  (It isn't, but that's how it's looking for it.)
Trouble is, how would this work with the native/builtin thing?  Right now
all our builtins don't live in the system directory, so we can always
override whatever native dll happens to get dropped there.  If we put a
little stub PE header in there, what's to stop an installer from
overwriting it?  Or, would this cause a problem?
Well, if the little stub is overwritten by a correct native DLL then 
there is no problem at all. If some install overwrites it with an older 
version than what apps expect (or Wine provides) then that might be a 
problem, but that's just the generic DLL Hell the windows library design 
implies.

thanka -mike

Re: Running dxdiag

2005-01-20 Thread Juan Lang

Hi Mike,

> Dumping the headers is necessary for stupid installers that map DLL
files
> manually and rummage around in the headers to figure out versions and
> stuff ... simply having an empty file isn't enough for all of them I'm
> afraid :(

This isn't enough for new installers, either :(  I have an MSI-based
InstallShield installer that's looking for shdocvw.dll to see if IE6 is
installed.  (It isn't, but that's how it's looking for it.)

Trouble is, how would this work with the native/builtin thing?  Right now
all our builtins don't live in the system directory, so we can always
override whatever native dll happens to get dropped there.  If we put a
little stub PE header in there, what's to stop an installer from
overwriting it?  Or, would this cause a problem?

--Juan



__ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

Re: [LOSTWAGES] update the non-standard include files task (RESEND)

2005-01-20 Thread Rémi Assailly

Selon "Dimitrie O. Paun" <[EMAIL PROTECTED]>:

> On Thu, Jan 20, 2005 at 02:58:22PM +0900, Mike McCormack wrote:
> >
> > So did you ;)  Here's a merge of both.
>
> I don't do this on purpose, but you missed win.h again :)
> Again, with feeling...
>
> --
> Dimi.
>


win.h still exists...

Re: Font selection logic defective?

2005-01-20 Thread Bill Medland

On January 20, 2005 03:31 am, Huw D M Davies wrote:
> On Wed, Jan 19, 2005 at 05:58:59PM -0800, Bill Medland wrote:
> > On January 18, 2005 03:00 pm, Huw D M Davies wrote:
> > > On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
> > > > (Huw?)
> > > >
> > > > Do I need to dig deeper to understand this or is there a defect in
> > > > the logic. If there are ttf fonts available does that mean a poor ttf
> > > > match will be selected even when a better x11drv font is available?
> > >
> > > Yes that's right, and also intentional.  It's basically impossible to
> > > do proper font support with server side fonts, so if we have any fonts
> > > we can use on the client side then we'll do client side rendering.
> >
> > But surely in my case it's still client-side rendering; it's just that it
> > isn't the freetype that is doing it. (NB I haven't the faintest idea what
> > I am talking about, of course, not knowing much about freetype)
>
> No, when there are no TrueType fonts then Wine lets the XServer do the
> font rendering and thus uses the fonts that the XServer knows about.
> This is server-side rendering.  Unfortunately the X11 protocol doesn't
> give nearly enough control over the rendering to emulate the win32 api
> font capabilities, so we really try to use client-side font
> rendering whenever possible.
>
> > Basically what is frustrating me here is that a client's perfectly good
> > Enterprise level operating system comes with a plethora of fonts, only a
> > couple of which are ttf and our system selects from that small list
> > instead of the much larger list (which presumably freetype supports but
> > we don't) and there is no way to stop it.
>
> At some point we should add support of Type1 PostScript fonts and this
> may help.
>
> > The only option available seems to me to be to
> > install (illegally?) the appropriate Microsoft ttf fonts (e.g. Arial).
>
> If you really want the output to look like Windows then this is the
> only solution.  I suggest you read the EULA of these fonts.

No No No

I want it to look, after installing OpenOffice, the way it looked before I 
installed OpenOffice.

It works perfectly adequately for me (and for our clients, hopefully) when it 
doesn't try to use the few ttf fonts that it finds and simply falls back on 
the XServer.
However your settings for the xlldrv section didn't seem to make a difference.

>
> Huw.

-- 
Bill Medland
Programmer
ACCPAC International, Inc.
[EMAIL PROTECTED]
Corporate: www.accpac.com
Hosted Services: www.accpaconline.com

Re: Wine threads and TRY/CATCH macros and DCE threads and TRY/CATCH macros

On Thu, 20 Jan 2005 11:29:23 +, Luke Kenneth Casson Leighton wrote:
> so i was wondering if someone could point me in the direction
> of some Wine source code - testing, implementation, macros
> etc. that would allow me to vaguely confirm whether my
> suspicions are correct.

http://source.winehq.com/

If you want to experiment with this stuff the right way to do it is to
write patches. The overlap between Samba and Wine is really small so
posting stuff about RPC or the SMB protocol here isn't going to get you
very far, because we don't care much about that right now.

I'd also note that Wines threading is exceedingly complex. It won't be
rewritten anytime soon.

thanks -mike

Re: Fwd: Re: Wine builtin mscms.dll

2005-01-20 Thread Hans Leidekker

On Thursday 20 January 2005 08:04, you wrote:

> I got your name from Mike. I was wondering if you could give me a pointer or a
> hint on how to use wine's builtin mscms.dll. A simple DLL override in
> .wine/config does not seem to do the job (using wine-20041210).

Well, you have to realize that development on mscms in Wine has only been
started a couple of months ago. My estimate is that it's now about 20% done
and still missing basic functionality. And I have only weekends to spend
time on it ;( So your best bet at this time is a native mscms. 

> (It works with a native mscms.dll file copied to the windows/system 
> directory, 
> but with a specific application, makes it 5 times slower).

The 5 times slow down you're seeing is not normal. Maybe you can investigate
the problem a little more and report to the Wine development list at 
[EMAIL PROTECTED]

 -Hans

Re: [Fwd: Wine-Wiki.org]

2005-01-20 Thread Andreas Mohr

Hi,

On Thu, Jan 20, 2005 at 09:28:50AM -0500, Tom wrote:
> Hello,
> 
> *My* thoughts about this is if we link to every wiki,tool,help,whatever 
> site out there they should in return link to our Donations site/link.
> 
> This is just my opinion :-)
Wrong, since now it's not only yours anymore ;-)

Andreas Mohr

Re: [LOSTWAGES] update the non-standard include files task (RESEND)

2005-01-20 Thread Dimitrie O. Paun

On Thu, Jan 20, 2005 at 02:30:09PM +0100, Rémi Assailly wrote:
> win.h still exists...

My bad, I've misread this check-in:
http://www.winehq.org/hypermail/wine-cvs/2005/01/0463.html

-- 
Dimi.

Re: [Fwd: Wine-Wiki.org]

2005-01-20 Thread Tom

Ivan Leo Puoti wrote:
Forwarding in case someone cares about this.
Ivan.

Subject:
Wine-Wiki.org
From:
Jason Swindle <[EMAIL PROTECTED]>
Date:
Wed, 19 Jan 2005 14:10:04 -0600
To:
[EMAIL PROTECTED]
 Hello,
 Can you please add Wine-Wiki.org to the list of Compatibility site.  We have 
been growing greatly, and if it was on the site, it would help everyone.

 Thanks
 ~Jason

Hello,
*My* thoughts about this is if we link to every wiki,tool,help,whatever 
site out there they should in return link to our Donations site/link.

This is just my opinion :-)
Tom

RpcImpersonateClient (and ImpersonateNamedPipeClient)

like the ImpersonateNamedPipeClient function, it's funny - i've
_just_ being dealing with this stuff in Samba TNG:

lkcl2005/01/20 13:05:50 CET

Modified files:
source/lib msrpc-client.c
source/rpc_parse parse_creds.c
Log:
new format for smbd <-> rpc-services intercommunication
of "inherited" context.

what was previously used was a uint32 to indicate blob
length followed by a CREDS_CMD struct containing a
user_struct, which also had in it a NET_USER_INFO_3.

_now_ what is sent is a PDU with a "new" PDU number
which had to be invented, followed by a modified
CREDS_CMD struct containing an OPTIONAL user_struct
and an OPTIONAL NET_USER_INFO_3.

discussions with elrond have been over what else should
be transmitted (e.g. NT_USER_TOKEN) or transmitted
_instead_ of NET_USER_INFO_3.

also, and this is for informational purposes, there
have been discussions on the Wine mailing lists about
doing RpcImpersonateClient properly, for ReactOS and
DCOM, and what's going on here is directly relevant:
it's the data that must be passed to ReactOS, it's a
long story...

Revision ChangesPath
1.27 +44 -14tng/source/lib/msrpc-client.c
1.14 +37 -13tng/source/rpc_parse/parse_creds.c

the data flow goes something like this:

* user logs in at workstation, types password, blah blah.

* LsaLogonEx is called, which ultimately works its way down to
over-wire formats via ncacn_np:NETLOGON to contacting a PDC,
or makes its way over kerberos PAC field.

in the case of a PDC, you get a NET_USER_INFO_3 struct back.

[btw, the username in the NET_USER_INFO_3 DOES NOT have to be
the same as the username used in the first step - login!!!]

* a "security blob" is created, let's call it an NT_SEC_BLOB.
the NT_SEC_BLOB caches the NET_USER_INFO_3 info, creates
an NT_USER_TOKEN and caches that.

this is what we know to be the "credentials" for the impersonation
stuff.

* the user does something - oh, i dunno, runs USRMGR.EXE or something.

* USRMGR connects to ncacn_np:samr, which results in an SMB connection.
samba tng will receive that, and go through the whole silly
NETLOGON process again (no choice, sorry: it's one of the
reasons why MS chose to use KRB5), to store *INTERNALLY*
a NET_USER_INFO_3 set of credentials.

this is part of the "SMB authentication" - see here:

http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/smbd/sesssetup.c?rev=1.10&content-type=text/vnd.viewcvs-markup

note the use in reply_sesssetup_and_X of "password_ok()" which is
expected to receive a NET_USER_INFO_3.

* if this succeeds, then USRMGR.EXE fires off a connection to SMB IPC$
over which a "NamedPipe" connection is established.

the above cvs patch allows the NET_USER_INFO_3 structure to be
"cleanly" passed over that to the server program that is "listening" on
the "Named Pipe" on the other side - in this case, samrd.

* samrd receives the NET_USER_INFO_3 struct, and squirrels it away.

* then, if the user needs to do some "proper" stuff like adding a user
to the SAM database, then the equivalent of "RpcImpersonateClient"
must be performed - and SeAccessCheck called.

etc.

so you can see that this stuff all sort-of hangs together around doing
it vaguely correctly.

the reason for the change in format, above, of the
samba tng <-> namedpipe <-> rpc daemon "security inheritance" protocol
is because it'd be an absolute bastard to modify FreeDCE to understand
anything other than PDUs.

so instead, i am adding a "new" PDU format (embrace and extend!!!) to
FreeDCE and am extending the "state machine" in FreeDCE to cope with the
new PDU.

and _this_ new PDU would "drop" the NET_USER_INFO_3 stuff into the
rpc_context_handle, such that it could be picked up by
rpc_impersonate_client, and ta-daaa, we come back full circle.

it'll end up here:

http://cvs.sourceforge.net/viewcvs.py/freedce/freedce/include/dce/linux-gnu/sec_authn.h?rev=1.2&view=markup

which gets used _here_:

http://cvs.sourceforge.net/viewcvs.py/freedce/freedce/ncklib/include/cn.h?view=markup

which ultimately exposes it to applications via an rpc_binding_rep_t
handle, via the auth_info member.

*whew* :)

... but like i said, this is a job for ReactOS and samba tng (and samba
if the samba team wish to) and all that Wine will see is that
RpcImpersonateClient and ImpersonateNamedPipeClient will just pass
around some pointers and just ... "work".

it _does_ mean careful design because i doubt very much whether people
will be happy to have samba tng as a dependency on Wine.

once you begin to appreciate the subtleties involved, here,
i will leave it up to you to relay the requirements to the
samba team: jelmer is the best person to speak to because i have
been explaining to hi

Re: Native comctl32.dll and native commctrl.dll

2005-01-20 Thread Vitaly Lipatov

Ð ÑÐÐÐÑ ÐÑ 10 ÑÑ 2005 13:09 Dripple ÑÐÐ(a):
> Do you want me to provide a extract of a WINEDEBUG=+dll run ?
+dll or other kind debugging output for anyone who wants help with this 
program.

-- 
Vitaly Lipatov, ALT Linux Team
Russia, Saint-Petersburg, www.etersoft.ru

Re: Font selection logic defective?

2005-01-20 Thread Huw D M Davies

On Wed, Jan 19, 2005 at 05:58:59PM -0800, Bill Medland wrote:
> On January 18, 2005 03:00 pm, Huw D M Davies wrote:
> > On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
> > > (Huw?)
> > >
> > > Do I need to dig deeper to understand this or is there a defect in the
> > > logic. If there are ttf fonts available does that mean a poor ttf match
> > > will be selected even when a better x11drv font is available?
> >
> > Yes that's right, and also intentional.  It's basically impossible to
> > do proper font support with server side fonts, so if we have any fonts
> > we can use on the client side then we'll do client side rendering.
> 
> But surely in my case it's still client-side rendering; it's just that it 
> isn't the freetype that is doing it. (NB I haven't the faintest idea what I 
> am talking about, of course, not knowing much about freetype)

No, when there are no TrueType fonts then Wine lets the XServer do the
font rendering and thus uses the fonts that the XServer knows about.
This is server-side rendering.  Unfortunately the X11 protocol doesn't
give nearly enough control over the rendering to emulate the win32 api
font capabilities, so we really try to use client-side font
rendering whenever possible.

> Basically what is frustrating me here is that a client's perfectly good 
> Enterprise level operating system comes with a plethora of fonts, only a 
> couple of which are ttf and our system selects from that small list instead 
> of the much larger list (which presumably freetype supports but we don't) and 
> there is no way to stop it.

At some point we should add support of Type1 PostScript fonts and this
may help.

> The only option available seems to me to be to 
> install (illegally?) the appropriate Microsoft ttf fonts (e.g. Arial).

If you really want the output to look like Windows then this is the
only solution.  I suggest you read the EULA of these fonts.

Huw.
-- 
Huw Davies
[EMAIL PROTECTED]

Wine threads and TRY/CATCH macros and DCE threads and TRY/CATCH macros

hi,

as you may be aware, dce threads is posix draft 4 threads and FreeDCE
has an emulation library kindly made up-to-date to successfully run even
on NPTL on x86 and AMD64, courtesy of loic.

http://cvs.sourceforge.net/viewcvs.py/freedce/dcethreads/

it is my understanding / guess that microsoft, in their
adoption of DCE 1.0 some fifteen years ago for NT 3.1, ported
DCE threads to Win32 [hence, you have all those lovely TRY
CATCH RAISE macros in all the lovely MSVC++ programs, whoopeee]

so i was wondering if someone could point me in the direction
of some Wine source code - testing, implementation, macros
etc. that would allow me to vaguely confirm whether my
suspicions are correct.

the first hypothesis i want to test is this: namely, that
Wine applications would run _better_ [read, "more correctly"]
by using dcethreads than by using its present implementation
of Win32 threads.

the _other_ hypothesis i want to test is this: namely, that
FreeDCE applications would be more "palatable" in today's modern
environment if compiled with Wine's threading code!

according to loic, who is an expert on the different thread
models, the thing is that certain syscalls are not interruptable
/ cancellable in Posix Draft 4 threads and in NPTL they are.

this CHANGES the behaviour of any programs using the wrong 
threading library in subtle ways.

thus, certain applications suddenly become unreliable where they were
previously fine.

etc.

l.

p.s. i don't claim to know all the answers, nor all the questions.

-- 
--
http://lkcl.net";>http://lkcl.net
--

Re: Regression : tools/wineinstall fails with an X Error