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
 

Wine Traffic #140 For 17 Oct 2002

By Brian Vincent

Table Of Contents

Introduction

This is the 140th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 263 posts in 886K.

There were 67 different contributors. 38 posted more than once. 25 posted last week too.

The top posters of the week were:

1. News: Xandros & CodeWeavers

11 Oct 2002 - 17 Oct 2002 (2 posts) Archive Link: "News"

Topics: News

People: CodeweaversLinux Global PartnersCodeWeaverscodeweaversJeremy WhiteXandrosNews

CodeWeavers announced a strategic relationship with Xandros. The product going to Xandros' distribution will combine the functionality of CrossOver Office and the CrossOver Plug-In. In addition it's been integrated with the entire distribution to give a more polished feel than the normal commercial products. CodeWeavers has since pulled the announcement from their web site for whatever reason, but several sites leaked the news after seeing the initial press release. There's a great interview with Jeremy White over at ConsultingTimes where he discusses in more depth the Xandros deal. >From the press release that wasn't really released:

CodeWeavers To Provide Windows-to-Linux Functionality For New Xandros® Desktop Operating System Much-Heralded Linux® OS Will Feature "CrossOver for Xandros" Based on CodeWeavers' CrossOver Software, Allowing Windows® Applications to Run Without Windows OS

There's a little more behind this than meets the eye. Both Xandros and CodeWeavers have a significant share owned by a holding company, Linux Global Partners. Other companies in their portfolio include Ximian, Gobe, Metro Link, and GNU Cash. All of the companies are fully independent, but as Linux Global Partner's web site states, " Our operating strategy is to integrate our partner companies into a collaborative network that leverages our collective knowledge and resources. With the goal of holding our partner company interests for the long-term, we use our collective resources to actively develop the business strategies, operations and management teams of our partner companies. "

Ski season has started. No promises on getting this out on a timely basis in the coming months. Not that there were any before..

2. Listview Update

13 Oct 2002 - 16 Oct 2002 (20 posts) Archive Link: "Second Listview status update"

Topics: Patches

People: Dimitrie PaunRein KlazesNewsCarlos Lozano

Dimi Paun wrote in with an update about the ongoing changes to the listview control:

The listview should now be better than before I started working on it. If there are regressions, I would like to know about them.

During my work, the REPORT mode got a lot faster rendering. The Q-series patches undoes partly those speed enhancements. However, the situation is temporary, and when I'm done with it, we'll have pretty much as fast a rendering as possible.

For this to happen, I need to do a bit more infrastructure work. Namely, we have to keep track of column information, such as rect, alignment, etc. This will no only speed up report rendering, it will allow us to have icons for subitems as well (most of the work for this is actually done, I just need a place to put the on/off flag).

Once this is done, we can start working on actually adding features. And there are a _lot_ of features that we're missing. But this is another story! :) My aim here is to bring the listview to a solid foundation that can take all these new features without turning it into something (1) buggy, (2) unmanageable, and (3) slow.

There is one more infrastructure bit that may need to be done. That is, we may need to keep an ordered array of item positions in LVS_{,SMALL}ICON modes. Currently, we don't have something like this, and as a result we need to iterate over the entire item set in the above mentioned modes. This works for a small number of items, but when we have 10s of thousands, or millions, or what have you of items, it will blow chunks. The good thing is that all the iterator work that I've done lately nicely separates all these details away from the code. So it can wait for now.

So once again, I am interested to hear about regressions. I think the code reached a state where we can concentrate on cleaning up our act, before adding new features.

Several people wrote back with problems, and Dimi began tackling them. A few days later he wrote another update:

Things look pretty good on the listview front. In fact, I am kindda happy the way things are, as the S-series patches were rather tricky at points...

Currently, I know of the following problems:

At this point, I would like to ask everybody that is aware of a listview problem to report it. I might not be able to put as much time, and effort into listview, as I did lately, so the more of a complete picture I have now, the better the chances that I'm gonna fix it.

Next on my TODO:

If you feel that there is a particular are of the listview that needs attention, let me know so I can work it into my TODO, time permitting.

3. Windows Code Migration Guide

15 Oct 2002 (3 posts) Archive Link: "FYI"

Topics: Documentation

People: Eric Pouech

Eric Pouech posted an excellent link to an excellent document on Microsoft's web site. The " UNIX Code Migration Guide" (you may also find it here ) ironically can serve as a wonderful Windows code migration guide. Inside is a wonderful description of Windows' architecture, much of which also applies to Wine. It discusses topics ranging from memory management to window management. If you've ever wanted to hack a Winelib app, dig into Wine internals, or just try to figure out equivalent features between unix and Windows, then you'll want to check it out.

A couple people pointed out subtle (and not to subtle) propaganda interspersed within.

4. Adding -DSTRICT Capability

15 Oct 2002 (4 posts) Archive Link: "Re: PATCH: compile fix (when all handles are void*)"

Topics: Build Process

People: Michael StefaniucFrancois GougetAlexandre JulliardDimitrie Paun

Michael Stefaniuc has been on a qwest converting all sorts of HANDLES to void*. In general, handles refer to resources have been loaded into memory. The Win32 API provides for several different types of handles to access things from windows to registry keys. With his latest patch he noted, "this patch was lying around. It makes wine compile with all handles (even HANDLE) converted to a void*."

Why does this matter, you ask? From Bugzilla bug #90:

In Wine's windef.h the definition for HANDLE is 'int' whereas on Windows it is a 'void*'. This causes many compilation warnings in WineLib applications (each time one puts NULL in a HANDLE for instance) and, I believe, also occasionally causes compilation errors (think function signature).

So we should change this definition but we must keep the same type for Wine and WineLib to avoid problems on architectures where sizeof(int)!=sizeof(void*) (i.e. 64bit architectures, i.e. architectures on which Wine does not run yet).

The problem is that this change will require many modifications to get Wine to compile cleanly. This task is still in the planning stage. The current thinking is to:

So using STRICT gives you the ability to differentiate between HANDLE's when you compile - right now they're all int, so you can accidentally assign one type of handle to another. (This doesn't prevent you from doing an explicit cast though.) Dimitrie Paun wanted to know if the latest patch meant compiling with -DSTRICT was coming soon. Michael went into detail:

Well, it depends what you mean with "soon". Bug #90 was opened 2000-10-31 so 3 - 4 month is pretty soon. There are 9 handles to convert but that number has nothing much to say. A wine (some days old, but in this field no much changes happened) compiled with -DSTRICT and all handles changed to void* gives:

I'm almost finished a short perl script to automaticly convert the "int format, HANDLE arg" warnings, which would leave us with the other 1343 warnings. Wine compiles and even seems to run so if Alexander would like to speed up the conversion he could change the remaining handles to void*, add -DSTRICT and hope that the some people get annoyed with the warnings and submit patches. But i don't recommend it (yet).

Alexandre didn't think prematurely adding it was the proper solution, but instead gave another option for phasing it in, " No, I don't think we want that. But one thing we could do is to compile individual dlls with -DSTRICT, so that we can fix them one at a time; this would avoid having to do a huge patch that changes the format strings all over the tree at the same time. I can do the needed Makefile magic if you'd like to try this approach."

5. Using wineconsole

16 Oct 2002 (3 posts) Archive Link: "wineconsole examples?"

Topics: Fixes

People: Bill HollandVincent BeronEric Pouech

Bill Holland was having trouble running a program and asked for help:

Is there a good example WINE configuration for running a simple console program (using wineconsole)?

For example, the windows tree.com program?

I'm actually trying to run TLIB (version control software from Dave Burton Systems, www.burtonsys.com ) under linux, and am so confused I want to start with a working example first. I'm new to linux, tlib, and wine!

Vincent Beron gave some quick pointers:

I don't know about wineconsole (Eric?), but for CUI DOS/WIN32 programs the ttydrv driver (in place of the x11drv) works.

It lauches in whichever terminal is presently used: console, ssh, xterm. I'm not sure about doing fancy "graphics" with it though. But if TLIB has the same UI as cvs, then it should be good (at least on the UI front).

Eric Pouech explained:

wineconsole tree.com should do the trick

in more details, you can either:

  1. choose to run your program in the (unix) console where you type the command with "wine tree.com"
  2. or dedicate a specific console for your app "wineconsole tree.com"

option 1 is better for integration with unix tools option 2 is better in terms of Wine internal handling, and may be less buggy (depending on what your program does)

6. Threading In Winelib Apps

16 Oct 2002 - 17 Oct 2002 (3 posts) Archive Link: "multithreading winelib app"

Topics: Winelib

People: Malte StarostikFrancois Gouget

Malte Starostik asked, " before I make some major mistakes: can a winelib app safely use pthreads and run WinAPI functions from multiple threads or will it have to use Windows threads?"

Francois Gouget gave the quick answer, " Winelib applications cannot use pthreads. They should not even be linked with the pthread library."

7. Large Screen Buffers for the Debugger

16 Oct 2002 - 17 Oct 2002 (9 posts) Archive Link: "winedbg"

Topics: Debugging

People: Dimitrie PaunEric Pouech

Dimi Paun wondered why the debugger wasn't working for him. The symptoms he reported were:

I had winedbg startup automatically a few times, and I noticed that I get no text in the console. Actually, I do (as I can select it and copy it), but it doesn't get rendered. I tried changing the font, but the only option I get is "Courier New". Tried different size, but nothing helped. Strange thing is that the sample "This is a test" in the font selection tab works just fine.

Eric Pouech asked to see a trace with -debugmsg +wineconsole,+wc_font turned on. The resulting output contained a line:

trace:wineconsole:WINECON_DumpConfig load cell=(10,20) cursor=(25,1) attr=0e font=L"Courier New"/400 hist=100/1 flags=QX msk=00000000 sb=(120,3000) win=(11244,16476)x(120,50) registry=L"W:_wine_programs_winedbg_winedbg.exe"

Eric Pouech immediately recognized the problem and wrote back, " set a much smaller screen-buffer 120,3000 will create a way too big screenbuffer (i mean the bitmap to render it) (as of today, the full sb is stored in a unique bitmap... and here the bmp allocation fails)"

 

 

 

 

 

 

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.