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:

• unified diff only (required)
• have a decent subject (recommended)
• a long description (optional, if the change warrants it)
• a meaningful ChangeLog entry (required)
• new files, if any, included in patch, diffed against /dev/null (required)
• patch inlined at the end of the message (required)
• one changeset per message

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.

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...

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?

Finally Can anyone point me at VERY basic, free programs which use directx 8.? - As examples, I was working through:

• http://www.two-kings.de/tutorials/d3d03/d3d03.html Tutorials 3->13, most produce something except 9 and 13 although 7 is wrong
• http://www.codeguru.com/directx/UDirect3D8.html Lighting is wrong but it sort of appears
• http://www.flipcode.com/tutorials/tut_dx8adv2d.shtml Looks about right Please do this via private email, so as not to clutter the wine-devel forum.

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.

Use msvcmaker. It generates Visual Studio 6.0 .dsw and .dsp files as well as an include/config.h file.

cd wine
./tools/winapi/msvcmaker

Then open wine.dsw in Visual Studio.

PS. Note that msvcmaker only runs under Unix. I use Samba to export the directory to Windows.

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).

AH HA!

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...

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.

Any suggestions?

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).

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 use them?