Hi Chris,
2010/4/1 Chris Robinson chris.k...@gmail.com:
On Wednesday 31 March 2010 2:00:57 pm Maarten Lankhorst wrote:
+ local_contexts = palcIsExtensionPresent(NULL,
ALC_EXTX_thread_local_context);
Missed a spot? Don't forget to use the correct function names for the
completed
On Wed, Mar 31, 2010 at 01:28:23PM +0200, wy...@volny.cz wrote:
Hi guys,
if it is not too late, i would have a proposal for GSoC. I'm waiting
quite long for BuildActionMap, SetActionMap, EnumDevicesBySemantics
co, i.e. to make games like need for speed happy/playable (bug 8754).
Thanks
Am 31.03.2010 um 22:41 schrieb John Koelndorfer:
Concerning tests, a possible project would be to pick an ATI and Nvidia GPU
and make sure that our existing
conformance tests pass on both GPUs on at least WinXP, WinVista and Win7.
Currently there is no single
Windows setup that can run all
On Thursday 01 April 2010 06:15:41 John Koelndorfer wrote:
DESCRIPTION
In Wine daily (as of 3/31/2010) .NET fails to install. The Wine debugging
output is riddled with stubs and fixmes. My initial work would be to examine
which functions are needed by the installer and prioritize work on
Hi Wine-devel
My name is Morten and I would like for some of my old DOS/WIN95 games to
work with wine. :)
I know that I most likely could solve this by using DOSbox and/or DOSemu.
But I don't consider either of them user friendly in it's raw form.
And I hope in the future it could be more of
- PŮVODNÍ ZPRÁVA -
Od: Marcus Meissner mar...@jet.franken.de
Komu: wy...@volny.cz
Předmět: Re: GSoC - keyboard input
Datum: 1.4.2010 - 9:08:48
On Wed, Mar 31, 2010 at 01:28:23PM +0200, wy...@volny.cz
wrote:
Hi guys,
if it is not too late, i would have a proposal for
GSoC. I'm
On Thu, Apr 1, 2010 at 10:17 AM, Morten Rønne morten.roe...@tdcadsl.dk wrote:
Hi Wine-devel
My name is Morten and I would like for some of my old DOS/WIN95 games to
work with wine. :)
I know that I most likely could solve this by using DOSbox and/or DOSemu.
But I don't consider either of
On 1 April 2010 12:50, Roderick Colenbrander thunderbir...@gmail.com wrote:
- if (is_identity_fixup(src_format_desc-color_fixup))
- {
- TRACE([OK]\n);
- return TRUE;
- }
-
When did we stop supporting those?
+ arbfp_blit.set_shader((IWineD3DDevice *)device,
On 1 April 2010 12:50, Roderick Colenbrander thunderbir...@gmail.com wrote:
---
dlls/wined3d/arb_program_shader.c | 20 +++-
dlls/wined3d/directx.c | 2 +-
dlls/wined3d/surface.c | 46 +---
On 31 March 2010 15:07, Roderick Colenbrander thunderbir...@gmail.com wrote:
I have worked on some more parts of the blit_shader code. Before I
clean it up and submit it, I'm posting it here to see if the direction
is ok.
I already commented on some issues with 0007 and 0008 since you
already
On Thu, Apr 1, 2010 at 1:45 PM, Henri Verbeet hverb...@gmail.com wrote:
On 1 April 2010 12:50, Roderick Colenbrander thunderbir...@gmail.com wrote:
- if (is_identity_fixup(src_format_desc-color_fixup))
- {
- TRACE([OK]\n);
- return TRUE;
- }
-
When did we stop
On 1 April 2010 14:27, Roderick Colenbrander thunderbir...@gmail.com wrote:
My feeling was that we only want to use arbfp_blit for complex fixups
and identity fixups are better suited for fbo_blit/ffp_blit.
fbo_blit doesn't exist yet here, and may be unavailable depending on
available
Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander:
First of all welcome to Wine. Myself I'm a bit worried about whether
we should improve our DOS support even further. The problem is that
more and more people are moving over to 64-bit Linux. While you can
run 32-bit programs on a 64-bit
Stefan Dösinger wrote:
Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander:
First of all welcome to Wine. Myself I'm a bit worried about whether
we should improve our DOS support even further. The problem is that
more and more people are moving over to 64-bit Linux. While you can
run 32-bit
On Tue, 30 Mar 2010 22:36:21 +0700, Alexandre Julliard
julli...@winehq.org wrote:
Mikhail Maroukhine mik...@yandex.ru writes:
- winedump/search.c::get_type - cleanup variable usage
That's not much better. It would be cleaner to stop abusing the passed
argument as a local variable.
I wrote a wiki page yesterday about the current state of Mono
integration in Wine and what I think needs to be done about it. That
is at: http://wiki.winehq.org/Mono
Basically, if you install Mono in Wine, Wine will use it to run .NET
programs. However, the combination doesn't work for any of the
On Thu, Apr 1, 2010 at 11:14 AM, Vincent Povirk
madewokherd+8...@gmail.com wrote:
I wrote a wiki page yesterday about the current state of Mono
integration in Wine and what I think needs to be done about it. That
is at: http://wiki.winehq.org/Mono
Basically, if you install Mono in Wine, Wine
On Thu, Apr 1, 2010 at 11:16 AM, Detlef Riekenberg wine@web.de wrote:
With greeting from the current day.
hehe nice
* If an installer for something other than .NET tries to install .NET,
file a bug for that with the dotnet keyword.
For any .Net version (1.1, 2.0, 3.5)? Does that also count for service
packs? I take it your recent work on mscoree should fake a dotnet
installation?
Any .NET version. Mono
This is not something within GSOC scope in my opinion, I expect you will
need 6 weeks alone to get up to speed with the concepts of msi and patching.
In general I think it's better to identify a small set of APIs to implement
or improve instead of aiming for a broad goal like improving .net
On Thu, Apr 1, 2010 at 11:27 AM, Vincent Povirk
madewokherd+8...@gmail.commadewokherd%2b8...@gmail.com
wrote:
* If an installer for something other than .NET tries to install .NET,
file a bug for that with the dotnet keyword.
For any .Net version (1.1, 2.0, 3.5)? Does that also count for
On Thu, Apr 1, 2010 at 6:31 PM, John Koelndorfer jkoelndor...@gmail.com wrote:
This is not something within GSOC scope in my opinion, I expect you will
need 6 weeks alone to get up to speed with the concepts of msi and patching.
In general I think it's better to identify a small set of APIs to
The compatibility information basically indicates that Mono can substitute
for .NET below version 3.0. 3.0 and higher still needs Microsoft's
implementation.
How would you handle hybridizing Mono with Microsoft's framework?
You would need different wine prefixes if you want to use both at
The compatibility information basically indicates that Mono can substitute
for .NET below version 3.0. 3.0 and higher still needs Microsoft's
implementation.
How would you handle hybridizing Mono with Microsoft's framework?
You would need different wine prefixes if you want to use
AFAIK mono doesn't implement WPF, so any .NET app that uses it is likely to
fail in mono. Correct me if i'm wrong
This is true, and according to
http://www.mono-project.com/Compatibility they have no plans to
implement it. But someone could, and even if the mono project doesn't
want it, it
Mikhail Maroukhine mik...@yandex.ru writes:
Hello,
Could you clear a little what do you mean under stop abusing?
I've removed incorrect usage of constness in declaration for the
variable that is changed for sure.
I've send try 2 patch with additional correction and extended log
message.
I
On Thu, Apr 1, 2010 at 7:24 PM, Vincent Povirk
madewokherd+8...@gmail.com wrote:
If you want to do something in the .NET area perhaps some work can be
done on Mono integration (see the mono topic Vincent started) and the
wiki (http://wiki.winehq.org/Mono).
While this has the advantage of
* On Thu, 1 Apr 2010, Stefan Dösinger wrote:
Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander:
Myself I'm a bit worried about whether we should improve our DOS
support even further. The problem is that more and more people are
moving over to 64-bit Linux. While you can run 32-bit
joerg-cyril.hoe...@t-systems.com a écrit :
Hi,
Eric Pouech wrote:
did you test the 16 = 32 bit conversion for the MCI_ALL_DEVICE ?
Which ones do you have in mind? There are tests involving MCI_ALL_DEVICE_ID
that pass on both win9x and later (also in patch #5). I wrote a few
more MCI
joerg-cyril.hoe...@t-systems.com a écrit :
Hi,
Eric Pouech wrote:
did you test the 16 = 32 bit conversion for the MCI_ALL_DEVICE ?
It's good you asked. Upon closer inspection, MCI_Sysinfo appears to
behave differently. I'd say it's even a bug in MS that setting
joerg-cyril.hoe...@t-systems.com a écrit :
Hi,
Eric Pouech wrote:
this patch is ugly as hell...
Please qualify. To me,
- data[3] = (DWORD_PTR)dev;
+ parms.open.lpstrElementName = dev;
looks more robust than before:
- no magic offsets,
- no casts that may silence
Just my 2 phennings worth on this...
Why reinvent the wheel... I would say instead of doing the emulator inside
wine... or a JIT... why not have
wine intersept the call to start the vm86 mode.. and forks off and starts
DOSEMU or whatever DOS box system is
configured.. That way wine doesnt have
John Klehm wrote:
On Thu, Apr 1, 2010 at 11:16 AM, Detlef Riekenberg wine@web.de wrote:
With greeting from the current day.
hehe nice
Like the part about world domination. However, that will have to wait
for Linux/MacOSX to be the OS of choice. :)
James McKenzie
Eric wrote:
With this patch set, one can get rid of most of the non visible parameters
values
while using a backtrace in winedbg.
That's great news, thanks, hope it goes in soon!
34 matches
Mail list logo
