I got this while running winedbg over deadlocked Gothic demo (v1.04d):
| 7 0x7fd362e5 SuspendThread+0x1d(hthread=0xc0)
[/usr/src/wine-cvs/wine/dlls/kernel/thread.c:348] in kernel32 (0x7aa8aaf8)
| fixme:dbghelp_msc:codeview_snarf Unsupported symbol id 5
| fixme:dbghelp_msc:dump : 0a 00 0
On Fri, 14 Oct 2005 07:19, Troy Rollo wrote:
> On Thursday 13 October 2005 19:22, Alexandre Julliard wrote:
> > It's probably easier to add a parallel set of CallDlgProc functions,
> > especially since this will require fewer changes to the assembly
> > thunks.
>
> I'll submit it both ways and you
Le jeudi 13 octobre 2005 à 21:29 -0400, Robert Reif a écrit :
> I guess I could have split it up into half a dozen patches.
>
> This is something I needed for work so I took the opportunity to
> do some wine hacking. I'm way to busy to do much more than
> just reading the mailing lists now and I
Vitaliy Margolen wrote:
1. Don't send patches in gz - only plain text is accepted here. ;)
2. This is not a good time for this changes (code freeze is still in affect).
Find some bugs in bugzilla to fix
Vitaliy.
I guess I could have split it up into half a dozen patches.
This is something
Thursday, October 13, 2005, 6:06:33 PM, Robert Reif wrote:
> Add DirectSoundFullDuplex support.
> This patch is rather large because it was necessary to refactor the
> existing code so it could be used by the full duplex code. Most of
> the changes are either changing all the code to use the lo
John Smith wrote:
THE MOST DIFFICULT THING IN GETTING BUG FIXED IS TO GET SOMEBODY WORK ON
IT.
If your business depends upon getting a Wine bug fixed, then you should
pay somebody to work on the problem. There are several companies
(including the one I work for) that can do this for you.
Hi,
On Monday 10 October 2005 09:06, Raphael wrote:
> Changelog:
> - begin of dwarf debug lines parsing
> - better robustness
> - support of unamed syms
> - better traces
>
> TODO:
> - find a clean way to handle forward declarations
> - debug lines parsing
>
as Eric wanted: without ty
On Thursday 13 October 2005 19:22, Alexandre Julliard wrote:
> It's probably easier to add a parallel set of CallDlgProc functions,
> especially since this will require fewer changes to the assembly
> thunks.
I'll submit it both ways and you can pick one.
If you want the bug fixed urgently, pay someone to do so.
John Smith wrote:
There was a discussion here about 2 months ago, where I asked for a
way to embed WINE config strings into Win32 executable (for example,
as string resources). I was told that it is better to fix the problem
rather tha
Hi,
[...]
> > Welcome to the real world
>
> Yes, we welcome you to the wonderful world of OpenSource.
>
> Please understand that a lot of us are not being paid ... and so just chose
> what to do. Some of us are paid to work on WINE, but for specific tasks.
>
> So your bug might lie around until som
On Thu, Oct 13, 2005 at 06:12:02PM +, John Smith wrote:
> There was a discussion here about 2 months ago, where I asked for a way to
> embed WINE config strings into Win32 executable (for example, as string
> resources). I was told that it is better to fix the problem rather than to
> create
Hi,
On Wednesday 12 October 2005 22:07, Oliver Stieber wrote:
> --- Daniel <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > some combination of wine and my system seems to be triggering a strange
> > bug:
> > Every program that uses OpenGL or D3D crashes upon trying to initialize
> > the graphics. Attac
Hello,
> No idea if any application would actually be really accelerated though.
Well, it didn't help Empire Earth, it broke the intro video(black screen, not
faster), but it showed me a bug in my code.
Stefan
Mike Hearn schrieb:
> On Wed, 12 Oct 2005 21:16:05 +, Eddahbi Karim wrote:
>
>>Now the mouse problem comes back but the workarounds don't work this
>>time. It's not a regression, it's a bug enhancement.
ACK
>>
>>The old workaround for WineX still work according to gentoo-forums [2].
>
>
Molle Bestefich wrote:
http://www.google.com/search?q=site%3Abugs.winehq.org doesn't work
either, Google does not index the contents of the bugs pages. Not
sure why.
See http:///bugs.winehq.org/robots.txt
I think at least the following paths should be opened up to GoogleBot
and other in
Raphael wrote:
but it's of no use with the patch you sent, so why clobber the patch
with this ?
no because i think its better to avoid assert in this case on dbghelp code :)
But if you prefer i can restore original code
IMO the correct fix would in field insertion to return one of three valu
On Thu, Oct 13, 2005 at 07:31:09PM +0200, Stefan Dösinger wrote:
> I always thought this patch was commited to CVS. Must have been mistaken.
Well, will see if doing a patch like that could help in the DirectX code
waiting for merging the DDraw and WineD3D code.
No idea if any application would ac
--- Mike McCormack <[EMAIL PROTECTED]> wrote:
>
> Damjan Jovanovic wrote:
>
> > The problem seems to be that after running for a
> > couple of seconds, all the file system calls like
> > ioctl() start failing with EBADF (bad file
> > descriptor). Is there something other than
> > wine_server_f
There was a discussion here about 2 months ago, where I asked for a way to
embed WINE config strings into Win32 executable (for example, as string
resources). I was told that it is better to fix the problem rather than to
create workarounds, and that fixing bugs is trivial and takes at most 2-3
Hi, wouldn't it be great to get Googleearth more or
less running before Wine 0.9 comes out. At least i
think it would be great as is is top voted application
and very popular. I did some investigation and found
that GoogleEarth suffers from at least 4 bugs. However
3 of them can be bypassed for no
Hello,
>I've got a hack that should make those kind of blits faster.
>http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html
I always thought this patch was commited to CVS. Must have been mistaken.
Stefan
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hello,
> I've got some real rending working with d3d7 and wined3d: The Empire Earth
> intro movie is playing. Well, it's only a 2D bitblt thing, but anyway.
>
Great, keep up the good work..
> It's terribly slow on my ATI radeon M9, some GL call
I think this is caused by theming. Frank Richter sent a patch for this
but it hasn't been accepted.
Le jeudi 13 octobre 2005 à 17:00 +0100, Mike Hearn a écrit :
> Hi,
>
> It seems that NSIS installers have regressed in Wine 0.9 - at least, the
> PE Explorer setup which looks and feels like an NSI
Hello,
I've got some real rending working with d3d7 and wined3d: The Empire Earth
intro movie is playing. Well, it's only a 2D bitblt thing, but anyway.
It's terribly slow on my ATI radeon M9, some GL calls take a lot of time, but
it looks correct. A screenshot can be found at
ftp://doesi.gmxho
Thursday, October 13, 2005, 10:00:07 AM, Mike Hearn wrote:
> Hi,
> It seems that NSIS installers have regressed in Wine 0.9 - at least, the
> PE Explorer setup which looks and feels like an NSIS based installer won't
> install with a "The folder name is invalid" error message. I poked at this
> a
Hi,
It seems that NSIS installers have regressed in Wine 0.9 - at least, the
PE Explorer setup which looks and feels like an NSIS based installer won't
install with a "The folder name is invalid" error message. I poked at this
a bit but got nowhere.
Can anybody confirm/deny it's a problem with al
On Wed, 12 Oct 2005 21:16:05 +, Eddahbi Karim wrote:
> Now the mouse problem comes back but the workarounds don't work this
> time. It's not a regression, it's a bug enhancement.
>
> The old workaround for WineX still work according to gentoo-forums [2].
It seems Warcraft relies upon NULL-add
> I have tried calling a native linux program with these (nautilus) and it
> consistently fails. Do I need a fully specified path (nautilus is in the
> search path mind you)?
I'd say that you're free to use a linux syscall to do whatever you want,
including forking the process and exec'ing the li
Troy Rollo <[EMAIL PROTECTED]> writes:
> OK, well an alternative is to do the same with them as with the
> CallWindowProc* entry points (rename them, add the extra parameter to each,
> and add new entry points under the existing names calling the versions with
> the BOOL parameter).
It's proba
On Thursday 13 October 2005 18:24, Alexandre Julliard wrote:
> Troy Rollo <[EMAIL PROTECTED]> writes:
> > So, what I propose to do is:
> >
> > 1. make __wine_call_wndproc_32A and __wine_call_wndproc_32W static (and
> > hence not exported)
>
> You can't do that, they need to be exported so that the
Troy Rollo <[EMAIL PROTECTED]> writes:
> They do not appear to be used anywhere outside of the file they are defined
> in, and it seems unlikely an app could ever have a legitimate use for them.
> Vitaliy suggested maybe they may have been inadvertently missed in a cleanup
> of cross-DLL calls.
> but it's of no use with the patch you sent, so why clobber the patch
> with this ?
no because i think its better to avoid assert in this case on dbghelp code :)
But if you prefer i can restore original code
> A+
Regards,
Raphael
pgpUAB1PaRkR3.pgp
Description: PGP signature
On Wednesday 12 October 2005 21:09, Oliver Stieber wrote:
> Hi,
>This patch allows cube textures to be updated fixing one of the problems
> in BUG 3550
>
> Oliver.
Good catch (for a long time i was trying to find what happened)
Regards,
Raphael
pgpx8VuRKbkzQ.pgp
Description: PGP signature
On Wed, Oct 12, 2005 at 09:07:18PM +0100, Oliver Stieber wrote:
> This seems weird, glxinfo says that glXChooseFBConfig should return
> something but
> err:opengl:X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError:
> 0)
> says that it isn't, I've checked through the code and it
34 matches
Mail list logo
