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
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 about that and other news in the Macromedia world.
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:
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.
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 maintainance 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 its 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 correspondance that took place off the list about some of the details. It may very well remain a separate patch.
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 enviroment so I started taking a look at WinCE and Microsoft Embedded Visual C++ 4.0 .BTW: Its 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 dont differ much from standard Win32 apps execpt the subsystem ID is differnt. If you attempt to run a WinCE application on Windows it will say that its 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 shouldnt 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 cant 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......
- 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.
- coredll - dummy forwarder dll
- commctl - dummy stub dll for common controls
Michael Pyne worked around a small problem that prevented him from usign 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?!?).