WWN Issue 213

This is the 213th issue of the Wine Weekly News publication. Its main goal is to to save a ton of money on car insurance. 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

This week, 133 posts consumed 442 K. There were 61 different contributors. 24 (39%) posted more than once. 22 (36%) posted last week too.

The top 5 posters of the week were:

21 posts in 50K by Alexandre Julliard
7 posts in 19K by Robert Shearman
7 posts in 20K by Hans Leidekker
6 posts in 16K by Dimitrie O. Paun
6 posts in 14K by Dan Kegel

News: Macromedia Port?, TransGaming Editorial	02/28/2004	Archive
News Heise broke some news about Macromedia porting some software to Linux using Wine. The original article is in German, you may be interested in a Google translation . CNET had a longer article and other news from Macromedia. Flash MX allows you to create Flash media presentations. While Flash plug-in support has been available for a while under Linux, authoring software hasn't been. (At least, I don't know of any.. if I'm wrong I'm sure I'll be corrected.) The article states that they're modifying their software to work with Wine, rather than fixing Wine to run it. I imagine they're more familiar with their own codebase and that such modifications would be easier for them. This may also be an opportunity to fix problems with their software. Either way, it would be really nice if they could contribute something back. (Here's a hint, knock-off an item on our ToDo list . Extra credit will be given for taking over anything currently assigned to Alexandre.) Thanks to Stefan Leichter for the link and Phil Krylov for commenting on it. Speaking of the ToDo list.. let's take a count of how things are progressing: Green (completed): 19 Yellow (in progress): 30 Red (not started): 18 So how does this compare to a few weeks ago when we looked at it? At the time Green was losing to Red, 11 to 20. Now it seems Green has pulled ahead. Items "in progress" decreased from 31 to 30. Of course, we cheated by adding things to the list that had been completed. Tom Wickline found an interesting editorial about TransGaming . I think the author nicely summarizes some very valid concerns. Formulating an opinion is left as an exercise for the reader.

News: Macromedia Port?, TransGaming Editorial

02/28/2004

Archive

News

Heise broke some news about Macromedia porting some software to Linux using Wine. The original article is in German, you may be interested in a Google translation . CNET had a longer article and other news from Macromedia.

Flash MX allows you to create Flash media presentations. While Flash plug-in support has been available for a while under Linux, authoring software hasn't been. (At least, I don't know of any.. if I'm wrong I'm sure I'll be corrected.) The article states that they're modifying their software to work with Wine, rather than fixing Wine to run it. I imagine they're more familiar with their own codebase and that such modifications would be easier for them. This may also be an opportunity to fix problems with their software. Either way, it would be really nice if they could contribute something back. (Here's a hint, knock-off an item on our ToDo list . Extra credit will be given for taking over anything currently assigned to Alexandre.) Thanks to Stefan Leichter for the link and Phil Krylov for commenting on it.

Speaking of the ToDo list.. let's take a count of how things are progressing:

Green (completed): 19
Yellow (in progress): 30
Red (not started): 18

So how does this compare to a few weeks ago when we looked at it? At the time Green was losing to Red, 11 to 20. Now it seems Green has pulled ahead. Items "in progress" decreased from 31 to 30. Of course, we cheated by adding things to the list that had been completed.

Tom Wickline found an interesting editorial about TransGaming . I think the author nicely summarizes some very valid concerns. Formulating an opinion is left as an exercise for the reader.

Wine As A Shared Library & Mono	03/04/2004	Archive
Winelib Integration The Mono guys having been working at better integrating Wine into their .Net implementation. The idea here is that Wine is capable of doing all the complex windowing required of .NET's System.Windows.Forms classes. So it makes sense to bolt Wine's Win32 to C#. Unfortunately, Mono required a forked version of Wine in order to load things the way they want. This doesn't help anyone and the maintenance work is a pain. (For more info, see some of the earlier threads in issues #162 and #171 .) Peter Bartok posted a small patch this week and explained a new process: This patch allows to use Wine as a shared library. It will allow the Mono project to use Wine as the backend for it's System.Windows.Forms implementation. ChangeLog: Alters initialization code to return control to caller instead of executing application if __wine_shared_lib flag is set. Adds winelib executable (wine-sharedlib) that a consumer can use to initialize Wine as a shared library, to load Wine DLLs and to import functions from DLLs. This is interesting because it's behavior that's often requested of Wine. Their addition is also nicely compartmentalized. Miguel de Icaza hoped it would get integrated, We are running some SWF applications now with Mono and this patch; And we are fairly happy, since it's a small patch to maintain this time. Of course, it would be best to make it part of Wine, so the user does not need two separate Wine installations. There appears to have been some private correspondence that took place off the list about some of the details. It may very well remain a separate patch.

Wine As A Shared Library & Mono

03/04/2004

Archive

Winelib Integration

The Mono guys having been working at better integrating Wine into their .Net implementation. The idea here is that Wine is capable of doing all the complex windowing required of .NET's System.Windows.Forms classes. So it makes sense to bolt Wine's Win32 to C#. Unfortunately, Mono required a forked version of Wine in order to load things the way they want. This doesn't help anyone and the maintenance work is a pain. (For more info, see some of the earlier threads in issues #162 and #171 .) Peter Bartok posted a small patch this week and explained a new process:

This patch allows to use Wine as a shared library. It will allow the Mono project to use Wine as the backend for it's System.Windows.Forms implementation.

ChangeLog:

Alters initialization code to return control to caller instead of executing application if __wine_shared_lib flag is set.
Adds winelib executable (wine-sharedlib) that a consumer can use to initialize Wine as a shared library, to load Wine DLLs and to import functions from DLLs.

This is interesting because it's behavior that's often requested of Wine. Their addition is also nicely compartmentalized. Miguel de Icaza hoped it would get integrated, We are running some SWF applications now with Mono and this patch; And we are fairly happy, since it's a small patch to maintain this time. Of course, it would be best to make it part of Wine, so the user does not need two separate Wine installations.

There appears to have been some private correspondence that took place off the list about some of the details. It may very well remain a separate patch.

WinCE Apps & Wine	03/04/2004	Archive
Steven Edwards looked into supporting WinCE apps with Wine. Apparently things are in pretty good shape to support it. He outlined what he needed to do in order to set up a test environment: This is all very experimental. I am working on in the ReactOS tree and it might not even work for larger apps but I am happy with the results so far. I was thinking the other day that ReactOS and WINE/Linux might get a big boost if we can push support in the embedded environment so I started taking a look at WinCE and Microsoft Embedded Visual C++ 4.0 .BTW: It's a free download now. http://www.microsoft.com/downloads/details.aspx?FamilyID=1dacdb3d-50d1-41b2-a107-fa75ae960856&DisplayLang=en I started looking at WinCE and thought it would be nice if we could be source compatible with WinCE apps and binary compatbile on x86. Well it seems that WinCE apps don't differ much from standard Win32 apps except the subsystem ID is different. If you attempt to run a WinCE application on Windows it will say that it's not able to run. Ok no problem, we just run "editbin /subsystem:windows blah.exe" and check it out. Now the app is looking for coredll.dll. No problem there I have created a stub coredll.dll that just forwards all calls to the proper Win32 dlls such as user32, kernel32, etc..... .....and check it out. My little messagebox test works on Windows. Ok soon then I go and run the same test on ReactOS but this time I run a copy of messagebox without changing the subsystem ID...Hey what do you know. It works =). I talked with Alexandre about it a bit and he said that WINE like ReactOS also shouldn't care about the subsystem ID so if someone is interested in testing just drop the messagebox programs and coredll.dll in to a directory and give it a shot. I am having trouble getting more complex apps (hello world) to work atm so I think i am just going to take a break and clear my head for a few days. Some of the WinCE API and Win32 is not 100% compatible so we can't just forward all parts to the Win32 implementation but I think we can do it for most of it. If anyone is interested in helping out the source is in the ROS CVS tree and attached to this email...... binary.zip messagebox.exe - wince messagebox program msgbox.exe - wince messagebox program with subsystem id changed to Windows. wincehel.exe - Hello World WinCE app wincehelw.exe - Hello World WinCE app with subsystem id changed to Windows. coredll.dll - WinCE Win32 API commctl.dll - WInCE common controls API. source.zip coredll - dummy forwarder dll commctl - dummy stub dll for common controls

Using Borland's C++ Linker	03/05/2004	Archive
Fixes Michael Pyne worked around a small problem that prevented him from using Borland's linker: If it helps, the patch that I was referred to a week or so ago regarding the linker for Borland C++ 5.5 hanging did work, after some modifications. It is attached to this message. Basically, I translated the VirtualAlloc() call into it's NtAllocateVirtualMemory() equivalent to solve the unresolved symbol errors, and just plain left out the check at the end of the function for the region size. Hope that's OK. Obviously this patch isn't suitable for inclusion into Wine proper since it seems to merely patch over a different problem. I've recompiled Wine with full debug information and such, and if someone knows what I should look for or do, I'd be more than willing to provide debug output to nail down the error. I've tracked down the infinite loop to NTDLL_wait_for_multiple_objects() in dlls/ntdll/sync.c. For some reason, whatever the program is waiting on doesn't ever seem to occur (unless, of course, the above patch is applied?!?).

World Wine News