Typo fixes
Francois Gouget
fgouget at free.fr
Sat Jun 7 20:58:23 CDT 2003
Changelog:
Fix common typos in the web site.
Index: templates/en/supported_applications.template
===================================================================
RCS file: /home/wine/lostwages/templates/en/supported_applications.template,v
retrieving revision 1.5
diff -u -r1.5 supported_applications.template
--- templates/en/supported_applications.template 26 Apr 2003 17:06:20 -0000 1.5
+++ templates/en/supported_applications.template 8 Jun 2003 01:41:03 -0000
@@ -16,12 +16,12 @@
<p>
Wine has an <a href="http://appdb.winehq.com/">Application Database</a> where Windows
-application compatability is recorded. Registered users can submit new apps, and comment
+application compatibility is recorded. Registered users can submit new apps, and comment
on existing ones. Screen shots are also available for many apps. Users can also vote on their
favorite apps.
</p>
-<h1>Other Wine Application Compatability Sites</h1>
+<h1>Other Wine Application Compatibility Sites</h1>
<p>
<a href="http://frankscorner.org"><b>Frank's Corner</b></a>: Frank has a fantastic Wine
@@ -30,9 +30,8 @@
<h1>Wine 0.9 Supported Applications List</h1>
-<p>This is a working version of the application lists which we hope to support 'officially'
-for Wine 0.9. Do not worry too much about formatting. It is not very good, and will
-most likely change before it goes to WineHQ. Please send comments, and suggestions,
+<p>This is a working version of the application lists which we hope to
+support 'officially' for Wine 0.9. Please send comments, and suggestions,
about the list to <a href="mailto:clozano at andago.com">Carlos Lozano</a>;
direct formatting related flames to <a href="mailto:dpaun at rogers.com">Dimitrie O. Paun</a>.</p>
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 8 Jun 2003 01:41:05 -0000
@@ -977,13 +976,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 +995,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/wn20000904_59.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20000904_59.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 wn20000904_59.xml
--- wwn/wn20000904_59.xml 2 Dec 2002 17:08:31 -0000 1.1.1.1
+++ wwn/wn20000904_59.xml 8 Jun 2003 01:41:17 -0000
@@ -75,7 +75,7 @@
<quote who="Ulrich Weigand">
The problem is that we implement thunks differently than Win95 does,
with the most important difference being that we actually have two
-seperate stacks per app, a 16-bit one and a 32-bit one, where Win95
+separate stacks per app, a 16-bit one and a 32-bit one, where Win95
has only <b>one</b> stack: 16-bit apps have their 16-bit stack, and when
thunking to 32-bit, ESP is simply set to the appropriate 32-bit flat
pointer pointing to the current 16-bit stack location; 32-bit apps
Index: wwn/wn19990920_9.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn19990920_9.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 wn19990920_9.xml
--- wwn/wn19990920_9.xml 2 Dec 2002 17:08:24 -0000 1.1.1.1
+++ wwn/wn19990920_9.xml 8 Jun 2003 01:41:06 -0000
@@ -232,7 +231,7 @@
How do people feel about adding optional support for a non-free
library that provides this functionality? Alexandre, if we did
work to support such a library (ifdefed, of course), would you allow
-that work into CVS, or would we have to keep a seperate branch
+that work into CVS, or would we have to keep a separate branch
ourselves?
<p />
Index: wwn/wn20001211_73.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20001211_73.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 wn20001211_73.xml
--- wwn/wn20001211_73.xml 2 Dec 2002 17:08:33 -0000 1.1.1.1
+++ wwn/wn20001211_73.xml 8 Jun 2003 01:41:22 -0000
@@ -293,7 +293,7 @@
Gavriel State wondered
<quote who="Gavriel State">
Is there really any reason not to just use pthread directly? We're not
-constrained by binary compatability issues on LinuxPPC (or MacOS X),
+constrained by binary compatibility issues on LinuxPPC (or MacOS X),
so there's no need to preserve any special registers.
<p />
Index: wwn/wn20001218_74.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20001218_74.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 wn20001218_74.xml
--- wwn/wn20001218_74.xml 2 Dec 2002 17:08:33 -0000 1.1.1.1
+++ wwn/wn20001218_74.xml 8 Jun 2003 01:41:22 -0000
@@ -270,7 +270,7 @@
<p />
-Dynamic linking allows to seperate executable code between several
+Dynamic linking allows to separate executable code between several
modules (each stored in a different file), but loaded in memory to
create a process image.
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 8 Jun 2003 01:41:26 -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 8 Jun 2003 01:41:36 -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/wn20020308_117.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20020308_117.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 wn20020308_117.xml
--- wwn/wn20020308_117.xml 2 Dec 2002 17:08:21 -0000 1.1.1.1
+++ wwn/wn20020308_117.xml 8 Jun 2003 01:41:38 -0000
@@ -771,7 +772,7 @@
<p>Ove replied, <quote who="Ove Kaaven">
I've been working on this as part of my COM restructure. I've implemented
- NdrDllRegisterProxy and large pieces of rpcrt4's marshaling framework. I'd
+ NdrDllRegisterProxy and large pieces of rpcrt4's marshalling framework. I'd
like to release it to WineHQ, but Gav still wants something in exchange.
(If we can't get money, we'll consider releasing it if a Wine developer
agrees to work on stuff that may be useful for us, like an ALSA driver,
Index: wwn/wn20020620_127.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20020620_127.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 wn20020620_127.xml
--- wwn/wn20020620_127.xml 2 Dec 2002 17:08:37 -0000 1.1.1.1
+++ wwn/wn20020620_127.xml 8 Jun 2003 01:41:45 -0000
@@ -329,7 +328,7 @@
I'm seeing two possible solutions to this
problem:
<ul>
- <li> If Fribidi was present during compile, check for its existance during
+ <li> If Fribidi was present during compile, check for its existence during
run time. If not present, don't enable the run time option. or </li>
<li> Copy (port?) Fribidi into the WINE code. It's LGPL, so the license
does allow that.</li>
@@ -386,7 +385,7 @@
mentioned that it had worked about a year ago but a patch had
caused a problem at some point. Tony Lambregts mentioned,
<quote who="Tony Lambregts">
- I estimate that it should take no more then 12 itinerations to
+ I estimate that it should take no more than 12 itinerations to
find the day of patch that broke it </quote> Ian wanted to
avoid installing Wine multiple times because of the hassle of
tweaking the installations. Several people jumped in to mention
Index: wwn/wn20020719_129.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20020719_129.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 wn20020719_129.xml
--- wwn/wn20020719_129.xml 2 Dec 2002 17:08:37 -0000 1.1.1.1
+++ wwn/wn20020719_129.xml 8 Jun 2003 01:41:46 -0000
@@ -162,7 +161,7 @@
<li> Make directories use real server handles, rather than pointers to
client structures. NtCreateFile supports taking a directory handle
and a relative path name from that directory to open files. I've
- tried to keep my SMB implementation seperate from everything else to
+ tried to keep my SMB implementation separate from everything else to
facilitate this.</li>
</p><p>
As you probably know, I've been working on #1 (see my patch from a few
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 8 Jun 2003 01:41:46 -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/wn20020913_135.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20020913_135.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 wn20020913_135.xml
--- wwn/wn20020913_135.xml 2 Dec 2002 17:08:39 -0000 1.1.1.1
+++ wwn/wn20020913_135.xml 8 Jun 2003 01:41:48 -0000
@@ -195,7 +197,7 @@
HAL (which is where the current ddraw code was starting to head), it calls
all the opengl calls inline. I have only tested on one machine with one
level of mesa (tough! thats all I have). It also has all the c parts in the
-d3d8 directory, completely seperate (and in some cases duplicating code from
+d3d8 directory, completely separate (and in some cases duplicating code from
the ddraw code), which may or may not be desired. I also dont have a clue
about the configure tests and makefile.in, so I have just a basic structure
which works enough for me. I'm also relatively certain I havent necessarily
Index: wwn/wn20021018_140.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20021018_140.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 wn20021018_140.xml
--- wwn/wn20021018_140.xml 2 Dec 2002 17:08:40 -0000 1.1.1.1
+++ wwn/wn20021018_140.xml 8 Jun 2003 01:41:50 -0000
@@ -316,7 +317,7 @@
<li>2045 of them are of type "int format, HANDLE arg", this leaves</li>
<li>1343 lines of warnings to look at.</li>
</ul></p><p>
-I'm almost finished a short perl script to automaticly convert the "int
+I'm almost finished a short perl script to automatically convert the "int
format, HANDLE arg" warnings, which would leave us with the other 1343
warnings. Wine compiles and even seems to run so if Alexander would
like to speed up the conversion he could change the remaining handles to
Index: wwn/wn20021025_141.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20021025_141.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 wn20021025_141.xml
--- wwn/wn20021025_141.xml 2 Dec 2002 17:08:40 -0000 1.1.1.1
+++ wwn/wn20021025_141.xml 8 Jun 2003 01:41:51 -0000
@@ -236,7 +237,7 @@
<li> widl is like MIDL for wine. For wine to be a useful RPC platform, quite
a bit of work needs to be done here. widl currently doesn't generate stubs
for RPC invocation -- it will need to; this is tricky because the MIDL compiler
- does some really wierd stuff. Then again, we don't neccesarily have to
+ does some really weird stuff. Then again, we don't necessarily have to
make widl work like MIDL, so it could be worse.</li>
<li> RPC has a quite featureful error handling mechanism; none of it is implemented
@@ -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 8 Jun 2003 01:41:54 -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/wn20021206_147.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20021206_147.xml,v
retrieving revision 1.1
diff -u -r1.1 wn20021206_147.xml
--- wwn/wn20021206_147.xml 18 Mar 2003 21:58:34 -0000 1.1
+++ wwn/wn20021206_147.xml 8 Jun 2003 01:41:55 -0000
@@ -309,7 +310,7 @@
That brings me to my other WIP, de-QT'ing KHTML and turning it into a
working browser implementation for WINE. So far this is actually coming
along quite well, and besides a few points it definatly makes an effective
-browser and IE compatability seems to generally be good enough to keep the
+browser and IE compatibility seems to generally be good enough to keep the
majority of IWebBrowser using applications happy. I've since abandoned my
earlier hopes to keep the changes minor (in order to make it easier to
backport fixes from the main KDE cvs), simply because it was making the
@@ -339,7 +340,7 @@
<li> Simple</li>
<li> No XPCOM dependancies</li>
-<li> Could be more easily hacked to add IE compatability (and was more IE
+<li> Could be more easily hacked to add IE compatibility (and was more IE
compatible to start with)</li>
<li> Small, good for embedding, relatively fast (gecko embedding is huge)</li>
<li> Would be possible to include in the Wine CVS tree as opposed to Gecko
Index: wwn/wn20030117_153.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20030117_153.xml,v
retrieving revision 1.1
diff -u -r1.1 wn20030117_153.xml
--- wwn/wn20030117_153.xml 18 Mar 2003 21:58:34 -0000 1.1
+++ wwn/wn20030117_153.xml 8 Jun 2003 01:41:58 -0000
@@ -287,7 +288,7 @@
my current code and play with that a little. Personally I didn't want to
have to take on the chore myself, but this whole Safari thing IS creating
more intrest in non-X11/QT platforms... it definatly changes the playing
-field, and with the large speed and compatability merges from Safari
+field, and with the large speed and compatibility merges from Safari
lately my current tree is hopelessly out of date anyway :)
</p><p>
So I think I will play with that and work on the DLL layout and COM
@@ -297,7 +298,7 @@
WINE-specific implementation if something more closely tied to the
upstream code is released meer weeks later.
</p><p>
-Of course there still a small problem of having to seperate the code into
+Of course there still a small problem of having to separate the code into
MS compatible COM objects and DLLs... I will have to benchmark the speed
impact of stubbing the MS dll's into khtml.dll/kjs.dll ecetra, instead of
replicating the exports more natively.
Index: wwn/wn20030207_156.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20030207_156.xml,v
retrieving revision 1.1
diff -u -r1.1 wn20030207_156.xml
--- wwn/wn20030207_156.xml 18 Mar 2003 21:58:34 -0000 1.1
+++ wwn/wn20030207_156.xml 8 Jun 2003 01:42:00 -0000
@@ -488,7 +489,7 @@
and shell32 + everything else but we are working on it. Right now the big thing is to compleate
our user32/Win32K and then we can make better use of the WINE code. I am trying to get the rest of
the ReactOS people to also use the WINE regression test framework for our test suite so we can
-share that also. Rest assured any fixes or new features will find thier way back in to the main
+share that also. Rest assured any fixes or new features will find their way back in to the main
wine tree.</quote></p>
</section>
Index: wwn/wn20030516_170.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20030516_170.xml,v
retrieving revision 1.1
diff -u -r1.1 wn20030516_170.xml
--- wwn/wn20030516_170.xml 16 May 2003 14:34:56 -0000 1.1
+++ wwn/wn20030516_170.xml 8 Jun 2003 01:42:06 -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
@@ -449,7 +450,7 @@
this may need some cleanup/review from a OLE guru on Linux but it builds
for me without warnings or errors under Mingw.
</p><p>
-Changelog: Seperate Win16 and Win32 Ole support in memlockbytes.
+Changelog: Separate Win16 and Win32 Ole support in memlockbytes.
</p></quote>
</section><section
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 8 Jun 2003 01:42:06 -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
Index: wwn/wn20030530_172.xml
===================================================================
RCS file: /home/wine/lostwages/wwn/wn20030530_172.xml,v
retrieving revision 1.1
diff -u -r1.1 wn20030530_172.xml
--- wwn/wn20030530_172.xml 3 Jun 2003 18:19:06 -0000 1.1
+++ wwn/wn20030530_172.xml 8 Jun 2003 01:42:06 -0000
@@ -180,7 +181,7 @@
</p><p>
The secondary problem is how to display the HTML + JavaScript needed for a
CHM viewer. I've started work on this several times, and so far the *best*
-(in terms of existing compatability with IE's CSS/JS/HTML 'features') has
+(in terms of existing compatibility with IE's CSS/JS/HTML 'features') has
been KJs and KHtml from the KDE project.
</p><p>
Gecko doesn't cut it - it's quite slow, bulky and worst of all too strict
@@ -199,7 +200,7 @@
writing ActiveX objects.
</p><p>
The second is that I never could get an answer from Alexandre as to adding
-C++ code to WINE itself. It would be possible to write it as a seperate
+C++ code to WINE itself. It would be possible to write it as a separate
non-core implementation, but many of these DLLs also have non-browser
related APIs that need to be in WINE itself. Again, diverting api calls
between the versions in WINE and our browser versions is complicated and
--
Francois Gouget fgouget at free.fr http://fgouget.free.fr/
Hiroshima '45 - Czernobyl '86 - Windows '95
More information about the wine-patches
mailing list