ChangeSet ID: 23423
CVSROOT: /opt/cvs-commit
Module name: lostwages
Changes by: jnewman(a)winehq.org 2006/03/06 12:52:10
Modified files:
wwn : wn20060305_307.xml
Log message:
Francois Gouget <fgouget(a)free.fr>
Assorted spelling fixes
Patch: http://cvs.winehq.org/patch.py?id=23423
Old revision New revision Changes Path
1.1 1.2 +9 -9 lostwages/wwn/wn20060305_307.xml
Index: lostwages/wwn/wn20060305_307.xml
diff -u -p lostwages/wwn/wn20060305_307.xml:1.1 lostwages/wwn/wn20060305_307.xml:1.2
--- lostwages/wwn/wn20060305_307.xml:1.1 6 Mar 2006 18:52:10 -0000
+++ lostwages/wwn/wn20060305_307.xml 6 Mar 2006 18:52:10 -0000
@@ -144,7 +144,7 @@ update a few weeks ago on that list wher
</p><p>
Here's a list of (known) problems faced:
<ol>
- <li> missing support for some ioctl's (HDMA, serial). Added to Valgrind (now
+ <li> missing support for some ioctls (HDMA, serial). Added to Valgrind (now
in branch, at least of x86)</li>
<li> missing support for tkill syscall. Added to Valgrind (now in branch), Wine
@@ -248,7 +248,7 @@ This week he announced the initial versi
I've brought my DirectDraw over WineD3D patch in a form where I want to show
it to the public for review. I've uploaded it to
<a href="http://stud4.tuwien.ac.at/~e0526822/">
-http://stud4.tuwien.ac.at/~e0526822/</a>, where it is described in detail(below
+http://stud4.tuwien.ac.at/~e0526822/</a>, where it is described in detail (below
the game list).
</p><p>
If there are no fundamental objections against it, I'll start sending patches
@@ -260,7 +260,7 @@ for WineD3D. The changes I'll make in sm
</p><p>
When WineD3D is ready, I'll send a patch for dlls/ddraw to wine-devel and
wine-user for a broad regression testing, and when the regressions are out,
-the ddraw can be replaced(From my POV, AJ has the last word of course ;) )
+the ddraw can be replaced (From my POV, AJ has the last word of course ;) )
</p></quote>
<p>DirectDraw sitting on top of WineD3D, the WineD3D layer can best decide
@@ -277,20 +277,20 @@ Basically all rendering and screen setup
</p><p>
There are a few changes to WineD3D:
<ul>
- <li> Initialization is split up in an OpenGL-free part and a
+ <li> Initialization is split up in an OpenGL-free part and an
IWineD3DDevice::Init3D method which initializes the 3D functions. This split
-is not yet complete, so a opengl lib must be installed and some ddraw
+is not yet complete, so an opengl lib must be installed and some ddraw
games (nfs3) crash in opengl calls called during initialization. The
IWineD3DDevice::Relase code has been split up too. IWineD3DDevice has methods
to setup the screen without a Direct3D swapchain</li>
- <li> An secound surface implementation was added, IWineX11Surface, which
+ <li> An second surface implementation was added, IWineX11Surface, which
handles 2D only-operations with the old surface_dib code. It will be renamed
to WineGDISurface, and WineX11Surface will use Xrender, WineD3DSurface will
get the ability to do 2D rendering with OpenGL</li>
<li> DirectDraw rendering methods such as IWineD3DSurface::Blt,
IWineD3DSurface::BltFast and IWineD3DSurface::Flip have been added, along with
related calls.</li>
- <li> Some DirectDraw data types will be added to to
+ <li> Some DirectDraw data types will be added to
include/wine/wined3d_types.h, and d3d9 types which are used by the wined3d
header and don't exist in d3d.h will be added to wined3d_types too. At the
moment, those definitions reside in dlls/ddraw/d3d_compat.h.</li></ul></p>
@@ -318,7 +318,7 @@ extensions in Wine, or even use the Linu
<p>Stefan Dösinger gave an example of it:</p>
<quote who="Stefan Dosinger"><p>
I have done this with Kmail and others. You have to add a few registry keys in
-HKCL and HKLM. Basically, you can launch any Linux app from wine by it's full
+HKCL and HKLM. Basically, you can launch any Linux app from wine by its full
path and pass command line arguments. There's of course the problem of
converting Windows paths to Unix paths.
</p><p>
@@ -327,7 +327,7 @@ http://www.winehq.com/site/fun_projects<
described. For examples how to use Open Office, you have to google.
</p><p>
I don't think that executing a Linux Plugin in a Win32 browser is possible,
-but cossover allows you to do the reverse.
+but CrossOver allows you to do the reverse.
</p></quote>
</section>
Module: wine
Branch: refs/heads/master
Commit: 46ecb15c5ccab9ce4802d20879dfc92b9fff3c91
URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=46ecb15c5ccab9ce4802d20…
Author: Vitaliy Margolen <wine-patch(a)kievinfo.com>
Date: Sun Mar 5 13:07:44 2006 -0700
wined3d: Fix retrieval of driver adapter versions.
---
dlls/wined3d/directx.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 39c41bd..1749635 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -1015,8 +1015,11 @@ HRESULT WINAPI IWineD3DImpl_GetAdapterId
reuse the values once we have a context which is valid. Values from
a temporary context may differ from the final ones */
if (isGLInfoValid == FALSE) {
+ WineD3D_Context *fake_ctx = NULL;
+ if (glXGetCurrentContext() == NULL) fake_ctx = WineD3D_CreateFakeGLContext();
/* If we don't know the device settings, go query them now */
isGLInfoValid = IWineD3DImpl_FillGLCaps(&This->gl_info, IWineD3DImpl_GetAdapterDisplay(iface, Adapter));
+ if (fake_ctx != NULL) WineD3D_ReleaseFakeGLContext(fake_ctx);
}
/* If it worked, return the information requested */
Module: wine
Branch: refs/heads/master
Commit: e70617883b4e883d46dc68ce8d6dfde7c4d354e4
URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=e70617883b4e883d46dc68c…
Author: Eric Pouech <eric.pouech(a)wanadoo.fr>
Date: Sun Mar 5 21:48:07 2006 +0100
dbghelp: Implemented TI_GET_COUNT in SymGetTypeInfo for function.
---
dlls/dbghelp/type.c | 21 ++++++++++++++-------
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/dlls/dbghelp/type.c b/dlls/dbghelp/type.c
index 4a336c5..4177aaa 100644
--- a/dlls/dbghelp/type.c
+++ b/dlls/dbghelp/type.c
@@ -551,13 +551,20 @@ BOOL symt_get_info(const struct symt* ty
break;
case TI_GET_COUNT:
- /* it seems that FunctionType also react to GET_COUNT (same value as
- * GET_CHILDREN_COUNT ?, except for C++ methods, where it seems to
- * also include 'this' (GET_CHILDREN_COUNT+1)
- */
- if (type->tag != SymTagArrayType) return FALSE;
- X(DWORD) = ((const struct symt_array*)type)->end -
- ((const struct symt_array*)type)->start + 1;
+ switch (type->tag)
+ {
+ case SymTagArrayType:
+ X(DWORD) = ((const struct symt_array*)type)->end -
+ ((const struct symt_array*)type)->start + 1;
+ break;
+ case SymTagFunctionType:
+ /* this seems to be wrong for (future) C++ methods, where 'this' parameter
+ * should be included in this value (and not in GET_CHILDREN_COUNT)
+ */
+ X(DWORD) = vector_length(&((const struct symt_function_signature*)type)->vchildren);
+ break;
+ default: return FALSE;
+ }
break;
case TI_GET_DATAKIND: