August 2010 - Wine-Devel - list.winehq.org

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by Dmitry Timoshkov

GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > > --- a/libs/wine/c_1361.c > > +++ b/libs/wine/c_1361.c > > @@ -8902,6 +8902,6 @@ const struct dbcs_table cptable_1361 = > > uni2cp_low, > > uni2cp_high, > > { > > - 0x84, 0xd3, 0xd9, 0xde, 0xe0, 0xf9, 0x00, 0x00 > > + 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9, 0x00, 0x00 > > } > > }; > > > May I ask some guidance to make this [1] patch accepted ? > Tests prove that the values above needs to be modified. > Actually, I don't know if "uni2cp_high" is generated from the Internet > or cpmap.pl (maybe both) > Anyway, I don't understand perl. > > May > http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT > be wrong ? > Or may Windows doesn't fully comply with unicode ? Windows uses an older Unicode specification, that's pretty normal that unicode.org and Windows data differ in some places. There is no need to change the mapping unless there is an application that depends on it. -- Dmitry.

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by GOUJON Alexandre

On 08/28/2010 02:12 PM, Alexandre Goujon wrote: > I know that libs/wine/c_1361.c is generated ("DO NOT EDIT!!"). > However (union cptable)cptable_1361.dbcs->lead_bytes needs to be modified according tests > [...] > diff --git a/libs/wine/c_1361.c b/libs/wine/c_1361.c > index b424cb1..50d2c47 100644 > --- a/libs/wine/c_1361.c > +++ b/libs/wine/c_1361.c > @@ -8902,6 +8902,6 @@ const struct dbcs_table cptable_1361 = > uni2cp_low, > uni2cp_high, > { > - 0x84, 0xd3, 0xd9, 0xde, 0xe0, 0xf9, 0x00, 0x00 > + 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9, 0x00, 0x00 > } > }; > May I ask some guidance to make this [1] patch accepted ? Tests prove that the values above needs to be modified. Actually, I don't know if "uni2cp_high" is generated from the Internet or cpmap.pl (maybe both) Anyway, I don't understand perl. May http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT be wrong ? Or may Windows doesn't fully comply with unicode ? Thanks --- [1] : http://source.winehq.org/patches/data/65550

Aug. 31, 2010

Re: Wine 1.4 plans?

by Tom Wickline

On Tue, Aug 31, 2010 at 9:45 AM, Austin English <austinenglish(a)gmail.com>wrote: > On Mon, Aug 30, 2010 at 4:06 PM, Dan Kegel <dank(a)kegel.com> wrote: > > I suppose we'll hear what the goals for 1.4 are at Wineconf, but > > here's my little wish list: > > > > Bug 6971, the mouse problem affecting many FPS-style games (Alexandre > > thinks it would take a month of his time?) > > Solving Wine's problems with Pulseaudio (bug #10495) > > Mono integration similar to the current Gecko integration (go Vincent!) > > Finishing d3dx9_36 and friends (i.e. getting rid of the need to run > > winetricks to load bits of Direct3D9) > > Excellent continuous build and test services at winehq.org, including > > performance tests (ok, this isn't really a wine feature) > > Move away from using 2D graphics acceleration, as Windows has done > > (this is both a superset and a subset of the DIBEngine idea) (heard > > this from Roderick) > > Arabic/Hebrew/other RTL left languages support is improving, that may > be a good candidate. > > Also, complete msvcr/mvscp and friends would be nice. > Rich Edit bugs and performance fixes would also be a nice, Ive not benchmarked it lately but Native Rich Edit use to be about 80% faster then builtin. Tom > -- > -Austin > > > -- Wine is not a conclusion but a process...

Aug. 31, 2010

Re: Wine 1.4 plans?

by Austin English

On Mon, Aug 30, 2010 at 4:06 PM, Dan Kegel <dank(a)kegel.com> wrote: > I suppose we'll hear what the goals for 1.4 are at Wineconf, but > here's my little wish list: > > Bug 6971, the mouse problem affecting many FPS-style games (Alexandre > thinks it would take a month of his time?) > Solving Wine's problems with Pulseaudio (bug #10495) > Mono integration similar to the current Gecko integration (go Vincent!) > Finishing d3dx9_36 and friends (i.e. getting rid of the need to run > winetricks to load bits of Direct3D9) > Excellent continuous build and test services at winehq.org, including > performance tests (ok, this isn't really a wine feature) > Move away from using 2D graphics acceleration, as Windows has done > (this is both a superset and a subset of the DIBEngine idea) (heard > this from Roderick) Arabic/Hebrew/other RTL left languages support is improving, that may be a good candidate. Also, complete msvcr/mvscp and friends would be nice. -- -Austin

Aug. 31, 2010

Chinese translation of key pages on wiki.winehq.org?

by Dan Kegel

Are there any Chinese speakers on the list? Any interest in starting a Chinese translation of wiki.winehq.org? I bring this up because a Chinese user/developer is asking for help getting started with submitting translations to Wine. I think he would find Chinese versions of http://wiki.winehq.org/SubmittingPatches and perhaps even http://wiki.winehq.org/Translating helpful. It seems strange for a translator to need help reading English documents, but perhaps it would help them come up the curve faster. - Dan

Aug. 31, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Andrew Eikum

On 08/30/2010 05:44 PM, Octavian Voicu wrote: > 1. You set color.ui to always and you're using less or another pager > that doesn't support color. You don't need to use a pager in git diff. > Normally, if you set color.ui to auto (or true), then color escape > sequences are only enabled when output is a terminal (not a pipe or > file). > > Instead of `git diff | less' just use `git diff'. If you really want > to use less, `git diff | less -r' should work with colors (-r enables > interpreting color escape codes in less). Git automatically invokes a pager, as given by your 'core.pager' setting (see 'man git-config'). It defaults to 'less'. If you're not getting color, check your LESS environment variable. Unset it to use Git's default settings (which should work with color escape sequences), or set it to something like "-R". See 'man less' for more options, obviously. If the above all seems correct, try a different or newer terminal emulator to help diagnose the problem. Andrew

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Octavian Voicu

On Mon, Aug 30, 2010 at 9:25 PM, David Adam <david.adam.cnrs(a)gmail.com> wrote: > Does not work for me :crying: I voluntary added trailing space to my file. > Nothing appears in red. I obtain in white and black > testcooperativelevels_normal();ESC[m > ESC[32m+ESC[mESC[32m testcooperativelevels_normal_other_ddraw();ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > releasedirectdraw();ESC[m > > I use kconsole. Maybe it is the problem ?? Something that starts with ESC[ is an escape sequence, it clearly shows that git is coloring the output, but your terminal isn't interpreting this. I also use kconsole (konsole actually, KDE terminal emulator right?). I see two possible causes: 1. You set color.ui to always and you're using less or another pager that doesn't support color. You don't need to use a pager in git diff. Normally, if you set color.ui to auto (or true), then color escape sequences are only enabled when output is a terminal (not a pipe or file). Instead of `git diff | less' just use `git diff'. If you really want to use less, `git diff | less -r' should work with colors (-r enables interpreting color escape codes in less). 2. Your terminal is not properly configured and colors don't work. Do you have colors in other commands, like in ls? Maybe this helps: https://bbs.archlinux.org/viewtopic.php?pid=511623 I have $TERM set to xterm. What distribution are you using? Maybe you can google for an answer on how to configure your terminal emulator to work with colors. Octavian

Aug. 30, 2010

Wine 1.4 plans?

by Dan Kegel

I suppose we'll hear what the goals for 1.4 are at Wineconf, but here's my little wish list: Bug 6971, the mouse problem affecting many FPS-style games (Alexandre thinks it would take a month of his time?) Solving Wine's problems with Pulseaudio (bug #10495) Mono integration similar to the current Gecko integration (go Vincent!) Finishing d3dx9_36 and friends (i.e. getting rid of the need to run winetricks to load bits of Direct3D9) Excellent continuous build and test services at winehq.org, including performance tests (ok, this isn't really a wine feature) Move away from using 2D graphics acceleration, as Windows has done (this is both a superset and a subset of the DIBEngine idea) (heard this from Roderick)

Aug. 30, 2010

Re: [1/3] mscoree: Store the AppDomain from CorExeMain, for use in other functions.

by Juan Lang

> Yeah, I'm not really sure how this is supposed to work. load_mono() > ensures that mono is loaded, so mono_handle should be set if it > succeeds. Unless someone calls CorExitProcess in another thread and > unloads it before we can grab the critical section again. > > Maybe load_mono should return without releasing the critical section, > thus preventing that race? The caller will almost always want to > proceed to create an AppDomain afterwards.. Ah, I see, you really did mean that. No, I don't think leaving the critical section open is the best thing. I expect someone calling CorExitProcess should expect problems if they continue to call mscoree functions after that. --Juan

Aug. 30, 2010

Re: [1/3] mscoree: Store the AppDomain from CorExeMain, for use in other functions.

by Vincent Povirk

> Hi Vincent, > > + EnterCriticalSection(&mono_lib_cs); > + if (!mono_handle) > + { > + ERR("CorExitProcess called on another thread?\n"); > + return -1; > you don't release mono_lib_cs here. Doh, thanks. > Similarly, in patch 3, > STDAPI ClrCreateManagedInstance(LPCWSTR pTypeName, REFIID riid, void > **ppObject) > (snip) > + EnterCriticalSection(&mono_lib_cs); > + if (!mono_handle) > + { > + ERR("CorExitProcess called on another thread?\n"); > + return E_FAIL; > > you don't release mono_lib_cs here, and the error message looks suspicious. > --Juan Yeah, I'm not really sure how this is supposed to work. load_mono() ensures that mono is loaded, so mono_handle should be set if it succeeds. Unless someone calls CorExitProcess in another thread and unloads it before we can grab the critical section again. Maybe load_mono should return without releasing the critical section, thus preventing that race? The caller will almost always want to proceed to create an AppDomain afterwards..

Aug. 30, 2010