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

Re: Wine and locales

by Shachar Shemesh

David Lee Lambert wrote: >On Wed, Jul 28, 2004 at 10:13:15PM -0700, Alexandre Julliard wrote: > > >>"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: >> >> >> >>>I like the idea of moving that setting to the config file. We can't >>>use existing unix locale settings except LC_ALL and LANG because >>>every user's system might have (and does have) very different locale >>>settings, we can't assume that everyone out there configures locale >>>in the same way. >>> >>> >>I don't see how the settings would be different, surely LC_CTYPE is >>always going to control the ASCII->Unicode mapping on Unix, so why >>shouldn't it do that on Wine? If the issue is that users change their >>setup without understanding the results, then surely adding even more >>config parameters that they need to get right is not going to improve >>the situation. >> >> > >Actually, there are a number of different locale-related things that Wine needs to >keep track of: > >1. ANSI->Unicode translation for programs that use the ANSI calls, as has been >discussed in this thread. > > Ok. >2. Unicode->codepage translation on standard output, and codepage->Unicode >translation on standard input. Note that I could set LANG to 'en_US.UTF-16' on my >Linux system, and programs SHOULD accept this. Most don't, however. > > Why should we set it differently than 1? In any case, I am not aware of UTF-16 being a compilable locale setting. Thus, it is not required that anyone support it. >3. Unicode->codepage->Unicode translation on Linux kernels before 2.4, whereafter >filenames are SUPPOSED TO be in UTF-8, and kernel modules do translation for >filesystems where filenames are stored in some other charset. (OPTIONAL, as >filenames are not a big deal and the newer kernel fixes it--however, there has to >be a converson from the short-per-character format to UTF-8). > > Name one such filesystem, please. EXT and reiser never cared, as far as I know. VFAT has to translate names stored in UTF-16. Are you saying the kernels<2.4 didn't have the "iocharset" option? >4. Selection of approriate language for strings in programs that use such >selection, > Discussed in this thread under the "GetDefaultUILanguage" API. > as well as time, numeric, and string formats. > Also discussed in this thread. > This is all through >GetLocaleInfo(), whose first argument is an LCID returned by either >GetUserDefaultLocale or GetSystemDefaultLocale. > > You can also pass "LOCALE_SYSTEM_DEFAULT" instead, but that doesn't matter. In any case, there are "user overrides" here, which we may, one day, want to implement. Everything is laid out in the table that started this thread. >5. The MultiByteToWideChar() and WideCharToMultiByte() functions, which allow a >program to do its own conversion to and from Unicode with a specified codepage. > > What do we need to do with these? They get an explicit codepage to convert to/from. Funny though it may sound, these functions are not affected by locale. >I think (1) should be specified on a per-program basis in the config file, with a >system default there, and, as final default, raw translation for ANSI-to-Unicode and >something reasonable the other way. I said in another message that codepages are >deprecated; I meant that the ANSI calls (as opposed to (5)) are deprecated for >internationalized applications. > > I don't agree. Mixing default codepages across simultaneously running programs is not possible on Windows, and sounds horribly difficult to implement. Clipboard handling and cross-file using are two examples of things that are likely to go horribly wrong if we tried. Having one setting applicable to all running processes sounds good enough. I don't object to a config setting overriding what LC_CTYPE says, but I don't see a use for it either. >The '.codepage' suffix of LANG and LC_CTYPE should both be searched for the answer >to (2). As for graphical output to X, it doesn't seem like that should be >restricted by setting LANG. > > Again - why should it be different than 1? >For (3) there should be an option in the config file like "filesystem_codepage", but >it should default to utf8. > > We should probably not bother, though. This "problem" is shared by every other Unix program running on the system, and solved the same way there - they use LC_CTYPE. >For (4), Wine should select an appropriate LangID and LCID based on the la_CC tag >and return them, respectively, in response to Get*DefaultLangID and Get*LCID. In >wine, at present, there is not really a seperate 'system' level. > >Furthermore, wine could respond to different groups of GetLocaleInfo() constants >according to LC_MESSAGES, LC_NUMERIC, etc., but this is an unusual feature that >probably isn't needed at first. It seems that using the config-file to define >codepage translation and the suffix for IO charset translation gets rid of the >typical user's need to have other variables besides LANG set. > >Consider locales I might use: > >LANG LCID LangID >---- ---- ------ >en_US 1 9 >es_MX 52 10 >es_US 1 9 >ar_SA 966 1 > >Let's say I have a program that prints "Hello, World" in the current language, using >wide calls. When I run it in Linux, it should print that string out using the >current language and codepage. Suppose I also have a database program that was >written in outer burgoslavia and keeps its data files in the encoding for outer >burgoslavian, which is supported only by Windows 95 for Burgoslavia and Windows >Server 2003. I don't want to change Linux to support Burgoslavian, but if >Burgoslavian is encoded in some Unicode font I can add a section to [AppDefaults] >and let that perticular program think it is running on an all-Burgoslavian system. > >For (5), the functions act the same no matter what locale the user is in. > > > -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 4, 2004

Re: ListView fixes for Diamond (Try 2)

by Robert Shearman

Filip Navara wrote: > Changelog: > - Don't update infoPtr->dwStyle in LISTVIEW_WindowProc. It's already > handled in LISTVIEW_StyleChanged and LISTVIEW_Create processing. > - Ignore WS_VSCROLL/WS_HSCROLL flags in infoPtr->dwStyle because it's > not always up-to-date. > - Fix TOOLBAR_DrawMasked to correctly use image list mask. > > - Filip > >------------------------------------------------------------------------ > >Changelog: >- Don't update infoPtr->dwStyle in LISTVIEW_WindowProc. It's already > handled in LISTVIEW_StyleChanged and LISTVIEW_Create processing. >- Ignore WS_VSCROLL/WS_HSCROLL flags in infoPtr->dwStyle because it's > not always up-to-date. >- Fix TOOLBAR_DrawMasked to correctly use image list mask. > >--- comctl32/listview.c Sat Jul 31 22:07:42 2004 >+++ comctl32/listview.c Wed Aug 4 00:19:30 2004 > > ... >--- comctl32/toolbar.c Sat Jul 31 22:07:14 2004 >+++ comctl32/toolbar.c Wed Aug 4 00:19:34 2004 >@@ -658,8 +658,7 @@ > > /* Create src image */ > hdcImage = CreateCompatibleDC(hdc); >- hbmImage = CreateBitmap(cx, cy, GetDeviceCaps(hdc,PLANES), >- GetDeviceCaps(hdc,BITSPIXEL), NULL); >+ hbmImage = CreateCompatibleBitmap(hdc, cx, cy); > SelectObject(hdcImage, hbmImage); > ImageList_DrawEx(himl, index, hdcImage, 0, 0, cx, cy, > RGB(0xff, 0xff, 0xff), RGB(0,0,0), ILD_NORMAL); >@@ -670,8 +669,8 @@ > SelectObject(hdcMask, hbmMask); > > /* Remove the background and all white pixels */ >- SetBkColor(hdcImage, ImageList_GetBkColor(himl)); >- BitBlt(hdcMask, 0, 0, cx, cy, hdcImage, 0, 0, SRCCOPY); >+ ImageList_DrawEx(himl, index, hdcMask, 0, 0, cx, cy, >+ RGB(0xff, 0xff, 0xff), RGB(0,0,0), ILD_MASK); > SetBkColor(hdcImage, RGB(0xff, 0xff, 0xff)); > BitBlt(hdcMask, 0, 0, cx, cy, hdcImage, 0, 0, NOTSRCERASE); > > > Filip, please put this in a separate patch. Rob

Aug. 4, 2004

Re: Wine and locales

by David Lee Lambert

On Wed, Jul 28, 2004 at 10:13:15PM -0700, Alexandre Julliard wrote: > "Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > > > I like the idea of moving that setting to the config file. We can't > > use existing unix locale settings except LC_ALL and LANG because > > every user's system might have (and does have) very different locale > > settings, we can't assume that everyone out there configures locale > > in the same way. > > I don't see how the settings would be different, surely LC_CTYPE is > always going to control the ASCII->Unicode mapping on Unix, so why > shouldn't it do that on Wine? If the issue is that users change their > setup without understanding the results, then surely adding even more > config parameters that they need to get right is not going to improve > the situation. Actually, there are a number of different locale-related things that Wine needs to keep track of: 1. ANSI->Unicode translation for programs that use the ANSI calls, as has been discussed in this thread. 2. Unicode->codepage translation on standard output, and codepage->Unicode translation on standard input. Note that I could set LANG to 'en_US.UTF-16' on my Linux system, and programs SHOULD accept this. Most don't, however. 3. Unicode->codepage->Unicode translation on Linux kernels before 2.4, whereafter filenames are SUPPOSED TO be in UTF-8, and kernel modules do translation for filesystems where filenames are stored in some other charset. (OPTIONAL, as filenames are not a big deal and the newer kernel fixes it--however, there has to be a converson from the short-per-character format to UTF-8). 4. Selection of approriate language for strings in programs that use such selection, as well as time, numeric, and string formats. This is all through GetLocaleInfo(), whose first argument is an LCID returned by either GetUserDefaultLocale or GetSystemDefaultLocale. 5. The MultiByteToWideChar() and WideCharToMultiByte() functions, which allow a program to do its own conversion to and from Unicode with a specified codepage. I think (1) should be specified on a per-program basis in the config file, with a system default there, and, as final default, raw translation for ANSI-to-Unicode and something reasonable the other way. I said in another message that codepages are deprecated; I meant that the ANSI calls (as opposed to (5)) are deprecated for internationalized applications. The '.codepage' suffix of LANG and LC_CTYPE should both be searched for the answer to (2). As for graphical output to X, it doesn't seem like that should be restricted by setting LANG. For (3) there should be an option in the config file like "filesystem_codepage", but it should default to utf8. For (4), Wine should select an appropriate LangID and LCID based on the la_CC tag and return them, respectively, in response to Get*DefaultLangID and Get*LCID. In wine, at present, there is not really a seperate 'system' level. Furthermore, wine could respond to different groups of GetLocaleInfo() constants according to LC_MESSAGES, LC_NUMERIC, etc., but this is an unusual feature that probably isn't needed at first. It seems that using the config-file to define codepage translation and the suffix for IO charset translation gets rid of the typical user's need to have other variables besides LANG set. Consider locales I might use: LANG LCID LangID ---- ---- ------ en_US 1 9 es_MX 52 10 es_US 1 9 ar_SA 966 1 Let's say I have a program that prints "Hello, World" in the current language, using wide calls. When I run it in Linux, it should print that string out using the current language and codepage. Suppose I also have a database program that was written in outer burgoslavia and keeps its data files in the encoding for outer burgoslavian, which is supported only by Windows 95 for Burgoslavia and Windows Server 2003. I don't want to change Linux to support Burgoslavian, but if Burgoslavian is encoded in some Unicode font I can add a section to [AppDefaults] and let that perticular program think it is running on an all-Burgoslavian system. For (5), the functions act the same no matter what locale the user is in. -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

Aug. 3, 2004

dosmem: MCB implementation

by markus.amsler＠oribi.org

Hi, I'm trying to run freecom[1] of the freedos project in wineconsole. After changing comspec in user.reg and some ugly hacks to kernel/dosmem.c it runs (dosmem_paragraph.patch). But it will never run cleanly without proper MCB support (it does its own MCB-chain walking, like a lot of other programms). I tried to implement it (dos_mcb.patch also ugly), and now i have some design questions: - where to implement MCB's? kernel or winedos? (the PSP from winedos is needed to write the MCB and the first MCB is needed in winedos DOS_LOL[2]) - how to get rid of the separtion hack of DOSMEM[3] - what about the use of DOSMEM in global16.c, do they need also MCB's (found no docu about the GA_DOSMEM flag) Markus [1] http://freedos.sourceforge.net/freecom/FreeCOM.html [2] http://source.winehq.org/source/dlls/winedos/devices.c#L478 [3] http://source.winehq.org/source/dlls/kernel/kernel32.spec#L1164

Aug. 3, 2004

Re: list view completely mangled in WINE

by Filip Navara

Dimitrie O. Paun wrote: [snip] >Almost. If it does go in though, we need to: > -- fix a few more places where we look at WS_[VH]SCROLL > > Ok, I have that done in my local tree and will send it tonight propably. > -- understand why did the listview work at all if the LVS_ stuff was missing > > I tried to run RegEdit with the same version of COMCTL32 and it preserved the listview specific flags. Maybe somebody with access to MFC source code (that is used by the Diamond application) can find out more. The application calls "CCtrlView::CCtrlView(WC_LISTVIEW, WS_VISIBLE | WS_CHILD | WS_BORDER)", so it must propably inject the listview flags later on, but I don't know enough about MFC internals to tell you how it does that (the window procedure of the list view is subclassed BTW). - Filip

Aug. 3, 2004

Re: WININET: take account of dwHeaderLength in HttpSendRequest

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > Does this look better? Strange I didn't get a compiler warning from that... > + if( dwHeaderLength == -1L ) > + len = strlenW(lpszHeaders); > + else > + len = dwHeaderLength; Well, it's better, but really needs a test to verify whether only -1 or any negative value is treated as a hidden strlen. -- Dmitry.

Aug. 3, 2004

Re: WININET: take account of dwHeaderLength in HttpSendRequest

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > ChangeLog: > * take account of dwHeaderLength in HttpSendRequest > - len = strlenW(lpszHeaders)+3; > - szCookedHeaders = HeapAlloc( GetProcessHeap(), 0, sizeof(WCHAR)*len ); > - strcpyW( szCookedHeaders, lpszHeaders ); > + if( dwHeaderLength < 0 ) > + len = strlenW(lpszHeaders); > + else > + len = dwHeaderLength; (dwHeaderLength < 0) is an always true condition, since dwHeaderLength is DWORD, i.e. unsigned long. -- Dmitry.

Aug. 3, 2004

Re: wine metacity and ctrl-alt-del binding - ctrl sticks

by Mike Hearn

This is a well known problem, you don't have to hit ctrl-alt-delete, for many users simply switching virtual desktops or using alt+tab will do it. Unfortunately it seems that Alexandres wm (fvwm?) does not exhibit this issue with Wine .... Grant Williamson wrote: > Curious if there is a patch somewhere for this. > > Running rhel3, gnome-2.2 with metacity. > > 1) Start notepad, type a few characters > 2) hit the keyboard combination ctrl-alt-del ... "gnome-session-kill > --save" is started. > 3) Cancel this option. > 4) Now try typing in Notepad, i.e. hit the keys "s" or "f", its just > like ctrl-s or ctrl-f have been held in. > 5) Hitting ctrl once cancels this. > > Anyone have a patch, to stop this happening? > > >

Aug. 3, 2004

wine metacity and ctrl-alt-del binding - ctrl sticks

by Grant Williamson

Curious if there is a patch somewhere for this. Running rhel3, gnome-2.2 with metacity. 1) Start notepad, type a few characters 2) hit the keyboard combination ctrl-alt-del ... "gnome-session-kill --save" is started. 3) Cancel this option. 4) Now try typing in Notepad, i.e. hit the keys "s" or "f", its just like ctrl-s or ctrl-f have been held in. 5) Hitting ctrl once cancels this. Anyone have a patch, to stop this happening?

Aug. 3, 2004

Re: list view completely mangled in WINE

by Tobias Burnus

Hello, Dimitrie O. Paun wrote: > BTW, I've tried to install the demo, but the installer dies on my > version of wine. Does it work for you, or did you use Windows for > the installation? I used WINE (more precisely CrossOver Office 3.0.1 and CXO nightly) to install the program, which worked flawlessly. Using the CXO config file, it also installed with the WINE CVS version. Tobias

Aug. 3, 2004