Wine Traffic #83 For 19 Feb 2001

It's the file create/read/write thats not working. I put a bit of code into file.c:CreateFileA so the UNC files that are on our server get remaped to w:/ files ( where w:/ is a ncpmounted novell directory on my linux box ) so that the normal dos functions should work. Most things work, ie I can see my mail folders but not new mail, ( pegasus email uses single files per new mail, and a index/data pair of files for mail folders ). Also when I try send email to locate users the mail does not get sent for read/write errors. This is because local mail delivery is done by the client program, by writting into the users maildir. How this is done is under novel you can Create files in directories that you cannot see (if that permission is granted to you). But you can't do this under unix. So the need to implement file i/o for novell files arises.

I have my news messages with a reader working under Wine stored on a 4.10 file server since years. It's not exactly fast but I have yet to lose data.

give the Scan file right to the user. Certainly more simple, and this is not a very serious security breakage IMO.

I've just asked for this on my user acc. so i'll see how it works. I still would like the other method, as a general idea the admin was not keen for everybody to be able to scan the mail directory.

I know it was already at least mentioned here - how to provide config file that works without change for more than one application. What do you think about this concept?

The changes to config file are relevant to some sections only. I think these are important:

• [DllDefaults], [DllOverrides]
• [wine] - because of path variable, some programs want to have something specific there
• [x11drv] - for example something runs better in managed mode, something not
• I'm not quite sure about [fonts], [spooler]

So probably we need to make these sections application dependent. when we parse the config file we don't have a lot information about the application we're going to run - in fact the file name only. Anyway that's probably enough. So maybe we could add the new optional sections like [x11drv-homesite*.exe]. The string after "-" sign could be an case insensitive regular expression. When some of this x11drv optional sections match the condition about its filename, it's taken and no more x11drv sections are considered. If not, the default non-optional x11drv section is taken.

I think we shouldn't follow some "inherit" concept because it could dim things a lot. Simple "this and only this section is valid" should be enough.

The problem here is the server. I notice that if you start one application with --managed, all applications started afterwards also get this set, if the server is still active when they start.

I think the server should store its preferences in a process specific area that can be set per-process (but by default would use the .wine/config setup). Everything else should be overridable on the command line, perhaps?

One nice thing about this would be the ability for a (gui?) wine utility to read and change those defaults for a process using server calls. Debug messages could be turned on/off, for example, while the server is still running. Being able to browse the servers process/thread tree, attach a debugger externally etc could also useful.

This would require a small set of 'server browser' calls to be made available, and the current global preferences such as tweak_winelook to be held by the server. However, its a fair bit of work, and unlikely to happen in the immediate future AFAICS.

After discussion we discovered quite big lack of this (EdNote: first) model: maintenance. The config file could easily exceed any reasonable size, and that is something we probably don't want (wine-users: send your config file...).

So here is the revision: Application specific config information could be stored in separate directory (let's say ~/.wine/app-config), one configuration per file. Each file will contain an entry which determines its validity, e.g. "Filename" = "homesite*.exe". Then there will be the [DllOverrides] section and maybe some others.

This breaks wine configuration into two pieces: application independent part (stored in ~/.wine/config, contains drives, paths and all other independent stuff) and application dependent part (stored in ~/.wine/app-config, contains things like [DllOverrides]).

On startup wine will load ~/.wine/config and pass through files stored in ~/.wine/app-config directory. The first match against regular expression defined in these files (Filename=...) causes to overwrite some sections from ~/.wine/config.

The advantage is much easier maintenance. The disadvantage could be that you can't see the whole configuration in ~/.wine/config file anymore - some settings could be overwritten by optional file in ~/.wine/app-config.

I don't know anything about the Win32 print API, but style wise I tend to stay away from alloca(). It screws up exception handling because it messes with the stack, and is machine dependent. Maybe LocalAlloc() would be a better choice?

The general problem with using alloca is that not all platforms supports alloca, however I think all reasonable platforms that has enough power to support Wine is likely to have it so I don't see any real reason not to use it.

Currently Wine uses it indirectly since the files generated by flex/bison uses it.

That said Alexandre has at least once rejected patches from me that used alloca, so he doesn't seem to like it. I don't remember him saying why though.

void foo(void)
{
	char buffer[10*PAGE_SIZE];
	buffer[siezof(buffer) - 1] = '\0';
}

If you know that the allocation will be small you don't need alloca(), you can use a constant-size buffer. And if you don't know the allocation maximum size you cannot use alloca() either because it may crash. So it doesn't buy anything and introduces potential portability problems.

the stack space is limited to 1Mb per thread (unless the application changed the defaults); it's not very tight, but it still means we cannot allocate arbitrary-sized data.

I was hoping to get some feedback from the winelib experts out there on whether this is better than the approach with macros suggested by David.

I had thrown in the idea of being able to prefix the msvcrt functions with something like MSVCRT_ and then linking against a library which forwarded the MSVCRT_function to MSVCRT.DLL.function. Thus using MSVCRT_function in the program would use the MSVCRT implementation, and using just function in the program would use the normal libc function. The idea behind this was the some source files could include header files which #defined function MSVCRT_function, other source files could include normal libc headers. Thus the references are set during compile time and not link time and also would allow you to essentially link to an MSVCRT and a libc within the same program if desired.

with the @ignore directive in your .spec, it is now possible to link with msvcrt and optionally have individual functions resolved to libc

they will then automatically get tested by anybody compiling Wine; while with the other approach they only get tested by people compiling Winelib apps, i.e. just about nobody <grin>

The headers look pretty good and as they are an important part of Winelib I would really like to see them get into CVS. But there's one thing to absolutely do first.

In your email you say "I took the rsxnt headers as a base since they are very uncluttered, and also released without copyright". Well, that's a big problem because if there's no copyright and no license information then we cannot use them, at least under US law. So you/we need to find the author(s) of these headers and get their authorization to use their headers and to release them under a license compatible with the X11 license. I see that a google search on rsxnt seems to give good results so at least contacting the authors should be quite feasible.

it would be good to acknowledge their contribution and let them know their modified code is being used.

While Jon has addressed this issue in regards to the MSVCRT headers, this might be a good time to point out that the legality of enforcing copyright on header files through licensing restrictions is questionable.

I'll preface this with the usual mention of the fact that I am not a lawyer, nor do I play one on TV. Please consult a qualified professional before taking action on anything I've written.

Copyright law does not protect idea, just the expression of them. Several court decisions have been rendered which suggest that the 'purely functional' elements of a computer program are not copyrightable. There are several cases that explicitly deal with the issue of copyright and header files. The most relevant one for Wine development is probably the 1992 decision in Sega v. Accolade, where Accolade reverse engineered the headers for Sega's ROM libraries in order to develop games compatible with Sega's hardware without paying Sega's royalties. ( http://www.eff.org/pub/Legal/Cases/sega_v_accolade_977f2d1510_decision.html") The court in that case said:

Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles -- articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by external factors such as compatibility requirements and industry demands... In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for the purposes of copyright. When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement.

Since Wine absolutely requires the specific header file layout, structure and function names, etc to be the way the Windows headers express them, there is good cause to believe that the header files are unprotected by copyright.

In fact, development tool licenses that attempt to restrict usage of these headers may even constitute anti-trust copyright misuse. Early versions of MS Visual C++ contained a shrinkwrap license that forbade the use of the product to create software for platforms other than Windows. Later revisions (ie: SP3) removed that restriction, so perhaps MS realized that this was not protectable.

One fly in the legal ointment is that while the headers may not be copyrightable, the shrinkwrap license may still be legal as a contract. There's a case where a court suggested that someone who buys a copy of a product that contains a shrinkwrap license agreement and unwraps it is legally bound to follow it, while the person who later finds the unwrapped CD 'on the street' with no such license is allowed to copy the portions that are unprotected by copyright. It's unclear where the anti-trust issue fits in there.

We've recently been working on getting American McGee's Alice (a visually stunning game, if you haven't seen it before) running well under Wine, and we've run into a serious speed issue with synchronization objects like Mutexes.

Currently, Alice runs at about 50% the framerate it gets in Windows with the same graphics driver (NVidia). When we started investigating, it turned out that the reason for this is that it's spending half of it's time in the WineServer. At first we assumed that this was due to the fact that the GL thunks need to grab the X11 lock. We realized that this wasn't necessary for most GL calls if we're using a direct rendering GL implementation, and turned off the locks. There was no effect - because there really wasn't much contention for the x11 lock.

After going through a number of similar Wine internal possibilities and getting nowhere, we finally realized that the problem was the app itself. It's grabbing and releasing a mutex of it's own bazillions of times each frame. Since there's nothing much we can do about that we started thinking about the proposed linux kernel module (EdNote: BROKEN KCREF) approach. After re-reading the thread and looking over the prototype, I have to concur with Alexandre's judgement - the prototype that exists is trying to do too much work.

I don't see how you are going to make this work reliably. A basic design principle of the server is that no matter what a client process does, it cannot break either the server or other clients; given the number of bugs Windows apps contain, I feel this is very important.

As soon as you introduce a shared memory area, you need the collaboration of all clients to ensure the stability of the whole system, since any client can corrupt system data structures. This is very bad. Also since the server is single-threaded its data structures don't need to be protected; but as soon as you manipulate them from multiple threads you need locking mechanisms, which will probably cost a lot in performance too.