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

DIB Engine - New approach
by Massimo Del Fedele April 21, 2009

April 21, 2009

The approach taken so far consisted in having 2 device pointers inside GDI32, one for dib engine and the other for normal display driver. This way had the disadvantage of having to keep in sync the DC with the right driver depending on selected bitmap, which lead to many small changes spread along all gdi code; going deeper with development this approach showed many limits and problems. So I decided to start again from scratch with a completely different approach which is giving good results and is quite less invasive on gdi32 code. Instead of doing : -- DIB ENGINE / GDI32 --- \ -- X11 DRIVER I took this approach : GDI32 -- DIB ENGINE -- X11 DRIVER The (X11) display driver is loaded from inside the engine, which replaces it from gdi32 point of view. The changes in gdi32 are *very* limited, just in driver.c code, making it to load (if desired) the engine instead of normal x11 driver. No other changes needed. I added as usual the code allowing to enable/disable the engine on request by registry and/or environment variable. If the engine is not present or disabled, the driver loader falls back to usual behaviour. The Engine then loads the X11 driver in init phase and acts as a gate depending on selected BMP, forwarding to X11 driver all requests for DDB bitmaps and doing the job itself for DIB ones. This approach showed many advantages, and I' almost ready converting all old code to it. By now I'm posting here 3 patches showing the approach; the posted driver is a simple pass-throu one, so it just forwards all calls to X11 driver. The last patch of the series shows the forking behaviour of DIB/DDB processing from inside the engine, but still forwarding all to X11. I'd like some comments on the approach taken; on next days I'll post a more complete code with most of the engine implemented. Ciao Max

3 5

Re: [1/5]msctf/test: setup test framework for ITfThreadMgrEventSink
by Alexandre Julliard April 21, 2009

April 21, 2009

Aric Stewart <aric(a)codeweavers.com> writes: > +static HRESULT WINAPI ThreadMgrEventSink_OnInitDocumentMgr(ITfThreadMgrEventSink *iface, > +ITfDocumentMgr *pdim) > +{ > + trace("%s\n",__FUNCTION__); > + return S_OK; > +} trace() already includes the file and line, and __FUNCTION__ is not portable, please avoid it in tests. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine patch code review or what to do if patches get stuck?
by Igor Tarasov April 21, 2009

April 21, 2009

Hi! The reason of why I write this to you is simple: my patches have stuck again and I don't know what to do. But since this happening not with me only and not this happens regularly, I have thought about looking at the problem a bit wider. Is there any code review system for patches that are sent to wine-patches? Or just some developers monitor wine-patches and say something if they have something to say? Or, how does Alexander make decisions regarding committing patches? I've been thinking about some kind of web-based system, like one used at http://codereview.chromium.org/ It would be nice, if there was sime kind of bot, that would grab all patches from wine-patches, sort them, make some initial analysis (maybe, run local test git repository, make various tests, check that threre are no conflicts, check code style (at least whitespace changes) etc). Then it could set a flag and report back to the sender. For instance it would flag "tests fail" and send details back to sender. Or "whitespace change detected" and send back the quoted diff parts. Then, somebody of developers might review it and put his mark/comments that would go to wine-devel (if necessary), or to sender directly. There could be simple templates for test reviews for common problems, and tags, such as "sure?" that means, that more explanations are needed why that implementation is correct. "too hackish" that means that style or code itself is of bad quality. "whitespace" whitespacechange detected. "tests required" tests are really required for this patch to go in. "okay", means that reviewer recommends the patch for commitment. "wrong", means that patch is totally wrong ..etc Some of these tags mean that report goes directly to developer, and patch is marked as obsolete, others make system send some feedback to wine-dev. It would take just few clicks for reviewer to get it done. This would provide good feedback, also this would help the one who makes the decisions to see that others have already checked that patch and what they think about that. Sometimes "no feedback" means that you just dont know - is there something wrong? Or maybe your patch wos not understood correctly? Or there are doubts that what you did is right? Or what? It would be better to have feedback like "are you serious?" than nothing at all :) P.S: the patches in question are http://www.winehq.org/pipermail/wine-patches/2009-April/072009.html and http://www.winehq.org/pipermail/wine-patches/2009-April/072013.html . They both are soo simple, that I even don't know how to ask of what's wrong with them :) -- Igor

5 6

Re: [1/2](try 2)msctf: helper functions for generating DWORD cookies
by Alexandre Julliard April 21, 2009

April 21, 2009

Aric Stewart <aric(a)codeweavers.com> writes: > + else if (id_last == array_size) > + { > + CookieInternal **new_cookies = NULL; > + new_cookies = HeapReAlloc(GetProcessHeap(),0,cookies,sizeof(CookieInternal*) * (array_size * 2)); > + if (!new_cookies) > + { > + array_size = 0; > + ERR("Out of memory, Unable to realloc cookies array\n"); > + return 0x0; > + } > + cookies = new_cookies; > + array_size *= 2; > + } > + > + /* try to reuse IDs if possible */ > + for (i = 0; i < id_last; i++) > + if (cookies[i] == NULL) break; It would be smarter to reuse the ID before growing the array. Also you could mark free entries with a 0 id or something like that, and avoid a level of indirection (and some memory leaks...) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [kernel32] add unittests for registry keys of serial ports
by Alexandre Julliard April 21, 2009

April 21, 2009

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > + RegOpenKeyA(HKEY_LOCAL_MACHINE, "Hardware\\Description\\System", &desc_sys); > + RegOpenKeyA(HKEY_LOCAL_MACHINE, "Hardware\\Devicemap\\Serialcomm", &sercom); > + RegOpenKeyA(HKEY_LOCAL_MACHINE, "Software\\Microsoft\\Windows NT\\CurrentVersion\\Ports", &sw_ports); You need to check for failure and handle it properly. I doubt you'll be able to open these keys on Win9x for instance. > + result = RegOpenKeyA(HKEY_LOCAL_MACHINE, "System\\Select", &sub_key1); > + if(ERROR_SUCCESS == result) { > + size = sizeof(count1); > + result = RegQueryValueExA( sub_key1, "Current", NULL, NULL, (LPBYTE) &count1, &size); > + RegCloseKey(sub_key1); > + } > + if(ERROR_SUCCESS == result) { > + sprintf(sub_key1_name, "System\\ControlSet%03d\\Enum\\ACPI", count1); > + RegOpenKeyA(HKEY_LOCAL_MACHINE, sub_key1_name, &acpi); > + } Do you really have an app that accesses ControlSetxxx directly? CurrentControlSet is a lot easier to work with. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Possible regression today's git wine-1.1.19-153-g55ad3fd
by Susan Cragin April 21, 2009

April 21, 2009

>>>>>Ohhh... got a nice crash after a re-boot. >>>> >>>> Never mind that. This looks more promising. At least, to me it does. The actctx error I get all the time, but I've never seen the other, and it happend right as the system froze up. >>>> >>>> fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.MFCLOC" (8.0.50608.0) >>>> err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Broken pipe >>>> err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Broken pipe >>>> err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Broken pipe >>>> err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Success >>> >>> Interesting. You are running Ubuntu studio 8.10 without pulseaudio, right? >>> >>> Have you updated the system between version runs (that may have >>> reintroduced pulseaudio, for example)? >>> >>> Are you running any other sound applications (or the sound that is >>> played after boot on Ubuntu)? >>> >>> Could you perform a git bisect to identify the guilty change? >> >>Doing some investigation, I have found >>(http://alsa.opensrc.org/index.php/HowTo_Asynchronous_Playback) >>""" >>That is basically all there is to the callback. Note however, that >>this example does not include error checking, which is a good idea of >>course. Occasionally, you may have to restore from a buffer under-run, >>in case the computer was caught up in some other process and didn't >>get to calling your callback. Whenever this happens, the first >>operation you perform on the device, in this case >>snd_pcm_avail_update, will return -EPIPE (a 'Broken Pipe' error). You >>can restore from this by calling the snd_pcm_prepare function again. >>""" >> >>This may be what you are experiencing here. I'd need to look into this >>further, but to be honest, I'm a little out of depth with the Windows >>and Wine sound interfaces. >> >>- Reece > >Reece: >I purged pulseaudio and checked that it had not been re-installed. I run Ubuntu 9.04 with all updates. I also use a test version of alsa-driver since my sound card is difficult to recognize but so far have had only great results -- no impact on wine at all. >The problem I am experiencing manifests itself in the program freezing... could be the sound, could also be the buttons doing something odd. One button's on-off toggle switches suddenly with no input on my part. >Regression test is below. >Susan > >b958dfdc4769515c0ef56c401430dd3e3980aabf is first bad commit >commit b958dfdc4769515c0ef56c401430dd3e3980aabf >Author: Huw Davies <huw(a)codeweavers.com> >Date: Thu Apr 16 11:51:45 2009 +0100 > > ole32: Change helper function to return the matching entry. > >:040000 040000 2964979dee4f353e1d565f7c20d8fdcc534f006d 8744cfee2e33db4799f58f102825103f565e18b9 M dlls I filed bug #18133, which has more detail and a screenshot. Susan

1 0

Re: [PATCH 5/5] user32/tests: Fix tests on win9x.
by Paul Vriens April 21, 2009

April 21, 2009

Huw Davies wrote: > --- > dlls/user32/tests/clipboard.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > > ------------------------------------------------------------------------ > > Was just about to sent a patch along those lines. Isn't it better to mark that win9x (and winME as well btw) one as broken()? -- Cheers, Paul.

2 4

Re: Article on wine development strategy
by Susan Cragin April 21, 2009

April 21, 2009

I would like to put in my two cents for making Dragon NaturallySpeaking 10 work at about "50%." DNS 10 is a terrible program in a lot of ways. It's interface is over-engineered, clumsy, unintuitive, and packed with features that the average user never even looks at. People who don't know DNS say, "I'd love to dictate into word, format by voice command, etc." People who know DNS well, say "just give me accuracy and speed, and forget everything else." Those people usually tend to be the natural DNS constituency: either disabled or want to churn out a tremendous amount of text without typing. I think my point here is that happiness depends not only on % but on the type of program. Not all programs are created equal. Not all features are a good idea. Susan Cragin

8 9

Maybe already known stuff, but.....
by Massimo Del Fedele April 21, 2009

April 21, 2009

Today I found this : #include "execinfo.h" void BT(void) { void *array[50]; size_t size; char **strings; size_t i; size = backtrace (array, 50); strings = backtrace_symbols (array, size); printf ("Obtained %zd stack frames.\n", size); for (i = 0; i < size; i++) printf ("%s\n", strings[i]); free (strings); } That allow to dump a backtrace (here max 50 frames) from inside a running program. Quite useful if app is non debuggable and don't run with +relay on because of copy protection. Ciao Max

2 2

NetBSD compile error
by Austin English April 21, 2009

April 21, 2009

I just installed NetBSD 5.0RC4 on a spare hard drive, and tried compiling Wine. I hadn't seen this error before, but I'm not sure if the regression is on NetBSD or Wine's end. Google doesn't show too much for this error, other than that apparently NetBSD's libexec requires execname to not be NULL: case 2: /* ORIGIN */ if (execname == NULL) xerr(1, "execname not specified in AUX vector"); if ((ep = strrchr(p = execname, '/')) == NULL) xerr(1, "bad execname `%s' in AUX vector", execname); break; http://ftp.lahtermaher.org/pub/os/netbsd/cvs/src/libexec/ld.elf_so/expand.c… austin987$ make LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -D__WINESRC__ -D_ADVAPI32_ -foversion.res version.rc execname not specified in AUX vector: No such file or directory *** Error code 1 Can anyone shed some light on this error? -- -Austin

1 0

Re: Possible regression today's git wine-1.1.19-153-g55ad3fd
by Susan Cragin April 21, 2009

April 21, 2009

>2009/4/20 Reece Dunn <msclrhd(a)googlemail.com>: >> 2009/4/20 Susan Cragin <susancragin(a)earthlink.net>: >>>>Ohhh... got a nice crash after a re-boot. >>> >>> Never mind that. This looks more promising. At least, to me it does. The actctx error I get all the time, but I've never seen the other, and it happend right as the system froze up. >>> >>> fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.MFCLOC" (8.0.50608.0) >>> err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Broken pipe >>> err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Broken pipe >>> err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Broken pipe >>> err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Success >> >> Interesting. You are running Ubuntu studio 8.10 without pulseaudio, right? >> >> Have you updated the system between version runs (that may have >> reintroduced pulseaudio, for example)? >> >> Are you running any other sound applications (or the sound that is >> played after boot on Ubuntu)? >> >> Could you perform a git bisect to identify the guilty change? > >Doing some investigation, I have found >(http://alsa.opensrc.org/index.php/HowTo_Asynchronous_Playback) >""" >That is basically all there is to the callback. Note however, that >this example does not include error checking, which is a good idea of >course. Occasionally, you may have to restore from a buffer under-run, >in case the computer was caught up in some other process and didn't >get to calling your callback. Whenever this happens, the first >operation you perform on the device, in this case >snd_pcm_avail_update, will return -EPIPE (a 'Broken Pipe' error). You >can restore from this by calling the snd_pcm_prepare function again. >""" > >This may be what you are experiencing here. I'd need to look into this >further, but to be honest, I'm a little out of depth with the Windows >and Wine sound interfaces. > >- Reece Reece: I purged pulseaudio and checked that it had not been re-installed. I run Ubuntu 9.04 with all updates. I also use a test version of alsa-driver since my sound card is difficult to recognize but so far have had only great results -- no impact on wine at all. The problem I am experiencing manifests itself in the program freezing... could be the sound, could also be the buttons doing something odd. One button's on-off toggle switches suddenly with no input on my part. Regression test is below. Susan b958dfdc4769515c0ef56c401430dd3e3980aabf is first bad commit commit b958dfdc4769515c0ef56c401430dd3e3980aabf Author: Huw Davies <huw(a)codeweavers.com> Date: Thu Apr 16 11:51:45 2009 +0100 ole32: Change helper function to return the matching entry. :040000 040000 2964979dee4f353e1d565f7c20d8fdcc534f006d 8744cfee2e33db4799f58f102825103f565e18b9 M dlls

1 0

Re: dsound: Allow a special cbSize case in CreateSoundBuffer
by Maarten Lankhorst April 20, 2009

April 20, 2009

Hey Jesse, Jesse Allen schreef: > OK now do you have comments? I have test cases. > > On Sun, Apr 19, 2009 at 6:30 PM, Jesse Allen <the3dfxdude(a)gmail.com> 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. >> >> Includes test cases which were verified on WinXP. >> Fixes bug #11716 >> If you want me to review a patch add me to cc please. The variable size_ok is unneeded here, you can rewrite that so that it will fall through if test fails. Apart from that it looks ok to me. Cheers, Maarten.

1 0

Re: Possible regression today's git wine-1.1.19-153-g55ad3fd
by Susan Cragin April 20, 2009

April 20, 2009

>Ohhh... got a nice crash after a re-boot. Never mind that. This looks more promising. At least, to me it does. The actctx error I get all the time, but I've never seen the other, and it happend right as the system froze up. fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.MFCLOC" (8.0.50608.0) err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Broken pipe err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Broken pipe err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Broken pipe err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Success

2 2

Janitor: list.h functions defined but not used
by Glenn L. McGrath April 20, 2009

April 20, 2009

Hi all, im new to the list, im interested in grinding away at some of the warnings wine generates... make depend was complaining about some static inline functions that it thinks arent used, this patch uses __attribute__ ((used)) to disable the warning. Glenn

7 7

Re: (Try2) wininet/tests: Fix HttpSendRequestW test on Win2k platform.
by Hans Leidekker April 20, 2009

April 20, 2009

On Monday 20 April 2009 20:14:14 Nicolas Le Cam wrote: > Win2k SP4 seems to be the only platform that follows what msdn says (see > http://msdn.microsoft.com/en-us/library/aa384247(VS.85).aspx) wininet is bundled with Internet Explorer, so it's more useful to look at the Explorer version than the Windows version. > Perhaps passing header's length to HttpSendRequest instead of adding a > broken expected value would be better. Let me know. No, the length parameter is the essence of this test. I wrote it because I saw IE7 call HttpSendRequestW like this which contradicts MSDN. The test shows that MSDN is outdated; on recent wininet HttpSendRequestW will calculate the header length for you. -Hans

2 1