Changelog: Fix common typos in the web site. Index: templates/en/supported_applications.template =================================================================== RCS file: /home/wine/lostwages/templates/en/supported_applications.template,v retrieving revision 1.5 diff -u -r1.5 supported_applications.template --- templates/en/supported_applications.template 26 Apr 2003 17:06:20 -0000 1.5 +++ templates/en/supported_applications.template 8 Jun 2003 01:41:03 -0000 @@ -16,12 +16,12 @@ <p> Wine has an <a href="http://appdb.winehq.com/";>Application Database</a> where Windows -application compatability is recorded. Registered users can submit new apps, and comment +application compatibility is recorded. Registered users can submit new apps, and comment on existing ones. Screen shots are also available for many apps. Users can also vote on their favorite apps. </p> -<h1>Other Wine Application Compatability Sites</h1> +<h1>Other Wine Application Compatibility Sites</h1> <p> <a href="http://frankscorner.org";><b>Frank's Corner</b></a>: Frank has a fantastic Wine @@ -30,9 +30,8 @@ <h1>Wine 0.9 Supported Applications List</h1> -<p>This is a working version of the application lists which we hope to support 'officially' -for Wine 0.9. Do not worry too much about formatting. It is not very good, and will -most likely change before it goes to WineHQ. Please send comments, and suggestions, +<p>This is a working version of the application lists which we hope to +support 'officially' for Wine 0.9. Please send comments, and suggestions, about the list to <a href="mailto:clozano@andago.com";>Carlos Lozano</a>; direct formatting related flames to <a href="mailto:dpaun@rogers.com";>Dimitrie O. Paun</a>.</p> Index: wwn/wn19990718_4.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn19990718_4.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn19990718_4.xml --- wwn/wn19990718_4.xml 2 Dec 2002 17:08:24 -0000 1.1.1.1 +++ wwn/wn19990718_4.xml 8 Jun 2003 01:41:05 -0000 @@ -977,13 +976,13 @@ <p /> At present, it is possible to run multiple Win32 apps by starting -seperate Wine processes manually at the command line, which would then -start seperate Wine server processes along with the app. These processes +separate Wine processes manually at the command line, which would then +start separate Wine server processes along with the app. These processes cannot communicate amongst each other using standard Win32 IPC APIs, may have problems due to unserialized access to registry files, etc. Some of this may be solvable by having a shared Wine server process. Extending the Wine server model in this way is <b>not</b> what people are -discussing as seperate address spaces though, right? +discussing as separate address spaces though, right? <p /> @@ -996,14 +995,14 @@ <p /> The problem with the shared address space model is that it does not -provide the memory protection that would be provided with the seperated +provide the memory protection that would be provided with the separated model, and that the new process will not have the same memory layout it would have had in Windows, right? <p /> If that's all it is, why is it a big deal? Unless I'm mistaken, -providing seperated address spaces will be a <b>big</b> deal, requiring +providing separated address spaces will be a <b>big</b> deal, requiring marshalling of all message data, and various other tweaky-to-get-right tasks. On the other side of the coin, how common is the use of CreateProcess amongst the apps people want to run? Is this useful Index: wwn/wn20000904_59.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20000904_59.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20000904_59.xml --- wwn/wn20000904_59.xml 2 Dec 2002 17:08:31 -0000 1.1.1.1 +++ wwn/wn20000904_59.xml 8 Jun 2003 01:41:17 -0000 @@ -75,7 +75,7 @@ <quote who="Ulrich Weigand"> The problem is that we implement thunks differently than Win95 does, with the most important difference being that we actually have two -seperate stacks per app, a 16-bit one and a 32-bit one, where Win95 +separate stacks per app, a 16-bit one and a 32-bit one, where Win95 has only <b>one</b> stack: 16-bit apps have their 16-bit stack, and when thunking to 32-bit, ESP is simply set to the appropriate 32-bit flat pointer pointing to the current 16-bit stack location; 32-bit apps Index: wwn/wn19990920_9.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn19990920_9.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn19990920_9.xml --- wwn/wn19990920_9.xml 2 Dec 2002 17:08:24 -0000 1.1.1.1 +++ wwn/wn19990920_9.xml 8 Jun 2003 01:41:06 -0000 @@ -232,7 +231,7 @@ How do people feel about adding optional support for a non-free library that provides this functionality? Alexandre, if we did work to support such a library (ifdefed, of course), would you allow -that work into CVS, or would we have to keep a seperate branch +that work into CVS, or would we have to keep a separate branch ourselves? <p /> Index: wwn/wn20001211_73.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20001211_73.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20001211_73.xml --- wwn/wn20001211_73.xml 2 Dec 2002 17:08:33 -0000 1.1.1.1 +++ wwn/wn20001211_73.xml 8 Jun 2003 01:41:22 -0000 @@ -293,7 +293,7 @@ Gavriel State wondered <quote who="Gavriel State"> Is there really any reason not to just use pthread directly? We're not -constrained by binary compatability issues on LinuxPPC (or MacOS X), +constrained by binary compatibility issues on LinuxPPC (or MacOS X), so there's no need to preserve any special registers. <p /> Index: wwn/wn20001218_74.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20001218_74.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20001218_74.xml --- wwn/wn20001218_74.xml 2 Dec 2002 17:08:33 -0000 1.1.1.1 +++ wwn/wn20001218_74.xml 8 Jun 2003 01:41:22 -0000 @@ -270,7 +270,7 @@ <p /> -Dynamic linking allows to seperate executable code between several +Dynamic linking allows to separate executable code between several modules (each stored in a different file), but loaded in memory to create a process image. Index: wwn/wn20010611_97.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20010611_97.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20010611_97.xml --- wwn/wn20010611_97.xml 2 Dec 2002 17:08:15 -0000 1.1.1.1 +++ wwn/wn20010611_97.xml 8 Jun 2003 01:41:26 -0000 @@ -372,7 +373,7 @@ <quote who="Patrick Stridvall"> <p>However regardless of this, uname shouldn't be used (at least not directly). Autoconf provides a standard -way to do this (which BTW happends to use uname). +way to do this (which BTW happens to use uname). It can be used as below.</p> <p><code>AC_CANONICAL_HOST<br /> Index: wwn/wn20020213_115.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20020213_115.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20020213_115.xml --- wwn/wn20020213_115.xml 2 Dec 2002 17:08:21 -0000 1.1.1.1 +++ wwn/wn20020213_115.xml 8 Jun 2003 01:41:36 -0000 @@ -622,7 +623,7 @@ contribute significantly to the project. Only the developers contribute, and it is not at all clear to me that they would stop.</p> -<p>Marcus Meissner has already shown that the existance of our AFPLed DCOM +<p>Marcus Meissner has already shown that the existence of our AFPLed DCOM code didn't stop him from going ahead and doing it himself. On the contrary - it helped him, since he got hints from our design. It's a shame that he had to, since we've been working hard to find a way to contribute Index: wwn/wn20020308_117.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20020308_117.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20020308_117.xml --- wwn/wn20020308_117.xml 2 Dec 2002 17:08:21 -0000 1.1.1.1 +++ wwn/wn20020308_117.xml 8 Jun 2003 01:41:38 -0000 @@ -771,7 +772,7 @@ <p>Ove replied, <quote who="Ove Kaaven"> I've been working on this as part of my COM restructure. I've implemented - NdrDllRegisterProxy and large pieces of rpcrt4's marshaling framework. I'd + NdrDllRegisterProxy and large pieces of rpcrt4's marshalling framework. I'd like to release it to WineHQ, but Gav still wants something in exchange. (If we can't get money, we'll consider releasing it if a Wine developer agrees to work on stuff that may be useful for us, like an ALSA driver, Index: wwn/wn20020620_127.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20020620_127.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20020620_127.xml --- wwn/wn20020620_127.xml 2 Dec 2002 17:08:37 -0000 1.1.1.1 +++ wwn/wn20020620_127.xml 8 Jun 2003 01:41:45 -0000 @@ -329,7 +328,7 @@ I'm seeing two possible solutions to this problem: <ul> - <li> If Fribidi was present during compile, check for its existance during + <li> If Fribidi was present during compile, check for its existence during run time. If not present, don't enable the run time option. or </li> <li> Copy (port?) Fribidi into the WINE code. It's LGPL, so the license does allow that.</li> @@ -386,7 +385,7 @@ mentioned that it had worked about a year ago but a patch had caused a problem at some point. Tony Lambregts mentioned, <quote who="Tony Lambregts"> - I estimate that it should take no more then 12 itinerations to + I estimate that it should take no more than 12 itinerations to find the day of patch that broke it </quote> Ian wanted to avoid installing Wine multiple times because of the hassle of tweaking the installations. Several people jumped in to mention Index: wwn/wn20020719_129.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20020719_129.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20020719_129.xml --- wwn/wn20020719_129.xml 2 Dec 2002 17:08:37 -0000 1.1.1.1 +++ wwn/wn20020719_129.xml 8 Jun 2003 01:41:46 -0000 @@ -162,7 +161,7 @@ <li> Make directories use real server handles, rather than pointers to client structures. NtCreateFile supports taking a directory handle and a relative path name from that directory to open files. I've - tried to keep my SMB implementation seperate from everything else to + tried to keep my SMB implementation separate from everything else to facilitate this.</li> </p><p> As you probably know, I've been working on #1 (see my patch from a few Index: wwn/wn20020807_131.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20020807_131.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20020807_131.xml --- wwn/wn20020807_131.xml 2 Dec 2002 17:08:38 -0000 1.1.1.1 +++ wwn/wn20020807_131.xml 8 Jun 2003 01:41:46 -0000 @@ -359,7 +361,7 @@ registries in addition to compiling wine so most of the time if you already have these set up then it is not nessesary to use wineinstall. </p><p> - However the structure of both the .wine/config and registries and thier + However the structure of both the .wine/config and registries and their contents has changed over time and as new features are added to wine. For example over time more functionality has been added to the various dlls and in the default config file various dlls now default to builtin Index: wwn/wn20020913_135.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20020913_135.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20020913_135.xml --- wwn/wn20020913_135.xml 2 Dec 2002 17:08:39 -0000 1.1.1.1 +++ wwn/wn20020913_135.xml 8 Jun 2003 01:41:48 -0000 @@ -195,7 +197,7 @@ HAL (which is where the current ddraw code was starting to head), it calls all the opengl calls inline. I have only tested on one machine with one level of mesa (tough! thats all I have). It also has all the c parts in the -d3d8 directory, completely seperate (and in some cases duplicating code from +d3d8 directory, completely separate (and in some cases duplicating code from the ddraw code), which may or may not be desired. I also dont have a clue about the configure tests and makefile.in, so I have just a basic structure which works enough for me. I'm also relatively certain I havent necessarily Index: wwn/wn20021018_140.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20021018_140.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20021018_140.xml --- wwn/wn20021018_140.xml 2 Dec 2002 17:08:40 -0000 1.1.1.1 +++ wwn/wn20021018_140.xml 8 Jun 2003 01:41:50 -0000 @@ -316,7 +317,7 @@ <li>2045 of them are of type "int format, HANDLE arg", this leaves</li> <li>1343 lines of warnings to look at.</li> </ul></p><p> -I'm almost finished a short perl script to automaticly convert the "int +I'm almost finished a short perl script to automatically convert the "int format, HANDLE arg" warnings, which would leave us with the other 1343 warnings. Wine compiles and even seems to run so if Alexander would like to speed up the conversion he could change the remaining handles to Index: wwn/wn20021025_141.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20021025_141.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 wn20021025_141.xml --- wwn/wn20021025_141.xml 2 Dec 2002 17:08:40 -0000 1.1.1.1 +++ wwn/wn20021025_141.xml 8 Jun 2003 01:41:51 -0000 @@ -236,7 +237,7 @@ <li> widl is like MIDL for wine. For wine to be a useful RPC platform, quite a bit of work needs to be done here. widl currently doesn't generate stubs for RPC invocation -- it will need to; this is tricky because the MIDL compiler - does some really wierd stuff. Then again, we don't neccesarily have to + does some really weird stuff. Then again, we don't necessarily have to make widl work like MIDL, so it could be worse.</li> <li> RPC has a quite featureful error handling mechanism; none of it is implemented @@ -552,7 +553,7 @@ to do page rendering and such.</p> <p>Malte replied, <quote who="Malte Starostik"> -Hmm, we're implementing the absolutely neccessary parts in reaktivate +Hmm, we're implementing the absolutely necessary parts in reaktivate with Konqueror, but that's run from inside Konq already, so it's a bit special. Maybe there would be a way to use either browser with those interfaces? :-)</quote></p> Index: wwn/wn20021122_145.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20021122_145.xml,v retrieving revision 1.1 diff -u -r1.1 wn20021122_145.xml --- wwn/wn20021122_145.xml 2 Dec 2002 17:40:34 -0000 1.1 +++ wwn/wn20021122_145.xml 8 Jun 2003 01:41:54 -0000 @@ -597,14 +598,14 @@ reentrent variant if present as well as having an alternative implementation if not. </p><p> -As to the implict existance question: I'm not sure. +As to the implict existence question: I'm not sure. First of all, to answer the related question: Should you have a alternative implementation for defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? </p><p> IMHO the answer is no. It is not worth the effort to support hypotetical platforms unless we can verify the -existance of one. +existence of one. </p><p> To return to the original question: I suggest that we should detect the presence or absence Index: wwn/wn20021206_147.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20021206_147.xml,v retrieving revision 1.1 diff -u -r1.1 wn20021206_147.xml --- wwn/wn20021206_147.xml 18 Mar 2003 21:58:34 -0000 1.1 +++ wwn/wn20021206_147.xml 8 Jun 2003 01:41:55 -0000 @@ -309,7 +310,7 @@ That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective -browser and IE compatability seems to generally be good enough to keep the +browser and IE compatibility seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the @@ -339,7 +340,7 @@ <li> Simple</li> <li> No XPCOM dependancies</li> -<li> Could be more easily hacked to add IE compatability (and was more IE +<li> Could be more easily hacked to add IE compatibility (and was more IE compatible to start with)</li> <li> Small, good for embedding, relatively fast (gecko embedding is huge)</li> <li> Would be possible to include in the Wine CVS tree as opposed to Gecko Index: wwn/wn20030117_153.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20030117_153.xml,v retrieving revision 1.1 diff -u -r1.1 wn20030117_153.xml --- wwn/wn20030117_153.xml 18 Mar 2003 21:58:34 -0000 1.1 +++ wwn/wn20030117_153.xml 8 Jun 2003 01:41:58 -0000 @@ -287,7 +288,7 @@ my current code and play with that a little. Personally I didn't want to have to take on the chore myself, but this whole Safari thing IS creating more intrest in non-X11/QT platforms... it definatly changes the playing -field, and with the large speed and compatability merges from Safari +field, and with the large speed and compatibility merges from Safari lately my current tree is hopelessly out of date anyway :) </p><p> So I think I will play with that and work on the DLL layout and COM @@ -297,7 +298,7 @@ WINE-specific implementation if something more closely tied to the upstream code is released meer weeks later. </p><p> -Of course there still a small problem of having to seperate the code into +Of course there still a small problem of having to separate the code into MS compatible COM objects and DLLs... I will have to benchmark the speed impact of stubbing the MS dll's into khtml.dll/kjs.dll ecetra, instead of replicating the exports more natively. Index: wwn/wn20030207_156.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20030207_156.xml,v retrieving revision 1.1 diff -u -r1.1 wn20030207_156.xml --- wwn/wn20030207_156.xml 18 Mar 2003 21:58:34 -0000 1.1 +++ wwn/wn20030207_156.xml 8 Jun 2003 01:42:00 -0000 @@ -488,7 +489,7 @@ and shell32 + everything else but we are working on it. Right now the big thing is to compleate our user32/Win32K and then we can make better use of the WINE code. I am trying to get the rest of the ReactOS people to also use the WINE regression test framework for our test suite so we can -share that also. Rest assured any fixes or new features will find thier way back in to the main +share that also. Rest assured any fixes or new features will find their way back in to the main wine tree.</quote></p> </section> Index: wwn/wn20030516_170.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20030516_170.xml,v retrieving revision 1.1 diff -u -r1.1 wn20030516_170.xml --- wwn/wn20030516_170.xml 16 May 2003 14:34:56 -0000 1.1 +++ wwn/wn20030516_170.xml 8 Jun 2003 01:42:06 -0000 @@ -403,7 +404,7 @@ </section><section title="Separating 16/32 Bit OLE Functions" - subject="PATCH - Start seperating 16/32 in Ole and ole32 memlockbytes" + subject="PATCH - Start separating 16/32 in Ole and ole32 memlockbytes" archive="http://www.winehq.com/hypermail/wine-devel/2003/05/0404.html"; posts="2" startdate="05/15/2003" @@ -413,7 +414,7 @@ OLE32. He gave an update of what he's trying to do and some of the issues involved:</p> <quote who="Steven Edwards"><p> - I am doing some work trying to seperate Ole* and Ole32 for use in + I am doing some work trying to separate Ole* and Ole32 for use in ReactOS. Before we can make use of most of the WINE code all of the Non-Win32api imported functions are going to need to be compiled out or rewitten. I dont need someone to do this for me but I am going to need a @@ -449,7 +450,7 @@ this may need some cleanup/review from a OLE guru on Linux but it builds for me without warnings or errors under Mingw. </p><p> -Changelog: Seperate Win16 and Win32 Ole support in memlockbytes. +Changelog: Separate Win16 and Win32 Ole support in memlockbytes. </p></quote> </section><section Index: wwn/wn20030523_171.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20030523_171.xml,v retrieving revision 1.1 diff -u -r1.1 wn20030523_171.xml --- wwn/wn20030523_171.xml 27 May 2003 14:25:49 -0000 1.1 +++ wwn/wn20030523_171.xml 8 Jun 2003 01:42:06 -0000 @@ -273,7 +274,7 @@ At one point Dimi thought a dsp2make utility would be a useful addition and Steven mentioned ReactOS had one. He went on to discuss some future plans, <quote who="Steven Edwards"> - My goal if the ReactOS guys can get more then winhello working is to have WINEs + My goal if the ReactOS guys can get more than winhello working is to have WINEs shell32 and comctl32 running for Linux world</quote>. </p> <p>All in all the meeting was quite successful and a lot of people were glad to @@ -399,7 +400,7 @@ will put in the new interface (that will also let me implement some of GetCharacterProperties more obscure features). That is not likely to happen. I suspect FriBidi has fallen off the end of the earth. It does -not implement mirroring, nor does it implement Arabic Shaping (wierd, +not implement mirroring, nor does it implement Arabic Shaping (weird, considering that the maintainer is from Iran). It only supports UCS-4. </p><p> Also - like I told Mike H on IRC, static linking ICU will mean that we Index: wwn/wn20030530_172.xml =================================================================== RCS file: /home/wine/lostwages/wwn/wn20030530_172.xml,v retrieving revision 1.1 diff -u -r1.1 wn20030530_172.xml --- wwn/wn20030530_172.xml 3 Jun 2003 18:19:06 -0000 1.1 +++ wwn/wn20030530_172.xml 8 Jun 2003 01:42:06 -0000 @@ -180,7 +181,7 @@ </p><p> The secondary problem is how to display the HTML + JavaScript needed for a CHM viewer. I've started work on this several times, and so far the *best* -(in terms of existing compatability with IE's CSS/JS/HTML 'features') has +(in terms of existing compatibility with IE's CSS/JS/HTML 'features') has been KJs and KHtml from the KDE project. </p><p> Gecko doesn't cut it - it's quite slow, bulky and worst of all too strict @@ -199,7 +200,7 @@ writing ActiveX objects. </p><p> The second is that I never could get an answer from Alexandre as to adding -C++ code to WINE itself. It would be possible to write it as a seperate +C++ code to WINE itself. It would be possible to write it as a separate non-core implementation, but many of these DLLs also have non-browser related APIs that need to be in WINE itself. Again, diverting api calls between the versions in WINE and our browser versions is complicated and -- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95
