| � | ||
|
Kernel Traffic Latest�|�Archives�|�People�|�Topics |
Wine Latest�|�Archives�|�People�|�Topics |
GNUe Latest�|�Archives�|�People�|�Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
Table Of Contents
| 1. | 22�Feb�2004�-�26�Feb�2004 | (14 posts) | Cross-compiling Wine, Revisited |
| 2. | 24�Feb�2004�-�25�Feb�2004 | (4 posts) | Theming Widgets |
| 3. | 22�Feb�2004�-�26�Feb�2004 | (9 posts) | NetBSD Audio Driver |
| 4. | 26�Feb�2004 | (6 posts) | Implementing NdrClientCall/NdrClientCall2 |
Introduction
This is the 212th issue of the Wine Weekly News publication. Its main goal is to act as a gravitational lens. 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
Mailing List Stats For This Week
We looked at 177 posts in 678K.
There were 61 different contributors. 32 posted more than once. 28 posted last week too.
The top posters of the week were:
1. Cross-compiling Wine, Revisited
22�Feb�2004�-�26�Feb�2004 (14 posts) Archive Link: "Re: crosstest compile fix (another)"
Topics: Ports
People: Hans Leidekker,�
The topic of cross-compiling came up this week. It's been a little while since the topic came up. Hans Leidekker beat MinGW into submission:
As promised, a set of MinGW RPM packages for a MinGW cross compiler that can compile all Wine tests. I've thrown in three patches of mine: one that adds missing DirectX guids, an urlmon import lib and some corrections to comctl32.
Find them here:
Later he reported on cross-compiling all of Wine:
I spent some time cross compiling all of Wine with MinGW according to this recipe:
and I thought you might be interested in the results. I can report a bug in Wine's makefiles right away: having those vxd's in subdirectories that end in .vxd causes make to barf on targets like this one:
because, if $(DLLEXT) is empty, it will try to create a link with a name that's already there as a directory.
Of all dlls these don't compile:
x11drv, kernel32, gdi32 and ntdll being predictable, because they build directly on X11 and Unix API's. Same goes for the networking related dlls (ws2_32, icmp and iphlpapi, vnb.vxd, wininet, wsock32). msvcrt is close to building because what I saw was mostly header clashes, which could be fixed with proper guards I think.
rpcrt4 fails because it uses one Unix API, gettimeofday, and both comctl32 and shlwapi suffer from the bug in dlltool that Dmitry reported and fixed recently.
2. Theming Widgets
24�Feb�2004�-�25�Feb�2004 (4 posts) Archive Link: "Theming widgets"
Topics: Graphics
People: Kevin Koltzau,�Mike Hearn,�
The framework for Kevin Koltzau's theming work has been laid, now it's time to begin thinking about how it will affect the look and feel of Wine. Kevin asked for opinions on the actual widgets:
I'm starting to work on theming some widgets, and I've come up with a few methods of doing this:
Windows takes a totally different approach, using a different version of common controls that implement theming, under windows in order to enable theming you first need a manifest to load the proper version of comctrl32 then you also must call InitCommonControls which registers the standard controls (BUTTON,EDIT,etc)
Going with that, I think #3 might be the best option, and extend InitCommonControls to subclass the standard controls if theming is enabled
Mike Hearn had a different idea, " 4) Theme all widgets with a hard link to uxtheme but have a "Win98 look" theme which replicates the current drawing?"
Kevin said if theming is disabled then the widgets will be responsible for drawing themselves. So the current style will stay as it is in that case. No one else replied and it appears Kevin is leaning toward his third option listed above.
3. NetBSD Audio Driver
22�Feb�2004�-�26�Feb�2004 (9 posts) Archive Link: "Re: Native NetBSD audio driver"
Topics: Multimedia
People: Yorick Hardy,�Eric Pouech,�Robert Reif,�
Yorick Hardy created a sounddriver for NetBSD:
This patch adds the audio driver winenbsd using the native NetBSD audio system as an alternative to OSS. On the one hand this is useful to directly make use of the features of the NetBSD audio system instead of using emulation, on the other hand it is another driver to maintain and is quite close to the wineoss driver. If the driver is accepted, I think the NetBSD support for wineoss should remain for testing and for the main driver.
Eric Pouech thought maybe it should just be combined with an existing driver, " I really think we're starting to create a real mess for the audio drivers. It's always useful to have drivers access the HW at the lowest level, so we should support NetBSD. However, if the interface is rather close to OSS, I'd rather suggest we try to integrate all the drivers with the same features into a single piece of driver."
Yorick reposted his patch including bugfix. At the very least it's a good starting point for someone else. Dimi thought that any integration with the OSS driver needed to be done now before the NetBSD patch bitrots and diverges. Robert Reif expanded on Eric's idea:
I think it might be worthwhile considering restructuring the audio drivers into hardware independent wave, direct sound, midi and mixer sections and a hardware dependent low level implementation for oss, alsa, ...
The basic structure of all the drivers is similar enough to abstracted out the hardware independent portions.
Alexandre thought that was a good idea. Yorick mentioned he would be able to combine the OSS and NetBSD drivers but definitely wouldn't have to time to do the restructuring Robert suggested.
4. Implementing NdrClientCall/NdrClientCall2
26�Feb�2004 (6 posts) Archive Link: "NdrClientCall/format string interpreter/stubless proxies"
Topics: RPC / COM / OLE
People: Mike Hearn,�Robert Shearman,�Greg Turner,�,�Microsoft,�Rob Shearman
Mike Hearn asked Rob Shearman, " A few weeks back you mentioned you had done some work on implementing the stubless proxy entry points - can you explain a bit more about this? In particular, how far away are you from having something submittable, have you got docs on the format string syntax and how much are you intending to implement? "
Rob described the work he had done:
I have implemented NdrClientCall/NdrClientCall2 and respective server functions and they are working fairly well (except for no exception handling and no pipe support). The thing that was blocking my submission of the patch was lack of testing. So far I have only tested on simple types and pointers to simple types. Full pointers have been implemented, but are not working correctly. I haven't had time to port my test program to the Wine test framework and test the rest of the types.
I have been using references from MSDN on NDR format strings compared with my own tests based on code generated by MIDL. I have also used the OpenGroup DCE specification. (I have URLs for these, but not at hand and you can probably find them in my previous posts on the subject.)
I will try to submit the patches tonight.
Later he announced the patch was available for anyone who wanted to try it out:
I have uploaded the big stubless RPC patch to a website as it is rather large (~120k). You can get it here:
As you can probably see, a lot of the stuff in this patch is a bit rough around the edges (lack of copyright notice in some files), but it does seem to work for a lot of cases.
P.S. It doesn't work for native OLE32 yet because we need some undocumented interfaces in RPCSS.
Mike wondered if it would be possible to document some of it, " Wow, fantastic! One thing, could you write up some basic info on the structure of format strings? I'm just a bit concerned that one day we'll have to rewrite the typelib marshaller to use this interpreter and not know how, as this stuff is pretty opaque :) "
Greg Turner pointed out that Microsoft had already documented a lot of it:
They are actually pretty well-documented on MSDN:
Looks like a lot of work, Robert; thanks for your efforts.
�
�
�
�
�
�
Sharon And Joy
�
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |