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

Re: list view completely mangled in WINE

by Filip Navara

Dan Kegel wrote: > Hi Filip, > if you're looking for testcases, could you try the demo programs in > http://bugs.winehq.org/show_bug.cgi?id=1268 and Sort of works. All the items are displayed, but when I switch to "Large Icons" mode all the items are placed at the position 0,0 above themselves. > http://bugs.winehq.org/show_bug.cgi?id=1404 This one works now. The spacing between the items isn't equal to the one with native COMCTL32, but the items are displayed. Regards, Filip

Aug. 6, 2004

Problem with ITypeInfo

by jack

Hi. I've tryed to run game Project Entropia and I got segmentation fault because of a bug in OLE. I've hacked code and I found two bugs: 1. ITypeInfo has back pointer to ITypeLib, but it's possible (and happened) that ITypeLib is destroyed and later ITypeInfo calls its function. I've solve this problem by call ITypeLib_AddRef while creating ITypeInfo (and ITypeLib_Release while destroying ITypeInfo). 2. ITypeInfo_Invoke doesn't support optional parameters. I've added support for cParamsOpt>0. MSDN says that optional parameter is when VARTYPE equals VT_EMPTY, but in my case it was a VT_BYREF | VT_VARIANT type but the pointer was NULL. When I treated it as VT_EMPTY, it was OK. I enclose my patch. My knownlage about OLE is sparse so I'm not able to test this. Thanks, Jacek

Aug. 6, 2004

Re: vc++ install requires NetUserModalsGet

by Saulius Krasuckas

On Sat, 31 Jul 2004, James Hawkins wrote: > Looking into netapi32/access.c, NetUserModalsGet is a stub and returns > NERR_InternalError by default. I think vcsetup is requiring this call > to succeed so it bails out because of the error. > > Reading the trace and the msdn docs about NetUserModalsGet, vcsetup is > calling with the level parameter == 2 so it is requesting the domain > name and identifier. > > With the included patch, I have stubbed the structure of the 4 levels > that can be queried, but I haven't written the code to handle them > yet. If anyone has any information or links that will enlighten me > about netapi32 or anything pertaining to this matter, I would greatly > appreciate it. I see [1] you've tried to implement the case of NetUserModalsGet() functionality where level == 2, also. Thanks, I need it, too. AFAIK it would suffice only to copy information pointed by the *PPOLICY_PRIMARY_DOMAIN_INFO struct to the *PUSER_MODALS_INFO_2 struct for that, while you have done something very complex IMHO: -NET_API_STATUS WINAPI NetUserModalsGet(LPCWSTR szServer, DWORD level, LPBYTE *pbuffer) +NET_API_STATUS WINAPI NetUserModalsGet(LPCWSTR server, DWORD level, LPBYTE *bufptr) + ... + PPOLICY_ACCOUNT_DOMAIN_INFO domainInfo; + PSID domainIdentifier; + ... + domainNameLen = lstrlenW(domainInfo->DomainName.Buffer) + 1; + ... + NetApiBufferAllocate(domainNameLen * sizeof(WCHAR) + sizeof(PSID), (LPVOID *)bufptr); + + umi = (USER_MODALS_INFO_2 *) *bufptr; + umi->usrmod2_domain_name = (LPWSTR) (*bufptr + sizeof(USER_MODALS_INFO_2)); + umi->usrmod2_domain_id = (PSID) ( + ((PBYTE) umi->usrmod2_domain_name) + domainNameLen * sizeof(WCHAR)); + + lstrcpynW(umi->usrmod2_domain_name, domainInfo->DomainName.Buffer, domainNameLen); + + CopySid(sizeof(umi->usrmod2_domain_id), + umi->usrmod2_domain_id, domainIdentifier); AFAICS: 1, there is big memory block allocated during the call to a NetApiBufferAllocate(). What for? Why just not use a size of a USER_MODALS_INFO_2 ? And yes, then you need to allocate the space twice more - for a string and for the new SID copy. 2, maybe you want to allocate all needed space using a single buffer? Then what does this size mean: "domainNameLen * sizeof(WCHAR) + sizeof(PSID)" ? 3, the domainIdentifier variable is left uninitialized. Does the patch work for you? I know, instead of asking I should sit down and just write some additional tests for the netapi32.dll. What I cannot decide myself here (after having read the MSDN docs) is the responsibility for freeing memory blocks, one allocated for the unicode string (usrmod2_domain_name) and another one to hold the copy of SID (usrmod2_domain_id). MSDN tells only to free the memory allocated for the buffer (pointed by the *bufptr). Every sample of C code on the net I've found which calls NetUserModalsGet() (and where the buffer contains some pointers by itself: USER_MODALS_INFO_1, USER_MODALS_INFO_2) isn't freeing those internal pointers: [2], [3], [4]. Does this mean the code (caller) leaks memory or it's just some automagic used on the system side (callee) to free the memory (on real Windows) later? > quote from MSDN: > "The NetUserModalsGet function retrieves global information for all > users and global groups in the security database, which is the > security accounts manager (SAM) database or, in the case of domain > controllers, the Active Directory." > > Does wine have a security accounts manager or an Active Directory? Good q. Will someone answer it, please? [1] http://www.winehq.org/hypermail/wine-patches/2004/08/0003.html [2] http://www.faqchest.com/msdn/ATL/atl-99/atl-9901/atl-990100/atl99012521_198… [3] http://66.102.11.104/search?q=cache:www.ntdev.org/archive/ntdev9807/msg0256… [4] http://66.102.11.104/search?q=cache:pintday.org/downloads/enum_tar.gz+NetUs…

Aug. 6, 2004

Re: vc++ install requires NetUserModalsGet

by Mike Hearn

Saulius Krasuckas wrote: >>Does wine have a security accounts manager or an Active Directory? > > > Good q. Will someone answer it, please? Wine does not implement any security APIs beyond the stubs needed for apps to work, it delegates security to the host system. Active Directory is not really in scope for Wine, that's more a Samba project, though we'll need to co-operate with them on it at some point (for instance COM can use Active Directory). thanks -mike

Aug. 6, 2004

Re: Different approach to a->w cleanup of crypt

by James Hawkins

On Fri, 6 Aug 2004 02:34:51 -0500, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > I have been trying to get my a->w cleanup of crypt committed for > quite some time now, and mostly with no luck because of all the bugs, > but I have a better idea about how accomplish this. The problem is > that crypt requires a lot of changes to get rid of the w->a calls (the > patch was ~27k), and it's too risky to commit the patch even though it > looks like all the bugs are gone. The solution is that I will change > one piece of crypt at a time and submit small patches that are easier > to find bugs in. There are a number of private functions in crypt > though that cant be changed to unicode because it will break > compilation before the rest of the patches are submitted, so I will > submit unicode patches with a W appended to the name of the function > as in > > static inline PSTR CRYPT_GetProvKeyName(PCSTR pProvName) > static inline PWSTR CRYPT_GetProvKeyNameW(PCWSTR pProvName) //added > > Any public api functions that I change until the final patch will use > the W version while the unchanged version will continue using the > regular ansii version so as to not break compilation. > > Along with the changes, I will also submit tests for the new unicode > api functions so they can be verified to be correct. > > The first patch adds CRYPT_GetProvKeyNameW. > > -- > James Hawkins > > > I forgot to mention that I have tested the new CRYPT_GetProvKeyNameW and it works exactly as the ansii version, but in unicode. -- James Hawkins

Aug. 6, 2004

Different approach to a->w cleanup of crypt

by James Hawkins

Hi, I have been trying to get my a->w cleanup of crypt committed for quite some time now, and mostly with no luck because of all the bugs, but I have a better idea about how accomplish this. The problem is that crypt requires a lot of changes to get rid of the w->a calls (the patch was ~27k), and it's too risky to commit the patch even though it looks like all the bugs are gone. The solution is that I will change one piece of crypt at a time and submit small patches that are easier to find bugs in. There are a number of private functions in crypt though that cant be changed to unicode because it will break compilation before the rest of the patches are submitted, so I will submit unicode patches with a W appended to the name of the function as in static inline PSTR CRYPT_GetProvKeyName(PCSTR pProvName) static inline PWSTR CRYPT_GetProvKeyNameW(PCWSTR pProvName) //added Any public api functions that I change until the final patch will use the W version while the unchanged version will continue using the regular ansii version so as to not break compilation. Along with the changes, I will also submit tests for the new unicode api functions so they can be verified to be correct. The first patch adds CRYPT_GetProvKeyNameW. -- James Hawkins

Aug. 6, 2004

Re: list view completely mangled in WINE

by Dan Kegel

Hi Filip, if you're looking for testcases, could you try the demo programs in http://bugs.winehq.org/show_bug.cgi?id=1268 and http://bugs.winehq.org/show_bug.cgi?id=1404 ? Especially the latter one, which has a tiny MFC demo program in both source code form and precompiled. It misbehaves badly with Wine, and has for years, but perhaps your patch will fix it. Thanks, Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

Aug. 6, 2004

Re: [D3D] Fixed XYZRHW vertex handling

by Christian Costa

Francois Gouget wrote: >--- dlls/ddraw/d3ddevice/mesa_old.c 2004-08-05 15:11:43.000000000 +0100 >+++ dlls/ddraw/d3ddevice/mesa.c 2004-08-05 12:50:45.000000000 +0100 >@@ -1172,7 +1172,7 @@ > glVertex3fv(coords); > } > inline static void handle_xyzrhw(D3DVALUE *coords) { >- if (coords[3] < 1e-8) >+ if ((coords[3] < 1e-8) && (coords[3] > -1e-8)) > glVertex3fv(coords); > else { > GLfloat w = 1.0 / coords[3]; > >This could be a job for fabsf of fabs (might be more portable): > >+ if (fabsf(coords[3]) < 1e-8) > > > > > This is cleaner but it adds an extra call. Since handle_xyzrhw is "call" for each vertex, I would leave it as is. :-) Bye, Christian

Aug. 6, 2004

BeginUpdateResource, UpdateResource and EndUpdateResource

by Vincent Béron

Hi, I'd like to implement those 3 APIs (both the A and W variants) as the process to update the Mozilla installer for a localized build uses them. Anybody has some pointers where to begin? I tried following the FindResourceEx path, but got lost in ntdll. Vincent

Aug. 5, 2004

Re: [D3D] Fixed XYZRHW vertex handling

by Francois Gouget

--- dlls/ddraw/d3ddevice/mesa_old.c 2004-08-05 15:11:43.000000000 +0100 +++ dlls/ddraw/d3ddevice/mesa.c 2004-08-05 12:50:45.000000000 +0100 @@ -1172,7 +1172,7 @@ glVertex3fv(coords); } inline static void handle_xyzrhw(D3DVALUE *coords) { - if (coords[3] < 1e-8) + if ((coords[3] < 1e-8) && (coords[3] > -1e-8)) glVertex3fv(coords); else { GLfloat w = 1.0 / coords[3]; This could be a job for fabsf of fabs (might be more portable): + if (fabsf(coords[3]) < 1e-8) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Aug. 5, 2004

Re: list view completely mangled in WINE

by Tobias Burnus

Hello, Tobias Burnus wrote: > The patch improves the situation a lot! Even Save List works now! > Thanks! I have another strangeness with multi-select lists (e.g. the lists in Diamond but this might affect other lists as well): * I go to a line, press shift and then the arrow keys. If I use arrow down, I can select as many lines as I want. If I use arrow up, I can only select two lines: The line I'm in and the one below, the others further below are unselected as I move upwards. * Multi-select with ctrl doesn't work using the keyboard. Select a line, press ctrl, move up/down to another line and press space. Expected: This line is selected as well. Actual result: Nothing happens (Not a bug, but a missing handy feature: In Windows, double clicking between two column headers (cursor: <-|->) adjusts the column-width so that everything fits. In WINE nothing happens. (Work-around: go to the same place and adjust manually.)) Regards, Tobias, who hopes that the submitted patches get applied to CVS.

Aug. 5, 2004

Is check for WS_THICKFRAME style really needed for sizing?

by Santosh Siddheshwar

Hi, Is the check for windows WS_THICKFRAME style really needed to decide whether a window can be resized or not? I have a scenario where this style is not set but the user can still size the window. This is being done by dispatching WM_SYSCOMMAND messages with SC_SIZE command but WINE is preventing these messages from being effectively handled by returning from the SysCommandSizeMove (winpos.c) method, without doing anything, if the window in question doesnt have this style set. Regards Santosh Siddheshwar ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

Aug. 5, 2004

warning when configuring wine-20040716 on OpenBSD 3.5+

by Angelos D. Keromytis

configure: WARNING: sys/sysctl.h: present but cannot be compiled configure: WARNING: sys/sysctl.h: check for missing prerequisite headers? configure: WARNING: sys/sysctl.h: see the Autoconf documentation configure: WARNING: sys/sysctl.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/sysctl.h: proceeding with the preprocessor's result configure: WARNING: sys/sysctl.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## checking for sys/sysctl.h... yes

Aug. 5, 2004

Fwd:Novell client

by Ivan Leo Puoti

new ad request.

Aug. 4, 2004

Re: Wine and locales

by Shachar Shemesh

David Lee Lambert wrote: >>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. >> >> > >If a program does a an ANSI call, it gets changed to Unicode. If that >data gets passed back to another program using an ANSI call, it gets >converted to the target codepage, as much as possible. If Wine is doing >console output to a non-Unicode codepage, it gets converted there too. > > Ok, you convinced me. Implement that in a way that Alexandre will deem fit for commit, and I won't object too loudly. I do believe that you will not succeed with the first part, however. >I'm not sure about mixing codepages under Windows, but input-method >switching is easy. > > True, but irrelevant. >>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. >> >> > >Let's say I want to run an Arabic dictionary program and Spanish >dictionary program as I'm typing a report in Word. Furthermore, the >arabic dictionary program would use ANSI calls and expects to run on >Arabic windows (with MS-ARAB encoding); the Spanish program would use >LATIN1. Word uses wide-character calls. How would I run all these >programs at the same time under Wine? > > Forget that. How would you run that under Windows? As far as I know, you can't do it there either. Coming from a country where a large portion of the population are native Russian speakers in a country where the dominant language is Hebrew, I'm pretty sure that I'd hear about it if it were possible. >(I'm not saying I actually have such a set of programs. Actually, I own >a copy of a standalone program that allows typing of Arabic programs on >Western windows, and also have access to systems where Office XP with the >Arabic and US-International input methods is installed.) > > Yes. That's because they either use the Unicode interface, or implement their own rendering engine. In short, I think what you're trying is impossible under Windows. I can also see some immediate implications to trying to do it in Wine. If it's important to you, you're welcome at it. It will not enter my personal todo list, however. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 4, 2004

Re: winedos: dos debugger support

by markus.amsler＠oribi.org

Quoting Andreas Mohr <andi(a)rhlx01.fht-esslingen.de>: > What does this patch do? Does it do what I believe it does?? :-) > (finally provide useful debugging for DOS programs launched by Wine?) Yeahp. For Debugging .com files you also have to apply the EXEC fix patch [1]. For line editing support, apply BUFFERED INPUT patch [5]. Tested Debuggers (for more see [2]): - Microsoft's debug.exe - ddeb.exe (my favorite) [3] - debug.com (with source) [4] Markus [1] http://www.winehq.org/hypermail/wine-patches/2004/08/0044.html [2] http://www.programmersheaven.com/zone5/cat188/ [3] http://www.programmersheaven.com/zone5/cat188/26391.htm [4] http://www.programmersheaven.com/zone5/cat188/2025.htm [5] http://www.winehq.org/hypermail/wine-patches/2004/08/0043.html

Aug. 4, 2004

Re: Wine and locales

by David Lee Lambert

On Wed, Aug 04, 2004 at 11:20:57AM +0300, Shachar Shemesh wrote: > 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 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. > > > >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. ... > > > Why should we set it differently than 1? (1) is when a program talks to what it thinks is a version of Windows according to the author's understanding of a the codepage. (2) and (3) are how are how Wine talks to the rest of the system. What codepage should be used under a utf8 locale, such as most of the setups on Redhat WS 9? There are no Windows programs that actually pass utf8 data to the Xxxx*A calls; if a program wants to use Unicode, it will use the wide character APIs. (MS Word, PAF 5, IE 6...) (I know I said UTF16 before. I haven't actually tried a UTF16-only setup, and UTF16 is not compatible with the C library because it uses \0 in normal text, etc.) > 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? I have some files stored on a Windows ME box with names containing accented characters, which show up fine in Explorer and the MS-DOS prompt on that system and on other WinME systems accross the network. In Linux the filenames appear to be encoded in CP437 when I use 'smbmount' whith no options. The manpage says that iocharset= (Linux side) and codepage= (Server side) are only supported in kernel 2.4 and above. However, on my system that runs kernel 2.4.x, the problem persists even when I pass options "iocharset=utf8,codepage=cp437" I get a message about CP437 not being supported, even though I have a kernel module cp437.o . By the way, Explorer and command.com only allow me to enter directories with 8-bit-character-names on the local system. Under Linux, I can enter said directory using tab completion, even though the characters don't show up. > > 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 > 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. Right. > 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. If a program does a an ANSI call, it gets changed to Unicode. If that data gets passed back to another program using an ANSI call, it gets converted to the target codepage, as much as possible. If Wine is doing console output to a non-Unicode codepage, it gets converted there too. I'm not sure about mixing codepages under Windows, but input-method switching is easy. > 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. Let's say I want to run an Arabic dictionary program and Spanish dictionary program as I'm typing a report in Word. Furthermore, the arabic dictionary program would use ANSI calls and expects to run on Arabic windows (with MS-ARAB encoding); the Spanish program would use LATIN1. Word uses wide-character calls. How would I run all these programs at the same time under Wine? (I'm not saying I actually have such a set of programs. Actually, I own a copy of a standalone program that allows typing of Arabic programs on Western windows, and also have access to systems where Office XP with the Arabic and US-International input methods is installed.) -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

Aug. 4, 2004

winedos: TSR (was MCB implementation)

by markus.amsler＠oribi.org

Hi, Quoting Steven Edwards <steven_ed4153(a)yahoo.com>: > Do you have to run FreeCOM? You could run ReactOS cmd.exe. Its based on > FreeCOM but works on Wine already. Perhaps. The main goal isn't running FreeCOM, my goal is TSR (Terminate and Stay Resident) support. I thought, the easiest way to get TSR working, is to start a DOS shell (not a win32 shell), and from there start the TSR programm. After receiving the TSR interrupt, you just haven't to free memory and interrupts, and it stays resident in the DOS Memory.(windows cmd.exe spawns also command.com if you run a TSR programm). So I need a DOS shell. First I tried Windows command.com, without success, it makes heavy use of the BIOS Rom (and is propriatary too). With FreeCOM I had more luck, some TSR's are working more or less. Now, what should happen, if you start a TSR programm in a win32 shell (like wcmd,Reactos cmd.exe or Windows cmd.exe)? Spawn FreeCOM, implement TSR somehow in win32 (shell or ntdll) or no TSR support in win32 shells? Any other ideas? Markus

Aug. 4, 2004

Re: dosmem: MCB implementation

by Steven Edwards

Hi, --- markus.amsler(a)oribi.org wrote: > 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). Do you have to run FreeCOM? You could run ReactOS cmd.exe. Its based on FreeCOM but works on Wine already. Thanks Steven __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

Aug. 4, 2004

rsabase and itunes

by Michael Jung

Rob, I've seen the press release concerning the CrossOver Office iTunes preview and I've noticed that it depends on libcrypto. Im just wondering if your effort with rsabase is related to this? Greetings, Michael -- Michael Jung, MSc Be liberal in what you accept, Integrated Circuits and Systems Lab and conservative in what you send. University of Technology, Darmstadt -- Jonathan Postel, Internet Pioneer phone: +49(6151)16-6692 / email: mjung(a)iss.tu-darmstadt.de

Aug. 4, 2004

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