Table Of Contents
|1.||8�Sep�2002�-�9�Sep�2002||(18 posts)||Patch Submission Tips|
|2.||9�Sep�2002�-�10�Sep�2002||(12 posts)||Direct3D 8 Support|
|3.||8�Sep�2002||(4 posts)||Wine DLLs under Visual C|
|4.||5�Sep�2002�-�8�Sep�2002||(7 posts)||Menu Handling Problems|
|5.||6�Sep�2002�-�7�Sep�2002||(8 posts)||New Header: winternl.h|
This is the 135th 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 229 posts in 730K.
There were 41 different contributors. 28 posted more than once. 21 posted last week too.
The top posters of the week were:
1. Patch Submission Tips
8�Sep�2002�-�9�Sep�2002 (18 posts) Archive Link: "patches policy"
Topics: Project Management, Patches
People: Dimitrie Paun,�Alexandre Julliard,�Jeff Smith,�Eric Pouech,�,�Michael Stefaniuc,�Andriy Palamarchuk,�Patrik Stridvall
Dimi Paun decided to stir things up a bit concerning the patch submission process:
There is something concerning submitting patches that bothers me to no end: inlining vs. attaching them.
I don't know about others, but for me 99/1 rule applies: I at least skim over 99% of the patches inlines in the message, whereas I bother to read at most 1% of the ones attached/tar.gzed/ziped. Maybe I'm an extreme case, but there's got to be more to it than my personal quirks.
If a patch is sent to wine-patches, it's sent there for peer review. If you don't want the review, send it to Alexandre directly, even though I suggest this is avoided as much as possible. However, it you do send it to wine-patches, please, *please* inline it!
What about a nice patch submission policy:
Most of these things are already followed by most people, with the exception of the inlining bit. Alexandre, what about you reject patches that aren't in this format with a pointer to these rules? All this is a matter of habit, and I think we'll all benefit if these rules are followed.
Alexandre opposed outright rejecting of patches:
I don't want to make it a strictly enforced rule, because I think there is a risk of discouraging people, especially occasional contributors. After you have spent hours tracking a bug and writing a patch, it's already hard when the patch is rejected because it's wrong, but if it gets rejected without anybody even looking at it because you didn't use the proper format, that's very discouraging. I think we should try to follow the network rule: be conservative in what you send and liberal in what you accept.
I do admit that it would be nice if frequent contributors could get into the habit of making patches that are easier to read and apply. I'll also note that I tend to deal first with patches that don't require me to do MIME gymnastics, so these are less likely to end up getting forgotten. Maybe that could provide some motivation...
Dimi pointed out his message applied more to regular contributors and was really more of a "strongly desired set of rules" . Some people wondered how to handle the case of a new directory, but Alexandre said not to even worry about it, " Simply diff the new files against /dev/null, patch will create the needed directories automatically." Patrik Stridvall mentioned he currently attached tar files to deal with that case. Michael Stefaniuc mentioned that tar files were particularly inconvenient for him to deal with.
Other people were against inlining patches because their mailers tended to wrap lines or change white space characters. In particular, Andriy Palamarchuk pointed out Yahoo's webmail tended to mess up patches. For that, Jeff Smith suggested adjusting the " "Screen Width" settings in "General Preferences"" . Most people seemed to agree that patches attached as plain text were okay since most mailers tended to inline it when viewed. As far as compressing the text, everyone seemed to agree it was bad and the amount of bandwidth saved wasn't worth it.
Eric Pouech pointed out a perl script in CVS that could be used as
a wrapper to
cvs diff to automate some of the process,
FYI there's the tools/genpatch in the wine tools directory that handles
most of the hassle of patch generation (new files...)...
I did add a few more options... if someone's interested in them, let me
WineHQ's development page (http://www.winehq.com/development/#patches) outlines most of these procedures.
2. Direct3D 8 Support
9�Sep�2002�-�10�Sep�2002 (12 posts) Archive Link: "Direct3D v8"
People: Jason Edmeades,�Alexandre Julliard,�,�Transgaming,�TransGaming
Jason Edmeades put together some initial Direct3D work and wondered if he should submit it to wine-patches. Thus far, all Direct3D support has been done by TransGaming and is available in their AFPL-licensed tree. Jason wrote:
What is the current state of affairs regarding DirectX (8) support in wine. With Transgaming producing a version which appears to work well from what I read on the Internet, what is happening about getting support for it in the wine tree - Is the intention to wait and see what Transgaming do?
The reason I ask - Not to start a political debate with pros and cons of Transgaming, but more because as a learning exercise with regard to 3d graphics, I started fiddling with Direct X 8 support and have some sample code which runs some simple Direct3D samples and most of a sequence of tutorials. (9 out of 11 work reasonably well).
I dont have a problem with the code remaining personal to me and probably archived, as I have learnt a lot by doing it (which was my original aim), but if it is agreed that adding directx 8 support completely different to the Transgaming code is ok, then I may try to submit some patches.
Note the current code is nowhere near ideal, so dont get your hopes up. Specifically, it exports X11DRV_get_client_window from X11DRV as a means of getting the X window from the HWND, which is not clean. It does not use a HAL (which is where the current ddraw code was starting to head), it calls all the opengl calls inline. I have only tested on one machine with one level of mesa (tough! thats all I have). It also has all the c parts in the d3d8 directory, completely seperate (and in some cases duplicating code from the ddraw code), which may or may not be desired. I also dont have a clue about the configure tests and makefile.in, so I have just a basic structure which works enough for me. I'm also relatively certain I havent necessarily used the highest performing code everywhere, I have done the best I could with my limited knowledge.
The way I look at it would be a starting point for others to work from. I could make a drop of the code on a website if anyone wants to see how bad it is first :-)
Anyway, thoughts please?
Alexandre was all for it, " We are not waiting for Transgaming code, we need to develop our own, so by all means submit anything you like. Even if it's to hackish to be included in the tree right now, it can serve as a starting point for others."
Jason wrote back with a couple questions (http://www.winehq.com/hypermail/wine-devel/2002/09/0176.html) and ended with:
Finally Can anyone point me at VERY basic, free programs which use directx 8.? - As examples, I was working through:
Jason submitted a patch (http://www.winehq.com/hypermail/wine-patches/2002/09/0097.html) the next day.
3. Wine DLLs under Visual C
8�Sep�2002 (4 posts) Archive Link: "Wine DLLs compiled under Visual C"
Topics: Build Process
People: Rolf Kalbermatter,�Patrik Stridvall,�,�Patrik Stridval,�Steven Edwards
There's been some work done recently to make Wine DLLs work under Windows. This could be valuable tool for debugging problems with existing built-in functions. Rolf Kalbermatter inquired about the progress:
I want to get some comments about how others here try to get the DLLs compiled under Visual C. I went ahead and tried to do this for shell32.dll and after a little work it went so far fine. However after creating a config.h file for Visual C with a few definitions such as for inline, I had to make some minor changes to some of the c source files such as adding an #include "config.h" and sometimes #include "wine/port.h" to the beginning.
Is this the recommended way of doing things or is there a reason that "config.h" shouldn't be included in some of the dll source files? I ask because I noticed that in a few of the shell32 files it is included but in the several of them it wasn't and in a few it doesn't (yet) need to be.
Patrik Stridvall gave some tips for getting it to compile out of the box:
Use msvcmaker. It generates Visual Studio 6.0 .dsw and .dsp files as well as an include/config.h file.
Then open wine.dsw in Visual Studio.
PS. Note that msvcmaker only runs under Unix. I use Samba to export the directory to Windows.
Steven Edwards wanted to know exactly what the status was and exactly what would currently build. Patrik replied, " The compile status in general is quite good. The link status however is not. A lot more work remains. "
4. Menu Handling Problems
5�Sep�2002�-�8�Sep�2002 (7 posts) Archive Link: "Recent change causes bad QuickBooks behaviour(?)"
People: Carl Sopchak,�Nick Capik,�Andreas Mohr,�
Carl Sopchak reported a problem with Quickbooks:
It's been a few weeks since I've run QuickBooks (8/19 was my last transaction date, so it'd be somewhere around there...). When I went to run it today (after several CVS updates on wine, including "moments ago"), after the company data file is opened, the main menu bar goes away. This was definately NOT a problem the last time I ran QuickBooks, so I surmise that it is the result of a change committed to CVS within the past two to three weeks that is causing this behaviour. It happens in both managed and unmanaged window mode.
Basically, the main menu bar should be at the top of the window, but the configurable taskbar / buttonbar is displayed "over" it. The accellerator keys for the menu bar are no longer recognised (the program beeps if you try to use <alt>f [for example] to get to the File menu).
Nick Capik added, "FWIW, Borland C++ version 5 was also broken in the same way." Andreas Mohr stepped up and claimed responsibility for the behavior, " Probably caused by my changes in the menu handling. Win9x seems to have quite some changes in menu behaviour compared to Win 3.x. The patch I'll send now will fix the problems some apps had with my previous patch, but it's far from the real solution: to implement menu behaviour the Win9x way."
Carl reported the new patch didn't fix the problem. Then after looking in the changes Andi mentioned he found a solution:
It seems that the call to SetWindowLongA to unregister menu on owning window
(per the comments; in the patch committed to CVS it's at "@@ -3842,6 +3844,9
@@") is the culprit. The committed patch had this call done unconditionally.
The patch that you posted a few days ago made the call conditional on
lppop->hWnd). When I commented this out (the condition and call), the menu
"re-appears". So, I guess for now, I'll leave the call out...
5. New Header: winternl.h
6�Sep�2002�-�7�Sep�2002 (8 posts) Archive Link: "New header winternl.h"
People: Patrik Stridvall,�Unknown,�Francois Gouget,�Alexandre Julliard,�,�Patrik Stridval,�Juergen Schmied
Patrik Stridvall posted a patch for a new header file. He explained where it came from:
As you probably know Microsoft released some information as part of the settlement.
As of Microsoft SDKs August 2002 there is a brand new header called winternl.h that contains a part of the relased information.
While the information in itself isn't very useful it is an offical header we should IMHO have in Wine.
Unfortunetly it can't be included at the same time as ntdef.h and ntddk.h because it partly defines the same information.
Now, I have the full Microsoft SDK August 2002 contains over 1000 .h files!!! But ntdef.h and ntddk.h is not among them. They doesn't seem to be offical headers or at least not any more.
So I'm a little unsure on how the headers should be organised. winternl.h contains to little information to fully replace ntdef.h/ntddk.h in fact in some cases of the enums in winternl.h is incomplete but the full enum exists in ntddk.h!!!
Futhermore some of the functions and data structures in ntddk.h is defined in no header in the offical Microsoft SDKs!!!
While we probably should include winternl.h because its an offical header I'm a little unsure on how or whether we should use it ourselves and what we should do with ntdef.h/ntddk.h.
Someone replied to Patrik with their thoughts, " For me this header looks like they copyed some informations from the ntddk in hurry into one file to release it. It's definitely not covering a complete api. We should leave this informations in ntddk.h and replace the winternl.h with a file containing only #include "ntddk.h" if there is some additional information in wintenl.h it shouldn't hurt to merge it into the aprobiate headers." But Patrik pointed out, " The problem is that we don't (and shouldn't) install ntdef.h and ntddk.h but we should do that with wintrnl.h since it is an official header and might be used by a Winelib application. Of course since it first appear a few weeks ago not many application are likely to use it yet..."
For that reason, Juergen Schmied suggested not doing anything at all. He pointed out the SDK has lots of headers not in Wine. Francois Gouget thought some effort should be made though:
Missing headers are making the lives of Winelib users pretty hard: the first time they try to compile their application they get tons of errors. They first wonder what they are doing wrong, then why Wine does things differently from Windows, is there a hidden reason, and then how the hell they are going to fix the headers and their messy dependencies and whether they should not rather completely give up.
Now, I'm not saying we should spend all our time trying to make sure our headers are perfect rather than improving binary emulation. As with everything this is a question of balance.
Now concerning this header, since it's so new (and quite useless) it certainly isn't going to be a problem soon and as you pointed out we definitely have other header issues to tackle first. Still if we can find an easy nice solution, let's go for it (unfortunately that does not appear to be the case).
Alexandre suggested creating it and using:
if we don't use the header it will most likely get broken by something and nobody will notice, and then when someone uses it in Winelib we have the same problem.
I think we should add the header and use it instead of ntddk.h where possible. This probably requires adding/moving definitions to it that are currently in ntddk.h, but that's acceptable as long as they are exported under Windows anyway. And it's better to follow the SDK than the DDK where we can, since this is what apps we want to build with Winelib will be using too.
I have already looked into it a little. However I think most of what is in ntddk.h must be moved into wintrnl.h. Possible some stuff should go in some other wine/*.h header.
Do you want things that is only defined in ntddk.h be protected by
#ifdef __WINE__ so no normal Windows application can't
Alexandre didn't think it was necessary, " No, I don't think there's any reason to prevent applications from using them, as long as the functions are exported under Windows we might as well make them available. This way, when Microsoft finally decides to document them, they can just use our headers ;-)"
A few days later Alexandre committed it to CVS.
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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.