d3ds9_xx
I have not seen any patch committed beginning the implementation of these libraries. Therefore, I was wondering which is the tree structure for these dlls that all of you propose and Alexander is willing to commit.
Re: Mono 1.2.5.1 on Wine
Kornél Pál wrote: > Hi, > > I tried to run Mono 1.2.5.1 on Wine but it dies with the "Weird VirtualQuery > result" error message. Are there any know bugs of Wine or Mono that prevent > it from running? > > I would like to make Mono run on Wine and I am willing to contribute patches > to Wine and Mono as well to achieve that. > > Use Mono 1.2.5.2. It works, but 1.2.5.1 does not. James
re: Wine Problem
Pedro Ferreira wrote: > I installed a software that talks with the informix client 2.7.0 > everything was running fine, the instalation went with minor problems. > Until now > >when i stated a connection to the informix server wine simply stops Which version of Wine? Have you tested the connection using the ilogin.exe demo that comes with the informix SDK? If you don't have it, you can download a free trial of the 2.80 SDK, that's probably close enough. The procedure for testing the connection is described here: http://www.synametrics.com/ifmxODBC.htm BTW the right mailing list for this is probably wine-users, not wine-devel. - Dan
Re: Monthcal lost focus fix
Gregor Brunmar <[EMAIL PROTECTED]> writes:
> diff --git a/dlls/comctl32/monthcal.c b/dlls/comctl32/monthcal.c
> index 8a92d42..e826612 100644
> --- a/dlls/comctl32/monthcal.c
> +++ b/dlls/comctl32/monthcal.c
> @@ -1719,11 +1719,12 @@ MONTHCAL_Paint(MONTHCAL_INFO *infoPtr, WPARAM wParam)
>
>
> static LRESULT
> -MONTHCAL_KillFocus(const MONTHCAL_INFO *infoPtr)
> +MONTHCAL_KillFocus(const MONTHCAL_INFO *infoPtr, HWND hFocusWnd)
> {
>TRACE("\n");
>
> - InvalidateRect(infoPtr->hwndSelf, NULL, TRUE);
> + if (infoPtr->hwndNotify != hFocusWnd)
> +ShowWindow(infoPtr->hwndSelf, SW_HIDE);
Is there a reason for removing the InvalidateRect completely?
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [PATCH 1/5] winealsa: Make widGetPos more accurate
Hi Alex, Alexandre Julliard schreef: > This doesn't work for me: > > ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p > winmm_test.exe.so capture.c && touch capture.ok > capture.c:73: Test failed: waveInGetPosition(0): returned 2730 bytes, should > be 0 > capture.c:84: Test failed: waveInGetPosition(0): returned 2730 samples, > should be 0 > capture.c:96: Test failed: waveInGetPosition(0): returned 341 ms, should be 0 > capture.c:108: Test failed: waveInGetPosition(0): SMPTE test failed > capture.c:119: Test failed: waveInGetPosition(0): MIDI test failed > capture.c:130: Test failed: waveInGetPosition(0): TICKS test failed > [lots more of the same] > Oops, it's a naive assumption on my side. Omit this patch, the other 4 should be fine. -Maarten
Re: [PATCH 1/5] winealsa: Make widGetPos more accurate
Maarten Lankhorst <[EMAIL PROTECTED]> writes: > --- > dlls/winealsa.drv/wavein.c |6 +- This doesn't work for me: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so capture.c && touch capture.ok capture.c:73: Test failed: waveInGetPosition(0): returned 2730 bytes, should be 0 capture.c:84: Test failed: waveInGetPosition(0): returned 2730 samples, should be 0 capture.c:96: Test failed: waveInGetPosition(0): returned 341 ms, should be 0 capture.c:108: Test failed: waveInGetPosition(0): SMPTE test failed capture.c:119: Test failed: waveInGetPosition(0): MIDI test failed capture.c:130: Test failed: waveInGetPosition(0): TICKS test failed [lots more of the same] -- Alexandre Julliard [EMAIL PROTECTED]
Re: msi 2: Reimplement MsiGetProductCode
"James Hawkins" <[EMAIL PROTECTED]> writes:
> Changelog:
> * Reimplement MsiGetProductCode.
The test fails occasionally with something like:
../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so
msi.c && touch msi.ok
msi.c:1426: Test failed: Expected {E853FAEA-A4E2-11DC-A19E-001A923592CB}, got
{E853FAAE-A4E2-11DC-A19E-001A923592CB}
msi.c:1530: Test failed: Expected {E853FAEA-A4E2-11DC-A19E-001A923592CB}, got
{E853FAAE-A4E2-11DC-A19E-001A923592CB}
make: *** [msi.ok] Error 2
--
Alexandre Julliard
[EMAIL PROTECTED]
Missing 32bit support libraries on x86_64 Debian
I just submitted this to the Debian tracker system, thought it may be useful to echo here in-case anyone else is using x86_64 Debian as it seems since Julliard put in a patch just before .42 to check more completely for dependencies it now shows that Debian (64) actually lacks certain deps for Wine. Ben H. --- Package: wine Version: All Severity: important Wine, when compiled from source (upstream source) shows that Debian is missing certain dependencies which cause loss of functionality in Wine on x86_64. These are libpng, libcups, libcapi20, libhal and openssl. This means that 32bit support packages need to be made for Debian for Wine to work properly (just like there is currently a lib32asound(-dev), etc to give ALSA support). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages wine depends on: ii debconf [debconf-2.0] 1.5.17 Debian configuration management sy pn libwine(no description available) ii xbase-clients 1:7.3+7miscellaneous X clients - metapack Versions of packages wine recommends: ii msttcorefonts 2.4Installer for Microsoft TrueType c pn wine-utils (no description available)
Re: Assorted spelling fixes.
On Fri, 7 Dec 2007, H. Verbeet wrote: > On 07/12/2007, Francois Gouget <[EMAIL PROTECTED]> wrote: > > --- a/dlls/wined3d/glsl_shader.c > > +++ b/dlls/wined3d/glsl_shader.c > > - * out. The nvidia driver only does that if the parameter is inout > > instead of out, hence the > > - * inout. > > + * out. The nvidia driver only does that if the parameter is > > in/out instead of out, hence the > > + * in/out. > I don't think that change is correct. GLSL function parameters can > have qualifiers to specify how the parameter is used. The possible > qualifiers are "in", "out" and "inout", where specifying no qualifier > is the same as specifying "in". I suppose the first "inout" could be > replaced with "in/out" without changing the meaning of the sentence > too much, but the second one is a reference to the actual qualifier. Oh, ok. I'll fix that. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ 145 = 1! + 4! + 5!
Re: (corrected) Add 18 pixel strike with japanese fonts to system.sdf Widths corrected and double checked for both strikes
On Thu, Dec 06, 2007 at 06:54:05PM +0900, Aric Stewart wrote: > I added a number of the black boxes to the 18 pixel strike (the range > before 161) and fontforge seemed unhappy if i did not add something to > the 16 pixel one. (maybe it was my misinterperting fontforge) but so i > added similar black boxes to what where already there. It was these lines that looked suspicious: -BDFChar: 351 154 4 0 2 0 8 -?smAM?smAM?iU0, -BDFChar: 352 156 4 0 2 0 8 -?smAM?smAM?iU0, +BDFChar: 351 154 4 1 2 0 8 +^qdb$^qdb$^]4?7 +BDFChar: 352 156 4 1 2 0 8 +^qdb$^qdb$^]4?7 Huw. -- Huw Davies [EMAIL PROTECTED]
Nifty new valgrind report script. New error in oleaut32. Call for volunteer(s).
I finally got tired of doing "history | grep diff" etc, and partially automated the daily valgrind run; the resulting script is at http://kegel.com/wine/valgrind/valgrind-daily.sh The results are now in directories named like http://kegel.com/wine/valgrind/logs-2007-12-06/ A summary of the new problems compared to last run are in files named like http://kegel.com/wine/valgrind/logs-2007-12-06-summary.txt And next to each individual result, there is a diff with the previous run, e.g. http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat.txt http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat-diff.txt To look at what changed since yesterday, start by looking at the day's summary file. In it, there's one line per test, followed by the changes in that test's results, if any. Lines that start with + indicate new problems (boo); lines that start with - indicate old problems that are now gone (yay!) Nearby lines that are identical except for one starting with + and one starting with - indicate a problem that moved, so ignore those. For example, in today's summary, http://kegel.com/wine/valgrind/logs-2007-12-06-summary.txt the first test with changes is in hlink: diff -u logs-2007-12-05/vg-hlink_hlink.txt logs-2007-12-06/vg-hlink_hlink.txt - Syscall param write(buf) points to uninitialised byte(s) That means the hlink test has one fewer error. Yay! The next test with changes is diff -u logs-2007-12-05/vg-ole32_moniker.txt logs-2007-12-06/vg-ole32_moniker.txt + Syscall param write(buf) points to uninitialised byte(s) - Syscall param write(buf) points to uninitialised byte(s) - Conditional jump or move depends on uninitialised value(s) The 'Syscall' error just moved, so that's not really a change. The 'Conditional' error went away, yay! The next test with changes is diff -u logs-2007-12-05/vg-oleaut32_varformat.txt logs-2007-12-06/vg-oleaut32_varformat.txt + Invalid read of size 2 That's a + with no matching -, so it's a new error, boo! Let's see if it's a real error, or just crap in the log. The first thing to check is the diff of that test's results with the last run: http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat-diff.txt It shows a fairly convincing new error: + Invalid read of size 2 +at VarFormatFromTokens (varformat.c:1888) +by VarFormat (varformat.c:2096) +by func_varformat (varformat.c:317) +by run_test (test.h:387) +by main (test.h:436) + Address 0x7F00AB01 is 15 bytes before a block of size 8 alloc'd +at RtlAllocateHeap (heap.c:1225) +by SysAllocStringByteLen (oleaut.c:357) +by VariantCopy (variant.c:722) +by VariantChangeTypeEx (variant.c:992) +by VarFormatFromTokens (varformat.c:1884) +by VarFormat (varformat.c:2096) +by func_varformat (varformat.c:317) +by run_test (test.h:387) +by main (test.h:436) Now, sometimes tests are flaky, and errors just happen to come and go, so this doesn't mean for sure it's a new error. But looking back a few days, I don't see it before. So it's probably a new error. Let's see, who's been submitting changes to oleaut32 lately?Only change in git since the last run seems to be http://www.winehq.org/pipermail/wine-cvs/2007-December/038491.html It's not clear how that patch could have caused the error offhand, but it's worth emailing the author and asking him to check, so I've cc'd him. And that's the only new error in the whole run. It's worth watching for new errors and alerting the authors, since the change is fresh in their mind, they'll probably be able to fix it quickly. Egg in the face is a dish best served warm. I'll try to keep running this script daily, but it'd be nice if somebody else took over (and possibly even increased the automation; I still have to do git pull, run the script, and upload by hand.) It doesn't help that valgrind only works well on some machines, but hey, what's life without challenges. - Dan
Mono 1.2.5.1 on Wine
Hi, I tried to run Mono 1.2.5.1 on Wine but it dies with the "Weird VirtualQuery result" error message. Are there any know bugs of Wine or Mono that prevent it from running? I would like to make Mono run on Wine and I am willing to contribute patches to Wine and Mono as well to achieve that. Kornél
Re: gdi32: Update fontsubstitutes and add ms shell dlg 2
On Fri, Dec 07, 2007 at 01:20:59PM +0100, Maarten Lankhorst wrote:
> ---
> dlls/gdi32/freetype.c | 34 ++
> 1 files changed, 18 insertions(+), 16 deletions(-)
> diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c
> index e9fb663..1542e29 100644
> --- a/dlls/gdi32/freetype.c
> +++ b/dlls/gdi32/freetype.c
> @@ -1884,83 +1884,83 @@ static const struct nls_update_font_list
> const char *oem, *fixed, *system;
> const char *courier, *serif, *small, *sserif;
> /* these are for font substitute */
> -const char *shelldlg, *tmsrmn;
> +const char *shelldlg, *shelldlg2, *tmsrmn;
> } nls_update_font_list[] =
> {
> /* Latin 1 (United States) */
> { 1252, 437, "vgaoem.fon", "vgafix.fon", "vgasys.fon",
>"coure.fon", "serife.fon", "smalle.fon", "sserife.fon",
> - "Tahoma","Times New Roman",
> + "MS Sans Serif", "Tahoma","Times New Roman",
> },
I'm fairly sure we don't want to map MS Shell Dlg to MS Sans Serif.
Which version of Windows has this mapping? Some map it to Microsoft
Sans Serif, but that's a completely different font...
Huw.
--
Huw Davies
[EMAIL PROTECTED]
Re: [2/2] msxml3: Register Missing Components
On Fri, Dec 07, 2007 at 02:07:44PM +1100, Alistair Leslie-Hughes wrote:
> diff --git a/dlls/msxml3/regsvr.c b/dlls/msxml3/regsvr.c
> index 9a0d938..1beed5b 100644
> --- a/dlls/msxml3/regsvr.c
> +++ b/dlls/msxml3/regsvr.c
> @@ -465,13 +465,13 @@ static LONG register_key_defvalueA(
> */
> static struct regsvr_coclass const coclass_list[] = {
> { &CLSID_DOMDocument,
> - "XML DOM Document",
> - NULL,
> - "msxml3.dll",
> - "Both",
> - "Microsoft.XMLDOM",
> - "1.0"
> -},
> +"XML DOM Document",
> +NULL,
> +"msxml3.dll",
> +"Both",
> +"Microsoft.XMLDOM",
> +"1.0"
> +},
There are a lot of white-space changes in this patch. Please re-submit
without them.
Thanks,
Huw.
--
Huw Davies
[EMAIL PROTECTED]
Re: d3d fill caps oddity
Am Donnerstag, 6. Dezember 2007 22:57:53 schrieb Christoph Frick: > Hi wined3d devs, > > i get this message on my notebook (Quadro 570m): > > fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex > samplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected > vertex samplers + MAX_TEXTURES(=8) > combined_samplers Ah, this is a false positive, and actually harmless. One could patch the code to not warn about this situation. See the comments in the code about why this happens. d3d9 doesn't support more than 4 vertex samplers, so even if the card supports more(a gf8 class card supports 32, due to the uniformed shader architecture), we're still fine with 8 fixed function textures and 4 vertex samplers. So you can suppress the warning by capping the supported fragment samplers at 4 in this check(e.g. max(4, gl_info->fragment samplers)). signature.asc Description: This is a digitally signed message part.
Re: Assorted spelling fixes.
On 07/12/2007, Francois Gouget <[EMAIL PROTECTED]> wrote: > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > - * out. The nvidia driver only does that if the parameter is inout > instead of out, hence the > - * inout. > + * out. The nvidia driver only does that if the parameter is in/out > instead of out, hence the > + * in/out. I don't think that change is correct. GLSL function parameters can have qualifiers to specify how the parameter is used. The possible qualifiers are "in", "out" and "inout", where specifying no qualifier is the same as specifying "in". I suppose the first "inout" could be replaced with "in/out" without changing the meaning of the sentence too much, but the second one is a reference to the actual qualifier.
Re: [1/2] msxml3: Implement IPersistStream
Alistair Leslie-Hughes wrote: > +hr = CreateStreamOnHGlobal(NULL, TRUE, &This->stream); > +if (FAILED(hr)) > +return hr You need to free This->stream somewhere. -- Rob Shearman
Re: [5/5] WineD3D: Use the disabled opengl extension string
Am Freitag, 7. Dezember 2007 10:16:51 schrieb H. Verbeet: > The clearest way to do this would probably be to simply do the > disabling in a separate loop over the disabled extensions string, > similarly to how we detect the extensions. This will only partially work because we should also filter "extensions" imported from higher opengl base versions signature.asc Description: This is a digitally signed message part.
Re: [5/5] WineD3D: Use the disabled opengl extension string
The clearest way to do this would probably be to simply do the disabling in a separate loop over the disabled extensions string, similarly to how we detect the extensions.
