WWN Issue 62

This is the 62nd release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).

This week, 73 posts consumed 186 K. There were 30 different contributors. 16 (53%) posted more than once. 16 (53%) posted last week too.

The top 5 posters of the week were:

7 posts in 12K by Alexandre Julliard
7 posts in 24K by Francois Gouget
7 posts in 27K by David Howells
6 posts in 12K by Eric Pouech
5 posts in 12K by gerard patel

Wine documentation	15 Sep 2000 00:00:00 -0800	Archive
Jeremy White put out for comment an RFC covering the Wine documentation aspects. This follows the first steps already made (see <kcref>previous issue</kcref>). Jeremy wrote: As part of the Wine 1.0 effort, we've been working on improving the Wine documentation. We have a proposal for a way to overhaul the documentation system, and we'd like some feedback. We start with the following goals: Documentation should be easy to find Documentation should be clear (the user should quickly see the thing that he or she wants, and there should be no confusion as to which document is 'right') Documentation should be consistent (the documentation should look the same whether it is on winehq or on a mirror, or in a tarball). Documentation should be easy to change. We propose the following visible changes: Entry documentation page should be simplified and prioritized Many multiple disconnected (but similar and/or redundant) documents should be merged under a consistent format. Centralize all of the documentation under one CVS point, possibly as a new CVS tree, possibly just as the documentation/ branch of the Wine CVS tree. Switch the FAQ to use a FAQ-O-MATIC, to facilitate updates and changes to it, and to allow the creation of a world editable late breaking bugs section. Jeremy then provided a link to such an experimental page Then, Jeremy proposed some changes in the way documentation is handled; basically, he was keen on having a separate CVS tree dedicated to documentation. Alexandre Julliard strongly preferred to keep the source and documentation trees together, so that changes to the code are reflected to the documentation. Dimitrie O. Paun even suggested to move documentation related to a given DLL into a specific subdirectory of the DLL source. Dimi felt this had several advantages: greater probability of having the docs maintained easier for people to get into the project possibility to maintain the dll separately No final agreement seems to have been reached.

Wine documentation

15 Sep 2000 00:00:00 -0800

Archive

Jeremy White put out for comment an RFC covering the Wine documentation aspects. This follows the first steps already made (see <kcref>previous issue</kcref>). Jeremy wrote: As part of the Wine 1.0 effort, we've been working on improving the Wine documentation.

We have a proposal for a way to overhaul the documentation system, and we'd like some feedback.

We start with the following goals:

Documentation should be easy to find
Documentation should be clear (the user should quickly see the thing that he or she wants, and there should be no confusion as to which document is 'right')
Documentation should be consistent (the documentation should look the same whether it is on winehq or on a mirror, or in a tarball).
Documentation should be easy to change.

We propose the following visible changes:

Entry documentation page should be simplified and prioritized
Many multiple disconnected (but similar and/or redundant) documents should be merged under a consistent format.
Centralize all of the documentation under one CVS point, possibly as a new CVS tree, possibly just as the documentation/ branch of the Wine CVS tree.
Switch the FAQ to use a FAQ-O-MATIC, to facilitate updates and changes to it, and to allow the creation of a world editable late breaking bugs section.

Jeremy then provided a link to such an experimental page

Then, Jeremy proposed some changes in the way documentation is handled; basically, he was keen on having a separate CVS tree dedicated to documentation. Alexandre Julliard strongly preferred to keep the source and documentation trees together, so that changes to the code are reflected to the documentation.

Dimitrie O. Paun even suggested to move documentation related to a given DLL into a specific subdirectory of the DLL source. Dimi felt this had several advantages:

greater probability of having the docs maintained
easier for people to get into the project
possibility to maintain the dll separately

No final agreement seems to have been reached.

Network broadcast issues	18 Sep 2000 00:00:00 -0800	Archive
James Hatheway ran into some networking issues: The app that I am debugging from time to time sends broadcast (255.255.255.255) UDP packets using the winsock function sendto(). On Windows, if the default gateway is not configured, the sendto() function still sends the UDP packet onto the local network. In Linux, if no default gateway is set, sendto() fails with a "network unreachable". Since it is possible to have an isolated local network that isn't connected to the internet, I guess it is possible to not have a gateway configured, so I want to fix WSOCK32_sendto() to be like Windows and handle this. Alexandre Julliard didn't like the proposed fix, and rather suggested to report an explicit error to the user, asking him/her <editorialize>I do need to be politically correct</editorialize> to add an explicit route from 255.255.255.255 to the local network.

Network broadcast issues

18 Sep 2000 00:00:00 -0800

Archive

James Hatheway ran into some networking issues: The app that I am debugging from time to time sends broadcast (255.255.255.255) UDP packets using the winsock function sendto(). On Windows, if the default gateway is not configured, the sendto() function still sends the UDP packet onto the local network. In Linux, if no default gateway is set, sendto() fails with a "network unreachable". Since it is possible to have an isolated local network that isn't connected to the internet, I guess it is possible to not have a gateway configured, so I want to fix WSOCK32_sendto() to be like Windows and handle this.

Alexandre Julliard didn't like the proposed fix, and rather suggested to report an explicit error to the user, asking him/her <editorialize>I do need to be politically correct</editorialize> to add an explicit route from 255.255.255.255 to the local network.

New Wine configuration tool	19 Sep 2000 00:00:00 -0800	Archive
Martin Pilka announced: wine-configuration wizard 0.3beta is now available at http://www.winehq.org/docs/wine-user/config-helper-programs#CONFIG-HELPER-WINECFG It's still an early beta version, so all your comments are welcomed. This is the first implementation of the tool defined earlier on (read <kcref>previous issue</kcref> for the details).

New Wine configuration tool

19 Sep 2000 00:00:00 -0800

Archive

Martin Pilka announced: wine-configuration wizard 0.3beta is now available at http://www.winehq.org/docs/wine-user/config-helper-programs#CONFIG-HELPER-WINECFG

It's still an early beta version, so all your comments are welcomed. This is the first implementation of the tool defined earlier on (read <kcref>previous issue</kcref> for the details).

Bug tracking	21 Sep 2000 00:00:00 -0800	Archive
Douglas Ridgway announced: CodeWeavers has been kind enough to set up a new bug tracking system for Wine using Bugzilla. This will replace the old system. You can see a preview at http://bugs.winehq.org/ , which is supposed to be fully live and the official bug database by the end of this week. The old system is currently only accessible at http://ursula.gmcl.com/Bugs/ and has 500+ existing reports. I can't guarantee that this system will remain accessible beyond the end of the week. It might be worthwhile trying to make sure that important reports are copied into the new system before they are lost / made inaccessible. A big thank you to CodeWeavers for setting up and maintaining this new system. Good bug tracking is a crucial part of making Wine great, and this system promises to be a significant improvement over what it's replacing. Even if it's not fully operational yet, you can still have a look at it.

Bug tracking

21 Sep 2000 00:00:00 -0800

Archive

Douglas Ridgway announced: CodeWeavers has been kind enough to set up a new bug tracking system for Wine using Bugzilla. This will replace the old system. You can see a preview at http://bugs.winehq.org/ , which is supposed to be fully live and the official bug database by the end of this week.

The old system is currently only accessible at http://ursula.gmcl.com/Bugs/ and has 500+ existing reports. I can't guarantee that this system will remain accessible beyond the end of the week. It might be worthwhile trying to make sure that important reports are copied into the new system before they are lost / made inaccessible.

A big thank you to CodeWeavers for setting up and maintaining this new system. Good bug tracking is a crucial part of making Wine great, and this system promises to be a significant improvement over what it's replacing.

Even if it's not fully operational yet, you can still have a look at it.

World Wine News