This is the 136th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).
It looks like I missed a review of CrossOver Office from back in April. It seems ZDNet's informal web poll at the time produced the following results:
Would your company switch its desktop PCs from Windows to Linux if Windows apps could run on Linux? Of the more than 15,000 respondents, 58 percent said they'd make the switch immediately; another 25 percent said they'd consider dumping Windows in favor of Linux within a year.
The author of the original article, Rich Castagna, wrote a followup discussing it. The numbers are pretty dramatic, even more so if you think about what the response would have been only a few years ago. Of course, I don't place much more confidence in ZDNet polls than I do Slashdot, but it's interesting to see.
My all-time favorite tech magazine, Linux Journal, has a review of CrossOver Office. It goes into detail on installation and has bunch of screenshots. The author, Jeffrey McDonald, was particularly glad to be able to run Outlook.
Martin Wilck asked what was being done with regards to the netapi32.dll:
The app I am trying to port with winelib makes heavy use of calls to the netapi32 DLL to check for permissions, etc.
I just took a glance over the spec file and found it consists mainly of stubs.
Is anybody (Mike?) currently working on netapi32, are there plans to implement larger parts, what are the main problems?
I guess this points towards the general Wine/Samba integration that Mike has been talking about earlier...
Andriy Palamarchuk admitted to taking a stab at it:
I'm now working to implement some netapi32 calls. My implementations use information, provided by Wine or give some dummy values. Do you think this will be enough for your application? You can give me the list of calls your application uses - I'll give preference to implementing them.
Sure the right approach would be to integrate it with Samba but I was not going to do it right now.
Martin explained exactly what he was looking for:
identification and access right verification. Currently I rather tend to replace all this by "native unix" verification. I actually don't think it's a good idea for my app to bypass the Unix system.
In this context, one idea would be to simply route requests like these to Unix services like PAM. There may even be a samba Authorization service for PAM installed. That way it might actually be possible to map authorization issues like this correctly from wine to e.g. a PDC, but through the native Unix interface, and without creating a Samba+Wine "monster" app. This is far future of course.
Two days later Martin posted a patch integrating Wine with PAM for authentication. He asked for comments:
Log Message:
Attempt to code LogonUser() using an interface between Wine and the PAM library.
Normally, this will validate Unix username/password pairs. If PAM is suitably configured (for using winbind), usernames and passwords can be obtained from a Windows Domain controller.
It is even possible for system administrators to setup a special authorization scheme for wine by editing "/etc/pam.d/wine".
Status:
Compiles, simple (non-unicode) test program authenticates sucessfully against Unix and Windows PDC accounts (and fails with wrong password).
Fixmes:
** LogonUserW() is untested, and I have little experience with Unicode transformations in wine. Be prepared for bugs there.
The LICENSE of PAM is rather unclear - on http://sourceforge.net/projects/pam it says "BSD License, GNU General Public License (GPL)". But I expect no problem with Wine linking against it.
The flags to LogonUser() are ignored, and the resulting Token is meaningless because wine currently has no concept of security tokens.
To make this really useful, more support for security issues needs to be implemented - but this function is (almost) sufficient for me :-)
There are no security checks on the parameters (are they null-terminated?), because I'm not sure how to do that (enforce maximum length? If yes, which?).
Perhaps the code should have gone into security.c rather than advapi.c. Or does the whole stuff belong somewhere in ntdll?
The next day Andriy
submitted
some work that implemented
NetQueryDisplayInformation, NetUserGetInfo, created
conformance tests, other netapi32 bug fixes and
improvements.
György Szombathelyi is working on rewriting wnaspi.dll to work with
an existing lower level library. ASPI is the Advanced SCSI Programming
Interface and used as an interface between host adapters and device
drivers. György was looking for some apps
to test some of the more obscure parts,
I'm working on a rewrite of the winaspi module, using Joerg Schilling's
libscg. (libscg is a scsi transport library, with support of many platforms,
cdrecord, cdrdao uses it). I'm nearly finished, but I could test only
winaspi32 (with nero and isobuster), I need a software that uses the 16 bit
aspi interface to test it. Anyone knows such a software that uses wnaspi.dll?
Tony Lambregts didn't think it was too important,
I don't think you will find too many of this type (16 bit software using
aspi) due to the fact that the aspi interface is newer than the 32 bit api.
Dimi Paun agreed,
Yeah, 16bit is rather dead, just go ahead with your changes, and if they
break anything, you'll find an application to test with... :)
A few days later György submitted a patch.
Steve Lustbader had a problem clashes between Windows and Unix function calls:
In my winelib app, most of the cpp files use MSVCRT only, and thanks to Martin I've gotten those to compile.
A couple of my source files, however, use a mix of MSVCRT and standard glibc (fork, exec, etc). When I include unistd.h, lots of function definitions conflict with msvcrt/io.h. How can I get this mix to compile? Does the @ignore in the spec file trick from the Winelib user's guide still apply, or has it been changed (or removed altogether)?
Martin Wilck suggested trying:
Here's what I would try: Encapsulate the Unix-specific calls in a separate source file(s) that compiles against the system headers, wrap the Unix calls in functions exported by these files, and then "simply" link the winelibwise and unixwise parts of your application.
Dividing the the two worlds over source files should have other benefits as well, softwaredesignwise :-)
Steven Edwards requested comments about closing out bug 529. It seems through private correspondance it was decided to just close it out and not deal with the perl framework any more. Steven's explanation was:
This bug can be closed as Alexandre has said that the regression suite will be dropping perl as no one uses it and its a bitch to get working on Windows. Trust me I have tried