February 2014 - Wine-Devel - list.winehq.org

Re: Assorted spelling fixes

by Francois Gouget

On Sun, 16 Feb 2014, Dmitry Timoshkov wrote: [...] > > >> - cab_ULONG window_size; /* window size (1Kb through 2Mb) */ > > >> + cab_ULONG window_size; /* window size (1 KB through 2 MB) */ [...] > In my years of University the students were told to remember that > 1Kb == 1024 bytes, 1Mb == 1024Kb and size prefixes should be written > as a capital letter to emphasize its meaning. '1Kb' is some number of bits, not bytes and is nowhere close to 1024 bytes. So that's one thing that really needed fixing in the old comment. Now as for the always confusing 1000 vs 1024 ambiguity and kB vs. KB vs. KiB aspect I don't care. Reference: * https://en.wikipedia.org/wiki/Bit The symbol for bit, as a unit of information, is either simply bit (recommended by the ISO/IEC standard 80000-13 (2008)) or lowercase b (recommended by the IEEE 1541 Standard (2002)). * https://en.wikipedia.org/wiki/Byte#Unit_symbol The unit symbol for the byte is specified in IEC 80000-13, IEEE 1541 and the Metric Interchange Format as the upper-case character B. The unit symbol kB is commonly used for kilobyte, but may be confused with the still often-used abbreviation of kb for kilobit. IEEE 1541 specifies the lower case character b as the symbol for bit; however, IEC 80000-13 and Metric-Interchange-Format specify the abbreviation bit (e.g., Mbit for megabit) for the symbol, providing disambiguation from B for byte. * https://en.wikipedia.org/wiki/Kilobyte All existing recommendations prefer to use the uppercase letter B for byte, because b is used for the bit. Just as a note, in the GUI we seem to be using 'k' (*), 'kB', 'MB' and 'GB'. If anyone wants to change the first two to 'KB' I'm fine with that. The 'KiB' variants may prove too confusing for non technical users however. (*) Look for '64k'. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

Feb. 16, 2014

Re: Questions about filename_tests in dlls/shell32/tests/shlexec.c

by Dmitry Timoshkov

Zhenbo Li <litimetal(a)gmail.com> wrote: > I checked wine test errors, and found some errors for > dlls/shell32/tests/shlexec.c[1]. I wanted to fix bugs in > 'static void test_filename(void)'. Probably you should explain first what bugs you want to fix. -- Dmitry.

Feb. 16, 2014

Re: Questions about filename_tests in dlls/shell32/tests/shlexec.c

by Francois Gouget

On Sun, 16 Feb 2014, Zhenbo Li wrote: [...] > However, I can't understand the intention of previous code: All > testcases are put into > 'static filename_tests_t filename_tests[]', > then they are tested via a while-loop. I think it is difficult to locate > *which* testcase really fails. > > Is re-factoring such code encouraged? If so, I'm glad to do it. No. The goal of this test structure is to avoid lots of code duplication. To compensate with the line number being of little use, the failure message prints the full data on what was tested. For instance the first failure is: shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD671.tmp\test file.noassoc") WaitForSingleObject returned 258 The verb is empty and the base filename 'test file.noassoc' so this corresponds to: /* Test filenames with no association */ {NULL, "%s\\test file.noassoc", 0x0, SE_ERR_NOASSOC}, It turns out I looked into this a bit and in fact all the 'returned 258' errors have the same cause: Windows 8 pops up a 'dialog' that asks whether to look for an app in the Microsoft Store to handle the unknown file extension. shell_execute() has some code to deal with those which centers on: HWND wnd = FindWindowA("#32770", "Windows"); That line is supposed to detect the dialog popped up by Windows, dismiss it and note to skip further tests that could trigger it. The problem is that on Windows 8 the 'dialog' has changed: it's a window with no decoration that looks very much like the Metro apps. So it's too different and thus is not detected. I tried to figure out what class or title that window has using Spy++ but any time I click outside it, it disappears. That's where I got stuck. So if anyone wants to take over... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.

Feb. 16, 2014

Questions about filename_tests in dlls/shell32/tests/shlexec.c

by Zhenbo Li

Hello, I checked wine test errors, and found some errors for dlls/shell32/tests/shlexec.c[1]. I wanted to fix bugs in 'static void test_filename(void)'. However, I can't understand the intention of previous code: All testcases are put into 'static filename_tests_t filename_tests[]', then they are tested via a while-loop. I think it is difficult to locate *which* testcase really fails. Is re-factoring such code encouraged? If so, I'm glad to do it. I really appreciate all finds of ideas. Thank you. [1]: http://test.winehq.org/data/aa22a3c4b2e772636163ea50e7245dba01fe7b34/win8_n… Zhenbo Li

Feb. 16, 2014

Re: Assorted spelling fixes

by Dmitry Timoshkov

Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > - cab_ULONG window_size; /* window size (1Kb through 2Mb) */ > + cab_ULONG window_size; /* window size (1 KB through 2 MB) */ This is not the typos, that's a common way of writing sizes by programmers, personally I prefer the old form (and will keep using it in future) and hate the "fixed" variant. Please avoid this kind of "fixes". -- Dmitry.

Feb. 16, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Ken Thomases

On Feb 16, 2014, at 3:06 AM, Christopher Thielen wrote: > No luck so far: I ran the application for about 30 seconds and generated a 975 MB log file but a case insensitive "overlay" appears not at all. To keep the log size down, you could try a warn+ddraw,warn+d3d,warn+d3d_surface log, instead. > Since this missing secondary mouse cursor only appears during certain game states, one idea I had is to look at the 'fixme's in the log and see if any roughly correlate to when the cursor should be on-screen. This is assuming the log growth correlates to game-time, which it probably does with the exception of program start and stop. > > I don't know if that's the next best way to debug this but there are two fixme lines that come up a lot (hundreds and hundreds of times): > > fixme:d3d:wined3d_debug_location Unrecognized location flag(s) 0xfffffc00. The wined3d_debug_location() function is used in other tracing lines. So, to figure out what is affected by it, you would want to read the next line or two from the log. > fixme:d3d:debug_d3dusage Unrecognized usage flag(s) 0x10000000 Same here. These both may go away if you reduce the logging to just WARNs (and ERRs and FIXMEs which are enabled by default). It's possible they were only be generated by TRACEs. -Ken

Feb. 16, 2014

Re: Assorted spelling fixes

by Henri Verbeet

On 16 February 2014 09:57, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > In my years of University the students were told to remember that > 1Kb == 1024 bytes, 1Mb == 1024Kb and size prefixes should be written > as a capital letter to emphasize its meaning. I'm very reluctant to > change this practice to something else regardless of explanations and > intents. I understand that for not technical people 1K == 1000, but > I'd assume programmers are not of that kind. > Strictly speaking the SI units are kB, etc. for 1000 bytes, and IEC KiB, etc. for 1024 bytes. For memory sizes, it's usually obvious enough from context which one is meant, so there's not much of a point to change it. It's more ambiguous for e.g. file or disk sizes where drive vendors often use 1000 based units, and transfer speeds where "b" usually means bits. But as I said, in most cases it's obvious enough from context, and "KB" instead of "Kb" isn't really much clearer.

Feb. 16, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Christopher Thielen

No luck so far: I ran the application for about 30 seconds and generated a 975 MB log file but a case insensitive "overlay" appears not at all. Since this missing secondary mouse cursor only appears during certain game states, one idea I had is to look at the 'fixme's in the log and see if any roughly correlate to when the cursor should be on-screen. This is assuming the log growth correlates to game-time, which it probably does with the exception of program start and stop. I don't know if that's the next best way to debug this but there are two fixme lines that come up a lot (hundreds and hundreds of times): fixme:d3d:wined3d_debug_location Unrecognized location flag(s) 0xfffffc00. (and somewhat less often though still prevalent): fixme:d3d:debug_d3dusage Unrecognized usage flag(s) 0x10000000 Do any of these fixmes sound to be likely candidates to the more knowledgeable DirectX folks? (The former sounds like a DX surface is supposed to be blitted somewhere but the request is invalid - perhaps that's the missing cursor?) - Christopher Thielen On 02/15/2014 05:05 PM, Ken Thomases wrote: > On Feb 15, 2014, at 6:17 PM, Christopher Thielen wrote: > >> I'm attempting to fix http://bugs.winehq.org/show_bug.cgi?id=13683 but need some advice as to where to start. I'm not too familiar with hacking on Wine. >> >> I'd like to test Stefan Dösinger's theory outlined in the comments for #13683 that the missing second mouse cursor is perhaps being implemented using DirectX overlays and that Wine's lack of overlay compatibility flags is to blame. >> >> Would the proper action to test this theory be to fake a certain set of flags in dlls/d3d8/device.c's static HRESULT WINAPI d3d8_device_GetDeviceCaps(IDirect3DDevice8 *iface, D3DCAPS8 *caps) ? If that proves to be the issue, I'd then need to write proper code to report the correct set of flags presumably. > > Probably you should start by collecting a log with the +ddraw,+d3d,+d3d_surface channels and looking for messages that mention "overlay". > > From a cursory look, it seems that wined3d supports some types of overlay surfaces and some operations on those surfaces, but not all. > > >> Is there any easy way to see which DLLs Wine loads when running an application? > > You can look at a +module log. > > -Ken >

Feb. 16, 2014

Re: Assorted spelling fixes

by Dmitry Timoshkov

Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 16 February 2014 12:19, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > > > >> - cab_ULONG window_size; /* window size (1Kb through 2Mb) */ > >> + cab_ULONG window_size; /* window size (1 KB through 2 MB) */ > > > > This is not the typos, that's a common way of writing sizes by programmers, > > personally I prefer the old form (and will keep using it in future) and hate > > the "fixed" variant. > > > I can't say I'm much of a fan of this kind of change either, but if we > really wanted to be strict about this as a project, I'd prefer either > "kB" or "KiB" (etc.), depending on what's meant. In my years of University the students were told to remember that 1Kb == 1024 bytes, 1Mb == 1024Kb and size prefixes should be written as a capital letter to emphasize its meaning. I'm very reluctant to change this practice to something else regardless of explanations and intents. I understand that for not technical people 1K == 1000, but I'd assume programmers are not of that kind. -- Dmitry.

Feb. 16, 2014

Re: Assorted spelling fixes

by Henri Verbeet

On 16 February 2014 12:19, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > >> - cab_ULONG window_size; /* window size (1Kb through 2Mb) */ >> + cab_ULONG window_size; /* window size (1 KB through 2 MB) */ > > This is not the typos, that's a common way of writing sizes by programmers, > personally I prefer the old form (and will keep using it in future) and hate > the "fixed" variant. > I can't say I'm much of a fan of this kind of change either, but if we really wanted to be strict about this as a project, I'd prefer either "kB" or "KiB" (etc.), depending on what's meant.

Feb. 16, 2014