[WINEHQ] Assorted spelling fixes
Francois Gouget
fgouget at free.fr
Mon Jun 20 05:00:19 CDT 2005
Changelog:
* templates/en/status_multimedia.template
templates/en/status_wine.template
wwn/wn19991018_13.xml
wwn/wn19991108_16.xml
wwn/wn20000515_43.xml
wwn/wn20001016_65.xml
wwn/wn20010506_94.xml
wwn/wn20010526_96.xml
wwn/wn20010802_101.xml
wwn/wn20010912_103.xml
wwn/wn20011007_105.xml
wwn/wn20011102_107.xml
wwn/wn20020213_115.xml
wwn/wn20020509_122.xml
wwn/wn20020530_124.xml
wwn/wn20020906_134.xml
wwn/wn20021025_141.xml
wwn/wn20021115_144.xml
wwn/wn20021206_147.xml
wwn/wn20021213_148.xml
wwn/wn20030117_153.xml
wwn/wn20030207_156.xml
wwn/wn20030228_159.xml
wwn/wn20030321_162.xml
wwn/wn20030502_168.xml
wwn/wn20030509_169.xml
wwn/wn20030523_171.xml
wwn/wn20030627_176.xml
wwn/wn20030704_177.xml
wwn/wn20030725_180.xml
wwn/wn20030829_185.xml
wwn/wn20031010_191.xml
wwn/wn20031031_194.xml
wwn/wn20031205_199.xml
wwn/wn20031212_200.xml
wwn/wn20031219_201.xml
wwn/wn20040116_205.xml
wwn/wn20040203_208.xml
wwn/wn20040326_216.xml
wwn/wn20040402_217.xml
wwn/wn20040827_237.xml
wwn/wn20041015_244.xml
wwn/wn20041126_250.xml
wwn/wn20050225_263.xml
wwn/wn20050304_264.xml
wwn/wn20050422_271.xml
wwn/wn20050503_272.xml
wwn/wn20050603_277.xml
wwn/wn20050610_278.xml
wwn/wn20050617_279.xml
wwn/interviews/interview_10.xml
Francois Gouget <fgouget at free.fr>
Assorted spelling fixes
--
Francois Gouget fgouget at free.fr http://fgouget.free.fr/
The nice thing about meditation is that it makes doing nothing quite respectable
-- Paul Dean
-------------- next part --------------
Index: templates/en/status_multimedia.template
===================================================================
RCS file: /var/cvs/lostwages/templates/en/status_multimedia.template,v
retrieving revision 1.8
diff -u -p -r1.8 status_multimedia.template
--- templates/en/status_multimedia.template 19 Jan 2005 16:58:13 -0000 1.8
+++ templates/en/status_multimedia.template 20 Jun 2005 09:21:09 -0000
@@ -159,7 +159,7 @@
<td class="pct50">50% complete ( Only decoding is supported ) </td>
<td>Mike McCormack</td>
</tr>
- <td colspan="5"><strong>Multimedia DLL's</strong></td>
+ <td colspan="5"><strong>Multimedia DLLs</strong></td>
<tr>
<td>avicap32.dll</td>
<td class="adequate"><a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/w98ddk/hh/w98ddk/mmedia_4v91.asp">Video Capture Reference</a></td>
Index: templates/en/status_wine.template
===================================================================
RCS file: /var/cvs/lostwages/templates/en/status_wine.template,v
retrieving revision 1.20
diff -u -p -r1.20 status_wine.template
--- templates/en/status_wine.template 7 Mar 2005 21:14:42 -0000 1.20
+++ templates/en/status_wine.template 20 Jun 2005 09:20:44 -0000
@@ -127,9 +127,9 @@
<td>Native DLL overrides</td>
<td class="good"><a href="http://www.winehq.org/site/docs/wine-user/config-dll">Good</a></td>
<td><a href="{$root}/site/?issue=46#Feature:%20DLL%20overrides%20by%20Ove%20K%E5ven">#46</a>,
- <a href="{$root}/site/?issue=134#Native%20vs.%20Builtin%20DLL's">#134</a>,
- <a href="{$root}/site/?issue=180#Configuring%20Native%20OLE%20DLL's">#180</a>,
- <a href="{$root}/site/?issue=200#Using%20Native%20DLL's%20in%20a%20Winelib%20App">#200</a></td>
+ <a href="{$root}/site/?issue=134#Native%20vs.%20Builtin%20DLLs">#134</a>,
+ <a href="{$root}/site/?issue=180#Configuring%20Native%20OLE%20DLLs">#180</a>,
+ <a href="{$root}/site/?issue=200#Using%20Native%20DLLs%20in%20a%20Winelib%20App">#200</a></td>
<td class="pct95">95% complete</td>
<td></td>
</tr>
@@ -406,7 +406,7 @@
<td>Wine Porting Tool (winemaker)</td>
<td class="outdated">Outdated</td>
<td><a href="{$root}/site/?issue=66#A%20tool%20to%20help%20Wine%20making">#66</a>,
- <a href="{$root}/site/?issue=101#Using%20Native%20DLL's">#101</a>,
+ <a href="{$root}/site/?issue=101#Using%20Native%20DLLs">#101</a>,
<a href="{$root}/site/?issue=189#Winelib:%20Advantages%20and%20Disadvantages">#189</a>,
<a href="{$root}/site/?issue=203#Winelib%20Porting%20Report">#203</a>,</td>
<td class="pct60">60% complete</td>
Index: wwn/wn19991018_13.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn19991018_13.xml,v
retrieving revision 1.2
diff -u -p -r1.2 wn19991018_13.xml
--- wwn/wn19991018_13.xml 18 Jul 2003 20:50:50 -0000 1.2
+++ wwn/wn19991018_13.xml 20 Jun 2005 01:53:33 -0000
@@ -85,9 +85,9 @@ guess the version a program needs.
<ul>
-<li />First the version detection looks onto the native dll's provided.
+<li />First the version detection looks onto the native dlls provided.
This is necessary since most programs are able to run on
-win95/98 as well as on nt4. The native dll's are not that tolerant.
+win95/98 as well as on nt4. The native dlls are not that tolerant.
<li />The most important information is the subsystem version (pe-exe-
header). If this version is >=4 the executable is a 'real' (not win32s)
@@ -95,9 +95,9 @@ program. This value is constant for all
windows (win95/98/nt4/nt5).
<li />Unfortunately there is no documented way to detect if a given set
-of native dll's and a program is a win95/98 (ascii) or nt4/5
+of native dlls and a program is a win95/98 (ascii) or nt4/5
(unicode) version of the program. I solved this by looking into the
-import-table of the native dll's. All system-dll's (comctl32, comdlg32,
+import-table of the native dlls. All system-dlls (comctl32, comdlg32,
shell32, ole32) are importing the ntdll. Any try to distinct by any
fields in the pe header or by the version resource does not work.
Index: wwn/wn19991108_16.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn19991108_16.xml,v
retrieving revision 1.2
diff -u -p -r1.2 wn19991108_16.xml
--- wwn/wn19991108_16.xml 18 Jul 2003 20:50:50 -0000 1.2
+++ wwn/wn19991108_16.xml 20 Jun 2005 01:54:01 -0000
@@ -42,7 +42,7 @@ going on around Wine (the Un*x Windows e
Mel Gorman reported some issues while using WineLib:
<quote who="Mel Gorman">I'm writing a plugin for <a href="http://www.xmms.org/">XMMS</a> for
-playing VQF's using WineLIB and windows DLL's. I had a nice amount of
+playing VQF's using WineLIB and windows DLLs. I had a nice amount of
success in getting a plugin to work but I had to separate XMMS and the
plugin into two separate programs which is kruddy as hell. When I try
to merge them together, there is segfaults every direction when the
Index: wwn/wn20000515_43.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20000515_43.xml,v
retrieving revision 1.3
diff -u -p -r1.3 wn20000515_43.xml
--- wwn/wn20000515_43.xml 16 Dec 2003 17:09:26 -0000 1.3
+++ wwn/wn20000515_43.xml 20 Jun 2005 09:22:00 -0000
@@ -55,7 +55,7 @@ This change impacted Michael Cardenas' p
<quote who="Michael Cardenas">
I just picked up the latest cvs tree and made the necessary changes to
my project for the dll separation. To get my project to link I had to
-explicitly link a number of dll's including:
+explicitly link a number of dlls including:
<ul>
<li />libcomdlg32.so
<li />libcomctl32.so
@@ -156,11 +156,11 @@ of it (as it's done with XFree, KDE...)
Michael then explained that Deneba ships canvas as an executable +
libcv7.so. Here libcv.so is just libwine with the name and the soname
changed (in the configure scripts...), <quote who="Michael Cardenas">
-I think that having a ton of little dll's all over for wine is probably not
+I think that having a ton of little dlls all over for wine is probably not
good for developers since it will introduce a bunch of linking problems,
and cause more hassles creating installers for new apps and worrying about
.so files loading properly, etc. This approach would introduce a benefit
-though, because we won't have to include all the extra dll's in our
+though, because we won't have to include all the extra dlls in our
distribution, which will allow for smaller installers and faster downloads.
It also allows us to fix a problem in a particular dll and distribute just
that dll.
Index: wwn/wn20001016_65.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20001016_65.xml,v
retrieving revision 1.5
diff -u -p -r1.5 wn20001016_65.xml
--- wwn/wn20001016_65.xml 16 Dec 2003 17:09:27 -0000 1.5
+++ wwn/wn20001016_65.xml 20 Jun 2005 01:56:11 -0000
@@ -334,7 +334,7 @@ applications (corporate user).
<p />
The GXExplorer works quite good with wine but you have to use some
-native dll's since it's using quite a bit of the ole stuff. Last time
+native dlls since it's using quite a bit of the ole stuff. Last time
I tried (some months ago) I had to use ole* dlls and many registry
keys from a native windows. This program is a good test for the build
in shell32, comctl32 and ole* since it uses many advanced features.
Index: wwn/wn20010506_94.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20010506_94.xml,v
retrieving revision 1.7
diff -u -p -r1.7 wn20010506_94.xml
--- wwn/wn20010506_94.xml 28 Mar 2005 16:22:18 -0000 1.7
+++ wwn/wn20010506_94.xml 20 Jun 2005 01:56:54 -0000
@@ -236,7 +236,7 @@ the FreeType header files.</p>
such an error? </p></quote>
<p>Eric Pouech thought the problem was a loader issue. At some point the
- native DLL's weren't being registered most likely because Wine's
+ native DLLs weren't being registered most likely because Wine's
initialization functions weren't being called. </p>
<p>Francois Gouget was digging through configure.in and noticed that
Index: wwn/wn20010526_96.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20010526_96.xml,v
retrieving revision 1.6
diff -u -p -r1.6 wn20010526_96.xml
--- wwn/wn20010526_96.xml 15 Jul 2004 18:41:41 -0000 1.6
+++ wwn/wn20010526_96.xml 20 Jun 2005 01:58:02 -0000
@@ -323,7 +323,7 @@ this problem has gone away (using Notes
<section
- title="Exposing Non-Windows Functions from DLL's"
+ title="Exposing Non-Windows Functions from DLLs"
subject="Question on exposing non-windows functions from dlls..."
archive="http://www.winehq.org/hypermail/wine-devel/2001/05/0126.html"
posts="7"
Index: wwn/wn20010802_101.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20010802_101.xml,v
retrieving revision 1.6
diff -u -p -r1.6 wn20010802_101.xml
--- wwn/wn20010802_101.xml 24 Mar 2004 16:18:47 -0000 1.6
+++ wwn/wn20010802_101.xml 20 Jun 2005 01:58:24 -0000
@@ -50,8 +50,8 @@ changes:</p>
<section
- title="Using Native DLL's"
- subject="native dll's"
+ title="Using Native DLLs"
+ subject="native dlls"
archive="http://www.winehq.org/hypermail/wine-devel/2001/07/0207.html"
posts="4"
startdate="07/25/2001"
Index: wwn/wn20010912_103.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20010912_103.xml,v
retrieving revision 1.7
diff -u -p -r1.7 wn20010912_103.xml
--- wwn/wn20010912_103.xml 20 May 2005 17:53:24 -0000 1.7
+++ wwn/wn20010912_103.xml 20 Jun 2005 01:59:25 -0000
@@ -119,7 +119,7 @@ a page</a> dedicated to Wine. </p>
<p>Travis Michielsen posted a message requesting some ideas on
implementing the advapi32.dll - the cryptography API that is
being used in more and more applications. Currently Microsoft
-splits this into several small DLL's and Travis was wondering
+splits this into several small DLLs and Travis was wondering
if he should use the same architecture or simply create one
monolithic DLL. One large DLL would prevent using the smaller
native versions, but it would also be easier to implement using
Index: wwn/wn20011007_105.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20011007_105.xml,v
retrieving revision 1.5
diff -u -p -r1.5 wn20011007_105.xml
--- wwn/wn20011007_105.xml 28 Mar 2005 16:22:18 -0000 1.5
+++ wwn/wn20011007_105.xml 20 Jun 2005 02:00:03 -0000
@@ -188,7 +188,7 @@ and suggested:</p>
enddate="10/03/2001"
>
-<p>Uwe Bonnes was having some problems with dll's loading. He provided
+<p>Uwe Bonnes was having some problems with dlls loading. He provided
some debugging info and explained:</p>
<quote who="Uwe Bonnes"><p>
some programm using a dll with Borland style imports crashes if the dll is
Index: wwn/wn20011102_107.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20011102_107.xml,v
retrieving revision 1.6
diff -u -p -r1.6 wn20011102_107.xml
--- wwn/wn20011102_107.xml 24 Mar 2004 16:12:19 -0000 1.6
+++ wwn/wn20011102_107.xml 20 Jun 2005 02:00:25 -0000
@@ -359,7 +359,7 @@ windoze APIs.
For example, KDX implements it's own GUI, it does not use the windoze API
for that. Also, KDX even implements it's own graphics routines, it does
not use the windoze GDI functions (except for the final step of getting
-the images onto the screen). KDX loads no obscure DLL's, it's just a
+the images onto the screen). KDX loads no obscure DLLs, it's just a
single .exe file. It does not use MDI or any crap like that. It does
not access the registry. It does not use MFC. So I think it would be
much easier for WINE than your average windoze program.
Index: wwn/wn20020213_115.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20020213_115.xml,v
retrieving revision 1.9
diff -u -p -r1.9 wn20020213_115.xml
--- wwn/wn20020213_115.xml 20 May 2005 17:57:50 -0000 1.9
+++ wwn/wn20020213_115.xml 20 Jun 2005 02:00:58 -0000
@@ -894,7 +894,7 @@ topics with his name or CodeWeavers.</p>
<section
- title="MFC DLL's"
+ title="MFC DLLs"
subject="Greetings and a question"
topic1="Commercial Development"
archive="http://www.winehq.org/hypermail/wine-devel/2002/02/0336.html"
Index: wwn/wn20020509_122.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20020509_122.xml,v
retrieving revision 1.10
diff -u -p -r1.10 wn20020509_122.xml
--- wwn/wn20020509_122.xml 7 Mar 2005 21:17:11 -0000 1.10
+++ wwn/wn20020509_122.xml 20 Jun 2005 02:01:21 -0000
@@ -373,7 +373,7 @@ run and the OS is self-hosting using
<a href="http://www.mingw.org">mingw</a>. The plan is to
use Wine as the Win32 subsystem once DLL separation is
complete. The main obstacles are:
-<ul><li />Building the DLL's under Mingw
+<ul><li />Building the DLLs under Mingw
<li />DLL separation - ReactOS can't use internal
wineserver functions
<li />Interfacing ReactOS and the Wine debugger
Index: wwn/wn20020530_124.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20020530_124.xml,v
retrieving revision 1.7
diff -u -p -r1.7 wn20020530_124.xml
--- wwn/wn20020530_124.xml 24 Mar 2004 16:18:47 -0000 1.7
+++ wwn/wn20020530_124.xml 20 Jun 2005 02:01:50 -0000
@@ -500,7 +500,7 @@ Well, to some degree, not the 3 RMS crit
I would think people interested in 3D and 3D games and development.
I think it is pretty obvious that you are not going to satisfy a
hard-core gamer, since there is no support for copyright protection
-and most of the tweaking is manual (downloading dll's for example).
+and most of the tweaking is manual (downloading dlls for example).
I see such a package for enthusiasts that want to check the
state-of-the-art in gaming without having to install windows (I
recently checked the SoF2 demo with this, even though the game was
Index: wwn/wn20020906_134.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20020906_134.xml,v
retrieving revision 1.7
diff -u -p -r1.7 wn20020906_134.xml
--- wwn/wn20020906_134.xml 16 Dec 2004 23:00:57 -0000 1.7
+++ wwn/wn20020906_134.xml 20 Jun 2005 02:03:02 -0000
@@ -232,7 +232,7 @@ patches to ReWind, so it's considered LG
<section
- title="Native vs. Builtin DLL's"
+ title="Native vs. Builtin DLLs"
subject="Press: Running Windows Games with WineX 2.1"
archive="http://www.winehq.org/hypermail/wine-devel/2002/08/0430.html"
posts="5"
@@ -241,8 +241,8 @@ patches to ReWind, so it's considered LG
<topic>Documentation</topic>
<p>
Jas Sandys-Lumsdaine wanted to know exactly how much better or
-worse it was to use native Windows DLL's instead of the corresponding
-built-in ones. Francous Gouget quickly explained,
+worse it was to use native Windows DLLs instead of the corresponding
+built-in ones. Francois Gouget quickly explained,
<quote who="Francois Gouget">
This very much depends on the application. Some application will work
@@ -252,7 +252,7 @@ built-in ones. Francous Gouget quickly
native libraries (e.g. from a Windows partition) than with the builtin
ones.</quote>
</p>
-<p>Jas still didn't understand why native DLL's wouldn't always
+<p>Jas still didn't understand why native DLLs wouldn't always
work:</p>
<quote who="Jas Sandys-Lumsdaine"><p>
Assuming native Windows dlls etc are correct (by definition of what Wine's
Index: wwn/wn20021025_141.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20021025_141.xml,v
retrieving revision 1.11
diff -u -p -r1.11 wn20021025_141.xml
--- wwn/wn20021025_141.xml 16 Dec 2004 23:00:57 -0000 1.11
+++ wwn/wn20021025_141.xml 20 Jun 2005 02:03:54 -0000
@@ -755,7 +755,7 @@ need to fetch the real libc handle? It
be enough. </quote></p>
<p>Ove thought it might not be enough and wondered about other
-DLL's breaking it,
+DLLs breaking it,
<quote who="Ove Kaaven">
I'm not sure, what happens if opengl32.dll.so or d3d8.dll.so links against
a libGL.so that links against libpthread.so that overrides fork() ? Would
Index: wwn/wn20021115_144.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20021115_144.xml,v
retrieving revision 1.8
diff -u -p -r1.8 wn20021115_144.xml
--- wwn/wn20021115_144.xml 16 Dec 2003 17:09:27 -0000 1.8
+++ wwn/wn20021115_144.xml 20 Jun 2005 02:04:25 -0000
@@ -390,7 +390,7 @@ yuv accel and direct rendering (yes, it
and all the mplayer features, filters etc sounds much better than running
the original slow qt5 player in wine window :)
</p></quote>
-<p>The work involved snagging some DLL's from QuickTime 5 and the
+<p>The work involved snagging some DLLs from QuickTime 5 and the
SDK, using wine-20020310, and other messy stuff. The mplayer folks
hope to clean this up soon.</p>
Index: wwn/wn20021206_147.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20021206_147.xml,v
retrieving revision 1.10
diff -u -p -r1.10 wn20021206_147.xml
--- wwn/wn20021206_147.xml 20 May 2005 17:57:50 -0000 1.10
+++ wwn/wn20021206_147.xml 20 Jun 2005 02:07:09 -0000
@@ -327,7 +327,7 @@ require it - but there are a few points
<li> It is C++. So far, all of WINEs dlls are plain C. Is this really a
rule, or just a result of the current areas of focus? I can't really
de-C++ khtml and co, but I'm unsure as to whether it's okay to add a
-requirement for a working C++ compile environment on core dll's.</li>
+requirement for a working C++ compile environment on core dlls.</li>
<li> It is somewhat big, several megabytes of new code. Hopefully I can chop
it down after removing a lot of the unneeded KDE and QT code I currently
@@ -551,14 +551,14 @@ C></code></ul>
</section><section
- title="Self-Registering DLL's"
- subject="Registering DLL's"
+ title="Self-Registering DLLs"
+ subject="Registering DLLs"
archive="http://www.winehq.org/hypermail/wine-devel/2002/12/0150.html"
posts="5"
startdate="12/04/2002"
>
<topic>Patches</topic>
-<p>Jeff Smith had a question about making DLL's enter their
+<p>Jeff Smith had a question about making DLLs enter their
own registry entries:</p>
<quote who="Jeff Smith"><p>
I was looking at entry C.5 of the 0.9 Todo list:
@@ -621,7 +621,7 @@ just start submitting patches, then.
</section><section
title="Configuring Wine"
- subject="Registering DLL's"
+ subject="Registering DLLs"
archive="http://www.winehq.org/hypermail/wine-devel/2002/12/0150.html"
posts="2"
startdate="12/04/2002"
Index: wwn/wn20021213_148.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20021213_148.xml,v
retrieving revision 1.8
diff -u -p -r1.8 wn20021213_148.xml
--- wwn/wn20021213_148.xml 16 Dec 2003 17:09:27 -0000 1.8
+++ wwn/wn20021213_148.xml 20 Jun 2005 02:07:25 -0000
@@ -426,7 +426,7 @@ of rolling its own?
<section
title="Registry Editors / Configuration Programs"
- subject="Registering DLL's"
+ subject="Registering DLLs"
archive="http://www.winehq.org/hypermail/wine-devel/2002/12/0150.html"
posts="13"
startdate="12/04/2002"
Index: wwn/wn20030117_153.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030117_153.xml,v
retrieving revision 1.9
diff -u -p -r1.9 wn20030117_153.xml
--- wwn/wn20030117_153.xml 24 May 2005 14:44:28 -0000 1.9
+++ wwn/wn20030117_153.xml 20 Jun 2005 09:22:47 -0000
@@ -300,7 +300,7 @@ upstream code is released meer weeks lat
</p><p>
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
+impact of stubbing the MS dlls into khtml.dll/kjs.dll ecetra, instead of
replicating the exports more natively.
</p></quote>
Index: wwn/wn20030207_156.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030207_156.xml,v
retrieving revision 1.10
diff -u -p -r1.10 wn20030207_156.xml
--- wwn/wn20030207_156.xml 27 Jan 2005 15:21:25 -0000 1.10
+++ wwn/wn20030207_156.xml 20 Jun 2005 02:07:57 -0000
@@ -529,7 +529,7 @@ let me know.
</p></quote>
<p>There's definitely a lot of useful data in there. But for now
-it just has what DLL's are being imported by another DLL. Several
+it just has what DLLs are being imported by another DLL. Several
people had ideas for how to represent it. Dimi Paun suggested: </p>
<quote who="Dimitrie Paun"><p>
Index: wwn/wn20030228_159.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030228_159.xml,v
retrieving revision 1.6
diff -u -p -r1.6 wn20030228_159.xml
--- wwn/wn20030228_159.xml 16 Dec 2003 17:09:27 -0000 1.6
+++ wwn/wn20030228_159.xml 20 Jun 2005 02:08:14 -0000
@@ -264,7 +264,7 @@ than that guy, since I don't have to use
hasn't come up much lately because a lot of it is done.
Some really hard parts remain but it's not as high a priority as
it once was. (Those really hard parts would include the x11drv,
-user32, gdi32, and kernel32 DLL's.) Anyway, he wondered about
+user32, gdi32, and kernel32 DLLs.) Anyway, he wondered about
x11drv:</p>
<quote who="David Fraser"><p>
Index: wwn/wn20030321_162.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030321_162.xml,v
retrieving revision 1.5
diff -u -p -r1.5 wn20030321_162.xml
--- wwn/wn20030321_162.xml 26 Jan 2004 22:57:41 -0000 1.5
+++ wwn/wn20030321_162.xml 20 Jun 2005 02:09:18 -0000
@@ -251,22 +251,22 @@ more like saws and hammers.<g>.</q
enddate="03/17/2003"
>
<topic>Utilities</topic>
-<p>Brad Campbell needed some help determining what DLL's were
+<p>Brad Campbell needed some help determining what DLLs were
imported by his app:</p>
<quote who="Brad Campbell"><p>
I'm using wine in a small control system to run a gui win32 program.
-I had an idea that I could determine what dll's this program used and
+I had an idea that I could determine what dlls this program used and
only including the wine.dll.so files that were required to run this program.
</p><p>
I started by doing a strings on the .exe file and using that to
determine which .dlls it referenced. I thought I could use the same
-process to determine which dll's were then referenced by the dll's the
-.exe pulled in. Plus including the core dll's by default.
+process to determine which dlls were then referenced by the dlls the
+.exe pulled in. Plus including the core dlls by default.
</p><p>
Am I missing something, or will this work ?
</p><p>
I'm in the process of developing a batch file to do it for me, is there
-a more accurate way of determining which dll's a dll references than
+a more accurate way of determining which dlls a dll references than
doing a text search for dll names in the binary?
</p></quote>
@@ -288,7 +288,7 @@ yet, not your case I guess).
</p></quote>
<p>Winedump worked fine on Brad's executable, but he wasn't able to
-run it on Wine's own DLL's. Since most DLL's import other ones
+run it on Wine's own DLLs. Since most DLLs import other ones
he couldn't determine the minimum ones he needed. Rather than using
+loaddll he thought it might be better to just manually check the
imports in each DLL makefile. Dmitry Timoshkov offered another
Index: wwn/wn20030502_168.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030502_168.xml,v
retrieving revision 1.6
diff -u -p -r1.6 wn20030502_168.xml
--- wwn/wn20030502_168.xml 20 May 2005 17:57:50 -0000 1.6
+++ wwn/wn20030502_168.xml 20 Jun 2005 09:23:20 -0000
@@ -141,7 +141,7 @@ send patches, I hope they would be integ
</p></quote>
<p>Pierre then went on to list some configuration issues he ran
-into and what appeared to be a problem with DLL's loading correctly.
+into and what appeared to be a problem with DLLs loading correctly.
His <a href="http://www.winehq.org/hypermail/wine-patches/2003/04/0267.html">patch</a>
included the following notes:</p>
<quote who="Pierre d'Herbemont"><p>
Index: wwn/wn20030509_169.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030509_169.xml,v
retrieving revision 1.5
diff -u -p -r1.5 wn20030509_169.xml
--- wwn/wn20030509_169.xml 24 Mar 2004 16:12:19 -0000 1.5
+++ wwn/wn20030509_169.xml 20 Jun 2005 09:23:40 -0000
@@ -330,9 +330,9 @@ directory and you are back.</quote></p>
<topic>Utilities</topic>
<p>Back in <a href="http://www.winehq.org/index.php?issue=156#Windows%20API%20Database%20(cont'd)">issue #156</a>
we discussed building a
-table or database of how Windows DLL's are interrelated.
+table or database of how Windows DLLs are interrelated.
By running a perl utility you can scan a Windows installation
-to locate DLL's and dump API imports and exports using
+to locate DLLs and dump API imports and exports using
winedump.
Dave Miller wrote in to announce more work he'd done on this tool:</p>
<quote who="Dave Miller"><p>
Index: wwn/wn20030523_171.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030523_171.xml,v
retrieving revision 1.8
diff -u -p -r1.8 wn20030523_171.xml
--- wwn/wn20030523_171.xml 31 Mar 2004 21:40:30 -0000 1.8
+++ wwn/wn20030523_171.xml 20 Jun 2005 09:24:19 -0000
@@ -256,7 +256,7 @@ Miguel de Icaza showed up to represent M
work (see the related thread in this issue for more info). Miguel was very
happy with their current patch because it didn't require much work for them.
Alexandre thought the real solution to Mono integration involved a deeper issue
-and hacking Wine DLL's to turn them into ELF libraries wasn't the way to do it.
+and hacking Wine DLLs to turn them into ELF libraries wasn't the way to do it.
He went on to mention the need for a way to <quote who="Alexandre Julliard">
turn a normal unix app into a winelib
app on the fly, basically by dlopening libwine.</quote> Jeremy White felt
@@ -268,8 +268,8 @@ tree,
</quote></p>
<p>Steven Edwards showed up to represent the ReactOS project. Currently Steven's
-work involves splitting up 16/32 bit DLL's. He mentioned that the ReactOS project
-was primarily concerned with a handful of DLL's:
+work involves splitting up 16/32 bit DLLs. He mentioned that the ReactOS project
+was primarily concerned with a handful of DLLs:
ole* shlwapi, winmm, comctl32, comdlg32 and shell32.
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,
Index: wwn/wn20030627_176.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030627_176.xml,v
retrieving revision 1.5
diff -u -p -r1.5 wn20030627_176.xml
--- wwn/wn20030627_176.xml 16 Dec 2003 17:09:27 -0000 1.5
+++ wwn/wn20030627_176.xml 20 Jun 2005 09:24:55 -0000
@@ -200,7 +200,7 @@ contribute that it will be able or to fi
<section
title="Status Page Updates"
- subject="Wine Status DLL's #2"
+ subject="Wine Status DLLs #2"
archive="http://www.winehq.org/hypermail/wine-devel/2003/06/0579.html"
posts="7"
startdate="06/24/2003"
@@ -216,7 +216,7 @@ necessary documentation, such as functio
available via <a href="http://msdn.microsoft.com">MSDN</a>. This
time around Tom
<a href="http://www.winehq.org/hypermail/wine-devel/2003/06/0579.html">modified</a>
-the DLL's status page to include links to the relevant docs. </p>
+the DLLs status page to include links to the relevant docs. </p>
<p>There was a bit of discussion concerning the wintab32 DLL. Rob
North and Aric Stewart's recent work hasn't been committed yet, so
Index: wwn/wn20030704_177.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030704_177.xml,v
retrieving revision 1.6
diff -u -p -r1.6 wn20030704_177.xml
--- wwn/wn20030704_177.xml 4 Jan 2005 19:49:24 -0000 1.6
+++ wwn/wn20030704_177.xml 20 Jun 2005 09:25:09 -0000
@@ -82,7 +82,7 @@ years ago.
</p><p>
Tom Wickline updated the
-<a href="http://www.winehq.org/?page=status_dlls">DLL's status page</a>
+<a href="http://www.winehq.org/?page=status_dlls">DLLs status page</a>
on WineHQ. If you've ever wondered what a particular DLL in Wine does
check out the new links to MSDN info. Tom has moved on to updating the
"Core" status page.</p>
Index: wwn/wn20030725_180.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030725_180.xml,v
retrieving revision 1.6
diff -u -p -r1.6 wn20030725_180.xml
--- wwn/wn20030725_180.xml 27 Jan 2005 15:21:25 -0000 1.6
+++ wwn/wn20030725_180.xml 20 Jun 2005 09:25:22 -0000
@@ -300,7 +300,7 @@ changes by magic, but progress is progre
</section><section
- title="Configuring Native OLE DLL's"
+ title="Configuring Native OLE DLLs"
subject="Re: [resend] Ensure ole32.dll gets correct version number"
archive="http://www.winehq.org/hypermail/wine-devel/2003/07/0523.html"
posts="5"
Index: wwn/wn20030829_185.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20030829_185.xml,v
retrieving revision 1.6
diff -u -p -r1.6 wn20030829_185.xml
--- wwn/wn20030829_185.xml 6 Oct 2004 15:05:11 -0000 1.6
+++ wwn/wn20030829_185.xml 20 Jun 2005 09:25:54 -0000
@@ -353,7 +353,7 @@ find a clue to my problem. Could anyone
>
<topic>DirectX</topic>
<p>Jonathon Wilson looked into whether Wine could use
-native DirectX DLL's and was surprised by what he found:</p>
+native DirectX DLLs and was surprised by what he found:</p>
<quote who="Jonathon Wilson"><p>
After investigating the DirectX NT dlls as part of an investigation to see
if they would work on ReactOS, I discovered something.
Index: wwn/wn20031010_191.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20031010_191.xml,v
retrieving revision 1.5
diff -u -p -r1.5 wn20031010_191.xml
--- wwn/wn20031010_191.xml 27 Jan 2005 15:21:25 -0000 1.5
+++ wwn/wn20031010_191.xml 20 Jun 2005 09:26:26 -0000
@@ -151,7 +151,7 @@ version. The uxtheme aware version conta
theming. To use uxtheme you need to add uxtheme support to the dlls that need
it which looks like a huge job. Perhaps this is something post Wine-1.0?</p></quote>
-<p>Dimi wondered why two DLL's were needed and Roderick explained:</p>
+<p>Dimi wondered why two DLLs were needed and Roderick explained:</p>
<quote who="Roderick Colenbrander"><p>
The "old" dll that MS ships with WindowsXP is comctl32.dll version 5.x which
is the same as on other Windows versions.
Index: wwn/wn20031031_194.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20031031_194.xml,v
retrieving revision 1.3
diff -u -p -r1.3 wn20031031_194.xml
--- wwn/wn20031031_194.xml 16 Dec 2003 17:09:27 -0000 1.3
+++ wwn/wn20031031_194.xml 20 Jun 2005 09:26:57 -0000
@@ -247,7 +247,7 @@ because you could have problems later wi
</p></quote>
-<p>Greg Turner offered to look at the problems with Wine's builtin DLL's
+<p>Greg Turner offered to look at the problems with Wine's builtin DLLs
if someone could give a pointer to a free installer he could test with.</p>
</section>
@@ -394,7 +394,7 @@ used yet (?).
Unfortunately, stubless proxies have been the recommended (by Microsoft) mode
of generating code from MIDL for many years. Increasingly, I see calls to
NdrClientCall2. The only solution (aside from coding wine) is to use native
-rpcrt4/ole32 -- but this, in turn, means you must use Windows 98 dll's or
+rpcrt4/ole32 -- but this, in turn, means you must use Windows 98 dlls or
else you will bump up against the missing "Ports" API if ncalrpc is used (it
usually is -- this is why I keep musing that I want to take a crack at
implementing this).
Index: wwn/wn20031205_199.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20031205_199.xml,v
retrieving revision 1.3
diff -u -p -r1.3 wn20031205_199.xml
--- wwn/wn20031205_199.xml 15 Jan 2004 00:02:46 -0000 1.3
+++ wwn/wn20031205_199.xml 20 Jun 2005 09:27:30 -0000
@@ -474,7 +474,7 @@ already did. </p></quote>
</quote></p>
<p>The real problem with InstallShield is its use of OLE and DCOM.
-Running with native versions of those DLL's helps, but obviously it's
+Running with native versions of those DLLs helps, but obviously it's
not the desired solution. Rob Shearman mentioned some of the problems
with native OLE/DCOM:</p>
<quote who="Robert Shearman"><p>
@@ -557,7 +557,7 @@ of any (current) effort to remedy that?
enddate="12/05/2003"
>
<topic>Debugging</topic>
-<p>Imagehlp.DLL is one of those odd system DLL's that live on the periphery
+<p>Imagehlp.DLL is one of those odd system DLLs that live on the periphery
of implementation. It's purpose is to analyze the structure of a PE file,
such as another DLL. This library contains a slew of functions for working
with and manipulating that structure. It's critical for debugging and
Index: wwn/wn20031212_200.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20031212_200.xml,v
retrieving revision 1.3
diff -u -p -r1.3 wn20031212_200.xml
--- wwn/wn20031212_200.xml 15 Jan 2004 00:02:46 -0000 1.3
+++ wwn/wn20031212_200.xml 20 Jun 2005 09:27:50 -0000
@@ -234,7 +234,7 @@ changed as evidenced by his reply:</p>
</section>
<section
- title="Using Native DLL's in a Winelib App"
+ title="Using Native DLLs in a Winelib App"
subject="Using a windows dll from a winelib or possibly native linux app."
archive="http://www.winehq.org/hypermail/wine-devel/2003/12/0231.html"
posts="6"
Index: wwn/wn20031219_201.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20031219_201.xml,v
retrieving revision 1.4
diff -u -p -r1.4 wn20031219_201.xml
--- wwn/wn20031219_201.xml 15 Jan 2004 00:02:46 -0000 1.4
+++ wwn/wn20031219_201.xml 20 Jun 2005 09:28:10 -0000
@@ -348,7 +348,7 @@ hundred patches in my mailbox when I get
He asked everyone to please review it and proofread it:
</p><quote who="Tom Wickline"><p>
-Here is the current DLL's Status Page.
+Here is the current DLLs Status Page.
I've made a number of changes since I last sent
these partial pages to the dev-list.
Here is a list of things I still need to do for completeness.
Index: wwn/wn20040116_205.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20040116_205.xml,v
retrieving revision 1.4
diff -u -p -r1.4 wn20040116_205.xml
--- wwn/wn20040116_205.xml 1 Jun 2005 19:08:50 -0000 1.4
+++ wwn/wn20040116_205.xml 20 Jun 2005 09:28:37 -0000
@@ -192,7 +192,7 @@ Half-Life's intro. Tim made the driver
provisions of the LGPL.
The new DLL led to some discussion of exactly how to structure the
-codebase to accept some DLL's. After Mike submitted the patch,
+codebase to accept some DLLs. After Mike submitted the patch,
Dmitry Timoshkov requested,
<quote who="Dmitry Timoshkov">
Mike, could you put the iccvid sources at the same place
@@ -208,7 +208,7 @@ appropriate place. I don't mind either
consistency. If the ICCVID driver was moved to wine/dlls then
MSRLE32 should be moved there as well. Dimi Paun was in favor
of a flatter directory structure and advocated it be placed with
-the other DLL's. Eric Pouech disagreed,
+the other DLLs. Eric Pouech disagreed,
<quote who="Eric Pouech">
I still don't see the point of having a unique dlls/ flat structure.
Which more than 100 dlls right now, I do think we need to structure it.
Index: wwn/wn20040203_208.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20040203_208.xml,v
retrieving revision 1.3
diff -u -p -r1.3 wn20040203_208.xml
--- wwn/wn20040203_208.xml 6 Feb 2004 16:01:17 -0000 1.3
+++ wwn/wn20040203_208.xml 20 Jun 2005 09:30:05 -0000
@@ -256,7 +256,7 @@ After an hour break we resumed discussio
Next up, Tom Wickline put together a presentation about getting applications to
run. Tom has worked quite a bit with Wine and CrossOver Office and
had some tricks for getting things to work. The key to just getting
-something to run seems to be using native Windows DLL's. He has a copy
+something to run seems to be using native Windows DLLs. He has a copy
of Windows 98 to copy things to and from. Generally he starts with
CrossOver Office and adds the following things in this order:
<ul>
@@ -273,20 +273,20 @@ and games he's tested.
</p><p>
One problem with this approach is it relies on access to native
-versions of DLL's. The goal of Wine is to not have this requirement
+versions of DLLs. The goal of Wine is to not have this requirement
which of course leads to the magnitude of the project. It did however
lead to an interesting revelation by Mark Tempel of a useful way to
debug problems. If you simply rename an executable it will first
-search the local directory for all of the DLL's it needs to run. This
+search the local directory for all of the DLLs it needs to run. This
can lead to many useful scenarios:
<ul>
<li>On Windows you can simply replace some of the major
- controls by copying Wine PE DLL's in the local directory.
+ controls by copying Wine PE DLLs in the local directory.
It's probably a bad idea to replace any in c:\windows\system
because it may (and Mark said probably) would prevent Windows
- from booting. The ReactOS guys already maintain PE DLL's
+ from booting. The ReactOS guys already maintain PE DLLs
that Windows could use natively.</li>
- <li>A trial and error process of replacing some DLL's will
+ <li>A trial and error process of replacing some DLLs will
definitely find shortcomings with Wine. </li>
</ul></p><p>...</p><p>
Index: wwn/wn20040326_216.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20040326_216.xml,v
retrieving revision 1.2
diff -u -p -r1.2 wn20040326_216.xml
--- wwn/wn20040326_216.xml 31 Mar 2004 21:40:30 -0000 1.2
+++ wwn/wn20040326_216.xml 20 Jun 2005 09:28:52 -0000
@@ -205,7 +205,7 @@ happening sometime after the insert.
Thanks hatky for your work.
</p></quote>
-<p>Francois pointed out that several DLL's needed to be
+<p>Francois pointed out that several DLLs needed to be
ignored since they were Wine-specific. He provided a list
that hatky integrated.</p>
Index: wwn/wn20040402_217.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20040402_217.xml,v
retrieving revision 1.4
diff -u -p -r1.4 wn20040402_217.xml
--- wwn/wn20040402_217.xml 12 Apr 2004 19:08:35 -0000 1.4
+++ wwn/wn20040402_217.xml 20 Jun 2005 09:29:19 -0000
@@ -95,7 +95,7 @@ using custom ".owm" installation scripts
in complexity and at the most basic level just download and
run an application installer. At the other end of the spectrum
it's possible to tell the script to manually extract cab files
-and use native DLL's (using Wine AppDefaults in the config
+and use native DLLs (using Wine AppDefaults in the config
file.) From their
<a href="http://www.ibiblio.org/onebase/onebase-linux.org/About/aboutol.html">about</a>
page:</p>
Index: wwn/wn20040827_237.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20040827_237.xml,v
retrieving revision 1.2
diff -u -p -r1.2 wn20040827_237.xml
--- wwn/wn20040827_237.xml 2 Sep 2004 19:09:22 -0000 1.2
+++ wwn/wn20040827_237.xml 20 Jun 2005 09:30:34 -0000
@@ -476,7 +476,7 @@ pointed out the latest CVS might contain
corrected calls to GetWindowLongA. Vincent reran the test and found things
improved! We dropped to 270! (Sorry, I just got done watching <i>The Daily
Show</i>, so pretend Jon Stewart is reading this paragraph out loud.) Rolf
-Kalbermatter did point out that calls in the shell related DLL's might not
+Kalbermatter did point out that calls in the shell related DLLs might not
be a problem. In a different thread, Vincent described how this has been
overlooked:</p>
<quote who="Vincent Beron"><p>
Index: wwn/wn20041015_244.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20041015_244.xml,v
retrieving revision 1.6
diff -u -p -r1.6 wn20041015_244.xml
--- wwn/wn20041015_244.xml 20 May 2005 17:57:50 -0000 1.6
+++ wwn/wn20041015_244.xml 20 Jun 2005 09:29:07 -0000
@@ -527,7 +527,7 @@ that's possible. Lars Segerlund inquire
this week:</p>
<quote who="Lars Segerlund"><p>
I was thinking of a silly thing to try, namely
- replacing windows dll's with wine's, does anybody
+ replacing windows dlls with wine's, does anybody
have any thoughts about it ?
</p><p>
I just thought about it as a debugging trick I
Index: wwn/wn20041126_250.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20041126_250.xml,v
retrieving revision 1.4
diff -u -p -r1.4 wn20041126_250.xml
--- wwn/wn20041126_250.xml 4 Jan 2005 19:49:24 -0000 1.4
+++ wwn/wn20041126_250.xml 20 Jun 2005 09:30:18 -0000
@@ -539,7 +539,7 @@ I took some screenshots.
http://sidenet.ddo.jp/winetips/files/</a></ul></p></quote>
<p>If you dissect the script you'll notice a lot of what it
-does is install some proprietary DLL's. Specifically, DCOM98,
+does is install some proprietary DLLs. Specifically, DCOM98,
MFC 4.0, and Microsoft Installer. So yes, it's cheating and
Wine isn't running these completely out of the box. However,
you can run them. </p>
Index: wwn/wn20050225_263.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20050225_263.xml,v
retrieving revision 1.2
diff -u -p -r1.2 wn20050225_263.xml
--- wwn/wn20050225_263.xml 7 Mar 2005 21:17:11 -0000 1.2
+++ wwn/wn20050225_263.xml 20 Jun 2005 09:30:59 -0000
@@ -326,7 +326,7 @@ And one thing we probably don't care abo
<section
title="Forwarding rsabase to rsaenh"
- subject="Re: status of wine dll's"
+ subject="Re: status of wine dlls"
archive="http://www.winehq.com/hypermail/wine-devel/2005/02/0552.html"
posts="10"
startdate="02/19/2005"
Index: wwn/wn20050304_264.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20050304_264.xml,v
retrieving revision 1.4
diff -u -p -r1.4 wn20050304_264.xml
--- wwn/wn20050304_264.xml 8 Mar 2005 20:16:16 -0000 1.4
+++ wwn/wn20050304_264.xml 20 Jun 2005 09:31:46 -0000
@@ -282,7 +282,7 @@ http://www.winehq.org/hypermail/wine-pat
-<p><u>Dll's Status</u></p><p>
+<p><u>Dlls Status</u></p><p>
<dl>
<dt>advapi32.dll & rsaenh.dll</dt>
<dd><a href="http://www.winehq.org/hypermail/wine-devel/2005/02/0552.html">
@@ -331,7 +331,7 @@ http://www.winehq.org/hypermail/wine-pat
<br /> 
<dt>DirectMusic (as a group)</dt>
<dd>Raphael & Christian have sent a couple nice patches in the
-last couple of months to bump the status on a couple of DirectMusic dll's</dd>
+last couple of months to bump the status on a couple of DirectMusic dlls</dd>
<br /> 
<dt>dsound.dll</dt>
<dd>What can I say; Robert Reif has sent hundreds of DirectSound patches alone!
@@ -584,7 +584,7 @@ Dragon Naturally Speaking 4 working unde
</p><p>
<ol>
<li>Install Dragon from CD no major issues.</li>
-<li>copy missing dll's</li>
+<li>copy missing dlls</li>
<li>ran up Dragon , enter user name , setup sticks at setting mike level but
exits cleanly.</li>
Index: wwn/wn20050422_271.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20050422_271.xml,v
retrieving revision 1.4
diff -u -p -r1.4 wn20050422_271.xml
--- wwn/wn20050422_271.xml 24 May 2005 14:44:28 -0000 1.4
+++ wwn/wn20050422_271.xml 20 Jun 2005 09:31:57 -0000
@@ -450,7 +450,7 @@ works for you and if it does send me (of
</p></quote>
</section>
<section
- title="Wine DLL's on Windows"
+ title="Wine DLLs on Windows"
subject="Still more fun?"
archive="http://www.winehq.org/hypermail/wine-devel/2005/04/0349.html"
posts="4"
Index: wwn/wn20050503_272.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20050503_272.xml,v
retrieving revision 1.3
diff -u -p -r1.3 wn20050503_272.xml
--- wwn/wn20050503_272.xml 20 May 2005 17:57:50 -0000 1.3
+++ wwn/wn20050503_272.xml 20 Jun 2005 09:32:22 -0000
@@ -72,7 +72,7 @@ Alexandre then moved on to the big items
DLL separation is still on the plate. Yes, we've been trying to
do that for years,
but now we're just down to separation of kernel32, ntdll, user32,
-and gdi32. Not much work is actively being done since those DLL's
+and gdi32. Not much work is actively being done since those DLLs
can never be replaced with native components. So it remains on
the to-do list, but not as a priority.
The config has to go into the registry and the config file must
@@ -576,7 +576,7 @@ recognize certain constructs. For examp
different constructs with different calling conventions. Marcus
opened up one of the digital camera drivers he wrote for gphoto and showed what
it did and various constructs it used. He moved on to discussing the
-implementation of stub DLL's. The high-level needs of Wine can get more info on
+implementation of stub DLLs. The high-level needs of Wine can get more info on
what needs to be done by implementing stubs and fleshing them out.
</p><p>
--
Index: wwn/wn20050603_277.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20050603_277.xml,v
retrieving revision 1.3
diff -u -p -r1.3 wn20050603_277.xml
--- wwn/wn20050603_277.xml 4 Jun 2005 16:53:58 -0000 1.3
+++ wwn/wn20050603_277.xml 17 Jun 2005 22:57:41 -0000
@@ -160,7 +160,7 @@ There does seem to be code within Wine t
but it currently does not seem to compile, at least on the Solaris
version.
</p><p>
-I have attached a small patch that allows me to get throught the 'make
+I have attached a small patch that allows me to get through the 'make
depend' section of the compile. Since it is my first patch, please look
at and let me know what I did wrong :)
</p></quote>
@@ -222,7 +222,7 @@ already rejected them. I think there ar
</p><p>
Good idea about the autoconf test for gas support, That's not hard to do, so
I'll contribute this ASAP. Sun's as doesn't work (on x86 anyway) the operand
-orders are different to gas so it won't assemble as expected.
+orders are different from gas so it won't assemble as expected.
</p><p>
You don't need gnu ld at all, x86 Solaris ld works fine. My GCC is built to
use gas + Solaris ld so I can use it to build kernel modules. Aside from
@@ -253,7 +253,7 @@ to be using Solaris 8, while Chuck was u
uncovered an issue:</p>
<quote who="Chuck Hall"><p>
-Started to go through this and found something intresting. lwp.h does
+Started to go through this and found something interesting. lwp.h does
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
@@ -289,9 +289,9 @@ least for copy protection that needs a k
<ol>
<li>Implement a WINE implementation of that kernel driver (in the same way
various stock windows kernel drivers have been implemented). Problem with
-this is that there is a big DMCA risk (which is why AFAIK its been rejected)
+this is that there is a big DMCA risk (which is why AFAIK it's been rejected)
</li>
- <li>Implement a fake NTOSKRNL that has just the entrypoints for accessing and
+ <li>Implement a fake NTOSKRNL that has just the entry points for accessing and
loading copy protection drivers (the set of kernel calls needed by the copy
protection drivers is only a very small subset of the total set of kernel
calls and AFAIK none of them are hardware related)<br />
@@ -387,13 +387,13 @@ is printed ok but after that the app cra
I use LPD for printing and my command line from wine is
'lpr -Pmyprinter'. I also try to print without MFC support
i.e creating the printer DC by hand etc - the crash is the
-same, it follows EndDoc() call.
+same, it follows the EndDoc() call.
</p><p>
-There is no crash like this at the same linux configuration using
+There is no crash like this in the same linux configuration using
in a 'pure' Win32 simple application without MFC though the code
for printing is the same.
</p><p>
-When i print to file, all is ok. So , my current workaround is
+When i print to file, all is ok. So, my current workaround is
printing to a temp file and then send the file to lpr.
</p><p>
I use RH9.0, wine20050419. My [spooler] section in config is the
Index: wwn/wn20050610_278.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20050610_278.xml,v
retrieving revision 1.1
diff -u -p -r1.1 wn20050610_278.xml
--- wwn/wn20050610_278.xml 10 Jun 2005 19:20:01 -0000 1.1
+++ wwn/wn20050610_278.xml 20 Jun 2005 01:14:13 -0000
@@ -129,7 +129,7 @@ much trouble they go through to sweep it
Steam has been sort of working with Wine for a while, although there's been
some difficulty getting it to run. The notable change with this howto compared
to past attempts is that it's no longer necessary to install Internet Explorer.
-A bunch of native DLL's are still required and instructions for installing
+A bunch of native DLLs are still required and instructions for installing
them are given.
</p>
</section>
@@ -206,7 +206,7 @@ Christian Costa sent a large patch in fo
<quote who="Christian Costa"><p>
This wrapper only support rle, msvideo1 and mjpeg for now.
-To enable support for it, download lastest FFMpeg package, built it and
+To enable support for it, download the latest FFMpeg package, build it and
install it.
Also copy avcodec.h, rational.h and common.h into a ffmpeg directory
created in a
@@ -254,12 +254,12 @@ which I mailed on May 15?
So far I haven't received any replies, despite this probably being rather
interesting, given that it is implemented by many of our winmm threads...
</p><p>
-Or should this remain untested until I will have a sizeable amount of
+Or should this remain untested until I have a sizeable amount of
time for testing myself during LinuxTag?
</p></quote>
<p>The patch from May required some work to set up properly, but has
-the potential improve anything highly dependent on the scheduler, such
+the potential to improve anything highly dependent on the scheduler, such
as games. Andi described the patch:</p>
<quote who="Andreas Mohr"><p>
That stuff will require a REAL self-made kernel,
@@ -328,7 +328,7 @@ the easy way to make something work. Pa
about something like that:</p>
<quote who="Paul Vriens"><p>
-I've just finished another test for NtQuerySystemInformatio. In this
+I've just finished another test for NtQuerySystemInformation. In this
test I test the structure SYSTEM_PROCESS_INFORMATION. The structure is
however different for NT4.
</p><p>
@@ -369,7 +369,7 @@ reviewing the applications that Google f
application gets rejected you know who's to blame ;-)
</p></quote>
-<p>In a different thread, Dan Kegel gave an update of the number of
+<p>In a different thread, Dan Kegel gave an update on the number of
applications received so far. Later statistics put the average at around
320 per day. All in all, there's going to be a lot of competition,
which can only be a good thing for a lot of open source projects.
@@ -378,7 +378,7 @@ application gets rejected you know who's
Google hasn't sent out any applications to
the mentoring organizations (e.g. Wine) yet,
but they did just release a breakdown of the
-number of proposals recieved for each project.
+number of proposals received for each project.
The count for Wine is at 77!
No idea how many of those will make it through
the selection process, but at least a few
@@ -488,13 +488,13 @@ relatively easy Cocoa work that's mostly
More economically visible than the user base, however, is the almost
overnight growth in Wine's potential market Apple's decision has caused.
Right now, there are quite a few small firms roughly the size of
-Codeweavers that make a majority of their money JUST porting games from
+CodeWeavers that make a majority of their money JUST porting games from
Wintel to OSX on PowerPC. As we know, porting these programs with Wine
is far more efficient than rewriting the code from scratch to use
completely different APIs, even if we have to expand Wine a little in
the process. Moreover, as Wine gets better and better it becomes
increasingly easier to port applications - I'm sure our users (and
-Transgaming's customers) wouldn't mind games working better in the free
+TransGaming's customers) wouldn't mind games working better in the free
version of Wine. In economic terms, that not only means that our
production technology is much better, it means we face increasing
returns to scale: we can provide the same service cheaper, and the
@@ -502,14 +502,14 @@ advantage is increasingly ours the more
</p><p>
Simply put, with Apple's move to x86 companies using Wine now have the
potential to displace these small porting firms very quickly. Since
-Codeweavers is currently the only company of Wine experts out there, I
+CodeWeavers is currently the only company of Wine experts out there, I
can't think of a better firm to enter this newly changed market. If I
-were Codeweavers, I'd strongly consider investing in a Cocoa developer
+were CodeWeavers, I'd strongly consider investing in a Cocoa developer
and a development kit, and put him to work making a Cocoa version of the
-Crossover interface. At the very least, I'd give Apple a call and see if
+CrossOver interface. At the very least, I'd give Apple a call and see if
they have any desire to help.
</p><p>
-And Apple should be helping a lot. Now, I can't be sure if Codeweaver's
+And Apple should be helping a lot. Now, I can't be sure if CodeWeavers
don't have a secret agreement with Apple already (it would certainly be
Apple's style), nor can I be sure that Apple isn't already secretly
forking Wine (much like they did with Konqueror). However, the point
Index: wwn/wn20050617_279.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/wn20050617_279.xml,v
retrieving revision 1.1
diff -u -p -r1.1 wn20050617_279.xml
--- wwn/wn20050617_279.xml 17 Jun 2005 05:57:42 -0000 1.1
+++ wwn/wn20050617_279.xml 20 Jun 2005 01:50:15 -0000
@@ -305,7 +305,7 @@ admit my configure check is not that goo
the static lib by default and it's not likely you find a shared version
lying somewhere when building Wine.</p></quote>
-<p>Marcus Meissner wondered if separate DLL's could be build to access
+<p>Marcus Meissner wondered if separate DLLs could be build to access
FFMpeg and then dropped in to provide the functionality. It would sort
of turn it into more of a packaging issue:</p>
<quote who="Marcus Meissner"><p>
@@ -313,7 +313,7 @@ What I think of is putting all codecs th
into a wine-quartz-avcoded.rpm which contains one (1) q_avcodec.dll which can
register all these filters.
</p><p>
-So just 1 add-on RPM to install additionaly.
+So just 1 add-on RPM to install additionally.
</p><p>
Since this can be provided by external contributors a distributor would not
have to worry about libavcoded related problems.
@@ -365,11 +365,11 @@ For more details on that effort, see WWN
<a href="http://www.winehq.com/?issue=275#Webcams%20&%20MSN%20Messenger">#275</a>, and
<a href="http://www.winehq.com/?issue=276#Video%20Driver%20Infrastructure">#276</a>.
He posted another patch this week that implemented more functionality.
-Messenger 6.2 is now closer to working with builtin DLL's. Maarten
+Messenger 6.2 is now closer to working with builtin DLLs. Maarten
described how to get it running, but it doesn't sound like it's for the
faint of heart:</p>
<quote who="Maarten Lankhorst"><p>
-MSN Messenger 6.2 (!!) seems to run fairly well with only builtin dll's,
+MSN Messenger 6.2 (!!) seems to run fairly well with only builtin dlls,
from what I can tell the only real thing missing is CreateTextServices
in riched20.dll, SSL support and urlmon's obtainuseragent (or
something), webcams will work without any additional native dll now, if
@@ -416,12 +416,12 @@ in config), because else smilies appear
What I miss however, is the icon in the system tray, while this works
fine under KDE it really *HURTS* not to have it in gnome.
</p><p>
-I currently use the following native dll's:
+I currently use the following native dlls:
msvcp60.dll/RTC{DLL,RES,RTP}.dll
</p><p>
The above 4 aren't really interesting, as they are required by the
mozilla activeX control, and not worth implementing. I can't remember
-wether it was installed by mozilla activeX, but I believe it was.
+whether it was installed by mozilla activeX, but I believe it was.
</p><p>
What is more interesting is that there is now only 1 file needed for msn
6.2 to work builtin (MSN+ works perfectly too):
Index: wwn/interviews/interview_10.xml
===================================================================
RCS file: /var/cvs/lostwages/wwn/interviews/interview_10.xml,v
retrieving revision 1.5
diff -u -p -r1.5 interview_10.xml
--- wwn/interviews/interview_10.xml 27 Jan 2005 15:21:25 -0000 1.5
+++ wwn/interviews/interview_10.xml 20 Jun 2005 01:52:24 -0000
@@ -376,7 +376,7 @@ platforms.
<question><p><i>BV:</i>
- Any idea how many of Wine's DLL's can be used in Windows?
+ Any idea how many of Wine's DLLs can be used in Windows?
</p></question>
<answer><p><i>Jon:</i>
More information about the wine-patches
mailing list