WineHQ: Assorted spelling fixes

Francois Gouget fgouget at free.fr
Thu Jul 8 03:50:01 CDT 2004



Changelog:

 * wwn/wn20040521_223.xml
   wwn/wn20040618_227.xml
   wwn/wn20040625_228.xml
   wwn/wn20040701_229.xml
   wwn/interviews/interview_14.xml

   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 --------------
Index: wwn/wn20040521_223.xml
===================================================================
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>
 </p><p>
-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 
 too).
 </p></quote>
 <p>
@@ -192,7 +192,7 @@
 by new distributions.  Marcus Meissner speculated it was part of a
 larger plot,
 <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 ;)
 </quote></p>
 
 </section>
@@ -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).
 </p><p>
   Now play :) 
 </p><p>
@@ -336,7 +336,7 @@
 <dd>
 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 @@
 <a href="http://www.winehq.com/hypermail/wine-devel/2004/05/0291.html">Attached</a>
 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>
 
 <dt>more hints</dt>
 
Index: wwn/wn20040618_227.xml
===================================================================
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 
 <a 
 href="http://www.codeweavers.com/site/about/general/press/?id=20040616">teamed
-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 
 store.</quote></p>
@@ -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,
 <quote who="LinuxDevCenter.com">
-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>
 
 </section>
@@ -143,7 +143,7 @@
  remove this funny mouse-warping-stuff.
 </p><p>
  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></quote>
 
 <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.
 </p><p>
-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:
 <ul><code>
 err:ntdll:RtlpWaitForCriticalSection thread 0x9 timed out waiting for
@@ -342,7 +342,7 @@
 the 'gnome-terminal' with no problem.
 </p><p>
 Again, with the 'fake_windows' provided by the 'WineTools' [2], 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.
 </p><p>
@@ -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 @@
 </p><p>
 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.
 </p></quote>
 
Index: wwn/wn20040625_228.xml
===================================================================
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
 is welcome.</p></quote>
 
@@ -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,
Index: wwn/wn20040701_229.xml
===================================================================
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 @@
 >
 <topic>Build Process</topic>
 
-<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.
 </p><p>
 Once I manually copied the file to the right place Wine worked just fine.
 </p></quote>
@@ -190,7 +190,7 @@
  created on the fly, as it is created when registering the DLLs. 
 </p><p>
  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. 
 </p></quote>
 
@@ -250,16 +250,16 @@
 
  
  A) convert the W-&gt;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 
 </p><p> 
- 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.
  </p></ul><p>
  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. 
 </p><p> 
 
- 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.
 </p><p> 
  
- 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.
 </p><p> 
  
  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></quote> 
 
 
 <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:
 <ul><code>
 dlls/shell32/systray.c: shell32: Shell_NotifyIconW: illegal call to 
@@ -290,15 +290,15 @@
 VerInstallFileA</code></ul></p><p>
 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: 
 <a href="http://cvs.winehq.com/patch.py?id=10692">http://cvs.winehq.com/patch.py?id=10692</a>
 </p></quote>
 
 <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
Index: wwn/interviews/interview_14.xml
===================================================================
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.
 </p><p>
 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 @@
 </p></question>
 
 <answer><p><i>Steven:</i>
-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?"
 </p><p>
@@ -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...
 </p><p>
@@ -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.
 </p><p>
 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 
  compatible license.
 </p></answer>
 
@@ -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 &lt;g&gt;.  
  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).
 </p><p>
@@ -357,7 +357,7 @@
 </p></question>
 
 <answer><p><i>Steven:</i>
-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 mailing list