ChangeSet ID: 22074 CVSROOT: /opt/cvs-commit Module name: lostwages Changes by: jnewman@winehq.org 2006/01/03 16:02:04
Modified files: wwn : wn20051211_301.xml wn20051223_302.xml
Log message: Francois Gouget fgouget@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