Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #220 For 23 Apr 2004

By Brian Vincent

Table Of Contents


This is the 220th issue of the Wine Weekly News publication. Its main goal is to buy mosquito repellent. 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

Mailing List Stats For This Week

We looked at 279 posts in 1033K.

There were 80 different contributors. 44 posted more than once. 32 posted last week too.

The top posters of the week were:

1. Visual FoxPro

16 Apr 2004 - 17 Apr 2004 (4 posts) Archive Link: "Visual FoxPro"


People: Cecil ChampenoisSteven EdwardsDuane ClarkPaul McNettMicrosoftFox

It's been a while since Visual Foxpro on Wine has been in the news, but this week Cecil Champenois wondered about the status of using it:

I have heard that there is a lot of interest in moving the WINE for Visual FoxPro forward. About a year ago, a major FoxPro developer by the name of Whil Hentzen was telling our User Group about the Visual FoxPro work you are doing with WINE. He also demonstrated Visual FoxPro working on a Linux laptop. We were all very impressed by this and wanted to jump right into development but were told that the conversion or whatever you want to call it was at least 1 to 1.5 years away. This discouraged us a bit, so what we'd like to know is this: Where does the WINE work in relation to VFP 6, 76 and 8 stand now?

We would like to begin some development in Linux, but need to know where the WINE work stands at this time and what the future looks like.

Steven Edwards didn't think there was a technical issue involved, " I have heard a lot of good reports of FoxPro working with WINE but the last major issue I heard was that Microsoft was restricting the redistribution of the FoxPro runtime on Non-Microsoft platforms. It seems they dont like people writting apps with thier tools for non-windows platforms <g>. I cant find a link to this information though so I could be mistaken or they may have amended the EULA to allow this type of redistrabtution like in the case of MFC and ATL. "

Duane Clark had a tip about where to find more info:

There is quite a bit of detailed info on the status of Wine with VFP in the Wine application database:

That is probably a pretty good starting point.

Paul McNett has done a lot of work running FoxPro with Wine and has a web page titled, HOWTO: Install Visual Foxpro on Linux/Wine. He also put together a much longer whitepaper on the subject.

2. Distributed Testing

20 Apr 2004 - 22 Apr 2004 (40 posts) Archive Link: "Winetest results uploaded... where?"

Topics: Testing

People: Dimitrie Paun

About a month ago we touched on a new distributed testing environment being set up (see issue #216 for a brief overview.) Things have been a bit stalled as some of the build components have been broken and various patches needed to get upstreamed. Now things are beginning come together and some preliminary results are available. Dimi provided a link for people to see a preview:

Look into:

Todays test results can be found here:

Right now this is still in development mode. Most of the harder parts are complete. Within the next few weeks we'll make available a client that can be downloaded to Windows computers and run as a service. Then nightly tests will be automatically distributed to them so Wine's regression testing suite can run on them. All of the results will be available on WineHQ.

The purpose of doing this is to collect more stastics about how Windows behaves compared to the way we think it behaves. Most developers have only limited access to Windows systems, and certainly none of them have each and every single version of Windows. By writing small tests and integrating them into the test system we'll be able to find out how well they really run on Windows.

A further advantage is that only knowledge of Win32 is required to write tests. With a little luck some Windows developers will be able to find time to help out.

3. Windows Local Security Authority

17 Apr 2004 - 18 Apr 2004 (6 posts) Archive Link: "Security of WINE and ReactOS: was Documents and settings"

Topics: Architecture

People: Steven EdwardsShachar ShemeshReactOS

The topic of getting some of the Win32 security mechanisms working with Wine has begun to come up more often over the past six months or so. Perhaps this is because they are increasingly used by programs. Steven Edwards started off a thread by sharing his thoughts about it:

Note I only know a little about the Local Securty Authority but I think its not going to be too hard to implement if Wine and ReactOS work together on it. /me just doubts how much he can write.

The unix security design of users and groups with permissions is not bad its just outdated. The nice thing about Unix is adding new security modules via PAM is not to bad except they are only for authentication. The unix concept of groups, users and permissions needs to be moved forward about 20 years. The SELinux stuff has really helped alot in this regard. (Please dont flame its the truth)

I recently addressed this in a discussion about ReactOS. Currently our lsass does not exist. I think we have what we have parts of the security reference monitor already implemented in ntoskrnl and most of the parts are there for winlogon and the SAM database so we need to develop the lsass services and build out the authentaticaion modules for MSV1_0 auth.

One of the nice things about the design of the Windows security module is that we can make plugins at both ends so that users can be granted access either based on a "domain" concept in winlogin/Gina using plugins for LDAP and PAM or via the lsass so users can be authencated locally.

It would be nice if we could work with the Winehq people on this as I think we can share the parts of the security subsystem that reside in lsass. Think of it like this

Kernel support

wineserver/ntosknrl need to both implement the security refernce montior for privlaged use of the local system resources. I dont know how much of this wineserver really needs to take in to account in the initial incarnation.

Local security subsystem

Lsass works interactivly with services and the login system and can accept all sorts of nice plugins so we are not limited to just the standard Windows authentication. As a matter of fact you could replace large parts of they authentication system if you are supper paronoid. Think of lsass as the sentry for Windows. It talks to the SRM to make sure you are not doing anything you shouldnt be.

User interaction

Interaction with the user will come from Winlogon on ReactOS or on Unix the user should already be authenticated via Linux security. This can of course be done via the authentication modules described above. Once the user

I wish I could attach the nice chart from Inside Windows NT so you could see the security subsystem. Its quite a piece of work and is quite a shame Windows security gets a bad name due to slack administrators.

Several people wrote in to mention their apprehension of the Windows security model, especially in instances where it may need access to root privileges. Of course, Steven calling Unix security "outdated" prompted some minor flaming as well. Josh Walker didn't see any difference between Windows XP and old DOS systems. Shachar Shemesh explained why, and then brought up some more ideas:

Joshua - your work XP was installed on FAT filesystem. If it were NTFS, you would have had a list of ACLs (Access Control Lists). This is a list that says "A can do this, B can do that, C is not allowed to do those" etc. It gives 100% granularity on what each entity can or cannot do, with each file, registry entry and device in the system.

Of course, Steven is, in my very humble opinion, dead wrong here. Windows' security model is a gross violation of KISS (keep it simple, stupid). Granularity is set so high, it is practically impossible to actually get anything configured. When was the last time you saw ANY windows program installer that changes the file permissions in any way? Last I checked, the standard installshield and wise template builders didn't even have an option to do that! In other words, we should not aspire to bring Window's security model into Linux. All the Windows security model did was cause every single user on the system to be an administrator.

At the moment, Wine is only aimed at single users installations. As long as that is the case, each wine user is an "Administrator" over his own fake-root wine installation. I don't see that changing.

I do want to see wine evolving into a (Linux) system wide installation, at which point security will have to come into play. I did post one idea on how to do that at

and in particular at

(October 2002!).

IMHO, the idea should be to bring Unix simplicit permissions to the Windows world, at least for the Unix installations of Wine. Reactos may well legitimately want the full blown stuff, with all the security problems that come with it. This means that we do translate the Posix users and groups into ACLs, but we do not necessarily do it the other way around. Let's not forget that the purpose of Wine is to bring Windows apps into the Unix/Linux world, not to change Unix/Linux itself.

There's a lot of work to be done in this area, anyone interested in examining the differences between Unix and Windows security models might be interested in working on this.

4. Listing More Downloads on WineHQ

17 Apr 2004 - 20 Apr 2004 (16 posts) Archive Link: "List other downloads on winehq"

Topics: WineHQ

People: Vincent BeronIvan Leo Murray-SmithJakob ErikssonMike HearnMicrosoft

Vincent Béron wondered if we could list more downloads on the Wine download page:

Following a discussion on IRC with a new user, we probably want to list on the Download page on winehq what other packages are available on sf, besides Wine per se.

Also, besides DCOM95, there are a couple other Microsoft packages that people are sometimes encouraged to install to get some functionality that Wine hasn't matched yet. Does somebody have a list of what can be found (and installed on a non-Windows platform) on Microsoft's site?

Ivan Leo Murray-Smith started with a list of things he's found helpful:

It's not a complete list, but I've got the following links

I think all these windows components can be used without problems on wine, but probably winehq can't redistribute any of them.

Mike Hearn said MSI, MDAC, and Internet Explorer were also useful. Ivan noted, " Installing IE requires a windows license for the computer where you're installing it. This sort of restricts it's use with wine. " But Jakob Eriksson pointed out that was not enforcable in every country and explained how it worked in Sweden:

Any additional license agreements are click-through or whatever. In Sweden a contract done like that is not valid. It has to be an oral or written agreement between two (juridical or physical) persons.

This leaves us with plain copyright law. IE is still copyrighted of course, so you may not be permitted to spread it further.

But since you have not agreed to any license, you are free to personally use your download however you wish.

Several small licensing discussion popped up, but in the end no list appeared on WineHQ.

5. Project David ?

22 Apr 2004 (10 posts) Archive Link: "project David?"

People: Rein KlazesR.U. DerangedMike HearnGe van GeldorpGeoff ThorpeMicrosoftRein Klaze

Rein Klazes wondered if anyone had heard of a Project David, " Somehow, we are doing something far to complicated:"

Speculation quickly turned to what, if any, technology the company had developed. Someone looked a bit closer and thought parts of Wine might be used by it, " If you can pierce through all that marketing hype, it seems to indicate they're using some code from the Wine project. I hope they're in compliance with Wine's LGPL license..."

Quite a few people were angered at comments on the web site against Wine. Mike Hearn placed the software firmly in the vaporware category:

Yeah, we're actually solving the problem instead of scamming investors out of their cash - or was I the only one who watched Hustle ?

Of course it's possible that they found some amazing way of hosting the NT kernel as a Linux kernel module, lifted the Wine x11drv and can now boot NT straight into Linux in an amusing twist on the CoLinux theme ..... but I doubt it ;)

Ge van Geldorp pointed out just how outrageous the claims sounded:

they say on the website: "David offer the following advantages: Does not require a copy of Microsoft Windows to run Windows Applications."

So, according to their website:

I'd say good luck.... If anyone wants to invest in this I also have a nice piece of Moon for sale, with a good view of the Earth.

The website mentioned a beta version was being given to the press on Thursday, April 22nd. Geoff Thorpe pointed out that if any part of Wine was being used by the project they needed to comply with licensing terms, " The very second their "demo" hits the wires, the redistribution clauses of the (L)GPL apply ..."

6. Combining Patches With Arch

18 Apr 2004 (1 post) Archive Link: "arch tip #2"

Topics: Patches

People: Mike Hearn

Anyone using the arch repository? Mike Hearn announced changes to a tool help create and manage patches:

I just checked in a new update to the genpatch script. It can now send an email to wine-patches automatically given a set of local changesets.

Use it like this: ./genpatch -m 5 6 7

if you did three commits, patch-5, patch-6 and patch-7 and want to send them all to wine-patches as one email. The log message and summary of the first patch will be used, and all three patches will be combined into one. You get to edit the email before it's sent and will be asked for confirmation, so you can read it over one last time.

By default it will send mail to localhost - if you don't want to setup sendmail you can have "export" in your shell init scripts to make it use a different mail relay.

So in summary, development on a series of related improvements to wine goes like this:

(setup arch and checkout the cvs gateway tree)

(make some changes, noting what they are in the arch-created log file as you go)

* committed

* committed

(this brings your tree up to date with winehq, only bother if you think there has been enough drift to make it worthwhile)

(read generated email, to confirm delete the first line + save + quit)







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.