ChangeSet ID: 23057 CVSROOT: /opt/cvs-commit Module name: lostwages Changes by: jnewman@winehq.org 2006/02/14 11:18:12
Modified files: wwn : wn20050812_287.xml wn20051025_296.xml wn20060210_305.xml
Log message: Francois Gouget fgouget@free.fr Assorted spelling and typos fixes.
Patch: http://cvs.winehq.org/patch.py?id=23057
Old revision New revision Changes Path 1.5 1.6 +1 -1 lostwages/wwn/wn20050812_287.xml 1.7 1.8 +4 -4 lostwages/wwn/wn20051025_296.xml 1.2 1.3 +22 -22 lostwages/wwn/wn20060210_305.xml
Index: lostwages/wwn/wn20050812_287.xml diff -u -p lostwages/wwn/wn20050812_287.xml:1.5 lostwages/wwn/wn20050812_287.xml:1.6 --- lostwages/wwn/wn20050812_287.xml:1.5 14 Feb 2006 17:18:12 -0000 +++ lostwages/wwn/wn20050812_287.xml 14 Feb 2006 17:18:12 -0000 @@ -277,7 +277,7 @@ user interface should be.</quote></p>
</section> <section - title="Registering DLL's" + title="Registering DLLs" subject="Delete Dll(Un)RegisterServer in d3dxof.dll?" archive="http://www.winehq.com/hypermail/wine-devel/2005/08/0214.html" posts="3" Index: lostwages/wwn/wn20051025_296.xml diff -u -p lostwages/wwn/wn20051025_296.xml:1.7 lostwages/wwn/wn20051025_296.xml:1.8 --- lostwages/wwn/wn20051025_296.xml:1.7 14 Feb 2006 17:18:12 -0000 +++ lostwages/wwn/wn20051025_296.xml 14 Feb 2006 17:18:12 -0000 @@ -97,10 +97,10 @@ the development mailing list. </p><p>
A huge project that began around the same time as address separation -was DLL separation. Wine's original DLL's weren't separated along the -same lines as Windows. Wine's DLL's should only call exported functions -of other DLL's. In other words, it should be possible to rip out one -of Wine's builtin DLL's and drop in a native Windows one without any +was DLL separation. Wine's original DLLs weren't separated along the +same lines as Windows. Wine's DLLs should only call exported functions +of other DLLs. In other words, it should be possible to rip out one +of Wine's builtin DLLs and drop in a native Windows one without any difference. <a href="http://www.winehq.org/?issue=5#Elfdlls%20are%20coming">If</a> <a href="http://www.winehq.org/?issue=7#ElfDLLs%20(cont'd)">you</a> Index: lostwages/wwn/wn20060210_305.xml diff -u -p lostwages/wwn/wn20060210_305.xml:1.2 lostwages/wwn/wn20060210_305.xml:1.3 --- lostwages/wwn/wn20060210_305.xml:1.2 14 Feb 2006 17:18:12 -0000 +++ lostwages/wwn/wn20060210_305.xml 14 Feb 2006 17:18:12 -0000 @@ -133,7 +133,7 @@ on LinuxElectrons:</p> <quote who="LinuxElectrons"><p> "Businesses tell us they want to switch to the desktop Linux operating system to reduce total cost of ownership or improve security, but it's the -thought of losing one or two software applications like Quickbooks or +thought of losing one or two software applications like QuickBooks or Microsoft Project that holds them back," said Kevin Carmony, CEO of Linspire, Inc. "CrossOver Office is genius because it removes that hesitation from the equation. Yes, you can still use Quicken or Microsoft software on your @@ -329,8 +329,8 @@ Michael Stefaniuc came up with a new, li
winedump has a VC++ symbol demangling function but that is bitrotting as it is a copy of the msvcrt.__unDname . As i wanted to use the newer - msvcrt.__unDname funtion i have written a quick and dirty program that - is basicaly only a wrapper around UnDecorateSymbolName(). Most importent + msvcrt.__unDname function i have written a quick and dirty program that + is basically only a wrapper around UnDecorateSymbolName(). Most important feature is that it runs on the command line. I'm not expecting it to go into Wine but others might find it useful. After applying the patch configure needs to be regenerated. @@ -355,7 +355,7 @@ instead of duplicating code?</quote></p> <quote who="Eric Pouech"><p> <ul>
-<li> because we don't want winedump to be winelib app</li> +<li> because we don't want winedump to be a winelib app</li> <li> because winedump does a bit more than just demangling (like adding pmt names) which requires an extra level of intelligence that doesn't exist in msvcrt.__undname</li></ul></p></quote> @@ -402,7 +402,7 @@ WTL on Windows gives me: </p><p> The goal is to combine WTL/ATL (no COM) with Winelib to create a Linux-application with the same look and -feel and roughly the same qualities: no DLL's, +feel and roughly the same qualities: no DLLs, shared libraries, C++ ABI hassles, etc. Just one binary linked to libc.
@@ -570,7 +570,7 @@ Winelib (if that's decided to be a suppo in some natural order. The overall initialization function should be configurable so that programs that need only - a few DLL's (user, gdi, crtdll, kernel, ntdll) + a few DLLs (user, gdi, crtdll, kernel, ntdll) don't need to link everything</li>
<li> Infrastructure to allow faking registry calls @@ -584,7 +584,7 @@ Winelib (if that's decided to be a suppo What I specifically don't need/want through Winelib: <ul><li> networking</li> <li> filesystem access</li> -<li> loading of external DLL's or other libraries</li> +<li> loading of external DLLs or other libraries</li> <li> C++ runtime library support</li></ul></p><p>
Also, if anyone is interested in hosting patches to ATL/WTL @@ -611,10 +611,10 @@ just update the one dynamic library that If the startup speed isn't good enough for you, you can use oprofile (or some other profiling framework) to work out which functions are taking up time. We would welcome any fixes to improve the startup speed. -Optionally, you could comment out functions do things that you don't need. +Optionally, you could comment out functions that do things that you don't need. </p></quote>
-<p>Claus explained a bit more about the application and ho he'd like to +<p>Claus explained a bit more about the application and how he'd like to deploy it:</p> <quote who="Claus Fischer"><p>
@@ -631,18 +631,18 @@ Mountain Rescue Service, has roughly 100 </p><p> When the first phase was finished, the program would still run under Windows 98 SE upwards. It now depends on the -following DLL's: +following DLLs:
- VERSION, - WS2_32, - KERNEL32, - USER32, - GDI32, - COMDLG32, - ADVAPI32, - SHELL32, - OLE32, - WININET, + VERSION,<br/> + WS2_32,<br/> + KERNEL32,<br/> + USER32,<br/> + GDI32,<br/> + COMDLG32,<br/> + ADVAPI32,<br/> + SHELL32,<br/> + OLE32,<br/> + WININET,<br/> COMCTL32</p><p>
On any reasonable PC with internet access (it's a networked @@ -663,7 +663,7 @@ For this reason, having WTL+Winelib for been just too nice to think of :-)</p></quote>
<p>That prompted Dmitry Timoshkov to point out the underlying facilities -to support those DLL's were non-trivial, +to support those DLLs were non-trivial, <quote who="Dmitry Timoshkov"> You seem to underestimate what the dependencies above mean for the running Windows system. You depend on the <i>whole</i> kernel + GUI @@ -697,7 +697,7 @@ Your <i>actual</i> goal is described her dependency hell. A noble goal indeed, but the right way to do this is to investigate things like autopackage, ELF statifier, and so on. And also to accept that a program with no dependencies is perhaps not so useful after -all. For instance, you can probably find GTK+ 2.2 or higher on everybodies +all. For instance, you can probably find GTK+ 2.2 or higher on everybody's system these days.</p></quote>
</section></kc>