Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #53 For 23�Jul�2000

By Eric Pouech

Table Of Contents


This is the 53rd 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).

Mailing List Stats For This Week

We looked at 139 posts in 550K.

There were 49 different contributors. 27 posted more than once. 22 posted last week too.

The top posters of the week were:

1. OpenGL/Mesa compilation woes

16�Jul�2000�-�17�Jul�2000 (6 posts) Archive Link: "Compilation problem with dlls/ddraw/d3ddevice/mesa.c"

People: Lionel Ulmer,�,�David Elliot

David Elliott reported compilations errors while rebuilding the latest CVS tree (`PFNGLCOLORTABLEEXTPROC' wasn't declared in dlls/ddraw/d3ddevice/mesa.c).

Lionel Ulmer was quite puzzled by the misbehavior:
Could you tell me where you did get your 'glext.h' file ? The OpenGL ABI (now finalized, in its 1.0 version) says that the 'glext.h' file MUST provide, for each extension, the corresponding typedef (as PFNGLCOLORTABLEEXTPROC here). The one from XFree 4.x definitely does.

After some investigations, it turned out that XFree 4.0.0 wasn't fully compliant to the stabilized ABI, whereas XFree 4.0.1 is. Lionel provided later on a patch to detect compliant header file, but also to cope with the issues raised by XFree 4.0.0. This compilation error should be history by now.

2. Winsock status

12�Jul�2000�-�16�Jul�2000 (5 posts) Archive Link: "What's required for 'Winsock' to be 100% complete?"

People: Warren Young,�Ove Kaaven,�,�Ove K�ven,�News

Warren Young wrote:
As maintainer of the Winsock Programmer's FAQ, I have a few interests in WINE's implementation of Winsock:
  1. You state that your Winsock 1.1 implementation is at 90% completion. What has to be done before you call it 100%?
  2. The Wine status page says that the documentation for Winsock in WINE is somewhere between outdated and nonexistent. What do you need? I ask because the freely-available Winsock 2 spec should be enough -- WINE shouldn't need its own docs unless the WINE implementation differs from the spec. (For those who haven't read the Winsock spec, it's more like a reference manual than many specs I've seen; pretty easy reading.)
  3. What does your Winsock 2 provider support today, and what does it need in the near future? I.e., Is there any lack in the Winsock 2 provider stopping you from getting to WINE 1.0?
  4. What about Winsock 2 support beyond 1.0? I imagine that this includes things like overlapped I/O, I/O completion ports, and the Service Provider Interface. Am I close?

    For what it's worth, in the Winsock programming community it's pretty much understood that if you use Winsock 2 features you're almost certainly tying your application to Windows. If WINE can run Winsock 2 programs, that's nice, but I wouldn't ding it too badly in the FAQ if it couldn't. The WINE people should take that to mean that I think their efforts are much better spent elsewhere. Winsock 2 mainly appeals to high-end server app writers and people with major transport/namespace compatibility issues. The former shouldn't be running under WINE, ever, and the latter is a minority of applications.

Ove K�ven gave a point to point answer:
  1. Winsock 1.1 implementation: Well, to implement any routines that remain, and fix remaining bugs... for example, I have strong doubts that OOB data is handled in all cases. Also the blocking behavior could be improved a bit, I'm not sure that it does it correctly in every case either (especially not if OOB data is involved).
  2. Winsock documentation: That docs don't exist doesn't mean that we need it, since there isn't much the user really needs to know about Winsock. But since you ask, to document how the winsock is implemented in Wine (the interaction between the wineserver and the client, what is done where, how it keeps track of socket state, and things like that) could be useful, to unconfuse potential new developers and bughunters in the area.
  3. Winsock 2.0 provider: Right now Wine's Winsock2 does exactly the same as Winsock1 (except that WSAEventSelect is also implemented and available, that is). And other Winsock 2 functionality would definitely not be a release-critical component.
  4. Winsock 2.0 support beyong 1.0: There are no specific plans. People just implement what they want to have. And there are no current efforts on Winsock functionality.

St�phane Lussier (from Macadamiam) just added Macadamiam folks have been working on a patch for WsControl()/WSAIoctl() to discover the name and characteristics of the current interface. Anyway, you should be able to read, sooner or later, from Wine on the Winsock FAQ

3. CD-ROMs information (serial number and label)

16�Jul�2000�-�17�Jul�2000 (11 posts) Archive Link: "CDrom - serial failed"

People: Andreas Mohr,�Rein Klazes,�,�Rein Klaze

Arnaud Atoch, while comparing the 'dir' output (on NT) with the 'dir' output of wcmd (the wine replacement for the command line interpreter) found some interesting but strange behaviors:

Andreas Mohr investigated this further.

On the first point, the issue was quite easily solved:
Many CD-ROMs contain several "volume descriptor" sectors. E.g. one ASCII volume descriptor, one Unicode, one Joliet etc. And NT4 reads the Unicode voldesc (which contains "F\0r\0a\0n\0c\0e\0\0"), whereas Wine read the ASCII voldesc ("FRANCE\0").

Reading from the right descriptor solved the issue.

The second point triggered more thoughts, but Rein Klazes reported:
Tried some CD's on Windows '98, NT4, 2000 and Wine. GetVolInformation() in Windows 2000 and NT4 return serial numbers with the bytes reversed as that on Win'98 and wine.

Strange that we never noticed.

Andreas Mohr wrote a patch for all of this (and he also fixed another bug, which, he said, could help some installers go further).

4. Link files

20�Jul�2000�-�21�Jul�2000 (6 posts) Archive Link: "linux linking"

People: David Elliot,�J�rgen Schmied,�

Brian With-No-Last-Name posted a patch for review. This patch allows to create link files to be added to the menus of KDE or Gnome windows managers. This greatly enhance the integration of Wine into existing desktops: Windows icon files would be directly seen from the desktop.

However, the patch, on his conception, received quite a few comments. Among them:

However, no replies have been made to the proposals, so don't hold your breath for an implementation.

5. Registry implementation details

20�Jul�2000�-�21�Jul�2000 (23 posts) Archive Link: "Missing copy of HKEY_USERS\.Default -> HKEY_CURRENT_USER"

People: Marcus Meissner,�J�rgen Schmied,�,�News

Marcus Meissner requested some information on modification done on the registry code:
Some weeks/months ago the copy of the HKEY_USERS\.Default\ registry subkeys to HKEY_CURRENT_USER was dropped, so that changes in the default are no longer used for the current user.

Was this intentional?

J�rgen Schmied explained what has been done, and gave some further explanations on .Default versus HCU (HKEY_CURRENT_USER) behavior:

J�rgen confirmed that the change Marcus thought about had been intentionally made to closer mimic Windows behavior. But in Marcus' case, Diablo 2 is looking for some folders entries in the HKCU which should have been initialized by explorer.exe (or copied from .Default when the user's account has been created).

The discussion then evolved into the details of administrating Wine in a multiuser environment, which had already been mainly covered by a feature article.

As a conclusion, it turned out that some points related to default folders location would need to be worked upon ; this includes:

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.