Re: dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...

[Ferenc Wagner]

Robert Reif <[EMAIL PROTECTED]> writes:

>> Winetest has a "runningunderwine" report option. Running
>> it under Wine will be supported.
>
> winetest results from wine are not accepted by the website.

Yes they are.  Just make dist.

> To be really useful as a developer tool, you would need wine
> specific information like the os/distribution version, sound library
> type and version and the wine version (with cvs patch info if
> not a standard release).

CVS revision numbers are available, but nothing else you ask
for.  If you send me some blobs of code to detect what you
need, I'm willing to help integrate it, provided it also
runs under Windows.
-- 
Feri.

Re: Resend: Re-implement MSVCRT *printf functions

[Alexandre Julliard]

Aneurin Price <[EMAIL PROTECTED]> writes:

> Any further comments on this?

Hard to say, that code is really painful to read. Please try to better
follow the coding conventions used in the rest of the code.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: Resend: Re-implement MSVCRT *printf functions

[Aneurin Price]

Any further comments on this?

Re: registry test incorrect for xp

[James Hawkins]

I am sorry, these errors are coming from the fact that some tests are
failing in shlwapi and leaving extraneous keys in Wine\Test. 
advapi32\registry is in fact correct, so I will be looking into the
errors of shlwapi to see what is happening.


On Mon, 8 Nov 2004 02:54:32 -0500, James Hawkins <[EMAIL PROTECTED]> wrote:
> I just completed building the wine conformance tests with Visual
> Studio .NET.  When I ran the advapi32/security tests, there were 28
> failures (compiled and tested on XP).  The first error I looked at is:
> 
> registry.c:93: Test failed: data_count set to 24 instead of 7
> 
> Looking at registry.c, this test calls RegEnumValue with an output
> data buffer that is too small,
> 
> LONG RegEnumValue(
>   HKEY hKey,
>   DWORD dwIndex,
>   LPTSTR lpValueName,
>   LPDWORD lpcValueName,
>   LPDWORD lpReserved,
>   LPDWORD lpType,
>   LPBYTE lpData,
>   LPDWORD lpcbData
> );
> 
> so the lpcbData should contain the required size of the buffer on
> return.  hKey is initialized to HKCU\Software\Wine\Test and dwIndex is
> 0, so we're reading this:
> 
> Name: Test1
> Type: REG_EXPAND_SZ
> Data: %LONGSYSTEMVAR%\subdir1
> 
> The current test expects RegEnumValue to expand the environment
> variable %LONGSYSTEMVAR%, leaving nothing since the variable doesn't
> exist.  If this were the case then lpcbData would return the length of
> 'subdir1' which is 7, which is what the test expects, but testing
> shows that even though the type is REG_EXPAND_SZ, RegEnumValue does
> not expand the environment variable, so lpcbData contains the length
> of %LONGSYSTEMVAR%\subdir1 which is 24, and which is what is returned
> when called with XP.  This is further clarified by msdn docs,
> 
> "Your application should call ExpandEnvironmentStrings before
> attempting to read the value of a REG_EXPAND_SZ registry data type."
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/apcompat/apcompat/call_expandenvironmentstrings_before_reading_reg_expand_sz.asp
> 
> While it never says that RegEnumValue doesn't expand REG_EXPAND_SZ,
> this evidence shows that this is the case.  If anyone has any thoughts
> on this, please let me know.  Otherwise I will be sending a patch that
> fixes this test and then checking the test in wine to see if our
> RegEnumValue needs to be fixed as well.
> 
> --
> James Hawkins
> 


-- 
James Hawkins

Re: Toolbar: Cleanup Patch

[Robert Shearman]

Dimitrie O. Paun wrote:
On Mon, Nov 08, 2004 at 11:27:44AM -0600, Robert Shearman wrote:
 

Changelog:
- bNtfUnicode is a dup' of bUnicode so remove it and fix the few places 
where it was used.
   

bUnicode is a bad name for this flag, bNtfUnicode would be better,
as bUnicode is sometimes use to denote how the text is stored in
the control, which is different from how notifications should be
sent.
What does the "Ntf" part of it mean? It is not immediately obvious. 
Please show me which controls are storing the text internally in two 
different formats as that should be fixed.
However, I will submit a change in a later patch that clarifies the 
comment for the bUnicode flag.

Rob

Re: 150 test failures. advapi32 test crashes.

[Hans Leidekker]

On Monday 8 November 2004 17:11, Dan Kegel wrote:

> > What do your $TMP and $TEMP look like?
> 
> In the Unix shell before I start wine, they are
> both unset.

I was asking because the path test uses GetTempPath which looks at
$TMP and $TEMP. My $TMP and $TEMP are unset as well and I don't have
a t: drive, but I can't reproduce your problem.

 -Hans

Re: signaling unix threads

[Alexandre Julliard]

Mike Hearn <[EMAIL PROTECTED]> writes:

> I quite liked Michaels idea of the RT signals. Is there some reason we
> can't use them?

Portability, plus we don't really want queued behavior anyway.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...

[Alexandre Julliard]

Robert Reif <[EMAIL PROTECTED]> writes:

> Isn't the point of winetest just to do a sanity check on the wine
> regression
> tests to make sure they are correct and valid.  You don't need a 100%
> pass rate to prove that the tests are valid as long as you understand the
> reason for failure.

You absolutely need a 100% pass rate, otherwise the tests are
meaningless. If we know why a test fails, that knowledge should be
stored in the code by making the test deal with that case properly
instead of reporting a failure.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: Fix DLL loader regression

[Alexandre Julliard]

Mike Hearn <[EMAIL PROTECTED]> writes:

> Any problem with this one Alexandre?

It needs to be integrated in the normal code flow, there's no reason
to do the RtlDosPathNameToNtPathName twice.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: Toolbar: Cleanup Patch

[Dimitrie O. Paun]

On Mon, Nov 08, 2004 at 11:27:44AM -0600, Robert Shearman wrote:
> Changelog:
> - bNtfUnicode is a dup' of bUnicode so remove it and fix the few places 
> where it was used.

bUnicode is a bad name for this flag, bNtfUnicode would be better,
as bUnicode is sometimes use to denote how the text is stored in
the control, which is different from how notifications should be
sent.

-- 
Dimi.

Re: 150 test failures. advapi32 test crashes.

[Dan Kegel]

Hans Leidekker wrote:
On Monday 8 November 2004 14:20, Dan Kegel wrote:

The path failures are all due to t: not existing; when I create
it by hand, those 397 errors go away.
It sounds very much like the startup code that creates c: and z: needs
to also create a t: drive!

What do your $TMP and $TEMP look like?
In the Unix shell before I start wine, they are
both unset.
- Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: 150 test failures. advapi32 test crashes.

[Hans Leidekker]

On Monday 8 November 2004 14:20, Dan Kegel wrote:

> The path failures are all due to t: not existing; when I create
> it by hand, those 397 errors go away.
> It sounds very much like the startup code that creates c: and z: needs
> to also create a t: drive!

What do your $TMP and $TEMP look like?

 -Hans

Re: dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...

[Robert Reif]

Winetest has a "runningunderwine" report option. Running it under Wine 
will be
supported.

winetest results from wine are not accepted by the website.
To be really useful as a developer tool, you would need wine
specific information like the os/distribution version, sound library
type and version and the wine version (with cvs patch info if
not a standard release).

Re: Miscellaneous UI Fixes

[Duane Clark]

William Poetra Yoga H wrote:
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:

On Sat, Nov 06, 2004 at 10:14:36PM -0800, William Poetra Yoga H wrote:
Reasons for sending the patch:
1. all at once: the patches are a group of related fixes (as said in the
website).
2. one file per message: I don't know :-P
3. one file per item: it's one fix per patch (as said in the website)
3, as documented on the website, is the preferred method. Otherwise,
we wouldn't have documented it as such :)
--
Dimi.
You mean 5 mails with one patch each? Or one mail with 5 diff files?
Just to be clarify a bit more, a "patch" fixes one thing, or several 
closely related things. A patch can contain changes to multiple files, 
when multiple files need to be changed to fix something. After applying 
a single patch, Wine should be able to be recompiled and run, presumably 
with whatever was being fixed now working.

In the case of your original email, where there is one attachment for 
menu size and one for nonclient size, they probably should be sent in 
separate patches/emails.

Re: Scrollbars

[Robert Shearman]

Nicolai Kuntze wrote:
Hi,
I have played with my continuing bug (#2302) but I have some problems 
understanding the meaning of the output:

fixme:win:GetWindowModuleFileNameA GetWindowModuleFileNameA(hwnd 
0x40032, lpszFileName 0x40670548, cchFileNameMax 80) stub!
trace:scroll:SetScrollInfo hwnd=0x10074 nBar=1 info=0x406715d4, bRedraw=1
trace:scroll:SCROLL_SetScrollInfo hwnd=0x10074 bar=1 mask=4 pos=1
trace:scroll:SCROLL_SetScrollInfo curVal=0 nPos=1
trace:scroll:SCROLL_SetScrollInfo new values: page=1 pos=0 min=0 max=0
trace:scroll:SCROLL_SetScrollInfo hide or disable
trace:scroll:SCROLL_ShowScrollBar hwnd=0x10074 bar=1 horz=0, vert=0
trace:scroll:SetScrollInfo hwnd=0x10074 nBar=1 info=0x406715d4, bRedraw=1
trace:scroll:SCROLL_SetScrollInfo hwnd=0x10074 bar=1 mask=4 pos=2
trace:scroll:SCROLL_SetScrollInfo curVal=0 nPos=2
trace:scroll:SCROLL_SetScrollInfo new values: page=1 pos=0 min=0 max=0
trace:scroll:SCROLL_SetScrollInfo hide or disable
trace:scroll:SCROLL_ShowScrollBar hwnd=0x10074 bar=1 horz=0, vert=0
trace:scroll:SetScrollInfo hwnd=0x10074 nBar=1 info=0x406715d4, bRedraw=1
trace:scroll:SCROLL_SetScrollInfo hwnd=0x10074 bar=1 mask=4 pos=3
trace:scroll:SCROLL_SetScrollInfo curVal=0 nPos=3
trace:scroll:SCROLL_SetScrollInfo new values: page=1 pos=0 min=0 max=0
trace:scroll:SCROLL_SetScrollInfo hide or disable
trace:scroll:SCROLL_ShowScrollBar hwnd=0x10074 bar=1 horz=0, vert=0

If my blue bar in the list disappears pos Value counts how many lines 
under the window I am. I have added a little debug to follow the 
source ... From the developer I got the following snipplet:

int SViewLow::ViewSetScrollY( int PPos, int PMax, int PPage)
{
SCROLLINFO Scroll;
memset( &Scroll, 0, sizeof( Scroll));
Scroll.cbSize= sizeof( SCROLLINFO);
Scroll.fMask= 0;
if (PPos!=-1)
Scroll.fMask|= SIF_POS;
if (PMax!=-1)
Scroll.fMask|= SIF_RANGE;
if (PPage!=-1)
Scroll.fMask|= SIF_PAGE;
Scroll.nPos= PPos;
Scroll.nPage= PPage;
Scroll.nMax= PMax-1;
return SetScrollInfo( (HWND)ViewGetHWND(), SB_VERT, &Scroll, TRUE);
}
Does anyone has an idea what this could be?

You need to figure out why PMax is being passed in as 1, hence making 
the range 0->0. SetScrollInfo is then correctly hiding the scrollbars.

Rob

Re: dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...

[Jakob Eriksson]

Robert Reif wrote:

Removing the test so it passes on a Windows system with a real bug is
not the right thing to do for a wine regression test.  The test is 
there to
find bugs and that's what it did.


How about this?

regards,
Jakob
Index: dlls/winmm/tests/capture.c
===
RCS file: /home/wine/wine/dlls/winmm/tests/capture.c,v
retrieving revision 1.15
diff -u -r1.15 capture.c
--- dlls/winmm/tests/capture.c  3 Nov 2004 22:13:44 -   1.15
+++ dlls/winmm/tests/capture.c  8 Nov 2004 10:41:42 -
@@ -352,26 +352,32 @@
 }
 
 /* Testing invalid format: 2 MHz sample rate */
-format.wFormatTag=WAVE_FORMAT_PCM;
-format.nChannels=2;
-format.wBitsPerSample=16;
-format.nSamplesPerSec=200;
-format.nBlockAlign=format.nChannels*format.wBitsPerSample/8;
-format.nAvgBytesPerSec=format.nSamplesPerSec*format.nBlockAlign;
-format.cbSize=0;
-oformat=format;
-rc=waveInOpen(&win,device,&format,0,0,CALLBACK_NULL|WAVE_FORMAT_DIRECT);
-ok(rc==WAVERR_BADFORMAT || rc==MMSYSERR_INVALFLAG ||
-   rc==MMSYSERR_INVALPARAM,
-   "waveInOpen(%s): opening the device with 2 MHz sample rate should fail: 
"
-   " rc=%s\n",dev_name(device),wave_in_error(rc));
-if (rc==MMSYSERR_NOERROR) {
-trace(" got %ldx%2dx%d for %ldx%2dx%d\n",
-  format.nSamplesPerSec, format.wBitsPerSample,
-  format.nChannels,
-  oformat.nSamplesPerSec, oformat.wBitsPerSample,
-  oformat.nChannels);
-waveInClose(win);
+if (strcmp("Avance AC'97 Audio", capsA.szPname) ||
+(capsA.vDriverVersion >> 8) != 5 ||
+(capsA.vDriverVersion & 0xff) != 0) {
+format.wFormatTag=WAVE_FORMAT_PCM;
+format.nChannels=2;
+format.wBitsPerSample=16;
+format.nSamplesPerSec=200;
+format.nBlockAlign=format.nChannels*format.wBitsPerSample/8;
+format.nAvgBytesPerSec=format.nSamplesPerSec*format.nBlockAlign;
+format.cbSize=0;
+oformat=format;
+
rc=waveInOpen(&win,device,&format,0,0,CALLBACK_NULL|WAVE_FORMAT_DIRECT);
+ok(rc==WAVERR_BADFORMAT || rc==MMSYSERR_INVALFLAG ||
+   rc==MMSYSERR_INVALPARAM,
+   "waveInOpen(%s): opening the device with 2 MHz sample rate should 
fail: "
+   " rc=%s\n",dev_name(device),wave_in_error(rc));
+if (rc==MMSYSERR_NOERROR) {
+trace(" got %ldx%2dx%d for %ldx%2dx%d\n",
+  format.nSamplesPerSec, format.wBitsPerSample,
+  format.nChannels,
+  oformat.nSamplesPerSec, oformat.wBitsPerSample,
+  oformat.nChannels);
+waveInClose(win);
+}
+} else {
+trace("This Windows driver is buggy. Not testing invalid sample 
rate.\n");
 }
 
 /* test non PCM formats */

Re: 150 test failures. advapi32 test crashes.

[Michael Jung]

On Monday 08 November 2004 16:47, you wrote:
> --- Michael Jung <[EMAIL PROTECTED]> wrote:
> > Yes, it is. I would even opt for removing this fixme (or changing it
> > to a
> > trace) and let the VerifyImage function always return TRUE.
> > Implementing it
> > in a sensible way would be a large effort, which would not buy us any
>
> This would be really nice as I think this is what causes the .NET
> runtime to fail to install. When installing the free Microsoft C
> Compiler it bombs because it tries to install the .Net runtime and it
> looks like it gets all the way to the end of the install and then I see
> this message. I assume its doing some kind of hash check on the package
> and if it fails then its rolling the MSI package back.

Sorry for being imprecise, but VerifyImage does already always return TRUE. I 
just meant that we should get rid of the FIXME (And that we thereby 
implicitly have a consensus that this feature will never be implemented, 
because its of no value).

Re: dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...

[Jakob Eriksson]

Robert Reif wrote:

Removing the test so it passes on a Windows system with a real bug is
not the right thing to do for a wine regression test.  The test is 
there to
find bugs and that's what it did.

So, a driver blacklist is in order then?
regards,
Jakob Eriksson

Re: 150 test failures. advapi32 test crashes.

[Michael Stefaniuc]

On Mon, Nov 08, 2004 at 04:41:59AM -0800, Dan Kegel wrote:
> Michael Jung wrote:
> >I fear that the problems with crypt.c and the crash are related to 
> >rsaenh.dll, which is pretty new in wine cvs. I can't reconstruct the test 
> >failures on my system. There are some entries in the initial registry, 
> >which did change due to rsaenh.dll. Could please retry without an existent 
> >.wine directory? 
> 
> Done.  (I even rebooted with nosmp.)  That seems to have helped the crypt 
> test;
Well, the test passes on my desktop at home (FC2 with 2.6.9 Linus kernel
with SMP (HT)) but fails on my RHEL3-U3 (up2date) laptop with UP kernel.

> now I just get
> ../../../../wine/tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p 
> rsaenh_test.exe.so ../../../../wine/dlls/rsaenh/tests/rsaenh.c && touch 
> rsaenh.ok
> fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200f90): not verifying image
> fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200fb0): not verifying image
> fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40202598): not verifying image
> 
> which is benign, right?
> 
> Unfortunately, it uncovered some other problems, which I'll post
> about separately.
On the laptop i get the typelib errors (missing DCOM9x) and capture and
wave errors (sound related). Rest works like a charm (ok, i manualy
create the t: drive just in case).

bye
michael
-- 
Michael Stefaniuc   Tel.: +49-711-96437-199
System Administration   Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart


pgpm5Nhz1YGIH.pgp
Description: PGP signature

Re: Re: Winetest questions

[Chris Morgan]

> On Sun, Nov 07, 2004 at 02:01:13PM -0800, Dan Kegel wrote:
> > 1. Why are all the archived posts to wine-test-results empty?
> > See http://www.winehq.org/hypermail/wine-tests-results/2004/11
> > Every message body is empty!  What's up with that?
> 
> That's a good question. Chris, what's going on?
> 

I suspect these are clients that have issues connecting to the net to upgrade 
their version of winrash since there are relatively few error reports compared 
to the number of test result submissions.  We should really have the script 
ignore empty requests like this as they don't tell us anything and simply spam 
the mailing list every day.

Chris

Re: dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...

[Jakob Eriksson]

Robert Reif wrote:
Jakob Eriksson wrote:
Robert Reif wrote:

Removing the test so it passes on a Windows system with a real bug is
not the right thing to do for a wine regression test.  The test is 
there to
find bugs and that's what it did.

So, a driver blacklist is in order then?
regards,
Jakob Eriksson

Isn't the point of winetest just to do a sanity check on the wine 
regression
tests to make sure they are correct and valid.  You don't need a 100%
pass rate to prove that the tests are valid as long as you understand the
reason for failure.  Putting a windows driver blacklist in a wine 
regression
test just doesn't seem right.

Maybe not, but seeing red enttries in the HTML report doesn't seem right 
either.
And why should anyone reading these logs have to remember which driver
was or wasn't broken...?


I would rather see effort spent worrying about bugs in wine sound drivers
rather than bugs in windows drivers.  But then, winetest isn't meant 
to be
run on wine which is a shame because it would be ideal for identifying
which wine hardware/os/library versions are causing problems.

Winetest has a "runningunderwine" report option. Running it under Wine 
will be
supported.


regards,
Jakob Eriksson

Re: 150 test failures. advapi32 test crashes.

[Steven Edwards]

--- Michael Jung <[EMAIL PROTECTED]> wrote:
> Yes, it is. I would even opt for removing this fixme (or changing it
> to a 
> trace) and let the VerifyImage function always return TRUE.
> Implementing it 
> in a sensible way would be a large effort, which would not buy us any

This would be really nice as I think this is what causes the .NET
runtime to fail to install. When installing the free Microsoft C
Compiler it bombs because it tries to install the .Net runtime and it
looks like it gets all the way to the end of the install and then I see
this message. I assume its doing some kind of hash check on the package
and if it fails then its rolling the MSI package back.

Thanks
Steven



__ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

Re: 150 test failures. advapi32 test crashes.

[Dan Kegel]

Dan Kegel wrote:
I pulled down sources from CVS this morning, and tried
running the regression tests.  There are about 150 failures.
>$ grep "Test failed" log | sed 's/:.*//' | uniq -c | sort
>   1 filtergraph.c
>   1 rsaenh.c
>   1 shelllink.c
>   1 shreg.c
>   2 typelib.c
>   4 capture.c
>   4 wave.c
>   6 dsound8.c
>   6 dsound.c
>   7 vartype.c
>   8 path.c
>  15 crypt.c
>  43 metafile.c
>  51 shellpath.c
Thanks to suggestions from Dmitry Timoshkov, Michael Jung, and Michael 
Stefaniuc,
I'm down to only 66 or so unexplained failures now.
I also discovered a bug in GetTempFileName.
Details:
I rebooted into single-processor mode out of paranoia,
wiped my .wine directory, and reran.  Here's the new summary:
  2 typelib.c
397 path.c
 43 metafile.c
 45 shellpath.c
  4 capture.c
  4 wave.c
  6 dsound8.c
  7 vartype.c
So that fixed the dsound, filtergraph, rsaenh, shelllink, shreg, and crypt 
problems
(guess stale registries are pretty dangerous; we do seem to need versioning...).
The typelib failures are, according to the test failure message,
due to the lack of a copy of stdole32.tlb.
The metafile failures were all due to having no TrueType fonts installed.
Downloading and running
http://prdownloads.sourceforge.net/corefonts/courie32.exe
fixed them.
The path failures are all due to t: not existing; when I create
it by hand, those 397 errors go away.
It sounds very much like the startup code that creates c: and z: needs
to also create a t: drive!
I'll look at the rest of the failures later.  I did notice a new bug, though:
GetTempFileName doesn't fail if T: doesn't exist!  Here's the evidence:
The first reported error in path is
path.c:355: Test failed: Couldn't delete the temporary file we just created
but, looking at the output of +all, I see the real first problem is
not caught:
0009: create_file( access=4000, inherit=0, sharing=, create=2, 
options=0050, attrs=0080, 
filename="/home/dank/.wine/dosdevices/t:/pat4e0.tmp" )
0009: create_file() = NO_SUCH_FILE { handle=(nil) }
0009:trace:heap:RtlFreeHeap (0x401f,0002,40200bd8): returning TRUE
0009:Ret  ntdll.NtCreateFile() retval=c00f ret=40356581
0009:warn:file:CreateFileW Unable to create file L"T:\\pat4e0.tmp" (status 
c00f)
0009:Call ntdll.RtlNtStatusToDosError(c00f) ret=403565f5
0009:Ret  ntdll.RtlNtStatusToDosError() retval=0002 ret=403565f5
0009:Call ntdll.RtlFreeUnicodeString(407af548) ret=4035660d
0009:trace:heap:RtlFreeHeap (0x401f,0002,40200ba0): returning TRUE
0009:Ret  ntdll.RtlFreeUnicodeString() retval=0001 ret=4035660d
0009:trace:file:CreateFileW returning 0x
0009:trace:file:GetTempFileNameW returning L"T:\\pat4e0.tmp"
- Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: 150 test failures. advapi32 test crashes.

[Michael Jung]

On Monday 08 November 2004 13:41, you wrote:
> Michael Jung wrote:
> > I fear that the problems with crypt.c and the crash are related to
> > rsaenh.dll, which is pretty new in wine cvs. I can't reconstruct the test
> > failures on my system. There are some entries in the initial registry,
> > which did change due to rsaenh.dll. Could please retry without an
> > existent .wine directory?
>
> Done.  (I even rebooted with nosmp.)  That seems to have helped the crypt
> test; now I just get
>
> ../../../../wine/tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p
> rsaenh_test.exe.so ../../../../wine/dlls/rsaenh/tests/rsaenh.c && touch
> rsaenh.ok fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200f90): not
> verifying image fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200fb0): not
> verifying image fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40202598): not
> verifying image
>
> which is benign, right?

Yes, it is. I would even opt for removing this fixme (or changing it to a 
trace) and let the VerifyImage function always return TRUE. Implementing it 
in a sensible way would be a large effort, which would not buy us any 
additional functionality. This function was meant to provide two things: 
1.) Enforcing US export regulations, which we should not care about (see 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/microsoft_policy_for_signing_csps.asp).
2.) Preventing tampering with CSP dlls, which has long been by-passed (it 
seems to be possible to exchange the unused NSAKEY in the binary advapi32.dll 
- and if you don't have write access to advapi32.dll you probably don't have 
write access to rsaenh.dll also).

Greetings,
Michael

Re: Fix for metafile test

[Dan Kegel]

Dmitry Timoshkov wrote:
metafile.c:91: Test failed: pass 0: dx[42] (1081735508) didn't match 4
make[3]: *** [metafile.ok] Error 43
Is the metafile test supposed to be broken like this under Wine?

That's because you have no truetype fonts installed. X11 fonts are
broken in that respect.
Thanks for the explanation.
It would be nice if the test would explain that.  Lots of people
don't have truetype fonts, and the test should xfail with the message
"I don't have what I need to run" rather than fail with "wine is broken".
- Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: 150 test failures. advapi32 test crashes.

[Dan Kegel]

Michael Jung wrote:
I fear that the problems with crypt.c and the crash are related to rsaenh.dll, 
which is pretty new in wine cvs. I can't reconstruct the test failures on my 
system. There are some entries in the initial registry, which did change due 
to rsaenh.dll. Could please retry without an existent .wine directory? 
Done.  (I even rebooted with nosmp.)  That seems to have helped the crypt 
test;
now I just get
../../../../wine/tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p 
rsaenh_test.exe.so ../../../../wine/dlls/rsaenh/tests/rsaenh.c && touch 
rsaenh.ok
fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200f90): not verifying image
fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200fb0): not verifying image
fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40202598): not verifying image
which is benign, right?
Unfortunately, it uncovered some other problems, which I'll post
about separately.
- Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: Blocking automatic debugger launch

[Jonathan Wilson]

Yeah, I know, it's just that it's not my code and I'm not certain that 
the authors will be releasing an update. There's a rumor of one but no 
certainty, as the company (a game publisher) refuses to make any 
announcements about what it's working on.
Does the crash happen on a real windows box?
If it doesnt happen on a real windows box, its probobly a WINE bug and 
should be fixed by the WINE people.
If it happens on real windows then yeah, its probobly something for the 
developer of the engine to fix.

Re: Fix for metafile test

[Dmitry Timoshkov]

"Dan Kegel" <[EMAIL PROTECTED]> wrote:

> Here's what I get when I run 'make test' on Wine:

[skipped]

> metafile.c:91: Test failed: pass 0: dx[42] (1081735508) didn't match 4
> make[3]: *** [metafile.ok] Error 43
> 
> Is the metafile test supposed to be broken like this under Wine?

That's because you have no truetype fonts installed. X11 fonts are
broken in that respect.

-- 
Dmitry.

Re: dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...

[Robert Reif]

Jakob Eriksson wrote:
Robert Reif wrote:

Removing the test so it passes on a Windows system with a real bug is
not the right thing to do for a wine regression test.  The test is 
there to
find bugs and that's what it did.

So, a driver blacklist is in order then?
regards,
Jakob Eriksson

Isn't the point of winetest just to do a sanity check on the wine 
regression
tests to make sure they are correct and valid.  You don't need a 100%
pass rate to prove that the tests are valid as long as you understand the
reason for failure.  Putting a windows driver blacklist in a wine regression
test just doesn't seem right.

I would rather see effort spent worrying about bugs in wine sound drivers
rather than bugs in windows drivers.  But then, winetest isn't meant to be
run on wine which is a shame because it would be ideal for identifying
which wine hardware/os/library versions are causing problems.

Re: Blocking automatic debugger launch

[Kenneth Porter]

--On Monday, November 08, 2004 10:38 AM +0100 Andreas Mohr 
<[EMAIL PROTECTED]> wrote:

Yes, there is: fix the crash! :-)
Yeah, I know, it's just that it's not my code and I'm not certain that the 
authors will be releasing an update. There's a rumor of one but no 
certainty, as the company (a game publisher) refuses to make any 
announcements about what it's working on.

Re: winzip 9 doesn't run under wine :-(

[Mike Hearn]

Hans Leidekker wrote:
What version of Wine are you using? It installs fine for me on CVS
from yesterday. I have grown into a habit of doing:
 $ rm -rf ~/.wine && wine 
because the rate of change in Wine is so high that you can expect
the registry (and the rest of .wine) to be out of sync with Wine's
code within a couple of days.
Yeah. All the more reason to get .wine versioning figured out soon.
thanks -mike

Re: winzip 9 doesn't run under wine :-(

[Hans Leidekker]

On Monday 8 November 2004 11:59, Mike Hearn wrote:

> > But winzip 9 still doesn't install, at least with default settings;
> > now the wrong value for default destination comes up in the installation
> > dialog box, "%SystemDrive%\Program Files\WinZip".  Seems like
> > some environment variable isn't being expanded somewhere?

What version of Wine are you using? It installs fine for me on CVS
from yesterday. I have grown into a habit of doing:

 $ rm -rf ~/.wine && wine 

because the rate of change in Wine is so high that you can expect
the registry (and the rest of .wine) to be out of sync with Wine's
code within a couple of days.

> Check the registry, does this string appear in it somewhere? If so we 
> probably need to set the key to type EXPANDSZ or whatever it's called ...

I recall that there were some changes related to these environment
variables recently. My guess is that Dan's .wine is from before those
changes.

 -Hans

Re: wine/ tools/wine.inf include/config.h.in dlls/ ...

[Michael Jung]

On Friday 05 November 2004 21:50, Vincent Béron wrote:
> Le jeu 04/11/2004 à 16:15, Alexandre Julliard a écrit :
> > Log message:
> >  Michael Jung <[EMAIL PROTECTED]>
> >  Implemented a substantial part of rsaenh.dll.
> >
> > Patch: http://cvs.winehq.org/patch.py?id=14412
>
> The committed patch doesn't compile on RH8. OpenSSL doesn't use the same
> name for some datatypes/functions as the version used by Michael
> (actually the prototype is different as well).
>
>...

Hi Vincent,

sorry for causing you problems. 

> + pbKeyStream_no_const = StrDupA(pbKeyStream);
> + encrypt_block_impl(pPubKey->aiAlgid, &pPubKey->context, 
pbKeyStream_no_const, pbDecrypted, 

This doesn't seem to be correct. You can't apply a string duplication function 
to clone a pbKeyStream since it is not a zero terminated string. I also don't 
consider it beneficial to have a dependecy on shlwapi for this API. 
Furthermore, I think this duplication should be done inside 
encrypt_block_impl (if at all). 

I'm currently working on integrating source code from LibTomCrypt into rsaenh, 
which will help us to get rid of the OpenSSL dependency. I'm hoping to get it 
ready for the weekend.

Greetings,
Michael

Re: winzip 9 doesn't run under wine :-(

[Mike Hearn]

Dan Kegel wrote:
But winzip 9 still doesn't install, at least with default settings;
now the wrong value for default destination comes up in the installation
dialog box, "%SystemDrive%\Program Files\WinZip".  Seems like
some environment variable isn't being expanded somewhere?
Check the registry, does this string appear in it somewhere? If so we 
probably need to set the key to type EXPANDSZ or whatever it's called ...

Re: 150 test failures. advapi32 test crashes.

[Michael Jung]

On Sunday 07 November 2004 23:19, Dan Kegel wrote:
> Hey folks,
> I pulled down sources from CVS this morning, and tried
> running the regression tests.  There are about 150 failures.
> Here's a summary:
>
> $ grep "Test failed" log | sed 's/:.*//' | uniq -c | sort
>1 filtergraph.c
>1 rsaenh.c
>1 shelllink.c
>1 shreg.c
>2 typelib.c
>4 capture.c
>4 wave.c
>6 dsound8.c
>6 dsound.c
>7 vartype.c
>8 path.c
>   15 crypt.c
>   43 metafile.c
>   51 shellpath.c
>
> Is this unusual?   How many failures are most people seeing?
> For what it's worth, this is a Red Hat 9.0 system with two processors,
> and this was done with no pre-existing .wine directory.
>
> Also, there was a crash during the test.  Here's that part of the log:

Dan,

I fear that the problems with crypt.c and the crash are related to rsaenh.dll, 
which is pretty new in wine cvs. I can't reconstruct the test failures on my 
system. There are some entries in the initial registry, which did change due 
to rsaenh.dll. Could please retry without an existent .wine directory? (Or at 
least unregister rsabase and register rsaenh - regsvr32 /U rsabase ; regsvr32 
rsaenh). I don't have time at the moment, but I will take a closer look 
tomorrow evening.

Greetings,
Michael

Re: Blocking automatic debugger launch

[Andreas Mohr]

Hi,

On Sun, Nov 07, 2004 at 09:13:36PM -0800, Kenneth Porter wrote:
> I've got an app that seems to be crashing during shutdown. (Tribes 
> Vengeance dedicated server) I'm running it detached inside a screen 
> session, and I don't want the debugger to automatically launch when the 
> app crashes. I just want the thing to die when I send it a "quit" command. 
> Currently I've hacked the registry setting and changed the debugger name 
> to "true". Is there a cleaner way to accomplish this?
Yes, there is: fix the crash! :-)

Anyway, I guess that Wine WILL do the debugger invocation once there's
an exception, so your approach should be fine.

Andreas Mohr

Re: Do we need one of those on our docs?

[Andreas Mohr]

Hi,

On Mon, Nov 08, 2004 at 10:10:46AM +0200, Shachar Shemesh wrote:
> From the samba developer's guide, http://us1.samba.org/samba/devel/
> 
> >*Important:* In order to avoid any potential licensing issues we
> >also ask that anyone who has signed the Microsoft CIFS Royalty
> >Free Agreement
> >
> > 
> >not submit patches to Samba, nor base patches on the referenced
> >specification. We ask, too, that patches submitted to Samba not
> >infringe on any known patents. Finally, as with all GPL work, the
> >submitter should ensure that submitted patches do not conflict
> >with any third-party copyright.
> >
> >
> Do we need to put in something like that too?
Oh, right, I've seen it before, but I didn't think about Wine then.

I vote for including it (in modified form, if necessary).

Better be safe than sorry (you never know what M$ will do two days later).

Andreas Mohr

Do we need one of those on our docs?

[Shachar Shemesh]

From the samba developer's guide, http://us1.samba.org/samba/devel/
*Important:* In order to avoid any potential licensing issues we
also ask that anyone who has signed the Microsoft CIFS Royalty
Free Agreement


not submit patches to Samba, nor base patches on the referenced
specification. We ask, too, that patches submitted to Samba not
infringe on any known patents. Finally, as with all GPL work, the
submitter should ensure that submitted patches do not conflict
with any third-party copyright.

Do we need to put in something like that too?
I'm not a lawyer (but I can probably get one). My understanding is that 
the "protocols" Microsoft policy don't really affect us. What may affect 
us is the wider and wider distribution of the Windows source code 
(Shared Source). We should not be highly affected by trade secrets: 
anyone publishing a trade secret is nullifying the secretness of it, and 
is the one bearing the responsibility for this action. However, 
copyright problems may be a problem for us. If someone takes a 
significant amount of code from MS and submits it, we may have some 
backtracking to do.

 Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/

Re: winzip 9 doesn't run under wine :-(

[Dan Kegel]

Dan Kegel wrote:
And even if you put in C: instead of %SystemDrive%, installation
goes a little further, but fails with
"WinZip internal error in file install.c line 930".
...
Hrm.  Even WinZip 8.1 is failing now in the same way, even
after I blow away ~/.wine.  Here's part of the output of
WINEDEBUG="+shell,+process,+dialog" ./wine 'C:\WinZip\winzip32.exe'
with WinZip 8.1.  Notice the suspicious-looking line:
SHGetFileInfoW (L"10 10 10 10.10 10 10 10", ...
The dialog call is for the error box.
This error persists even after installation;
you get it every time you run the app.
- Dan
trace:shell:SHGetFolderPathW returning 0x80070002 (final path is L"c:\\windows\\profiles\\dank\\My Documents")
trace:shell:SHGetFolderLocation -- (new pidl (nil))
trace:shell:SHAlloc 42 bytes at 0x402508b8
trace:shell:SHAlloc 16 bytes at 0x4024ab68
trace:shell:SHFree 0x402508b8
trace:shell:SHFree 0x4024ab68
trace:shell:SHGetFileInfoW (L"C:\\" fattr=0x80 sfi=0x4072f68c(attr=0x4086716c) size=0x2b4 flags=0x4115)
trace:shell:PathIsRelativeW (L"C:\\")
fixme:shell:SHGetFileInfoW set icon to shell size, stub
trace:shell:PathFindExtensionW (L"C:\\")
trace:shell:HCR_MapTypeToValueW L"" 0x400cffae
trace:shell:SHGetFileInfoW icon=0x120e index=0x attr=0x4086716c name=L"" type=L"" ret=0x4023ad98
fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray 0x4072f92c
trace:shell:SHGetSettings (0x4072f948 0x0480)
trace:shell:SHGetSettings -- 0x
trace:shell:SHGetFileInfoW (L"10 10 10 10.10 10 10 10" fattr=0x0 sfi=0x4072f3b0(attr=0x4072f3e4) size=0x2b4 flags=0x4010)
trace:shell:PathIsRelativeW (L"10 10 10 10.10 10 10 10")
trace:shell:PathCombineW (0x4072ef68,L"Z:\\home\\dank\\demo\\build",L"10 10 10 10.10 10 10 10")
trace:shell:PathIsRelativeW (L"10 10 10 10.10 10 10 10")
trace:shell:PathAddBackslashW (L"Z:\\home\\dank\\demo\\build")
trace:shell:PathCanonicalizeW (0x4072ef68,L"Z:\\home\\dank\\demo\\build\\10 10 10 10.10 10 10 10")
trace:shell:PathFindExtensionW (L"Z:\\home\\dank\\demo\\build\\10 10 10 10.10 10 10 10")
trace:shell:HCR_MapTypeToValueW L"" 0x400cfd51
trace:shell:SHGetFileInfoW icon=0x40254618 index=0x attr=0x4072f3e4 name=L"" type=L"" ret=0x4023b5f0
trace:dialog:DIALOG_GetCharSize dlg base units: 8 x 16
trace:dialog:GetDialogBaseUnits base units = 8,16
trace:dialog:DIALOG_ParseTemplate32 DIALOGEX 0, 0, 250, 97, 0
trace:dialog:DIALOG_ParseTemplate32  STYLE 0x80c800c0
trace:dialog:DIALOG_ParseTemplate32  EXSTYLE 0x
trace:dialog:DIALOG_ParseTemplate32  CAPTION L"WinZip"
trace:dialog:DIALOG_ParseTemplate32  FONT 8, L"MS Shell Dlg", 0, FALSE
trace:dialog:DIALOG_GetCharSize dlg base units: 7 x 14
trace:dialog:DIALOG_CreateIndirect units = 7,14
trace:dialog:DIALOG_CreateControls32  BEGIN
trace:dialog:DIALOG_GetControl32 L"Static" L"" 4541, 6, 6, 238, 16, 5002, , 
trace:dialog:DIALOG_GetControl32 L"Static" L"" 4542, 6, 25, 238, 8, 5002, , 
trace:dialog:DIALOG_GetControl32 L"Static" L"If this is a recurring problem and you would like WinZip to create a log file with details about the error so that you can report this problem to the developers, you can do so now." -1, 7, 
43, 232, 27, 5002, , 

--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html