Re: Out-of-tree compilation and running

[Detlef Riekenberg]

On Mi, 30.03.2005, 23:04 +0100 Paul Millar wrote in wine-patches:

> I've tested this with an in-tree and out-of-tree compilation.  Seems to work 
> OK
> for me in both cases.

I'm working at wineprefixcreate also and while looking at your Patch, i
found a race-condition when the user started wineprefixcreate:

wine.inf is searched first in "$datadir" and then in "$srcdatadir".

"$datadir" is "from the binary wine-tree" when wineprefixcreate was
called with "--use-wine-tree" but it could also come from "the installed
wine-version", when the option "--use-wine-tree" was not used. 

wine.inf could be from a different wine-version in this case!

my modifications are: 

before parsing the options:

+  topdir=""
+  srcdatadir=""

while parsing "--use-wine-tree":
- datadir="$topdir/tools"


and later: 

# Copy the .inf script and run it
if [ -n "$topdir$srcdatadir" ]
then
 for dir in "$topdir" "$srcdatadir"; do
  if [ -n "$dir" -a -e "$dir/tools/wine.inf" ]; then
cp "$dir/tools/wine.inf" "$CROOT/windows/inf/wine.inf"
break
  fi
else
cp "$datadir/wine.inf" "$CROOT/windows/inf/wine.inf"
fi
--

I moved srcdatadir one dir-level up to use the same level as "$topdir"
and to make my life more easy, because i need
"$srcdatadir/documentation/samples/config" for my patches.

Sorry, no diff here because I changed much more in my version. 
(Bug 2844 and Bug 2845).

--
by by ...
  ... Detlef

Planetside running at about 80%

[Benjamin Cutler]

After hacking away at powrprof.dll to the point where stubs exist (see
my previous post), I was able to get Planetside to launch and run to the
point where I could actually get into the game. However, the textures
were hit and miss. Some worked, but some were blanked out white. Also,
onne you got in game the UI was washed out with white and almost
unusuable. This even affected the Server/Character selection screens
(but only AFTER you'd been logged into the world).  Given that there
were quite a few fixme messages related to d3d in the logs, I imagine
this means the support isn't quite up there just yet (though it's very
impressive). The patcher, however, crashes shortly after startup (but
runs fine on Cedega 4.3), so you have to patch on Cedega at the very
least. The sound was pretty much perfect, however if the game loses
focus while in full screen mode, it won't gain mouse control when it
regains focus, unless Wine is run in desktop mode. This was all using
the CVS as of April 9, 2005, plus my powrprof patches (sent to
wine-patches earlier today), plus changing two lines in
dlls/ddraw/ddraw/user.c (User_DirectDraw_Construct) to return 96 megs of
video memory (this source file is hard-coded to return 16 megs, but
Planetside won't run unless it sees at least 32). Also, the game
triggers an exception when it quits.

http://www.cs.colostate.edu/~cutler/planetside1.jpg - Running around in
NC Sanctuary
http://www.cs.colostate.edu/~cutler/planetside2.jpg - Demonstrating
"wash out" problem on map screen

Attachment 1:
"~/Planetside/Sony/Planetside$ wine 2>planetside.training.trace
planetside.exe -off"

Offline training mode, SIGINT after loading since it won't let you quit
in the middle of training.

Attachment 2:
"~/Planetside/Sony/Planetside$ wine 2>planetside.online.trace
planetside.exe /K:"

Online mode, encrypted being the login info passed from the
patcher/launcher, encoded in some way I can't decipher.

Attachment 3:
"~/Planetside/Sony/Station$ wine 2>launcher.trace Launcher.exe
/game:planetside"

Patcher/Launcher. If the Mozilla ActiveX control is not installed, it
crashes out shortly after startup. With it installed, a Message Box with
the warning "c is not a registered protocol" pops up, and wine locks up
and requires a kill -9 to close. I suspect the error is from the ActiveX
control not handling local files without "file:///" in front, but that's
a different problem.

Other than the problems mentioned, performance was quite nice, exactly
what I'd expect out of this machine if it were running Windows. Kudos to
the Wine devs for getting it this far!
err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TT"
err:font:ReadFontDir Can't open directory "/usr/share/fonts/TT"
fixme:mmtime:timeBeginPeriod Stub; we set our timer resolution at minimum
fixme:powrprof:CallNtPowerInformation (18, (nil), 0, 0x77adf894, 76) stub!
fixme:powrprof:CallNtPowerInformation (19, (nil), 0, 0x77adf848, 76) stub!
fixme:mmtime:timeBeginPeriod Stub; we set our timer resolution at minimum
fixme:mmtime:timeEndPeriod Stub; we set our timer resolution at minimum
fixme:mmtime:timeBeginPeriod Stub; we set our timer resolution at minimum
fixme:d3d_caps:IDirect3D8Impl_FillGLCaps found GL_VERSION  ("1.5.3 NVIDIA 
71.74")->(0x00471c06)
fixme:d3d_caps:IDirect3D8Impl_FillGLCaps found GL_RENDERER ("GeForce FX 
5900XT/AGP/SSE/3DNOW!")->(0x0250)
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(40,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(128,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(129,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(130,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(131,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(132,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(133,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(134,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(135,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(156,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(161,1) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(162,-1) not 
handled yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(163,0) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(164,1065353216) 
not handled yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(165,1) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(172,3) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_SetRenderState (0x77cd7d98)->(173,1) not handled 
yet
fixme:d3d:IDirect3DDevice8Impl_GetDeviceCaps (0x77cd7d98) : stub, calling 
idirect3d for now
fixme:d3d:IDirect3DDevice8Impl_GetDeviceCaps (0x77cd7d98) : stub, c

Re: Out-of-tree compilation and running

[Dimitrie O. Paun]

On Sun, Apr 10, 2005 at 11:46:38AM +0200, Detlef Riekenberg wrote:
> Sorry, no diff here because I changed much more in my version. 

Try to separate the changes, and submit a diff. I'm afraid things
will go to /dev/null without one.

-- 
Dimi.

Re: dib.c problem, and Solution to winmm deadlocking problem

[Matthew Mastracci]

Robert Lunnon wrote:
After weeks of searching I have finally found my deadlock problem. 
Its actually not related to audio at all it's a ddraw problem with poor error handling, the surface wasn't released properly when  the error
 "Application gave us bad source rectangle for Blt." occurs
I addressed part of this bug in my latest DDRAW patch from last week 
(DDRAW: Surface locking patch, take 3 [repost]), but I missed the 
"return ret;" part of it.  doh!

@@ -959,7 +961,7 @@ error:
 release:
 IDirectDrawSurface7_Unlock(iface,NULL);
 if (src) IDirectDrawSurface7_Unlock(src,NULL);
-return DD_OK;
+return ret;
 }
I'll have to update my patch once more with this fix.
Matt.

Re: lostwages/templates/en status_ui.template

[Jacek Caban]

Log message:
Dimitrie O. Paun <[EMAIL PROTECTED] >
* Work is ongoing on richedit
* Audit of Syslink
* We've done all we can on shdocvw.dll for now

...

-   25%: implement shdocvw.dll
+   100%: We forward to Mozilla, but more work is needed 
on Mozilla for compatibility.

I completely disagree. We can do much more than there is done right now. shdocvw
is more than WebBrowser control and we can inplement those areas, but WebBrowser
needs a lot of work as well. Mozilla ActiveX Control seems not to be 
systematically
developed and the compability we need is not their aim. We need an 
implementation
of WebBrowser based on MSHTML, which will be possible when I finish my work on 
it.
This way we'll be able to implement shdocvw correctly (eg. it'll be possible to
implement Internet Explorer OLE Automation), but now it's far, far away from it
and really far from 100% complete.

LISTVIEW_SetItemState problem in FlashFXP (and other applications)

[Rolf Kalbermatter]

I was just discussing the problem with FlashFXP on Wine and did some
Google search on this.
It turned out that back in 2003 this problem was already noticed by one
of the developers
of FlashFXP and also somehow documented as follows: 

> http://forum.ru-board.com/topic.cgi?forum=5&topic=0132&start=240:
> 
>  1. FlashFXP is no longer compatible with WINE, Switching to the
OwnerData
>listview has broken compatiblity, it's unlikely that WINE will be
supported.
>WINE needs to be made more compatible with FlashFXP.
> |- After reviewing the wine source code I believe the problem is
located here
>http://source.winehq.org/source/dlls/comctl32/listview.c line 2971
& 2972
>2971 for (i = nFirst; i <= nLast; i++)
>2972 LISTVIEW_SetItemState(infoPtr,i,&item);
>The Problem: In OwnerData mode the OnData event is triggered when
the
>ItemState changes. However in the OnData event we set the item
state.
> 
>I suspect this causes an infinite loop.
> 
This probably is very close to the actual problem. Looking at current
listview.c
in CVS I see following at about this location:
 
> 2979 /* FIXME: this is not correct LVS_OWNERDATA
> 2980  * setting the item states individually will generate
> 2981  * a LVN_ITEMCHANGED notification for each one. Instead,
> 2982  * we have to send a LVN_ODSTATECHANGED notification.
> 2983  * See MSDN documentation for LVN_ITEMCHANGED.
> 2984  */
> 2985 for (i = nFirst; i <= nLast; i++)
> 2986 LISTVIEW_SetItemState(infoPtr,i,&item);

Of course there are people here much more familiar with Common Controls
than me, so
I will probably not be able to do a quick fix to this myself. Just
thought I would
point out my findings so that others can confirm or reject the probable
cause of the
endless loop in FlashFXP and other applications.

Rolf Kalbermatter

Pushing up data through the stream in quartz

[Maarten Lankhorst]

I'm trying to figure out how to do this, but I can't find anything on 
the subject.
From what I can tell, you have to make a media sample, then use 
outputpin_sendsample to deliver it,
so, how do I fill up a media sample with a single frame?
For now, just with NULL data would be sufficient..

Re: Wine msn webcam patch (Attempt 2)

[Robert Shearman]

Maarten Lankhorst wrote:
I've been trying to get msn webcam to work again, and I found out that 
WINEDEBUG=+quartz gives a crash when msn creates a pin, and then does 
some stuff with it, I can only presume some TRACE or WARNING causes 
the error, but the effect is I can't use those commands, this patch 
currently allows MSN preview screen to become gray, but it's not 
actually sending any information (not even fake images) to msn's 
webcam pin, if someone can find where exactly it crashes, it would 
help a lot, and make it a lot easier for me to actually implement a 
working webcam (Right now it will probably only work for msn 
messenger, but I can imagine other programs will work with this too in 
a future version)
This file makes changes to qcap, but they are not needed for the 
process as far as I know

Hi Maarten,
Thanks for your work on devenum,quartz and qcap. I have some comments in 
addition to the ones Mike has already made.

diff -Nru wine-old/dlls/devenum/createdevenum.c 
wine-new/dlls/devenum/createdevenum.c
--- wine-old/dlls/devenum/createdevenum.c   2005-01-25 11:56:39.0 
+0100
+++ wine-new/dlls/devenum/createdevenum.c   2005-04-09 16:10:47.0 
+0200
@@ -117,6 +117,7 @@
if (IsEqualGUID(clsidDeviceClass, &CLSID_AudioRendererCategory) ||
IsEqualGUID(clsidDeviceClass, &CLSID_AudioInputDeviceCategory) ||
+IsEqualGUID(clsidDeviceClass, &CLSID_VideoInputDeviceCategory) ||
IsEqualGUID(clsidDeviceClass, &CLSID_MidiRendererCategory))
{
hbasekey = HKEY_CURRENT_USER;
@@ -142,6 +143,7 @@
{
if (IsEqualGUID(clsidDeviceClass, &CLSID_AudioRendererCategory) ||
IsEqualGUID(clsidDeviceClass, &CLSID_AudioInputDeviceCategory) ||
+IsEqualGUID(clsidDeviceClass, &CLSID_VideoInputDeviceCategory) ||
IsEqualGUID(clsidDeviceClass, &CLSID_MidiRendererCategory))
{
 HRESULT hr = DEVENUM_CreateSpecialCategories();
@@ -413,6 +415,7 @@
CoTaskMemFree(pTypes);
	}
	}
+res = DEVENUM_CreateAMCategoryKey(&CLSID_VideoInputDeviceCategory);
 

I'm not sure these changes are correct. If you go down the same route as 
done for the MIDI, wave in and wave out devices then you have to 
enumerate the video input devices and create keys for them here, but 
there is no clean way of doing this.

pMapper = (IFilterMapper2*)mapvptr;
-IFilterMapper2_CreateCategory(pMapper, &CLSID_VideoInputDeviceCategory, MERIT_DO_NOT_USE, friendlyvidcap);
+IFilterMapper2_CreateCategory(pMapper, &CLSID_VideoInputDeviceCategory, MERIT_NORMAL, friendlyvidcap);
IFilterMapper2_CreateCategory(pMapper, &CLSID_LegacyAmFilterCategory, MERIT_NORMAL, friendlydshow);
IFilterMapper2_CreateCategory(pMapper, &CLSID_VideoCompressorCategory, MERIT_DO_NOT_USE, friendlyvidcomp);
IFilterMapper2_CreateCategory(pMapper, &CLSID_AudioInputDeviceCategory, MERIT_DO_NOT_USE, friendlyaudcap);
 

This change is wrong. The video input category is MERIT_DO_NOT_USE on 
both my Win2k and WinXP systems (tested with a webcam on the WinXP 
system too). This makes sense because you don't want capture devices to 
be automatically included in a filter graph to satisfy some requirement 
of some filter. If the MSN webcam won't work without this change then 
there is a bug elsewhere.

+/* AMStreamConfig interface, we only need to implement {G,S}etFormat */
+static HRESULT WINAPI AMStreamConfig_QueryInterface(IAMStreamConfig * iface, REFIID riid, LPVOID * ppv)
+{
+   FIXME("%p: stub, not worth the effort\n", iface);
+   return S_OK;
+}
 

I'll implement it for you:
{
   if (IsEqualIID(riid, &IID_IUnknown) ||
   IsEqualIID(riid, &IID_IAMStreamConfig))
   {
   *ppv = (LPVOID)iface;
   return S_OK;
   }
   FIXME("No interface for iid %s\n", debugstr_guid(riid));
   return E_NOINTERFACE;
}
+
+static ULONG WINAPI AMStreamConfig_AddRef(IAMStreamConfig * iface)
+{
+   FIXME("%p: stub, not worth the effort\n", iface);
+   return 1;
+}
 

Again, you should implement this:
return InterlockedIncrement(&This->refs);
+
+static ULONG WINAPI AMStreamConfig_Release(IAMStreamConfig * iface)
+{
+   FIXME("%p: stub, not worth the effort\n", iface);
+   return 1;
+}
+
 

You should implement this too.
+static HRESULT WINAPI AMStreamConfig_SetFormat(IAMStreamConfig *iface,
+  AM_MEDIA_TYPE *pmt) {
+   ERR("%p: %p stub !!\n", iface, pmt);
+   return E_NOTIMPL;
+}
 

Use FIXME instead of ERR.
+
+static HRESULT WINAPI AMStreamConfig_GetFormat(IAMStreamConfig *iface,
+  AM_MEDIA_TYPE **pmt) {
+   ERR("%p: %p stub !!\n", iface, pmt);
+   // FIXME: The stuff below is just there so it contains something
 

Again, use FIXME. Don't use C99 comments. Use /* comment */ instead.
+
+   VIDEOINFOHEADER *pvi;
+
+   pmt[0] = CoTaskMemAlloc(sizeof (AM_MEDIA_TYPE));
+   memcpy (&pmt[0]->formattype, &FORMAT_VideoInfo, sizeof (GUID));
+   mem

Re: Pushing up data through the stream in quartz

[Robert Shearman]

Maarten Lankhorst wrote:
I'm trying to figure out how to do this, but I can't find anything on 
the subject.
From what I can tell, you have to make a media sample, then use 
outputpin_sendsample to deliver it,
so, how do I fill up a media sample with a single frame?

A sample *is* a single frame, so there is no special case. For code that 
does this, please see dlls/quartz/acmwrapper.c.
The general pattern is:
1. Get a blank available sample (OutputPin_GetDeliveryBuffer).
2. Set the size of the data represented by the sample 
(IMediaSample_SetActualDataLength)
3. Get a pointer to the sample buffer (IMediaSample_GetPointer)
4. Fill with data (memcpy).
5. Send the sample to the downstream filter (OutputPin_SendSample).

For now, just with NULL data would be sufficient..

Replace the above mentioned memcpy call with a memset instead then.
Rob

Re: real SetProcessClass and SetThreadPriority support

[Robert Shearman]

Mike Hearn wrote:
On Fri, 08 Apr 2005 13:29:56 -0500, Robert Shearman wrote:
 

2. setuid binaries make
sysadmins nervous and would require a security audit by us. Yes, they
don't need to make it setuid, but then the people who do could run their
programs as root anyway. 
   

Presumably only the code up until the point at which we drop privs needs
to be audited though. Suid root binaries that drop privs are pretty common.
 

You're forgetting the reason why we need the suid root binary - because 
allowing processes to set their priority as realtime (or otherwise very 
high) leaves the system open to a trvial DoS attack. Not only do the 
startup code paths need to be audited, but also the priority setting 
logic too.

Rob

Re: LISTVIEW_SetItemState problem in FlashFXP (and other applications)

[Dimitrie O. Paun]

On Sun, Apr 10, 2005 at 09:06:37PM +0200, Rolf Kalbermatter wrote:
> Of course there are people here much more familiar with Common Controls
> than me, so I will probably not be able to do a quick fix to this myself. 

Good find! Can you test this patch?


Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.406
diff -u -p -r1.406 listview.c
--- dlls/comctl32/listview.c25 Mar 2005 20:49:00 -  1.406
+++ dlls/comctl32/listview.c11 Apr 2005 02:37:26 -
@@ -2967,22 +2965,35 @@ static void LISTVIEW_AddGroupSelection(L
 {
 INT nFirst = min(infoPtr->nSelectionMark, nItem);
 INT nLast = max(infoPtr->nSelectionMark, nItem);
-INT i;
+NMLVODSTATECHANGE nmlv;
 LVITEMW item;
+BOOL bOldChange;
+INT i;
+
+/* Temporarily disable change notification
+ * If the control is LVS_OWNERDATA, we need to send
+ * only one LVN_ODSTATECHANGED notification.
+ * See MSDN documentation for LVN_ITEMCHANGED.
+ */
+bOldChange = infoPtr->bDoChangeNotify;
+if (infoPtr->dwStyle & LVS_OWNERDATA) infoPtr->bDoChangeNotify = FALSE;
 
 if (nFirst == -1) nFirst = nItem;
 
 item.state = LVIS_SELECTED;
 item.stateMask = LVIS_SELECTED;
 
-/* FIXME: this is not correct LVS_OWNERDATA
- * setting the item states individually will generate
- * a LVN_ITEMCHANGED notification for each one. Instead,
- * we have to send a LVN_ODSTATECHANGED notification.
- * See MSDN documentation for LVN_ITEMCHANGED.
- */
 for (i = nFirst; i <= nLast; i++)
LISTVIEW_SetItemState(infoPtr,i,&item);
+
+ZeroMemory(&nmlv, sizeof(nmlv));
+nmlv.iFrom = nFirst;
+nmlv.iTo = nLast;
+nmlv.uNewState = 0;
+nmlv.uOldState = item.state;
+
+notify_hdr(infoPtr, LVN_ODSTATECHANGED, (LPNMHDR)&nmlv);
+infoPtr->bDoChangeNotify = bOldChange;
 }
 
 

-- 
Dimi.