As most of you probably know (at least those of you who managed to get out of bed in time for my keynote ;-) we are supposed to release 0.9 real soon now. We do have one remaining issue: the documentation needs some major work. Not every bit of it is critical for the release, but we need to fix at least the User's Guide to reflect the recent configuration changes. Would anybody be interested in helping with that?

To get the docs in a terminal run :

cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/wine co -P docs

When prompted for a password press the enter key. A subdirectory named docs will be created. and you can edit to your hearts content. ;)

Make sure you read over: http://www.winehq.org/site/sending_patches

I put DOCS: at the beginning of the subject when sending this way Dimi can easily pick it out.

I started in on this about a year ago and there's a pretty good outline to work from. Some of the actual content is just plain wrong now, but it's probably about 90% accurate. There have been changes the the DLL Overrides and Drive Settings part of Winecfg. I'd also consider this stuff to be a little light on the configuration side. For example, to configure just application settings you need to add an app on the first tab of winecfg and then make the overrides on the second tab. I don't think this discusses how that per-app stuff is done (it also affects Graphics.)

Last year I sent this to wine-devel talking about it:

--------------------------------

For now, the biggest changes can be found in configuring.sgml (which translates into the "Configuring Wine" part of the guide.) A diff is available here:

http://www.theshell.com/~vinn/wine-user-guide.diff

However, this stuff is best looked at as a side-by-side comparison with the existing docs. You can find that here:

http://www.theshell.com/~vinn/wine-user-guide.html

(Not having looked at Mike's recent patches, I'm sure this will soon be out of date. Things like drive detection are missing. There's also parts that I left undone: such as the printing config, an appendix listing reg keys would be nice once we know what they all are. Other parts probably need a better explanation, such as font configuration. Anything you notice missing is probably worth telling me about, though it won't be hard to find lots of mistakes.)

One of the big goals of all this is to reduce the amount of documentation and outdated stuff. Therefore, registry.sgml, printing.sgml, and fonts.sgml have been somewhat merged into configuring.sgml. fonts.sgml contained a lot of outdated info in it that probably caused more confusion than helped.

Going forward, we have a lot of documentation in the User Guide about downloading Wine, compiling Wine, CVS, etc; mostly stuff that's already duplicated in some form or another on the web site. I'd like to see as much stuff like that removed from the User Guide as possible, we can simply refer people to WineHQ for more info. (I think the reason for the duplication is that the website docs simply didn't exist when the User Guide was written, now the website has superceded the User Guide.) When it's all said and done we should be left with the following sections:

• Introduction
• Configuration
• Running
• Troubleshooting

--------------------------------

what i'm going to try to do is take a shot at simply compiling dcethreads - on win32.

if that _works_ (the tests pass) it'll be great - it will prove two things: 1) that pthreads-win32 works 2) that the dce exception handling will fly, on win32, and _that_ means pretty much zero (urk! let's hope!) work.

for now.

my main goal: "GetItWorking(tm)".

i couldn't care less about binary compatibility for now: i want "services" - i want srvsvcd, i want winregd, i want lsarpcd, i want samrd - all compiled, all working, using TCP/IP.

i can then work on rewriting freedce's ntlmsspauth.so to be a DLL (starting off as my favourite - a stub with username and password of "test").

i can then work on writing an "ncalrpc" plugin transport (which is very straightforward: a matter of filling in about 25 functions in a vector table).

and also on a ncacn_np plugin transport.

"working" means that other people will then be able to focus on issues like binary compatibility.

guys (wine team) i have to say this. you were utterly insane to not use freedce as your starting point - and i am still bewildered by you not even looking at its source code (which is topologically identical in almost all areas, to what you've created) or the opengroup's documentation.

i say that with the greatest of respect for what you've achieved without freedce.

What i have working so far can be found at the freedce-devel sf.net mailing list archives, and as of today, rpcd (the endpoint mapper on port 135) works.

And also when i add a NamedPipes transport (ncacn_np) it will be on \PIPE\epmapper, too. that'll be a fun job. no, really!

Tomorrow's job is to link the echo_server and test that, and if that works, try the echo_client too.

If those work, then the free software community will have its own DCE/RPC reference implementation running on win32.

I decided to give it a try without thinking for a long time, and I've made little progress: I've replaced the old OpenGL interface with a stub which is ready to take calls to WineD3D. I've noticed the following problems so far:

• Headers: WineD3D depends on the d3d8 or d3d9 headers. I've made the check pass with d3d.h, but I had to copy a lot of definitions from d3d9types.h. The thing compiles without errors or warnings now, but there may be side effects I don't know for now.
• Surfaces... You mentioned it, I think I don't need to explain anything here ;-)
• Not a problem, but a suggestion: Does it make sense to have DirectDraw using WineD3D? Without direct access to the video memory it's slow, and DGA has permission problems. Using WineD3D here might make surfaces less trouble, and it could give better performance without needing rw access to /dev/mem.

Where there is a difference between d3d8 and d3d9 headers a new type is created WINED3DFOOBAR and put into include/wine/wined3dtypes.h, this should be easy enough to extend to d3d7.

p.s. the reason for intergrating with ddraw is so that X11Drv works properly with wined3d, this affects things like locking the mouse to a window in full screen mode and being able to Get and Release the DC for the surface.

Ok, what do you guys think.

I have an Arm based machine Running Windows CE. Same machine also runs Linux...

Do you think it can be the same Wine codebase, implementing Both Win32 API as well as WindowsCE API?

What areas must be rewritten (or not) ?

1. Loader
2. HAL (is there an HAL in Wine)
3. Debugging / exceptions

any thing else? Other CPU(s)?

What if I want to do the same but for WindowsCE x86?

Funny how Microsoft uses a totally different set of Headers for CE. Even the Wine-headers are closer to the original SDK than CE. The order of function is different, the macros, the styling. There is no resemblance, not even one name of one parameter. Just the Function name and the Header name. Its like they had a copyright problem and needed to write it from scratch.:)

Now for wine I will not do the same. I'll try to keep the same headers, and where there are ABI differences. Like calling convention parameter sizes.. I'll try to use a macro.

On the implementation side Linux is Linux is Linux so I guess that should work well. But it looks like The Win32 API was shifted around a bit so in CE functions don't sit in the same Dll's as they sit in Win32, and apps are linked differently. So spec files and Makefiles will have to be different.

What I'm afraid of is the things I don't know, which is how x86 is Wine. And how separated is that from the rest of the code.

This patch is written for MSI, but could be adapted to other code. It keeps a linked list of allocated memory and removes free'd memory from the list.

It requires that you change all the HeapAlloc's or mallocs in a dll to msi_alloc (for example), but can detect unfree'd memory and invalid free's.

I have discovered quite a few problems in my own code with this patch, so hopefully somebody else will find it useful too.

First, thanks for fixing so many leaks!

I think that we should concentrate on making valgrind the default leak detection method in Wine, however.

Reasons:

• it catches many, many leaks without any reprogramming effort
• it catches many, many other problems
• it has other tools which are very useful, too (cache profiling, ...)
• it's so much better than any other "clever hack" that people come up with in 2 hours

Thus IMHO valgrind should work perfectly with Wine, and it should be the first thing that pops up when people want to do things like this: IOW it should be documented rather prominently which are some useful ways of using it in combination with Wine.

OTOH we might want to put a safety net in place in case valgrind somehow becomes impossible to use in combination with Wine, so maybe we should investigate a second leak tracer, too.

Or am I completely mistaken here?

Valgrind is great, and I've used it before, but it's a little heavy duty for what I want at the moment.

The main disadvantages are:

• it slows down Wine and programs running Wine. (Office 2003 install already takes a minute or so)
• it doesn't differenciate between Wine leaking memory and a program running in Wine leaking memory
• it requires a patched version of Wine to run
• it isn't built into Wine (ie. I could ship this patch with minimal overhead, and have my users point out memory leaks)
• it has issues following forks, and being run from scripts

The patch is not meant to replace valgrind, just to provide another way of finding problems in Wine code.

How much work is left before printing in Wine is more or less working with most major applications (like, say, Photoshop and Acrobat Reader)?

I have the attached script (exists at ~/bin/wine_envsetup) to set up my environment (assumes wine in ~/wine), but running ~/wine/wine will also work.

You can set up a ~/.wine from the source tree using:

./tools/wineprefixcreate --use-wine-tree .

Then add an alias to set up your environment to your ~/.bashrc, something like this:

export OLDPATH=$PATH alias winehq='. $HOME/bin/wine_envsetup'

You can then run 'winehq' to setup your environment. I find this configuration useful to because I have multiple wine environments, so multiple ~/bin/*_envsetup scripts. It points everything to the right place so that running 'wine' on the command line will run the wine binary from the setup I'm interested in, not a shell script.

Again, you don't need to go to all this trouble if you're happy to run the ~/wine/wine script in the source directory.

#!/bin/sh
# set up the Wine environment

CVSROOT=:pserver:cvs at cvs.winehq.org:/home/wine
PATH=$OLDPATH:$HOME/wine:$HOME/wine/tools/winegcc
WINESERVER=$HOME/wine/server/wineserver
WINELOADER=$HOME/wine/loader/wineloader
WINEPREFIX=$HOME/.cxoffice/default
LD_LIBRARY_PATH=$HOME/wine/libs/unicode:$HOME/wine/dlls:$HOME/wine/libs/wine
WINEDBG=$HOME/wine/debugger/winedbg
WINEDLLPATH=$HOME/wine/dlls:$HOME/wine/programs
export CVSROOT PATH WINESERVER WINEPREFIX LD_LIBRARY_PATH WINEDBG WINEDLLPATH WINELOADER