Wine Traffic

This is the 134th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

News Zack Brown News

This month's CVS drop occured on September 4th. Alexandre noted the following in the announcement:

WHAT'S NEW with Wine-20020904: (see ChangeLog for details)

Much improved PowerPC support.
More correct locale definitions.
Progress on the conversion of handle types to pointers.
Many Visio and Quicken fixes merged from Crossover.
Lots of bug fixes.

A review of WineX 2.1 appeared over on Linux Orbit:

WineX 2.1 is a fairly mature product that gives many Windows games the ability to run on the Linux desktop. Although many programmers see WineX and other translation layers for Windows programs as bad opposed to complete Linux native translations, the end users really won't care that much. If you have a Windows game that you'd like to try with WineX, do a little homework first, and give WineX a try.

A bunch of screenshots were included. Some of them include:

And LinuxPlanet reviewed CodeWeaver's CrossOver Office. The interviewer was especially interested in Quicken's performance.

Also, I'd like to take a second to plug Zack Brown's mailing lists for the Kernel Traffic/Cousins project. It's a great way to find out when an issue comes out. Plus, with the new XML parsers Zack came up with you can get emailed a very nicely formatted version of this page. It prints nicely should you wish to stock your bathroom with some reading material.

Multimedia Transgaming Ove Kåven TransGaming

The Quartz multimedia DLL has been covered in past issues . Most recently I mentioned that TransGaming had a version in their WineX 2.1 tree. Unbeknownst to me, that DLL appears to be the original work of Hidenori Takeshima. Back in May, Hidenori had asked for all of his code to be removed from the various Wine projects due to liability concerns - both ReWind and the LGPL'ed Wine complied. Yet, the code remains out there for anyone who wants to search for it. Tom Wickline asked what was preventing WineX code (LGPL licensed) from being put in the main Wine tree. Lionel Ulmer answered:

Well, as most of the code is LGPLed in there, it could be integrated easily in WineHQ (after clean-up and reimplentation of the APFL parts if any).

Of course, that is, if people want to use some code that the original author explicitely asked us to remove from Wine.

Gavriel State explained:

The WineX head branch hasn't quite had all the license and quartz updating as yet, but you can find the detailed list in the WineX LICENSE file for the winex-2-0-branch CVS branch:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/winex/wine/LICENSE?rev=1.3.2.2

I tried contacting Hidenori for several weeks before we included the quartz code in WineX 2.1, but without success. His email address no longer seems valid, and mail to the postmaster at his domain has gone unanswered. Google searches also turn up very little.

Alexandre has no plans on adding any of Hidenori's code back into Wine, But of course if we didn't want to respect Hidenori's wishes then we wouldn't have the problem at all because the code would still be there. The fact is that Hidenori doesn't want his code distributed, and that's why I have removed it; so I'm not going to add it again just because it went through WineX first. We can certainly include the LGPL parts that have been written by Transgaming (if any, I haven't checked what they did), but not the ones written by Hidenori.

Hidenori appears to still be following the wine-devel list because he replied shortly after the first post:

I'm original developer of quartz. I don't want my quartz code to be restored.

There seems to be many patented algorythms. Many codecs like MPEG-1/2/4 are patented. The ffmpeg library seems to use many patented codes. And the legal state of quartz interfaces is unclear for me. I can't accept any liability.

Please add all codes in CVS explicitly: The code has been removed since the original author requests 'please remove my quartz codes' explicitly. The original author don't accept any liability.

Gav responded with a request for Hidenori to contact him about it. Ove Kåven spoke up for ReWind:

ReWind is X11, not LGPL (it's Wine that's LGPL). Anyway, no, because Hidenori wanted his code to be removed from ReWind, and it was. The reason it's still used in WineX is because Hidenori cited legal issues when asking for their removal, and TransGaming is prepared to deal with the risk of any such legal and licensing issues, which I think the noncommercial projects such as Wine and ReWind do not want to risk. But if Wine wanted to (like if Hidenori said it's ok after all), there would be no problem, there's no AFPL code in quartz, just a few necessary features and many bugfixes to Hidenori's LGPL code (he never agreed to license his patches to ReWind, so it's considered LGPL).

Documentation

Jas Sandys-Lumsdaine wanted to know exactly how much better or worse it was to use native Windows DLL's instead of the corresponding built-in ones. Francous Gouget quickly explained, This very much depends on the application. Some application will work better with the native (Windows) libraries, and some others with the builtin (Wine) libraries. There is no general rule and I think it's even impossible to say with certainty that more applications run with the native libraries (e.g. from a Windows partition) than with the builtin ones.

Jas still didn't understand why native DLL's wouldn't always work:

Assuming native Windows dlls etc are correct (by definition of what Wine's APIs are trying to copy), doesn't this imply the Wine framework (excl. built in dlls) still has issues.

Otherwise, what else could be going wrong when an app fails to run?

Francois explained in more detail:

Windows libraries (e.g. comctl32, shlwapi, etc) use other libraries (e.g. user32, ole32, etc). So if you use the Windows shlwapi library you may end up making calls to the ole32 or user32 library which are not yet completely implemented, especially if it is an undocumented API.

Obviously Wine libraries tend not to call undocumented and/or unimplemented APIs in other libraries, thus sometimes resulting in better behavior.

You will say "why not use only Windows libraries then?" Simply because for some libraries it is not possible. user32.dll is one such library, ntdll.dll, kernel32.dll, socket libraries, sound libraries and DirectX libraries are some others.

Michal Kostrzewa thought of an idea using Wine to support Windows printer drivers:

I'm trying to imagine a method for using windows printer drivers under linux. As far as I know, from gdi's point of view it works like: LoadLibrary(driver) (drv appears to be a dll), some of 24 DDI functions which every printer driver should contain, Initialization = Enable, Control, next goes drawing functions like Output, Pixel. It doesn't have to access paralell ports - it can write to file (when printing under Windows you have this little checkbox, and gdi initializes driver telling this filename I think). Content of this file can be directly sent to port in Linux's way. I know that's not that simple, but I'm very interested in your opinions: what do you think about it having experience in dlling under linux :-) ? I know that wine doesn't run drivers, but it can run win dlls. Is it possible at all? Or this is just a linux-supports-every-printer dream? Perhaps someone tried this already?

Ilja Kamps pointed out that Wine used to support them, but it's has been broken for over a year. Huw Davies pointed toward some code, There's some support for 16 bit printer drivers (note the drivers for win9x are 16 bit). The code is in dlls/gdi/win16drv/ but as you say this may well be broken at the moment.

If you go back to December of 2000 you'll find a discussion between Andi Mohr and Alexandre about breaking the 16-bit drivers.

Marcus Meissner

The LOGFONT structure defines the attributes of a font in Windows. Part of this definition includes things like width and height. It also defines which character set it maps to. Jeff Smith had a question about the character set definitions:

ANSI_CHARSET and SYMBOL_CHARSET need to be defined (in include/wingdi.h), but I have some doubts about the details.

SYMBOL_CHARSET should be defined as (BYTE)2, I believe.

If the current value of DEFAULT_CHARSET as (BYTE)1 is correct, then I suspect ANSI_CHARSET should be (BYTE)0. I question the current value of DEFAULT_CHARSET, and suspect it should be the reverse (DEFAULT:0 ANSI:1). DEFAULT defines tend to be 0 except for a few special cases (and this one does not fit as one of in my book).

I'm sure someone out there is more familiar with this than I am, and I would appreciate their feedback.

Notes:
There is a function in shell32.dll as distributed in Win95-OSR-2.1, that uses the LOGFONT structure. In this function, the structure is used for three fonts: "Times New Roman", "Arial", and "Wingdings". The lfCharSet member for each case is 0, 0, and 2, respectively.

Francois Gouget looked it up and found:

Don't know much about this but the Microsoft headers say that:

ANSI_CHARSET is 0
DEFAULT_CHARSET is 1
SYMBOL_CHARSET is 2

Marcus Meissner pointed out they were already defined in the file Jeff mentioned. He wondered why Jeff didn't have them. Francois replied, They are in mine, but Jeff seems to think they are wrong. All I'm saying is that since they match the Microsoft values they are by definition correct.

Shachar Shemesh pointed out, I think "correct" is too strong a word here. I would go for "conforming".

Andreas Mohr agreed, Well said ! Given Microsoft's biblical documentation "correctness", I can't help but wonder whether we should reject this value order completely and use our own instead ;-))

Testing

Martin Wilck posted a patch for some Winsock tests after figuring out last week why they wouldn't run . In the changelog he noted, This patch is large, but it actually adds no code. The winsock unit tests is just split up over several files, most of which (except simple_test.c, event_test.c) act only as include files.

Alexandre didn't think it should be split up like that and explained, That's not really the usual scheme. It may look that way because we have few tests at the moment, but we can't put each test in a separate file, or we will end up with thousands of them. The right approach is to follow more or less the layout of the source files, that is if two APIs are implemented in the same source file they should be tested in the same test file; so I think the current winsock tests are OK as they are. And in any case #including .c files is strongly discouraged.

Integration Winelib ReactOS

Steven Edwards forwarded an email about getting the system.windows.forms (SWF) classes from Mono running with Winelib:

I have started some discussion with the Mono developers on how to better share our work and they have sent these directions for anyone that is interested in testing Mono with Winelib. There is also a Mono build for Win32 if you want to test it under Wine/ReactOS. I will try and find some free time in the next few weeks to see if I can help with documenting problems or areas our projects can work together better.

Instructions for testing it were attached:

Great to hear there are more people to assist with the work! There is plenty to go around.

My main priority has been getting WineLib to work from a Mono application. In the C# code I have been working mainly with the Application, Form, Control, and NativeWindow classes. I have been trying to get the Form class to work since it is the base for everything in Windows Forms.

In case you do not already know (it was surprise for me!) a WineLib application is a Windows application that is compiled under Unix/Linux as a shared library. This is then started as any other Windows application under Wine using the wine command. You cannot simply link in libwine (gcc myapp.c -lwine).

To get started I suggest installing Wine and Mono first if they are not already installed. I am using the Wine snapshot from 08/04/2002 (Wine-20020804.tar.gz) built from source and installed under /usr/local. Also be sure to build/use a version of Mono with garbage collection disabled as there is a problem using WineLib with garbage collection enabled (check the mono-list archives for this discussion). Then try building the project under System.Windows.Forms/WINELib.

In the makefile you may have set these to the appropriate files and/or paths on your PC:

If you type make from the mcs/class/System.Windows.Forms/WINELib directory it will (hopefully) build:

System.Windows.Forms.dll - The current (if largely incomplete) Windows Forms package.
FormTest.exe, NativeWindowTest.exe, Test.exe - Test applications which link to and tests the System.Windows.Forms.dll
monostub.exe.so - The WineLib application that starts the Mono/WineLib application. This small WineLib application embeds the Mono JIT engine allowing any Mono application running in it access to WineLib/Win32 function calls.

Before starting any of the applications set the LD_LIBRARY_PATH to the current directory so DllImport can find the monostub.exe.so library:


	export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.

To start any of the applications you type (from the WINELib directory):


	wine monostub.exe.so mono-winelibapp.exe

Let me know if you encounter any problems. Sometimes the code I have in CVS has problems with the very latest branch in CVS. As Mono gets better the compiler has picked up my errors better.

Hopefully this is enough to get started. Let me know if you encounter any problems or have any questions. After your environment is ready we can decide how to break down some of the work. Is there anything you are interested in working on?