• Still more work on Direct3D shaders.
• Now using the Gecko engine directly for MSHTML.
• Better support for apps switching to full screen mode.
• Support for multiple joysticks.

• Still more work on Direct3D.
• A lot of MSI bug fixes and improvements.
• More compatible memory management.
• Several fixes for Win64 support.
• Some performance improvements.

What Applications Will it Run?

We intend for it to run all the applications that our current CrossOver Office product runs, with some new additions in the Microsoft 2003 version products. We also hope to offer support for a limited number of games. However, the final mix of supported applications is still being determined.

Our annual Wine conference is taking place in approximately 6 weeks time. It is an opportunity for you to put names to faces and to talk about projects that are too crazy to think about discussing on wine-devel! It is also an opportunity to share knowledge and to share some drinks!

When is it? 16th & 17th September 2006

Where is it? University of Reading

Who Should Come? Anyone interested in Wine development. Please note: this is a developers-only conference.

How To Sign Up? Check out http://www.winehq.org/site/wineconf for details. Please RSVP if you intend to come.

What's the Agenda? We'll be starting a thread on that shortly.

What's Urgent? The University is requiring that we have an exact head count for rooms on campus. What's more, we have to give them that count a month in advance, and they will not give us a refund for folks that don't show up or want to change things around. Hence, if you would like one of the convenient, reasonably priced rooms on campus, you need to follow the payment step at: http://www.winehq.org/site/wineconf/travel

as soon as possible to book your room. Note that since we won't get any refunds for cancellations, we won't be able to refund your money either :-( .

I thought WineConf 2005 was a lot of fun and I think everyone else who attended would agree with me, so hurry up and make your travel arrangements and RSVP now!

I know that Wineconf is still over a month away, but you'll really regret it if you don't make your accomodation selections now.

If you paypal (or even arrange to mail a check) to me *now*, you'll get to hang out with all the cool people, on campus, and learn what the "Drink-making facilities on each corridor" really means, all for the low low price of about 40 pounds (okay, so the exchange rate sucks, and that's $75 US, but still...)

If you don't get me an room request in the next few days, then I'll have to close down our room reservation, and you'll be stuck in some sleazy motel on the edge of town paying outrageous sums of of money. (Okay, they actually all look like nice places to stay, but they will be a ways away, and they all cost more :-/).

Again, see this page for more details:

http://www.winehq.org/site/wineconf/travel

If you can't do Paypal, I can take a check in US currency as well.

Much thanks for the comments on yesterday's patch of a service thread implementation for remote process operations. This patch uses APCs to implement CreateRemoteThread/RtlCreateUserThread, VirtualAllocEx/NtAllocateVirtualMemory and VirtualQueryEx/NtQueryVirtualMemory.

APCs are queued per-thread, so I made minimal changes to add a per-process APC queue. Of course, this implementation suffers from the limitation that the remote process must go into an interuptible wait for the operation to succeed; an operation targeting a suspended process would block.

Stefan Siebert mentioned that VirtualQueryEx is necessary for Lotus Notes Software Diagnostics (nsd.exe). I successfully tested this function with a simple program that prints a process' memory map:

http://www.codecomments.com/archive371-2005-3-421246.html

Lastly, I should mention that I have two pending patches to add conformance tests for remote processes operations:

• http://www.winehq.org/pipermail/wine-patches/2006-July/029259.html
• http://www.winehq.org/pipermail/wine-patches/2006-July/029260.html

Tommy's APC version of his VirtualAllocEx / CreateRemoteThread patch seems to be safe (since APCs only run a points where threads in well-written programs are not holding locks), is complete enough to make many apps happy, and is probably the best that can be done without a service thread or a real kernel change. I've encouraged him to submit it for real. Let's get this puppy committed!

I'm not too clear why this is a problem. I thought that kernel APCs run on just interruptible waits, which excludes the wait on suspend and perhaps others.

Also, I was under the impression that only locks taken in the code path of the VM and thread creation functions had to be respected. If necessary, non-interruptible waits could/should be done while holding these locks (although I looked through the code and it doesn't look like any applicable code does a wait while holding a lock).

The closest Alexandre has come to answering this is

http://www.mail-archive.com/wine-devel@winehq.org/msg29265.html

but with APCs we at least handle one of his two objections (an APC definitely doesn't interrupt any critical section initialization). leaving

"One problem is that many locks have to be acquired in a specific order to avoid deadlocks, and since you don't know which locks the thread is already holding you can't guarantee the order"

So all you have to do is identify all the locks that your APCs might need to acquire, and verify that they are always acquired in the same order by all possible code paths.

Well, you are right that running APCs only on waits is a lot safer than interrupting the thread anywhere. Unfortunately, interrupting the thread is really what you want. In particular remote operations on suspended threads have to be supported, since manipulating a process from the debugger is probably the number one reason for this feature.

Still, doing that stuff in APCs is a step in the right direction, you just need to make sure you can safely run these APCs from the SIGUSR1 handler.

Some patches were committed to wine recently to make it use _NET_WM_STATE_FULLSCREEN for fullscreen apps. These patches appear to work in kwin but not metacity (I was using firefox as a test). In metacity, it appears wine recognizes that it needs to make a window fullscreen and send the appropriate message, but nothing happens (panels are still on top of firefox in fullscreen mode).

I've mentioned this in Wine's bugzilla #3312, but I suspect it's probably caused by some quirk in metacity that wine triggers by doing some rather odd things itself. That's why I've CC'd the metacity-devel list (to which I and probably anyone on any wine mailing lists are not subscribed).

So, uh, metacity people, under what circumstances would metacity be likely to put a window that had sent the proper _NET_WM_STATE_ADD message for _NET_WM_STATE_FULLSCREEN behind panels?

Windows does not have a fullscreen mode. In Windows, windows that are Always on Top are on top of panels. Windows applications enter "fullscreen mode" by positioning themselves take up the whole screen and being always on top (actually, now I'm not so sure they have to be always on top; I'm only basing that on my experience as a Windows user).

When the size of a window or the screen resolution changes, Wine marks windows whose client area covers the whole screen as fullscreen. This is done in the update_fullscreen_state function in this file.

Look at src/window.c:recalc_window_features() for possible reasons metacity decided to disable fullscreenability.

In this case it looks pretty clear though - the firefox window isn't resizable, metacity disables fullscreen in that case unless the window size is equal to the screen size and the window is not decorated.

It looks like 1280x1024 could be your screen size, so my guess is that the window has a frame on it.

I don't really know why the !window->decorated is in the check in recalc_window_features but Elijah may well.

This would explain why wine fullscreening works sometimes, it probably works when the window is a) full screen size and b) also disables the window decorations.

Fullscreen mode would remove the decorations anyhow though, is why I don't know why metacity checks this.

>From the metacity log, it looks to me like Wine withdraws the window, turns on window decorations, then remaps the window.

Metacity then has to unmap/map one more time in order to place the window inside its window frame. Undecorated windows don't have a frame so don't have the extra unmap/map caused by reparenting, but normal windows do.

Clients and WMs both have to distinguish between maps that are incidental to implementation details and maps that have a meaning in the ICCCM. Essentially you need a "withdrawn" flag on windows indicating whether you have yourself mapped or unmapped the window. The WM may also map/unmap in order to reparent, manage workspaces, etc. and you should just ignore those map events most of the time.

If you need a "steady state" mapped status that matches the Windows API, then you would need to "simulate" it on the client side, by e.g. using the client-side withdrawn flag instead of the mapped state.

I've added a patch which fixes the problem for me. Here is a comment I've put there to explain why the patch is needed:

"The problem appears to not be related to the heuristics Metacity uses to check whether a window may be fullscreened, but rather to a missing update of a window state after screen resolution change so that heuristics can do their work.

I've used slightly old Metacity 2.10.0 sources, but hopefully the attached patch is still relevant."

Please let me know whether the patch is a right way to fix the bug, or you need further explanations.

Actually, that's because Dmitry was using an older version. The patch actually appiled to head would have also applied to 2.14.3. :) Anyway, the returning from fullscreen mode bug makes perfect sense, and I'm pretty sure I know the cause: metacity tries to return the window to the size it was before it was fullscreened, and it sounds like it was successful in this case. Remember that the application resized itself to the size of the screen, then you (wine) noticed that and decided to send the fullscreen toggle message. Thus, the size the window had before being fullscreen, happened to be a size equal to the size of the screen. Since wine has added heuristics for detecting when an app sets its size to the size of the screen, I think it either needs to add heuristics for resizing back to normal size, or to just have the fullscreen toggle message replace the apps' resizing commands instead of supplementing them.

Something strange to happened my Wine installation recently. I'm getting following messages if I run any program from Wine:

$ winemine
wine_main_preload_info not found
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
wine_main_preload_info not found
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report

The programs still work fine after those for lines are printed. What's worse is that that Windows PE files don't work at all, including those that come with Wine:

$ wine winhlp32.exe
wine_main_preload_info not found
wine: could not load L"C:\\windows\\winhlp32.exe": Module not found

I'm using current Wine from git on Fedora Core development (future FC6) for x86_64, glibc-2.4.90, gcc-4.1.1, Linux 2.6.18-rc2 (actually, the current version from the wireless-2.6 branch). The CPU is Intel with EM64T. Wine is compiled with default settings for i386 by the i386 compatibility compiler and i386 compatibility libraries included in Fedora. I removed ~/.wine to start with a clean system.

Since I keep updating the kernel and Wine almost every day and I upgraded from FC5 to Development recently, it's hard to say what's the exact reason.

P.S. I have a 32-bit Ubuntu 6.04 installation on the same machine, so I used chroot to compile and run Wine under Ubuntu under the same 64-bit kernel. I also used linux32 to fool uname into thinking it's an i686 machine. The messages from ELF programs are gone, but PE files still fail:

$ winemine
$ wine winhlp32.exe
wine: could not load L"C:\\windows\\winhlp32.exe": Module not found

Moreover, if I run this Wine on Fedora, the results are the same - no more messages about wine_main_preload_info and setup_dos_mem. I guess it's a compile issue. Unfortunately, the difference between config.status in both builds is quite significant to pinpoint the reason.

Looks like the wine-preloader isn't being run, so memory that wine needs isn't reserved.

Maybe check that configure is setting the EXTRA_BINARIES variable?

mike@black:~/wine$ grep ^EXTRA_BINARIES loader/Makefile
EXTRA_BINARIES = wine-kthread wine-pthread wine-preloader

It is installed and it is run. If I replace wine-preloader with a script that logs the arguments and runs the renamed wine-preloader, I see it being called twice when an exe file with run with Wine. For example:

$ wine FarManager170.exe
wine_main_preload_info not found
wine_main_preload_info not found
wine: could not load L"Z:\\home\\proski\\dist\\windows\\FarManager170.exe": Invalid address

OK, it seems to be that the preloader can't lookup the ELF symbol "wine_main_preload_info" in wine-pthread.

That's bad, because the preloader is reserving memory, but has no way to let wine-pthread know which memory it reserved.

Can you see that symbol exported from wine-pthread?

mike@black:~/wine$ nm loader/wine-pthread | grep wine_main_preload_info 7bf023d8 B wine_main_preload_info

find_symbol() looks for DT_HASH (4) to set symtabend and fails to find it. As I understand it, we should trick ld into creating the DT_HASH tag or use some other way to locate wine_main_preload_info.

The 6ffffef5 tag is DT_GNU_HASH - that may be a good alternative to DT_HASH. Adding -Wl,--hash-style=sysv to the gcc flags when linking wine-pthread solves the problem!!!

I think adding support for DT_GNU_HASH would be a good idea anyway.

Great work! There's some information on DT_GNU_HASH here:

http://sourceware.org/ml/binutils/2006-06/msg00418.html

Looks like we don't actually use the hash table to look up the symbol, just to find the last entry in the symbol table.

I agree with you the best way to solve the problem would be to handle DT_GNU_HASH.

Thanks to a few targeted patches written by Stefan Siebert and James Hawkins, and of course decades of effort by the whole Wine team, Lotus Notes 7 trial version now installs and runs! See http://wiki.winehq.org/LotusNotes for details.

I just spent an hour or so playing with Notes as a plain old email client. It had a few mysterious crashes, but in general seemed usable. (Not that I'd ever use it after getting used to gmail, but that's another story.) I filed bug #5752 about a strangeness in the email client.

Good news. One possible "market" for this is in the Debian world as currently the Linux Notes client will not install as it can not work out what version of Mozilla is installed. IBM have never really make any of their stuff easy to install on Debian. Of course the Debian sid wine will need to be brought up to date (currently .15) and will need the two patches mentioned above included.

Luc: is there a definitive list somewhere what API WinLib implements of Win32, and what it doesn't? I have had some difficulty finding this information.

Dan: Each of Wine's DLL's comes with a file which lists which APIs it implements, e.g. atl.spec The lines that say 'stub' are not really implemented.

http://www.winehq.org/site/winapi_stats has a summary of this data, I think. But even some of the ones that don't say 'stub' are only partial or sham implementations. The real way to tell how many bugs your Windows app will run into is to try simply installing the Windows app on Linux using Wine. Does your app have a regression test or GUI test framework of any sort? If so, you can run that under Wine and compare results.

Luc: one application we'd like to port uses active scripting (VBScript). Basically we wrote some features in VBScript, which in turn automating our application (like macros in Photoshop CS). What would be our options for this if we were to use WinLib? (MainWin ships with VBscript and JScript)

Dan: Wine doesn't currently support VBScript (unless you install WSH from Microsoft). That could be added, but it'd be a substantial effort.

Luc: Would the Ole Compound Storage format (StgCreateDocfile) WinLib read/write be binary compatible with the one on Windows?

Dan: Should be.

Luc: what are the options of an application that embeds the IE web browser control?

Dan: That's supported now, though you may find that Wine's implementation has rough edges. Nothing a little support contract with Codeweavers couldn't iron out.

Incidentally, if you're sticking with x86 only, you should consider just shipping your Windows .exe unchanged, and using Wine instead of Winelib. It works just as well, and it's a lot easier. That's what was done for Picasa.

If you haven't already seen it, you might want to look at my Wine for Windows ISVs page, http://kegel.com/wine/isv

I expect you'll run into some issues when testing your Windows executable on Linux with Wine. When you do, I'd be glad to try to help resolve them (though I might need you to send me a copy of the software so I can reproduce the trouble locally).