Table Of Contents
|1.||28�May�2005�-�3�Jun�2005||(2 posts)||News: Summer of Code, Linux Mag article|
|2.||23�May�2005�-�2�Jun�2005||(15 posts)||Wine on Solaris|
|3.||1�Jun�2005�-�2�Jun�2005||(2 posts)||Copy Protection Status #1|
|4.||1�Jun�2005�-�3�Jun�2005||(6 posts)||Copy Protection Status #2|
|5.||1�Jun�2005�-�2�Jun�2005||(3 posts)||Forking and Printing|
|6.||31�May�2005�-�3�Jun�2005||(42 posts)||Summer of Code Announcement|
This is the 277th issue of the Wine Weekly News publication. Its main goal is to hate budgeting. 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 218 posts in 765K.
There were 87 different contributors. 44 posted more than once. 39 posted last week too.
The top posters of the week were:
1. News: Summer of Code, Linux Mag article
28�May�2005�-�3�Jun�2005 (2 posts) Archive Link: "News"
A big announcement came out of Google this week. They're sponsoring a Summer of Code (http://code.google.com/summerofcode.html) project for students to spend the summer writing open source software. The amount of impact this might have could be phenomenal. Right now 40 different projects are represented, including Wine (we were one of the first 6 though!)
It works like this: students will receive $4500 for completing their project. The sponsoring organization will receive an additional $500. Up to 200 individuals will get sponsorship making the grand total $1,000,000 being invested by Google. That's a pretty significant number. Check out Google's participant FAQ (http://code.google.com/summfaq.html) for details and eligibility requirements.
For anyone wanting to be involved, we've put together some resources to help you figure out what to work on. There's no shortage of projects, so check out the SummerOfCode wiki page (http://wiki.winehq.org/SummerOfCode) and fill out an application (http://code.google.com/soc_application.html) . Submissions are due by June 14th. The Wine team is really looking forward to working with everyone on projects!
In other news, there's an interesting article over at Linux Mag written by Jason Perlow titled "A Mile in IT's Shoes (http://www.linux-mag.com/content/view/1974/2303/) ". It's a pretty good read and pretty much dead on. CrossOver Office happens to be mentioned, but certainly isn't the focus of the article.
2. Wine on Solaris
23�May�2005�-�2�Jun�2005 (15 posts) Archive Link: "Wine on Sparc"
People: Chuck Hall,�Eric Frias,�Robert Lunnon
Occasionally Wine gets ported to other architectures. Wine should be capable of running Windows executables on any x86 operating system and should be able to run Winelib apps on everything else. The reality is, very few people try to do it and most of Wine's developers use Linux. Therefore, support for other architectures can be spotty. Chuck Hall inquired a few weeks ago:
I have heard that people are using Wine on Solaris. I would like to know if they are using Wine on the SPARC version or the x86 version of Solaris?
There does seem to be code within Wine to have it run on SPARC machines, but it currently does not seem to compile, at least on the Solaris version.
I have attached a small patch that allows me to get throught the 'make depend' section of the compile. Since it is my first patch, please look at and let me know what I did wrong :)
Eric Frias replied in reference to Chuck's patch:
I'm using it on the Sparc version, with Solaris 7 and 8. Winelib only, of course, none of the emulation stuff is going to work on Sparc.
Right now I'm using an old version of wine circa November 2004, and it needed a few minor fixes to work correctly. I'm in the process of upgrading to the latest & greatest, and unless there are major problems I plan on getting it working sometime this week. In the past, upgrades haven't been too much of a problem. When I get it working, I'll try to get my patches back to the wine-patches list promptly.
I posted my last batch of patches to wine-patches back on 2004-11-17, and I know some of them didn't make it into CVS. I also saw some patches posted to one of the wine lists around 2005-05-07 by Robert Lunnon with titles like "Solaris Compatibility" that you might want to look at. I don't know if his patches were for Sparc or x86, or if they've been accepted.
I'm not sure how to explain why this isn't working for you. I know we compile with a version of gcc that is configured to use the GNU assembler and GNU linker from binutils. Perhaps yours is using the native Solaris assembler, and it doesn't understand .previous? The assembly portions might only compile correctly with the GNU assembler.
Chuck explained his toolchain:
When was the last time the Wine README was updated? Using the GNU toolchain I get a few more warning messages during 'make depend' but it does work. Gcc, gas, and gld need to be from the GNU toolchain, the rest seems to work as Solaris native.
You mentioned that you had patches for Wine on SPARC, would you mind sharing them or should I do a google search for them?
Robert Lunnon jumped in to talk about the specifics of different pieces of the toolchain:
I don't have a SPARC box so I haven't tested SPARC compatibility though the patches do handle some SPARC things. Since the API is the same all should work OK as far as syscalls go. Wine doesn't build out of the box though!, there are a couple of extra patches that you need to implement SYSV native threads on Solaris 10 or above and some stubs to make some other things work properly (like disabling the debugger and executing libs across a symlink containing a colon ). I publish a kit of patches with each binary I publish but I haven't republished the binary since the latest putback, many of them have now been rolled into CVS wine and are redundant. Some patches may never get in because Alexandre already rejected them. I think there are only one or two essential ones now. (send me an e-mail)
Good idea about the autoconf test for gas support, That's not hard to do, so I'll contribute this ASAP. Sun's as doesn't work (on x86 anyway) the operand orders are different to gas so it won't assemble as expected.
You don't need gnu ld at all, x86 Solaris ld works fine. My GCC is built to use gas + Solaris ld so I can use it to build kernel modules. Aside from libtool feeding it duplicate libraries in kde (which solaris ld doesn't like at all) I rarely have problems with that configuration. I'd recommend this gcc config.
Under x86 Solaris wine works pretty much on a Par with Linux, I even had a reported Success with Lotus Notes which was reported broken for Linux.
Eric said he would work on getting the latest Wine to build on Sparc Solaris and mentioned he was slightly concerned about the new DLL import changes Alexandre committed a few weeks ago. After he was done, he reported:
It actually went more smoothly than I expected. I've attached a patch with the minimal changes I needed to get 'notepad' running. As you can see, I disabled winedbg, oleaut32, and dbghelp because they are missing some assembly bits, and they aren't strictly necessary for most winelib applications. I haven't tried compiling or running anything big with this, so it may be missing a few patches... but it's a start.
Chuck reported he was able to get the patch to work. Eric happened to be using Solaris 8, while Chuck was using 9. As a result, Chuck uncovered an issue:
Started to go through this and found something intresting. lwp.h does exist and is found, so HAVE_SYS_LWP_H is defined. The test for _lwp_create fails. Looking a bit deeper I found that the lwp.h for Solaris 9 is different from the one in Solaris 10 (which is what I am using). Based on this and something I read awhile ago, I believe that Sun is attempting to phase out the lwp stuff on Solaris.
It looks like a workaround will need to be created for _lwp_create. I will look into this and see what is the "official" way to write the code now, if any. Also a workaround will need to be made for all other _lwp_* calls that no longer exist.
All in all, Wine looks to be usable on Solaris still, which is nice.
3. Copy Protection Status #1
1�Jun�2005�-�2�Jun�2005 (2 posts) Archive Link: "Copy Protection & WINE"
Topics: Status Updates
People: Jonathon Wilson,�Ivan Leo Puoti
Jonathon Wilson (who must not read WWN since we've covered this topic in the recent past) had three ideas for getting copy protection working in Wine. These are actually moot points since Ivan Leo Puoti is actively working on this. Still, for completeness, Jonathon asked:
From what I understand, there are 3 ways to do copy protection in WINE (at least for copy protection that needs a kernel driver to work):
What is the current state of copy protection work for WINE? Which of these 3 options do the developers intend to follow?
Ivan went through each approach:
4. Copy Protection Status #2
1�Jun�2005�-�3�Jun�2005 (6 posts) Archive Link: "safedisc stuff"
Topics: Status Updates
People: Ivan Leo Puoti,�Andreas Mohr,�Mike Hearn
In more up to date news regarding copy protection, Ivan gave an update of exactly what he's working on. He reached a significant milestone with Age of Empires 2:
I actually got this for the first time a few days ago, but I thought I might as well share it as I think it's cool. AFAIK DMCA compliant code has never got this far with safedisc 1.
The screenshot is rather anticlimatic - it simply shows the splash screen for AoE2. What's going on behind the scenes is more interesting. Ivan has implemented a minimal ntoskrnl.exe interface that can load the real Safedisc driver shipped with the game. So all those no-cd cracks wouldn't be necessary for Safedisc v1 games.
Later Ivan sent an email about the actual code (which hasn't been submitted yet):
Mike Hearn asked me to send the work in progress stuff, so here (http://www.winehq.com/hypermail/wine-devel/2005/06/att-0055/01-safedisc.tar.bz) it is. Some of it sucks (See QueryServiceStatus for the worst hack ever, that doesn't even usually work), but the design should be more or less ok. It needs lots of cleanup and optimisation.
Stephen Torri ran into a problem and Andi Mohr explained what the errors meant:
#define STATUS_NO_SUCH_DEVICE 0xC000000E
#define STATUS_NO_SUCH_FILE 0xC000000F
5. Forking and Printing
1�Jun�2005�-�2�Jun�2005 (3 posts) Archive Link: "Winelib MFC app crashes after printing"
People: Eugene Aksenov,�Eric Frias
Eugene Aksenov ran into a printing problem with an app that was ported with Winelib:
I have a small MFC app ported to winelib which uses MFC compiled with winelib. Really, it is just an App-Wizard generated application. I always have a crash of the application after printing. The page is printed ok but after that the app crashes.
I use LPD for printing and my command line from wine is 'lpr -Pmyprinter'. I also try to print without MFC support i.e creating the printer DC by hand etc - the crash is the same, it follows EndDoc() call.
There is no crash like this at the same linux configuration using in a 'pure' Win32 simple application without MFC though the code for printing is the same.
When i print to file, all is ok. So , my current workaround is printing to a temp file and then send the file to lpr.
I use RH9.0, wine20050419. My [spooler] section in config is the default from the wine installation.
Did anybody meet a problem like that ? Is it MFC that has some impact here ? Thanks a lot for any hints.
Eric Frias recognized the issue and provided a patch:
I've run into this bug & fixed it. I just was never confident enough in my fix to get around to submitting it.
The problem you're seeing is most likely because you have a C++ application. When wine prints something via lpr, it forks off a child process to do the printing. Instead of doing exec("lpr") as most other programs do, wine does a system("lpr"); exit(); The normal exit causes the child process to execute global destructors, which the 'exec' wouldn't. If the global destructors free memory that is also used by the parent process (which is probably common), the parent process will quickly crash.
Try the attached patch and see if it fixes your problem. I think it's mostly correct for linux, solaris, and hp. We'd need to check the behavior of system() on other platforms to make sure it's consistent. On Solaris, it looks like there are circumstances when system() will invoke 'ksh' instead of 'sh', but I hope wine doesn't need to worry too much about that little detail.
Eric's patch to printdrv.c looked like this:
+#if defined(__hpux) || (defined(__sun) && defined(__SVR4))
+����execl("/usr/bin/sh/index.html", "sh", "-c", psCmdP, 0);
+����execl("/bin/sh/index.html", "sh", "-c", psCmdP, 0);
+����/* If the exec fails, we'll just take our chances and exit */
Eugene reported success with the patch, " Yes, this patch fixes the problem. Thanks for the description. I checked on linux only. Perhaps, the patch is to be submitted."
6. Summer of Code Announcement
31�May�2005�-�3�Jun�2005 (42 posts) Archive Link: "Google Summer of Code"
People: Dan Kegel,�News
Dan Kegel announced the Summer of Code program first:
Google is offering students summer stipends to contribute to open source projects! To qualify for a stipend, you have to submit a proposal by June 14th, and the proposal has to be approved. See http://code.google.com/summerofcode.html
It would be cool if the Wine project put together a list of suggested projects for students to work on. It would be like http://www.winehq.org/site/contributing#devel (http://www.winehq.org/site/contributing#devel) but perhaps with a bit more guidance, and oriented around things the students can finish (and get past Alexandre!) by September 1st.
It touched off a flurry of emails and ideas. Even more was discussed on IRC. The end result was most of the ideas listed on the wiki page (http://wiki.winehq.org/SummerOfCode) .
Sharon And Joy