[WINEHQ] Assorted spelling fixes
Francois Gouget
fgouget at free.fr
Sun Sep 25 10:27:00 CDT 2005
Changelog:
* news/2005083001.xml
wwn/wn20010226_84.xml
wwn/wn20050603_277.xml
wwn/wn20050916_290.xml
wwn/wn20050923_291.xml
Assorted spelling fixes
--
Francois Gouget fgouget at free.fr http://fgouget.free.fr/
f u kn rd ts, ur wy 2 gky 4 ur wn gd.
-------------- next part --------------
Index: news/2005083001.xml
===================================================================
RCS file: /var/cvs/lostwages/news/2005083001.xml,v
retrieving revision 1.3
diff -u -p -r1.3 2005083001.xml
--- news/2005083001.xml 31 Aug 2005 20:39:29 -0000 1.3
+++ news/2005083001.xml 25 Sep 2005 08:18:37 -0000
@@ -2,10 +2,10 @@
<date>August 30, 2005</date>
<title>WineHQ has moved!</title>
<body>
- We moved WineHQ to a new ISP today. The website was down for awhile,
+ We moved WineHQ to a new ISP today. The website was down for a while,
but now things are working well again. There still may be a few quirks
- here an there. We are on top of those and things will be smooth again soon.
+ here and there. We are on top of those and things will be smooth again soon.
<br /><br />
- Now back to your regularly scheduled wine hacking.
+ Now back to your regularly scheduled Wine hacking.
</body>
</news>
Index: wwn/wn20010226_84.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20010226_84.xml,v
retrieving revision 1.3
diff -u -p -r1.3 wn20010226_84.xml
--- wwn/wn20010226_84.xml 16 Dec 2003 17:09:27 -0000 1.3
+++ wwn/wn20010226_84.xml 25 Sep 2005 08:19:11 -0000
@@ -119,7 +119,7 @@ John Sturtz (re)-opened the long awaited
harness for Wine (and its implementation of the Windows API).
<quote who="John F Sturz">
-I work for CodeWeavers here in St Paul. Awhile back, I was set to the
+I work for CodeWeavers here in St Paul. A while back, I was set to the
task of working on winetest, a Wine application which provided a
flex/bison-based parser for a little scripting language from which
Wine API functions could be called. The idea was that one could write
Index: wwn/wn20050603_277.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20050603_277.xml,v
retrieving revision 1.4
diff -u -p -r1.4 wn20050603_277.xml
--- wwn/wn20050603_277.xml 20 Jun 2005 16:21:07 -0000 1.4
+++ wwn/wn20050603_277.xml 25 Sep 2005 08:19:30 -0000
@@ -257,7 +257,7 @@ Started to go through this and found som
exist and is found, so HAVE_SYS_LWP_H is defined. The test for
_lwp_create fails. Looking a bit deeper I found that the lwp.h for
Solaris 9 is different from the one in Solaris 10 (which is what I am
-using). Based on this and something I read awhile ago, I believe that Sun
+using). Based on this and something I read a while ago, I believe that Sun
is attempting to phase out the lwp stuff on Solaris.
</p><p>
It looks like a workaround will need to be created for _lwp_create. I
Index: wwn/wn20050916_290.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20050916_290.xml,v
retrieving revision 1.2
diff -u -p -r1.2 wn20050916_290.xml
--- wwn/wn20050916_290.xml 18 Sep 2005 07:00:02 -0000 1.2
+++ wwn/wn20050916_290.xml 25 Sep 2005 11:24:36 -0000
@@ -184,7 +184,7 @@ So overall, things are looking good. </
>
<topic>Architecture</topic>
<p>Device drivers have always been a hot topic with Wine. The idea
-of some how running Windows device drivers with Wine comes up every
+of somehow running Windows device drivers with Wine comes up every
few months. In recent years, some of the discussion has actually
gotten pretty serious and some of the ideas have actually seemed
somewhat plausible. For instance,
@@ -201,7 +201,7 @@ device driver into loading; you also hav
the standard Win32 API. Vitaliy Margolen asked this week:</p>
<quote who="Vitaliy Margolen"><p>
We need ntoskrnl to run some subset of drivers on wine. Notably cd protection
-drivers. They are not a hardware drivers, but a means to access something that
+drivers. They are not hardware drivers, but a means to access something that
is not accessible from user space. So in a sense ntoskrnl is just a process to
run those drivers in, and send/receive requests to/from those drivers.
</p><p>
@@ -231,7 +231,7 @@ Solutions for (1):
<ul>
1.1. Use a hack to determine that passed name is a device name. (Device names
don't have colon in them).<br />
-1.2. Check against all possible names other then device names. (A:..Z:,
+1.2. Check against all possible names other than device names. (A:..Z:,
etc.)<br />
1.3. Try it last if all else fails. (since name spaces don't intersect this
should work.)<br />
@@ -254,7 +254,7 @@ Solutions for (2):
ntoskrnl to create an IRP. ntoskrnl will process them and notify wineserver
when call is complete.
(This is the most complicated and closer represents what windows does.
- There are still a problem communicating to ntoskrnl. It is probably the
+ There is still a problem communicating with ntoskrnl. It is probably the
way to go in the future. But that will require number of things implemented
which are not trivial.)<br />
</ul></li></ul>
@@ -286,20 +286,20 @@ which is a user mode implementation of n
Mode Linux.
</p><p>
That would require being able to write to a process's memory from the
-ntoskrnl, which is what your really need to implement ReadFile and
+ntoskrnl, which is what you really need to implement ReadFile and
WriteFile so device driver can work properly.
</p><p>
That project is really beyond the scope of Wine... but an interesting
-one none the less :)</p></quote>
+one nonetheless :)</p></quote>
<p>Peter Beutner wanted to know about one of the methods Vitaliy had
mentioned,
<quote who="Peter Beutner">
-Why implement ntoskrnl as a seperate process plus inventing a new IPC
+Why implement ntoskrnl as a separate process plus inventing a new IPC
protocol to talk to it? As you said: "ntoskrnl for windows _is_ what
-wineserver for wine.". So why not implement the needed ntoskrnl stuff
+wineserver is for wine.". So why not implement the needed ntoskrnl stuff
into wineserver?</quote></p>
@@ -352,7 +352,7 @@ Summary of all the ideas and requirement
other way around. Unless we implement int 0x2e handling and replace
wineserver with ntoskrnl. (this is wine not reactos, ntdll already has all
the required functionality)</li>
-<li> Drivers can not be ran in a process that requires them (drivers we are
+<li> Drivers cannot be run in a process that requires them (drivers we are
concerned
about keep information that is shared between different processes, drivers
require their own environment that is different from a user process
@@ -410,7 +410,7 @@ the Wine management structure. It seems
communication problem. At the end of the thread it appeared a few things
could be done to help the process, however it doesn't appear anyone will
step up to work on it.
-real solutions were offered. </p>
+Real solutions were offered. </p>
<p>Troy Rollo started the discussion with:</p>
<quote who="Troy Rollo"><p>
I should preface this by saying that I don't mean any criticism or offence by
@@ -462,7 +462,7 @@ virtually certain that the patch would b
A supporting facility you would probably need would likely include either
separate mailing lists for each sub-project (things get lost in wine-devel
<i>now</i> with consolidated read-only lists for people who want a convenient
-way of watching all of the discussions or a shift to an NNTP heirarchy with
+way of watching all of the discussions or a shift to an NNTP hierarchy with
mailing gateways.
</p><p>
These structures are nothing new - most of the really big projects work this
@@ -643,7 +643,7 @@ might remember that Oliver began working
ago. He maintained much of that code outside of the Wine tree for a
long time and only began submitting patches a few months ago. That was
sort of frustrating for a lot of Wine developers, but things have really
-progressed. Oliver has broken his DirectX work into small, contained
+progressed. Oliver has broken his DirectX work into small, self-contained
patches and Alexandre has committed almost all of them. Oliver wrote:</p>
<quote who="Oliver Stieber"><p>
I thought it was about time I gave a status update on DirectX9/wined3d, so here goes.
@@ -747,7 +747,7 @@ Just because no one else has said it yet
</p><p>
Nice work, Jer!
</p><p>
-(Jer is masking all the behind the scenese wrangling
+(Jer is masking all the behind the scenes wrangling
he did with our two ISPs to arrange this, and the
mad scramble to replace a raided drive that
had fried, and the rebuild to Debian. )
@@ -768,7 +768,7 @@ for things like screenshots.</p>
archive="http://www.winehq.com/hypermail/wine-devel/2005-September/040079.html"
posts="2"
>
-<p>Is Wine SMP safe? Well.. it certainly seems like a topic someone would
+<p>Is Wine SMP safe? Well... it certainly seems like a topic someone would
have brought up if there were issues. Dan Kegel asked about a bug report:</p>
<quote who="Dan Kegel"><p>
I've seen conflicting reports about whether Wine is safe
@@ -789,7 +789,7 @@ to see if he can still reproduce it.</p>
I'm running it since 1.5 years on a SMP system (P4, HT enabled and smp
kernel). I don't remember to have run into SMP problems. Or better said
-in the problems i tried to debug there wasn't a SMP bug.</quote></p>
+in the problems i tried to debug there wasn't an SMP bug.</quote></p>
</section>
Index: wwn/wn20050923_291.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20050923_291.xml,v
retrieving revision 1.2
diff -u -p -r1.2 wn20050923_291.xml
--- wwn/wn20050923_291.xml 23 Sep 2005 05:18:14 -0000 1.2
+++ wwn/wn20050923_291.xml 25 Sep 2005 15:20:40 -0000
@@ -67,7 +67,7 @@ Its main goal is to fix scripts and hate
>
<topic>News</topic>
<p>Only because I don't want the next news item to get a real headline,
-I'm going to give a link to Newsforge that
+I'm going to give a link to NewsForge that
<a href="http://programming.newsforge.com/programming/05/09/19/223211.shtml?tid=25&tid=132">mentions Wine</a> in passing. Google's Summer of Code has
wrapped up and Chris DiBona had a lot to say about the success of the program.
</p>
@@ -109,7 +109,7 @@ well, it might even be doing more harm t
<p>Those three docs are written in SGML, which is quite similar to HTML.
We use the <a href="http://www.docbook.org">Docbook</a> schemas to
describe the contents. In turn, we can use the Docbook utilities to
-convert the SGML into whatever we want, such as PDF's, HTML, etc. That
+convert the SGML into whatever we want, such as PDFs, HTML, etc. That
documentation used to live within the core Wine CVS tree, but we split
it out earlier in the summer. Now it has its own CVS tree and Dimi Paun
has been making commits. Tom Wickline described how to get to the docs:</p>
@@ -137,7 +137,7 @@ a little outdated, but it's a good start
I started in on this about a year ago and there's a pretty good
outline to work from. Some of the actual content is just plain wrong
now, but it's probably about 90% accurate. There have been changes
-the the DLL Overrides and Drive Settings part of Winecfg. I'd also
+to the DLL Overrides and Drive Settings part of Winecfg. I'd also
consider this stuff to be a little light on the configuration side.
For example, to configure just application settings you need to add an
app on the first tab of winecfg and then make the overrides on the
@@ -184,7 +184,7 @@ duplicated in some form or another on th
much stuff like that removed from the User Guide as possible, we can
simply refer people to WineHQ for more info. (I think the reason for the
duplication is that the website docs simply didn't exist when the User
-Guide was written, now the website has superceded the User Guide.)
+Guide was written, now the website has superseded the User Guide.)
When it's all said and done we should be left with the following sections:
<ul>
<li> Introduction</li>
@@ -314,7 +314,7 @@ ready to take calls to WineD3D. I've not
<li> Headers: WineD3D depends on the d3d8 or d3d9 headers. I've made the check
pass with d3d.h, but I had to copy a lot of definitions from d3d9types.h. The
thing compiles without errors or warnings now, but there may be side effects
-I don't know for now.</li>
+I don't know of for now.</li>
<li> Surfaces... You mentioned it, I think I don't need to explain anything
here ;-)</li>
@@ -334,7 +334,7 @@ created WINED3DFOOBAR and put into inclu
should be easy enough to extend to d3d7.
</p><p>
-p.s. the reason for intergrating with ddraw is so that X11Drv works properly
+p.s. the reason for integrating with ddraw is so that X11Drv works properly
with wined3d, this affects things like locking the mouse to a window in full
screen mode and being able to Get and Release the DC for the surface.
</p></quote>
@@ -408,14 +408,14 @@ strange:</p>
Even the Wine-headers are closer to the original SDK than CE. The order
of function is different, the macros, the styling. There is no
resemblance, not even one name of one parameter. Just the Function name
-and the Header name. Its like they had a copyright problem and needed to
+and the Header name. It's like they had a copyright problem and needed to
write it from scratch.:)</p><p>
Now for wine I will not do the same. I'll try to keep the same
headers, and where there are ABI differences. Like calling convention
parameter sizes.. I'll try to use a macro.</p><p>
On the implementation side Linux is Linux is Linux so I guess that
should work well. But it looks like The Win32 API was shifted around a
-bit so in CE functions don't sit in the same Dll's as they sit in Win32,
+bit so in CE functions don't sit in the same Dlls as they sit in Win32,
and apps are linked differently. So spec files and Makefiles will have
to be different.</p><p>
More information about the wine-patches
mailing list