We had a number of minor glitches that we felt were important to release to our customers.

These include fixes for Notes (bouncing windows), fixes for Office install issues (e.g. spellchecker), and a lot of other minor problems that bothered us; a full changelog is included in this email, below.

It also includes a fix which prevents the EMF exploit from working in Wine; many thanks to Marcus Meissner for his speedy fix to Wine to that end.

We have a fix for ipod support that we decided to exclude from this release because we worried that it might break other programs. However, we are going to put up a FAQ on our web site in the next day or two to give interested customers a workaround.

As always, if you are happy with your current version of CrossOver, please do not rush out to upgrade to version 5.0.1. However, we did take some care to make 5.0.1 a nice stable upgrade, so it should be safe.

I'd like to thank the many people that helped with this release, including our customers, with their excellent problem reports, our beta testers (thanks guys!), the broader Wine community, and especially to Andrew Bogott, for his diligent and somtimes lonely work on seeing this release out the door.

This patch reduces the attack vector on metafiles.

I originally wanted to filter only SETABORTPROC, but there are a lot of things that might be used to inject code.

Please take with a large dose of salt.

http://wiki.winehq.org/BenchMark-0.9.5

I was curious how we did last year so I dug up some numbers with the help of git. I counted patches applied to the tree starting from 1999:

year    # patches
1999   2656
2000   2722
2001   1885
2002   3094
2003   3283
2004   3851
2005   6037
Total: 23528

This is almost too good to be true isn't it? I worried for a while that these figures might be influenced by the switch from cvs to git, e.g. that cvs history somehow shows up compressed in git. On second look though it really seems that the past year has seen an impressive increase in productivity, compared to the previous years.

I'm sure number of people wonder where did ntoskrnl go. It's still here in the too hackish form to be committed.

For the past month it didn't even compile because of all the changes to different parts of Wine. I just thought I should put it back together and see if it's still working. And surprise surprise it still works. So here it is again, before I'll break it again re-implementing the way the user space talks to it.

BTW, it is still just barely enough to run safedisc 1.x copy-protection. Diff against wine-0.9.6

We actually managed to get HPUX (on PA-RISC) working reasonably well early last year. We didn't attempt porting a few of the parts I considered optional, like winedbg, oleaut32, and opengl. Still, it ran some pretty significant applications (i.e., mine :-) very well.

The assembly code generated for HPUX is a bit different from the other platforms, and all of the ifdefs in winebuild were getting pretty hard to follow. I'm hoping the recent changes to winebuild will make it easier to integrate, whenever I get around to updating... Until that happens, if anyone needs HPUX winelib, I'll be happy to send a tar of my working copy. It works on HPUX 11 and 11i, and maybe others.

The Sparc Solaris version of winelib we use works on at least Solaris 7, 8, and 9. It was working on Solaris 2.6 at one point, but we no longer have a machine that old to test on.

Not sure if this is the correct mailing list, please redirect me if not. My goal is to port some Windows apps to AIX, so I decided to take as much Wine (winelib) as I could to help me. Initially I thought only a small portion would be suitable, but after a few weeks of work I have all the dlls/libs compiled (as simple AIX .so's) and because I'm quite naive about Wine internals, I went for wineserver also. My first question is: has anyone tried this before? I've been googling endlessly, and haven't found a single mention (unfortunately, "wine" and "aix" keeps trying to find French drinks). If anyone has, or anyone is interested in my (hacky) attempt, please email me directly (I try to keep up on this list, but I don't do very well). I wanted to avoid the "wine" loader, so I made a pseudo-main like:

int main( int argc, char *argv[] ) {
char error[1024];
int i;

if (wine_main_preload_info) {
for (i = 0; wine_main_preload_info[i].size; i++)
wine_mmap_add_reserved_area( wine_main_preload_info[i].addr, wine_main_preload_info[i].size );
}
AIX_set_pthread_funcs (); /* sets up thread function call table */
wine_thread_init (); /* thread initialization stuff */
process_init (); /* does a bunch of .exe initializations */
WinMain (0,0,0,0);
}

Amazingly, after building one of our simpler Windows clients, I get:

hac1dev:ghart$ ./simpleClient
err:ntdll:critsection.c 309: section f0b82b58 "virtual.c: csVirtual"
wait timed out in thread 0009, blocked by 0000, retrying (60 sec)
err:ntdll:critsection.c 309: section f0b7ad50 "exception.c:
vectored_handlers_section" wait timed out in thread 0009, blocked by
0000, retrying (60 sec)
Ctrl-C Killed

So, if you have been kind enough to read this far, perhaps you also might share any ideas you have about what I have done wrong. I have traced through both the wineserver and winelib (ntdll, kernel, user, ...) code in the debugger but I haven't seen anything obvious (to my untrained eyes). I have been so bold as to even include my traces (the [PAUSE] in the client.trc is when I hit the breakpoint in the server, and start it tracing).

The problem might well be in my attempted ports of the pthread routines, the atomic operations, or some other assembly stuff.

I was trying to compile the test application (Notepad) with winelib to get a feel for how to use it. I followed the instructions in your docs, but ended up with a target file notepad2.exe.so. The instructions imply that I should end up with an executable called notepad2, since they tell me to run it.

If I run the .so file it segfaults, so I assume it really is a shared library and not just an executable with a funny name.

I want to understand what I've done wrong here, because if I can't get this right I certainly won't be able to port anything complicated. I'm sorry if this has been asked often before, but I couldn't find an easy way of searching the mailing list.

I am using WINE-0.9.4 built by Adam Schreiber for Slackware 10.2.

No winelib application is not a standalone as you would think. You need to run it in the same way as all the rest exe files: wine notepad2

I've put together a little Microsoft Office on BSD howto on the Wiki, If anyone here uses OpenBSD, NetBSD or DragonFlyBSD I would be interested to know if you can get Office 2000 to install and run with Wine out of the box or with my cheats. :D So others who read the howto in the future will know the status of there distro.

http://wiki.winehq.org/Office-BSD?action=show

A while back I posted a question about how to get debugging working with Eclipse in fedora 4. I am having some success, so if anyone else out there is interested here's how it is set up.

In regedit:

• disabled auto winedbg by renaming AeDebug I changed HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/Current Version/AeDebug to AeDebug-DISABLED. Without this gdb doesn't seem to be able to get a hold of SEGFAULTs.

In eclipse's Run/Debug dialog box:

• set the c/c++ application to WINE_SRC/loader/wine-pthread WINE_SRC points to a compiled version of wine. For me, I got the wine src rpm and ran rpmbuild -bb. This is where main() is, which eclipse looks for at start up.
• put your .exe.so file on the Arguments tab
• choose the GDB Debugger on the Debugger tab
• add WINE_SRC on the Source tab as a "Filesystem directory with subdirectories"

The only weirdness so far is that sometimes (not always) the debugger suspends when a new thread is created. I just resume (F8) past that. And I am not sure what impact bypassing wine-preload's exec-shield workaround will have on me. More on that if I learn more.

But I gotta say that having a functioning IDE with integrated debugging on Linux is a major relief and, for me at least, a long time coming!

PS: I installed FC4, and then did yum update. eclipse is version 3.1.1 updated from the eclipse UI from the version that came with FC4.

You could (not tested) alternatively:

• set winegdb --gdb as the name for executing gdb
• not reset the AeDebug key
• set the executable to be the real exec (+ .so extension if run from the build tree)

You would this way:

• keep all the preloader stuff, so that your memory layout is better (and the same than when run from command line)
• still be compatible with the segfault stuff

I have noticed significant increase in crashes and lockups in winecfg's audio page. Could we do something about that before the next release?

This makes it hard for any first timer to configure Wine. Especially knowing that most people will have to change hardware acceleration to "emulation" and they will not be able to do so.

I agree with you but can you be more specific?

There is a bug in arts itself which causes arts to crash. I believe this has been fixed in the latest arts libraries.

There can be a short hang in the esd driver if esd in not configured properly.

One person reported a computer lockup with OSS but that is probably a kernel driver bug.

Winecfg is now really using all compiled in audio drivers to do hardware probing of all available hardware. OSS with a real OSS kernel driver (not ALSA emulated OSS) is the only really stable setup now. All the sound drivers need to be looked at more closely now so they either work properly on a wide range of hardware or fail gracefully on misconfigured or marginal setups.

Contrary to popular belief, sound can work very well in Wine and even work better than on Windows but only with some hardware and with some versions of linux. In general, both Wine and the sound systems that it uses have a long way to go before they will work well for everyone out of the box. Even Windows has problems doing sound well for everyone out of the box.

From a user's perspective, even if arts crashes, it shouldn't be taking winecfg down with it. Counting on users to have correct audio setups across distros sounds a bit utopian. Obviously we can't fix sound for the users, but we can at least show an error message saying what failed. Also, people who have arts installed but don't run it as their sound mixer still crash (happens under Ubuntu too).

I'm running Kubuntu on my desktop and clicking the Audio tab under cvs gives this:

ALSA lib pcm_dmix.c:746:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
wine: Unhandled page fault on write access to 0x44fec1ec at address 0x7e6f49d1 (thread 0009), starting debugger...

The crash occurs in libartsc.so.0 as shown above.

Can you try this patch:

http://bugs.winehq.org/attachment.cgi?id=1523&action=view

It tries to catch the exception in the arts library. This is just a hack to work around a bug in the arts library.

The line ARTS_Init(); is what's crashing! This is the first call to the library. Clearly an arts library bug.

The point is that it is not crashing in winecfg or any wine code at all. Adding an exception handler to catch a crash in an external library may work but it's a workaround for a broken external library. The external library needs to be fixed.

I've been working on a still image implementation for Wine / ReactOS for a while now, and I've only recently realised how impossible it is in Wine at the moment...

Wine's SETUPAPI.DLL is not even in its infancy, it doesn't even let you enumerate non-serial-port devices, and doesn't load class-installers, so you can't even install a scanner's INF file. I see that ReactOS's implementation is better and it is under the right (LGPL) licence; are we planning on including it into Wine, and if so, when?

Wine's NEWDEV.DLL is pure stubs - so you can't even start installing the device INF file. ReactOS's latest SVN version of it is a little closer to what I need, but can we include GPL code in Wine? (I've asked the developers to relicense it under the LGPL for us, but they haven't gotten back to me yet).

So what should I do - submit my STI.DLL and STI_CI.DLL into Wine now, even though they won't be usable for a good while - or wait for Wine to mature?

And does anyone know any good documentation for writing COM out-of-process servers (that use ncalrpc transport and have some [local] methods)?

It's likely somebody will have some comments on your code or Alexandre will require you to change the way things are done before he accepts it into Wine.

With this in mind, you should submit what you have early to get feedback on it. You should also attempt to break it up into smaller seperate, independent parts where possible.

For example, if you've changed include/sti.h, you could submit those changes first, as they're low risk and should be applied without any trouble. Same for any other improvements to Wine that makes sense on their own.

Some people are working on a driver framework for Wine, so you might want to consult with them about the best way to share that framework.