Re: ieframe: Use SHANDLE_PTR in IWebBrowserApp::get_HWND.
Sorry, should have replied to this. These tests shouldn't even run on 2000, already seen e.g. in http://www.winehq.org/pipermail/wine-devel/2013-April/099536.html http://www.winehq.org/pipermail/wine-devel/2012-November/097823.html Let me know if there's any issues. Thanks, Thomas On 2013-07-14 13:04, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=26282 > > Your paranoid android. > > > === W2KPROSP4 (32 bit webbrowser) === > webbrowser.c:2631: Test failed: expected GetOverridesKeyPath > webbrowser.c:2636: Test failed: expected Invoke_SETSECURELOCKICON > webbrowser.c:2637: Test failed: expected Invoke_FILEDOWNLOAD > webbrowser.c:3076: Test failed: doc_disp == NULL > webbrowser: unhandled exception c005 at 004033D1
Re: Manpage patch, please review
Am 16.07.2013 19:59, schrieb Julian Rüger: > Hi all! > > While working on the translation of the (main) manpage, I noticed a few > issues in the English version and started working on a patch. That was > quite some time ago, I had little spare time lately and didn't get > around to finish and send it in. So I figured I just take what I have > now and ask you guys for comments. I appreciate any remarks or > suggestions. > > Thanks, > Julian > > Notes: > > I had a change similar to Frédéric's, mentioning wine can run 64-bit > programs now. He was quicker and I like his wording better. I had > something like "[...]or Win64 executable (if your version of wine was > compiled with 64-bit support)." > I guess that would be more confusing to people using their distro's wine > packages and people compiling their own wine know that anyway. > Do you agree or do you think it's better to be more specific? Frédéric has done it quite good, because it's committed :) Further you can't compile Wine in 64-bit mode on 32-bit that easily, and you can't run it, your version doesn't handle that. > CUI -> CLI: > According to Google and Wikipedia, CLI is more common. i'd say that's analogue to IMAGE_SUBSYSTEM_WINDOWS_CUI > -.BR @bindir@/wineserver , > +.IR @bindir@/wineserver , > and following, similar changes: > > This is the way it is formatted in the wineserver manpage. I noticed > there is no uniform style across our manpages, so we should have a > guideline. > Should paths be bold or italic/underlined? Not sure, are there other guidelines out there we can use?
Manpage patch, please review
Hi all! While working on the translation of the (main) manpage, I noticed a few issues in the English version and started working on a patch. That was quite some time ago, I had little spare time lately and didn't get around to finish and send it in. So I figured I just take what I have now and ask you guys for comments. I appreciate any remarks or suggestions. Thanks, Julian Notes: I had a change similar to Frédéric's, mentioning wine can run 64-bit programs now. He was quicker and I like his wording better. I had something like "[...]or Win64 executable (if your version of wine was compiled with 64-bit support)." I guess that would be more confusing to people using their distro's wine packages and people compiling their own wine know that anyway. Do you agree or do you think it's better to be more specific? CUI -> CLI: According to Google and Wikipedia, CLI is more common. -.BR @bindir@/wineserver , +.IR @bindir@/wineserver , and following, similar changes: This is the way it is formatted in the wineserver manpage. I noticed there is no uniform style across our manpages, so we should have a guideline. Should paths be bold or italic/underlined? >From 66391fbb22bdb150333b99e05250df4a3fa6f3f5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Julian=20R=C3=BCger?= Date: Tue, 16 Jul 2013 19:29:34 +0200 Subject: loader: Various small manpage improvements. --- loader/wine.man.in | 56 1 file changed, 26 insertions(+), 30 deletions(-) diff --git a/loader/wine.man.in b/loader/wine.man.in index aac5e75..84db685 100644 --- a/loader/wine.man.in +++ b/loader/wine.man.in @@ -1,4 +1,5 @@ -.TH WINE 1 "July 2013" "@PACKAGE_STRING@" "Windows On Unix" +.\" -*- nroff -*- +.TH WINE 1 "October 2005" "@PACKAGE_STRING@" "Windows On Unix" .SH NAME wine \- run Windows programs on Unix .SH SYNOPSIS @@ -10,8 +11,7 @@ wine \- run Windows programs on Unix .B wine --version .PP For instructions on passing arguments to Windows programs, please see the -.B -PROGRAM/ARGUMENTS +.B PROGRAM/ARGUMENTS section of the man page. .SH DESCRIPTION .B wine @@ -22,14 +22,14 @@ For debugging wine, use .B winedbg instead. .PP -For running CUI executables (Windows console programs), use +For running CLI executables (Windows console programs), use .B wineconsole instead of .BR wine . -This will display all the output in a separate windows (this requires X11 to -run). Not using +This will display the program's output in a separate window (requires a +graphical environment using the X11 or Mac driver to run). Not using .B wineconsole -for CUI programs will only provide very limited console support, and your +for CLI programs will provide very limited console support, and your program might not function properly. .PP When invoked with @@ -44,8 +44,8 @@ The program name may be specified in DOS format .RI ( C:\(rs\(rsWINDOWS\(rs\(rsSOL.EXE ) or in Unix format .RI ( /msdos/windows/sol.exe ). -You may pass arguments to the program being executed by adding them to the -end of the command line invoking +You may pass arguments to the program being executed by appending them to the +command line invoking .B wine (such as: wine notepad C:\(rs\(rsTEMP\(rs\(rsREADME.TXT). Note that you need to '\(rs' escape special characters (and spaces) when invoking Wine via @@ -55,48 +55,44 @@ wine C:\(rs\(rsProgram\(rs Files\(rs\(rsMyPrg\(rs\(rstest.exe .PP .SH ENVIRONMENT VARIABLES .B wine -makes the environment variables of the shell from which -.B wine -is started accessible to the windows/dos processes started. So use the -appropriate syntax for your shell to enter environment variables you need. -.TP +makes the environment variables of the shell from which it is run accessible +to the windows/dos processes started. Use the appropriate syntax for your +shell to enter environment variables you need. +.TP .I WINEPREFIX If set, the content of this variable is taken as the name of the directory where .B wine -stores its data (the default is +stores it's data (the default is .IR $HOME/.wine ). -This directory is also used to identify the socket which is used to -communicate with the +This directory is also used to determine the socket used for communication with the .IR wineserver . All .B wine processes using the same .B wineserver (i.e.: same user) share certain things like registry, shared memory, -and config file. +and kernel objects. By setting .I WINEPREFIX to different values for different .B wine -processes, it is possible to run a number of truly independent -.B wine -processes. +processes, it is possible to run a number of truly independent sessions. .TP .I WINESERVER Specifies the path and name of the .B wineserver binary. If not set, Wine will try to load -.BR @bindir@/wineserver , +.IR @bindir@/wineserver , and if this doesn't exist it will then look for a file named -"wineserver" in the path and in a few other likely locations. +\fIwineserver\fR in the
Re: loader: Indicate wine can run 64-bit apps in manpage
On Tue, Jul 16, 2013 at 4:57 PM, Frédéric Delanoy wrote: > --- > loader/wine.man.in | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) Please ignore this patch: I accidentally resent it. Sorry about the noise. Frédéric
Re: po: Update Turkish translation (second try)
-<<< HEAD -"PO-Revision-Date: 2013-07-13 04:49+0200\n" -=== -"PO-Revision-Date: 2013-07-04 00:10+0200\n" ->>> 598685e6c5992355de35b4345e91eb4e50b9f07e +"PO-Revision-Date: 2013-07-13 05:00+0200\n" [...] -#: attrib.rc:27 cmd.rc:322 +#: attrib.rc:27 cmd.rc:325 These look wrong: there is currently no conflict in the checked-in PO file and there should not be any line-number changes in the patch. So it won't apply to the current Git repository. Something must have happened when you rebased or generated the diff. -- Francois Gouget http://fgouget.free.fr/ In a world without fences who needs Gates?
Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.
On Mon, Jul 15, 2013 at 7:02 PM, Alexandre Julliard wrote: > This looks like a better approach, yes Sorry, this approach doesn't work as I expected, further investigation show that posted messages would be processed before input messages, msdn confirms it: --- quote --- If no filter is specified, messages are processed in the following order: Sent messages Posted messages Input (hardware) messages and system internal events Sent messages (again) WM_PAINT messages WM_TIMER messages --- quote --- msdn also said: To retrieve input messages before posted messages, use the wMsgFilterMin and wMsgFilterMaxparameters. However, even we can change the filter in our test, native Popup WndProc still receive posted messages before input message because it has its own message loop and we can't (and of cause we shouldn't) change it. This situation run out of my head, I can't find any easy way to fix it, I doubt if there is any way better than the original patch (patch 97161, pending). I'm open to any suggestion, thanks! If no better solution I hope patch 97161 is acceptable. -- Regards, Qian Hong - http://www.codeweavers.com
Re: ntdll: Tests for RtlHashUnicodeString()
Nikolay Sivov wrote: > >> +#include "ddk/wdm.h" > > Please don't do that, this breaks compilation with PSDK headers. If you need > > some specific definitions, types or API prototypes - replicate them in the > > test > > itself. > What breaks exactly? The fact that PSDK doesn't have DDK headers by > default or something specific about this particular header? If it's a > missing header I don't see a problem with installing DDK. Also kernel32 > tests have include from ddk subdir too and I don't even have this header > installed with DDK 7.something, is it broken for you too? Yes, it's the missing ddk subdirectory which breaks things. Installing a DDK was never a requirement for compiling Wine tests under Windows, and I hope there will never be one. The only kernel32 test that has #include "ddk/..." is volume.c, that can't be an excuse to adding more broken tests, it's better to fix volume.c instead. I'd suggest to try compiling Wine tests under Windows with a PSDK compiler using Wine and PSDK headers as a simple exercise. Once this works, try to add DDK headers as another complexity level, then decide whether you really would like to add another hoop to jump through. Compilation with a PSDK tool chain and PSDK headers is an extremely valuable thing for testing, it would be a pity to lose it. -- Dmitry.
