> > I recently tried 2.6.18.1 kernel and wine stoped working. Then I
> > downgraded to 2.6.16.18 and wine working fine now.
>
> I'm using a custom built 2.6.18.1 on Debian Unstable/AMD64 now, and Wine
> works fine for me, so this is unlikely to be a Wine problem.
I compiled 2.6.18.1 wi
"Andrew Talbot" <[EMAIL PROTECTED]> wrote:
The last formal argument of MCIWndCreate() is not const-qualified in the SDK.
It is in my version of the PSDK headers, but it is not in the PSDK docs.
--
Dmitry.
"Andrew Talbot" <[EMAIL PROTECTED]> wrote:
-typedef void *MSIITERHANDLE;
+typedef void*MSIITERHANDLE;
+typedef const void *MSICITERHANDLE;
Personally I don't like MSICITERHANDLE typedef at all. It' not obvious
that 'C' in the name marks constness of the object. Using 'const' explicitl
L. Rahyen wrote:
The system is gentoo linux (2.6.18-gentoo-r1)
I recently tried 2.6.18.1 kernel and wine stoped working. Then I downgraded
to 2.6.16.18 and wine working fine now.
I'm using a custom built 2.6.18.1 on Debian Unstable/AMD64 now, and Wine
works fine for me, so this is unlikel
> The system is gentoo linux (2.6.18-gentoo-r1)
I recently tried 2.6.18.1 kernel and wine stoped working. Then I
downgraded
to 2.6.16.18 and wine working fine now.
After doing some important work, I will recompile 2.6.18.1 again with
same .config and will see what happens. But b
# wine --version
Works!
But:
Makefile
-
test:
wine --version
-
Then run:
#make test
Wine will segfault!
I am having the same problem.
I use wine to run a compiler from a Makefile. A few months ago,
it worked fine, but recently it stopped working. I even downgraded
to
On 04.11.2006 19:35, Jaap Stolk wrote:
> On 11/4/06, Louis. Lenders <[EMAIL PROTECTED]> wrote:
>> Hi, subject says it: When will ie6 registry key be added?
>
> Adding registry keys will not fix all of these problems. Some
> installers also check the version info of the (stub) dll's in wine.
> (in
On Fri, Nov 03, 2006 at 01:57:33PM +0100, Roderick Colenbrander wrote:
> > one of the patches from 2006-10-31 fixed my problems as it seems.
> > IL2 now crashed out 1 of 4 starts but with another error. the
> > remaining stuff is fine - although NASCAR 2003 is very slow now.
> Regarding the slowne
On 11/4/06, Louis. Lenders <[EMAIL PROTECTED]> wrote:
Hi, subject says it: When will ie6 registry key be added?
Adding registry keys will not fix all of these problems. Some
installers also check the version info of the (stub) dll's in wine.
(in my case, Autocad 2004)
In cases where a faked re
Roderick Colenbrander wrote :
Could you check if the attached patch works? It does more or less what I
explained in the last email. If it works I'll clean it up as right now it is a
bit hacky. I hope to find some apps to test it on.
Regards,
Roderick
Your patch fixes everything : WoW does no
> > Roderick Colenbrander wrote :
> > >> Roderick Colenbrander wrote :
> > >>
> > >>> Or perhaps a testcase isn't needed at all. I think the use of
> > >> CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to
> > MSDN this
> > >> function creates a memory device context. Perhaps somet
Robert Reif <[EMAIL PROTECTED]> writes:
> This last commit:
> http://www.winehq.org/pipermail/wine-cvs/2006-November/027508.html
> totally breaks wine on Red Hat 9.
How is it broken?
> Red Hat 9 has been partially broken since 2.4 kernel support has been
> dropped a while back but this patch mak
This last commit:
http://www.winehq.org/pipermail/wine-cvs/2006-November/027508.html
totally breaks wine on Red Hat 9.
Red Hat 9 has been partially broken since 2.4 kernel support has been
dropped a while back but this patch makes it totally unusable.
It is unfortunate that 2.4 kernel suppor
> Roderick Colenbrander wrote :
> >> Roderick Colenbrander wrote :
> >>
> >>> Or perhaps a testcase isn't needed at all. I think the use of
> >> CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to
> MSDN this
> >> function creates a memory device context. Perhaps something like this
Roderick Colenbrander wrote :
Roderick Colenbrander wrote :
Or perhaps a testcase isn't needed at all. I think the use of
CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to MSDN this
function creates a memory device context. Perhaps something like this works:
HDC hdc = Create
> Roderick Colenbrander wrote :
>
> > Or perhaps a testcase isn't needed at all. I think the use of
> CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to MSDN this
> function creates a memory device context. Perhaps something like this works:
> > HDC hdc = CreateDC(...);
> > int fo
Stefan Dösinger wrote:
With vertex fixups I'd expect it to give 20-25 fps. You can test what you're
likely to get with the attached hack.
Gain with Bf1942 is about 20-30%, not bad for a one liner.
Roderick Colenbrander wrote :
Or perhaps a testcase isn't needed at all. I think the use of
CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to MSDN this
function creates a memory device context. Perhaps something like this works:
HDC hdc = CreateDC(...);
int format_orig = GetP
Stefan Dösinger <[EMAIL PROTECTED]> writes:
> +GetWindowRect(((IWineD3DSwapChainImpl
> *)This->swapchains[0])->win_handle, &windowRect);
> +/* Warning: glScissor uses window coordinates, not viewport coordinates,
> so our viewport correction does not apply
> +* Warning2: Even in wind
> > Roderick Colenbrander wrote :
> > >> Hi,
> > >>
> > >> After investigating a bit in the Wine code, it seems that the
> > flickering
> > >> bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a
> > DC
> > >> which type is OBJ_MEMDC while it should return a DC which type is
> >
"Kai Blin" <[EMAIL PROTECTED]> wrote:
--- a/dlls/secur32/ntlm.c
+++ b/dlls/secur32/ntlm.c
@@ -1345,22 +1345,32 @@ static SECURITY_STATUS SEC_ENTRY ntlm_Ve
if(helper->neg_flags & NTLMSSP_NEGOTIATE_SIGN)
{
SecBufferDesc local_desc;
-SecBuffer local_buff[2];
+Sec
> Roderick Colenbrander wrote :
> >> Hi,
> >>
> >> After investigating a bit in the Wine code, it seems that the
> flickering
> >> bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a
> DC
> >> which type is OBJ_MEMDC while it should return a DC which type is
> >> OBJ_DC. And si
Roderick Colenbrander wrote :
Hi,
After investigating a bit in the Wine code, it seems that the flickering
bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a DC
which type is OBJ_MEMDC while it should return a DC which type is
OBJ_DC. And since in the current git tree, the
> Hi,
>
> After investigating a bit in the Wine code, it seems that the flickering
> bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a DC
> which type is OBJ_MEMDC while it should return a DC which type is
> OBJ_DC. And since in the current git tree, the DC type of a Pbuffer
Jesse Allen wrote :
On 11/3/06, Bertrand Coconnier <[EMAIL PROTECTED]> wrote:
Hi,
After investigating a bit in the Wine code, it seems that the flickering
bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a DC
which type is OBJ_MEMDC while it should return a DC which type is
O
Hi, subject says it: When will ie6 registry key be added?People are filing bugs against wine, because installers fail, saying ie6 has to be installed. I guess in most cases, they will rush for ies4linux (which is btw a great script i think, but useless to use other apps then ie6) and end up with a
26 matches
Mail list logo
