"Martin Fuchs" martin-fuchs@gmx.net wrote:
- use TCHAR to make the code UNICODE compatible
By using TCHAR you actually hide the problem and make the code very hard to maintain. What is the purpose of that in Wine or ReactOS? Why don't you use unicode directly?
"Martin Fuchs" martin-fuchs@gmx.net wrote:
- use TCHAR to make the code UNICODE compatible
By using TCHAR you actually hide the problem and make the code very hard to maintain. What is the purpose of that in Wine or ReactOS? Why don't you use unicode directly?
Come on - is this really that difficult? ;-) And as you see, I will maintain it for you.
Winefile was always UNICODE/ANSI-capable by using TCHAR, TEXT(), and the right functions. Currently ReactOS is using the UNCODE version, and Wine is using the ANSI version. Both without problems.
Regards,
Martin
On Wed, 6 Oct 2004, Martin Fuchs wrote: [...]
Winefile was always UNICODE/ANSI-capable by using TCHAR, TEXT(), and the right functions. Currently ReactOS is using the UNCODE version, and Wine is using the ANSI version. Both without problems.
I think it's wrong that Wine's winefile is ANSI: doesn't that mean we'll have trouble displaying filenames in some cases?
Certainly if it used Unicode on Wine too we would be garanteed not to have the problem...
Hi Francois,
Winefile was always UNICODE/ANSI-capable by using TCHAR, TEXT(), and the right functions. Currently ReactOS is using the UNCODE version, and Wine is using the ANSI version. Both without problems.
I think it's wrong that Wine's winefile is ANSI: doesn't that mean we'll have trouble displaying filenames in some cases?
Some very rare cases - yes may be. Does the Wine implementation deliver UNICODE file names anyhow? UNICODE filenames are mostly only present when using a NTFS drive.
Well, changing Wine's winefile to UNICODE is not as easy as in ReactOS:
- First the problem of TEXT() string constants. They would have to converted to the (IMHO) ugly "WCHAR str = {...}" constants.
- Winefile also reads Unix directories using readdir(). Is there a UNICODE version of this function, or would you have to use some UTF-8 conversion?
OK, this little problems can all be solved, if you want to switch to a UNICODE winefile.
Regards,
Martin
On Thu, 7 Oct 2004, Martin Fuchs wrote: [...]
Hi Francois,
Winefile was always UNICODE/ANSI-capable by using TCHAR, TEXT(), and the right functions. Currently ReactOS is using the UNCODE version, and Wine is using the ANSI version. Both without problems.
I think it's wrong that Wine's winefile is ANSI: doesn't that mean we'll have trouble displaying filenames in some cases?
Some very rare cases - yes may be. Does the Wine implementation deliver UNICODE file names anyhow? UNICODE filenames are mostly only present when using a NTFS drive.
Of course it does if you call the Unicode functions. Unix systems don't store the filenames in Unicode but use codepages. This codepage may be UTF-8 which is equivalent to Unicode or some other codepage. Wine takes care of converting from that codepage to Unicode.
Well, changing Wine's winefile to UNICODE is not as easy as in ReactOS:
- First the problem of TEXT() string constants. They would have to
converted to the (IMHO) ugly "WCHAR str = {...}" constants.
Ugly but working, both in Wine and in Reactos.
- Winefile also reads Unix directories using readdir().
Is there a UNICODE version of this function, or would you have to use some UTF-8 conversion?
There's no Unix function that returns 16bit Unicode characters. But the filenames retrieved from readdir() can easily be converted to Unicode by using MultiByteToWideChar(...CP_UNIX...).
Of course it does if you call the Unicode functions. Unix systems don't store the filenames in Unicode but use codepages. This codepage may be UTF-8 which is equivalent to Unicode or some other codepage. Wine takes care of converting from that codepage to Unicode.
There's no Unix function that returns 16bit Unicode characters. But the filenames retrieved from readdir() can easily be converted to Unicode by using MultiByteToWideChar(...CP_UNIX...).
What happens if two mounted drives want to use different code pages? CP_UNIX is only one constant, and can't handle both cases. I suspect, there is some inherent problem with this approach.
Regards,
Martin
On Thu, 7 Oct 2004, Martin Fuchs wrote: [...]
There's no Unix function that returns 16bit Unicode characters. But the filenames retrieved from readdir() can easily be converted to Unicode by using MultiByteToWideChar(...CP_UNIX...).
What happens if two mounted drives want to use different code pages? CP_UNIX is only one constant, and can't handle both cases. I suspect, there is some inherent problem with this approach.
I don't know the details but I'm told this is not supposed to happen. On a related note, in Wine it used to be possible to specify a codepage per Windows drive but this is no longer possible (again AFAIU).
I'd be happy too if someone can shed some more light on this.
"Francois Gouget" fgouget@free.fr wrote:
What happens if two mounted drives want to use different code pages? CP_UNIX is only one constant, and can't handle both cases. I suspect, there is some inherent problem with this approach.
I don't know the details but I'm told this is not supposed to happen. On a related note, in Wine it used to be possible to specify a codepage per Windows drive but this is no longer possible (again AFAIU).
I'd be happy too if someone can shed some more light on this.
Mount options in Linux are supposed to match current Linux locale.
For instance I'm using the following options in order to see russian file names on FAT drives mounted in Linux:
RH 6.2, KOI8-R locale: codepage=866,iocharset=koi8-r RH 9.0, UTF-8 locale: codepage=866,iocharset=utf8
iocharset option must match current locale, otherwise a user will see a mess instead of the proper file names. And there is no point in specifying different iocharset options for different mount points.
"Martin Fuchs" martin-fuchs@gmx.net writes:
What happens if two mounted drives want to use different code pages? CP_UNIX is only one constant, and can't handle both cases. I suspect, there is some inherent problem with this approach.
No, Unix file names are interpreted according to the Unix codepage, that's how every other Unix program works too.
Note that using ASCII doesn't do anything to address that issue, it's just silently broken. At least switching to Unicode forces you do to the conversions in the right codepage.
"Martin Fuchs" martin-fuchs@gmx.net wrote:
Come on - is this really that difficult? ;-) And as you see, I will maintain it for you.
The problem is not whether you are maintaining it or not. It's about a programming practices in Wine for internal Win32 code. Using TCHAR buys you nothing. That's not you really want to maintain. Why do you need to hide real API names and types?
That approach leads you for instance to the following buggy code: reactos/lib/user32/windows/messagebox.c. A developer who has ported Wine code simply does not see a difference between A and W kind of APIs and types and uses type casts to hide compiler warnings. That code is terribly broken, but it's very hard to find.
"Dmitry Timoshkov" dmitry@baikal.ru writes:
The problem is not whether you are maintaining it or not. It's about a programming practices in Wine for internal Win32 code. Using TCHAR buys you nothing. That's not you really want to maintain. Why do you need to hide real API names and types?
Maybe we should forbid TCHARs in the programs/ directory too...
"Alexandre Julliard" julliard@winehq.org wrote:
The problem is not whether you are maintaining it or not. It's about a programming practices in Wine for internal Win32 code. Using TCHAR buys you nothing. That's not you really want to maintain. Why do you need to hide real API names and types?
Maybe we should forbid TCHARs in the programs/ directory too...
In that case programs should be compiled with __WINESRC__ defined, but that will require to use explicit A/W win32 type and API names.
At one point programs directories were supposed to be a sample for porting existing win32 code to Wine (and that's still the case), so I'm afraid we can't move in that direction (although I'd prefer to not see TCHARs used in the Wine tree).
Come on - is this really that difficult? ;-) And as you see, I will maintain it for you.
The problem is not whether you are maintaining it or not.
Well, you began to talk about maintaining the code:
By using TCHAR you actually hide the problem and make the code very hard to maintain. What is the purpose of that in Wine or ReactOS? Why don't you use unicode directly?
It's about a programming practices in Wine for internal Win32 code. Using TCHAR buys you nothing. That's not you really want to maintain. Why do you need to hide real API names and types?
My programming practice is to use TCHAR and the appropriate function names to get a code that can simple be compiled in both modes. And it's really not difficult. You only have to use some rules.
For example: - Use buffers on the stack to avoid malloc() calls for string buffers: TCHAR buffer[BUFFER_LEN]; - If you need to use dynamic allocation, just do: LPTSTR buffer = (LPTSTR) malloc(len*sizeof(TCHAR)); - Use _tcs... functions or lstr... functions instead of str... functions: _tcslen() or lstrlen() instead of strlen()
Or just use C++ instead of C, then you can hide the internals more easily in a String class.
Using this simple rules you get a program you can use in both versions. Of course if you know, you will only use your program in the UNICODE version, this doesn't make sense. In this case just program it using WCHAR strings.
That approach leads you for instance to the following buggy code: reactos/lib/user32/windows/messagebox.c. A developer who has ported Wine code simply does not see a difference between A and W kind of APIs and types and uses type casts to hide compiler warnings. That code is terribly broken, but it's very hard to find.
Then this is the problem of that developer. He should not use type casts at wrog places to hide compiler warnings.
AJ> Maybe we should forbid TCHARs in the programs/ directory too...
Do what you can't let.
It's just not the same if you code an application, which could be used in both modes (UNICODE/ANSI), or if you code some internal Wine DLL. Using TCHARs there doesn't make sence, yes.
Let's finish this discussion here. I see it does not lead to some usefull end.
Martin
-
Alexandre Julliard -
Dmitry Timoshkov -
Francois Gouget -
Martin Fuchs