March 2012 - Wine-Devel - list.winehq.org

Re: [PATCH 2/3] dmsynth: Check the rigth CLSID to create the DirectMusicSynthSink object.

by Marvin

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=17544 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

March 29, 2012

Re: [PATCH 1/3] dmsynth: Add basic tests.

by Marvin

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=17543 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

March 29, 2012

Re: [PATCH 1/3] dmsynth: Add basic tests.

by Marvin

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=17543 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

March 29, 2012

Re: [PATCH 1/5] dmusic: Add some tests for enumerating and creating ports.

by Marvin

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=17542 Your paranoid android. === WNT4WSSP6 (32 bit dmusic) === dmusic.c:51: Test failed: CoCreateInstance returned: 80040154 dmusic: unhandled exception c0000005 at 00401347 === W2KPROSP4 (32 bit dmusic) === dmusic.c:51: Test failed: CoCreateInstance returned: 80004002 dmusic: unhandled exception c0000005 at 00401347 === W2K3R2SESP2 (32 bit dmusic) === dmusic.c:51: Test failed: CoCreateInstance returned: 80040154 dmusic: unhandled exception c0000005 at 00401347 === WVISTAADM (32 bit dmusic) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation === W2K8SE (32 bit dmusic) === dmusic.c:51: Test failed: CoCreateInstance returned: 80040154 dmusic: unhandled exception c0000005 at 00401347

March 29, 2012

SoC 2012 Ideas

by Charles Davis

Hi, Since I graduate this year, this may be the last time I participate--or at least, attempt to participate, since last year didn't quite work out for me :(--in Summer of Code. (I realize I was supposed to email you last week, but what's done is done.) So, without further ado, here's what I'm proposing: 1) Make Wine use App Sandbox on Mac OS X. A project that used to be listed on the SoC ideas page was to implement proper sandboxing in Wine. Apparently, you think this is unrealistic, because you took it down. (Not the page, just that suggestion.) But, I think that if I narrowed my focus a bit, it could be possible to do this. I'm proposing using the Mac OS App Sandbox API--the beginnings of which were introduced in 10.5 and which came into its own in 10.7--to improve security of Wine on Mac OS. Wine is an excellent candidate for the App Sandbox, because most of its file-system activity is limited to a single directory--namely, the Wine prefix. I'm not sure what you think of this, though, so I'm throwing this out there to get feedback. At the very least, I would like to be able to limit Wine's file-system activity to the prefix. 2) HLSL compiler. Well, my D3D bytecode backend to LLVM didn't pan out like I'd hoped. Maybe an LLVM-based compiler is too complex for Wine right now. But perhaps we don't need it right now anyway. If CodeWeavers can't afford to pay me, maybe Google can. I can add a simple parser and compiler (that performs little or no optimization) that hopefully would be sufficient for Wine's purposes. 3) Integrate pieces of DCE/RPC into Wine. As you may or may not know, in Mac OS 10.7, Apple stopped using Samba (probably because it uses the GPL3 as its license) in favor of their own implementation--which just so happens to be based on the original DCE/RPC implementation (the same one that was used as a base for MS RPC). I figured we could cannibalize pieces of it for our own use. Or is that not acceptable? What do you think? I'm not sure how useful or feasible these are, so I'm posting to the list before. Chip

March 29, 2012

Re: winspool.drv: Update allowed driver Version

by Marvin

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=17541 Your paranoid android. === WINEBUILD (build) === Can't determine base name

March 28, 2012

Re: RFC: Duplicate in/out device naming

by Paul Chitescu

On Wednesday 28 March 2012 04:43:54 pm Ken Thomases wrote: > On Mar 27, 2012, at 11:04 AM, Andrew Eikum wrote: > > I added a prefix to each MMDevice indicating its flow direction. > > > > This solves the Rosetta Stone issue, as you can see in the bug. But > > when testing this in other applications, it quickly becomes silly. > > Audacity 1.3 adds its own "Out: " prefix to WinMM device names, > > creating "Out: Out: default" in the UI. > > Meh. I don't think that's a particularly troublesome side effect. If no > better solution presents itself, then I say this is the least bad of the > alternatives. > > That said... > > > The unique identifier must be a prefix, as WinMM's szPname field > > truncates at 31 characters. > > Is it really likely that identifiers will not leave any characters to > spare? Anyway, since WinMM is already arbitrarily truncating them, you can > truncate them even earlier at 29 characters and suffix with as much of " > output" or " input" as will fit. > > Another approach is to prefix but using an obscure "code" which won't look > silly when applications also prefix the device name. For example, the ALSA > driver might use "WAO" and "WAI" (for "Wine ALSA Output" and "Wine ALSA > Input", respectively) or whatever. These codes will be inscrutable, but > not obviously redundant with an application-provided "Out: " prefix. And > users are already somewhat used to inscrutable terms in device names (for > example, "HDA" meant nothing to me until I looked it up). > > Regards, > Ken Maybe add some extra checks like: - If it's input and it doesn't already contain (case insensitive) "input" or "capture" or "microphone" append " Input" (as much as it fits in buffer) - If it's output and it doesn't already contain (case insensitive) "output" or "playback" or "speaker" append " Output" (as much as it fits in buffer) Paul

March 28, 2012

Re: po: Update German translation

by André Hentschel

Am 28.03.2012 04:33, schrieb Julian Rüger: > Hi André, > > Am Dienstag, den 27.03.2012, 21:43 +0200 schrieb André Hentschel: >> --- >> po/de.po | 7 +++---- >> 1 files changed, 3 insertions(+), 4 deletions(-) >> >> #: jscript.rc:37 >> -#, fuzzy >> #| msgid "Invalid parameter.\n" >> msgid "Invalid character" >> -msgstr "Ungültiger Parameter.\n" >> +msgstr "Ungültiges Zeichen" > > du solltest die alte msgid auch entfernen. (Ist ein neues Feature, > wurden schon andere drauf hingewiesen ;) Thx missed that, next time it's all up to you. Giving the translation stuff completely in your hands now. :) -- Best Regards, André Hentschel

March 28, 2012

Re: RFC: Duplicate in/out device naming

by Ken Thomases

On Mar 27, 2012, at 11:04 AM, Andrew Eikum wrote: > I added a prefix to each MMDevice indicating its flow direction. > This solves the Rosetta Stone issue, as you can see in the bug. But > when testing this in other applications, it quickly becomes silly. > Audacity 1.3 adds its own "Out: " prefix to WinMM device names, > creating "Out: Out: default" in the UI. Meh. I don't think that's a particularly troublesome side effect. If no better solution presents itself, then I say this is the least bad of the alternatives. That said... > The unique identifier must be a prefix, as WinMM's szPname field truncates at 31 characters. Is it really likely that identifiers will not leave any characters to spare? Anyway, since WinMM is already arbitrarily truncating them, you can truncate them even earlier at 29 characters and suffix with as much of " output" or " input" as will fit. Another approach is to prefix but using an obscure "code" which won't look silly when applications also prefix the device name. For example, the ALSA driver might use "WAO" and "WAI" (for "Wine ALSA Output" and "Wine ALSA Input", respectively) or whatever. These codes will be inscrutable, but not obviously redundant with an application-provided "Out: " prefix. And users are already somewhat used to inscrutable terms in device names (for example, "HDA" meant nothing to me until I looked it up). Regards, Ken

March 28, 2012

Re: [2/4] scrrun: Register Scripting interfaces (try 2)

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -4,4 +4,6 @@ C_SRCS = scrrun.c > > RC_SRCS = scrrun.rc > > +IDL_TLB_SCRS = scrrun.idl This can't possibly do anything. I've fixed it up, but please test your code before sending, it's not the first time you send a registration patch that doesn't register anything. -- Alexandre Julliard julliard(a)winehq.org

March 28, 2012