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

Re: Would like to get some feedback on GSOC idea

by Juan Lang

Hi Marek, On Tue, Mar 27, 2012 at 9:13 AM, M C <kcmark(a)gmail.com> wrote: > Hi everyone, > > My name is Marek Chmiel, I am a student a NEIU. I am studying computer > science and network security related topics. This semester I had spent > a fair amount of time writing crypt related functions with java, and > became very interested in Cryptography. After looking over the > suggested ideas on SOC official wine wiki I was pleasantly surprised > to see that there was already a crypt related idea suggested. I have a > great understanding of c++ and java, and though I know c I have not > worked with it as much as the other languages. > > Implementing a DSS provider sounds like an awesome task to tackle, if > someone has never written code for Linux, can they take on such a > task? Are there any significant issues implementing a DSS that you > guys know about? Any crypt GSOC ideas would you suggest for someone > who has wrote limited amount of code for Linux? If you know C, you ought to be able to code in Linux. I don't see that being a significant hurdle. I don't know of any significant issues implementing a DSS provider. The usual gotchas with coding for Wine apply here: tests, tests, tests. Solid test cases are a prerequisite to adding new code to Wine, and if a SoC project produces nothing but a solid test suite, it's still a win. I expect this is a pretty straightforward project for someone motivated, so I'm happy to see someone interested in picking it up. > What I would also like to do, besides implementing a DSS provider, is > to fix most if not all of the crypt related bugs that remain in Wine. > This might seem like more than most people can chew, but viewing the > Bug Tracking database it appears that there aren't that many crypt > related bugs and might even be caused by a lack of a DSS provider > (Hopefully this wouldn't create a entire new series of bugs). There aren't that many bugs, it's true. I don't think many of them relate specifically to DSS, and some may be quite challenging to fix. But the more you can fix, the better :) As you dig more into the project, I'm sure you'll have more specific questions. By all means ask once you get there. (Also, I'll try to be a mentor, should your project be accepted. I may be on vacation part of the summer, hopefully not enough to impact your work too much.) --Juan

March 29, 2012

Implementing a DSS provider

by M C

Hello everyone, I am doing some research in regards GSOC, and would like to find out if anyone besides Juan Lang is experienced enough to make suggestions in regards to bug 10506 and/or the implementation of a DSS provider.

March 29, 2012

Re: [PATCH 2/5] dmusic: Enumerate ports for midi out and midi in devices in EnumPort.

by Christian Costa

Le 29/03/2012 20:25, Alexandre Julliard a écrit : > Christian Costa<titan.costa(a)gmail.com> writes: > >> With this patch I get exactly the same output for ports caps (except guid) as native. >> I kept the comment regarding dmusic32 usage altough the native version >> of dmusic I used does standard winmm calls to get port informations. >> --- >> dlls/dmusic/Makefile.in | 2 - >> dlls/dmusic/dmusic.c | 120 ++++++++++++++++++++++++++++++++--------------- >> 2 files changed, 82 insertions(+), 40 deletions(-) > It doesn't work here: > > ../../../tools/runtest -q -P wine -M dmime.dll -T ../../.. -p dmime_test.exe.so performance.c&& touch performance.ok > performance.c:111: Test failed: Got unexpected portcaps struct size: 00000004 > make[1]: *** [performance.ok] Error 1 > This happens in tests newly added by Andrew (dmusic: Support creating default ports with GUID_NULL). In his test, the dwSize member of the structure DMUS_PORTCAPS is not initialized before getting port caps This worked because before my patch only the Microsoft Synthetizer is enumerated and caps returned by the Synth GepCaps sets the dwSize member. I can sets the dwSize in my code but normally it's up to the caller to set the dwSize member. The callee should copy the number of bytes specified by dwSize or just return an error.

March 29, 2012

Re: [PATCH 2/5] dmusic: Enumerate ports for midi out and midi in devices in EnumPort.

by Alexandre Julliard

Christian Costa <titan.costa(a)gmail.com> writes: > With this patch I get exactly the same output for ports caps (except guid) as native. > I kept the comment regarding dmusic32 usage altough the native version > of dmusic I used does standard winmm calls to get port informations. > --- > dlls/dmusic/Makefile.in | 2 - > dlls/dmusic/dmusic.c | 120 ++++++++++++++++++++++++++++++++--------------- > 2 files changed, 82 insertions(+), 40 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M dmime.dll -T ../../.. -p dmime_test.exe.so performance.c && touch performance.ok performance.c:111: Test failed: Got unexpected portcaps struct size: 00000004 make[1]: *** [performance.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

March 29, 2012

Re: MsiGetFileHash

by Hans Leidekker

On Thu, 2012-03-29 at 18:29 +0200, Robert van Herk wrote: > + mapping = CreateFileMappingW( handle, NULL, PAGE_READONLY, 0, 0, NULL ); > + if (mapping) > + { > + p = MapViewOfFile( mapping, FILE_MAP_READ, 0, 0, length ); > + if (p) > + { > + MD5_CTX ctx; > + > + MD5Init( &ctx ); > + MD5Update( &ctx, p, length ); > + MD5Final( &ctx ); > + UnmapViewOfFile( p ); > + > + memcpy( pHash->dwData, ctx.digest, sizeof pHash->dwData ); > + r = ERROR_SUCCESS; > + } > + CloseHandle( mapping ); > + } > + } else { > + /* Empty file -> set hash to 0 */ > + memset( pHash->dwData, 0, sizeof pHash->dwData ); > + r = ERROR_SUCCESS; > } > + > CloseHandle( handle ); Please use 4 space indentation and put brackets on a new line like in the rest of that function. Same for the test. Please also provide a more descriptive subject line and prefix it with "msi: "

March 29, 2012

Re: SoC 2012 Ideas

by Stefan Dösinger

Am Mittwoch, 28. März 2012, 22:10:27 schrieb Charles Davis: > 2) HLSL compiler. My general response to "HLSL Compiler" would be "too complex for gsoc, too much work, nope", but since I know that you worked on compilers in the past it might work for you. I cannot promise anything of course, but my guess is that it is worth writing an application. I think three things would be important: 1) A plan how to integrate the compiler step by step. I think a general consensus is to start with a parser that can parse the entire (d3d9?) language, but I don't know what the idea is beyond that. 2) A flexible plan that allows for adjustments depending on how the project progresses, once a complete parser is done. The good thing about the parser is that I've once written a hacky compiler as a school project, and the parser is pretty much complete for d3d9 shaders. Even if the other code is pretty ugly, the parser should be reusable. 3) A design that is flexible enough for future needs(or well, d3d10/11). I am still afraid of getting stuck in a dead end street with anything written from scratch, but since all other options failed I guess that's the only way left. Maybe Henri and Matteo can weight in with their opinions as well. Cheers, Stefan

March 29, 2012

Re: [PATCH 3/3] (try2) gdi32: Add support for loading scalable font resources.

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > --- > dlls/gdi32/font.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 75 insertions(+), 0 deletions(-) This one doesn't build: gcc -m32 -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -Werror -I/usr/include/freetype2 -g -O2 -o font.o font.c font.c: In function ‘AddFontResourceExW’: font.c:3498:59: error: ‘count’ may be used uninitialized in this function [-Werror=uninitialized] font.c:3475:36: note: ‘count’ was declared here cc1: all warnings being treated as errors make[1]: *** [font.o] Error 1 Admittedly count would always be initialized with the files we create, but we probably shouldn't rely on that. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2012

Re: [PATCH 2/5] dmusic: Enumerate ports for midi out and midi in devices in EnumPort.

by Andrew Eikum

On Thu, Mar 29, 2012 at 04:18:20PM +0200, Christian Costa wrote: > It's the original code. I decided to keep it in this patch and add error > checking in the patch that comes just after. > I can merge them but I prefer to do things incrementally as much as > possible. Ah, sure enough. I missed that patch. Though in [3/5], you're missing assigning hr for _GetPortCaps(). I also think it would be nice to WARN with the result code in the failure case (or TRACE if a failure is expected in some cases). You know, the usual "if(FAILED(hr)){WARN(..., hr); return hr;}" error checking thing.

March 29, 2012

Re: [PATCH 5/5] dmusic: Implement partially SetDirectSound.

by Christian Costa

2012/3/29 Andrew Eikum <aeikum(a)codeweavers.com> > It would be nice to see some tests for this. For example, how does > this IDirectSound reference relate to the one created by > IDirectMusicPerformance::InitAudio()? > > There are few tests mark as todo in my first dmusic patch about interaction beween SetDirectSound and CreatePort. These tests were supposed to be fixed by this patch but it needed some stuff in CreatePort as well as GUID_NULL support. I removed this part because you send a patch for it. I will wait you patch gets in and resend the full version. More generally, wrt to SetDirectSound, I would like to focus first on dmusic only without dmime Init and InitAudio involved. I've another patch next involving dmime which fixes Init wrt to SetDirectSound. I also doing so InitAudio test but I don't know why I can event make the dmime tests running with all dlls as native.

March 29, 2012

Re: [PATCH 3/3] dmsynth: Put port caps that match native ones.

by Christian Costa

2012/3/29 Andrew Eikum <aeikum(a)codeweavers.com> > Just to be clear, which "native" do you mean? Does this match Windows > 7's dmusic behavior, or something else? I've been trying to target > Windows 7's behavior in the new audio design. > > They're recents but I don't remember. I will check this evening. I didn't know about Windows 7 target but I'm ok with that so I will aligned if needed. > Also... > > On Thu, Mar 29, 2012 at 08:53:52AM +0200, Christian Costa wrote: > > - obj->pCaps.dwEffectFlags = DMUS_EFFECT_REVERB | DMUS_EFFECT_CHORUS > | DMUS_EFFECT_DELAY; > > + obj->pCaps.dwEffectFlags = DMUS_EFFECT_REVERB; /* > DMUS_EFFECT_CHORUS | DMUS_EFFECT_DELAY */ > > I'd just remove the unused flags. No need for crufty comments. > > > Ok I will remove them.

March 29, 2012