lostwages/wwn wn20051211_301.xml wn20051223_30 ...
Jeremy Newman
jnewman at wine.codeweavers.com
Tue Jan 3 16:02:05 CST 2006
ChangeSet ID: 22074
CVSROOT: /opt/cvs-commit
Module name: lostwages
Changes by: jnewman at winehq.org 2006/01/03 16:02:04
Modified files:
wwn : wn20051211_301.xml wn20051223_302.xml
Log message:
Francois Gouget <fgouget at free.fr>
Assorted spelling fixes.
Patch: http://cvs.winehq.org/patch.py?id=22074
Old revision New revision Changes Path
1.3 1.4 +7 -7 lostwages/wwn/wn20051211_301.xml
1.2 1.3 +13 -13 lostwages/wwn/wn20051223_302.xml
Index: lostwages/wwn/wn20051211_301.xml
diff -u -p lostwages/wwn/wn20051211_301.xml:1.3 lostwages/wwn/wn20051211_301.xml:1.4
--- lostwages/wwn/wn20051211_301.xml:1.3 3 Jan 2006 22: 2: 4 -0000
+++ lostwages/wwn/wn20051211_301.xml 3 Jan 2006 22: 2: 4 -0000
@@ -137,7 +137,7 @@ handle 8bit paletted which is used by ga
support this by default. The second patch which I attached as well adds
support for this. On cards (at least all nvidia cards from geforce 1 to the
fx) that support the opengl paletted texture extension this extension is
-used. It makes StarCraft very fast atleast on my Athlon XP2000 system with a
+used. It makes StarCraft very fast at least on my Athlon XP2000 system with a
GeforceFX where the game was slow before. As not all cards support paletted
textures I emulated this using a simple fragment shader. (a 1D texture
containing the palette is used as a lookup table)
@@ -185,7 +185,7 @@ using Mesa, I could try that soon using
slower than the current code as Mesa uses Xlib too in the indirect case. In
general about all cards these days have some form of opengl support (intel,
via, ati, nvidia, ..) perhaps only the latest S3 GPUs and perhaps some SIS
-ones (thought some have drivers) lack support. Note that cards don't need
+ones (though some have drivers) lack support. Note that cards don't need
much functionality at all as OpenGL is only for the uploading of textures
and the rendering of them.
</p><p>
@@ -201,7 +201,7 @@ directly access the framebuffer of the v
render 2D images on the screen. Games like StarCraft, Total Annihilation,
C&C and lots of others use DirectDraw in this way. Second there's another
class of games like Age Of Empires2, Heroes of Might and Magic IV and others
-which mix ddraw with GDI. They for instance render a image using ddraw and
+which mix ddraw with GDI. They for instance render an image using ddraw and
then use GetDC/ReleaseDC to get a device context so that they can draw in
the surface. (directly into the video memory)
</p><p>
@@ -273,7 +273,7 @@ WineD3D in any case. Then WineD3D could
or OpenGL for 2D rendering. :)
</p><p>
Maybe we should have a close look at the details of such a thing. I do not
-really recommend a ad-hoc attempt, as d3d7->WineD3D was nearly too much.
+really recommend an ad-hoc attempt, as d3d7->WineD3D was nearly too much.
</p></quote>
<p>Lionel liked the idea:</p>
@@ -312,7 +312,7 @@ So what's the point of this mail? While
by wrapping D3D7 only and leave DirectDraw in ddraw.dll, it has a few ugly
drawbacks:
<ul>
-<li> Device initialization: In D3D7, the first step is to create a IDirectDraw
+<li> Device initialization: In D3D7, the first step is to create an IDirectDraw
Device, set up the device, create a surface and then create a Direct3D
Device. When creating the WineD3DDevice in the last step, I have to do some
ugly things to wrap the already existing Surface to a newly created
@@ -525,7 +525,7 @@ don't always provide *.so symlinks for 3
The script creates all missing links in one directory (/usr/local/lib is
the default). Not only was libcups found next time, but also the old
workaround with imake has become unneeded. The configure script runs
-out-of-box and finds X11 libraries.
+out-of-the-box and finds X11 libraries.
</p><p>
I'm posting the script here in hope that it will be useful for some Wine
users. I'm not sure it it merits inclusion in Wine, but I would not
@@ -538,7 +538,7 @@ Pavel replied with more details:</p>
<quote who="Pavel Roskin"><p>
They are provided for some basic libraries, such as zlib and ncurses.
-Other libraries, such as cups, as missing, but my script can remedy it,
+Other libraries, such as cups, are missing, but my script can remedy it,
because the only missing file is the symlink to *.so for the linker.
</p><p>
Unfortunately, openssl support cannot be fixed by the script
Index: lostwages/wwn/wn20051223_302.xml
diff -u -p lostwages/wwn/wn20051223_302.xml:1.2 lostwages/wwn/wn20051223_302.xml:1.3
--- lostwages/wwn/wn20051223_302.xml:1.2 3 Jan 2006 22: 2: 5 -0000
+++ lostwages/wwn/wn20051223_302.xml 3 Jan 2006 22: 2: 5 -0000
@@ -154,11 +154,11 @@ to be following. Tony wrote:</p>
<Rant>
Well that is a real sore spot with me. You know that I am a strong
supporter of wine but it really concerns me that we have gone beta and
-not addressed preventing regessions from getting into our releases in
+not addressed preventing regressions from getting into our releases in
any way. We currently have no freeze or notification of exactly when
the next release is going to go out. Sure we had the one big code
freeze just before 0.9 but then we went back to releasing without any
-notification. At his point even if our application maintainers test
+notification. At this point even if our application maintainers test
their app every day there is no way for them to prevent that
regression going into the next release.
</p><p>
@@ -192,17 +192,17 @@ progressing:</p>
<quote who="Tony Lambregts"><p>
Perhaps it's partly a matter of perception then.
</p><p>
-If I understand you 0.9 was a major release then, and 0.9.1 and
+If I understand you, 0.9 was a major release then, and 0.9.1 and
company are minor releases, with the next major release being 1.0. So
I anticipate that we will have a major freeze before 1.0 just like we
had before 0.9?
</p><p>
-Since I'm pretty sure we do not have the resources to do nightly's
+Since I'm pretty sure we do not have the resources to do nightlies
like they did for Mozilla, then once certainly every two weeks is
better than once a month.
</p><p>
If we could count on a release every two weeks that would be ideal.
-That way people like me who use CVS ( or GIT) could help prevent
+That way people like me who use CVS (or GIT) could help prevent
regressions even getting into the minor releases, which in turn would
encourage more people to use the minor releases. I would prefer to see
that releases were done on a Tuesday, myself, since I have more free
@@ -268,7 +268,7 @@ and report problems.</p>
>
<topic>Project Management</topic>
<p>We mentioned a few weeks ago (WWN
-<a href="http://www.winehq.com/?issue=299#Desktop%20Summit">#299</a>) there
+<a href="http://www.winehq.com/?issue=299#Desktop%20Summit">#299</a>) that there
was a desktop summit being sponsored by OSDL. Well, Jeremy White and Dan
Kegel both attended the event and Jeremy wrote the following over on
OSDL's <a href="http://lists.osdl.org/pipermail/desktop_architects/2005-December/000354.html">desktop_architects</a>
@@ -343,7 +343,7 @@ need the cash; Microsoft doesn't.
That's it; didn't have that much to say; but now
I feel better <grin>
</p><p>
-And the honest truth is that I didn't really need to
+And the honest truth is that I didn't really need to be
present in Portland; we didn't have any major gaps that
group could have addressed. While Wine certainly depends
on a range of other projects, we've actually found folks
@@ -402,14 +402,14 @@ team, notably Eric Frias and Juraj Herce
<a href="http://news.inq7.net/infotech/index.php?index=1&story_id=60585">Apparently</a>
SpecOpsLabs has released a product based on their Project David stuff. What
is that? Well, we don't really know. The last time it came up it was
-determined they had simply stolen CodeWeaver's CrossOver product. They
+determined they had simply stolen CodeWeavers CrossOver product. They
haven't bothered to engage in any dialog with the community, so it's unknown
what their intentions are. </p><p>
Tom Wickline pointed out the link above and Willie Sippel followed up by
-mentioning it was a part of TurboLinux FUJI. Tom ask if anyone knew where
+mentioning it was a part of TurboLinux FUJI. Tom asked if anyone knew where
the source code to the Wine changes were and Jeremy White reminded him:</p>
<quote who="Jeremy White"><p>
-In fact, the only person that can demand anything with regart to the LGPL is
+In fact, the only person that can demand anything with regard to the LGPL is
someone that is running their software. So if someone has bought
a copy of TurboLinux 11 in Japan, they have the right to demand
a copy of the source code to the Wine bits in Project David; presumably
@@ -444,7 +444,7 @@ their product:
<li> That was followed shortly thereafter by Mike McCormack discovering
a CrossOver only hack was visible in a screenshot. So they basically
ripped off CodeWeavers. SpecOpsLabs never had an explanation for why
-a CrossOver specific bug some how made it into their tree. In fact,
+a CrossOver specific bug somehow made it into their tree. In fact,
they specifically denied using CXO:
<ul><li><a href="http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=1454">OSViews</a></li>
</ul>
@@ -540,10 +540,10 @@ is the right one, but it works quite nic
posts="4"
>
<topic>Debugging</topic>
-<p>With Wine you can easily generate debugging logs that trace the API's
+<p>With Wine you can easily generate debugging logs that trace the APIs
called by a program. Corey McClymonds asked if there was a way to do
that on Windows, apparently to be able to compare the code paths used
-by Windows DLL's and Wine's:</p>
+by Windows' DLLs and Wine's:</p>
<quote who="Corey McClymonds"><p>
There is a game, known as Continuum, that has a very complicated setup
before it actually starts the game, to prevent cheating. Due to this, the
More information about the wine-cvs
mailing list