• Support for Find function in regedit.
• Winelib app to eject a CD.
• Many MSI improvements.
• Better support for running text-mode apps without X.
• Improved support for various code obfuscation tools.
• Lots of bug fixes.

What's new in this release:

• Winelib Explorer app (just a wrapper around winefile for now).
• Debugger cleanups and improvements.
• Many wininet fixes.
• Better autogenerated API manpages.
• A bunch of Korean translations.
• Lots of bug fixes.

Surprisingly, I found there to be little difference between the applications' performance running on Linux with CrossOver Office and on XP. Indeed, I found some applications, such as Word 2000, to actually run faster on Linux.

Who knew?

How likely is it that someday all Windows programs will work perfectly through CrossOver Office?

Jon: I think the answer to your question really hinges on the effort level behind Wine. Right now, the Wine community and CodeWeavers comprise a relatively small group of developers. And while we've managed to achieve a minor technological miracle with that limited resource pool, we could continue advancing that miracle a whole lot quicker if there were more developers and more money behind the effort. With proper backing, I'm convinced that Wine can move itself from being a niche technology--something that works brilliantly in some cases, but poorly in others--and towards a technology that 1) people perceive as being widely and generally useful, and 2) is relatively easily fixable from a development standpoint. Not perfect. But broadly accepted and easier to improve. That's the goal.

Raphael Junqueira asked on bugzilla what the safedisc status is. Currently it works fine, and I believe what we have is more or less ready for CVS. However Vitaliy told me Alexandre didn't like the object manager Vitaliy wrote, mostly he didn't like permanent objects, that drivers depend on. I haven't talked to Alexandre about this but hopefully some reasonable solution can be found so we can get Vitaliy's OM into wineserver (I mean my original implementation that uses pointers as handles also works, but things look better with a real OM). So let's try and trigger some community discussion, we are talking about the guts of wine after all. Vitaliy, what's the OM status currently? Alexandre, what didn't you like about it?

Following Alexandre's suggestions I've managed to get OM working without support for permanent objects. There will be some modification required for ntoskrnl for that to work. I'm just about finished integrating new OM into ntoskrnl tree and almost ready to give it a try.

As far as OM goes it's mostly finished and passes all but two of om tests. Also it don't see any side-affects from it either. All the programs I've tested work in the same way as they were before. All named object moved to directories and using RootDirectory part of OBJECT_ATTRIBUTES for create/open.

Attached is the final revision of the directory object implementation. If it looks ok I'm ready to send some patches <g>

Today I have finally managed to get some useable graphics with D3D7 and WineD3D. The Tomb Raider 3 Demo is running. :)

The only visible problem I can see are textures: They only have a solid color, all other things seem to work. I've uploaded a screenshot to http://doesi.gmxhome.de/tomb3-2.png , if anyone wants to have a look.

I'll try to fix the textures and get some more games running, then I'll upload a beta patch somewhere for others to try. (Well, if anyone is interested, I can mail the current code too).

I have sorted that texture problem out now(Incorrect Loading and the TEXTUREHANDLE render state was missing), and to my eyes Tomb Raider 3 runs correct now with WineD3D.

Does anyone know any other games which are running with the old Direct3D 7 implementation? I will give Prince of Persia 3D a try tomorrow, but the last time I tried it crashed before initialising DDraw.

Many users want wine to play Diablo2, Starcraft, Civ3, Sacrifice, ... (I don't know if these games use ProcessVertices or Multithreading)

You can see most wanted games (and how to download demos) here :) http://appdb.winehq.org/votestats.php

I've put together a Direct3D 8 wrapper for wined3d which should hopefully replace the current Direct3D 8 code. The patch needs a little bit of tidying, some work of vertex declarations and a hell of a lot of testing before it can go into Wine.

So far I've tested Rail Road Tycoon 3, Celebrity Death match, Madden NFL 2004 all the d3d8 demos from http://www.codesampler.com, a few more games I can't remember at the moment and everything's seems to be working as good as or better than the current Direct3D 8 code.

I would be grateful if anyone with DirectX 8 games or applications that currently work or they would like to get working could test the patch and report back any errors they come across.

The patch is against Wine cvs 2005-11-05 and can be downloaded from https://sourceforge.net/project/shownotes.php?release_id=368929 for the time being.

I've updated the directX 8 wrapper with a load more bug fixes notably Max Payne 2 now works correctly. For anyone who's interested the update patch is available here: https://sourceforge.net/project/shownotes.php?release_id=371929&group_id=134206

At the moment we have a very outdated version of the auto-generated "make htmlpages" Wine API documentation at

http://source.winehq.org/WineAPI/

I believe that the API documentation is important for a number of reasons:

1. It might provide info to ISVs that might think about porting an app to Wine as to whether the APIs that they use are implemented or not.
2. It provides info about undocumented functions.
3. It provides an alternative source to MSDN in case it becomes unavailable for whatever reason.
4. It spreads the word about Wine through high search engine rankings, making it more likely that someone will stumble upon Wine and start coding for fun.

It appears that this was previously generated at release time by the wine_release script (http://cvs.winehq.org/cvsweb/tools/wine_release), but was disabled over 2 years ago. I was wondering what the reason was, but I guess it is that it takes a long time to build and a lot of CPU time. We don't really want the WineHQ web server to be running at 100% CPU for ~20 minutes while it builds the API documentation.

Therefore I propose that I could send a tarball of the documentation to Newman every release, every month, or after a major update of the documentation (whichever is sooner) and he can put it up in the appropriate location. Alternatively, we could also put the auto-generated docs in cvs and generate diffs.

Alexandre, any comments about how the release process should work with regard to the Wine API documentation? Newman, which method of updating would you prefer? Any one else have any comments at all about this?

I've just submitted a bug (3889) about destroyed MBR and Dustin Navea asked me to subscribe to this list. Here comes some detailed description:

As a regular user I've launched winecfg as a regular user, then proceeded to the dist setup. I've tried several options like automatic configuration, manual configuration. Then I've tried to change some drive letters manually. After reboot a "PRESS A KEY TO REBOOT" message appeared instead of a GRUB screen. Next time I booted with grub-floppy and then restored the MBR with grub-install /dev/hda. Please let me know what additional information you need. It's happend on Slackware 10.2 system, 2.6.14 kernel with ck-3 patches.

bash-3.00$ ls -l /dev/hda*
brw-rw---- 1 root disk 3, 0 2005-11-20 20:33 /dev/hda
brw-rw---- 1 root disk 3, 1 2005-11-20 20:33 /dev/hda1
brw-rw---- 1 root disk 3, 2 2005-11-20 20:33 /dev/hda2
brw-rw---- 1 root disk 3, 3 2005-11-20 20:33 /dev/hda3
brw-rw---- 1 root disk 3, 4 2005-11-20 20:33 /dev/hda4
brw-rw---- 1 root disk 3, 5 2005-11-20 20:33 /dev/hda5
brw-rw---- 1 root disk 3, 6 2005-11-20 20:33 /dev/hda6

bash-3.00$ groups
users disk lp floppy audio video cdrom scanner

This never would have been possible with a normal user account. But if somebody "creates a special user" by extending his rights and putting him into the disks group, he should be aware of the implications. I don't think there is a "documentation bug".

Of course that is not an excuse why Wine wants to write to the MBR ;)

(dlls/kernel/volume.c) Don't try to set the label in the superblock of FAT filesystems, that doesn't do the right thing anyway.

Only set label and serial number when they are actually changed.

My name is Susheel Daswani. I am a second-year law student at Berkeley School of Law. I am also a software engineer - I used to develop the LimeWire open source Gnutella p2p application. Nice to meet everyone.

For my 'Antitrust & IP' course this semester I am writing a brief about why I think the remedy in the Microsoft antitrust case was inadequate. My main recommendation is that the 'applications barrier to entry' phenomenon (users like OSes with lot of applications, developers like OSes that users like) need not aid Windows' dominance. This is of course familiar thinking to the WINE community - if a *nix (or any other OS) could effortlessly run every Windows application, then we wouldn't have a monopolist over in Redmond, or at least we'd have some fervent competition in the personal desktop OS space.

So my question for the WINE developers is "What materials from Microsoft would most aid the development of WINE"? The Windows API is of course public, so my guess is that isn't a huge bar to creating WINE. So what are the bars? Is it simply the scope of the project? Is there information that MS could divulge that would greatly aid the WINE effort? Would open sourcing part of Windows help?

I plan to use your answers for no other purpose than educating my professor on what, alas, *could* have been done to help restore competition to the personal desktop OS market.

Unfortunately, you guess incorrectly. While the API may legally be public (the interface can't be protected, as far as we know,) it isn't always documented. MS uses undocumented APIs very, very frequently in its own products, and I don't just mean in its applications: parts of its API depend on other, hidden parts of its API. Even the parts that are documented are not documented completely. For example, many APIs take 32-bit flags parameters, some of whose meanings are documented. But the behavior for all possible values is not well-specified, nor are the return values. I continue this thread next:

> Is it simply the scope of the project?

This is a large part of the problem. It's difficult to appreciate just how large it is. (There was a presentation about this once, maybe by David Korn, but I've lost track of it.) We can only learn the behavior through experimentation, and so do application developers. The application developers depend on undocumented behaviors, so we have to replicate them, including bugs. The problem is, there are many more of application developers (and Windows developers) than there are of us.

Also part of the problem, though I don't think it comes close to scale as far as its impact, is that our architectures are different. For example, the code obfuscation tools (securom, safedisk et al) depend on device drivers being loaded by ntoskrnl.exe. This is related to the hidden assumpmtions problem I described already, but sometimes we have to implement a large amount of silliness that we didn't anticipate having to do, or reimplement stuff that was already working for some apps. ReactOS can potentially avoid some of these issues, since they're copying much more of Windows's architecture.

One of the problems is that microsoft uses a vague term "Operating System component" for almost everything one might expect to get free access to. This includes Internet Explorer and its components including upgrades, Windows Media Player and its components, MDAC, and many other things like MFC which don't exist in older Windows versions, and which are allowed to download only for "genuine windows" users. It effectively removes a visible border between an application, a redistributable component, and the OS itself. Microsoft simply wants to tell the users that everything it develops is Windows OS, and therefore is illegal to use on any other platform. It's nonsense to require an OS license to install an application.

For instance Office 2003 does not install MFC dlls while its components don't work without MFC. Since Wine doesn't have MFC, and clearly MFC is not an OS component, and developing MFC is out of the Wine scope, that's a problem.

That is, the documentation of the API has gotten substantially better. However, there is no way for anyone in the 'public' to request a clarification or visibility into this process. The process is overseen by a committee and they are not responsible to anyone but the judge. So, the documentation gets better, but it happens overnight, invisibly. We have no way of knowing that the documenation was improved, and no way of knowing where further improvements are coming next, and no way to ask for specific clarifications.

I think Dmitry was quite right in his point as well. Given that the original lawsuit was over the illegal use of Internet Explorer, I find it quite bitter indeed that Microsoft is still able to claim IE as part of the operating system. That is, there are a wide range of applications that will not function without Internet Explorer. Their failure is not because of a simple API that can be replaced with Firefox, but because of deep interwoven dependencies.

So, to summarize, the punishment to Microsoft for illegally pushing IE and destroying Netscape is...the continued use of IE as an monopolistic lever. Nice.

I'm not able to use wine command in crontab it giving following error "Error opening terminal: unknown"

I'm using wine 0.9, i have added following command in crontab

20 10 * * * /home/Maven/test.sh

In the "test.sh" file has the following wine comments

ssdir=/mnt/VSS-DB < VSS DB mounted folder --> path=$path;......

export ssdir
export path

wine "z:/mnt/winsys/Program Files/Microsoft Visual Studio/Common/VSS/win32/ss.exe" Workfold $/xyz/Development/src "z:/mnt/workfold/" -Yarunm,maven
wine "z:/mnt/winsys/Program Files/Microsoft Visual Studio/Common/VSS/win32/ss.exe" get $/xyz/Development/src -yarunm,maven -R -f

What you need is to upgrade to 0.9.1. It should work, as aforementioned ttydriver is no more and replaced with nulldriver.

OK, so what I suspect is happening is crontab has no DISPLAY variable set, so wine is defaulting to using the ttydriver. Unfortunately, crontab environment isn't attached to any tty, so that fails too with the error message you see.

What you really want is the nulldriver (which I think Alexandre mentioned once a while back) but that doesn't exist yet. [ed. note: it does exist] I'm not sure how to start up a pseudo-tty for your crontab entry. It should be possible but I'm not sure if there's standard tools to achieve it.

What I do for WRT is start up a VNC for the duration, then shut it down again. See script snippets below for some ideas. This should work for you, but its something of a hammer to crack a nut.

I used to use Xvfb (from XFree86) as the (virtual) frame-buffer device and have some scripts to support that. Unfortunately, that had a nasty habit of crashing whenever one tried any openGL/glx stuff and the XF86 people weren't interested in fixing the bugs.

Do something like:

crontab-script.sh:

#!/bin/bash

. /usr/local/share/wine/wine-functions # or wherever

eval $(startVNC)
wine some-prog.exe
eval $(stopVNC)

wine-functions:

function startVNC()
{
 res=${XVFB_RESOLUTION:-1600x1200}
 depth=${XVFB_DEPTH:-16}
 disp=${XVFB_DISPLAY:-1}

 $VNCDIR/vncserver :$disp -geometry ${res} -depth $depth
 echo "export DISPLAY=:${disp};"
 echo "echo vncserver up and running..."
}

function stopVNC()
{
 disp=${XVFB_DISPLAY:-1}

 $VNCDIR/vncserver -kill :$disp

 echo "unset DISPLAY;"
 echo "echo vncserver stopped."
}

Unfortunately, I had to patch vncserver script to stop it from writing to ~/.vnc. Here's the patch:

--- /usr/bin/vncserver Fri Feb 27 09:19:42 2004
+++ VNC/vncserver Sun Sep 25 21:18:34 2005
@@ -18,6 +18,8 @@  # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
 # USA.
 #
+# APM - 2005-05-13: work solely out of WRT directory. Unfortunately, this
+# requires patching this executable
 #
 # vncserver - wrapper script to start an X VNC server.
@@ -37,7 +39,7 @@
 $depth = 24;
 $desktopName = "X";
 $vncClasses = "/usr/share/vnc/classes";
-$vncUserDir = "$ENV{HOME}/.vnc";
+$vncUserDir = "$ENV{VNCDIR}" || "$ENV{HOME}/.vnc";
 $fontPath = "unix/:7100";

Modeled after winebrowser. Local testing found that thunderbird (know as mozilla-thunderbird on Debian-based systems) and evolution accept a mailto: url on the command line. kmail however has it's own interface. Any other GUI-based mail client of interest that handles these urls? Test it like so:

$ mua 'mailto:wine-devel at winehq.org?subject=test&body=test'

This should bring up a new mail window with To: and Subject: fields and text body set accordingly.

On December 1-2, OSDL is hosting a meeting for the desktop architects from the various Linux desktop organizations to help decide on ways to improve and promote Linux on the Desktop. An electronic copy of the invitation can be found at the following URL. This contains a full agenda, preparation info, and logistical info.

http://groups.osdl.org/apps/group_public/download.php/1522/osdl_invite_L2_P7.pdf

If anyone from wine is interested in participating, they are encouraging everyone to register for the meetings. They will be limiting attendance to 45, so they may only be able to accept 2 or 3 from every desktop organization, but they need your name on the list. A finalized list of attendees will be sent out afterwards. To register go to the following web site:

http://groups.osdl.org/apps/DTL_Architects_Meeting_Dec2005/register.php

Wine Project Overview
Purpose: Implement Windows API for Unix

Wine loader - run Windows Applications
Winelib - port Windows applications

All PE format files (.exe + .dll) 'just work' with binary loader.
C/C++ code recompiles and 'just works' with Winelib

CodeWeavers
ReactOS project

Wine Project History

Founded 1993
Single Maintainer
797 Contributors over Lifetime, ~40 active
Alpha Software, limited functionality, through 2005
First Beta (0.9) released October 2005
Many things work
Server interface stable
Some ABI stability

Associations With Other Desktop Organizations

Wine is a power user of the kernel, glibc, and x.org
Have very specific needs around memory, threading, and display control
We break X more than any other app I know
We get no respect
exec shield, glibc threading changes, feels like a constant arms race; be nice if we could be more involved, given time to respond
Also touch: OpenGL, ALSA/Jack/ESD/Arts/OSS
Hurray for Freedesktop.org
Menu Specifications
Xembed Protocol

Gap Analysis In Current Implementations

Missing capabilities
Many things don't work == a whole lotta bugs
Developing capabilities
Most core pieces are there, most things 'should' work
DirectX coming along nicely
Sound still needs work
Many things at 90%+, but still need work
Top priority development items in plan
"We have not yet begun to optimize"
Regression testing
Driving to 1.0

Major Plans

6 month plan
Refine beta releases of 0.9, drive towards 1.0
2 year plan
World Domination?

I guess we need to spell out what we need from other projects to better integrate Win32 apps with the rest of Linux. These things take time, and we need to bring them on their radar.

Also, if OSDL is willing to put some of their uber-kernel hackers on Desktop Linux, would be nice if we could come up with a spec on what needs to be done on the kernel side to speed up Wine. I know, this has been hashed out to death before, but I guess it would be interesting to probe and find out their willingness to help us out on the kernel side of things.

How about inability of X server to handle pixmaps larger than 32767 x 32767 and an ugly workaround introduced by the following patch:

ftp://ftp.x.org/pub/X11R6.8.2/patches/xorg-CAN-2005-2495.patch

This has been discussed under the "Re: Regression: Winrar fails to start" topic.

OK, here is my wish list from the X.org guys:

• relative mouse movement reporting. This is a must-have to have proper DInput support without the hacks we currently have in the code. Extension already discussed with X people on the mailing lists and they seem OK with it. Now we just need to find someone who codes it :-)
  
  As said, need to check if the XInput stuff could be re-used (last time I checked no as you cannot take control with XInput of the 'core' device - i.e. the mouse).
• full support for resolution / depth switching. A nice idea was discussed the other day on the fd.o lists: what about being able to easily start a new display using an X API which would start a new X screen. This screen could then be used for full-screen games and would support any requested depth / resolution change (the problem with the former - depth change - is that clients need to support it and so the 'new screen' idea would solve this problem as one could still have legacy X applications running on the 'main screen' while still have complete control of depth / resolution on this secondary screen).

Then some 'nice to have' which would help in the GL / D3D front but may be out of FD.O scope (and for which work-arounds are known):

• GL (GLX ?) extension which would remove the 'thread-affinity' from GL. I.e. a GL context would be at the process level and not at an application level. An even better solution would to be able to create 'shareable' contexts which another thread could attach to (i.e. remove the one thread <=> one context rule).
• GLX extension that would export the 'clip-list' functionnalities of cards (or at lest the one which is in the X code itself). Would help on applications (like Wine) that do their own in-window clipping.
• same point as before but for Xv the day we will re-add this code for accelerated YUV display.

Some 'misc' stuff that is really in the 'we could use it' category:

• have 'connection-level' configuration. Basically, if a client X change an X setting (resolution, mouse acceleration, ...), as soon as this client exits, restore the previous configuration. Would be useful to prevent having people restarting X because Wine crashed after having changed the resolution using XRand.
• have a non-connection limited mouse-grab. To explain better, this would enable one to grab the pointer into a window (i.e. the mouse would never leave this window) while still sending events to all connections and not only to the connection which started the grab. This could be nice to simulate 'full-screen desktop mode' or for DXGrab. No idea if with Wine's current event model this is still usefull though.

Another 'let's dream' possibilities:

• direct frame buffer access :-)

And finally, not in my domain, but investigate re-using something from FD.O for the fabled DIB engine (extensions to Cairo, ...) ?

First, apologies for the length. It's quite a complex issue:

A few days ago someone sent to the list asking why a program he'd written on WinXP runs under WineDbg but not under plain wine. Over the weekend I debugged the program and found out that his program doesn't use the standard WinMain entrypoint function. As such, he was using GetStartupInfo to get startup flags. He uses the wShowWindow flag to control the showing of the program's main window. Trouble is, this value is zero unless the program is started as a child process using CreateProcess, given a STARTUPINFO with wShowWindow set to something other than 0 (usually SW_SHOWNORMAL or SW_SHOW.) So my question is, how does the information in STARTUPINFO get set initially? I looked through the code for winecrt0 and found that before WinMain is called, the wShowWindow flag is set to SW_SHOWNORMAL. But because this program does not use WinMain, this value doesn't get set. However, the program works fine on native Windows XP. I looked at ntdll and kernel32 dll code, but I'm not sure I'm looking in the right place. Can someone give me some hints as to how to attack this problem?

What would it take to really support MS database client apps in Wine? The situation is not copacetic; everywhere you turn, it's easy to find enough problems to stop the average VB database app.

I tried installing a real world small government app. It used VBSQL.OCX, and required a file from the SQL 7.0 Client redistributables. Here's the script I used to install it (yikes): http://www.kegel.com/wine/initvbapp.sh.txt I lost touch with the guy who needed this app, presumably he gave up because it was so hard to install under Wine. Here are all the bugs related to mdac installation: http://bugs.winehq.org/buglist.cgi?product=Wine&long_desc_type=substring&long_desc=mdac_typ

Another VB database app installed (after some effort), but failed with an "automation error". http://bugs.winehq.org/buglist.cgi?long_desc_type=substring&long_desc=automation+error

Other VB apps use "dbgrid32", and a small sample app that uses that currently fails. See http://bugs.winehq.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=dbgrid32.ocx

Perhaps it's time to create an open source torture test in VB 6 that exhibits as many of these problems as possible, and use that as a regression test in Wine.

Anyone willing/able to take that on? Roderick Colenbrander wrote the DBGRID32.OCX test; perhaps he'd be willing to write an expanded set of tests?

I do not know what special needs the VB database apps have but for sure they need a good oleaut32.dll. At least the variant arithmetic functions aren't good enough for your requirements. With good enough I mean is that they do not handle all the input variants that native oleaut32 are handling. That isn't hard to implement but requires a lot of tests as this functions are very poorly documented and are designed specificaly to support only the variants they get passed down by the VB runtime. Good examples of such tests and implementation are VarMul, VarAdd and 1-2 other functions (from which I adapted the tests for VarMul and VarAdd). A sign for a not "fully" implemented variant arithmetic function is a fixme which says something like "VarXxx partial implementation, doesn't support vt ..." (if you get this it is the source of the automation error you more than probably got too) or if the function returns E_FAIL. From my experience so far with variant arithmetic functions those return in the native oleaut32 DISP_E_BADVARTYPE or DISP_E_TYPEMISMATCH.

Automation errors are of different kinds: easy to fix and hard to fix. #2480 would be an easier one to fix: The problem is in the VarCmp (variant arithmetic) function and the function would need to be changed to accept that combination of variant types the fixme is complaining about. No need to do it here as I resumed my work on VarCmp to make it accept the same input variants as native function in WinXP does. #1713 is a hard to fix bug as the OLE object functionality isn't implemented yet for richedit. Nor will it be according to the last comment in the bug report.