Apparently some typo fixes were not applied the first time around. So here's the second round. It can be applied by doing: cd lostwages patch -p0 </path/to/email.txt Changelog: Fix common typos in the web site. Index: wwn/wn19990718_4.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn19990718_4.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn19990718_4.xml --- wwn/wn19990718_4.xml 2 Dec 2002 17:08:24 -0000 1.1.1.1 +++ wwn/wn19990718_4.xml 9 Jun 2003 20:40:39 -0000 @@ -977,13 +977,13 @@ <p /> At present, it is possible to run multiple Win32 apps by starting -seperate Wine processes manually at the command line, which would then -start seperate Wine server processes along with the app. These processes +separate Wine processes manually at the command line, which would then +start separate Wine server processes along with the app. These processes cannot communicate amongst each other using standard Win32 IPC APIs, may have problems due to unserialized access to registry files, etc. Some of this may be solvable by having a shared Wine server process. Extending the Wine server model in this way is <b>not</b> what people are -discussing as seperate address spaces though, right? +discussing as separate address spaces though, right? <p /> @@ -996,14 +996,14 @@ <p /> The problem with the shared address space model is that it does not -provide the memory protection that would be provided with the seperated +provide the memory protection that would be provided with the separated model, and that the new process will not have the same memory layout it would have had in Windows, right? <p /> If that's all it is, why is it a big deal? Unless I'm mistaken, -providing seperated address spaces will be a <b>big</b> deal, requiring +providing separated address spaces will be a <b>big</b> deal, requiring marshalling of all message data, and various other tweaky-to-get-right tasks. On the other side of the coin, how common is the use of CreateProcess amongst the apps people want to run? Is this useful Index: wwn/wn20010611_97.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20010611_97.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20010611_97.xml --- wwn/wn20010611_97.xml 2 Dec 2002 17:08:15 -0000 1.1.1.1 +++ wwn/wn20010611_97.xml 9 Jun 2003 20:41:01 -0000 @@ -372,7 +373,7 @@ <quote who="Patrick Stridvall"> <p>However regardless of this, uname shouldn't be used (at least not directly). Autoconf provides a standard -way to do this (which BTW happends to use uname). +way to do this (which BTW happens to use uname). It can be used as below.</p> <p><code>AC_CANONICAL_HOST<br /> Index: wwn/wn20020213_115.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20020213_115.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20020213_115.xml --- wwn/wn20020213_115.xml 2 Dec 2002 17:08:21 -0000 1.1.1.1 +++ wwn/wn20020213_115.xml 9 Jun 2003 20:41:11 -0000 @@ -622,7 +623,7 @@ contribute significantly to the project. Only the developers contribute, and it is not at all clear to me that they would stop.</p> -<p>Marcus Meissner has already shown that the existance of our AFPLed DCOM +<p>Marcus Meissner has already shown that the existence of our AFPLed DCOM code didn't stop him from going ahead and doing it himself. On the contrary - it helped him, since he got hints from our design. It's a shame that he had to, since we've been working hard to find a way to contribute Index: wwn/wn20020807_131.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20020807_131.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20020807_131.xml --- wwn/wn20020807_131.xml 2 Dec 2002 17:08:38 -0000 1.1.1.1 +++ wwn/wn20020807_131.xml 9 Jun 2003 20:41:21 -0000 @@ -359,7 +361,7 @@ registries in addition to compiling wine so most of the time if you already have these set up then it is not nessesary to use wineinstall. </p><p> - However the structure of both the .wine/config and registries and thier + However the structure of both the .wine/config and registries and their contents has changed over time and as new features are added to wine. For example over time more functionality has been added to the various dlls and in the default config file various dlls now default to builtin Index: wwn/wn20021025_141.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20021025_141.xml,v retrieving revision 1.2 diff -u -r1.2 wn20021025_141.xml --- wwn/wn20021025_141.xml 9 Jun 2003 15:18:38 -0000 1.2 +++ wwn/wn20021025_141.xml 9 Jun 2003 20:41:25 -0000 @@ -552,7 +553,7 @@ to do page rendering and such.</p> <p>Malte replied, <quote who="Malte Starostik"> -Hmm, we're implementing the absolutely neccessary parts in reaktivate +Hmm, we're implementing the absolutely necessary parts in reaktivate with Konqueror, but that's run from inside Konq already, so it's a bit special. Maybe there would be a way to use either browser with those interfaces? :-)</quote></p> Index: wwn/wn20021122_145.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20021122_145.xml,v retrieving revision 1.1 diff -u -r1.1 wn20021122_145.xml --- wwn/wn20021122_145.xml 2 Dec 2002 17:40:34 -0000 1.1 +++ wwn/wn20021122_145.xml 9 Jun 2003 20:41:28 -0000 @@ -597,14 +598,14 @@ reentrent variant if present as well as having an alternative implementation if not. </p><p> -As to the implict existance question: I'm not sure. +As to the implict existence question: I'm not sure. First of all, to answer the related question: Should you have a alternative implementation for defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? </p><p> IMHO the answer is no. It is not worth the effort to support hypotetical platforms unless we can verify the -existance of one. +existence of one. </p><p> To return to the original question: I suggest that we should detect the presence or absence Index: wwn/wn20030516_170.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20030516_170.xml,v retrieving revision 1.2 diff -u -r1.2 wn20030516_170.xml --- wwn/wn20030516_170.xml 9 Jun 2003 15:18:38 -0000 1.2 +++ wwn/wn20030516_170.xml 9 Jun 2003 20:41:40 -0000 @@ -403,7 +404,7 @@ </section><section title="Separating 16/32 Bit OLE Functions" - subject="PATCH - Start seperating 16/32 in Ole and ole32 memlockbytes" + subject="PATCH - Start separating 16/32 in Ole and ole32 memlockbytes" archive="http://www.winehq.com/hypermail/wine-devel/2003/05/0404.html" posts="2" startdate="05/15/2003" @@ -413,7 +414,7 @@ OLE32. He gave an update of what he's trying to do and some of the issues involved:</p> <quote who="Steven Edwards"><p> - I am doing some work trying to seperate Ole* and Ole32 for use in + I am doing some work trying to separate Ole* and Ole32 for use in ReactOS. Before we can make use of most of the WINE code all of the Non-Win32api imported functions are going to need to be compiled out or rewitten. I dont need someone to do this for me but I am going to need a Index: wwn/wn20030523_171.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20030523_171.xml,v retrieving revision 1.1 diff -u -r1.1 wn20030523_171.xml --- wwn/wn20030523_171.xml 27 May 2003 14:25:49 -0000 1.1 +++ wwn/wn20030523_171.xml 9 Jun 2003 20:41:41 -0000 @@ -273,7 +274,7 @@ At one point Dimi thought a dsp2make utility would be a useful addition and Steven mentioned ReactOS had one. He went on to discuss some future plans, <quote who="Steven Edwards"> - My goal if the ReactOS guys can get more then winhello working is to have WINEs + My goal if the ReactOS guys can get more than winhello working is to have WINEs shell32 and comctl32 running for Linux world</quote>. </p> <p>All in all the meeting was quite successful and a lot of people were glad to @@ -399,7 +400,7 @@ will put in the new interface (that will also let me implement some of GetCharacterProperties more obscure features). That is not likely to happen. I suspect FriBidi has fallen off the end of the earth. It does -not implement mirroring, nor does it implement Arabic Shaping (wierd, +not implement mirroring, nor does it implement Arabic Shaping (weird, considering that the maintainer is from Iran). It only supports UCS-4. </p><p> Also - like I told Mike H on IRC, static linking ICU will mean that we -- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.