Wine Traffic #291 For 23 Sep 

By Brian Vincent

Table Of Contents

Introduction

This is the 291st issue of the Wine Weekly News publication. Its main goal is to fix scripts and hate the new pipermail interface less. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 136 posts in 319K.

There were 50 different contributors. 27 posted more than once. 33 posted last week too.

The top posters of the week were:

1. News: Summer of Code Wrapup

(2 posts) Archive Link: "News"

Topics: News

People: NewsforgeSpecOpsLabsSlashdotNews

Only because I don't want the next news item to get a real headline, I'm going to give a link to Newsforge that mentions Wine (http://programming.newsforge.com/programming/05/09/19/223211.shtml?tid=25&tid=132) in passing. Google's Summer of Code has wrapped up and Chris DiBona had a lot to say about the success of the program.

Given the completely vaporous nature of SpecOpsLabs, I really hate to give them any more publicity than they've already received. However, last week Slashdot published a story about a $10,000 challenge (http://archives.free.net.ph/message/20050921.093916.4717740b.en.html) being offered by the company. The "challenge" itself seems to make absolutely no sense and riddled with enough holes to be unintelligible. Speculation on wine-devel ranged from enthusiastic apathy to amazement that the company was still around.

2. Docs Needed

(16 posts) Archive Link: "Documentation volunteer(s) needed"

Topics: Documentation

People: Alexandre JulliardTom WicklineBrian VincentHolly BostickWineHQDimi Pauncvs

We need help fixing up some docs. Alexandre asked for volunteers this week:

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?

A quick look at Wine's docs (http://www.winehq.com/site/documentation) shows the three guides to be in varying condition. The Developers Guide actually isn't too bad. The User Guide needs some attention. The Winelib Guide, well, it might even be doing more harm than good.

Those three docs are written in SGML, which is quite similar to HTML. We use the Docbook (http://www.docbook.org) schemas to describe the contents. In turn, we can use the Docbook utilities to convert the SGML into whatever we want, such as PDF's, HTML, etc. That documentation used to live within the core Wine CVS tree, but we split it out earlier in the summer. Now it has its own CVS tree and Dimi Paun has been making commits. Tom Wickline described how to get to the docs:

To get the docs in a terminal run :

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

Then I sent a long email describing work I've already done. It's a little outdated, but it's a good starting point:

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:

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

(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:

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

Holly Bostick sounded interested in working on it, but more help is definitely welcome. For example, the part about documenting the various registry keys could be done in parallel.

3. FreeDCE & Wine

(7 posts) Archive Link: "freedce/win32 - making progress."

Topics: RPC / COM / OLE

People: Luke LeightonMike McCormack

Luke Leighton of Samba (and later Samba TNG) infamy has popped on and off wine-devel for several months. Luke has tried to persuade Wine's developers to use the FreeDCE (http://sourceforge.net/projects/freedce) code for RPC. We actually covered this in the past and there's pretty good explanation of the whole process in WWN #258 (http://www.winehq.org/?issue=258#FreeDCE%20&%20Wine%20&%20DCOM) . Now, as you read the threads on wine-devel you'd probably be tempted to take Luke's view that Wine is insane for duplicating all this work. Well, read Mike McCormack's response in that WWN issue - we're really not reinventing a bunch of code. The stuff Wine really needs happens at a different level and there's nowhere to get that from. Wine's DCOM only very recently hooked into the actual RPC code. In theory that means wire-level compatibility could begin to take place.

Now, a lot of Luke's ideas have sort of been taken with a grain of salt. It's one thing to ask others to port 250,000 lines of code to another platform, it's another to prove that it's possible. So apparently Luke is trying to prove that not only can it be done, but that it can be useful. As Luke started down that road, he posted a sort of roadmap:

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.

Then a few days later, he reported some success:

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.

So wait.. what could that mean for Wine? Well, it's not exactly clear to me. Now that our DCOM uses the rpcrt4 library, it could hook into rewritten functions to access Luke's work. I have no idea if real-world applications need anything like that or not.

4. WineD3D and DirectX7

(5 posts) Archive Link: "D3D7 -> WineD3D"

Topics: DirectX

People: Stefan DosingerOliver Stieber

Most modern games use DirectX 8 or 9, and the near-term focus in Wine is to develop that area. Those two versions are relatively similar and can share a lot of functionality. Wine's DX7 and earlier implementations don't share any code with the newer versions. However, the plan that's been discussed is to develop a new library, wined3d, and use it to implement DirectX 9 code. From there, the existing DirectX 8 code can be migrated to it. Then DirectX 7 can be added, etc. Now, the DirectX 9 code is really taking shape and it looks like migrating DirectX 8 is in the works. This week a thread took a bit of a tangent and Oliver Stieber talked a little bit about DX 7 and wined3d. Stefan Dösinger apparently has worked on this a little and gave a quick synopsis of where the scary monsters live:

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:

Oliver didn't think the header issue would be much of a problem:

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.

Stefan followed up later by mentioning he was running into a lot of problems.

5. Wine & WindowsCE

(3 posts) Archive Link: "Windows CE on Wine"

Topics: Ports

People: Boaz HarroshFilip NavaraSteven EdwardsAndreas MohrMicrosoftReactOS

Pop quiz: how many times has Microsoft written the Win32 API? Not one.. not two.. not three.. yup - four different times. Imagine coming up with an API and then being doomed to implement it four different times. For those wanting to keep track, there's the short-lived Win32S, the Win32 of NT, Win32 in Windows 9x, and the baby of the group, Windows CE. As you can imagine, there's no way for perfect compatibility. (Have you seen the "Compatibility Mode" offerings in Windows XP? There's something positively evil lurking in there.)

Boaz Harrosh asked an interesting question this week, one that's surprisingly never come up in the past four years:

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?

Of course someone had already thought about it. Filip Navara replied, " We have already made this experiment once ... you can find info about it in the ros-dev (or ros-kernel) mailing list archives and skeletons of the two WinCE DLLs in the ReactOS SVN history (trunk/reactos/lib/commctrl and trunk/reactos/lib/coredll ... revision ~14000). It was proved that to run simple WinCE/x86 programs all that is needed is to get the loader to accept the WinCE PE signature (which Wine used to ignore and probably still does) and have implementation of the DLLs... "

Steven Edwards also had a tip, " I had to flip the subsystem ID of a WinCE test app using one of the msvc build tools. My sample application just called a message box api. I don't know if any more complex WinCE applications would work due to threading and memory management differences. "

Boaz began working on it and quickly noticed something very strange:

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.

Andi Mohr took a stab at why Windows CE appeared so foreign, " Just an outrageously wild guess: OS/2? Maybe the standard Windows headers were going back to the time where they cooperated with IBM to create OS/2, so they decided to play it safe and create a completely new header set that they would be able to reuse for their main Windows tree in case IBM were to sue them in the very distant future? The same goes for the actual CE source code, I guess."

6. Finding Memory Leaks

(3 posts) Archive Link: "memory leak detection patch"

Topics: Memory Management

People: Mike McCormackAndreas Mohr

Mike McCormack came up with a nice way to find memory leaks in Wine's code. It needs to be adapted for each DLL to make use of it and Mike did it for MSI:

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.

Andi Mohr thought Valgrind would be better:

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:

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?

Mike thought his patch was just another, and in some ways better, way to tackle the problem:

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:

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

7. Printing & Acrobat Reader

(3 posts) Archive Link: "question about the status of the wine printing system"

People: Dan KegelFrancois Gouget

Dan Kegel stumbled across an odd problem, one that fortunately has a good workaround:

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

Francois Gouget described why Acrobat Reader had problems, " I don't know much about printing, but as I was explained it, the problem is that Acrobat Reader uses a special EMF escape to directly send Postscript or something like it to the printer and that does not work right in Wine. As far as I know Acrobat Reader is the only application with this problem."

Well, the solution seems to be to simply use the native Linux Acrobat Reader.

8. Running Wine From Source Tree

(5 posts) Archive Link: "Running Wine from source tree"

Topics: Build Process

People: James LiggettMike McCormackcvs

If you're working on Wine and have a lot of different versions laying around, it might get confusing to actually install it. Not to mention the few extra minutes it takes to do a make install. James Liggett asked, " I'm doing a lot of testing, and I was wondering if I can run Wine from within its source tree without having to reinstall it after every build. If it can be done without conflicting with an existing installation of Wine, how do I do it?"

Mike McCormack gave a quick recipe:

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:

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

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.

 

 

 

 

 

 

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.