Re: spelling/typo fixes ect. -- lostwages
On Fri, Jul 04, 2003 at 12:47:21AM -0400, Tom Wickline wrote: Hi, Happy 4th :) Changelog 1) spelling/typo fixes 2) missilanious fixes If you decide to do 1), then it might be useful to also do that for 2) at the same time... Or should this be the militarian form of miscellaneous? :-)) (missilanious wrong coordinates were used to bomb the site) Anyway, thanks for your janitorial work! It's an important task! Andreas Mohr
Re: spelling/typo fixes ect. -- lostwages
Andreas Mohr wrote: On Fri, Jul 04, 2003 at 12:47:21AM -0400, Tom Wickline wrote: Hi, Happy 4th :) Changelog 1) spelling/typo fixes 2) missilanious fixes If you decide to do 1), then it might be useful to also do that for 2) at the same time... Or should this be the militarian form of miscellaneous? :-)) (missilanious wrong coordinates were used to bomb the site) LOL.. Ive been awake (couple day's now) way to long.. thinking one thing and typing another. Also I just checked and the spelling on my wrong word is correct. :) Anyway, thanks for your janitorial work! It's an important task! No... The real _THANKS_ goes out to you for doing this important work. Tom Andreas Mohr
Re: Typo fixes
Francois, h, I don't know why, but this patch did not go. This is what I got. [EMAIL PROTECTED] lostwages]$ patch -p0 typos.diff patching file wwn/wn19990718_4.xml Hunk #1 FAILED at 977. Hunk #2 FAILED at 996. 2 out of 2 hunks FAILED -- saving rejects to file wwn/wn19990718_4.xml.rej patching file wwn/wn20010611_97.xml Hunk #1 FAILED at 373. 1 out of 1 hunk FAILED -- saving rejects to file wwn/wn20010611_97.xml.rej patching file wwn/wn20020213_115.xml Hunk #1 FAILED at 623. 1 out of 1 hunk FAILED -- saving rejects to file wwn/wn20020213_115.xml.rej patching file wwn/wn20020807_131.xml Hunk #1 FAILED at 361. 1 out of 1 hunk FAILED -- saving rejects to file wwn/wn20020807_131.xml.rej patching file wwn/wn20021025_141.xml Hunk #1 FAILED at 553. 1 out of 1 hunk FAILED -- saving rejects to file wwn/wn20021025_141.xml.rej patching file wwn/wn20021122_145.xml Hunk #1 FAILED at 598. 1 out of 1 hunk FAILED -- saving rejects to file wwn/wn20021122_145.xml.rej patching file wwn/wn20030516_170.xml Hunk #1 FAILED at 404. Hunk #2 FAILED at 414. 2 out of 2 hunks FAILED -- saving rejects to file wwn/wn20030516_170.xml.rej patching file wwn/wn20030523_171.xml Hunk #1 FAILED at 274. Hunk #2 FAILED at 400. 2 out of 2 hunks FAILED -- saving rejects to file wwn/wn20030523_171.xml.rej On Mon, 2003-06-09 at 16:28, Francois Gouget wrote: Apparently some typo fixes were not applied the first time around. So here's the second round. It can be applied by doing: cd lostwages patch -p0 /path/to/email.txt Changelog: Fix common typos in the web site. 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 - 1.1.1.1 +++ wwn/wn19990718_4.xml 9 Jun 2003 20:40:39 - @@ -977,13 +977,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 bnot/b what people are -discussing as seperate address spaces though, right? +discussing as separate address spaces though, right? p / @@ -996,14 +996,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 bbig/b deal, requiring +providing separated address spaces will be a bbig/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/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 - 1.1.1.1 +++ wwn/wn20010611_97.xml 9 Jun 2003 20:41:01 - @@ -372,7 +373,7 @@ quote who=Patrick Stridvall pHowever 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 pcodeAC_CANONICAL_HOSTbr / 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.xml2 Dec 2002 17:08:21 - 1.1.1.1 +++ wwn/wn20020213_115.xml9 Jun 2003 20:41:11 - @@ -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 -pMarcus Meissner has already shown that the existance of our AFPLed DCOM +pMarcus 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
Re: Typo fixes
On 10 Jun 2003, Jeremy Newman wrote: Francois, h, I don't know why, but this patch did not go. This is what I got. [EMAIL PROTECTED] lostwages]$ patch -p0 typos.diff patching file wwn/wn19990718_4.xml Hunk #1 FAILED at 977. Hunk #2 FAILED at 996. 2 out of 2 hunks FAILED -- saving rejects to file wwn/wn19990718_4.xml.rej [...] That's strange. I sent these exactly the same way I send regular Wine patches and I don't think Alexandre ever had problems with them. Which email client are you using? Maybe it mangles the patches when saving the email to a file (probably wrapping lines). Let's try again. I am putting the patch as an attachment this time. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere... 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.xml2 Dec 2002 17:08:24 - 1.1.1.1 +++ wwn/wn19990718_4.xml10 Jun 2003 22:45:38 - @@ -977,13 +977,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 bnot/b what people are -discussing as seperate address spaces though, right? +discussing as separate address spaces though, right? p / @@ -996,14 +996,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 bbig/b deal, requiring +providing separated address spaces will be a bbig/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/wn20010513_95.xml === RCS file: /home/wine/lostwages/wwn/wn20010513_95.xml,v retrieving revision 1.1 diff -u -r1.1 wn20010513_95.xml --- wwn/wn20010513_95.xml 9 Jun 2003 15:57:38 - 1.1 +++ wwn/wn20010513_95.xml 10 Jun 2003 22:45:39 - @@ -165,7 +165,7 @@ pBut according to the performance tests that the author made, the linux pipe is somewhat the same speed as doors so maybe it could be optimized more or maybe is Linux's pipe -already so optimized that doors are unnecesary./p +already so optimized that doors are unnecessary./p pSo what do you think, would this be useful for speeding up wine? I apologoize if you already know about this.../p/quote 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 - 1.1.1.1 +++ wwn/wn20010611_97.xml 10 Jun 2003 22:45:39 - @@ -372,7 +373,7 @@ quote who=Patrick Stridvall pHowever 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 pcodeAC_CANONICAL_HOSTbr / Index: wwn/wn20020213_115.xml === RCS file: /home/wine/lostwages/wwn/wn20020213_115.xml,v retrieving revision 1.2 diff -u -r1.2 wn20020213_115.xml --- wwn/wn20020213_115.xml 10 Jun 2003 18:05:36 - 1.2 +++ wwn/wn20020213_115.xml 10 Jun 2003 22:45:42 - @@ -623,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 -pMarcus Meissner has already shown that the existance of our AFPLed DCOM +pMarcus 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
Re: Typo fixes
Francois Gouget wrote: -As to the implict existance question: I'm not sure. +As to the implict existence question: I'm not sure. +As to the implicit existence question: I'm not sure. ^
Re: Typo fixes
On Mon, 9 Jun 2003, Duane Clark wrote: Francois Gouget wrote: -As to the implict existance question: I'm not sure. +As to the implict existence question: I'm not sure. +As to the implicit existence question: I'm not sure. Ah, I wasn't looking for that one. I'll send a patch to fix it with the next round. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
minor typo in winemaker
diff102.diff Description: Binary data
Re: Patch - Fix typo
On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: I noticed this when adapting WINE code for ReactOS [...] - * DialogBoxIndirectParam (USER.240) - * DialogBoxIndirectParam16 (USER32.) + * DialogBoxIndirectParam16 (USER.240) + * DialogBoxIndirectParam (USER32.) */ INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, HANDLE16 dlgTemplate, HWND16 owner16, DLGPROC16 dlgProc, No this is correct. The 16 bit function's external name is DialogBoxIndirectParam The 32 bit function's external name is DialogBoxIndirectParam16 Then maybe add a comment instead: (yep, 16/32 naming is correct) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
RE: Patch - Fix typo
On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: I noticed this when adapting WINE code for ReactOS [...] - * DialogBoxIndirectParam (USER.240) - * DialogBoxIndirectParam16 (USER32.) + * DialogBoxIndirectParam16 (USER.240) + * DialogBoxIndirectParam (USER32.) */ INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, HANDLE16 dlgTemplate, HWND16 owner16, DLGPROC16 dlgProc, No this is correct. The 16 bit function's external name is DialogBoxIndirectParam The 32 bit function's external name is DialogBoxIndirectParam16 Then maybe add a comment instead: (yep, 16/32 naming is correct) Well, it quite common in the core DLLs that the naming is done that way so it would be quite a lot of IMHO unnessary comments. PS. winapi_check automatically finds functions that are wrong so the Wine sourc eis currrently 100% correct (save bugs in winapi_check of course) as far as the issue above in documentation header is concerned.
typo?
Log message: Export the CallFrom16xxx functions from kernel32. Renamed them __wine_call_from_16 to follow the naming convention. ... +@ varargs __wine_call_from_16_word() __wine_call_from_16_word +@ varargs __wine_call_from_16_long() __wine_call_from_16_word +@ varargs __wine_call_from_16_regs() __wine_call_from_16_word +@ varargs __wine_call_from_16_thunk() __wine_call_from_16_word Shouldn't this be: +@ varargs __wine_call_from_16_word() __wine_call_from_16_word +@ varargs __wine_call_from_16_long() __wine_call_from_16_long +@ varargs __wine_call_from_16_regs() __wine_call_from_16_regs +@ varargs __wine_call_from_16_thunk() __wine_call_from_16_thunk -- Dimi.
