Wine Traffic #53 For 23�Jul�2000
Table Of Contents
Introduction
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:
- 16 posts in 53K by David Elliott <dfe@infinite-internet.net>
- 13 posts in 30K by Juergen Schmied <juergen.schmied@debitel.net>
- 11 posts in 23K by Ove Kaaven <ovehk@ping.uio.no>
- 10 posts in 32K by Andreas Mohr <a.mohr@mailto.de>
- 6 posts in 125K by Patrik Stridvall <ps@leissner.se>
- Full Stats
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:
- You state that your Winsock 1.1 implementation is at 90%
completion. What has to be done before you call it 100%?
- 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.)
- 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?
- 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.
-
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).
-
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.
-
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.
-
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.com command line
interpreter) found some interesting but strange behaviors:
- the label was in upper-case in Wine (FRANCE), while in
lower-case under Windows (France)
- the serial number was inversed (F156-6DCC instead of CC6D-56F1)
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.
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:
- J�rgen Schmied didn't like the non optional part of the patch
(a link for both Gnome and KDE was always created)
- David Elliot proposed another integration scheme:
Actually, why not just write .lnk files only
(exactly like Windows NT does). Have a "Start Menu\Programs" directory
for each user (in the .wine directory would probably make the most
sense) and also a global "Start Menu\Programs) maybe in something like
/usr/share/wine. Of course this does mean that ~/.wine and
/usr/share/wine will have to be available as Windows drive letters.
Integration with GNOME, KDE, and [insert your desktop environment or
bloated WM of choice here] could be provided by parsing the .lnk
files. GNOME already has AnotherLevel, KDE, and Debian support. IIRC,
KDE can read GNOME's menus. I would envision a "WINE programs" item.
I assume we could provide a generic way of reading the .lnk files and
provide it in an .so that could be used by the different desktops.
The .so should be able to parse the .lnk and return the icon, the name
of the menu, and the tooltip (Noticed that win2k has these). It should
also have a function that will execute the program. It should simply
run wine giving it the command line from the .lnk file.
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?
- first of all, .Default is not really the default keys for
any user, but rather a template that shall be used when a new user is
created. Once a user has been created in the registry, modifications
to the .Default key, are not automatically reported to his HKU
(HKEY_USERS) hive.
- Wine does not provide yet a good mechanism to create a new
user...
- Currently, Wine only uses the HKCU (HKEY_CURRENT_USER),
meaning that every user has its own user.reg file (normally in
~/.wine/user.reg) containing his own settings.
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:
- enhance the Wine installation script for creating the
correct folders locations in HKLM (HKEY_LOCAL_MACHINE)
- fix the SHELL32.DLL to take care of that
- add also some tools to add new users accounts
�
�
�
�
�
�
Sharon And Joy
�