Wine Traffic #157 For 14 Feb 2003

So where should a developer go to find good code snippets when writing Wine regression or compliance tests, without running afoul of copyright laws?

One possibility is http://www.codeproject.com. Their submission page, http://www.codeproject.com/info/submit.asp, quite clearly states:

"If you post to CodeProject then you retain copyright of your article and code. You also give CodeProject permission to use it in a fair manner and also permit all developers to freely use the code in their own applications. ... You are more than welcome to submit code that is already published at another site, provided you own the copyright on that article, and provided you have not given the other site exclusive rights to your article."

That sounds like code at CodeProject is fair game. Do other (smarter) people agree? I ask, of course, because I'd like to make sure it'll be ok to submit a testcase based partly on CodeProject code.

I've been poking around inside the wine clipboard system, in an attempt to make it properly compliant with the agreed upon specs over at

http://www.freedesktop.org/standards/clipboards.txt

At the moment, Wine mixes up CLIPBOARD and PRIMARY, which is not a good idea. Ideally, Wine would work like GTK, Qt, Mozilla and all the rest do, which is to keep CLIPBOARD for ctrl-c, ctrl-v type operations, and primary for selected text/middle click.

When you select some text in say notepad, both CLIPBOARD and PRIMARY are grabbed, which is wrong, only primary should be grabbed. In a similar fashion, when you select Edit | Copy only CLIPBOARD should be grabbed.

Currently, selecting text in Wine doesn't do anything (at least, not in notepad). So, the obvious way to fix that would be to introduce a new Wine-specific API, that lets the Wine controls call SetSelectedText or something, which then interfaces with X.

So, I think x11drv/clipboard.c should be changed to basically eliminate references to PRIMARY, as without the ability to deal with middle clicks and grab-on-select, Wine has no business changing that selection.

Therefore my questions are:

1. Should I try and hack up a patch to stop wine using PRIMARY?
2. What are the rules governing new wine specific APIs. I know the DLL Separation work is supposed to eliminate them, but there are no FAQs anywhere on it that I can see, could somebody explain this please?

You may be able to hack some of the controls to support text selection but you won't be able to do it for the general case. For example this wouldn't work in Word. So I don't see this working. In fact it could break assumption made by the application. In my opinion, the only way to copy data from a Windows App to X is via control-c/Clipboard API.

In Windows, to copy data you generally need to select the data (Under X this would grab the PRIMARY selection) and then hit control-c (Under X this would grab the CLIPBOARD selection).

In think we should always be grabbing both PRIMARY and CLIPBOARD and releasing them when we loose either (ClearAllSelections=1). This seemed to be the least confusing for many users as well.

I'm in the process of finishing a large clipboard patch for CodeWeavers that should also address the dll separation issues. Hopefully I'll get the patch together soon and post it to the list.

As you pointed out, if we can't use text selection to pass data via PRIMARY (because Windows apps don't allow this) then it follows that we should only use CLIPBOARD. But when I select and copy text from Word, I want be able to paste it into my xterm! I find this to be a common complaint.

I guess in Wine we have been simulating the selection of data into PRIMARY by assuming that if you copied data into the clipboard you probably selected it.

Your right though, Wine apps may be somewhat unique but at the end of the day its behaviour is non-standard. What does everyone else think? This is one area that most people will have an opinion :)

i always dreamed to have something like the Stanford Checker for Wine and some days ago i've seen on freshmeat smatch. It's a project from KernelJanitors and it seems useful, at least it's worth an entry on Dimi's janitorial page.

A short description:

Smatch is basicaly a patch to gcc-3.1.1 that makes the gcc dump out it's internal represantation of the code and a set of perl modules/scripts to ease the parsing of the dumped code. Most of the perl scripts are for the Linux Kernel but writing new scripts seems to be easy. I wrote (well, mostly adapted an existing script for the kernel) one script http://people.redhat.com/mstefani/wine/smatch/enter_leave.pl (if we decide to adopt smatch it should probably go to $wine/tools/smatch/) to find code path with missing LeaveCriticalSection's. Scripts to find some other usefull things like fd, DC, GDI obejects leaks should be easy to write.

Oddly enough, it looks like it's ok to pass NULL as the filename to CreateNamedPipe. Anyone know what programs do that, and why?

Here's a patch that makes our CreateNamedPipe check for legal filenames (or NULL). It should probably allow forward slashes... The patch also adds a quickie regression test, but I still have to use late binding for CreateNamedPipe (or is it ok for the test to fail on win9x?).

Tests should succeed on all Windows platforms. For platforms where the API is not supported, the individual checks should be skipped. Typically this involves either:

1. either using GetProcAddress if the API is missing altogether on some platforms
2. of calling the API and testing for the error code, usually ERROR_CALL_NOT_IMPLEMENTED

CreateNamedPipe{A,W} exists on Win95 so at most you will need something along the lines of 2.