Jeremy Newman : Francois Gouget <fgouget@free.fr>

Jeremy Newman jnewman at wine.codeweavers.com
Tue Sep 11 10:18:41 CDT 2007


Module: website
Branch: master
Commit: 737a03588524f39156ebc1cf59f504a2004023d3
URL:    http://source.winehq.org/git/website.git/?a=commit;h=737a03588524f39156ebc1cf59f504a2004023d3

Author: Jeremy Newman <jnewman at jnewman.(none)>
Date:   Tue Sep 11 10:17:59 2007 -0500

Francois Gouget <fgouget at free.fr>
Assorted spelling fixes.

---

 wwn/wn20070514_331.xml |   40 ++++++++++++++++++++--------------------
 1 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/wwn/wn20070514_331.xml b/wwn/wn20070514_331.xml
index dc4c525..af12a1e 100644
--- a/wwn/wn20070514_331.xml
+++ b/wwn/wn20070514_331.xml
@@ -170,7 +170,7 @@ more apps.</p>
 0.9.37 had reached a milestone:</p>
 <quote who="Stefan Dosinger"><p>
 
-With Wine 0.9.37 we've archieved something that I allow myself to call a small 
+With Wine 0.9.37 we've achieved something that I allow myself to call a small 
 milestone - All Direct3D7 Immediate mode SDK demos successfully perform their 
 intended rendering. I have some screenshots on my university junk server:
 <ul>
@@ -179,14 +179,14 @@ http://stud4.tuwien.ac.at/~e0526822/sdkdemos1.png</a></li>
 <li><a href="http://stud4.tuwien.ac.at/~e0526822/sdkdemos2.png">
 http://stud4.tuwien.ac.at/~e0526822/sdkdemos2.png</a></li></ul>
 </p><p>
-Two major problems are left though, namely windowed opengl rendering(see the 
-junk where a menu bar should be) and GetDC(there should be a little bit of 
+Two major problems are left though, namely windowed opengl rendering (see the 
+junk where a menu bar should be) and GetDC (there should be a little bit of 
 text rendered, I disabled render target locking to get proper performance).
 </p><p>
 Some demos have a few smaller problems too. The bump earth and bump waves need 
-vendor specific extensions(GL_NV_texture_shader2 / GL_ATI_envmap_bumpmap) and 
+vendor specific extensions (GL_NV_texture_shader2 / GL_ATI_envmap_bumpmap) and 
 the bend demo needs GL_ARB_vertex_blend which nvidia does not support. So I 
-took that screenshot on my mac running linux(ati radeon X1600. The mipmap 
+took that screenshot on my mac running linux (ati radeon X1600). The mipmap 
 demo renders the mipmaped texture garbled, although this works on nvidia 
 cards. The Z buffer demo says w buffers aren't supported, but the normal z 
 buffer does what the w buffer is supposed to do.
@@ -202,12 +202,12 @@ regressions I can get hold of, and I am trying to make D3D thread safe
 finally. From the application point of view my focus will stay on fixing 
 older apps first, which somewhat includes getting thread safety, render 
 target locking and GetDC working properly. My hope is also to fix the other 
-related DX7 sdk demos, like the DDraw demos(except overlays, they are highly 
+related DX7 sdk demos, like the DDraw demos (except overlays, they are highly 
 tricky with the current wined3d-x11drv integration) and getting native 
 d3drm.dll working.
 </p><p>
 I also want to say thanks to all the small and big helpers who help with 
-technical advise, debugging and regression testing. Special thanks goes to 
+technical advice, debugging and regression testing. Special thanks goes to 
 Henri without whom I'd be totally lost and who has to be credited for a huge 
 majority of the shader work in the last half year, and a lot of other things 
 too.
@@ -221,7 +221,7 @@ attachments, not even as jpgs.</p></quote>
 <p>Henri Verbeet then suggested D3D8 be the next target, although a lot of
 it is implemented.  Stefan explained a little more about future DirectX work:
 </p><quote who="Stefan Dosinger"><p>
-Yeah, thats the other thing of course :-) But as I said even d3d7 and ddraw
+Yeah, that's the other thing of course :-) But as I said even d3d7 and ddraw
 had a few biggies I want to fix. Of course I may grab some low hanging fruits
 like kicking out the fvf code from d3d8 and wined3d :-) Or get the sdk demos
 going, they should all work now by looking at their names.
@@ -245,11 +245,11 @@ working with regard to Direct3D.</p>
 <p>A largish patch arrived this week and before we get into it, we'll step 
 back and give a little introduction.</p>
 
-<p>Some new features added to Windows in the past few years requires some
-new terminolgy to learn.  Some of this functionality is used by .NET, though
+<p>Some new features added to Windows in the past few years require learning
+some new terminolgy.  Some of this functionality is used by .NET, though
 it's not strictly a .NET technology.
 So let's say you've got an <i>assembly</i>, a collection of PE files like
-DLL's, and you want to describe how they all interelate and what version of
+DLLs, and you want to describe how they all interelate and what version of
 DLL you want to use.  What 
 you'd do is create a <i>manifest</i> composed of an XML structure that defines 
 how the different classes are bound together, dependencies, versioning info, 
@@ -283,14 +283,14 @@ so far:</p>
 The following series provides a first real implementation of activation 
 contexts. It has been written by Jacek Caban and myself. Even if individual 
 patches show only one of the two names (for ease of packaging), reality is 
-different. In many cases, ideas, implementation, bug fix(es), improvement have 
+different. In many cases, ideas, implementation, bug fix(es), improvements have 
 been done by both of us.
 </p><p>
 Basically, this first series of patches implements:
 <ul>
 <li> searching and building the hierarchy of manifests needed by an application</li>
 <li> parsing of such manifests</li>
-<li> implementation of the Query function on this hierarchy of manifest</li>
+<li> implementation of the Query function on this hierarchy of manifests</li>
 <li> core activation context manipulation APIs (add/release ref, stacking...)</li>
 </ul></p><p>
 This doesn't allow yet to let an application with manifest being successfully 
@@ -375,14 +375,14 @@ USB interfaces that Windows has.
 </p><p>
 <u>CONNECTING WINE TO USB: A HOW-TO GUIDE</u>
 </p><p>
-There is 4 ways to do it:
+There are 4 ways to do it:
 <ol>
 <li> Make a kernel module in your OS (eg. a Linux kernel module) that
 exports the same interface that the software expects and works the
 same way as the Windows driver. Using USBSCAN.SYS as an example,
 reading does a USB bulk read, writing does a USB bulk write, and 13 or
 so i/o control codes do various other things, among them USB control
-and interrupt tranfers. Change kernel32's CreateFileW() to open the
+and interrupt transfers. Change kernel32's CreateFileW() to open the
 /dev device node used by the kernel module and send it to the wine
 server using wine_server_fd_to_handle(), then reading and writing will
 go to your kernel module, where you can implement them by doing USB
@@ -391,7 +391,7 @@ capture i/o control codes used by your device, call
 wine_server_handle_to_fd(), and do an ioctl() on that fd to send that
 i/o control call to the kernel module, which then reacts
 appropriately. This way has been tested by me, it works and it's fast,
-but it's non-portable (eg. Linux-only, and Linux's USB interface keep
+but it's non-portable (eg. Linux-only, and Linux's USB interface keeps
 changing so an out-of-tree module will only work on some versions, the
 usual problems...), difficult (kernel-mode code is hard to write), and
 generally a royal PITA.
@@ -442,7 +442,7 @@ allow device drivers to be written to a standard framework.</p>
 	posts="1"
 >
 <topic>Packaging</topic>
-<p>Marco Meijer packaged updated Mandriva RPM's and announced them:</p>
+<p>Marco Meijer packaged updated Mandriva RPMs and announced them:</p>
 <quote who="Marco Meijer"><p>
 As I have still no way to upload the mandriva wine rpm to the
 official winehq download server, I put it on my own website.
@@ -461,7 +461,7 @@ http://www.xs4all.nl/~meijer2/wine/</a>
 >
 <topic>Debugging</topic>
 <p>Markus Amsler felt the time it took to load debug symbols was way too
-slow.  For example, in World of Warcraft it's 100 seconds or so.  He
+long.  For example, in World of Warcraft it's 100 seconds or so.  He
 came up with a patch to use Wine's Heap memory functions directly and it
 reduced the load time to 18 seconds.  There was some back and forth
 discussion with Eric Pouech, the resident dbghelp.dll guru, and some
@@ -479,7 +479,7 @@ with bigger files. insert_first, process_heap are out.</li>
  <li> big pools have more memory overhead than big heaps.</li>
  <li> big pools are a lot slower than big heaps.</li>
 </ul></p><p>
-IMO the best results would give removing the pools (like in 
+IMO the best results would be removing the pools (like in 
 process_heap) and freeing unused memory manually, the other way round it 
 was allocated. But at a first glance it looks like quite a bit of work, 
 which I'm not sure is worth the result. I think the best approach would 
@@ -500,7 +500,7 @@ the pool. I even implemented a simple radix tree for the bucket storage.
 The initial bucket size has no measurable effect, so I left it at 1 to 
 save some bytes.
 </p><p>
-Here the stats for this series:
+Here are the stats for this series:
 </p><p>
 <table>
 <tr><td>&#120; </td><td>Memory after startup(kB)</td><td>  Memory normal 




More information about the wine-cvs mailing list