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 :)

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.

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?

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.

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.

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.

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):

1. Implement a WINE implementation of that kernel driver (in the same way various stock windows kernel drivers have been implemented). Problem with this is that there is a big DMCA risk (which is why AFAIK its been rejected)
2. Implement a fake NTOSKRNL that has just the entrypoints for accessing and loading copy protection drivers (the set of kernel calls needed by the copy protection drivers is only a very small subset of the total set of kernel calls and AFAIK none of them are hardware related)
   or
3. Implement a proper kernel driver loader (i.e. one that would sit in the windows kernel and do the same sort of thing as that ndiswrapper and that ntfs.sys loader do)

What is the current state of copy protection work for WINE? Which of these 3 options do the developers intend to follow?

[#1.]

This will never be done, apart from the DMCA it would require a new driver for each new build of every copy protection system in the world

[#2.]

This is what I'm doing, the safedisc 1 driver works quite well with it, some ring 0 emulation is needed but that also works quite well and isn't much of an issue.

[#3.]

This would be a real pain as it would mean implementing the windows binary driver interface in the kernel, it would also not be very portable.

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.

http://www003.portalis.it/115/download/aoe.png

Mike Hearn asked me to send the work in progress stuff, so here 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.

ntstatus.h:

#define STATUS_NO_SUCH_DEVICE 0xC000000E
#define STATUS_NO_SUCH_FILE 0xC000000F

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.

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.

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 but perhaps with a bit more guidance, and oriented around things the students can finish (and get past Alexandre!) by September 1st.