All the news that fits, we print.
This is the 186th release of the weekly Wine Weekly News publication. Its main goal is to run amok. 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, 182 posts consumed 542 K. There were 51 different contributors. 26 (50%) posted more than once. 28 (54%) posted last week too. The top 5 posters of the week were:
|
News: Slashdotted | 08/30/2003 | Archive |
---|---|---|
News
We got Slashdotted for news we reported last week. Nothing else to see here folks.. move along, move along. |
Wineproc: A New Utility | 09/03/2003 | Archive |
---|---|---|
Utilities
Eric Pouech created a new utility and announced it on wine-patches with the code: this tool allows to do a few basic operations on a Wine session:
it comes in two flavors:
help is required to:
downside: the get_symbol function in system.c is really ugly. I wouldn't be surprised if Alexandre doesn't like it (I don't like it myself). A cleaner solution would be to implement dbghelp.dll for this kind of behavior (easier said than done). any comment welcomed!! (thanks to Dimi for his quick fixes on the listview control BTW) Cool stuff! It will be interesting to see how this progresses. |
Winecfg Revisited | 08/28/2003 | Archive |
---|---|---|
Configuration
After stagnating for many months, work on winecfg has started again. Winecfg aims to be the graphical interface for configuring Wine. Eventually all of Wine's configuration will be moved into the registry and programs like winecfg and regedit can be used to tweak the setup. This system will supplant the current config file method. All in all, the project needs a lot of help and volunteers are welcome. Last week we mentioned Mike Hearn had gotten a hold of a bunch of winecfg work from Mark Westcott and needed to start merging it. That process began this week. After a few patches Mike described the process he envisioned for going live with it: I should probably detail The Plan here. It's simple:
Does that sound OK Alexandre, or did you have different ideas? Dimi had an issue with point #2: I really don't understand why we need the dual-purpose stuff. All we need to do is:
Mike thought that view was a little simplistic and pointed out some areas that needed consideration: A quick glance at my local winecfg and my local config file (which probably doesn't have every setting possible in it) shows we're missing:
Coding for Win32 takes ages (too bad we can't use something sane like gtk and be done with it *sigh), so I might not be able to get them all functional in the time I have. Another problem we might have is that this is going to be a pretty cluttered and confusing UI if we cram everything possible into it. Do we really have to scrap the config file completely? Dimi remarked, Man, oh man, quite a bit of stuff. maybe we can get rid of some of them. :) Or maybe we don't need UI stuff for all of them. Even on Windows users have to use regedit from time to time, let's not try to be more catholic than the Pope. Alexandre, what's your minimal set of things for winecfg before we can do the switch? Alexandre felt some prudence should be taken when switching over: Well, we need everything that normal users will want to use. But I don't think the priority should be on switching to winecfg as soon as possible; on the contrary we should take the time to review the config, and use that opportunity to clean things up before we make the switch. So for instance if some parameters are too obscure to justify implementing them in winecfg, we should ask whether we really need them in the config at all, or whether we could handle them somehow automatically. Also we need to fix the code that uses config parameters to try to take into account dynamic changes as much as possible, so that you can make a change from winecfg and see it take effect at once, without having to restart your Wine session. Dimi described a process to facilitate this that could be done in parallel with other work: All of which are good things to do, but I'm afraid we're bundling things together unnecessarily. And this is no good -- we already have velocity problems :) Removing obsolete parameters is helpful with winecfg, because it can save a lot of work in building the GUI. But to separate the tasks a bit more, I'd say we need a list of the parameters that we want to be able to control through winecfg. The rest will become part of a janitorial cleanup task. Dealing with dynamic changes in the configuration is orthogonal to the winecfg work. For some performance critical areas is not necessarily feasible, but I suspect most of them can be made dynamic. I can keep this as a separate janitorial task -- I can maintain a list of options with their current status, and whether or not we need to change it from static -> dynamic, etc. Keeping these 3 tasks separate does not mean they will be lost and forgotten -- I volunteer to keep track of them independently. In fact, we'll get more work done this way, because different people enjoy working on different bits. Defining exactly what we want winecfg to do will help Mike get the job done faster. Defining explicitly and granularly the parameter cleanup tasks will allow others (not interested in winecfg work) pick up pieces and run with them. This is good -- a big problem with contributing to Wine is simply that people don't know what needs to be done. Defining such tasks is a good step forward. I am sure there are a lot of people interested in a 0.9 release that are willing to help to reach that goal faster, if only they could pick up small, well-defined tasks. Alexandre cautioned against using winecfg too soon and described two other tasks that needed to be completed first: Sure, they are separate tasks, it's more an issue of in which order we do things. If we are going to change things in the config tree, then it's a lot easier to do before winecfg is used, otherwise we need to add a lot of backwards compatibility code in there; so I think throwing the switch for winecfg should be one of the last things we do, once the rest is at least well under way. That doesn't prevent working on winecfg, we can do at least 95% of it without having to make it edit the primary config tree. Also once the config is in the registry it becomes inconvenient to modify by hand, so it implies we first need write support in regedit, and a working default configuration so that regedit/winecfg can actually start without requiring config changes. From there discussion delved into several different areas. Francois Gouget was concerned that switching to a registry-only format made it difficult to describe what each setting did. Currently comments in the config file serve that purpose. Other folks brought up ideas for which settings to just drop from the configuration. Finally, specifics of winecfg behavior, such as applying only a subset of changes, were discussed. |
Collecting Test Statistics | 08/29/2003 | Archive |
---|---|---|
Testing
Wine's test suite has steadily grown over the past year and now it's time to start putting it to use. One person running tests once in a while is no match for collecting statistics from multiple sites and configurations. This topic spanned a few different threads and was alluded to last week. A few different folks have stepped up to the plate. First, Ferenc Wagner announced: Hereby I ask people who have access to real Windows machines to help me gather information about the behaviour of cross- compiled conformance tests on the different platforms. Please go to http://afavant.elte.hu/~wferi/wine for details. If you can build the tests in the Wine tree by MSVC, then packaging the compiled binaries would also mean a valuable addition. You will also find a packaging script on the page. Ferenc's site details the test results from various Windows versions. The tests also show problems with the existing test programs and things that need to be fixed. (Do we have some volunteers? Bueller? Bueller?) That post was followed the next day by Jakob Eriksson announcing a package of tests . In addition to running the tests it packages up the results to mail back to WineHQ. The two efforts are very complementary but overlap slightly on the reporting format. Ferenc preferred his format simply because he already had a parser to examine the results. Jakob then asked, So, is there a mailing list I can direct the test results to? Jeremy Newman promptly responded: http://www.winehq.org/mailman/listinfo/wine-tests-results wine-tests-results at winehq.org I'll update the Forums page on the site about this in a little bit. I have to do my "paid" work first. ;) Jakob then began mail bombing the list as he tested his utility. |
NetBSD mmap Improvements | 08/26/2003 | Archive |
---|---|---|
Ports
Memory Management
Todd Vierling submitted a patch for improving mmap behavior on NetBSD: On NetBSD (upcoming 1.6.2, and 1.7/2.0-current), there is a new extension flag MAP_TRYFIXED that essentially simulates current Linux mmap behavior: try the mmap() hint first, without clobbering mapped pages, even if the hint falls within traditionally "protected" malloc heap space. If the fixed mapping fails, the block is still mapped at a relocated address, as if mmap were called with no flags set. With this patch, mmapping PE files on NetBSD becomes an order of magnitude faster, as the vfork()-and-mincore() silly walk is avoided altogether. I've implemented the patch as forward-looking, allowing other platforms to add MAP_TRYFIXED to gain the same benefit. (This mmap flag name does not appear to be used in any divergent fashion on any other platform, per my research when picking the flag's name.) Alexandre suggested a change, If you want to keep compatibility with older kernels, you'll need to check if MAP_TRYFIXED is available at runtime, you can't test for that at compile time. Or if you don't need to maintain compatibility then you should get rid of the NetBSD ifdefs completely. Todd didn't that that was necessary for NetBSD: NetBSD isn't like Linux. In NetBSD, the kernel, includes, and libc are not bidirectionally interchangeable; they are unidirectionally upgraded. A binary compiled with newer libc and kernel is documented not to work on older kernels and libc. This is a little less true for release branches, but features do still appear between minor releases, with this same caveat. In general, this holds true with other applications on NetBSD. If a feature appears in the C headers, it is assumed to exist. The patch is in line with NetBSD's compatibility principles. Adding runtime detection code is IMHO just introducing an unnecessary OS dependency garbage code block, and I'd rather avoid that pollution. For now, I'd like to keep try_mmap_fixed() around for with systems that have not upgraded to kernels capable of MAP_TRYFIXED. The try_mmap_fixed() method works fine on newer NetBSD systems, so binaries compiled with older headers still work even if the kernel supports MAP_TRYFIXED. (They'll just be slower. 8-) Alexandre felt it was limitation, Of course this implies that everybody builds all their apps from source. But if that's what NetBSD people expect then it's OK with me. and then added in another post, if you want to ship a binary that works for everybody, with your method you have to stick to the lowest common denominator. With run-time checks you can have a binary that takes advantage of new kernel features, while still running everywhere. Obviously it's a bit more complex to implement, so you only want to do that where there's a real gain in using the new features; still I think the concept applies for all platforms. Everyone seemed to agree that for this specific instance, both because the platform was NetBSD and that creating a run-time check would be difficult, not having a run-time check would be acceptable. Todd didn't feel it would be very limiting, This is not a problem, as 99% of Wine users on NetBSD are building from source. The very small remainder of prebuilt-binary users can easily be told to ensure that the OS version is up-to-date (since there are security fixes that necessitate this anyway). Alexandre did end up committing the patch. From there the focus delved into the maintainability of run-time checks and the sanity of checking run-time features with #ifdef at compile time. Gradually everything degenerated into mini-flamewar which is quite ironic considering this seems to be a corner-case for usage. vi rules. |
Exception Handling | 08/27/2003 | Archive |
---|---|---|
Someone wrote in and described a problem with structured exception handling: Using MSVC i can write
__try {
using Winelib i can write
__TRY {
what can i use how EXCEPTION_EXECUTE_HANDLER ? Alexandre gave some pointers: In general you need to create a function that returns a filter value (EXCEPTION_EXECUTE_HANDLER or EXCEPTION_CONTINUE_SEARCH), and pass that function name in __EXCEPT(). There are many examples of that in the Wine source. As a simplification, if you want to execute the handler in all cases (i.e. your filter function always returns EXCEPTION_EXECUTE_HANDLER) then you can use NULL instead of a function name. Greg Turner mentioned a caveat, There are limitations. You must exit the try block using "normal" flow control. That is, using return, goto, break, or continue to leave a __TRY block will cause disaster. Otherwise they work OK. |
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.