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

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.

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:

• Newsbin dies swiftly (reported my Rein Klazes)
• FTPCommander seems to experience some listview-related faults (reported by Carlos Lozano)
• Xnews has some minor focus rectangle problems (discovered by myself :))
• IDAdemo _may_ have some minor drawing glitches (ditto)

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:

• Fix Newsbin's crash (BTW, Rein I need a new trace with the latest CVS, if possible)
• Store per-column info into the listview (see the second status update for details)

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.

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:

• change Wine to compile with STRICT turned on while we're at it. This makes handles incompatible with each other resulting in better type safety.
• make the change one type at a time
• maybe define a new macro for use during the transition. The new macro, DECLARE_NEW_HANDLE, would generate a handle type as if STRICT was turned on while the other one would be unchanged. At the end we would change it back to DECLARE_HANDLE and put STRICT in Wine's makefile.

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:

• 3388 lines of warnings
• 2045 of them are of type "int format, HANDLE arg", this leaves
• 1343 lines of warnings to look at.

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).

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!

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).

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)

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.

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"