Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||3 Apr 2004 - 9 Apr 2004||(4 posts)||News: Wine-20040408, developerWorks Article, WiX|
|2.||6 Apr 2004 - 7 Apr 2004||(7 posts)||Managing Windows|
|3.||6 Apr 2004||(1 post)||AbiWord on ReactOS|
|4.||5 Apr 2004 - 6 Apr 2004||(5 posts)||CryptoAPI Needs Help|
|5.||8 Apr 2004||(8 posts)||Execshield/Prelinking (con't)|
|6.||6 Apr 2004 - 7 Apr 2004||(6 posts)||Some Development Stats|
|7.||2 Apr 2004||(1 post)||W95inf32 DLL Implementation|
|8.||7 Apr 2004||(1 post)||Arch Utility: genpatch|
|9.||6 Apr 2004||(1 post)||How To Set Up BiDi Support|
This is the 218th issue of the Wine Weekly News publication. Its main goal is to get ready to go on vacation. 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 115 posts in 523K.
There were 47 different contributors. 27 posted more than once. 26 posted last week too.
The top posters of the week were:
1. News: Wine-20040408, developerWorks Article, WiX
3 Apr 2004 - 9 Apr 2004 (4 posts) Archive Link: "Mews"
People: Alexandre Julliard, developerWorks, Rob Mensching, eWeek, eweek, , Microsoft, ReactOS, News
Just after I thought I'd finished this week's issue, Alexandre came out with Wine-20040408:
WHAT'S NEW with Wine-20040408: (see ChangeLog for details)
The first of those, configuring drives and ports with symbolic links, are the results of the new filesystem changes. There's definitely some interesting stuff in there. It might take a few days for all the builds to be available, but you can grab them from our download page.
IBM's developerWorks put together an article titled "A taste of Wine: Transition from Windows to Linux". It provides a great overview of Wine and even digs into Winelib by providing a sample app. The authors offer some interesting tips, "In debugging Wine installs, it is very useful if you have a Windows system available as well. That way, you can use a tracer on a Windows installation to find out exactly which files are copied, which registry entries are added or updated, which INI files are altered, and so on. Noting the order of the install steps and comparing with a failed Wine install is a good guide for troubleshooting. "
An item that made the news early in the week concerned Microsoft putting a project on SourceForge. There was a bit of confusion concerning exactly what WiX is. One of the reasons I'm even mentioning it here is because some people theorized it would help Wine with Microsoft installation programs. I think the best summary comes from the blog of it's creator, Rob Mensching:
Before everyone gets sidetracked by the Open Source implications, let.s talk about exactly what WiX is. WiX is a toolset composed of a compiler, a linker, a lib tool and a decompiler. The compiler, called candle, is used to compile XML source code into object files that contain symbols and references to symbols. The linker, called light, is fed one or more object files and links the references in the object files to the appropriate symbols in other object files. Light is also responsible for collecting all of the binaries, packaging them appropriately, and generating the final MSI or MSM file. The lib tool, called lit, is an optional tool that can be used to combine multiple object files into libraries that can be consumed by light. Finally, the decompiler, called dark, can take existing MSI and MSM files and generate XML source code that represents the package.
So no, WiX is not an implementation of Microsoft's Installer. Nonetheless, this is an interesting foray for Microsoft. The eWeek article linked above theorizes on some ulterior motives they may have for allowing this.
LinuxToday began posting community news again after taking several months off. Thanks goes out the Brian Proffitt, LinuxToday Editor, for that.
2. Managing Windows
6 Apr 2004 - 7 Apr 2004 (7 posts) Archive Link: "Window management thoughts"
People: Mike Hearn, Dimitrie Paun, Alexandre Julliard, , Dimi Paun
One of the big items on the to-do list is to change the way Wine handles windowing. Mike Hearn started a thread this week about window management:
So, me and Mike have been discussing some ideas for window management in Wine. Currently it hasn't turned into code, but I thought I'd write up what our thoughts were so others could comment and maybe be inspired to write patches.
Currently Wine decides whether to make a window managed or not based on a series of heuristics, in is_window_toplevel in dlls/x11drv/window.c
Unfortunately these heuristics are frequently wrong, as they have only limited information to work with (window styles, mostly). In CrossOver, is_window_toplevel is easily the most hacked function in the entire codebase. This manifests itself in a variety of ways:
We currently make certain windows unmanaged typically because we need to control their position or rendering with a high degree of accuracy. Unfortunately some X window managers ignore positioning hints, even when we ask them not to. There is no way to make things like menus and tooltips work correctly with these WMs, so we take the window out of the usual window management mechanism entirely.
Unfortunately due to the design of the win32 API there is no simple way to tell the difference between a large menu and the Trillian main window. We could mark our own menus specially to make them unmanaged and have everything else be managed, but we then run into problems with programs that draw their own menus and tooltips, of which there are a truly shocking number.
So what is a possible solution?
Well, one way forward is to implement another mode, in which Wine makes all windows managed and uses a variety of WM hints to get the desired behaviour. For instance, the PPosition flag asks the WM to place the window where the application requests it to. Some WMs respect this, others do not, in yet others it's a toggleable option. For people with WMs that meet the requirements of Wine all windows could be made managed, and for people that don't use such WMs the old way can still be used.
IIRC it's possible to ask the WM for identification which means this setting could be largely autodetected by having blacklists of WMs to use the old mode for (or vice-versa).
Unfortunately there's no way to know how well this approach would work, or even if it would work at all, short of trying it.
Dimi Paun thought the plans were to abandon that way of managing windows:
I personally think we should not care about non-compliant WMs. You use one of those, you suffer the consequences. We can't operate in a vacuum, there are standards, and we must be able to rely on something.
But this, I'm afraid, besides the point. This entire discussion assumes that the Win32 windows are mapped to X windows. If IIRC, Alexandre was saying that we need to switch back to the old ways, where we handle most of the windowing code. In which case I guess a lot of this will go away.
Mike then clarified his original idea, "as far as I know the WM rewrite is about using X windows only for toplevel win32 windows, and not using X child windows for win32 child windows. The managed/unmanaged thing is only relevant to toplevel windows. So I think they are separate though it'd be nice for Alexandre to clarify exactly what the WM rewrite will affect and entail. "
Alexandre then explained some of the work he planned to do:
Well, it's not really a rewrite, more the continuation of the address space separation work, to make all of the window management instead of just half of it behave properly across processes.
The managed/unmanaged thing is really a different issue, but the inter-process stuff will change a lot of things in x11drv, that hopefully will then make it easier to deal with the managed stuff (for instance by making it easier to recreate a window on the fly to switch to managed mode); so that's why I think the inter-process support should be finished before we start making big changes in the X11 WM support.
In case you missed it, those two paragraphs probably constitute our roadmap for the next few months.
3. AbiWord on ReactOS
6 Apr 2004 (1 post) Archive Link: "AbiWord on ReactOS"
People: Steven Edwards, , ReactOS
From time to time we mention ReactOS. Those guys are basically making a clone of Windows NT including binary compatibility for Windows drivers. For their Win32 subsystem they've adopted Wine. It's been a win-win situation for both projects and this year they've really started to make a lot of progress on their user interfaces. This week Steven Edwards forwarded a message from their mailing, "Run abiword lately after those recent changes? simply amazing...the first REAL app to run on ROS..."
Like they say, a picture is worth a thousand words: AbiWord screenshot.
4. CryptoAPI Needs Help
5 Apr 2004 - 6 Apr 2004 (5 posts) Archive Link: "CryptoAPI"
People: Jacek Chaupka, Juan Lang, Robert Shearman, , Microsoft, Mike McCormack, Rob Shearman
Getting crypto and security related API's has come up more and more recently. Jacek Chaupka wanted to know what was going on:
Has anybody started implementing CryptoApi in WINE?? If no mayby someone can give me some clues how to start... I am not bad i C++ I think, but I have never make thing like that. I don't promise I will do that, but I can try... :)
Juan Lang offered a starting point:
Hi Jacek, take a look at Wine's rsabase.dll, that DLL doesn't do very much yet. All its functions (CPAcquireContext, etc) are described here:
If you have access to a Windows box it's easier: you can load the DLL itself and call all the functions and try to reproduce what it's doing.
Rob Shearman also had some ideas:
It depends on which part you are trying to implement. For the Certificate Store functions I would recommend implementing the "OID support functions" first, as it is indicated by [ same link Juan had above ] that a number of other functions depend on them. The OID's are looked up from a set of builtin types (see CertOpenStore reference) and from the registry key: HKLM\Software\Microsoft\Cryptography\OID. Some other tips: MSDN is a good resource for information. Try to implement functions using other Win32 functions. Write test programs to run against the Wine and Microsoft versions of the DLLs.
Juan wasn't sure if that was necessary or not though, " I was taking a look at implementing the certificate store functions, and I was thinking (hoping?) I could avoid the OID stuff. Maybe I'm missing something, but a cert will be stored in the registry in some well-known format, and as long as Wine handles the registry I/O bit, OpenSSL ought to be able to read the certs, right? So CertOpenStore/CertEnumStore et al wouldn't need to do any asn.1 decoding, at least not from the get-go."
Mike McCormack actually added an item to the Fun Projects page a few weeks ago and thought it could be implementing using OpenSSL's libcrypto.so.
5. Execshield/Prelinking (con't)
8 Apr 2004 (8 posts) Archive Link: "inheriting exec-shield avoidance"
People: Peter Riocreux, Mike McCormack, Mike Hearn,
Peter Riocreux brought up execshield/prelinking again this week (see last week's issue for more about that.) This time it involved Fedora Core 1:
I am intermittently trying to get Wine to play nicely with a big EDA tool, and it is doing not too badly today with the 20040309 snapshot on Fedora Core 1.
The thing that I think is stopping it working is that whatever is done to stack-shield by the prepending "setarch i386" on invocation is not inherited by the .exe that the program calls. Net result is that I get the "..... security-patched kernel ?" error message from the child process instead of the parent. Progress of a sort.
Is there anything, short of turning off exec-shield entirely, that can be done about this?
Mike Hearn suggested turning off prelinking too. Then Mike McCormack jumped in and mentioned he had been working on things a bit:
I'm not familiar with the using "setarch i386" to solve the problem...
I've also been working on the exec-shield problem over the last couple of days. My solution is similar to Mike Hearn's approach, but faster and more compact, since it doesn't require loading of libc twice or static linking with glibc. The idea is to use a staticly linked ELF object, reserve memory and then load the target dynamicly linked object.
It seems to do what I want, but will require a patch or two to wine to use MAP_FIXED when mapping the first megabyte of address space, and to make sure newly forked processes are forked with it as the (pre)loader.
I've attached the source code. The idea is to run it like this:
wld /home/mike/wine/loader/wine-pthread my.exe
Peter tried it out and reported:
First up, I get two instances of the following:
unknown header type 6474E551
It makes the first load work, - giving the same result as the setarch idea (I know (or at least I *think* I know) it is by a different means), but it doesn't solve the inheritance/forking problem. I assume that is what the patches you mention would do.
To make this a bit clearer, A creates children B then C. With setarch or wld when exec-shield is ON, A loads, but B doesn't. With exec-shield OFF, B loads, but C doesn't! I don't understand the latter at all.
In case it is relevant, I suspect that the child processes are created by a built-in scripting language engine.
Mike recognized the problem, " Yeah, I'm aware of the problem with interitance... there might be a tricky way to fix it by setting WINELOADER to the name of a script that runs "wld $winebinary"... otherwise wine will need to be modified. "
Peter had some ideas for other fixes:
If wld knew (hardcoded or from an environment variable) where to find wine (the binary), no script would be necessary and it would be even simpler. At configure/compile time Wine could know/detect/be told whether the default loader had to be wine (the binary) or wld.
Thinking further, why not, if wld is needed, call what is now wine something else (e.g. winefoo for this discussion) and wld be called wine. Then no source modification is needed to existing wine code and invocation using wine rahter than wld is possible, maintaining users' mental compatibility and script compatibility (IYSWIM).
Mike Hearn felt that the work he had done could be merged with Mike M.'s to get a reasonably efficient and working solution.
6. Some Development Stats
6 Apr 2004 - 7 Apr 2004 (6 posts) Archive Link: "Project Management"
People: Mike Hearn, Brian Vincent, , News
It might not be obvious from reading this weekly newsletter, but development has picked up a bit over the past few months. Mike Hearn pointed out an interesting statistic:
Check that out - 5mb of patches for the last 3 months running. A meg of patches just 6 days into the new month already!
It seems Wine is moving faster than ever before.
Then there was a bit of discussion about the size of Wine, and Mike summarized:
$ find wine -type f|xargs cat |wc -lc
Yes, about 1.6 million lines. This includes the autofoo build magic though, sloccount gives a lower number (a bit less than a million).
I then posted the following:
The website stats are interesting too:
|Daily Avg||Monthly Totals|
Skipping to the KBytes and Hits columns, things are up. Even more interesting is in Feburary we got Slashdotted and in March we didn't. So it appears people are interested.
7. W95inf32 DLL Implementation
2 Apr 2004 (1 post) Archive Link: "W95INF32 implementation, incase it's useful to anybody"
People: Mike McCormack,
Mike McCormack did a bit of work on a DLL and posted it to wine-devel rather than just throwing it away:
In the process of understanding another bug, I did a little work to implement w95inf32, which appears to be a small IE/win9x only DLL and which is probably of not much use to Wine. It appears to be a thin wrapper 32bit around 4 functions in SETUPX.
So this is just for documentation purposes, and in case anybody is curious or finds a real need for this DLL.
You can find that implementation in the archives.
8. Arch Utility: genpatch
7 Apr 2004 (1 post) Archive Link: "arch tip #1"
Topics: Project Management
People: Mike Hearn,
Not sure if anyone out there is using the arch gateway (see issue #217 for more details), but Mike Hearn added a new tool this week:
At Dimis request, I've added a new script to the root of the gateway tree.
The genpatch program takes a series of patch ids as parameters and can generate and send an email to wine-patches with the combined diff of all the given commits.
For example: let's say you are working on a feature. You do 3 commits, to keep the changes physically separate, however you decide the commits are too fine grained to submit all at once, so you want to submit them together.
Genpatch makes that easy. Say you commit patch-4, patch-5 and patch-6:
./genpatch -m 4 5 6
will compute the combined differential of all those commits, take the commit log and summary of the first and generate an email from them. The patch will include and new files that were added.
9. How To Set Up BiDi Support
6 Apr 2004 (1 post) Archive Link: "Compiling Wine with BiDi support - instructions"
People: Shachar Shemesh,
Thanks to Shachar Shemesh, Wine has support for bi-directional text. Shachar has been pretty busy lately, but this week he reappeared with patches and some new info about setting everything up:
Here are the formal instructions for compiling Wine with bidi support. When doing so, it is recommended that you use a fairly recent version of ICU (2.6 and up), or else there is going to be a runtime soft dependancy on some ICU files in the resulting Wine. No big deal - if these files are not there, Wine will work just fine, only without BiDi support. Still, this is not necessary.
A few things to note:
Instead of reposting the program for testing whether Win32 supports reordering, the link to the file in the list's archive is at http://www.winehq.org/hypermail/wine-devel/2003/08/att-0175/01-biditest.c.
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.