Re: Wine: DirectDraw over Direct3D
On Tuesday 13 December 2005 21:43, Mike Hearn wrote: > On Mon, 12 Dec 2005 21:11:44 +0100, Stefan Dösinger wrote: > > In Wine, there are 2 ways: The first is to use X calls, which is safe, > > but slow. > > What makes you think that? X drawing primitives as well as XRender should > be hardware accelerated even though they aren't OpenGL. No, most of basic X primitives aren't not really hw accelerated XAA is inadequate for recent graphic cards (status http://wiki.x.org/wiki/XorgPerformance). For example, for texturing most of primitives are based on software algorithms (and Mesa do it faster). With EXA it's better but it's not perfect yet (improving little by little) Regards, Raphael pgpdtlqcYUpua.pgp Description: PGP signature
Regression in Wine on FreeBSD (DVD Shrink)
Hello All, Lately I've been trying to track down a problem that prevents DVD Shrink 3.2 from starting on FreeBSD in any version of Wine built on/after 04-20-2005 (including the recent beta releases). Any version built prior to this works fine. I've tracked the problem down to the changes made to x11drv/dib.c (and associated) on 04-20-2005. I'm not fluent in C; I merely found the problem through trial and error. If I copy the x11drv/dib.c (and ntdll/, so the old dib.c will work) from 04-18-2005 in place of the one introduced on the 20th, the problem disappears and DVD Shrink fires right up. Changing dib.c (and dib.c only) back to the 20th snapshot re-introduces the problem, and DVD Shrink hangs again. As I don't understand the code, I don't know how to detect where the problem really lies, as the dib.c changes may only be indirectly responsible. I am very willing to test for or aid anyone who wouldn't mind helping with this problem, however. I have already contacted the author of the changes (dib.c and associated) and he suggested I try this list. If anyone would like to glance at the differences between the two files I've mentioned above, I have posted a diff here: http://lickwid.net/~tlp/dib.c.diff --- are the old and working changes +++ are the new and broken changes Any help would be greatly appreciated. Thanks, -- Travis Poppe IRC: tlp @ irc.freenode.net
Re: WINE-NB.BLOCK
> Hello, > > I`m sorry, but my English is not so good, but I`m trying to get an answer > about: > > I have installed SUSE 10.0, then WINE and then WINETOOLS. and the IE6. Now, > when I press the key comma, on the numeric-block, I get the remove > function. When I press die remove function an the cursor-block, I get a > comma. > > The function is always the same. It is the same when I put the > numeric-block on or off. > > How I can get a comma on the right key? > > Thank you for your understanding for my schoolenglish! > > Rüdiger
Re: gethostbyname(my_name) and IL2-Sturmovik
Am Dienstag, 13. Dezember 2005 20:14 schrieb Juan Lang: > I still think David's patch could use some work, What's wrong with the new version? Greetings, David
Re: Wine: DirectDraw over Direct3D
On Mon, 12 Dec 2005 21:11:44 +0100, Stefan Dösinger wrote: > In Wine, there are 2 ways: The first is to use X calls, which is safe, but > slow. What makes you think that? X drawing primitives as well as XRender should be hardware accelerated even though they aren't OpenGL.
Re: Problems generating c++ project since wine 0.9.3
Vincent Béron wrote: >> Is there something that I am misisng when generating this project? Or is >> this a known issue? > > Known problem (caused then fixed by me). > The fix was committed after 0.9.3, and is the patch available from > http://source.winehq.org/git/?p=wine.git;a=commitdiff_plain;h=fe987b303581740cb96231a9abc42987473451db;hp=2b4377f5eb0a8b11484e4f053f9dbcf765c5a32d > > Vincent Thank you, the patch solved the problem.
Create new mailing list wine-isv?
I used to hate the term ISV (Independent Software Vendor) since it sounded so acronymy compared to 'developer', but it's very commonly used in the industry to refer to outfits which are trying to write and sell off-the-shelf software -- and as monkey-boy said, Microsoft is where it is partly because it worked hard to attract and support those guys. So I've been thinking about how to attract more Windows ISVs to test, support, and promote their apps on Linux with Wine. Part of the problem is a lack of high-level documentation specifically aimed at the ISV. Another is ISVs getting lost in the shuffle on wine-users or wine-devel. I've made a start at the documentation (http://kegel.com/wine/isv), and hope to move that to winehq at some point. Now I'd like to create a discussion forum for ISVs where they will feel more comfortable; the level of discussion would be halfway between that in wine-users and wine-devel, but aimed more at Windows developers than people who are familiar with Linux. How about we create a new mailing list, wine-isv, aimed squarely at ISVs and the Wine community members who want to help them? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
[wined3d] Converting Wined3d to use WGL instead of GLX
Hello all, As I mentinoed in a recent post, I have almost completed the GLX->WGL conversion. Last night I tracked down my last bug that was causing most of my demo apps to fail. It seems that the problem was the conversion from glXGetProcAddress to using wglGetProcAddress. wined3d uses glXGetProcAddress to get the OpenGL extension function pointers, which is what wglGetProcAddress also does. However wglGetProcAddress _first_ checks opengl32.dll for the extension and returns the thunk function pointer if it exists, and only then falls back to libGL.so by calling glXGetProcAddress. So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I get crashes in most D3D9 applications. If I use glXGetProcAddress in wined3d everything works fine, but then wined3d is still dependent on glx. So my questions: 1) should the thunks returned from wglGetProcAddress be causing crashes at all? Note that they don't crash right away, but "eventually" usually during a call to glDrawArrays it seems (after a call to glSecondaryColor3fEXT). 2) what is the reason for wglGetProcAddress to check opengl32.dll before libGL.so? Would the reverse logic still be a resonable solution? Regards, Aric
Re: Can't install mdac at all now
On 12/13/05, Raphael <[EMAIL PROTECTED]> wrote: > Hi Dan, > my patch haven't been commited so it doesn't work I think you misunderstand. There's been a regression. Things are worse than before, even with your patch not applied before or after; your patch was to unpack the cabs, but they don't even get copied now, let alone unpacked. > Markus is working on a better implementation Any ETA? I guess I'll stop worrying, if he's going to get that area working, he'll fix this regression anyway. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: question regarding FindWindow
Marcus Meissner wrote:
Hi,
While debugging Google Earth I see hangs in FindWindow...
Apparently the
if (GetWindowTextW( list[i], buffer, len + 1 ) && !strcmpiW( buffer, title )) break;
call hangs on the server... But how is this possible?
+win,+server snippet:
trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE
0009: redraw_window( window=0x10020, flags=0005, region={} )
0009: redraw_window() = 0
trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE
0009: redraw_window( window=0x10020, flags=0005, region={} )
0009: redraw_window() = 0
0009: get_window_children( parent=0x10020, atom=, tid= )
0009: get_window_children() = 0 { count=3, children={0x10026,0x10024,0x10022} }
fixme:win:WIN_FindWindow before getwindowtext
fixme:win:WIN_FindWindow after getwindowtext
fixme:win:WIN_FindWindow before getwindowtext
0009: send_message( id=0010, type=1, flags=0, win=0x10024, msg=000d,
wparam=0023, lparam=55937970, x=0, y=0, time=10a4, info=00
00, timeout=0, callback=(nil), data={} )
0009: send_message() = 0
0009: get_msg_queue( )
0009: get_msg_queue() = 0 { handle=0x148 }
0009: set_queue_mask( wake_mask=8040, changed_mask=8040, skip_wait=1 )
0009: set_queue_mask() = 0 { wake_bits=, changed_bits= }
0009: select( flags=4, cookie=0x55c1f6f8, signal=(nil), timeout=0,
handles={0x148,0x80} )
0009: select() = PENDING
*hang*
What debug to enable and what to look at?
Look at why the message loop for 0x10024 doesn't process the message.
This may be one of the things that Windows handles in the server rather
than sending messages to each window.
Rob
Re: WLDAP32: link to the reentrant version of libldap
Hans Leidekker wrote: The configure check somehow needs -lpthread on Fedora based systems but Wine's build system links wldap32 to libldap_r without it just fine. Adding -lphtread to the configure check doesn't seem to cause any trouble on my Debian based Ubuntu either (where it isn't needed). I suspect it's a problem with the (newer) autoconf tools in Fedora. -Hans Changelog Link to the reentrant version of libldap. f891a05d34c03c99b3476dea041cca3f9e06cc09 diff --git a/configure.ac b/configure.ac index a834d40..4b9a0f2 100644 --- a/configure.ac +++ b/configure.ac @@ -542,15 +542,20 @@ then fi dnl Check for OpenLDAP *** +saved_libs="$LIBS" +LIBS="$LIBS $LIBPTHREAD" + AC_SUBST(LDAPLIBS,"") if test "$ac_cv_header_ldap_h" = "yes" -a "$ac_cv_header_lber_h" = "yes" then -AC_CHECK_LIB(ldap, ldap_initialize, +AC_CHECK_LIB(ldap_r, ldap_initialize, [AC_CHECK_LIB(lber, ber_init, [AC_DEFINE(HAVE_LDAP, 1, [Define if you have the OpenLDAP development environment]) - LDAPLIBS="-lldap -llber"])]) + LDAPLIBS="-lldap_r -llber"])]) fi +LIBS="$saved_libs" + dnl Check for FreeType 2 AC_SUBST(FREETYPELIBS,"") AC_SUBST(FREETYPEINCL,"") This patch breaks builds on RH9 and appears to be responsible for the build breakage on http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php
Re: Can't install mdac at all now
On Tuesday 13 December 2005 08:39, Dan Kegel wrote: > Bug 3636 is worse now. > http://bugs.winehq.org/show_bug.cgi?id=3636 > A few weeks ago, after mdac installer finished, > I could go and unpack the installed cabs by hand. > Now the installer aborts before it even copies the cabs. > Bleah. > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv Hi Dan, my patch haven't been commited so it doesn't work Markus is working on a better implementation Regards, Raphael pgpM3bmrkByej.pgp Description: PGP signature
Re: Wine: DirectDraw over Direct3D
On Tuesday 13 December 2005 09:28, Stefan Dösinger wrote: > Am Dienstag, 13. Dezember 2005 04:25 schrieb Aric Cyr: > > What is slow with ATI cards? It seems that you should only need basic 3D > > acceleration to do what you propose. Is fglrx missing something that > > would be required for 2D rendering? > > Texture upload is very slow. glReadPixels, glWritePixels and friends take > ages. That means that blt, Lock, and Unlock is really slow. > There is some hope at least: Xine and Mplayer can play videos over OpenGL > really fast, maybe we can find out how they do it. for glReadPixels, glWritePixels you can use the frame buffer object extension (or/with pbuffers) :) Keep your Good work > Stefan Regards, Raphael pgpkar9FrUeHA.pgp Description: PGP signature
Re: Problems generating c++ project since wine 0.9.3
Le dim 11/12/2005 à 19:43, Sergio a écrit :
> Hi all,
>
> I've been having problems trying to compile one c++ project since latest
> wine version (0.9.3). This project compiled and worked fine with previous
> versions.
>
> The error messages look like:
> /usr/include/wine/windows/unknwn.h:26: error: expected unqualified-id before
> ‘{’ token
> ...
> /usr/include/wine/windows/objidl.h:66: error: expected unqualified-id before
> ‘:’ token
> ...
> /usr/include/wine/windows/oaidl.h:553: error: expected unqualified-id before
> ‘:’ token
> ...
> /usr/include/wine/windows/propidl.h:287: error: expected unqualified-id
> before ‘:’ token
> ...
> /usr/include/wine/windows/oleidl.h:46: error: expected unqualified-id before
> ‘:’ token
> ...
>
> Is there something that I am misisng when generating this project? Or is
> this a known issue?
Known problem (caused then fixed by me).
The fix was committed after 0.9.3, and is the patch available from
http://source.winehq.org/git/?p=wine.git;a=commitdiff_plain;h=fe987b303581740cb96231a9abc42987473451db;hp=2b4377f5eb0a8b11484e4f053f9dbcf765c5a32d
Vincent
question regarding FindWindow
Hi,
While debugging Google Earth I see hangs in FindWindow...
Apparently the
if (GetWindowTextW( list[i], buffer, len + 1 ) && !strcmpiW( buffer, title
)) break;
call hangs on the server... But how is this possible?
+win,+server snippet:
trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE
0009: redraw_window( window=0x10020, flags=0005, region={} )
0009: redraw_window() = 0
trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE
0009: redraw_window( window=0x10020, flags=0005, region={} )
0009: redraw_window() = 0
0009: get_window_children( parent=0x10020, atom=, tid= )
0009: get_window_children() = 0 { count=3, children={0x10026,0x10024,0x10022} }
fixme:win:WIN_FindWindow before getwindowtext
fixme:win:WIN_FindWindow after getwindowtext
fixme:win:WIN_FindWindow before getwindowtext
0009: send_message( id=0010, type=1, flags=0, win=0x10024, msg=000d,
wparam=0023, lparam=55937970, x=0, y=0, time=10a4, info=00
00, timeout=0, callback=(nil), data={} )
0009: send_message() = 0
0009: get_msg_queue( )
0009: get_msg_queue() = 0 { handle=0x148 }
0009: set_queue_mask( wake_mask=8040, changed_mask=8040, skip_wait=1 )
0009: set_queue_mask() = 0 { wake_bits=, changed_bits= }
0009: select( flags=4, cookie=0x55c1f6f8, signal=(nil), timeout=0,
handles={0x148,0x80} )
0009: select() = PENDING
*hang*
What debug to enable and what to look at?
Ciao, Marcus
Re: PATCH: handle NULL XImage in GetBitmapBits
On Tue, Dec 13, 2005 at 07:13:00PM +0100, Willie Sippel wrote: > Am Dienstag, 13. Dezember 2005 11:42 schrieb Alexandre Julliard: > > Marcus Meissner <[EMAIL PROTECTED]> writes: > > > Changelog: > > > In GetBitmapBits() handle the correct bitmap information > > > when a DIB is used. > > > > I think for a DIB we want to copy the bits directly, like we already > > do in SetBitmapBits. Does this work for you? > > > All three patches (yours and the two by Marcus) fix bug 4034... ;-) Can also confirm that it fixes the issue. Ciao, Marcus
Re: Can Wine run "sv.net classic"? Not at the moment :-(
On 12/13/05, Sven Paschukat <[EMAIL PROTECTED]> wrote: > Dan Kegel schrieb: > > MDAC-2.7sp1 is plenty for (most?) VB6 apps, and we definitely > > want Wine to be able to run them sooner rather than later. > > So I think this deserves fixing, and there's no need to delay. > > You can install MDAC and the most other Windows components via the > Winetools: That's nice, but it's not an acceptable resolution to the problem. Wine should be able to install MDAC without Winetools. > Installing and running sv.net works fine here. That's nice to hear, but we need sv.net to run without "winetools". - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Can Wine run "sv.net classic"? Not at the moment :-(
Dan Kegel schrieb: MDAC-2.7sp1 is plenty for (most?) VB6 apps, and we definitely want Wine to be able to run them sooner rather than later. So I think this deserves fixing, and there's no need to delay. - Dan You can install MDAC and the most other Windows components via the Winetools: http://www.von-thadden.de/Joachim/WineTools/ Installing and running sv.net works fine here. Sven
Re: gethostbyname(my_name) and IL2-Sturmovik
Hi Pavel,
> And on the other side, try to query a DNS server for "localhost".
> Every DNS server should immediately return 127.0.0.1, it's RFC
> compliance requirement.
Just to be clear, we're not talking about gethostbyname("localhost").
We're talking about gethostbyname(the_name_of_my_machine). In Windows,
this returns your external address. See the following sample code which
demonstrates this:
http://tangentsoft.net/wskfaq/examples/ipaddr.html
On Linux, at least for me, I get only 127.0.0.1 for my hostname (juandell,
when I'm running on this laptop.) If I were to have this name registered
with DNS, and if I were to ask a DNS server for the address of it, I
wouldn't get 127.0.0.1, of course.
But we're not talking about DNS anyway. We're talking about winsock's
gethostbyname function. Wine's implementation isn't correct, since it
doesn't match Windows. I still think David's patch could use some work,
but let's not argue about whether its behaviour is correct: matching
Windows is what we're obliged to do.
--Juan
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
A DirectX ToDo
Hello Everyone, I've just posted a first draft of a DirectX ToDo on the Wiki : http://wiki.winehq.org/DirectX-ToDo?action=show Feedback, Comments, Suggestions are welcome. Cheers, Tom
cross-compile error
Hi, When doing Cross-Compiles I am seeing this error ../../include/wine/exception.h:142: error: parse error before "sigjmp_buf" ../../include/wine/exception.h:142: warning: no semicolon at end of struct or union ../../include/wine/exception.h:146: error: parse error before '}' token ../../include/wine/exception.h:146: warning: type defaults to `int' in declaration of `__WINE_FRAME' ../../include/wine/exception.h:146: warning: data definition has no type or storage class It seems the detection of sigjmp longjmp is busted for cross-compiling. I am using this patch locally but don't know how to properly fix it. Index: include/wine/exception.h === RCS file: /home/wine/wine/include/wine/exception.h,v retrieving revision 1.26 diff -u -r1.26 exception.h --- include/wine/exception.h1 Sep 2004 17:36:04 - 1.26 +++ include/wine/exception.h13 Dec 2005 18:03:58 - @@ -139,7 +139,7 @@ /* finally data */ __WINE_FINALLY finally_func; } u; -sigjmp_buf jmp; +jmp_buf jmp; /* hack to make GetExceptionCode() work in handler */ DWORD ExceptionCode; const struct __tagWINE_FRAME *ExceptionRecord; -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: gethostbyname(my_name) and IL2-Sturmovik
Hi! > > I think you are wrong. POSIX does not say that it's wrong to have the > computer name associated with 127.0.0.1 in /etc/hosts, and it doesn't say > that gethostbyname(my_name) should return a "real" IP. OK, but it also doesn't explicitly state that gethostbyname(my_name) may return 127.0.0.1, so it's just neutral :-). > If I remember > correctly, though, Microsoft, specifies that gethostbyname(my_name) > *should* return real IP. I don't know M$ standards, sorry, cannot comment on this. > > This subtle difference means that Wine must take extra care. Fetching a > real IP on a UNIX host is not trivial, but doable. > Yes, it is. BUT: man 5 hosts tells that: "The Berkeley Internet Name Domain (BIND) Server implements the Internet name server for UNIX systems. It aug ments or replaces the /etc/hosts file or host name lookup, and frees a host from relying on /etc/hosts being up to date and complete." So it seems to imply that the DNS info is currently an authoritative source for host name queries. Of course everybody knows it, I'm just making note of it to support my following question: Did you ever see in the real world that a DNS server would return 127.0.0.1 as a response to a regular host name query ? I think not. And on the other side, try to query a DNS server for "localhost". Every DNS server should immediately return 127.0.0.1, it's RFC compliance requirement. Isn't it logical to keep the host table coherent with DNS ? Or are you happy that in case your DNS server fails you get totally different results ? Of course I cannot argue more. It's just about the administrator's personal style and knowledge. I'm maintaining and administering Unix systems from 1985, long before Linux was born, and I would never allow such a thing in my host table. But if the current distro maintainers are of another view, I will not do anything against it. It's just about Open Source freedom: I will remove that patch from wine for me, and that's it :-). With regards, Pavel Troller
Re: Latest winetest (20051212) issue on WinXP
Paul Vriens wrote: Hi, I've just noticed that during the running of winetest.exe windows creates a nice desktop stating that 'Active Desktop' is stopped because an unexpected error occurred. Anyone? Paul. Send them a bugreport ;)
Re: WINED3D / D3D9: SetVertexShader & SetPixelShader should not change the shader's refcount
> The best thing to do is add an internal reference instead of referencing the
> parent. e.g.
> if (pShader != NULL) {
> IWineD3DVertexShader_AddRef(pShader);
> }
> if (oldShader != NULL) {
> IWineD3DVertexShader_Release(oldShader);
> }
Is that reference really needed?
Re: WINED3D / D3D9: SetVertexShader & SetPixelShader should not change the shader's refcount
--- "H. Verbeet" <[EMAIL PROTECTED]> wrote:
> SetVertexShader & SetPixelShader should not change the shader's
> refcount. Verified on win2k, DirectX 9.0c.
>
> Changelog:
> - Don't change the shader's refcount in SetVertexShader & SetPixelShader
> > 26c6ae144c6f7e40f7a7c6e3059851819ecf
> diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
> index c3a7f9c..a9c253f 100644
> --- a/dlls/wined3d/device.c
> +++ b/dlls/wined3d/device.c
> @@ -3761,7 +3761,6 @@ HRESULT WINAPI IWineD3DDeviceImpl_GetVer
>
> HRESULT WINAPI IWineD3DDeviceImpl_SetVertexShader(IWineD3DDevice *iface,
> IWineD3DVertexShader*
> pShader) {
> IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
> -IWineD3DVertexShader *oldShader = This->updateStateBlock->vertexShader;
>
> This->updateStateBlock->vertexShader = pShader;
> This->updateStateBlock->changed.vertexShader = TRUE;
> @@ -3772,20 +3771,7 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetVer
> return D3D_OK;
> }
>
> -if (pShader != NULL) {
> -IUnknown *newVertexShaderParent;
> -/* GetParent will add a ref, so leave it hanging until the vertex
> buffer is cleared */
> -TRACE("(%p) : setting pShader(%p)\n", This, pShader);
> -IWineD3DVertexShader_GetParent(pShader, &newVertexShaderParent);
> -} else {
> -TRACE("Clear down the shader\n");
> -}
> -if (oldShader != NULL) {
> -IUnknown *oldVertexShaderParent;
> -IWineD3DVertexShader_GetParent(oldShader, &oldVertexShaderParent);
> -IUnknown_Release(oldVertexShaderParent);
> -IUnknown_Release(oldVertexShaderParent);
> -}
> +TRACE("(%p) : setting pShader(%p)\n", This, pShader);
The best thing to do is add an internal reference e.g.
if (pShader != NULL) {
IWineD3DVertexShader_AddRef(pShader)
IWineD3DVertexShader_Release(oldShader)
___
NEW Yahoo! Cars - sell your car and browse thousands of new and used cars
online! http://uk.cars.yahoo.com/
Re: WINED3D / D3D9: SetVertexShader & SetPixelShader should not change the shader's refcount
--- "H. Verbeet" <[EMAIL PROTECTED]> wrote:
> SetVertexShader & SetPixelShader should not change the shader's
> refcount. Verified on win2k, DirectX 9.0c.
>
> Changelog:
> - Don't change the shader's refcount in SetVertexShader & SetPixelShader
> > 26c6ae144c6f7e40f7a7c6e3059851819ecf
> diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
> index c3a7f9c..a9c253f 100644
> --- a/dlls/wined3d/device.c
> +++ b/dlls/wined3d/device.c
> @@ -3761,7 +3761,6 @@ HRESULT WINAPI IWineD3DDeviceImpl_GetVer
>
> HRESULT WINAPI IWineD3DDeviceImpl_SetVertexShader(IWineD3DDevice *iface,
> IWineD3DVertexShader*
> pShader) {
> IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
> -IWineD3DVertexShader *oldShader = This->updateStateBlock->vertexShader;
>
> This->updateStateBlock->vertexShader = pShader;
> This->updateStateBlock->changed.vertexShader = TRUE;
> @@ -3772,20 +3771,7 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetVer
> return D3D_OK;
> }
>
> -if (pShader != NULL) {
> -IUnknown *newVertexShaderParent;
> -/* GetParent will add a ref, so leave it hanging until the vertex
> buffer is cleared */
> -TRACE("(%p) : setting pShader(%p)\n", This, pShader);
> -IWineD3DVertexShader_GetParent(pShader, &newVertexShaderParent);
> -} else {
> -TRACE("Clear down the shader\n");
> -}
> -if (oldShader != NULL) {
> -IUnknown *oldVertexShaderParent;
> -IWineD3DVertexShader_GetParent(oldShader, &oldVertexShaderParent);
> -IUnknown_Release(oldVertexShaderParent);
> -IUnknown_Release(oldVertexShaderParent);
> -}
> +TRACE("(%p) : setting pShader(%p)\n", This, pShader);
The best thing to do is add an internal reference instead of referencing the
parent. e.g.
if (pShader != NULL) {
IWineD3DVertexShader_AddRef(pShader);
}
if (oldShader != NULL) {
IWineD3DVertexShader_Release(oldShader);
}
___
NEW Yahoo! Cars - sell your car and browse thousands of new and used cars
online! http://uk.cars.yahoo.com/
Re: gethostbyname(my_name) and IL2-Sturmovik
@Peter
I'm attaching the patch I've written again, so everyone can find it. It tries
to find out the public IP by walkind the Interfaces available through the
Kernel.
@Pavel
I think that such a patch should be applied, Peter just said what I wanted to
hear :-)
Windows just acts different in this, and wine should act exactly the same. You
can't expect every Linux-user to specially hand-write his /etc/hosts so that
his windows-programs/games work. :)
greetings
Am Dienstag, 13. Dezember 2005 16:57 schrieb Peter Åstrand:
> On Tue, 13 Dec 2005, Pavel Troller wrote:
> >> 127.0.0.1 localhost.localdomain localhost Zwirch
> >
> > Yes, I know that *MANY* well-known distros are wrong with /etc/hosts and
> > similar files..
> >
> > I think that it is NOT GOOD to patch wine to fix this case; it behaves
> > absolutely correctly and all the problem should be solved by correctly
> > configuring your Linux networking. Please see any good document about
> > naming principles of network interfaces.
>
> I haven't followed the whole thread, so sorry if I've missed something
> obvious, but:
>
> I think you are wrong. POSIX does not say that it's wrong to have the
> computer name associated with 127.0.0.1 in /etc/hosts, and it doesn't say
> that gethostbyname(my_name) should return a "real" IP. If I remember
> correctly, though, Microsoft, specifies that gethostbyname(my_name)
> *should* return real IP.
>
> This subtle difference means that Wine must take extra care. Fetching a
> real IP on a UNIX host is not trivial, but doable.
>
> Instead of just fetching the IP by looking up the hostname, I suggest
> using the approach below instead. It will fail if there is no route to
> 192.168.1.1 (typically this means that you don't have a default gateway).
> When this happens, you can resolv the hostname as a fallback.
>
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
> int s, c, got_sockname = 0;
> struct sockaddr_in serv_addr;
> struct sockaddr_in my_addr;
> char *my_ip;
>
> serv_addr.sin_family = AF_INET;
> serv_addr.sin_port = htons(1);
> /* Even better: Use the server you will connect to */
> inet_aton("192.168.1.1", &serv_addr.sin_addr);
>
> s = socket (PF_INET, SOCK_DGRAM, 0);
> if (s < 0) {
> perror("socket");
> exit(EXIT_FAILURE);
> }
>
> /* connect fails if if server is unreachable, for example */
> if ((c = connect(s, (struct sockaddr*) &serv_addr, sizeof(serv_addr)))
> >= 0) { socklen_t my_addrlen;
> my_addrlen = sizeof(my_addr);
> if (getsockname(s, (struct sockaddr*)&my_addr, &my_addrlen) >= 0)
> { got_sockname = 1;
> }
> }
>
> if (!got_sockname)
> /* Use 127.0.0.1 as a fallback. Even better: Resolv the
> hostname. */
> inet_aton("127.0.0.1", &my_addr.sin_addr);
>
> my_ip = inet_ntoa(my_addr.sin_addr);
> printf("%s\n", my_ip);
>
> return 0;
> }
>
> Regards,
Index: dlls/winsock/socket.c
===
RCS file: /home/wine/wine/dlls/winsock/socket.c,v
retrieving revision 1.203
diff -b -B -c -r1.203 socket.c
*** dlls/winsock/socket.c 12 Dec 2005 12:49:05 - 1.203
--- dlls/winsock/socket.c 13 Dec 2005 12:26:18 -
***
*** 2927,2932
--- 2927,2991
return retval;
}
+
+ /***
+ * getpublicIP (Internal)
+ *
+ * Tries to guess the public IP-Adress by enumerating the available Interfaces
+ * target needs to be a buffer with the maximum size given in "size"
+ */
+
+
+ BOOL getpublicIP(char* target,int size)
+ {
+ char buff[1024];
+ char buffer[1024];
+ struct ifconf ifc;
+ struct ifreq *ifr;
+ int skfd;
+ int i;
+
+ skfd = socket(AF_INET, SOCK_DGRAM, 0);
+ if (skfd < 0)
+ {
+ WARN("A socket could not be created");
+ return FALSE;
+ }
+
+ ifc.ifc_len = sizeof(buff);
+ ifc.ifc_buf = buff;
+ if (ioctl(skfd, SIOCGIFCONF, &ifc) < 0)
+ {
+ WARN("ioctl(SIOCGIFCONF) failed");
+ close(skfd);
+ return FALSE;
+ }
+
+ close(skfd);
+
+ ifr = ifc.ifc_req;
+
+ for (i = 0; i < ifc.ifc_len / sizeof(struct ifreq); i++)
+ {
+ struct sockaddr_in* addr=(struct sockaddr_in*)&ifr[i].ifr_addr;
+ unsigned char* ip = ((unsigned char*)&addr->sin_addr);
+
+ if(strcmp(ifr[i].ifr_name,"lo")==0)continue; /*Exclude loopback-device by Name "lo"*/
+
+ if(ip[0]==127&&ip[1]==0&&ip[2]==0&&ip[3]==0)continue; /*Exclude 127.0.0.1*/
+
+ sprintf(buffer,"%i.%i.%i.%i", (int)ip[0],(int)ip[1],(int)ip[2],(int)ip[3]);
+
+ if(size>strlen(buffer))strcpy(target,buffer);
+
+ return TRUE;
+ }
+
+ return FALSE;
+ }
+
+
+
/***
*
Re: Can Wine run "sv.net classic"? Not at the moment :-(
On 12/13/05, Marcus Meissner <[EMAIL PROTECTED]> wrote: > MDAC also requires WGA, so we might need to reimplement it anyway first. MDAC-2.7sp1 is plenty for (most?) VB6 apps, and we definitely want Wine to be able to run them sooner rather than later. So I think this deserves fixing, and there's no need to delay. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Latest winetest (20051212) issue on WinXP
Hi, I've just noticed that during the running of winetest.exe windows creates a nice desktop stating that 'Active Desktop' is stopped because an unexpected error occurred. Anyone? Paul.
Re: PATCH: handle NULL XImage in GetBitmapBits
Am Dienstag, 13. Dezember 2005 11:42 schrieb Alexandre Julliard:
> Marcus Meissner <[EMAIL PROTECTED]> writes:
> > Changelog:
> > In GetBitmapBits() handle the correct bitmap information
> > when a DIB is used.
>
> I think for a DIB we want to copy the bits directly, like we already
> do in SetBitmapBits. Does this work for you?
>
All three patches (yours and the two by Marcus) fix bug 4034... ;-)
Ciao,
Willie
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
<[EMAIL PROTECTED]>
Re: gethostbyname(my_name) and IL2-Sturmovik
On Tue, 13 Dec 2005, Pavel Troller wrote:
127.0.0.1 localhost.localdomain localhost Zwirch
Yes, I know that *MANY* well-known distros are wrong with /etc/hosts and
similar files..
I think that it is NOT GOOD to patch wine to fix this case; it behaves
absolutely correctly and all the problem should be solved by correctly
configuring your Linux networking. Please see any good document about
naming principles of network interfaces.
I haven't followed the whole thread, so sorry if I've missed something
obvious, but:
I think you are wrong. POSIX does not say that it's wrong to have the
computer name associated with 127.0.0.1 in /etc/hosts, and it doesn't say
that gethostbyname(my_name) should return a "real" IP. If I remember
correctly, though, Microsoft, specifies that gethostbyname(my_name)
*should* return real IP.
This subtle difference means that Wine must take extra care. Fetching a
real IP on a UNIX host is not trivial, but doable.
Instead of just fetching the IP by looking up the hostname, I suggest
using the approach below instead. It will fail if there is no route to
192.168.1.1 (typically this means that you don't have a default gateway).
When this happens, you can resolv the hostname as a fallback.
#include
#include
#include
#include
#include
int main()
{
int s, c, got_sockname = 0;
struct sockaddr_in serv_addr;
struct sockaddr_in my_addr;
char *my_ip;
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(1);
/* Even better: Use the server you will connect to */
inet_aton("192.168.1.1", &serv_addr.sin_addr);
s = socket (PF_INET, SOCK_DGRAM, 0);
if (s < 0) {
perror("socket");
exit(EXIT_FAILURE);
}
/* connect fails if if server is unreachable, for example */
if ((c = connect(s, (struct sockaddr*) &serv_addr, sizeof(serv_addr))) >=
0) {
socklen_t my_addrlen;
my_addrlen = sizeof(my_addr);
if (getsockname(s, (struct sockaddr*)&my_addr, &my_addrlen) >= 0) {
got_sockname = 1;
}
}
if (!got_sockname)
/* Use 127.0.0.1 as a fallback. Even better: Resolv the
hostname. */
inet_aton("127.0.0.1", &my_addr.sin_addr);
my_ip = inet_ntoa(my_addr.sin_addr);
printf("%s\n", my_ip);
return 0;
}
Regards,
--
Peter Åstrand Chief Developer
Cendio www.thinlinc.com
Teknikringen 3 www.cendio.se
583 30 LinköpingPhone: +46-13-21 46 00
Re: gethostbyname(my_name) and IL2-Sturmovik
> On 12/13/05, David Nolden <[EMAIL PROTECTED]> wrote: > > @Pavel Troller > > I've checkt the /etc/hosts now. You were right, it says > > > > 127.0.0.1 localhost.localdomain localhost Zwirch > > > > (With Zwirch the Name of this Computer) > > > > But I can't just statically rewrite it, because I use DHCP. Also this is a > > fresh Ubuntu-Install, so I'm surely not the only > > Wine-User with such an /etc/hosts.. > > > > This link may be of interest: > http://lists.debian.org/debian-devel/2005/10/msg00387.html > > Tom > Hi! Yes, it uncovers even more problems with the /etc/hosts file on many distributions (hey, I'm so happy that I'm maintaining my own private distro, independently of all the "big players" on the market :-) ). However, your link talks mainly about localhost.localdomain. I am even more strict and I'm saying that the host name also should not be there. And because I know that the host name should be assigned to EXACTLY ONE network interface, it is a reason that in my distro, when there are no public if's active, a dummy0 comes up and the host name is assigned to it. This if holds an address DIFFERENT from localhost (192.168.0.1 is used as a preconfigured default on a fresh install). Once more, please don't patch wine, it's evidently not its problem at all! With regards, Pavel Troller
Re: gethostbyname(my_name) and IL2-Sturmovik
On 12/13/05, David Nolden <[EMAIL PROTECTED]> wrote: > @Pavel Troller > I've checkt the /etc/hosts now. You were right, it says > > 127.0.0.1 localhost.localdomain localhost Zwirch > > (With Zwirch the Name of this Computer) > > But I can't just statically rewrite it, because I use DHCP. Also this is a > fresh Ubuntu-Install, so I'm surely not the only > Wine-User with such an /etc/hosts.. > This link may be of interest: http://lists.debian.org/debian-devel/2005/10/msg00387.html Tom
Re: gethostbyname(my_name) and IL2-Sturmovik
> @Pavel Troller > I've checkt the /etc/hosts now. You were right, it says > > 127.0.0.1 localhost.localdomain localhost Zwirch > > (With Zwirch the Name of this Computer) > > But I can't just statically rewrite it, because I use DHCP. Also this is a > fresh Ubuntu-Install, so I'm surely not the only > Wine-User with such an /etc/hosts.. > Hi ! Yes, I know that *MANY* well-known distros are wrong with /etc/hosts and similar files.. The trick is that specifying your hostname for localhost interface improves Linux functionality in the case that there isn't other network interface active. Otherwise, a plenty of services would not work locally. However, when a real network interface comes up, it should be changed and moved to the line with a real IP address, which is not so obvious in the real world... I think that it is NOT GOOD to patch wine to fix this case; it behaves absolutely correctly and all the problem should be solved by correctly configuring your Linux networking. Please see any good document about naming principles of network interfaces. With regards, Pavel Troller
Re: gethostbyname(my_name) and IL2-Sturmovik
@Pavel Troller
I've checkt the /etc/hosts now. You were right, it says
127.0.0.1 localhost.localdomain localhost Zwirch
(With Zwirch the Name of this Computer)
But I can't just statically rewrite it, because I use DHCP. Also this is a
fresh Ubuntu-Install, so I'm surely not the only
Wine-User with such an /etc/hosts..
@Juan
You're right, I've checked the patch and it indeed was ugly! But when I sent
it I hadn't done the check under Windows, so I didn't know if the patch was
generally useful, so I mainly ment it as a piece for discussion.(Also I
didn't notice how ugly it really was ;)
I've cleaned it up a bit, closed the leak, and did a few other small tweaks so
now the patch itself might be acceptable.
greetings, David
Am Dienstag, 13. Dezember 2005 07:04 schrieb Pavel Troller:
> > Ok, I've just checked doing the same thing under windows.
> >
> > The test(ripdaveno is the name of the Computer I tested on):
> >
> > {
> > ...
> > hostent* h = gethostbyname("ripdaveno");
> > char* str = inet_ntoa(*((in_addr*)h->h_addr_list[0]));
> > ...
> > }
> >
> > The string in str was "192.168.2.75" which is my Network IP-Adress. With
> > wine(under Linux), as far as I've tested it, exactly the same code always
> > generates "127.0.0.1".
> >
> > Since Wine tries to simulate Windows as exactly as possible, this is
> > wrong. So, in my opinion this Patch is necessary. :-)
>
> Hi!
> It's strange but there is no patch in this mail I can look at...
> However, even more strange is that wine returns localhost address to
> you... Why ? I just tested Your testing code (just slightly modified to get
> it to compile) on both plain linux as well as in wine and in both cases it
> returns my real public IP. Isn't your Linux networking setup (/etc/hosts
> table) a bit wrong ? My one contains (arcus is my machine name)
>
> 127.0.0.1 localhost
> 195.39.17.7 arcus.sinus.cz arcus
>
> I have already seen broken setups containing things like
>
> 127.0.0.1 localhost arcus
>
> which is of course wrong.
>
> Regards, Pavel Troller
Index: dlls/winsock/socket.c
===
RCS file: /home/wine/wine/dlls/winsock/socket.c,v
retrieving revision 1.203
diff -b -B -c -r1.203 socket.c
*** dlls/winsock/socket.c 12 Dec 2005 12:49:05 - 1.203
--- dlls/winsock/socket.c 13 Dec 2005 12:26:18 -
***
*** 2927,2932
--- 2927,2991
return retval;
}
+
+ /***
+ * getpublicIP (Internal)
+ *
+ * Tries to guess the public IP-Adress by enumerating the available Interfaces
+ * target needs to be a buffer with the maximum size given in "size"
+ */
+
+
+ BOOL getpublicIP(char* target,int size)
+ {
+ char buff[1024];
+ char buffer[1024];
+ struct ifconf ifc;
+ struct ifreq *ifr;
+ int skfd;
+ int i;
+
+ skfd = socket(AF_INET, SOCK_DGRAM, 0);
+ if (skfd < 0)
+ {
+ WARN("A socket could not be created");
+ return FALSE;
+ }
+
+ ifc.ifc_len = sizeof(buff);
+ ifc.ifc_buf = buff;
+ if (ioctl(skfd, SIOCGIFCONF, &ifc) < 0)
+ {
+ WARN("ioctl(SIOCGIFCONF) failed");
+ close(skfd);
+ return FALSE;
+ }
+
+ close(skfd);
+
+ ifr = ifc.ifc_req;
+
+ for (i = 0; i < ifc.ifc_len / sizeof(struct ifreq); i++)
+ {
+ struct sockaddr_in* addr=(struct sockaddr_in*)&ifr[i].ifr_addr;
+ unsigned char* ip = ((unsigned char*)&addr->sin_addr);
+
+ if(strcmp(ifr[i].ifr_name,"lo")==0)continue; /*Exclude loopback-device by Name "lo"*/
+
+ if(ip[0]==127&&ip[1]==0&&ip[2]==0&&ip[3]==0)continue; /*Exclude 127.0.0.1*/
+
+ sprintf(buffer,"%i.%i.%i.%i", (int)ip[0],(int)ip[1],(int)ip[2],(int)ip[3]);
+
+ if(size>strlen(buffer))strcpy(target,buffer);
+
+ return TRUE;
+ }
+
+ return FALSE;
+ }
+
+
+
/***
* gethostbyname (WS2_32.52)
*/
***
*** 2930,2937
--- 2989,3000
/***
* gethostbyname (WS2_32.52)
*/
+
struct WS_hostent* WINAPI WS_gethostbyname(const char* name)
{
+ char myname[1000];
+ struct in_addr newaddr;
+
struct WS_hostent *retval = NULL;
struct hostent* host;
#ifdef HAVE_LINUX_GETHOSTBYNAME_R_6
***
*** 2941,2946
--- 3004,3012
int locerr = ENOBUFS;
#endif
char buf[100];
+
+ gethostname(myname,(size_t)1000);
+
if( !name) {
name = buf;
if( gethostname( buf, 100) == -1) {
***
*** 2961,2969
#else
EnterCriticalSection( &csWSgetXXXbyYYY );
host = gethostbyname(name);
if (!host) SetLastError((h_errno < 0) ? wsaErrno() : wsaHerrno(h_errno));
#endif
! if
Re: BUG (3920) + sync between DIBs and X Server optimisation. (please help)
Yeah, i also belive putting the modifying rect in Coerce is better, when i
first made the changes i just wanted to modify as little as possible and add
things without modifying the already existing code too much, keeping it
clean. I also belive i am doing something wrong:
I noticed that in X11DRV_DIB_CopyDIBSection() function created to optimise
bitblt(), the sync is done this way:
X11DRV_DIB_DoCopyDIBSection(physBitmap, FALSE, colorMap, nColorMap,
physDevDst->drawable, xSrc, ySrc,
physDevDst->org.x + xDest, physDevDst->org.y
+ yDest,
width, height);
They take in consideration the (org.x,org.y) in the physical device! I don't
understand too well what a physical devise exactly is, and i was wondering
if i am not mistaking when i sync like this in
X11DRV_DIB_DoUpdateDIBSection():
X11DRV_DIB_DoCopyDIBSection(physBitmap, toDIB,
physBitmap->colorMap, physBitmap->nColorMap,
physBitmap->pixmap, x, y, x, y,
width, height);
and not taking in consideration the origins of the device?
Iulian
From: Robert Shearman <[EMAIL PROTECTED]>
To: Marinescu-Ghetau Iulian <[EMAIL PROTECTED]>
CC: wine-devel@winehq.org
Subject: Re: BUG (3920) + sync between DIBs and X Server optimisation.
(please help)
Date: Mon, 12 Dec 2005 11:07:20 -0600
Marinescu-Ghetau Iulian wrote:
I came to the conclusion that the slowness in "Heroes IV" it has to do
with
sync'ing lage bitmaps between application DIBs and X Server(see the log:
http://bugs.winehq.org/attachment.cgi?id=1470&action=view ).
Also, a complete description of the bug is here:
http://bugs.winehq.org/show_bug.cgi?id=3902
So i had this ideea that every GDI function could memorise the rectangle
that is modifying, so each time a sync between DIB and X Server is needed,
only a small part from the bitmap will get copied! I also made some
changes to dib.c, bitblt.c and x11drv.h in "wine-0.9.2\dlls\x11drv" folder
to implement my ideea, keeping backwards compatibility (if a DIB function
doesn't set a valid rectangle for the bitmap that its modifying, the
default values are taken - which is the entire bitmap)
- and finally, a GDI function calls it like this (for example bitblt):
X11DRV_SetBoundRect(physDevDst->bitmap,xDst,yDst,width,height);
X11DRV_CoerceDIBSection( physDevDst, DIB_Status_GdiMod, FALSE );
if (physDevDst != physDevSrc)
{
X11DRV_SetBoundRect(physDevSrc->bitmap,xSrc,ySrc,width,height);
X11DRV_CoerceDIBSection( physDevSrc, DIB_Status_GdiMod, FALSE );
}
I think it would be better to make X11DRV_CoerceDIBSection take the
parameters for a bounding rect, otherwise it is possible to forget a call
to SetBoundRect and cause the DIB to not be updated.
--
Rob Shearman
Re: http headers reworking
How odd, I just applied only the patch i sent and rebuilt my tree and all the tests pass just fine for me. I will try with a totally clean tree but that will take a while to build. I will ask you offline maybe for wininet logs to see where it is failing. -aric Alexandre Julliard wrote: Aric Stewart <[EMAIL PROTECTED]> writes: Redo how headers are handled. eliminating the concept of Standard Headers and allow all headers to be added multiple times. Allow querying of headers with an index to get the multiple headers. Respect response vs request headers in HttpQueryInfo. Add a number of tests to extensively test header adding and replacing. All fixes for Picasa. The tests don't work here: http.c:1152: Test failed: Index was not incremented http.c:1156: Test failed: Second Index Should Not Exist http.c:1167: Test failed: Index was not incremented http.c:1168: Test failed: incorrect string was returned(test2) http.c:1173: Test failed: Index was not incremented http.c:1177: Test failed: Third Header Should Not Exist http.c:1187: Test failed: Index was not incremented http.c:1188: Test failed: incorrect string was returned(test3) http.c:1193: Test failed: Index was not incremented http.c:1197: Test failed: Third Header Should Not Exist http.c:1207: Test failed: Index was not incremented http.c:1208: Test failed: incorrect string was returned(test3) http.c:1213: Test failed: Index was not incremented http.c:1217: Test failed: Third Header Should Not Exist http.c:1227: Test failed: Index was not incremented http.c:1228: Test failed: incorrect string was returned(test4) http.c:1232: Test failed: Index was not incremented http.c:1233: Test failed: incorrect string was returned(test4) http.c:1236: Test failed: Third Header Should Not Exist http.c:1244: Test failed: Index was not incremented http.c:1245: Test failed: incorrect string was returned(test5) http.c:1249: Test failed: Index was not incremented http.c:1250: Test failed: incorrect string was returned(test5) http.c:1253: Test failed: Third Header Should Not Exist http.c:1261: Test failed: Index was not incremented http.c:1262: Test failed: incorrect string was returned(test6) http.c:1266: Test failed: Index was not incremented http.c:1267: Test failed: incorrect string was returned(test6) http.c:1270: Test failed: Third Header Should Not Exist http.c:1278: Test failed: Index was not incremented http.c:1279: Test failed: incorrect string was returned(test7) http.c:1283: Test failed: Index was not incremented http.c:1287: Test failed: Third Header Should Not Exist
Re: http headers reworking
Aric Stewart <[EMAIL PROTECTED]> writes: > Redo how headers are handled. > eliminating the concept of Standard Headers and allow all headers to be > added multiple times. > Allow querying of headers with an index to get the multiple headers. > Respect response vs request headers in HttpQueryInfo. > Add a number of tests to extensively test header adding and replacing. > All fixes for Picasa. The tests don't work here: http.c:1152: Test failed: Index was not incremented http.c:1156: Test failed: Second Index Should Not Exist http.c:1167: Test failed: Index was not incremented http.c:1168: Test failed: incorrect string was returned(test2) http.c:1173: Test failed: Index was not incremented http.c:1177: Test failed: Third Header Should Not Exist http.c:1187: Test failed: Index was not incremented http.c:1188: Test failed: incorrect string was returned(test3) http.c:1193: Test failed: Index was not incremented http.c:1197: Test failed: Third Header Should Not Exist http.c:1207: Test failed: Index was not incremented http.c:1208: Test failed: incorrect string was returned(test3) http.c:1213: Test failed: Index was not incremented http.c:1217: Test failed: Third Header Should Not Exist http.c:1227: Test failed: Index was not incremented http.c:1228: Test failed: incorrect string was returned(test4) http.c:1232: Test failed: Index was not incremented http.c:1233: Test failed: incorrect string was returned(test4) http.c:1236: Test failed: Third Header Should Not Exist http.c:1244: Test failed: Index was not incremented http.c:1245: Test failed: incorrect string was returned(test5) http.c:1249: Test failed: Index was not incremented http.c:1250: Test failed: incorrect string was returned(test5) http.c:1253: Test failed: Third Header Should Not Exist http.c:1261: Test failed: Index was not incremented http.c:1262: Test failed: incorrect string was returned(test6) http.c:1266: Test failed: Index was not incremented http.c:1267: Test failed: incorrect string was returned(test6) http.c:1270: Test failed: Third Header Should Not Exist http.c:1278: Test failed: Index was not incremented http.c:1279: Test failed: incorrect string was returned(test7) http.c:1283: Test failed: Index was not incremented http.c:1287: Test failed: Third Header Should Not Exist -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH: handle NULL XImage in GetBitmapBits
Marcus Meissner <[EMAIL PROTECTED]> writes:
> Changelog:
> In GetBitmapBits() handle the correct bitmap information
> when a DIB is used.
I think for a DIB we want to copy the bits directly, like we already
do in SetBitmapBits. Does this work for you?
diff --git a/dlls/gdi/bitmap.c b/dlls/gdi/bitmap.c
index a0c6b25..5c2b6c3 100644
--- a/dlls/gdi/bitmap.c
+++ b/dlls/gdi/bitmap.c
@@ -307,6 +307,30 @@ LONG WINAPI GetBitmapBits(
if (!bmp) return 0;
+if (bmp->dib) /* simply copy the bits from the DIB */
+{
+DIBSECTION *dib = bmp->dib;
+const char *src = dib->dsBm.bmBits;
+DWORD max = dib->dsBm.bmWidthBytes * dib->dsBm.bmHeight;
+if (count > max) count = max;
+ret = count;
+if (!bits) goto done;
+
+if (bmp->dib->dsBmih.biHeight >= 0) /* not top-down, need to flip
contents vertically */
+{
+src += dib->dsBm.bmWidthBytes * dib->dsBm.bmHeight;
+while (count > 0)
+{
+src -= dib->dsBm.bmWidthBytes;
+memcpy( bits, src, min( count, dib->dsBm.bmWidthBytes ) );
+bits = (char *)bits + dib->dsBm.bmWidthBytes;
+count -= dib->dsBm.bmWidthBytes;
+}
+}
+else memcpy( bits, src, count );
+goto done;
+}
+
/* If the bits vector is null, the function should return the read size */
if(bits == NULL)
{
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Wine: DirectDraw over Direct3D
> > What is slow with ATI cards? Â It seems that you should only need basic > 3D > > acceleration to do what you propose. Â Is fglrx missing something that > would > > be required for 2D rendering? > Texture upload is very slow. glReadPixels, glWritePixels and friends take > ages. That means that blt, Lock, and Unlock is really slow. > There is some hope at least: Xine and Mplayer can play videos over OpenGL > really fast, maybe we can find out how they do it. > > Stefan Indeed glReadPixels and glWritePixels might be slow using the Ati drivers but those calls weren't used for the texture uploading. For that purpose just glTexImage2D / glTexSubImage2D calls were used. If texture uploading was slow on the Ati drivers people would be unable to play games ;) Roderick -- GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro* Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl
freetype and wine
Hi: I get everytime i want to display a report on my access97 app this error: fixme:font:load_VDMX Failed to retreive vTable Then the fonts of the report are displayed separated and bigger than on windows. Somebody told me to install freetype new version. I have installed the last version of freetype2 (9.8.3) and it keeps on the same. Do i have to do something for telling wine to use the new version of freetype? Im using windows98 emulation in wine for this app. Has it something to do that i have moved all windows xp ttf files to fonts fake directory?? Thanks all!
Re: Wine: DirectDraw over Direct3D
Am Dienstag, 13. Dezember 2005 04:25 schrieb Aric Cyr: > What is slow with ATI cards? It seems that you should only need basic 3D > acceleration to do what you propose. Is fglrx missing something that would > be required for 2D rendering? Texture upload is very slow. glReadPixels, glWritePixels and friends take ages. That means that blt, Lock, and Unlock is really slow. There is some hope at least: Xine and Mplayer can play videos over OpenGL really fast, maybe we can find out how they do it. Stefan
Re: Can Wine run "sv.net classic"? Not at the moment :-(
On Mon, Dec 12, 2005 at 11:51:44PM -0800, Dan Kegel wrote: > http://www.heise.de/newsticker/meldung/67265 describes > what looks like a nice opportunity for wine to prove > itself. German employers are required to send insurance > information online. There are two allowed methods: > either a web page (which apparantly sucks), or a windows > app called sv.net classic, available as a free download at > http://www.itsg.de/svnet/ > > I tried installing it, but I didn't get past square one because > the mdac installer is more busted than it used to be, at > least on my machine. MDAC also requires WGA, so we might need to reimplement it anyway first. Ciao, Marcus
