Wine Traffic #243 For 8 Oct 2004

This is the 243rd issue of the Wine Weekly News publication. Its main goal is to revere Scaled Composites as a bunch of geniuses. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org

There were 47 different contributors. 26 posted more than once. 20 posted last week too.

Last week in the course of Winecfg discussion the topic of automatically detecting which audio drive is needed came up (see WWN issue #242.) James Hawkins offered to take a stab at it, but wanted some input as to how to go about it. Some discussion occurred, then James outlined an idea:

I want to make sure I'm getting the right idea. So I would implement a new audio driver like winealsa, wineoss etc but named something like wineautodetect. This driver is actually a proxy that checks each of the available drivers to see if they are available, and if so, initialize that driver and send all audio messages to the it. Would the registry value for audio driver be wineautodetect instead of winealsa, wineoss etc? If this is how it is to be implemented, nothing in winmm would have to be changed would it? That's what I'm thinking. Are alsa, oss, arts etc the wave out part of winmm? So winmm makes calls to the wineautodetect driver like it would any other driver, and then wineautodetect in turn passes those calls onto the detected driver, right? Ok that's about what I have right now. Let me know if you have any thought, ideas, or suggestions.

The idea was tossed around a bit, then Alexandre spoke up because he thought this was the wrong way to go about it:

I don't think we want to add yet another driver just for autodetection. Each driver should simply refuse to load if its hardware isn't present, then winmm can load each of them in turn until one succeeds.

Eric Pouech pointed out, " you must then ensure that the list of drivers from the registry fits you desired order (e.g. Alsa before OSS, or ESD...)."

There's been a sporadic effort to do an audit of various parts of Wine compared to documented parts of Windows available via MSDN. Basically, when someone last touches a control, for example, it's helpful to take some time and figure out what's missing while it's still fresh in their mind. It also serves as a helpful starting point for the next person. Dimi Paun did an audit of the button code and it prompted Dmitry Timoshkov to remark, " "Button" is a built-in user32 control and has nothing to do with comctl32 at all. Same for all other controls in the dlls/user/ subdirectory. "

Rob Shearman pointed out, " That was true up until Windows XP. All of the built-in user32 controls have now been copied into comctl32 and extended."

Dmitry didn't think that sounded right though, " I can't believe that a simple win32 program linked against user32 only under XP starts to depend on comctl32 as well. user32 in XP can't depend on comctl32 too. "Button", "listbox", "combobox" and others were always a part of user32, moving them into comctl32 would break a lot of apps. Perhaps comctl32 simply subclasses standard user32 controls and adds "skinning" for them?"

Dimi didn't think it really mattered much, " I think they just made a copy into comctl32, but this is more of a gut feel than anything else :) Anyway, MS now documents the standard controls together with the common ones (which makes sense, logically they belong together, they are all controls after all), so my comment is OK for its purpose (which is to correctly identify the piece of documentation that the audit was against)."

It wasn't okay with Dmitry though, " No, your comment is not OK. You are documenting a user32 control, not a comctl32 one. You didn't even confirm where it resides now in XP. I bet it's still in user32."

From there the discussion delved into whether or not it was right to perform an audit against documentation that might differ from the actual implementation in Windows. Dmitry's main concern was that the audit by Dimi added comments in the user32 DLL that directed developers to look at comctl32 documentation. Dimi explained the rationale:

Dmitry, please stop repeating misinformation. Go read the MSDN, I've provided you with the relevant URLs. Here is the situation:

in XP, there are *two* implementations of the standard controls: the old one in user32, and a strict superset, in comctl32. Applications can ask for the one in comctl32 by specifying so in their manifest file. This is done so that applications continue to run on older versions of Windows.
since we don't have the same constrains as MS, and since we can't afford to maintain two versions of the standard controls, we are just going to extend the ones from user32 to the full capability of the ones in comctl32 ver. 6. As such, it make sense to audit them against the comctl32 ver. 6 documentation.

In other words, the comment is right on the money.

With regard to the second point, Rob thought it might be a dicey proposition, " How do you plan on using image lists from user32? How will you make sure that the version 6 behaviour doesn't break older programs? It's these questions that made Microsoft move the controls to comctl32. Will we get ourselves into a bigger mess by not having two separate implementations? "

Dimi replied, " I don't dispute that our current approach is not perfect. You are right, there may be some problems with it, and in the long term, we may have to duplicate them. However, doing so mow would imply a lot of work, and as you can see, we're way short of manpower. From what I've seen, we can safely implement most of the XP functionality into the user32 without risking of breaking stuff. That is to say, I don't see right now a big need to dupicate the controls. Let's cross that bridge when we get there. "

Alexandre didn't weigh in, but he usually gets the last word in. In this case, he committed the patch and it reads:

This code was audited for completeness against the documented features of Comctl32.dll version 6.0 on Oct. 3, 2004, by Dimitrie O. Paun.

Unless otherwise noted, we believe this code to be complete, as per the specification mentioned above. If you discover missing features, or bugs, please note them below.

TODO

Styles
- BS_NOTIFY: is it complete?
- BS_RIGHTBUTTON: same as BS_LEFTTEXT
- BS_TYPEMASK
Messages
- WM_CHAR: Checks a (manual or automatic) check box on '+' or '=', clears it on '-' key.
- WM_SETFOCUS: For (manual or automatic) radio buttons, send the parent window BN_CLICKED
- WM_NCCREATE: Turns any BS_OWNERDRAW button into a BS_PUSHBUTTON button.
- WM_SYSKEYUP
- BCM_GETIDEALSIZE
- BCM_GETIMAGELIST
- BCM_GETTEXTMARGIN
- BCM_SETIMAGELIST
- BCM_SETTEXTMARGIN
Notifications
- BCN_HOTITEMCHANGE
- BN_DISABLE
- BN_PUSHED/BN_HILITE
- BN_KILLFOCUS
- BN_PAINT
- BN_SETFOCUS
- BN_UNPUSHED/BN_UNHILITE
- NM_CUSTOMDRAW
Structures/Macros/Definitions
- BUTTON_IMAGELIST
- NMBCHOTITEM
- Button_GetIdealSize
- Button_GetImageList
- Button_GetTextMargin
- Button_SetImageList
- Button_SetTextMargin

First of all, excuse me for my bad english. But i hope it will be the worst thing that all of you will read here :)) I'm trying to port an industrial application on linux, some people suggested I try to compile it using wine/winelib. I documented myself a bit on it, and i tried to build a sample application (as the user guide tells, winemine :D) but winemaker DOES NOT generate any configure script! wine version is 14/9/2004 and was compiled from source on Slackware 10.0 running on a Via C3 (Intel x86 100% compatibile). Is there any suggestion or workaround, or maybe this is normal, or maybe then i'm forgetting something really stupid? (maybe not so stupid, don't think it makes a difference :D) I also tried to generate by myself a configure script, using tools such as autoscan, autoheader and autoconf, and trying to "fine tune" the output script by hand, but I could not manage to get the application compile. Something tells me i'm not on the right way to compile a greater, more complex program like I have to do :)))

Dimi explained this is normal, " Yes, winemaker no longer generates a configure script. It just generates a Makefile, which you may need to hand edit a bit. Then just type 'make' :)"

Vincent Béron, who recently updated parts of the Winelib User Guide, had some other tips:

The winelib-user-guide was out-of-date for that section. Current cvs version is closer to how it works now.

Try building notepad instead of winemine, following the version at http://cvs.winehq.org/cvsweb/wine/documentation/winelib-intro.sgml (or the doc on winehq.org after the next snapshot is out). Looking at the diff from 1.10 to 1.11 along with the current version on winehq should point you what changed exactly.

Internationalization issues both intrigue me and sometimes confuse me. This one falls mostly in the latter - I don't totally understand the issue involved here. Microsoft has a way of writing programs that can become Unicode-aware in some locales and ANSI-only in others by using a special definitions included in TCHAR.H. Microsoft describes the process like this:

To simplify transporting code for international use, the Microsoft run-time library provides Microsoft-specific "generic-text" mappings for many data types, routines, and other objects. You can use these mappings, which are defined in TCHAR.H, to write generic code that can be compiled for single byte, multibyte, or Unicode, depending on a manifest constant you define using a #define statement. Generic-text mappings are Microsoft extensions that are not ANSI compatible.

In fact, Wine has it's own tchar.h and you can get an idea of how these special definitions work. Well, using this within Wine is apparently bad for reasons I'm not too sure of. (Perhaps simply because Wine itself doesn't have a use for TCHAR and friends. Unicode functions must use Unicode data types, for example.) Winelib programs are the exception.

This week Martin Fuchs posted a patch for Winefile, the Wine file manager program, that used the TCHAR data type to make the program Unicode compatible. Dmitry Timoshkov didn't like that, " 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 didn't think it should be a problem and mentioned that on ReactOS it allowed for a Unicode implementation otherwise it was simply ANSI. Francois Gouget thought everything should be made Unicode aware, but Martin wasn't so sure it was necessary and pointed out some problems:

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.

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...).

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.

Alexandre hasn't committed the patch in question yet so it's unclear whether the practice is acceptable.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	1 Oct 2004 - 6 Oct 2004	(15 posts)	Audio Driver Auto Detection
2.	4 Oct 2004 - 5 Oct 2004	(21 posts)	Button Code Audit
3.	6 Oct 2004	(3 posts)	Changes to Winelib Usage
4.	6 Oct 2004 - 7 Oct 2004	(13 posts)	Using tchar.h in Winelib Programs

Wine Traffic #243 For 8 Oct 2004

By Brian Vincent