On 27 January 2010 20:14, Arjun Comar wrote:
> @Henri: I'm always up for a challenge. Perhaps you could suggest a smaller
> subset of the problem that would be more feasible to attempt in 2-3 months?
> Perhaps a few effects rather than any significant chunk of them? Also, what
> are you looking fo
That sounds interesting, and may be a good way to learn. I'll CC this reply
to him to see if he still needs somebody.
@Tony: It'd be slow going since I still need to learn how everything works,
but if you're willing to work with me, I don't mind helping you out with
your project.
On Wed, Jan 27,
Howdy!
While you're figuring out your proposal, you might want
to look over the code from previous SoC (or university) Wine
projects that didn't quite make it in. One easy one might
be the dxdiag written by the UCLA students.
Dusting it off and bringing some of its features into the wine tree
migh
Alexandre Julliard wrote:
Michael Ost writes:
I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so
all users from any .wine directory can launch it with a script that
contains 'exec wine APP.exe'. I'm mimicking how, say, regedit works.
During development I want to run a devel
> Hello,
>
> Well I'm mostly interested in the texture code, but I probably shouldn't
> begin with that. So I'll take the font code. It's not really a critical
> part so I can take my time doing it and learning wine development
> without conflicts with my normal schedule. Then if the texture code
Michael Ost writes:
> I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so
> all users from any .wine directory can launch it with a script that
> contains 'exec wine APP.exe'. I'm mimicking how, say, regedit works.
>
> During development I want to run a development-local APP.exe
Alexandre Julliard wrote:
Michael Ost writes:
The first step would probably be to explain why you need to have an app
with the same name as an existing builtin.
Right, ok.
I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so
all users from any .wine directory can launch it w
On 01/22/2010 03:48 PM, Tony Wasserka wrote:
> [...]
> As for the affected bug reports, just search for the "d3dx" or
> "createtexture" terms on bugzilla ;) No non-DX-SDK apps are really
> dependant on the mesh stuff AFAIK, only few on the font stuff (e.g. the
> Dolphin emulator), so there aren't r
hi arjun,
it's good to see your interest :)
tony has been searching for someone to integrate his gsoc work, see:
http://www.winehq.org/pipermail/wine-devel/2010-January/081160.html
maybe you are that guy? ;) it would serve as an introduction to the
d3d environment at least. maybe too much idk.
i
Michael Ost writes:
> Alexandre Julliard wrote:
>> Actually the current way is precisely what LD_LIBRARY_PATH does for
>> relocatable installs. The loader first looks in the rpath $ORIGIN path,
>> then in LD_LIBRARY_PATH, then in system directories. Wine does exactly
>> the same thing.
>
> I did
Thanks everybody for the replies.
>Welcome! I'm glad you've chosen Wine; we can sure use more help.
>
>Sounds like you know your way around, but please feel free to ask for help
>anytime. The IRC channel works particularly well; real discussions will
>keep us from being annoyed by the trolls.
>
Alexandre Julliard wrote:
Michael Ost writes:
I agree. And that's what your patch does, right? Would you like to
submit it to the wine-patches list? I think the case for it is strong,
especially since (1) you found that it fixes a behavior change in
WINEDLLPATH from November 2006 --- arguably
Juan Lang writes:
> Fix for bug 21501.
It doesn't work here:
../../../tools/runtest -q -P wine -M wintrust.dll -T ../../.. -p
wintrust_test.exe.so softpub.c && touch softpub.ok
softpub.c:491: Test failed: expected TRUST_E_NOSIGNATURE or CRYPT_E_FILE_ERROR,
got 0006
make[2]: *** [softpub.o
On Wed, Jan 27, 2010 at 8:36 AM, Michael Stefaniuc wrote:
> Tom Wickline wrote:
>> On Wed, Jan 27, 2010 at 8:32 PM, Paul Vriens
>> wrote:
>>> Not sure how new it is, but it looks like 2.5.33 is the minimum:
>>>
>>> http://source.winehq.org/git/wine.git/?a=commitdiff;h=ce3077e55d76c3870f5724c
On 01/27/2010 04:41 PM, joerg-cyril.hoe...@t-systems.com wrote:
Hi,
my (unreleased) MIDI tests have spotted that not all versions of MS-Windows
seem to send out the MM_MOM_POSITIONCB callback/notification resulting from
a MEVT_F_CALLBACK event in midiStreamOut(). w9X/ME appears not to know abou
Hi,
my (unreleased) MIDI tests have spotted that not all versions of MS-Windows
seem to send out the MM_MOM_POSITIONCB callback/notification resulting from
a MEVT_F_CALLBACK event in midiStreamOut(). w9X/ME appears not to know about
it.
Machines since NT honour it (even though I've seen mixed re
Ilya Shpigor wrote:
> +static void test_TranslateCharsetInfo(void)
> +{
> +/* Any other codepages are not supported
> + * by TranslateCharsetInfo in Windows XP
> + */
> +test_codepage(42, 2);
> +test_codepage(874, 222);
> +test_codepage(932, 128);
> +test_codepage(936,
Stefan Dösinger wrote:
> Am 27.01.2010 um 13:16 schrieb Henri Verbeet:
>
>> On 27 January 2010 12:57, Tony Wasserka wrote:
>>> at the msdn documentation to see the whole list of interfaces. I guess
>>> the most profitable would be implementing the effect interfaces, since
>>> these are the most u
Tom Wickline wrote:
> On Wed, Jan 27, 2010 at 8:32 PM, Paul Vriens
> wrote:
>> Not sure how new it is, but it looks like 2.5.33 is the minimum:
>>
>> http://source.winehq.org/git/wine.git/?a=commitdiff;h=ce3077e55d76c3870f5724cd995e980e4756
>>
>> --
>> Cheers,
>>
>> Paul.
> The version check
On Wed, Jan 27, 2010 at 8:32 PM, Paul Vriens wrote:
> On 01/27/2010 01:25 PM, Stefan Dösinger wrote:
>>
>> It would help a lot if the code from last years gsoc d3dx9 projects made
>> it into wine git sooner rather than later to allow new participants to build
>> on it. I don't know what the state
On 01/27/2010 11:01 AM, Ilya Shpigor wrote:
Hi Ilya,
These tests introduce failures on Win9x/NT4:
https://winetestbot.geldorp.nl/JobDetails.pl?Key=456
It would maybe be worthwhile to add some more info to the traces by
using __LINE__ for example (see examples in other tests).
You can req
On 27 January 2010 13:07, Stefan Dösinger wrote:
> Am 27.01.2010 um 11:19 schrieb Henri Verbeet:
>> You shouldn't need that. It only flushes for the current context anyway.
> From section 5.2.2 in the extension:
>> If the sync object being blocked upon will not be signaled in finite
>> time
On 01/27/2010 01:25 PM, Stefan Dösinger wrote:
It would help a lot if the code from last years gsoc d3dx9 projects made it
into wine git sooner rather than later to allow new participants to build on
it. I don't know what the state of Tony's work is, but I think the only real
concern blocking
Am 27.01.2010 um 13:16 schrieb Henri Verbeet:
> On 27 January 2010 12:57, Tony Wasserka wrote:
>> at the msdn documentation to see the whole list of interfaces. I guess
>> the most profitable would be implementing the effect interfaces, since
>> these are the most used ones next to shaders and t
On 27 January 2010 12:57, Tony Wasserka wrote:
> at the msdn documentation to see the whole list of interfaces. I guess
> the most profitable would be implementing the effect interfaces, since
> these are the most used ones next to shaders and textures. I'm not sure
I'm sure the effect interface w
Am 27.01.2010 um 11:19 schrieb Henri Verbeet:
>> The only deeper change in patch 3 is that I am passing
>> GL_SYNC_FLUSH_COMMANDS_BIT. I think this is reasonable when we're waiting
>> for drawing to complete.
>>
> You shouldn't need that. It only flushes for the current context anyway.
>From se
Hi,
We've had two D3DX projects last year - one implementing shaders, the
other (which was mine) implementing meshes, fonts and texturing code.
Both have only partially been integrated, yet (as far as I know), but
most of the other stuff in d3dx9 is still untouched, you can take a look
at the msdn
Hi,
I'm seeking advice and ideas about 2 issues:
A) I've added trace() output to a callback function. On a
dual-core XP box, output comes out like follows:
mmidiid.ci:56.: Ccall:bac7k! 9m: sTg=e3c9s 1t2 fef58 a0
iled: Message 3c9 from command midiStreamOut
which is a mixture of characters fro
On 26 January 2010 20:22, Stefan Dösinger wrote:
> Patch 2 moves the event query faking out of the way. That allows me to remove
> all GL extension checks, and the buffer code just checks if it can create a
> d3d event query. (Patch 1 removes some dead code I ran into). Once Mesa
> supports ARB
Hi folks,
Google announced this year's GSoC incarnation. It would be nice if everybody
could have a look at http://wiki.winehq.org/SummerOfCode and check if the
project they want to mentor is on there. Also, feel free to propose new
projects, assuming a student with low prior knowledge about Wi
30 matches
Mail list logo