April 2009 - Wine-Devel - list.winehq.org

re: Remote named pipes and stuff.
by Dan Kegel April 22, 2009

April 22, 2009

Kai asked: > Is there a use case for remote named pipes? http://support.microsoft.com/kb/q238949/ shows that SQL Server supports named pipes as an access method. Some apps or sites might assume that works, and not be able to use TCP/IP for this. Google finds at least three examples of people wanting to used named pipes in previous wine threads: http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/06fbfdfb5… "I'm trying to run a Delphi application on Wine. The application uses BDE to talk to a MSSQL server, but database communication does not work. Enable debugging i see this error message: warn:file:wine_nt_to_unix_file_name L"SRVCAF1\\pipe\\sql\\query" not found in ...dosdevices/unc warn:ntdll:NtCreateFile L"\\??\\UNC\\SRVCAF1\\pipe\\sql\\query" not found (c000003a) warn:file:CreateFileW Unable to create file L"\\\\SRVCAF1\\pipe\\sql\ \query" (status c000003a) Is this UNC pipe supposed to work on Wine? " (I think you even replied to that thread :-) http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/e7323dfa9… "I am trying to connect a client with named pipes to a remote server. Using the kernel32 function CreateFile I get the folling message: fixme:file:wine_nt_to_unix_file_name UNC name L"\\??\\UNC\\192.168.1.157\\pipe\\Archiv\\Server" not supported I am using Wine20040505. Is the anybody out there who can help? To be frank, I am a rooky using wine an Linux, but... ;o) " http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/a3d22d752… "[Outlook seems to use a named pipe to connect to Exchange: fixme:win32:WaitNamedPipeA \\EXCH_CTL2\pipe\epmapper 0x00000000 "] So, there you have it. Databases, Microsoft Exchange, and the like seem to like using remote named pipes. - Dan

1 0

[PATCH] comctl32/toolbar.c: fix trace info for TOOLBAR_InternalInsertButtonsT
by Giuseppe Bilotta April 22, 2009

April 22, 2009

TOOLBAR_DumpTBButton should be invoked over the button currently being inserted, and not always over the first button. --- dlls/comctl32/toolbar.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/comctl32/toolbar.c b/dlls/comctl32/toolbar.c index cf54df7..851a5cc 100644 --- a/dlls/comctl32/toolbar.c +++ b/dlls/comctl32/toolbar.c @@ -1832,7 +1832,7 @@ TOOLBAR_InternalInsertButtonsT(TOOLBAR_INFO *infoPtr, INT iIndex, UINT nAddButto for (iButton = 0; iButton < nAddButtons; iButton++) { TBUTTON_INFO *btnPtr = &infoPtr->buttons[iIndex + iButton]; - TOOLBAR_DumpTBButton(lpTbb, fUnicode); + TOOLBAR_DumpTBButton(lpTbb + iButton, fUnicode); ZeroMemory(btnPtr, sizeof(*btnPtr)); -- 1.6.2.254.g84bde

1 0

Re: Article on wine development strategy
by Scott Ritchie April 22, 2009

April 22, 2009

Vincent Povirk wrote: > Your model makes bugs that show up in only a few applications very > rare. I've added some to your existing model with duct tape. I > arbitrarily decided that about 40% of apps would have 1 or 2 unique > bugs, in addition to the current ones. > You can better model this by just changing the probability distribution of the various bugs and using the "alternate" method where each bug has an absolute probability of affecting a given app. Then make about 1000 bugs have .05% probability or so, and odds are most of them will only affect one or two apps (if you have 2500 you're modelling) > The result is an exponential curve, until about 80% of apps are > solved. After that, the curve is linear. > > This makes a sort of sense. If we do it right, we're likely to fix the > bugs that affect a lot of apps before we finish with the ones that > affect one or two. Once the major bugs are fixed, Wine and Windows > become comparable to a more "normal" set of different interface > implementations: largely compatible, but a few developers will > continue finding subtle differences to rely on forever. The rate at > which apps hit these differences should be fairly consistent. > > I do wish I had a better way to do this than tacking it on to the > existing stuff. I think I broke pickNextBug, but fortunately that's > unused until all apps are solved. > > If you increased the number of very rare (1 or 2 apps) bugs in a less > crappy way, it might show something smoother. > I'll try my suggested method now. > I have a feeling that in general the exact shape depends mostly on how > likely it is for a bug to occur in multiple apps and on how many bugs > each app has. If a typical app has only a few bugs (the constants > you've chosen imply that it doesn't), things look very nice at the > start. If a typical bug affects many apps (the constants you've chosen > imply that it does), things look very nice at the end. > Yeah, I'll note that whether a typical app has a few bugs or a lot of bugs to start with depends on whether we want to model "from the start" or from here on out. Thanks, Scott Ritchie

1 0

Re: msvcrt/tests : add some tests for strtok()
by Alexandre Julliard April 22, 2009

April 22, 2009

Rein Klazes <wijn(a)online.nl> writes: > - pmemcpy(mem+5, mem,nLen+1); > - ok(pmemcmp(mem+5,xilstring, nLen) == 0, > - "Got result %s\n",mem+5); > + if( pmemcpy) { > + pmemcpy(mem+5, mem,nLen+1); > + ok(pmemcmp(mem+5,xilstring, nLen) == 0, > + "Got result %s\n",mem+5); > + } else > + skip("memcpy not found\n"); I doubt any version of the dll is missing memcpy, and even so that should be a separate patch. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: comctl32: TOOLBAR_SetImageList should recalulate toolbar only if it is necessary
by Alexandre Julliard April 22, 2009

April 22, 2009

Igor Tarasov <tarasov.igor(a)gmail.com> writes: > Forgot the patch :) > > 2009/4/19 Igor Tarasov <tarasov.igor(a)gmail.com>: >> Currently TOOLBAR_SetImageList recalculates toolbar and button sizes >> even if there is no need in this (when new image list bitmap sizes are >> equal to toolbar bitmap sizes). This overwrites button sizes that >> might have been defined by application, and thus leads to visual >> glitches. Native comctl does not change any toolbar sizes on >> TB_SETIMAGELIST when bitmap size is the same. It doesn't work here: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so toolbar.c && touch toolbar.ok toolbar.c:934: Test failed: Unexpected button size toolbar.c:936: Test failed: Unexpected button size toolbar.c:944: Test failed: Unexpected button size toolbar.c:946: Test failed: invalid rect (button) (0,2) (163,40) - expected (0,2) (163,26) toolbar.c:946: Test failed: invalid rect (button) (163,2) (326,40) - expected (163,2) (326,26) toolbar.c:946: Test failed: invalid rect (button) (326,2) (489,40) - expected (326,2) (489,26) toolbar.c:946: Test failed: invalid rect (button) (489,2) (652,40) - expected (489,2) (652,26) toolbar.c:946: Test failed: invalid rect (button) (652,2) (819,40) - expected (652,2) (819,26) toolbar.c:946: Test failed: invalid rect (button) (819,2) (850,40) - expected (819,2) (850,26) toolbar.c:949: Test failed: invalid rect (button) (0,2) (163,40) - expected (0,0) (163,38) toolbar.c:949: Test failed: invalid rect (button) (163,2) (326,40) - expected (163,0) (326,38) toolbar.c:949: Test failed: invalid rect (button) (326,2) (489,40) - expected (326,0) (489,38) toolbar.c:949: Test failed: invalid rect (button) (489,2) (652,40) - expected (489,0) (652,38) make[2]: *** [toolbar.ok] Error 13 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [4/4] msi/tests: Fix package test when run on a different drive than C:\.
by James Hawkins April 21, 2009

April 21, 2009

On Tue, Apr 21, 2009 at 2:30 PM, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: > This one finally fixes current relative path test to expect correct > value. > + drives = GetLogicalDrives(); + lstrcpyA(path, "A:\\"); + for (i = 0; i < 26; path[0] = '\0', i++) + { + if (!(drives & (1 << i))) + continue; + + path[0] = 'A' + i; + if (GetDriveType(path) != DRIVE_FIXED) + continue; + + lstrcatA(path + 3, CURR_DIR + 3); + attr = GetFileAttributesA(path); + if (attr != INVALID_FILE_ATTRIBUTES && (attr & FILE_ATTRIBUTE_DIRECTORY)) + { + if (path[lstrlenA(path)-1] != '\\') + lstrcatA(path, "\\"); + break; + } + path[3] = '\0'; + } Same as 2/4. Please refactor and add many nice comments detailing exactly what is happening in native msi to make this necessary. -- James Hawkins

2 2

Changing the language that wine runs in (testing language versions of dialogs)
by Reece Dunn April 21, 2009

April 21, 2009

Hi, Looking at http://bugs.winehq.org/show_bug.cgi?id=18125, it has winecfg from wine 1.1.19 running in Spanish. The screenshot shows that the static text is wrapped over 4 lines, but the text is clipped (should be 8x4 dlus high). This is not the issue reported there, but I would like to fix it and improve the layout. So, how do I change locale? Especially from a just-built version of Wine. I have tried: LANG=es ./wine winecfg LANG=es.UTF-8 ./wine winecfg LC_ALL=es ./wine winecfg LC_ALL=es.UTF-8 ./wine winecfg and export LANG=es && ./wine winecfg variants. I have also tried changing the system regional and language settings. None of these have worked. It's not on the FAQ either. I am using Kubuntu 9.04. Thanks, - Reece

5 6

Re: [2/4] msi/tests: Add empty dir test for the DrLocator part of the AppSearch action.
by James Hawkins April 21, 2009

April 21, 2009

On Tue, Apr 21, 2009 at 2:30 PM, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: > This patch adds a test to demonstrate current wrong behaviour in case of > an empty path, it is basically there to validate last patch of the > series that change relative path test behaviour (i.e. expected values), > as it seems it was rejected because it wasn't backed up by a previous > test. > + drives = GetLogicalDrives(); + lstrcpyA(path, "A:\\"); + for (i = 0; i < 26; i++) + { + if ((drives & (1 << i))) + { + path[0] = 'A' + i; + + if (GetDriveType(path) == DRIVE_FIXED) + break; + } + path[0] = '\0'; + } Please refactor this into a helper function. A comment describing exactly what is being tested and why this bit of code is needed would be beneficial. -- James Hawkins

1 0

Re: dsound: Allow a special cbSize case in CreateSoundBuffer (updated)
by Detlef Riekenberg April 21, 2009

April 21, 2009

On Mo, 2009-04-20 at 21:51 -0700, Jesse Allen wrote: > In CreateSoundBuffer, some apps pass sizeof(WAVEFORMATEXTENSIBLE) for > the cbSize and we have to allow it, but only when the SubFormat is > KSDATAFORMAT_SUBTYPE_PCM. > > This updated patch is simpler... at the expense of being less clear ;) > > Includes test cases which were verified on WinXP. > Fixes bug #11716 Hi Jesse. Your patch introduced failures for the dsound-test on some systems with win98, w2k and w2k3. ( http://test.winehq.org/data/tests/dsound:dsound8.html ) Can you please take a look? Thanks -- By by ... Detlef

1 0

Win64 keyword?
by Austin English April 21, 2009

April 21, 2009

Howdy, Seems quite a few bugs have been filed recently about our win64 support. While setting the hardware to PC-X86-64 describes the hardware accurately, it doesn't really tell us if the user is running 32 bit wine or 64 bit wine on their 64 bit OS. We've already got a win16 keyword, so how about a win64 keyword to make searching for these bugs easier? -- -Austin

2 1