wine-devel November 2005

wine-devel@winehq.org

171 participants
353 discussions

GetOpenFileNameA has trouble with UTF-8 locale and UTF-8 encoded pathname
by Alex Villacís Lasso 22 Nov '05

22 Nov '05

Consider the following MSVC program: --------------------- cut ------------------------- // PruebaOpenDlg.cpp : Defines the entry point for the console application. // #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <windows.h> int main(int argc, char* argv[]) { OPENFILENAME ofn; // common dialog box structure char szFile[260]; // buffer for file name // Initialize OPENFILENAME ZeroMemory(&ofn, sizeof(OPENFILENAME)); ofn.lStructSize = sizeof(OPENFILENAME); ofn.hwndOwner = NULL; ofn.lpstrFile = szFile; ofn.nMaxFile = sizeof(szFile); ofn.lpstrFilter = "All\0*.*\0Text\0*.TXT\0"; ofn.nFilterIndex = 1; ofn.lpstrFileTitle = NULL; ofn.nMaxFileTitle = 0; ofn.lpstrInitialDir = NULL; // ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST; // Display the Open dialog box. memset(szFile, 0, sizeof(szFile)); if (GetOpenFileName(&ofn)==TRUE) { char * p; FILE * hFile; printf("Chosen filename is: %s\n", ofn.lpstrFile); printf("Byte encoding is :"); for (p = ofn.lpstrFile; *p; p++) { printf(" (%c %02x)", *p, *p); } printf("\n"); hFile = fopen(ofn.lpstrFile, "rb"); if (hFile != NULL) { fclose(hFile); puts("File is readable through specified filename"); } else { printf("Unable to reach file through %s - %s\n", ofn.lpstrFile, strerror(errno)); } } return 0; } --------------------- cut ------------------------- Consider also the following Linux environment: home directory is /home/alex, and is mapped to drive F: in dosdevices. The home directory contains a directory named gatón (the string contains a [U+00F3 LATIN SMALL LETTER O WITH ACUTE] and is UTF-8 encoded as 0x67 0x61 0x74 0xC3 0xB3 0x6E), inside of which a sample file exists, which is to be selected by the Open File dialog. All tests were made in a Fedora Core 4 system with a *default* LANG=es_EC.UTF-8. The symptom is that, when wine runs with an UTF-8 locale (as specified with the LANG environment variable), and an attempt is made to choose a filename that is UTF-8 encoded in the filesystem, GetOpenFileNameA may return a byte string that CreateFile and other file functions are unable to map into a valid filename. Whether GetOpenFileNameA returns a valid filename or not seems to depend on the way the navigation is performed. That is, if the application starts the Open File dialog from the current directory, and the user navigates by directory change only, the invalid filename will be returned. However, if the user first chooses a drive letter (such as F:) and then navigates from there, the filename returned is a valid one. The following tests illustrate the behavior. For each entry, the first two lines are the conditions for the test. The remaining three lines are the actual output from the supplied program, copied and pasted from the console. The instances of \uffff seen are from invalid character encodings displayed in the console. LANG=en_US From current directory /home/alex: Chosen filename is: f:\gatón\Barenaked Ladies - One Week.mp3 Byte encoding is : (f 66) (: 3a) (\ 5c) (g 67) (a 61) (t 74) (\uffff ffffffc3) (\uffff ffffffb3) (n 6e) (\ 5c) (B 42) (a 61) (r 72) (e 65) (n 6e) (a 61) (k 6b) (e 65) (d 64) ( 20) (L 4c) (a 61) (d 64) (i 69) (e 65) (s 73) ( 20) (- 2d) ( 20) (O 4f) (n 6e) (e 65) ( 20) (W 57) (e 65) (e 65) (k 6b) (. 2e) (m 6d) (p 70) (3 33) File is readable through specified filename LANG=en_US From explicit choice from drive F: : Chosen filename is: F:\gatón\Barenaked Ladies - One Week.mp3 Byte encoding is : (F 46) (: 3a) (\ 5c) (g 67) (a 61) (t 74) (\uffff ffffffc3) (\uffff ffffffb3) (n 6e) (\ 5c) (B 42) (a 61) (r 72) (e 65) (n 6e) (a 61) (k 6b) (e 65) (d 64) ( 20) (L 4c) (a 61) (d 64) (i 69) (e 65) (s 73) ( 20) (- 2d) ( 20) (O 4f) (n 6e) (e 65) ( 20) (W 57) (e 65) (e 65) (k 6b) (. 2e) (m 6d) (p 70) (3 33) File is readable through specified filename LANG=es_EC From current directory /home/alex: Chosen filename is: f:\gatón\Barenaked Ladies - One Week.mp3 Byte encoding is : (f 66) (: 3a) (\ 5c) (g 67) (a 61) (t 74) (\uffff ffffffc3) (\uffff ffffffb3) (n 6e) (\ 5c) (B 42) (a 61) (r 72) (e 65) (n 6e) (a 61) (k 6b) (e 65) (d 64) ( 20) (L 4c) (a 61) (d 64) (i 69) (e 65) (s 73) ( 20) (- 2d) ( 20) (O 4f) (n 6e) (e 65) ( 20) (W 57) (e 65) (e 65) (k 6b) (. 2e) (m 6d) (p 70) (3 33) File is readable through specified filename LANG=es_EC From explicit choice from drive F: : Chosen filename is: F:\gatón\Barenaked Ladies - One Week.mp3 Byte encoding is : (F 46) (: 3a) (\ 5c) (g 67) (a 61) (t 74) (\uffff ffffffc3) (\uffff ffffffb3) (n 6e) (\ 5c) (B 42) (a 61) (r 72) (e 65) (n 6e) (a 61) (k 6b) (e 65) (d 64) ( 20) (L 4c) (a 61) (d 64) (i 69) (e 65) (s 73) ( 20) (- 2d) ( 20) (O 4f) (n 6e) (e 65) ( 20) (W 57) (e 65) (e 65) (k 6b) (. 2e) (m 6d) (p 70) (3 33) File is readable through specified filename LANG=es_EC.UTF-8 From current directory /home/alex: Chosen filename is: f:\gatón\Barenaked Ladies - One Week.mp3 Byte encoding is : (f 66) (: 3a) (\ 5c) (g 67) (a 61) (t 74) (\uffff ffffffc3) (\uffff ffffffb3) (n 6e) (\ 5c) (B 42) (a 61) (r 72) (e 65) (n 6e) (a 61) (k 6b) (e 65) (d 64) ( 20) (L 4c) (a 61) (d 64) (i 69) (e 65) (s 73) ( 20) (- 2d) ( 20) (O 4f) (n 6e) (e 65) ( 20) (W 57) (e 65) (e 65) (k 6b) (. 2e) (m 6d) (p 70) (3 33) Unable to reach file through f:\gatón\Barenaked Ladies - One Week.mp3 - No such file or directory LANG=es_EC.UTF-8 From explicit choice from drive F: : Chosen filename is: F:\gat\uffffn\Barenaked Ladies - One Week.mp3 Byte encoding is : (F 46) (: 3a) (\ 5c) (g 67) (a 61) (t 74) (\uffff fffffff3) (n 6e) (\ 5c) (B 42) (a 61) (r 72) (e 65) (n 6e) (a 61) (k 6b) (e 65) (d 64) ( 20) (L 4c) (a 61) (d 64) (i 69) (e 65) (s 73) ( 20) (- 2d) ( 20) (O 4f) (n 6e) (e 65) ( 20) (W 57) (e 65) (e 65) (k 6b) (. 2e) (m 6d) (p 70) (3 33) File is readable through specified filename Case 5 is incorrect, but is the easiest to hit in the UTF-8 locales. This problem is significant because all Fedora distributions since at least Fedora Core 2 have UTF-8 support, which is probably enabled in non-US locales. Other popular distributions probably have this UTF-8 support enabled too. I am posting this on wine-devel instead of creating a bug report because I wanted to receive some comments on what the expected behavior should be before trying to submit a patch myself. Unless somebody says otherwise, I would try to submit a patch that makes case 5 behave like case 6, by modifying the encoding of the ANSI string to match what the file-open functions would expect for the filename. However, this essentially requires an answer to the following question: should non-Unicode strings that represent filenames be UTF-8 encoded, or locale encoded? In the UTF-8 locales, GetOpenFileNameA seems to think UTF-8 encoded sometimes, but the file open functions expect locale-encoded (in my case is ISO-8859-1). Therefore, the incorrect behavior. How would the answer change (if at all) for Chinese or Japanese locales with a need for multibyte characters? Alex Villacís Lasso

4 6

Re: Wine bug id 3900
by Dimi Paun 22 Nov '05

22 Nov '05

From: " Andrew Webb" <andrew7webb(a)comcast.net> > I think I have the right format for a patch. But if not, please be > patient as its my first attempt. Andrew, it seems to me the patch is wrapped. The easiest way to avoid the wrapping would be to simply attach it as a text file. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Fwd: Re: MBR was destroyed
by seorge 22 Nov '05

22 Nov '05

Please tell me, what exact information should I provide the developers with the experiment described below. I really want to help, but I also don't want to play with my data without understanding what exactly is needed from me. Thanks in advance! ---------- Forwarded Message ---------- > Ok, and can restore ~/.wine dir to previous state (maybe "rm -rf ~/.wine > && wineprefixcreate" would help) and reproduce this bug again, please? I've removed my previous .wine dirrectory, so the only thing I can do is to reproduce everything happend with me yesturday: 1. try to launch some win32 application - this will create .wine 2. try to setup disks and change labels. As I undestand after this experiment I need to send something or at the mailing list from the content of the .wine. Please tell me what it should be.

5 7

Re: error of double click chinese name txt file in softwares (e.g winefile, WinRAR)
by Paul Vriens 22 Nov '05

22 Nov '05

On Tue, 2005-11-22 at 15:02 +0800, mengzhuo li wrote: > ChangeLog: > dlls/kernel/process.c > > limengzhuo muziwind(a)yahoo.com.cn > > fix the error of double clicking chinese name txt file in software > (e.g. winfile). > > it shows the error > wine: cannot open builtin library for L"C:\\windows\\\6d4b\8bd5.txt" > > ______________________________________________________________________ > 无限容量雅虎相册，原图等大下载，超快速度，赶快抢注！ > plain text document attachment > (fix-crash-of-double-click-chinese-name-txt-in-softwares.diff), > "3670824031-fix-crash-of-double-click-chinese-name-txt-in-softwares.diff" > ? fix-crash-of-double-click-chinese-name-txt-in-softwares.diff > Index: dlls/kernel/process.c > =================================================================== > RCS file: /home/wine/wine/dlls/kernel/process.c,v > retrieving revision 1.109 > diff -u -p -r1.109 process.c > --- dlls/kernel/process.c 10 Oct 2005 10:28:48 -0000 1.109 > +++ dlls/kernel/process.c 22 Nov 2005 06:31:07 -0000 > @@ -247,6 +247,8 @@ static BOOL find_exe_file( const WCHAR * > enum loadorder_type loadorder[LOADORDER_NTYPES]; > int i, file_exists; > > + file_exitst = 0; > + Did you actually compile this ? (exists != exitst) Paul.

1 0

Re: error of double click chinese name txt file in softwares (e.g winefile, WinRAR)
by Andreas Mohr 22 Nov '05

22 Nov '05

Hi, On Tue, Nov 22, 2005 at 03:02:16PM +0800, mengzhuo li wrote: > ChangeLog: > dlls/kernel/process.c > > limengzhuo muziwind(a)yahoo.com.cn > > fix the error of double clicking chinese name txt file in software (e.g. winfile). > > it shows the error > wine: cannot open builtin library for L"C:\\windows\\\6d4b\8bd5.txt" Thanks for the patch, but have you actually tested it and verified it to work? The spelling of the variable suggests you haven't... > int i, file_exists; > > + file_exitst = 0; Andreas Mohr

1 0

Re: [wined3d] pixel shader cross compiler [3] resend
by Ivan Gyurdiev 22 Nov '05

22 Nov '05

> +typedef FLOAT D3DMATRIX44[4][4]; > +typedef FLOAT D3DMATRIX43[4][3]; > +typedef FLOAT D3DMATRIX34[4][4]; > +typedef FLOAT D3DMATRIX33[4][3]; > +typedef FLOAT D3DMATRIX32[4][2]; > Are those matrices bigger than they should be, or is this intentional? Also, all the matrices that have size(x)!=size(y) seem backwards to be - maybe I'm misunderstanding, but I think your x and y indices are backwards in functions using m2x3, m3x4 and m4x3, and will segfault (but then again, I haven't tried it, so I could be wrong). Additionally: +void pshader_m3x4(WINED3DSHADERVECTOR* d, WINED3DSHADERVECTOR* s0, D3DMATRIX34 mat) { + d->x = mat[0][0] * s0->x + mat[0][1] * s0->y + mat[0][2] * s0->z; + d->y = mat[2][0] * s0->x + mat[1][1] * s0->y + mat[1][2] * s0->z; + d->z = mat[2][0] * s0->x + mat[2][1] * s0->y + mat[2][2] * s0->z; + d->w = mat[3][0] * s0->x + mat[3][1] * s0->y + mat[3][2] * s0->z; Wrong index, second row. +void pshader_m3x3(WINED3DSHADERVECTOR* d, WINED3DSHADERVECTOR* s0, D3DMATRIX33 mat) { + d->x = mat[0][0] * s0->x + mat[0][1] * s0->y + mat[2][2] * s0->z; + d->y = mat[1][0] * s0->x + mat[1][1] * s0->y + mat[2][2] * s0->z; + d->z = mat[2][0] * s0->x + mat[2][1] * s0->y + mat[2][2] * s0->z; + d->w = 1.0f; + PSTRACE(("executing m3x3(1): mat=(%f, %f, %f) s0=(%f) d=(%f) \n", mat[0][0], mat[0][1], mat[0][2], s0->x, d->x)); + PSTRACE(("executing m3x3(2): mat=(%f, %f, %f) (%f) (%f) \n", mat[1][0], mat[1][1], mat[1][2], s0->y, d->y)); + PSTRACE(("executing m3x3(3): mat=(%f, %f, %f) X (%f) = (%f) \n", mat[2][0], mat[2][1], mat[2][2], s0->z, d->z)); + PSTRACE(("executing m3x3(4): (%f) \n", d->w)); +} Wrong index, second row. In pshader_lrp... I wouldn't know if the 4th row is a bug or not, but I'm suspicious.

2 2

Re: WINEMAILER: a new winelib app
by Alexandre Julliard 22 Nov '05

22 Nov '05

Hans Leidekker <hans(a)it.vu.nl> writes: > Changelog > Added winemailer, a winelib app that wraps the native OS > mail client. I think this could just as well go into winebrowser, it's really a very similar functionality. -- Alexandre Julliard julliard(a)winehq.org

1 0

wine and automation objects
by Curro Amores 22 Nov '05

22 Nov '05

hi, I have an application with Access 97 and i use automation for some aspects. The app runs perfectly but when i want to do something that uses automation it crashes. Anybody could help me? thanks

3 2

windows.h
by Steven Edwards 22 Nov '05

22 Nov '05

Hi All, I don't understand the reason we are still manually including each header in most of the sources. Its like totally incompatible with the latest PSDK unless you add a define for _X86_. We are getting to the point in some of the sources where we might as well just include Windows.h becuase we already include all of the files it includes or close enough to them. Can someone explain the reason to me we are still manually messing with a lot of these headers? Thanks Steven P.S. I have even read threads online where Microsoft's Visual Studio developers tell the users NOT to manually include WinNT, WinBase, etc.

2 1

Licensing and technical issues with a Wine package that includes the Mozilla ActiveX Control
by Scott Ritchie 22 Nov '05

22 Nov '05

Greetings, As part of my work to create the ultimate works-out-of-the-box Wine package, I've begun to ponder the idea of including the Mozilla ActiveX control inside the Wine package. Currently, to install applications that use Internet Explorer internally, such as Steam, the user has to download the Mozilla ActiveX control as a tar file and then manually register the DLL to get Wine to use it (see the Howto in the AppDB entry here: http://appdb.winehq.org/appview.php?versionId=1554 ) Modifying Wine to recognize when the Mozilla ActiveX Control is installed without having to register it manually should be easy enough, however distributing it with the Wine package or as a separate side package presents an unusual licensing issue. Now, the Mozilla ActiveX control is freely licensed, and we can redistribute it however we please. Unfortunately, to make it work in Wine we also need to use the dlls for the Microsoft Foundation Classes that it's written in such as msvcp70.dll, as Wine does not currently implement those. These files have an unusual license. Someone who owns the compiler (such as MSVC 7) is allowed to distribute them, however redistribution further from there isn't necessarily allowed, as the person receiving the file doesn't have a license to redistribute like the EULA for the compiler grants. This doesn't seem to prevent us from giving out the package with the DLL included, however users wouldn't be able to redistribute it. This sounds much like the way the situation is with the NVidia drivers. Would building the package be the right way to go here, with the ultimate destination being the restricted copyright repository in Ubuntu? Or is there something I'm overlooking here (perhaps reading the license wrong)? Thanks, Scott Ritchie

6 7

← Newer
1
...
8
9
10
11
12
13
14
...
36
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel November 2005