Re: lostwages/templates/en status_ui.template
Hi Jacek, I don't touch the engine code! I use Gecko's embedding API. The HTML rendering will never be compatible at all, but that's not important in most cases. What we need is a compatible API, and that can be done using Gecko as HTML engine, everything else we have to implement ourself (eg. my current implementation uses Gecko to download document - that also needs to be changed). Perhaps the way forward is to get mshtml working with Gecko's embedding API, as you're doing, then switch shdocvw to use your implementation of mshtml. That will give us full control over all the relevant OLE interfaces, which are probably the things that will give us most trouble. Soon you'll see - I promise:) If you mean how much of code do we need to port to Wine tree, the answer is that no code excepting creating our headers. Everything else is in a shared library that can be loaded at runtime. My current implementation imports only 6 functions (and 3 of theme are to manipulate strings!). Everything else can be done using interfaces. Cool! Looking forward to that. Once you get it going, post what you have, and somebody can start working on shdocvw. Mike
Re: Fix for shell32.SHBrowseForFolder (proper Desktop tree + BFFM_SETSELECTION implemented)
Hi Wolfgang, On Tuesday 12 April 2005 01:03, Wolfgang Scherer wrote: Solution Fix TreeView setup behavior. Implement BFFM_SETSELECTION functionality. I've tried your patch and it breaks the SHBrowseForFolder usage in winecfg's drive mapping property sheet. I don't have time now, but will look into it soon (hopefully this evening). The last patch, which was applied to this code is http://www.winehq.org/hypermail/wine-cvs/2005/03/0017.html Would you mind to try if this one broke DVD Shrink 3.2? (patch -R) Bye, -- Michael Jung [EMAIL PROTECTED]
Re: Out-of-tree compilation and running
Hi Detlef, Thanks for looking at this, but I'm afraid I'm slightly confused by your modified version of the patch On Sunday 10 April 2005 10:46, Detlef Riekenberg wrote: 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! True, but this is the desirable effect, if I've understood correctly. If the user specifies --use-wine-tree=/some/path/to/wine, then this is where she wants to get her wine.inf file from (assuming in-tree compilation). The situation might arise if the user installs a release version of wine, but is trying out a CVS version to see if it fixes a problem. The user specifies a WINEPREFIX of ~/.wine-cvs (for example) whilst trying out the cvs version. Under these circumstances the user would want to generate the default registry using wine.inf from the CVS tree (i.e. from --use-wine-tree), and not the older values from the release wine.inf file in /usr/local (or wherever it was installed). I can't see under what circumstance a user would specify --use-wine-tree and want to use the older, installed version of wine.inf. When would this be useful? For out-of-tree compilation, the --use-source-tree option would be used in conjunction with the --use-wine-tree option, giving the correct result. So, sorry I don't see the problem here. Could you explain further? + topdir= + srcdatadir= AFAIK, this is basically a no-op unless you're up to mischief. Under normal BASH shell expansion, there isn't a difference between an unset variable and one being empty: [EMAIL PROTECTED]:~$ unset a [EMAIL PROTECTED]:~$ eval '[ ! -z $a ] echo \$a is $a' [EMAIL PROTECTED]:~$ a= eval '[ ! -z $a ] echo \$a is $a' [EMAIL PROTECTED]:~$ a=some value eval '[ ! -z $a ] echo \$a is $a' $a is some value (the evals are just to prevent the shell expanding the variable a before the initial assignment in the command line) One *can* determin if a variable is set, but to me this would come under the category of dubious activity [EMAIL PROTECTED]:~$ eval 'set|grep -q ^a= echo \$a is $a' [EMAIL PROTECTED]:~$ a= eval 'set|grep -q ^a= echo \$a is $a' $a is [EMAIL PROTECTED]:~$ a=some value eval 'set|grep -q ^a= echo \$a is $a' $a is some value # 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 Both $topdir and $srcdatadir are absolute directories, so the combination $topdir$srcdatadir doesn't make any sense. I *think* what you mean is something more like if [ -n $topdir -o -n $srcdatadir ]; then I'd have slight issues with this generally as your duplicating code. OK, its just the cp here, but its bad form and makes code more error prone. The duplication arises because of the previous issues with $datadir (which I think is a mistake). 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. OK, but this does induce the code duplication above. Perhaps, if you need to record the source-top-dir it would be better to define a $srctopdir inside the switch statement, defining $srcdatadir as $srctopdir/tools I also noticed you made some cosmetic changes to winewrapper, but included this chunk: @@ -106,7 +106,7 @@ if [ -z $WINEPREFIX -a ! -d $HOME/.wine ] then -if [ ! -z $srcdir ]; then +if [ -n $srcdir ]; then $topdir/tools/wineprefixcreate --update --use-wine-[...] else $topdir/tools/wineprefixcreate --update --use-wine-[...] (kmail line wrapping be damned!) Isn't ``[ ! -z $var ]'' equivalent to ``[ -n $var ]'' ? Sorry, lots of questions ... Paul. pgptHOIDk4pjJ.pgp Description: PGP signature
Re: Rough Draft
Le Mon, 11 Apr 2005 22:58:31 +0100, Andrew Neil Ramage a écrit : Rough Draft is a useful Windows word processor that natively saves files in .RTF format. Unfortunately, when installing it I got the following errors: fixme:richedit:RichEditANSIWndProc EM_AUTOURLDETECT: stub fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub fixme:richedit:RichEditANSIWndProc EM_LIMITTEXT: stub fixme:richedit:RichEditANSIWndProc EM_EXLIMITTEXT: stub fixme:richedit:ME_ReleaseStyle all style references freed (good!) err:menubuilder:InvokeShellLinker failed to fork and exec wineshelllink err:menubuilder:InvokeShellLinker failed to fork and exec wineshelllink fixme:msvcrt:_setmbcp Unreal codepages (e.g. -3) not implemented fixme:msvcrt:_setmbcp Unreal codepages (e.g. -3) not implemented I would say that using msvcrt from windows and telling wine to use it as native may help. Cheers Alban
Cross-building went wrong
Hi all, [yawn] One of the new tests broke winetest build (see below). Anyone have a suitable patch against mingw that adds StgCreatePropSetStg? Cheers, Paul. [EMAIL PROTECTED] tests]$ make i686-mingw32msvc-gcc marshal.o moniker.o propvariant.o stg_prop.o storage32.o testlist.o -o ole32_test.exe -loleaut32 -lole32 -luser32 -lkernel32 -lntdll -luuid stg_prop.o(.text+0xe8): In function `testProps': /home/paul/Production/wine-cross-source/dlls/ole32/tests/stg_prop.c:55: undefined reference to [EMAIL PROTECTED]' stg_prop.o(.text+0xdef):/home/paul/Production/wine-cross-source/dlls/ole32/tests/stg_prop.c:217:undefined reference to [EMAIL PROTECTED]' distcc[2034] ERROR: compile on localhost failed make: *** [ole32_test.exe] Error 1 pgps0hlIWh2cf.pgp Description: PGP signature
Re: Multimedia Control Panel question
Hey Robert, On Apr 12, 2005 7:15 AM, Robert Reif [EMAIL PROTECTED] wrote: The proper way to set the default sound card is to use the same registry keys as Windows and either use a native mmsys.cpl or devise a wine specific way of doing the same thing. Creating a builtin mmsys.cpl is one way of accomplishing this and another way is to add this capability to winecfg. You could also have winecfg launch mmsys.cfg (native or builtin). Any ideas on what would be the best way for wine? Just a single registry entry like Windows does is not going to work I think. We need at least a third to specify the sound system. We already do that but what prevents us from stop using Wine\Config and move the sound driver and sound device entries to HKCU\Software\Microsoft\Multimedia\Sound Mapper? In my mind the best solution to all of our sound device selection problems would be to have winecfg handle the frontend. And drop especially the dsound and alsa specific selection methods in the config file. Winecfg would offer the list of drivers. Each driver would detect the devices available. Winecfg would get the list of devices with waveOutGetDevCaps so we can keep device detection methods out of winecfg. Optionally we offer a text input field for those drivers where we can not discover all devices. Winecfg would then store the driver and device (ID or name?) in Multimedia\Sound Mapper. Sounds doable? Paul
Re: dib fixes
On 11 Apr 2005 17:48:58 +0200, you wrote:
Rein Klazes [EMAIL PROTECTED] writes:
I tried to do this, you need to clip to the visible region as well. I
could not get it 100% full proof because of races between the clip
calculations and the actual positions on the screen.
So I get the pixels now from the root window (clipped to the screen) and
everything is rock solid. The code is simpler too.
That's ugly, and it will fail miserably if the drawable is a bitmap,
you really have to use the specified drawable. Look at how the BitBlt
code does it to determine the proper limits.
Hmm, I was looking at BitBlt for ideas. This was the straight forward
implementation but then discarded:
static void X11DRV_DIB_SetImageBits_GetSubImage(
const X11DRV_DIB_IMAGEBITS_DESCR *descr, XImage *bmpImage)
{
/* compressed bitmaps may contain gaps in them. So make a copy
* of the existing pixels first */
RECT bmprc = { descr-xDest, descr-yDest,
descr-xDest + descr-width , descr-yDest + descr-height};
RECT rc;
GetRgnBox( descr-physDev-region, rc );
/* convert from dc to drawable origin */
OffsetRect( rc, descr-physDev-org.x, descr-physDev-org.y);
/* clip visible rect with bitmap */
if( IntersectRect( rc, rc, bmprc))
XGetSubImage( gdi_display, descr-drawable, rc.left, rc.top,
rc.right - rc.left, rc.bottom - rc.top, AllPlanes,
ZPixmap, bmpImage,
descr-xSrc + rc.left - bmprc.left,
descr-ySrc + rc.top - bmprc.top);
}
As soon as I move the window to which I am calling SetDIBitsToDevice
partly outside of the screen, the drawable lies partly outside the
screen rectangle and XGetSubImage fails - crash.
Clipping to the screen rectangle helps somewhat for very slow moves, but
with faster moves I still get those failures.
What am I doing wrong here?
Rein.
shell32/brsfolder.c
Hi Wolfgang,
@@ -400,24 +423,41 @@ static LRESULT MsgNotify(HWND hWnd, UIN
break;
lptvid=(LPTV_ITEMDATA)pnmtv-itemNew.lParam;
- if (SUCCEEDED(IShellFolder_BindToObject(lptvid-lpsfParent, lptvid-lpi,0,
(REFIID)IID_IShellFolder,(LPVOID *)lpsf2)))
- { FillTreeView( lpsf2, lptvid-lpifq, pnmtv-itemNew.hItem,lptvid-pEnumIL);
+ if ( _ILIsDesktop( lptvid-lpi ))
+ {
+ /* Always fill Desktop node without binding to object */
+ FillTreeView( lptvid-lpsfParent, lptvid-lpifq, pnmtv-itemNew.hItem,
lptvid-pEnumIL);
+ }
+ else if (SUCCEEDED(IShellFolder_BindToObject(
+ lptvid-lpsfParent, lptvid-lpifq,
^
In TV_ITEMDATA variables, lpsfParent is the IDL of the parent, lpi is the
relative IDL to the child and lpifq is the fully qualified IDL to the child.
So what you are doing here effectively is to concatenate the parent's IDL with
the fully qualified IDL. Replacing this with lptvid-lpi fixes the problem
in winecfg.
There are several occurences of _ILIsDesktop( lptvid-lpi ) in your patch,
which semantically doesn't make much sense to me, since lpi is only the
relative IDL.
Bye,
--
Michael Jung
[EMAIL PROTECTED]
[NtQuerySystemInformation #1] Fixes + tests (second round)
Hi,
this is a second go at some unit tests and related fixes for
NtQuerySystemInformation.
The ultimate goal is to get SysInternal's Process Explorer running.
I welcome suggestions and remarks. If none I will submit this to
wine-patches and start the further works.
The differences between this one and the first is that I've tried to get
the needed length regardless of the passed Length. This is how
SystemProcessInformation and some others work and how MSDN tells us it
should be implemented. I've also found that M$ doesn't always do this.
The patch after this one will add so more unit tests. For example
SystemTimeOfDayInformation will always return STATUS_SUCCESS even if the
given buffer is too small.
Cheers,
Paul Vriens.
Changelog
Start of unit tests for NtQuerySystemInformation
Return STATUS_INVALID_INFO_CLASS for non-implemented classes
Return len regardless of given Length
Return STATUS_INFO_LENGTH_MISMATCH if given length is not sufficient
Return STATUS_ACCESS_VIOLATION if no buffer given
Index: dlls/ntdll/nt.c
===
RCS file: /home/wine/wine/dlls/ntdll/nt.c,v
retrieving revision 1.75
diff -u -p -r1.75 nt.c
--- dlls/ntdll/nt.c 28 Mar 2005 10:03:57 - 1.75
+++ dlls/ntdll/nt.c 12 Apr 2005 18:06:32 -
@@ -566,6 +566,8 @@ NTSTATUS WINAPI NtQuerySystemInformation
{
NTSTATUSret = STATUS_SUCCESS;
ULONG len = 0;
+PVOID si = 0;
+int i, j;
TRACE((0x%08x,%p,0x%08lx,%p)\n,
SystemInformationClass,SystemInformation,Length,ResultLength);
@@ -574,70 +576,63 @@ NTSTATUS WINAPI NtQuerySystemInformation
{
case SystemBasicInformation:
{
-SYSTEM_BASIC_INFORMATION* sbi = (SYSTEM_BASIC_INFORMATION*)SystemInformation;
-if (Length = sizeof(*sbi))
-{
-sbi-dwUnknown1 = 0;
-sbi-uKeMaximumIncrement = 0;
-sbi-uPageSize = 1024; /* FIXME */
-sbi-uMmNumberOfPhysicalPages = 12345; /* FIXME */
-sbi-uMmLowestPhysicalPage = 0; /* FIXME */
-sbi-uMmHighestPhysicalPage = 12345; /* FIXME */
-sbi-uAllocationGranularity = 65536; /* FIXME */
-sbi-pLowestUserAddress = 0; /* FIXME */
-sbi-pMmHighestUserAddress = (void*)~0; /* FIXME */
-sbi-uKeActiveProcessors = 1; /* FIXME */
-sbi-bKeNumberProcessors = 1; /* FIXME */
-len = sizeof(*sbi);
-}
-else ret = STATUS_INFO_LENGTH_MISMATCH;
+si = RtlAllocateHeap(GetProcessHeap(), 0, sizeof(SYSTEM_BASIC_INFORMATION));
+SYSTEM_BASIC_INFORMATION* sbi = (SYSTEM_BASIC_INFORMATION*)si;
+
+sbi-dwUnknown1 = 0;
+sbi-uKeMaximumIncrement = 0;
+sbi-uPageSize = 1024; /* FIXME */
+sbi-uMmNumberOfPhysicalPages = 12345; /* FIXME */
+sbi-uMmLowestPhysicalPage = 0; /* FIXME */
+sbi-uMmHighestPhysicalPage = 12345; /* FIXME */
+sbi-uAllocationGranularity = 65536; /* FIXME */
+sbi-pLowestUserAddress = 0; /* FIXME */
+sbi-pMmHighestUserAddress = (void*)~0; /* FIXME */
+sbi-uKeActiveProcessors = 1; /* FIXME */
+sbi-bKeNumberProcessors = 1; /* FIXME */
+len = sizeof(*sbi);
}
break;
case SystemCpuInformation:
{
-SYSTEM_CPU_INFORMATION* sci;
-sci = (SYSTEM_CPU_INFORMATION *) SystemInformation;
-if (Length = sizeof(*sci))
-{
-/* FIXME: move some code from kernel/cpu.c to process this */
-sci-Architecture = PROCESSOR_ARCHITECTURE_INTEL;
-sci-Level = 6; /* 686, aka Pentium II+ */
-sci-Revision = 0;
-sci-Reserved = 0;
-sci-FeatureSet = 0x1fff;
-}
-else ret = STATUS_INFO_LENGTH_MISMATCH;
+si = RtlAllocateHeap(GetProcessHeap(), 0, sizeof(SYSTEM_CPU_INFORMATION));
+SYSTEM_CPU_INFORMATION* sci = (SYSTEM_CPU_INFORMATION*)si;
+
+/* FIXME: move some code from kernel/cpu.c to process this */
+sci-Architecture = PROCESSOR_ARCHITECTURE_INTEL;
+sci-Level = 6; /* 686, aka Pentium II+ */
+sci-Revision = 0;
+sci-Reserved = 0;
+sci-FeatureSet = 0x1fff;
+len = sizeof(*sci);
}
break;
case SystemPerformanceInformation:
{
-SYSTEM_PERFORMANCE_INFORMATION* spi = (SYSTEM_PERFORMANCE_INFORMATION*)SystemInformation;
-if (Length = sizeof(*spi))
-{
-memset(spi, 0, sizeof(*spi)); /* FIXME */
-len = sizeof(*spi);
-}
-else ret = STATUS_INFO_LENGTH_MISMATCH;
+si = RtlAllocateHeap(GetProcessHeap(), 0, sizeof(SYSTEM_PERFORMANCE_INFORMATION));
+
Mouse warp questions
Hello, I have a a question about the mouse warp code in dlls/dinput/mouse.c Why is MOUSE_HACK still defined? From reading the archives I concluded that warping the mouse in three states was disabled long ago(1), but MOUSE_HACK is still defined. I found a patch sent to wine-patches in 2003 which commented this define line(2). My problem is that this MOUSE_HACK breaks the mouse in Settlers 3, bug 2475 (3). Is there any reason why the mouse hack is still/again activated? Thanks, Stefan References: (1)http://www.winehq.org/hypermail/wine-devel/2004/06/0325.html (2)http://www.winehq.com/hypermail/wine-patches/2003/01/0019.html (3)http://bugs.winehq.org/show_bug.cgi?id=2475
Re: Move notifies around to match native
On Tue, Apr 12, 2005 at 12:24:11PM -0600, Vitaliy Margolen wrote: Also small fix for custom draw color. Native does not use colors returned from NM_CUSTOMDRAW notify. This is odd, and it deserves at the very least a comment in the code, but more preferably a unit test. -- Dimi.
Re: shell32/brsfolder.c
Hi Wolfgang,
On Tuesday 12 April 2005 22:30, you wrote:
As you might have guessed, I don't have too much knowledge about
Windows programming. All I wanted to do in the first place was getting
the DVD Shrink dialog to work ;-)
I didn't mean to bash your patch. If DVD Shrink doesn't work as on Windows
then obviously there something is not correctly implemented in wine. I'm not
that familiar with the Windows API either, but I do have two more comments on
your patch.
So in order to fix the DVD Shrink failure, only the following change is
needed:
# -8-(snip)--
@@ -100,6 +100,13 @@
ILRemoveLastID(pidlParent);
pidlChild = ILClone(ILFindLastID(root));
+/* This is needed to avoid duplication of the Desktop GUID,
+ when an empty PIDL is passed in! */
+if (_ILIsDesktop(pidlChild)) {
+ILFree( pidlChild );
+pidlChild = NULL;
+}
+
if (_ILIsDesktop(pidlParent)) {
hr = SHGetDesktopFolder(lpsfParent);
} else {
# -8-(snap)--
I still like the BFFM_SETSELECTION feature though.
You should probably split this up into two individual patches, then. This
would make it easier to find misbehaving code later on.
+{
+/* Always show selection */
+LONG_PTR dlg_style;
+dlg_style = GetWindowLongPtrW(hwndTreeView, GWL_STYLE);
+dlg_style |= TVS_SHOWSELALWAYS;
+SetWindowLongPtrW(hwndTreeView, GWL_STYLE, dlg_style );
+}
+
This probably belongs into the shell32_*.rc files (look for
SHBRSFORFOLDER_MSGBOX). Unfortunately, you have to fix it for all the
localized versions.
I (and I'm sure all of the wine folks, too) do appreciate your effort. Please
go ahead and submit to wine-patches. Alexandre will decide if it's ready for
inclusion.
Bye,
--
Michael Jung
[EMAIL PROTECTED]
Re: Cross-building went wrong
Hi Paul, Anyone have a suitable patch against mingw that adds StgCreatePropSetStg? Well, I haven't a patch, but adding the line [EMAIL PROTECTED] to w32api/lib/ole32.def ought to do it. --Juan __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re[2]: Move notifies around to match native
Tuesday, April 12, 2005, 3:09:57 PM, you wrote: On Tue, Apr 12, 2005 at 12:24:11PM -0600, Vitaliy Margolen wrote: Also small fix for custom draw color. Native does not use colors returned from NM_CUSTOMDRAW notify. This is odd, and it deserves at the very least a comment in the code, but more preferably a unit test. Well, yes and no. This is custom draw callback/notify. It shouldn't change control's parameters, such as color. At least on a permanent basis. This is what set color messages for. I have a Delphi Custom TreeView sample that has all kinds of problems. For one, the colors it is setting are not displayed correctly. Second, and mach bigger problem, it goes into endless loop. I have traced this down to SetItemT invalidating new item if anything got changed. The problem is Delphi using callbacks for both image indexes. Also I can't quite understand why TVM_GETITEM for iImage returns something like 0x4079D5D0 while traces show 0, 1 or 3 dependant on open/closed/has children. I'm working on it right now to see what could be done about it. At the very least we should distinguish what should cause screen update and what's not. Simple memcmp doesn't cut it here. So far it looks like we'll have to do something different if iImage or iSelectedImage returned as a callback. As far as conformance tests go, I'm not sure how to do it. The part I would like to test is what changes could cause TreeView node to get invalidated. Do I have to subclass TreeView to define notify message handler? if not, how to do this inside the conformance test? Vitaliy
How to format a IMediaSample?
I'm having troubles sending a media sample over the graph, I'm wondering wether that is because of the receiving filter or my own fault. the thing I'm trying to send is a uncompressed 24 bit image, the bitmap info header data of it is pretty much as this: mediatype: BI_RGB24 Width: 320 Height: 240 Bitcount: 24 Size of the image in bytes: 230400 compression: BI_RGB so my questions about it are: - What should I do with the ALLOCATOR_PROPERTIES - What do I have to put in IMediaSample SetActualDataLength - How can I fill the pointer returned by IMediaSample GetPointer so that the sample gets accepted?
Re: Move notifies around to match native
On Tue, Apr 12, 2005 at 04:13:32PM -0600, Vitaliy Margolen wrote: Well, yes and no. This is custom draw callback/notify. It shouldn't change control's parameters, such as color. At least on a permanent basis. This is what set color messages for. Agreed. But judging by what listview is doing, we do need to use them when we are drawing the item (or whatever). But I agree, we must not change those parameters permanently. Also I can't quite understand why TVM_GETITEM for iImage returns something like 0x4079D5D0 while traces show 0, 1 or 3 dependant on open/closed/has children. I guess this needs more debugging :) -- Dimi.
