Re: [PATCH] cmd: Add help info for xcopy
On 10/09/2011 00:56, Octavian Voicu wrote: 2011/9/9 Frédéric Delanoy frederic.dela...@gmail.com mailto:frederic.dela...@gmail.com Patch is OK, but for consistency, shouldn't the externals be put at the start of wcmdmain.c, just after the inbuilt[][]10]? This way, you could see directly which command is built-in, and which is external. + make it static const, since it's not used outside of builtins.c. Octavian That's true in that case but the list will go to another file. I sent a patch for that. Christian
Re: Marking test cases as flaky?
Stefan Dösinger stefandoesin...@gmx.at writes: On Saturday 10 September 2011 21:56:26 Dan Kegel wrote: Might want to define the new form as ok2_ or something so we can defer changing the explicit uses of ok_(). I dislike the idea, it has the feeling of legacy cruft. Either way it is a fairly minor point - the main change that needs debating is whether we should print the function name or not. We don't want that by default, especially since __FUNCTION__ is not portable. If you have cases where you get frequent failures that are hard to debug, you can always print extra info in the ok message. -- Alexandre Julliard julli...@winehq.org
Re: Auto-selecting local variable/parameters when 'p'rinting values using winedbg?
2011/9/9 Eric Pouech eric.pou...@orange.fr: WineDbg set ! symbol_picker scoped will do what you want unfortunately, there's no way to store it as a default command (you can always use --command or --file on command line to help) A+ Speaking of --command and --file options, they aren't documented either. I'm willing to update winedev guide, but I'd like more info first. I found that --file accepts the set of commands to execute (but winedbg exits afterwards), but what does --command do? Is there a way to specify initial commands to execute, then stay *inside* winedbg after the last command of the file is issued? Frédéric
Re: Auto-selecting local variable/parameters when 'p'rinting values using winedbg?
2011/9/12 Frédéric Delanoy frederic.dela...@gmail.com: I found that --file accepts the set of commands to execute (but winedbg exits afterwards), but what does --command do? OK --command simply executes a single command and exits/continues the program until termination. Is there a way to specify initial commands to execute, then stay *inside* winedbg after the last command of the file is issued? Or maybe I should use stuff like 'expect' to do that? Frédéric
Re: [1/3] msxml3: Add xmlparser interfaces
Hi Francois, I think that's the problem. Wine reimplements the Windows' Platform SDK Win32 and Win64 APIs, not Windows Mobile which is what the PowerPC SDK is. Apparently there are some differences so it would be best not to mix the two. Note that this is not to say that Wine should not also implement the Windows Mobile API, just that adding support for it would require larger adjustments. It shouldn't be a problem, this is the only place you can get a reference to these interfaces. It appears that once these interfaces were Deprecated they where removed from the SDK for msxml. See MSDN to show that they now deprecated, and they aren't just for Mobile Devices. http://msdn.microsoft.com/en-us/library/ms757816%28VS.85%29.aspx It was part of the msxml3 at some point on windows, see bug http://bugs.winehq.org/show_bug.cgi?id=5841 Best Regards Alistair Leslie-Hughes
Re: [PATCH 07/21] vbscript: Added interpreter support for numeric literals
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=14152 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
Re: [PATCH 08/21] vbscript: Added hex literal implementation
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=14153 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
Re: [PATCH 13/21] vbscript: Added interp_neg implementation
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=14155 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
Re: [PATCH 15/21] vbscript: Added interp_add implementation
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=14156 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
Re: [1/3] msxml3: Add xmlparser interfaces
Alistair Leslie-Hughes wrote: It shouldn't be a problem, this is the only place you can get a reference to these interfaces. It appears that once these interfaces were Deprecated they where removed from the SDK for msxml. See MSDN to show that they now deprecated, and they aren't just for Mobile Devices. In that case you should be able to find appropriate definitions in older PSDK versions. -- Dmitry.
Re: [PATCH 16/21] vbscript: Added interp_sub implementation
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=14157 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
Re: [PATCH 17/21] vbscript: Added '' expression implementation
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=14158 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
audio: when is a Resource temporarily unavailable?
Hi, Bug #28056 involving FreeBSD and OSS exhibits: warn:oss:AudioRenderClient_ReleaseBuffer write failed: 35 (Resource temporarily unavailable) My own notes from times as old as wine-1.1.8 show the same error with ALSA: err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable The symbolic errno constant is EAGAIN=EWOULDBLOCK. Does anybody have a suspicion when/why this happens? - is audio simply not reliable? - is Wine not correctly driving audio output? - ...? FWIW, my test experiments outside Wine recently produced EWOULDBLOCK once despite non-blocking mode in ALSA, when attempting to write a small number of frames, less than period_size. Is this failure really temporary or would it be safer to close or reset the audio device given such an error value? What's your experience? Thank you, Jörg Höhle
Support for alternate data streams in NtCreateFile?
Hi, What is the support status of (NTFS) names streams in wine? I only see include/winnt.h:4788:#define FILE_NAMED_STREAMS 0x0004 but it doesn't seem to be used anywhere else in the code. (there's probably no possible translation in most filesystems) NtCreateFile (hence cmd) currently happily creates files/directories with colons in them, while it probably shouldn't for most FS. I'm asking this because ':' is normally disallowed in file/dirnames (http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx), and was trying to add tests in ntdll/tests/file.c, except when named streams are supported by the underlying FS. Should I test the flags returned from GetVolumeInformation, and add tests for both named-stream-allowed and non-named-stream allowed FSs? Or should I assume that named streams won't ever be implemented and assume colons are disallowed, without checking the FILE_NAMED_STREAMS flag? Frédéric
Re: [PATCH 2/4] ntdll: Colon character is not allowed in dir/filenames
Frédéric Delanoy frederic.dela...@gmail.com writes:
@@ -162,6 +162,7 @@ static void create_file_test(void)
'\\','f','a','i','l','i','n','g',0};
static const WCHAR questionmarkInvalidNameW[] =
{'a','f','i','l','e','?',0};
static const WCHAR pipeInvalidNameW[] = {'a','|','b',0};
+static const WCHAR colonInvalidNameW[] = {':','c',0};
That's not a good test file name...
--
Alexandre Julliard
julli...@winehq.org
Re: Support for alternate data streams in NtCreateFile?
Frédéric Delanoy frederic.dela...@gmail.com writes: Hi, What is the support status of (NTFS) names streams in wine? I only see include/winnt.h:4788:#define FILE_NAMED_STREAMS 0x0004 but it doesn't seem to be used anywhere else in the code. (there's probably no possible translation in most filesystems) It's kind of supported, by simply not doing anything special and creating separate files. -- Alexandre Julliard julli...@winehq.org
Re: dpnet: return a TCP/IP provider in IDirectPlay8PeerImpl_EnumServiceProviders (try 2)
Louis Lenders xerox_xerox2...@yahoo.co.uk writes: changes from try1: remove erraneous HeapFree That's not much better. -- Alexandre Julliard julli...@winehq.org
Re: attrib: Add quotes to fix the usage message indentation.
Francois Gouget fgou...@free.fr writes: --- Start-of-line spaces are ignored in RC files. That syntax is not supported by RC, so it's best avoided. -- Alexandre Julliard julli...@winehq.org
Re: [5/5] ddraw: Use a Z format suported by the driver in the visual test
I see this problem made it into wine-git. This is going to make the gcc-2.95 bot fail on every build. I'll plop a fix in locally to pacify it for now and/or disable email from the gcc-2.95 bot. On Sun, Sep 11, 2011 at 4:29 PM, Dan Kegel d...@kegel.com wrote: Fails to compile on gcc-2.95 here: visual.c: In function `enum_z_fmt': visual.c:61: request for member `u1' in something not a structure or union visual.c:61: request for member `u1' in something not a structure or union make[1]: *** [visual.o] Error 1 make: *** [dlls/ddraw/tests] Error 2 -- Forwarded message -- From: build...@kegel.com Date: Sun, Sep 11, 2011 at 1:56 PM Subject: Re: 78663: Subject: [5/5] ddraw: Use a Z format suported by the driver in the visual test To: d...@kegel.com This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. The Buildbot has detected a failed build on builder runtests-gcc295 while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-gcc295/builds/31 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_2 For more info about this message, see http://wiki.winehq.org/BuildBot
RFC: Translating Wine's dialogs with PO files
This is the next step in making full use of the PO files for translating Wine. But how to get there is unclear, hence this RFC. The issue with dialogs is that in RC files all the dialog and control sizes are hardcoded. For instance in the line below '208, 6, 56, 14' represent the x-left, y-top, width and height of the button: DEFPUSHBUTTON Save As, IDOK, 208, 6, 56, 14, BS_DEFPUSHBUTTON | WS_GROUP | WS_TABSTOP The problem is that once translated to French, for instance, the label becomes 'Enregistrer sous' which is much longer and may require enlarging the button. But RC files do not contain the information needed to do that automatically. For instance they don't specify enlarging this button requires enlarging the 'Cancel' and 'Help' buttons below too. So how do we solve this problem? Option 1 - Automatically layout the dialogs at compile time --- Gtk applications solve this problem by storing all the information needed to automatically layout dialogs in an XML file. The size and location of all the controls is then computed at runtime, after the dialog has been translated. We could do something similar, it would go something like this: * Use some format that lets us store all the layout information as the primary definition for Wine's dialogs. * At compile time translate the dialogs. * For each translation, layout the dialog and generate an RC file containing the computed control coordinates and sizes. * Then compile the RC files as usual. (alternatively the last two steps could be merged) Questions: * Which format should we use to define the layout? - Glade is the format used by Gtk. However it seems pretty Gtk centric and the set of controls/properties it supports may not match the Windows ones. It's possible to add libraries of custom widgets so that may be a solution. http://en.wikipedia.org/wiki/Glade_Interface_Designer - It looks like Microsoft added support for auto-layout in WPF (Windows Presentation Foundation) for .Net applications. This information can be stored in XAML XML files. http://msdn.microsoft.com/en-us/library/ms750441.aspx https://github.com/yadyn/WPF-Task-Dialog/blob/master/TaskDialog/CommandLink.xaml Does anyone know how this works? Is it something we would need to implement in Wine anyway? Does some project already have support for it? Mono maybe? - For completeness I'll also mention that WxWidget also has a cross-platform layout engine. http://docs.wxwidgets.org/2.9.2/overview_xrc.html However as far as I know, none of them has tools that can generate RC files. * How can we do the layout? - Can we reuse a third-party layout engine? Like the one used for Glade files? - Wouldn't that introduce troublesome build dependencies? - Would it be ok if these dependencies are needed only when in maintainer mode? (In maintainer mode a change to a PO file could trigger an update to the corresponding RC files which would then be committed with the PO file change.) - Should we instead implement it all by ourselves? * How can we mesure the size that strings will take at run time? We probably have all the code we need in Wine. But can we use it are compile time? Will the computed layout depend on the fonts that are installed on the system where Wine is compiled? This is particularly important for languages with non-latin characters such as Japanese, Hebrew or Telugu. Pros: * We would not have to manually layout dialogs ever again. Yay! * We might be able to reuse the graphical dialog design tools of the system we adopt, like Glade or possibly some .Net tools. * There would be no risk of the translation and layout getting out of sync. * We would no longer need one RC file per language, thus eliminating the risk that they become out of sync (e.g. adding a given window style to some but not all languages). Cons: * Just integrating support for the layout engine and generating RC files seems like a lot of work. * Potential for additional build-time third-party dependencies for the layout engine. * Would require rewritting all our dialogs so they have all the needed layout information. That is definitely a lot of work. Option 2 - Add layout information to RC files - The idea here is the same as for option 1 except that we would add the layout information as comments in the existing RC files. As a very rough exemple it could look something like this: #layout# start box(orientation = vertical, padding = 8) #layout# start button(expand = true, fill = true) DEFPUSHBUTTON Save As, IDOK, 208, 6, 56, 14, BS_DEFPUSHBUTTON | WS_GROUP | WS_TABSTOP #layout# end button ... #layout# end box Pros: * Same as for option 1. Cons: * We would be inventing
Re: RFC: Translating Wine's dialogs with PO files
Hello Francois, before I start: my comment below in no way implies that option 4 is the way to go. On 09/12/2011 07:28 PM, Francois Gouget wrote: Option 4 - Put the sizes in special PO files This would really be a very ugly hack. Like option 2 it requires that every control of a given dialog have a unique id. Then for each of them we would create PO file entries of the form: msgctxt rc-filename:dialog-id:control-id msgid x:y:width:height msgstr You wouldn't need a special PO file. You could put that info into a comment of the respective entry to translate using the #. comment. http://www.gnu.org/s/hello/manual/gettext/PO-Files.html says: Comment lines starting with #. contain comments given by the programmer, directed at the translator; these comments are called extracted comments because the xgettext program extracts them from the program's source code. This would avoid separate files, unique IDs for all the entries and would be visible to the translator. bye michael We then put all these 'messages' in a sizes-lang.po file. Whenever a control needs to be resized a 'translation' would be provided in the relevant sizes-lang.po file. We would only keep the English RC file and when compiling the resources for a given language wrc would check whether the sizes-lang.po file contains a translation of the size data for the current control. Pros: * Maybe the easiest solution to put in place. Cons: * Totally ugly. * Probably awful to work with to change the layout of a dialog. * All the drawbacks of Option 2.
Re: RFC: Translating Wine's dialogs with PO files
Francois Gouget fgou...@free.fr writes: This is the next step in making full use of the PO files for translating Wine. But how to get there is unclear, hence this RFC. The issue with dialogs is that in RC files all the dialog and control sizes are hardcoded. For instance in the line below '208, 6, 56, 14' represent the x-left, y-top, width and height of the button: DEFPUSHBUTTON Save As, IDOK, 208, 6, 56, 14, BS_DEFPUSHBUTTON | WS_GROUP | WS_TABSTOP The problem is that once translated to French, for instance, the label becomes 'Enregistrer sous' which is much longer and may require enlarging the button. But RC files do not contain the information needed to do that automatically. For instance they don't specify enlarging this button requires enlarging the 'Cancel' and 'Help' buttons below too. So how do we solve this problem? There's another option: design the dialogs with enough spare room that most languages would fit, and maintain language-specific RC files for the special cases that really can't be accommodated. Ideally, a tool would be written to warn about a translation overflowing the available space, so that it can be looked into. Not very satisfying, but a lot simpler than the other options... -- Alexandre Julliard julli...@winehq.org
Re: RFC: Translating Wine's dialogs with PO files
On Mon, 12 Sep 2011, Michael Stefaniuc wrote: [...] Like option 2 it requires that every control of a given dialog have a unique id. Then for each of them we would create PO file entries of the form: msgctxt rc-filename:dialog-id:control-id msgid x:y:width:height msgstr You wouldn't need a special PO file. You could put that info into a comment of the respective entry to translate using the #. comment. [...] This would avoid separate files, unique IDs for all the entries and would be visible to the translator. This would be pretty tricky for a button like 'OK' which appears in a great many dialogs, each time in a different position. Also even if it is in the same position in two English dialogs, once translated it may need to be in different positions (due to other controls being resized). So that brings back the need for uniquely identifying a given control. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS
Re: Auto-selecting local variable/parameters when 'p'rinting values using winedbg?
Le 12/09/2011 10:32, Frédéric Delanoy a écrit : 2011/9/12 Frédéric Delanoyfrederic.dela...@gmail.com: I found that --file accepts the set of commands to execute (but winedbg exits afterwards), but what does --command do? OK --command simply executes a single command and exits/continues the program until termination. Is there a way to specify initial commands to execute, then stay *inside* winedbg after the last command of the file is issued? not currently Or maybe I should use stuff like 'expect' to do that? IMO, the best solution would be to: - let winedbg have a default init command file (say .winedbgrc) to be loaded at startup (if the file exists in current directory, then in ~ directory...) - add to generic options to winedbg: + the first one to give an alternate name to default .winedbgrc file (or to locate it) + the second one to tell winedbg not to load the default file regarding the 'expect' stuff, you can look at the automaton to test winedbg https://github.com/ericZp/wdtp not sure it fully matches what you want to do, but it can help A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: RFC: Translating Wine's dialogs with PO files
On 09/12/2011 08:14 PM, Alexandre Julliard wrote: Francois Gouget fgou...@free.fr writes: This is the next step in making full use of the PO files for translating Wine. But how to get there is unclear, hence this RFC. The issue with dialogs is that in RC files all the dialog and control sizes are hardcoded. For instance in the line below '208, 6, 56, 14' represent the x-left, y-top, width and height of the button: DEFPUSHBUTTON Save As, IDOK, 208, 6, 56, 14, BS_DEFPUSHBUTTON | WS_GROUP | WS_TABSTOP The problem is that once translated to French, for instance, the label becomes 'Enregistrer sous' which is much longer and may require enlarging the button. But RC files do not contain the information needed to do that automatically. For instance they don't specify enlarging this button requires enlarging the 'Cancel' and 'Help' buttons below too. So how do we solve this problem? There's another option: design the dialogs with enough spare room that So we need somebody that can design dialogs. From the scope it is a similar job to the icon modernization/standardization done by Joel. Which isn't a bad thing as our dialogs have a pretty inconsistent look and feel. most languages would fit, and maintain language-specific RC files for the special cases that really can't be accommodated. Ideally, a tool would be written to warn about a translation overflowing the available IMHO we need this tool first to ease the work of the person cleaning up the dialogs; we don't want him/her to run away screaming after the first few dialogs. space, so that it can be looked into. Not very satisfying, but a lot simpler than the other options... And has the buy in of the Wine maintainer... SHIP IT! ;) bye michael
