WineHQ: Assorted spelling fixes
fgouget at free.fr
Thu Jul 8 03:50:01 CDT 2004
Assorted spelling fixes
Francois Gouget fgouget at free.fr http://fgouget.free.fr/
In theory, theory and practice are the same, but in practice they're different.
-------------- next part --------------
RCS file: /var/cvs/lostwages/wwn/wn20040521_223.xml,v
retrieving revision 1.2
diff -u -r1.2 wn20040521_223.xml
--- wwn/wn20040521_223.xml 21 May 2004 16:18:36 -0000 1.2
+++ wwn/wn20040521_223.xml 26 May 2004 09:48:32 -0000
@@ -117,12 +117,12 @@
const*)ptr; This could be harmfull if not declared properly.
Unfortunately, we cannot turn this warning on all the time because some
C functions implementation would always trigger it (strstr for example),
-unless we use intergral values (not pointer) to cast from the const
+unless we use integral values (not pointer) to cast from the const
char* to the returned char*), and this is uglier IMO than the warning we
try to avoid.</li></ol></li></ul>
-Some others warnings could be used as well. Trying also the Intel
-compiler gave lots of interesting warnings (and a tons of not so usefull
+Some other warnings could be used as well. Trying also the Intel
+compiler gave lots of interesting warnings (and a tons of not so useful
@@ -192,7 +192,7 @@
by new distributions. Marcus Meissner speculated it was part of a
<quote who="Marcus Meissner">
- Could it be that Redhat is trying to deliberately break WINE every half year ;)
+ Could it be that Red Hat is trying to deliberately break WINE every half year ;)
@@ -212,7 +212,7 @@
<quote who="Raphael Junqueira"><p>
I'm glad to announce that now (with this little patch) Unreal2 is working
-and playable (it's only slow and i havent seen graphics problems for now).
+and playable (it's only slow and i haven't seen graphics problems for now).
Now play :)
@@ -336,7 +336,7 @@
traditionally, one can kill local systems which are usable within one file only,
i.e. "static". Pretty 20year old unix stuff. The other symbols are referencable
-outside (in .o) and the standard shard linker will put all of them into the
+outside (in .o) and the standard shared linker will put all of them into the
shared library symbol export table. - But now we want two different symbol
flavours, one exported to the same library, the others for the rest of the world.
Perhaps use a linker script to decide later about symbol visibility.<br /></dd>
@@ -347,7 +347,7 @@
are two simple test*.c files and a makefile. The final sharedlib
symbol table contains only test3 after stripping. - using a linker script instead
-of in-source __attribute__ is left as an excercise to the reader.<br /></dd>
+of in-source __attribute__ is left as an exercise to the reader.<br /></dd>
RCS file: /var/cvs/lostwages/wwn/wn20040618_227.xml,v
retrieving revision 1.3
diff -u -r1.3 wn20040618_227.xml
--- wwn/wn20040618_227.xml 18 Jun 2004 15:07:49 -0000 1.3
+++ wwn/wn20040618_227.xml 28 Jun 2004 12:40:33 -0000
@@ -106,8 +106,8 @@
<p>CodeWeavers and Lycoris have
-up</a> to offer a product that bundles CrossOver Office with the Lycrois
-Desktop/LX distribution. <quote who="Codeweavers">
+up</a> to offer a product that bundles CrossOver Office with the Lycoris
+Desktop/LX distribution. <quote who="CodeWeavers">
Lycoris will also begin selling CrossOver Office as a standalone product to
the public via all Lycoris wholesale and retail outlets as well as its Lycoris
@@ -122,7 +122,7 @@
you'll need a licensed copy of Windows to use</quote>. They admit that
CrossOver Office would have been a nice solution,
-CodeWeavers doesn't offer support for Project. If it had, Crossover would have
+CodeWeavers doesn't offer support for Project. If it had, CrossOver would have
been a good choice: it's fast, resource-light, and inexpensive </quote></p>
@@ -143,7 +143,7 @@
remove this funny mouse-warping-stuff.
the mouse feels much better this way, but I am new to wine and maybe I
- missed something important and/or did not remove the mousewarping cleanly.
+ missed something important and/or did not remove the mouse-warping cleanly.
<p>Lionel Ulmer didn't like the patch at all:</p>
@@ -163,7 +163,7 @@
<p>James admitted he didn't know what it was but asked for an
explanation to help understand better:</p>
<quote who="James Dean Anderson"><p>
- There are several things in wine I don't know yet (eg
+ There are several things in wine I don't know yet (e.g.
what does GEN_EVENT do exactly / what are these critical-sections / etc.).
But I think doing mouse-warping in 3 states and across different
functions is much to complicated and while it works great in MaxPayne,
@@ -256,7 +256,7 @@
Because the entirety of Win32 is thread safe you will see this sort of
thing all over the place.
-If a thread deadlocks on a critical section (ie is queued up waiting to
+If a thread deadlocks on a critical section (i.e. is queued up waiting to
enter for a long time) you will see a message like this:
err:ntdll:RtlpWaitForCriticalSection thread 0x9 timed out waiting for
@@ -342,7 +342,7 @@
the 'gnome-terminal' with no problem.
Again, with the 'fake_windows' provided by the 'WineTools' , I can
-install 'Photoshop 7.0' with all the options (included 'ImageReady').
+install 'Photoshop 7.0' with all the options (including 'ImageReady').
The only problem I get is an error creating the icon set, but pressing
'OK' lets the installation process to finish cleanly.
@@ -372,7 +372,7 @@
opened <a href="http://bugs.winehq.org">Bugzilla tickets</a>
on things that didn't work:</p>
<quote who="Mike Kost"><p>
- Here a continuation of my game testing efforts. Same rules still apply in my
+ Here is a continuation of my game testing efforts. Same rules still apply in my
efforts: All games tested are freely available as demos or F/OSS games on the
Internet and they don't work right. I know 20040505 is showing its age, but
there isn't a 200406xx yet.
@@ -444,8 +444,8 @@
This won't be merged so I'm sending it to wine-devel not wine-patches.
Getting it merged is blocking on either somebody giving me example code
-for [un]marshaling an HICON into a block of memory or (best fix) images
-being moved into the wineserver. This is on Ulrichs todo list but if
+for [un]marshalling an HICON into a block of memory or (best fix) images
+being moved into the wineserver. This is on Ulrich's todo list but if
anybody wants to beat him to it, go ahead, it's still some time off yet.
RCS file: /var/cvs/lostwages/wwn/wn20040625_228.xml,v
retrieving revision 1.1
diff -u -r1.1 wn20040625_228.xml
--- wwn/wn20040625_228.xml 24 Jun 2004 22:35:03 -0000 1.1
+++ wwn/wn20040625_228.xml 28 Jun 2004 12:50:25 -0000
@@ -157,7 +157,7 @@
does work. Steven Edwards shared a new version this week:</p>
<quote who="Steven Edwards"><p>
This a replacement control panel that was developed for ReactOS until
-the Control Panel namespace in Shell32 is done. Its far from perfect
+the Control Panel namespace in Shell32 is done. It's far from perfect
but seems to be a little better than the older implementation. Feedback
@@ -351,7 +351,7 @@
<li> cleanup of naming conventions. Things shared with the
public header *always* start with MSVCRT_</li>
<li> stuff that's private, doesn't start with MSVCRT_
- From this two rules follows that a symbol starts
+ From these two rules follows that a symbol starts
with MSVCRT_ if and only if it's shared with the
public headers, where it appears without MSVCRT_</li>
<li> most private functions start with msvcrt_ now,
RCS file: /var/cvs/lostwages/wwn/wn20040701_229.xml,v
retrieving revision 1.1
diff -u -r1.1 wn20040701_229.xml
--- wwn/wn20040701_229.xml 1 Jul 2004 22:39:57 -0000 1.1
+++ wwn/wn20040701_229.xml 7 Jul 2004 15:38:04 -0000
@@ -88,7 +88,7 @@
-<p>Mike Hearn found a problem with recent Mandrake RPM's:</p>
+<p>Mike Hearn found a problem with recent Mandrake RPMs:</p>
<quote who="Mike Hearn"><p>
Ivans comment that the Mandrake RPMs didn't work on Red Hat/Fedora
@@ -98,7 +98,7 @@
It turns out the reason they don't work on Fedora is because they don't
work at all - wine.inf is in /usr/share/doc/wine-20040615 which is wrong,
it needs to be in /usr/share/wine. As this file is in the wrong place Wine
-refuses to start on a new users account.
+refuses to start on a new user account.
Once I manually copied the file to the right place Wine worked just fine.
@@ -190,7 +190,7 @@
created on the fly, as it is created when registering the DLLs.
Before we go any further, I'd like to ask everybody to contribute their
- thoughts/requirements/desires so that we get a conprehensive view of
+ thoughts/requirements/desires so that we get a comprehensive view of
the problem we are trying to solve.
@@ -250,16 +250,16 @@
A) convert the W->A calls in the wide-char functions to A->W calls in
-the asci functions and implement the wide-char functions instead, or
+the ascii functions and implement the wide-char functions instead, or
- B) implement both asci and wide-char functions separately ie asci
-functions only call asci functions etc.
+ B) implement both ascii and wide-char functions separately i.e. ascii
+functions only call ascii functions etc.
If we are to choose plan A, I have seen several different methods of
-converting asci to wide-char, and I am wondering which method is best.
+converting ascii to wide-char, and I am wondering which method is best.
- I would have to argue that implementing both the asci functions and
+ I would have to argue that implementing both the ascii functions and
wide-char functions separately would be the most efficient way to solve
the W->A problem. Throughout all the wine libs, many conversion calls
are being made from W->A and A->W, when most of these calls could be
@@ -268,20 +268,20 @@
speed would also increase.
- There are a couple snags when it comes to implementing asci and
+ There are a couple snags when it comes to implementing ascii and
wide-char functions independently, but that can be discussed later.
If I'm totally off the mark, let me know, and if there are other jobs I
could be doing, let me know as well because I would like to contribute,
-but I'm not exactly sure what to do yet. Thankyou for your time.
+but I'm not exactly sure what to do yet. Thank you for your time.
<p>Marcelo Duarte advised:</p>
<quote who="Marcelo Duarte"><p>
I did not check your code, but each situation has its reason and you
-decide which you will be better.
+decide which will be better.
I suggest you to start converting something simple, like:
dlls/shell32/systray.c: shell32: Shell_NotifyIconW: illegal call to
@@ -290,15 +290,15 @@
When I made one of these conversions, I chose "<tt>dlls/shell32/shlexec.c:
shell32: ShellExecuteExW: illegal call to ShellExecuteExAand</tt>" very
-laborious and was complicated. You can give one looked at as I made:
+laborious and was complicated. You can give a look at one I made:
<p>Steven Edwards also had some suggestions,
<quote who="Steven Edwards">
-Welcome! I dont think it matters from a performance point of view. From
+Welcome! I don't think it matters from a performance point of view. From
my reading of documentation regarding Windows NT it seems they have
-abut a 20% performance hit on the ASCII calls vs the Unicode calls. I
+about a 20% performance hit on the ASCII calls vs the Unicode calls. I
think that they implement both ASCII and Unicode rather than have ASCII
call the unicode functions. (This is due to the fact that they had a
semi-share source base with Win9x). Most of Wine just has the A
RCS file: /var/cvs/lostwages/wwn/interviews/interview_14.xml,v
retrieving revision 1.1
diff -u -r1.1 interview_14.xml
--- wwn/interviews/interview_14.xml 25 May 2004 17:18:45 -0000 1.1
+++ wwn/interviews/interview_14.xml 26 May 2004 09:49:29 -0000
@@ -78,13 +78,13 @@
initial port to the ReactOS build system and I spent the better part of a year
working with Alexandre to get those changes merged back in to WineHQ in a
proper way. I would say that because of the method we have used in porting Wine
-to Mingw we are able to make use 75% of the Wine code and maybe even more as
+to Mingw we are able to make use of 75% of the Wine code and maybe even more as
Wine evolves from the Win16/Win9x design to the Win32/NT design.
Currently in ReactOS the port of Wine involves building most of the Wine
components that sit above the core Win32 subsystem of gdi32/user32 and
kernel32/ntdll. From these modules we pick and chose parts of code that are
-not too dependant on direct Unix or Wineserver calls and do not need X11
+not too dependent on direct Unix or Wineserver calls and do not need X11
functions. Anything else such as the common controls, common dialogs and
shell32 interface is mainly just a recompile for us. The simplest way to tell
if we can share a module in Wine is to see if that module or part of source
@@ -148,7 +148,7 @@
-It's a good question. Its also one that I hear quite a lot so if you ever
+It's a good question. It's also one that I hear quite a lot so if you ever
meet me at a tradeshow by the end of the day I tend to be in a bad mood and
just answer by saying, "Why do you want to clone Unix?"
@@ -158,7 +158,7 @@
free clones with FreeBSD and Linux for quite a while so it's just a matter of
the market evolving to answer that need. I suspect Microsoft will take my
words one day to say that Longhorn is going to be the hydrogen engine of
-computing but I think its free software that is the unlimited fuel. Microsoft
+computing but I think it's free software that is the unlimited fuel. Microsoft
can't provide that unless they reform their business and that's what ReactOS is
all about. We are a <u>react</u>ion to the state of the market. I myself am a
very free market leaning conservative so the idea of ReactOS is a good fit for
@@ -182,7 +182,7 @@
Yes it's quite a bit of work but I really think most of the hard work in
cloning ntoskrnl has been done already. Most of our support for the Windows NT
driver model is in place. While it needs some expansion to code the Windows
- Driver Model of 2000 and XP, it's not that major of a enhancement. I would
+ Driver Model of 2000 and XP, it's not that major of an enhancement. I would
really like to see this happen sometime soon but ReactOS won't start getting
enough users for the driver issues to matter until we have proper networking...
@@ -195,7 +195,7 @@
network code in netapi32 and iphlpapi. The ReactOS networking works (large
parts were ripped from Linux) but it does not conform to the Windows NT model
for networking with the NDIS and TDI layers correctly. Plugging the holes and
- making it act more like Windows networking what Art and the
+ making it act more like Windows networking is what Art and the
rest of the ReactOS Network team has been focused on.
My plan is to use ReactOS fulltime for my primary OS within the year.
@@ -234,7 +234,7 @@
the quality of both Wine and ReactOS while making it easier for Windows
developers to test Wine components with their apps in the Microsoft Debugger.
The only other thing is, I do wish the TransGaming guys would get on the ball
-and license their work as LGPL. But its their right to keep working off of the
+and license their work as LGPL. But it's their right to keep working off of the
X11 fork and pick and choose LGPL modules as they go along and I have to
support them in that. As compared to other projects I have done some work
with, I think Wine is one of the best, otherwise I would not still be around.
@@ -256,7 +256,7 @@
replacement in ReactOS but it cannot be shipped with Wine as it is GPL rather
than LGPL. At some point we are going to have to develop replacement
components for everything in Windows so if there is a program that Wine needs
- and ReactOS implements it then I will try to make sure its released under a
+ and ReactOS implements it then I will try to make sure it's released under a
@@ -276,7 +276,7 @@
to do more "paying" work again on the Linux side I find myself using Windows
less and less again, even for my ReactOS work. Some of the ReactOS developers
including myself also put a good bit of work into making ReactOS self-hosting
- with mingw-gcc. It is possible to rebuild ReactOS on ReactOS although its
+ with mingw-gcc. It is possible to rebuild ReactOS on ReactOS although it's
very slow and without networking you can't update your source tree. Once we get
the networking part nailed down I may become one of the first people to
setup a dedicated ReactOS development box.
@@ -306,7 +306,7 @@
out the Win16 and Win32 stuff is still an ongoing project that will be done
around the same time Wine 1.0 is released <g>.
The hard part, at least for me, is when we have to totally rewrite something
- because it depends on a internal Wine function or is a Win32 function
+ because it depends on an internal Wine function or is a Win32 function
implemented on top of Win16 (Wineism) or a Win32 function that depends on the
native Unix API (Unixisms).
@@ -357,7 +357,7 @@
-I really think we need to make a effort to get everything we can building
+I really think we need to make an effort to get everything we can building
under Microsoft Visual Studio. I believe in this so much that I'm tempted to
add this to the Wine 1.0 TODO list. Once we make it easy for the Windows
developers to test their applications with Wine modules they are more
More information about the wine-patches