Re: dxdiagn: PhysicalMemory parameter is a string not long long

[Vitaliy Margolen]

Alexandre Julliard wrote:
> Vitaliy Margolen <[EMAIL PROTECTED]> writes:
> 
>> Was anything wrong with this patch? I've used a simple utility 
>> DxDiagOutput.exe from DXSDK to find and test this.
> 
> The printf format is wrong.
> 
Well it really should be "%llu" but Wine doesn't support that. "%lu" is used 
btw at least in one place in the code: 
http://source.winehq.org/source/dlls/ntdll/actctx.c#L1746

What should it be then? The same as wine_dbgstr_longlong?

Vitaliy.

Recent change causes registry creation to fail

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I am trying to write a scripted wine installation in a nonstandard
directory.  As part of this procedure, I set $WINEPREFIX and then run
wineprefixcreate.  This worked perfectly in 0.9.59, but in 0.9.60+ it
fails with

wineserver: chdir to config dir : Not a directory
wine: for some mysterious reason, the wine server failed to run

"regedit" fails with the same error.  Wine does run, but its registry
appears to be screwy.  For example, the DOS environment variables like
%PROGRAMFILES% and %PATH% are not set at all.

I have traced the error to a change made by Alexandre Julliard to
registry.c in mid-April [1].  Why might that change have this effect?
What should I do to avoid this problem?

Thank you,
Ben Schwartz
OLPC volunteer

[1]
http://source.winehq.org/git/wine.git/?a=blobdiff;f=server/registry.c;h=d2c0b23dcf80f042d73046fbe60aac78d7ce16a0;hp=50848924601c5bbbc504b2f9a83ec55a1fad57b3;hb=161160f05ae2340ab5bb35307ca02056cbca68e9;hpb=e52e5e67159753cdc0c5abfa409f71c0710dab47
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkg/g8wACgkQUJT6e6HFtqTgdwCeM7S/HVIS8LU82qVQ5R3cs0Yt
HGAAn3cQhdG4VR5H/2jbIbU7SS/uDRX4
=5Bd7
-END PGP SIGNATURE-

Re: advpack: don't close a handle if it wasn't opened

[James Hawkins]

On Thu, May 29, 2008 at 10:34 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> Avoids referencing an undefined variable.
>

The right way to fix this is to set subkey to NULL in the beginning.

-- 
James Hawkins

Re: user32: Allow a NULL foreground window in the tests

[Dmitry Timoshkov]

"James Hawkins" <[EMAIL PROTECTED]> wrote:

> Passing 0 for the foreground window essentially disables the test,
> whereas allowing a NULL window is testing another variation of what
> can happen with the foreground window, just like if a last error is,
> e.g.,  ERROR_FILE_NOT_FOUND on one platform instead of
> ERROR_PATH_NOT_FOUND.  Your method disables the test completely.

Yes, passing foreground == 0 disables the foreground window test. That
should be done very carefully for the tests that always fail. I'd expect
for instance test_SetActiveWindow() and test_SetForegroundWindow() not
need to disable it.

-- 
Dmitry.

[website] Re: wine site: Translate sendind_patches to Spanish in web.site.git

[Ángel Guzmán Maeso]

> OK. Patches are complete. The majority of the website can be translated
> now.


O_O XLNT!!


> What still needs to be done is to allow translation of the sidebar nav. My
> plan is to move that out of the config.php file and into a separate file,
> possibly in XML.

Well, sound good for me.

People who want to send translations of the news and wwn will probably need
> to subscribe to wine-cvs and watch for commits from me for the files in the
> "en" dirs to keep the turn around time on translations shorter.

Yeah, I am already subscribed to ALL lists of wine, so it's no problem
(wine-cvs, wine-devel, wine-bugs...wine-santa, wine-bogeyman...).

At the very least, the website will always fall back to the english version
> of the template.

 Ok


> Yeah, I'm working on a patch now to enable translations of all the content.
> Someone will have fun jobs of sending in translations of all the WWN
> content, but if they are up to the challenge.
>
> Hold off on your updates until I'm done.

Well, Still not begin to translate part of WWN, but translates other
templates.

FYI, your templates will need to be in UTF-8 encoded text files. Make sure
> your text editor is set to output that. Your original patch was not UTF-8.


Sorry, I used Geany, Gedit and other and they are in conflict of encode.

For Your Information: Not translate NEVER with google translator or other
"translators" because they are machines and they translate as if they were
wild Indians or master yoda. If you use your translators, at least you know
enough language to translate that, because if not the translation will be
very very bad, for example, in /template/es/404.template

I send a patch with translations for many templates and 404.template (in
UTF-8 believe) and a small improve in a function of file site.
This improvement use array_ramdom instead of rand+count but the bound is not
clear for me, so you should review
diff --git a/site b/site
index 578dcaa..d373193 100644
--- a/site
+++ b/site
@@ -380,7 +380,8 @@ function view_screenshots ($x)
 function view_quote ()
 {
 $quotes = split("\n",$GLOBALS[html]->template('base','quotes'));
-return $quotes[rand(0,(count($quotes)-2))]; 
+return $quotes[array_rand($quotes)]; # Not sure of bound 0 to n-2?
+	# return $quotes[array_rand($quotes)-2]; Maybe this, but also -2?
 }
 
 // end of file
diff --git a/templates/es/404.template b/templates/es/404.template
index 278271b..88ed3aa 100644
--- a/templates/es/404.template
+++ b/templates/es/404.template
@@ -1,17 +1,22 @@
-
+
 
 
-404 no encontrados 
+404 no encontrado
 
 
 
-Apesadumbrado, ese documento no fue encontrado. Compruebe por favor su URL e intente otra vez. 
+Lo sentimos, ese documento no fue encontrado. Por favor 
+compruebe su URL e intentelo otra vez. 
 
 
-
+
 
 
-Si usted siguió un acoplamiento de una página de WineHQ.org y alcanzó esta página en error, divulgúelo por favor a WineHQ.org http://bugs.winehq.org/enter_bug.cgi?product=WineHQ.com";>Bugzilla. 
+Si usted siguió un enlace desde una página de WineHQ.org y alcanzó 
+esta página en error, por favor informe de ello en WineHQ.org 
+http://bugs.winehq.org/enter_bug.cgi?product=WineHQ.com";>
+Bugzilla. 
  
 
  
diff --git a/templates/es/download-deb.template b/templates/es/download-deb.template
new file mode 100644
index 000..58dcca2
--- /dev/null
+++ b/templates/es/download-deb.template
@@ -0,0 +1,62 @@
+
+
+
+Wine para Ubuntu, Debian y distribuciones basadas en Debian
+
+
+Debian y distribuciones basadas en Debian como Ubuntu utilizan una herramienta
+especial para administrar paquetes conocida como APT. APT es capaz de instalar 
+automáticamente todas las dependencias necesarias para un paquete de software, 
+así como mantener el paquete actualizado, mediante el escaneo de lo que se 
+conoce como repositorios de APT. Las distribuciones basadas en Debian tienen sus 
+propios repositorios de software que incluyen Wine. Sin embargo, mantenemos 
+nuestro propio repositorio con los últimos paquetes disponibles aquí para su 
+descarga.
+
+ Podría haber instrucciones gŕaficas aquí, sin embargo hemos encontrado que los
+terminales de comandos son en realidad más sencillos de describir y 
+más rápidos para la entrada de usuario. Debido a que los 
+comandos de abajo utilizan sudo, puede que tenga que introducir su 
+contraseña de usuario después de pulsar la tecla Enter.
+
+Añadiendo el repositorio APT de WineHQ:
+
+En primer lugar, abra una ventana de terminal (Aplicaciones-> Accesorios-> Terminal). Entonces
+añada la clave de repositorio a su sistema APT de lista de claves de confianza por copia y
+pegue el texto siguiente:
+
+wget -q http://wine.budgetdedicated.com/apt/387EE263.gpg -O- | sudo apt-key add -
+
+A continuación, añada el repositorio al sistema de listado de fuentes APT:
+
+Para Ubuntu Hardy (8.04):
+sudo wget http://wine.budgetdedicated.com/apt/sources.list.d/hardy.list -O /etc/apt/sources.list.d

Re: Currently Git doesn't build on Linux x86_64

[Hin-Tak Leung]

Erik de Castro Lopo wrote:
> Hi all,
> 
> I've just pulled from git and the latest change I have is this one:
> 
> commit 4c928d39ad82e576113a34bfa4d27dd0b3eaba17
> Author: James Hawkins <[EMAIL PROTECTED]>
> Date:   Wed May 28 19:15:15 2008 -0500
> 
> oleaut32: Disable olefont tests that fail on all platforms.
> 
> When I ./configure it I get:
> 
> checking for freetype-config... freetype-config
> checking for -lfreetype... not found
> configure: error: FreeType development files not found.
> Fonts will not be built. Dialog text may be invisible or unaligned.
> Use the --without-freetype option if you really want this.
> 
> This is an Ubuntu Hardy system and I do have freetype installed:
> 
> > dpkg -L libfreetype6-dev | grep libfreetype.so
> /usr/lib/libfreetype.so
> 
> Is anyone else seeing this?

Argh, that's not right. On Ubuntu Hardy, or Debian derivatives, I believe
the 32-bit version of the libraries are under /usr/lib32 (unlike most other
distros, where the distinction is /usr/lib vs /usr/lib64 rather than /usr/lib32 
vs /usr/lib).

*I am not a Debian-derivative user*, but /usr/lib/libfreetype.so is probably
the 64-bit version and strictly speaking, quite irrelevant to wine (which needs
32-bit version of the libraries)?

Re: Currently Git doesn't build on Linux x86_64

[Austin English]

On Thu, May 29, 2008 at 5:44 PM, Erik de Castro Lopo
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've just pulled from git and the latest change I have is this one:
>
>commit 4c928d39ad82e576113a34bfa4d27dd0b3eaba17
>Author: James Hawkins <[EMAIL PROTECTED]>
>Date:   Wed May 28 19:15:15 2008 -0500
>
>oleaut32: Disable olefont tests that fail on all platforms.
>
> When I ./configure it I get:
>
>checking for freetype-config... freetype-config
>checking for -lfreetype... not found
>configure: error: FreeType development files not found.
>Fonts will not be built. Dialog text may be invisible or unaligned.
>Use the --without-freetype option if you really want this.
>
> This is an Ubuntu Hardy system and I do have freetype installed:
>
>> dpkg -L libfreetype6-dev | grep libfreetype.so
>/usr/lib/libfreetype.so
>
> Is anyone else seeing this?
>
> Cheers,
> Erik
> --
> -
> Erik de Castro Lopo
> -
> "Men who use terrorism as a means to power, rule by terror
> once they are in power."
> -- Helen Macinnes
>
>
>

http://wiki.winehq.org/WineOn64bit

Re: implemented first testcase for dxdiagn

[Vitaliy Margolen]

Markus wrote:
> 
> 
> 
> 

> +hr = IDxDiagContainer_GetNumberOfProps(pAdapterContainer, 
> &dwPropCount);
> +ok(dwPropCount == 72, "Incorrect number of properties in display 
> adapter container. "
> +"Found (%d) should be (%d).\n", dwPropCount, 72);

I don't think you can relay on that being true all the time. Besides what's 
the point in testing the number of properties?

As a general note - if you add a test that currently fails on Wine it needs 
todo_wine at front of it.

Vitaliy.

Currently Git doesn't build on Linux x86_64

[Erik de Castro Lopo]

Hi all,

I've just pulled from git and the latest change I have is this one:

commit 4c928d39ad82e576113a34bfa4d27dd0b3eaba17
Author: James Hawkins <[EMAIL PROTECTED]>
Date:   Wed May 28 19:15:15 2008 -0500

oleaut32: Disable olefont tests that fail on all platforms.

When I ./configure it I get:

checking for freetype-config... freetype-config
checking for -lfreetype... not found
configure: error: FreeType development files not found.
Fonts will not be built. Dialog text may be invisible or unaligned.
Use the --without-freetype option if you really want this.

This is an Ubuntu Hardy system and I do have freetype installed:

> dpkg -L libfreetype6-dev | grep libfreetype.so
/usr/lib/libfreetype.so

Is anyone else seeing this?

Cheers,
Erik
-- 
-
Erik de Castro Lopo
-
"Men who use terrorism as a means to power, rule by terror
once they are in power."
-- Helen Macinnes

Re: [website] Re: wine site: Translate sendind_patches to Spanish in web.site.git

[Jeremy Newman]

OK. Patches are complete. The majority of the website can be translated now.

What still needs to be done is to allow translation of the sidebar nav. 
My plan is to move that out of the config.php file and into a separate 
file, possibly in XML.

People who want to send translations of the news and wwn will probably 
need to subscribe to wine-cvs and watch for commits from me for the 
files in the "en" dirs to keep the turn around time on translations shorter.

At the very least, the website will always fall back to the english 
version of the template.

Jeremy Newman wrote:
> Yeah, I'm working on a patch now to enable translations of all the 
> content. Someone will have fun jobs of sending in translations of all 
> the WWN content, but if they are up to the challenge.
> 
> Hold off on your updates until I'm done.
> 
> FYI, your templates will need to be in UTF-8 encoded text files. Make 
> sure your text editor is set to output that. Your original patch was not 
> UTF-8.
> 
> Ángel Guzmán Maeso wrote:
>> 2. The website does not support translations yet. I don't think it
>> is much work to support it. Mainly the HTML class template()
>> function needs to check the browser for the language, then change
>> the template dir, if the template for the language is not found,
>> then the EN version is loaded as a fallback.
>>
>>
>> I have PHP programming for 4 years and my level still is not perfect, 
>> although the management sufficiently.
>>
>> I think it's hard work, but it is not difficult. Some of my pages bear 
>> languages and this is a small sketch of the script that I use to 
>> recognize the languages and apply them in my pages 

Re: AppDB: More information about the test environment needed

[Reece Dunn]

2008/5/29 Groeschel, Volker <[EMAIL PROTECTED]>:
> I just found two conflicting reports for  Age of empires:
>http://appdb.winehq.org/objectManager.php?sClass=version&iId=10326
>
> Both are on Ubuntu 8.04 and 1.0-rc1. One is Silver, one is Garbage. But it
> is just one example.

Going with AoE, I have recently tried this with the same setup (except
for using 1.0-rc2). I haven't submitted these results yet as I need to
verify them on a clean setup without any "fiddling".

Installation:
I1.  wine /media/cdrom0/aoesetup.exe works, but running the game gives
a "no CD in drive" error;
I2.  wine "d:\\aoesetup.exe" also works, and does *not* give a no CD error.

Therefore, you can get it to work without any configuration adjustment
or cracks.

Running:
R1.  wine "c:\\program files\\...\\aoe.exe" causes an error about
failing to detect graphics card (see one of the threads on the forum
for more information);
R2.  cd $WINEPREFIX/drive_c/Program\ Files/... && wine aoe.exe works perfectly;
R3.  wine winefile and then double clicking on aoe.exe also works perfectly.

There is the black text (difficult to read!) bug noted in the test
results comments.

I suspect that the Silver rating is I1+R2 and the Garbage rating is I1+R1.

> My suggestion is to ask for more information about the test environment.
> ...
> It is quite hard to get real informaltion on this topic.

I think that may help in some situations, and would be good for
collecting information for use in bug reports, but I don't know
exactly how useful it will be. In this instance, it *is* possible to
get a good experience from the game, but you need to know the quirks
of that application.

I am going to write up the above once I have verified it on a clean
WINEPREFIX with no fiddling. Therefore, for me I'd rate it Gold, with
the black text on the mission objectives screen being the only thing
preventing it getting Platinum.

- Reece

Re: [website] Re: wine site: Translate sendind_patches to Spanish in web.site.git

[Jeremy Newman]

Yeah, I'm working on a patch now to enable translations of all the 
content. Someone will have fun jobs of sending in translations of all 
the WWN content, but if they are up to the challenge.

Hold off on your updates until I'm done.

FYI, your templates will need to be in UTF-8 encoded text files. Make 
sure your text editor is set to output that. Your original patch was not 
UTF-8.

Ángel Guzmán Maeso wrote:
> 
> 2. The website does not support translations yet. I don't think it
> is much work to support it. Mainly the HTML class template()
> function needs to check the browser for the language, then change
> the template dir, if the template for the language is not found,
> then the EN version is loaded as a fallback.
> 
> 
> I have PHP programming for 4 years and my level still is not perfect, 
> although the management sufficiently.
> 
> I think it's hard work, but it is not difficult. Some of my pages bear 
> languages and this is a small sketch of the script that I use to 
> recognize the languages and apply them in my pages 
> 

Re: ntdll: Strengthen current tests and add new tests for asynchronous I/O.

[Zac Brown]

Woops, ignore this patch. Its got a couple things wrong with it. I'll send a 
fix 
later on.

-Zac

Zac Brown wrote:
> Strengthen current tests and add new tests for asynchronous I/O. Missing 
> test for empty messages as well as thoroughly testing input and output 
> of read/write commands.
> 
> -Zac Brown
> 
> 
> 
> 
> From d2a3cbaf6d71c3b0bcfa39afcf854de7e5daa5bb Mon Sep 17 00:00:00 2001
> From: Zac Brown <[EMAIL PROTECTED]>
> Date: Thu, 29 May 2008 13:34:50 -0700
> Subject: [PATCH] Strengthen current tests and add new tests for asynchronous 
> I/O.
> 
> ---
>  dlls/ntdll/tests/file.c |  103 
> ---
>  1 files changed, 79 insertions(+), 24 deletions(-)
> 
> diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c
> index d824530..e3cbf77 100644
> --- a/dlls/ntdll/tests/file.c
> +++ b/dlls/ntdll/tests/file.c
> @@ -2,6 +2,7 @@
>   *
>   * Copyright 2007 Jeff Latimer
>   * Copyright 2007 Andrey Turkin
> + * Copyright 2008 Google (Zac Brown)
>   *
>   * This library is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU Lesser General Public
> @@ -65,6 +66,7 @@ static inline BOOL is_signaled( HANDLE obj )
>  }
>  
>  #define PIPENAME ".\\pipe\\ntdll_tests_file.c"
> +#define TEST_BUF_LEN 10
>  
>  static BOOL create_pipe( HANDLE *read, HANDLE *write, ULONG flags, ULONG 
> size )
>  {
> @@ -114,7 +116,10 @@ static BOOL get_msg(HANDLE h)
>  {
>  LARGE_INTEGER timeout = {{-1000*3}};
>  DWORD res = pNtRemoveIoCompletion( h, &completionKey, &completionValue, 
> &ioSb, &timeout);
> -ok( res == STATUS_SUCCESS, "NtRemoveIoCompletion failed: %x\n", res );
> +if (res == STATUS_TIMEOUT)
> +ok( res == STATUS_TIMEOUT, "NtRemoveIoCompletion should have timed 
> out, got: %x\n", res );
> +else
> +ok( res == STATUS_SUCCESS, "NtRemoveIoCompletion failed: %x\n", res 
> );
>  if (res != STATUS_SUCCESS)
>  {
>  completionKey = completionValue = 0;
> @@ -507,6 +512,7 @@ static void test_iocp_fileio(HANDLE h)
>  FILE_COMPLETION_INFORMATION fci = {h, CKEY_SECOND};
>  HANDLE hPipeSrv, hPipeClt;
>  NTSTATUS res;
> +BOOL rw_res;
>  
>  hPipeSrv = CreateNamedPipeA( pipe_name, PIPE_ACCESS_INBOUND, 
> PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, 4, 1024, 1024, 1000, 
> NULL );
>  ok( hPipeSrv != INVALID_HANDLE_VALUE, "Cannot create named pipe\n" );
> @@ -533,49 +539,97 @@ static void test_iocp_fileio(HANDLE h)
>  if (hPipeClt != INVALID_HANDLE_VALUE)
>  {
>  OVERLAPPED o = {0,};
> -BYTE buf[3];
> +BYTE buf_send[TEST_BUF_LEN];
> +BYTE buf_rcv[TEST_BUF_LEN];
>  DWORD read;
>  long count;
> +unsigned int i;
>  
>  NTSTATUS res = pNtSetInformationFile( hPipeSrv, &iosb, &fci, 
> sizeof(fci), FileCompletionInformation );
>  ok( res == STATUS_SUCCESS, "NtSetInformationFile failed: %x\n", res 
> );
>  ok( U(iosb).Status == STATUS_SUCCESS, "iosb.Status invalid: %x\n", 
> U(iosb).Status );
>  
> -count = get_pending_msgs(h);
> -ok( !count, "Unexpected msg count: %ld\n", count );
> -ReadFile( hPipeSrv, buf, 3, &read, &o);
> -count = get_pending_msgs(h);
> -ok( !count, "Unexpected msg count: %ld\n", count );
> -WriteFile( hPipeClt, buf, 3, &read, NULL );
> -
> -if (get_msg(h))
> +/* Try messages of differing lengths and values, checking that they 
> match. */
> +for( i = 1; i < 10; i++ )
>  {
> -ok( completionKey == CKEY_SECOND, "Invalid completion key: 
> %lx\n", completionKey );
> -ok( ioSb.Information == 3, "Invalid ioSb.Information: %ld\n", 
> ioSb.Information );
> -ok( U(ioSb).Status == STATUS_SUCCESS, "Invalid ioSb.Status: 
> %x\n", U(ioSb).Status);
> -ok( completionValue == (ULONG_PTR)&o, "Invalid completion value: 
> %lx\n", completionValue );
> +memset( buf_send, 0, TEST_BUF_LEN );
> +memset( buf_rcv, 0, TEST_BUF_LEN );
> +memset( buf_send, i, i );
> +
> +/* Try reading before writing */
> +count = get_pending_msgs(h);
> +ok( !count, "Unexpected msg count: %ld\n", count );
> +rw_res = ReadFile( hPipeSrv, buf_rcv, i, &read, &o );
> +ok( rw_res == FALSE, "Unexpected success of ReadFile\n" );
> +ok( GetLastError() == ERROR_IO_PENDING, "Expected error of 
> ERROR_IO_PENDING, got %d\n", GetLastError() );
> +count = get_pending_msgs(h);
> +ok( !count, "Unexpected msg count: %ld\n", count );
> +rw_res = WriteFile( hPipeClt, buf_send, i, &read, NULL );
> +ok( rw_res == TRUE, "Unexpected fail of WriteFile\n" );
> +if (get_msg(h))
> +{
> +ok( completionKey == CKEY_SECOND, "Invalid completion key: 

Re: Disabling Compiz (Was: uninformed musings on ddraw + bugs 2082 and 1347 + dib engine)

[Austin English]

On Thu, May 29, 2008 at 1:26 PM, H. Verbeet <[EMAIL PROTECTED]> wrote:
> 2008/5/29 Stefan Dösinger <[EMAIL PROTECTED]>:
>> However, windows has a DLL which allows apps to disable Aero manually, I 
>> think
>> that's wdm.dll.
>>
> dwmapi.dll, iirc.
>
>
>

hModule := DllCall("LoadLibrary", "str", "dwmapi.dll")
DllCall("dwmapi\DwmEnableComposition", "uint", 0)

http://www.autohotkey.com/forum/topic23347.html

Re: Disabling Compiz (Was: uninformed musings on ddraw + bugs 2082 and 1347 + dib engine)

[H. Verbeet]

2008/5/29 Stefan Dösinger <[EMAIL PROTECTED]>:
> However, windows has a DLL which allows apps to disable Aero manually, I think
> that's wdm.dll.
>
dwmapi.dll, iirc.

[website] Re: wine site: Translate sendind_patches to Spanish in web.site.git

[Ángel Guzmán Maeso]

> 2. The website does not support translations yet. I don't think it is much
> work to support it. Mainly the HTML class template() function needs to check
> the browser for the language, then change the template dir, if the template
> for the language is not found, then the EN version is loaded as a fallback.


I have PHP programming for 4 years and my level still is not perfect,
although the management sufficiently.

I think it's hard work, but it is not difficult. Some of my pages bear
languages and this is a small sketch of the script that I use to recognize
the languages and apply them in my pages




> 3. Some parts, like the news and WWN are not in a system that can be easily
> translated. Not sure what to do about that. IOW, they are not using the html
> template() class, they are based on a hacky XML format.


XML not is a problem.  The contents of WWN can be easily translated. Only
you must create a directory for each language and put all the files in
English so that they can be loaded. After that there is only translate the
contents of XML (not the label, if not the content) and the WWN will be
translated.

I think the translation of the website is very important because with the
growth of Wine and many new users will greatly appreciate that the contents
may be in their language.

I could try to build support for website, but I have not even looked at the
entire code of the website and I take a few weeks (or maybe just days)
understand. It would be very helpful if the website was translated for Wine
1.0.
 

Re: winetest issue on w2k and below

[Paul Vriens]

Austin English wrote:
> On Thu, May 29, 2008 at 7:31 AM, Paul Vriens <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Lately I've been seeing an issue with winetest on Windows whereby the
>> kernel32_test.exe file can't be deleted after the test.
>>
>> On NT4 I've also seen popups during the test with some remark about not being
>> able to initialize user32.dll. This is when the process test is run for 
>> kernel32.
>>
>> Anyone else seeing this? Or better yet, anyone know the cause?
>>
>> --
>> Cheers,
>>
>> Paul.
>>
>>
>>
> 
> -To list as well-
> 
> I've been seeing it for a week or so. 2K is also crashing the debugger
> in a weird way, can't recall the exact error message, but it was a
> second scarier message than usual.
> 
I just run some older winetests on my NT4 box:

(all from http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/)

winetest-200805062030-paul-mingw.exe (no problem with kernel tests)
winetest-200805081000-paul-mingw.exe (problems)

Now it's just to see what has changed in that period.

Doing regression tests with a full winetest is a bit harder :-(

-- 
Cheers,

Paul.

README: Few more updates

[Austin English]

Anything wrong with this patch?

http://www.winehq.org/pipermail/wine-patches/2008-May/055215.html

Re: uninformed musings on ddraw + bugs 2082 and 1347 + dib engine

[Travis Watkins]

On Thu, May 29, 2008 at 10:21 AM, Stefan Dösinger
<[EMAIL PROTECTED]> wrote:
> -> Talk to the beryl devs to get a way to disable compiz. We'll need this for
> fullscreen mode anyway, but we should not rely on it for windowed mode, since
> we can't disable compositing on MacOS. So we have to work around this problem

We already allow this with the "Unredirect fullscreen windows" option.
If the window is detected as fullscreen compiz basically disables
itself and the window is drawn like it would be without compiz
running.

-- 
Travis Watkins
http://www.realistanew.com

Re: winetest issue on w2k and below

[Austin English]

On Thu, May 29, 2008 at 7:31 AM, Paul Vriens <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Lately I've been seeing an issue with winetest on Windows whereby the
> kernel32_test.exe file can't be deleted after the test.
>
> On NT4 I've also seen popups during the test with some remark about not being
> able to initialize user32.dll. This is when the process test is run for 
> kernel32.
>
> Anyone else seeing this? Or better yet, anyone know the cause?
>
> --
> Cheers,
>
> Paul.
>
>
>

-To list as well-

I've been seeing it for a week or so. 2K is also crashing the debugger
in a weird way, can't recall the exact error message, but it was a
second scarier message than usual.

Re: uninformed musings on ddraw + bugs 2082 and 1347 + dib engine

[Remco]

On Thu, May 29, 2008 at 5:21 PM, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> My recommendation is this:
> -> Talk to the beryl devs to get a way to disable compiz. We'll need this for
> fullscreen mode anyway, but we should not rely on it for windowed mode, since
> we can't disable compositing on MacOS. So we have to work around this problem

Doesn't Compiz already offer the "Unredirect Fullscreen Windows" option?

Remco

Re: Disabling Compiz (Was: uninformed musings on ddraw + bugs 2082 and 1347 + dib engine)

[Stefan Dösinger]

Am Donnerstag, 29. Mai 2008 17:36:26 schrieb Travis Watkins:
> We already allow this with the "Unredirect fullscreen windows" option.
> If the window is detected as fullscreen compiz basically disables
> itself and the window is drawn like it would be without compiz
> running.
That's perfect for our ddraw/d3d needs!

However, windows has a DLL which allows apps to disable Aero manually, I think 
that's wdm.dll. Do you expose any API which Wine could use to implement this?

Re: user32: Allow a NULL foreground window in the tests

[James Hawkins]

On Thu, May 29, 2008 at 10:21 AM, Dmitry Timoshkov
<[EMAIL PROTECTED]> wrote:
> "James Hawkins" <[EMAIL PROTECTED]> wrote:
>
>>> NULL foreground window is already allowed, you just need to fix the
>>> callers
>>> of check_wnd_state() to pass 0 for foreground.
>>>
>>
>> It's not consistent across platforms.
>
> Passing 0 for foreground will make the same thing as your patch - prevent
> failures when there is no consistent foreground window, i.e. when the test
> is useless.
>

Passing 0 for the foreground window essentially disables the test,
whereas allowing a NULL window is testing another variation of what
can happen with the foreground window, just like if a last error is,
e.g.,  ERROR_FILE_NOT_FOUND on one platform instead of
ERROR_PATH_NOT_FOUND.  Your method disables the test completely.

-- 
James Hawkins

Re: user32: Allow a NULL foreground window in the tests

[Dmitry Timoshkov]

"James Hawkins" <[EMAIL PROTECTED]> wrote:

>> NULL foreground window is already allowed, you just need to fix the callers
>> of check_wnd_state() to pass 0 for foreground.
>>
> 
> It's not consistent across platforms.

Passing 0 for foreground will make the same thing as your patch - prevent
failures when there is no consistent foreground window, i.e. when the test
is useless.

-- 
Dmitry.

Re: uninformed musings on ddraw + bugs 2082 and 1347 + dib engine

[Stefan Dösinger]

Am Donnerstag, 29. Mai 2008 13:39:57 schrieb Vincent Povirk:
> That page cites this blog (creepily similar to what I described, using
> one clientside buffer per X window, except when gdi+ddraw or virtual
> desktops are involved):
> http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx
Yeah, but it mentiones that it does the double buffering for GDI windows, not 
directx / directdraw ones. It also mentiones that drawing to the screen 
is "Bd!". Also I do not see how shadowing the window would help here; If 
we don't want to overwrite any non-wine part of the screen, setting up the 
clipping when drawing ddraw to the screen is ok.

I've done some testing with the font.exe ddraw sample from the dx sdk. This is 
an illustration what it looks like:
http://84.112.174.163/~stefan/font-wine.png

There are no special surprises when the window is not overlapped by any other 
window. The app draws to a HWND, not NULL. Surprises occur when another 
Window overlaps it. This here is from Windows XP:
http://stud4.tuwien.ac.at/~e0526822/ddrawtoscreen.bmp

As you can see, the ddraw updates overwrite the Explorer window. I have no 
idea why the font color is different though; It seems unimportant.

This is what happens on Vista with Aero off:
http://84.112.174.163/~stefan/font-vista.png

Now with aero on:
http://84.112.174.163/~stefan/font-aero.png
The aero-disabling screen flicker wasn't cought in the screenshot. However, 
you see the (german) aero-disable message. In the screenshot it has a nice 
fade effect, but on the screen it was flickering badly and not readable. A 
lot of other GUI elements were flickering too.

This shows at least how vista handles aero + ddraw apps - not at all. However, 
with the aero disabling it can keep the draw-to-screen semantics, and with 
fullscreen apps disabling aero doesn't hurt anyway. I roughly remember some 
Vista-disables-aero-with-quicktime-antitrust! whining about 1.5 years ago 
too.

> I think I've seen the ddraw sample you refer to (with gdi and ddraw
> windows), but I seem to have misplaced it. Last I checked, the desktop
> hack breaks it, and I think it uses SetHWnd for a clipper on its
> primary surface.
What you have to keep in mind is that ddraw checks the position of the dest 
window and adjusts the drawing coordinates accordingly. So if you just 
replace the HWND with NULL you get a wrong placement. You'll have to adjust 
x11_copy_to_screen in dlls/wined3d/surface.c as well.

We can work around the black screen issue with a fast way to read back the 
screen on frontbuffer locks. This is called glReadPixels + 
GL_ARB_pixel_buffer_object. However, for this we need a way to get the NULL 
hwnd semantics with opengl, which seems impossible so far.

My recommendation is this:
-> Talk to the beryl devs to get a way to disable compiz. We'll need this for 
fullscreen mode anyway, but we should not rely on it for windowed mode, since 
we can't disable compositing on MacOS. So we have to work around this problem

-> Continue to draw to the dest window with the gdi ddraw renderer. This keeps 
us Compiz and MacOS compatible, and I think we didn't have a problem that way 
so far

-> Ignore the quicktime-black-screen bug. Make Dan happy by switching to 
winver=Vista by default after 1.0

-> make x11_copy_to_screen draw to the NULL window to fix Diablo 1, Worms and 
others. First we have to make sure this doesn't break with compiz or on MacOS 
though.

Re: user32: Allow a NULL foreground window in the tests

[James Hawkins]

On Thu, May 29, 2008 at 10:07 AM, Dmitry Timoshkov
<[EMAIL PROTECTED]> wrote:
> "James Hawkins" <[EMAIL PROTECTED]> wrote:
>
>> According to msdn, "The foreground window can be NULL in certain
>> circumstances, such as when a window is losing activation. " which is
>> exactly when these failures occur.
>>
>> Changelog:
>> * Allow a NULL foreground window in the tests.
>
> NULL foreground window is already allowed, you just need to fix the callers
> of check_wnd_state() to pass 0 for foreground.
>

It's not consistent across platforms.

-- 
James Hawkins

Re: user32: Allow a NULL foreground window in the tests

[Dmitry Timoshkov]

"James Hawkins" <[EMAIL PROTECTED]> wrote:

> According to msdn, "The foreground window can be NULL in certain
> circumstances, such as when a window is losing activation. " which is
> exactly when these failures occur.
> 
> Changelog:
> * Allow a NULL foreground window in the tests.

NULL foreground window is already allowed, you just need to fix the callers
of check_wnd_state() to pass 0 for foreground.

-- 
Dmitry.

Re: advpack: Fix buffer sizes for possibly quoted strings (try 2, including testcase)

[James Hawkins]

On Thu, May 29, 2008 at 9:20 AM, Michael Karcher
<[EMAIL PROTECTED]> wrote:
> Increase buffer size to make quoted strings fit. This fixes the problem
> Dan described in
>  http://www.winehq.org/pipermail/wine-devel/2008-May/065954.html which
> is caused by quoted 'HKLM' not fitting into prefix. This patch does, on
> request, *not* fix the bigger picture issue that made it possible for
> this bug to slip for such a long time, which is missing error checking
> on SetupGetStringFieldW calls in get_dest_dir. Valid .inf files should,
> of course, not exercise the missing error check, so on valid .inf
> files, this patch is sufficient for correct behaviour.
>
> In the testcase with quoted 'HKLM', SetupGetStringFieldW fails because
> of unsufficient buffer size, which is *ignore* by the current code. As
> from the previous destination parsed in the patch the local automatic
> variable still contains the unquoted HKLM and by luck does not get
> overwritten between invocations of get_dest_dir, the testcase passes
> nevertheless except if compiled by gutsy's gcc 4.1 without optimization
> which puts the local variable to a stack location that does not survive
> between different invocations of get_dest_dir.
>
> The attached change to the testcase "pollutes" the local variable prefix
> with HKCU, so the bug is always exposed and not just by bad luck.
> ---
>  dlls/advpack/advpack.c |   10 +-
>  1 files changed, 5 insertions(+), 5 deletions(-)
>

You must've attached the wrong patch because there is no test case.
Also, don't make a change to the existing tests.  Please write a
completely new test that exposes just the one bug you're trying to
fix.  They're called 'unit' tests for a reason.

-- 
James Hawkins

Re: advpack: Fix buffer sizes for possibly quoted strings

[James Hawkins]

On Thu, May 29, 2008 at 8:58 AM, Michael Karcher
<[EMAIL PROTECTED]> wrote:
> Increase buffer size to make quoted strings fit. This fixes the problem
> Dan described in
>  http://www.winehq.org/pipermail/wine-devel/2008-May/065954.html which
> is caused by quoted 'HKLM' not fitting into prefix. This patch does, on
> request, *not* fix the bigger picture issue that made it possible for
> this bug to slip for such a long time, which is missing error checking
> on SetupGetStringFieldW calls in get_dest_dir. Valid .inf files should,
> of course, not exercise the missing error check, so on valid .inf
> files, this patch is sufficient for correct behaviour.
>
> In the testcase with quoted 'HKLM', SetupGetStringFieldW fails because
> of unsufficient buffer size, which is *ignore* by the current code. As
> from the previous destination parsed in the patch the local automatic
> variable still contains the unquoted HKLM and by luck does not get
> overwritten between invocations of get_dest_dir, the testcase passes
> nevertheless except if compiled by gutsy's gcc 4.1 without optimization
> which puts the local variable to a stack location that does not survive
> between different invocations of get_dest_dir.
> ---
>  dlls/advpack/advpack.c |   10 +-
>  1 files changed, 5 insertions(+), 5 deletions(-)
>

Add a test case please.

-- 
James Hawkins

Re: dxdiagn: PhysicalMemory parameter is a string not long long

[Alexandre Julliard]

Vitaliy Margolen <[EMAIL PROTECTED]> writes:

> Was anything wrong with this patch? I've used a simple utility 
> DxDiagOutput.exe from DXSDK to find and test this.

The printf format is wrong.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: dxdiagn: PhysicalMemory parameter is a string not long long

[Vitaliy Margolen]

Vitaliy Margolen wrote:
> ---
> dlls/dxdiagn/provider.c |7 ---
> 1 files changed, 4 insertions(+), 3 deletions(-)
> 

Was anything wrong with this patch? I've used a simple utility 
DxDiagOutput.exe from DXSDK to find and test this.

Vitaliy.

winetest issue on w2k and below

[Paul Vriens]

Hi,

Lately I've been seeing an issue with winetest on Windows whereby the 
kernel32_test.exe file can't be deleted after the test.

On NT4 I've also seen popups during the test with some remark about not being 
able to initialize user32.dll. This is when the process test is run for 
kernel32.

Anyone else seeing this? Or better yet, anyone know the cause?

-- 
Cheers,

Paul.

Re: uninformed musings on ddraw + bugs 2082 and 1347 + dib engine

[Vincent Povirk]

My information on Windows Vista comes from some things I happened to
read on Wikipedia for an unrelated reason:
http://en.wikipedia.org/wiki/Desktop_window_manager#Redirection

That page cites this blog (creepily similar to what I described, using
one clientside buffer per X window, except when gdi+ddraw or virtual
desktops are involved):
http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx

If an application wants to draw to the screen where there is no Wine
window (either the screen outside their window or with no window at
all), I think we will have to accept that this is impossible as long
as a compositing window manager is running. Such an application would
have to be run in a virtual desktop.

I do not have a copy of Windows Vista around to test any of this.

I think I've seen the ddraw sample you refer to (with gdi and ddraw
windows), but I seem to have misplaced it. Last I checked, the desktop
hack breaks it, and I think it uses SetHWnd for a clipper on its
primary surface.

-- 
Vincent Povirk

AppDB: More information about the test environment needed

[Groeschel, Volker]

I just found two conflicting reports for  Age of empires:
   http://appdb.winehq.org/objectManager.php?sClass=version&iId=10326
 
Both are on Ubuntu 8.04 and 1.0-rc1. One is Silver, one is Garbage. But
it is just one example.
 
My suggestion is to ask for more information about the test environment.
 
To specify it I think it would be helpfull to know the grafics chip/card
and the used driver.
 
With the new free drivers around the block it could be even more
helpfull to have this information.
 
The same ATI card e.g. could use Radeon, RadeonHD or the Catalyst
driver.
 
The same is true for Nvidia with nvidia, nv and Nouveau driver.
 
I often read that Wine developers recommend nvidia, but I actually have
good experience with radeon. 
 
It is quite hard to get real informaltion on this topic.
 
 

Re: [1/2] tests: Add functions to make it possible to handle Windows misbehaviors that we don't want to reproduce in Wine.

[Alexandre Julliard]

Francois Gouget <[EMAIL PROTECTED]> writes:

> This patch introduces the buggy(), deprecated() and strict_wine 
> functions I mentioned in: 
> http://www.winehq.org/pipermail/wine-devel/2008-April/065322.html

I like the idea, but I don't think this should copy the todo mechanism,
as it doesn't scale well. For todo that's OK because the number of todos
is supposed to remain small, and get smaller as Wine improves; but
strict checking is something we'll want more and more of, so ultimately
we'll have them all over the place. It gets even worse if we want to be
strict for other platforms too.

So I would suggest to not add a strict(platform), but make buggy() and
deprecated() always do strict checking except when platform is
"windows".  If we need to have a buggy() check succeed on Wine for
some reason it can always be wrapped in a todo_wine.

-- 
Alexandre Julliard
[EMAIL PROTECTED]