WineHQ: Assorted spelling fixes
Francois Gouget
fgouget at free.fr
Wed Oct 27 05:38:08 CDT 2004
This patch supersedes the previous one. It fixes a typo spotted by Filip
Navara and a new bunch of spelling errors spotted by Walt Ogburn.
Changelog:
* news/2004101401.xml
wwn/wn20010506_94.xml
wwn/wn20011224_111.xml
wwn/wn20030606_173.xml
wwn/wn20041015_244.xml
wwn/wn20041022_245.xml
Assorted spelling fixes
--
Francois Gouget fgouget at free.fr http://fgouget.free.fr/
Advice is what we ask for when we already know the answer but wish we didn't
-- Eric Jong
-------------- next part --------------
Index: news/2004101401.xml
===================================================================
RCS file: /var/cvs/lostwages/news/2004101401.xml,v
retrieving revision 1.2
diff -u -r1.2 2004101401.xml
--- news/2004101401.xml 14 Oct 2004 18:54:06 -0000 1.2
+++ news/2004101401.xml 25 Oct 2004 23:12:17 -0000
@@ -5,7 +5,7 @@
<p>
The following updates came in this week:
<ul><li>Dimi Paun updated the <a href="/site/todo_lists">To-Do List</a> and
- moved various items moved closer to completion.</li>
+ moved various items closer to completion.</li>
<li>The
<a href="/site/status_ui">UI Status</a> page was updated to reflect
Index: wwn/wn20010506_94.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20010506_94.xml,v
retrieving revision 1.5
diff -u -r1.5 wn20010506_94.xml
--- wwn/wn20010506_94.xml 16 Dec 2003 17:09:27 -0000 1.5
+++ wwn/wn20010506_94.xml 27 Oct 2004 10:23:54 -0000
@@ -200,7 +200,7 @@
<p>From there the discussion evolved into ways of setting up the autoconf
checks and exactly what versions of Freetype should be supported. Red Hat
shipped FreeType 1.4 with their 7.0 distribution while with 7.1 they
-included FreeType 2.0.1 too. The concensus seemed to be that FreeType
+included FreeType 2.0.1 too. The consensus seemed to be that FreeType
2.0 API should be used. From there Ian went on to add autoconf checks for
the FreeType header files.</p>
Index: wwn/wn20011224_111.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20011224_111.xml,v
retrieving revision 1.7
diff -u -r1.7 wn20011224_111.xml
--- wwn/wn20011224_111.xml 15 Jul 2004 18:41:41 -0000 1.7
+++ wwn/wn20011224_111.xml 27 Oct 2004 10:24:05 -0000
@@ -111,7 +111,7 @@
KC Wine #20</a> and <a href="http://kt.zork.net/wine/wn20000124_27.html#1">KC Wine #27</a>.
The license at the time had some requirements that may have made it incompatible
with other software projects and possibly not even a true open source license.
-Back then the concensus was to use an existing license "written by lawyers instead of hackers". So the move was done to a BSD-like license.</p>
+Back then the consensus was to use an existing license "written by lawyers instead of hackers". So the move was done to a BSD-like license.</p>
<p>Licensing will perpetually be a topic that you had best put a fireproof
suit on in order to participate. In the open source world there are basically
Index: wwn/wn20030606_173.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030606_173.xml,v
retrieving revision 1.5
diff -u -r1.5 wn20030606_173.xml
--- wwn/wn20030606_173.xml 16 Dec 2003 17:09:27 -0000 1.5
+++ wwn/wn20030606_173.xml 27 Oct 2004 10:24:16 -0000
@@ -268,7 +268,7 @@
Wine properly... So that we are only hiding the problem anyway.
</quote></p>
-<p>Thus far there doesn't seem to be a concensus on a solution and will
+<p>Thus far there doesn't seem to be a consensus on a solution and will
probably rely on Alexandre to make the decision.</p>
</section><section
Index: wwn/wn20041015_244.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20041015_244.xml,v
retrieving revision 1.1
diff -u -r1.1 wn20041015_244.xml
--- wwn/wn20041015_244.xml 15 Oct 2004 03:59:52 -0000 1.1
+++ wwn/wn20041015_244.xml 27 Oct 2004 10:23:42 -0000
@@ -185,7 +185,7 @@
<p>We discussed Jason Edmeades plans to work on
Direct3D 9 a few weeks ago (see WWN issue
<a href="http://www.winehq.com/?issue=240#DirectX%209%20Roadmap">#240</a>).
-The concensus seemed to be created a shared library between
+The consensus seemed to be to create a shared library between
Direct3D 8 and Direct3D 9 code given how similar they are.
The other alternative is to copy all the D3D8 code and then
add in the D39D changes. However, this scheme creates
@@ -198,7 +198,7 @@
<p>Patch #1:</p>
<quote who="Jason Edmeades"><p>
-First dx9 related patch - Its mostly a 'feeler' patch to ensure the
+First dx9 related patch - It's mostly a 'feeler' patch to ensure the
direction I am going is not rejected, and as discussed I plan to move the
code into the wined3d library from d3d8, and use it for d3d9.
</p><p>
@@ -210,7 +210,7 @@
Changelog
<ul>
Make a wined3d interface, and generate a wined3d object in the d3d9 create
-method. Make the first (aimple) call implementation into the new wined3d
+method. Make the first (simple) call implementation into the new wined3d
interface (d3d8 change will follow later), and ensure the wined3d8 object
has access to the locks required for later on.</ul>
</p></quote>
@@ -236,7 +236,7 @@
creating utils.c to store them in. Eventually the ones in d3d8 will be
removed but for now just duplicate the code
</p><p>
- BTW Before anyone asks, dont hold your breath for any working d3d9 support -
+ BTW Before anyone asks, don't hold your breath for any working d3d9 support -
This may take months!
</p></quote>
@@ -271,7 +271,7 @@
Well I've almost completed the simple interface, and the logical progression
is onto the hardest!!
</p><p>
-I have also only called the new code from d3d9 for now as its a complete
+I have also only called the new code from d3d9 for now as it's a complete
skeleton to be built on.
</p><p>
Changelog
@@ -288,8 +288,8 @@
<p>Patch #10:</p>
<quote who="Jason Edmeades"><p>
-Fully support (as far as was previously - they havent changed in dx9)
-VertexBuffer and Resource classes and use when called from d3d9 (not d3d8
+Fully support (as far as was previously - they haven't changed in dx9)
+VertexBuffer and Resource classes and use them when called from d3d9 (not d3d8
yet - later!). This also reduces the header includes in all the d3d9
interface, as they will be included from the private header when needed and
it will be easier to remove them when they are no longer needed
@@ -320,10 +320,10 @@
<p>With the D3D9 changes, Jason ran into
some issues sharing code and explained:</p>
<quote who="Jason Edmeades"><p>
- If you havent noticed, I'm trying to port the d3d8 code into wined3d and
+ If you haven't noticed, I'm trying to port the d3d8 code into wined3d and
make it common for use from d3d9, and this is all COM objects. I have come
across something which in theory would enable me to tidy my code simply, but
- I cant see how to make it work in C.
+ I can't see how to make it work in C.
</p><p>
Now I have a class, for example FRED who implements some common functions,
and all the code for it would be in fred.c. I also have a subclass, defined
@@ -349,24 +349,24 @@
defined (I think this is a necessity for emulating subclassing in C?).
</p><p>
Now, obviously if the common funcs need changing I can copy in the code, and
- change the vtbl to have a local override but at the moment I dont need to
+ change the vtbl to have a local override but at the moment I don't need to
(they are mostly stubs even in the d3d8 code today).
</p><p>
- However, doing this fails to compile - It wont allow me to have a vtbl in
+ However, doing this fails to compile - It won't allow me to have a vtbl in
jim.c which includes pointers to functions which are in fred.c, even if I
have extern prototypes defined. Basically this is because array
initialization requires constant values.
</p><p>
- However, this would seem something which is so common - ie inheritence is
+ However, this would seem something which is so common - i.e. inheritence is
used all over the place. How do people handle this? I've looked through a
- few places in the code and cant see how this can be done. I could 'pretend'
+ few places in the code and can't see how this can be done. I could 'pretend'
by initializing the Vtbl as I create the com object and do some LoadLibrary
type dynamic addressing but I really want link time resolution not load time
resolution.
</p><p>
One solution would be to put the common routines in a header file, and
-#include it, but code in headers or #including modules is uaually frowned
-upon! I cant see any sensible way of doing this and I'd rather not do lots
+#include it, but code in headers or #including modules is usually frowned
+upon! I can't see any sensible way of doing this and I'd rather not do lots
of code duplication if avoidable as this common class is used in about 7
other classes!
</p></quote>
@@ -386,13 +386,13 @@
I like the solutions of putting the structures in - thats a neat
way of ensuring consistency...</p><p>
-However, I think the vtbl issue is different - Dont you get away with
+However, I think the vtbl issue is different - Don't you get away with
constructing the vtbl because all subclasses are in the same C part, or
have I missed something?
</p><p>
-BTW I dont want to call cross shared library for inheritance, but I
+BTW I don't want to call cross shared library for inheritance, but I
do want to call cross 'C' part in the same library, so hopefully
-shouldnt need to use the spec file.
+shouldn't need to use the spec file.
</p><p>
Any thoughts? If not, I'll go for forwarding functions - painful,
but not the end of the world.</p></quote>
@@ -429,7 +429,7 @@
However, I'd appreciate a gut check from anyone more
experienced with it than I.
</p><p>
-The fundamental problem is that Powerpoint does a
+The fundamental problem is that PowerPoint does a
timeBeginPeriod(1), trying to set timer resolution
to 1 ms; we steadfastly discard that, and continue
generating time updates and events on a roughly
@@ -439,7 +439,7 @@
Some investigation with a test program shows that most Windows systems
start with a default resolution of 1 ms.
This test program is attached; the 'average' reported
-at the top is the default resolution. Further, Windows seem to
+at the top is the default resolution. Further, Windows seems to
steadfastly ignore any timeBeginPeriod(x)
where x > the current period. I surveyed about 6 systems;
a mix on Win98/Win2k and Win XP. All but one rogue
@@ -479,7 +479,7 @@
on it and had to do the job yourself for a better resolution.
</p><p>
Wine provides 1ms resolution in GetTickCount, ReactOs does also (through
- a quicly browsing of the code) (and the number of cases where winmm
+ a quick browsing of the code) (and the number of cases where winmm
will be run on Windows), so the basic proposition sounds fine.
</p><p>
From an implementation point of view, there's something wrong with it.
@@ -527,7 +527,7 @@
this week:</p>
<quote who="Lars Segerlund"><p>
I was thinking of a silly thing to try, namely
- replacing windows dll's with wines, does anybody
+ replacing windows dll's with wine's, does anybody
have any thoughts about it ?
</p><p>
I just thought about it as a debugging trick I
@@ -541,7 +541,7 @@
directly since apparently it's a great way to
cripple a working system:</p>
<quote who="Steven Edwards"><p>
-It wont work well. I have done it before. The best thing to do is the
+It won't work well. I have done it before. The best thing to do is the
change your dlls search order and use a copy of the Wine dlls built for
Mingw and test them under Windows that way. Certain key processes such
as winlogon are tied to ole32 and friends.</p></quote>
@@ -561,18 +561,18 @@
applications using an undocumented trick on Windows,
<quote who="Steven Edwards">
Under Windows you can just compile the dll using mingw and then drop
-the dll in to the program direct that you want to test. Lets say you
-have a app name foo.exe you can copy the wine comctl32.dll to that
+the dll in to the program direct that you want to test. Let's say you
+have an app named foo.exe you can copy the wine comctl32.dll to that
directory that contains foo.exe and the make a copy of foo.exe and name
the copy foo.exe.local When you create a *.exe.local file it exposes a
hidden hack in Windows that forces it to search the local directory
-first for dlls no matter what the registry setting is. Note this only
+first for dlls no matter what the registry setting is. Note that this only
works for comctl32, shell32, shlwapi, ole32 and a few others. Dlls from
Wine like user32, gdi32, ntdll, kernel32 and friends cannot be loaded
on Windows.</quote></p>
<p>The neat thing about this approach is it lets you
-mix and match native DLL's on Windows to figure out
+mix and match native DLLs on Windows to figure out
potential problems. </p>
</section>
Index: wwn/wn20041022_245.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20041022_245.xml,v
retrieving revision 1.1
diff -u -r1.1 wn20041022_245.xml
--- wwn/wn20041022_245.xml 22 Oct 2004 18:08:27 -0000 1.1
+++ wwn/wn20041022_245.xml 25 Oct 2004 23:29:26 -0000
@@ -93,7 +93,7 @@
</quote>
<p>It looks like our packaging crew has been at work and you can find
-updated versions on Wine on our
+updated versions of Wine on our
<a href="http://www.winehq.com/site/download">download page.</a> It
should also be pointed out that the FreeBSD and Debian packages haven't
been updated in a while. Gerald Pfeifer has reported problems with the
@@ -123,15 +123,15 @@
using winelib. The software contanis one exe file and several dll files. I
would like to keep this structure when moving them to linux. That is, I
still would like to generate several corresponding shared libraries
-(instead of statically linking all files together) in llinux and they will be
+(instead of statically linking all files together) in linux and they will be
loaded at the runtime.
</p><p>
However using winelib tools (winemaker, configure, make) for shared
-library generation, I get unresolved symbols error.
+library generation, I get unresolved symbol errors.
</p><p>
It seems that I have to write a spec file for each dll to import(and
-export) functions provide by other dlls. However, since they all written
-in c++ and what need to be imported can either be class or class method,
+export) functions provided by other dlls. However, since they are all written
+in c++ and what need to be imported can either be a class or a class method,
and parameters can be class either. SO I don't know how to handle this in
spec file. Beside each dll file exports many functions or classes. It
would be tedious to write a lengthy spec file manually.
@@ -209,27 +209,27 @@
}<br />
// this code forces the winebuild to pull-in listed dlls as well</code></ul>
</p><p>
-link every thing the regular wine way this way DLLS load in the right
+link everything the regular wine way this way DLLs load in the right
order, get initialized, and their Windows "import tables", like calls to
kernel32 etc, gets initialized by the loader.
-But (and here is where I'm out of dated) also specify the .so as a link
+But (and here is where I'm out of date) also specify the .so as a link
option to the gcc linker. (ld)
</p><p>
In the old system, before winegcc. One would do -lmydll on the winebuild
-command line. And than in turn -lmydll on the ld command line - for
-resolve of C++ symbols. Now that we use winegcc I'm not sure what is the
+command line. And then in turn -lmydll on the ld command line - to
+resolve the C++ symbols. Now that we use winegcc I'm not sure what is the
switch for additional libs like .so and static libs. Look maybe it is
documented. (Dimi how do you add external libs to a winelib link stage
under winegcc?)
</p><p>
But be careful with this approach. It is an order of a magnitude slower
-on load time than DLL linkage on windows. I came to a dead end with one
-of my projects, where I managed to compile and run every thing but I had
+at load time than DLL linkage on windows. I came to a dead end with one
+of my projects, where I managed to compile and run everything but I had
to revert to PE compiled code because it took my app 4-6 minutes to
load. (PE takes 40 seconds). It was a 1.2 M lines of C++ code divided in
to 37 DLLs + MFC in a dll.
</p><p>
-We have talked about the right solution with Alexander on Wineconf. What
+We have talked about the right solution with Alexander at Wineconf. What
he suggested was:
<ol>
<li> make the __declspec( export ) macro expand to a gcc "section"
@@ -285,10 +285,10 @@
<quote who="Boaz Harrosh"><p>
Most definitely the Linux-shared loader. It took ages. The code is heavy
C++ code full of templates with weak symbols, inline virtual functions,
-and plain horizontal code structure. almost any thing you can do to slow
+and plain horizontal code structure. almost anything you can do to slow
a linker down. The PE export-import tables are much better in this
situation since there is no searching to do. (and no fixups) All
-searching if any is done in link-time. (Run time on the other hand is
+searching if any is done at link-time. (Run time on the other hand is
slower). Actually this app is very bad on Windows too. So we compile it:
"all libraries static" when doing "Release" code. We use DLLs in debug
because the static linking takes 15 minutes.
@@ -297,16 +297,16 @@
Linux. I put up a machine with 2-Gg of ram + setup 2Gg of swap space.
The linker would work for 5-10 minutes than it would hit the swap space.
Memory would go up and up until about 50 minutes where the kernel
-starts to kill every thing in sight including the Linker. MSVC++ does
+starts to kill everything in sight including the Linker. MSVC++ does
not do that, it uses temporary files. Lots of them, to finish the link.
-I did not even try none-debug builds because the all point of the winlib
+I did not even try non-debug builds because the whole point of the winelib
was that Developers could use full screen debugger (Kdevelop) to debug
-Linux problems. If we only have traces and relays than PE is Just good
+Linux problems. If we only have traces and relays then PE is Just good
enough.
</p><p>
Thanks for letting me whine. ;-)
Please do post your results on how to Link the .so on the winegcc
-command line. And also most important if you succeed with prelinking. I
+command line. And also, most importantly, if you succeed with prelinking. I
think that is the best way to go but I'm not a Linux guru and didn't
manage to do it. </p></quote>
@@ -335,9 +335,9 @@
<li>Icon Backgrounds are white instead of grey</li>
<li>All the Icons were drawn a few pixels below where they belong, which
makes them a bit overdrawn by the Icon below.</li>
-<li>The Strings above the seperator were drawn next to the right border
+<li>The Strings above the separator were drawn next to the right border
wich makes them partially overdrawn by the Buttons Icon.
-(Strings and Buttons beyond the seperator are drawn right)</li>
+(Strings and Buttons beyond the separator are drawn right)</li>
</ul></p><p>
If the mouse hovers over the button, the text redraws at the right place
</p></quote>
@@ -440,7 +440,7 @@
where Wine should expect to find the <tt>windows</tt>
directory. Most normal and sane people choose this
to be the default <tt>c:\windows</tt>, but Microsoft
-does allow this to be configuable. Alexandre committed
+does allow this to be configurable. Alexandre committed
the patch except for that one parameter and mentioned
that it's still being used by the registry code.
Dimi wondered where specifically it was being read
More information about the wine-patches
mailing list