World Wine News

CrossOver for Xandros will combine functionality from CrossOver Office, which lets applications such as Microsoft Office and IBM's Lotus Software division's Notes run; and CrossOver Plugin, which lets Linux Web browsers use Windows Web applications, such as Windows Media Player, QuickTime and Shockwave.

Xandros Desktop users will be able to run or view these applications without having to buy, configure or install additional software on top of the operating system, officials said.

There is one hook: CodeWeavers will not provide support or maintenance upgrades for Xandros customers, who will have to pay separately for a CrossOver support contract.

Redmond, WA -- (press release) -- Continuing its leadership role in providing alternative desktop software, Lycoris partners with TransGaming to bring unprecedented cross-platform gaming into the hands of Desktop/LX users.

With the new Lycoris GamePak, Desktop/LX users gain simple installation of improved and enhanced Open Source games, plus the ability to play top Windows games, all in one box. Access to TransGaming's WineX software, which allows DirectX games to run on other platforms, will be included with the Lycoris GamePak, on retail store shelves this Holiday season.

Lycoris and TransGaming have reached an agreement that will also enable GamePak subscribers to get discounts on major Linux gaming titles such as TimeGate Studios' award winning game series Kohan, and promises to add value for users who move over to the Desktop/LX platform during the holidays.

Lycoris sees this as an important step to offering a viable alternative to Windows and giving gamers the excitement and action they expect.

Above what Ove already implemented, I really haven't done all that much. Frankly, in its current state, it is quite possible that the RPC work I am doing will /detract/ from the stability of wine, until the implementation is more complete. RPC is painfully complicated, and a victim of serious creeping featurism. Microsoft makes it worse by providing poorly documented extensions to the protocol, and a largely undocumented marshalling API (much of which developers typically don't have to learn because the API calls are generated by the MIDL compiler).

My target right now is to get a "hello world" API invocation to work across processes using wine RPC. Once that is achieved, I plan to create a unit test for this. Then, we'll have a framework that we can begin to extend and implement "properly." I am not there yet, but I think I'm getting close. I just have to implement marshalling for strings, which, in theory, looks pretty easy. There are probably many bugs that need squashing before it works, and maybe some additional gaps in functionality that I don't even realize exist yet... but I do think I'm pretty near.

Now, what remains to be done? Well, as Ove mentions in the TODO for his units, "a whole lot." Here are several things in no particular order:

• widl is like MIDL for wine. For wine to be a useful RPC platform, quite a bit of work needs to be done here. widl currently doesn't generate stubs for RPC invocation -- it will need to; this is tricky because the MIDL compiler does some really weird stuff. Then again, we don't necessarily have to make widl work like MIDL, so it could be worse.
• RPC has a quite featureful error handling mechanism; none of it is implemented right now.
• The server portions of the patch don't seem to be getting accepted by Alexandre. My guess is that once I have a working test he'll conceed to let this in. To implement this properly is tricky and possibly beyond my abilities; Ove seems to think the right way to do this is to use LPC (Local Procedure Call, another undocumented monster). LPC has no implementation in wine and is not going to be trivial to create.
• there are several different memory allocation schemes for MSRPC. I don't even understand what they all are yet, much less have them properly implemented.
• MSRPC provides impersonation capabilities which currently are not possible to implement in wine.
• Some transports are not yet implemented. The existing transport implementations are incomplete. (By transports I mean, tcp/ip, named-pipes, local procedure call, etc --- the various types of low-level plumbing that can be used to connect the client and the server).
• Data marshalling is the means by which RPC represents data across process and machine boundaries. MSRPC extends NDR format for this. The wire protocol is mostly documented, but the MS API's to convert data-types in memory into NDR are not. This, alone, is a sizable chunk of work.
• ORPC is RPC for OLE; once we have a working RPC framework, we can use it to implement out-of-process OLE client/server communications. This will be a huge win for wine. But again, it's a lot of work, and I'm no OLE expert (hell, I'm no RPC expert :)
• Surely there is much more stuff I am forgetting. Like Ove said, it's "a whole lot" of stuff, approximately as big a project as, say, DirectX.

Basically, RPC for wine is a huge beast of a project. IMO it is probably the biggest and most difficult-to-fill hole in wine's feature-completeness ATM. In the short term, don't expect any miracles --- I really doubt that I'm going to "solve" this (in my spare time!) anytime soon. But, once I start getting some results, I imagine others will be enticed to help out, as contributors like Ove already have. (To be clear: Ove enticed me, not the other way around: He did all the "real" work, and deserves way more credit than me for any success I may achieve in the near future).

I'm holding back on submitting an "official" patch to give Alexandre the chance to catch up so I can start a new "F" series and not stay forever conceptually forked from CVS wine. But I thought he or somebody else might like to see what's I'm up to so here goes (I'm also having some HD troubles so, in case I have a meltdown, this will prevent me from losing my work!)

I'm enclosing a diff relative to E_PL15 and also a bigger one of uncomitted changes relative to CVS wine (the E_PLxx series are inclusive of this latter diff, so there is nothing new there). I've indexed it as F_PL1 because presumably F_PL0 will be yet another copy of the unmerged server parts.

the E_PL15_unmerged patch does not include the F_PL1_pre0 patch, so if you take CVS wine, apply E_PL15_unmerged.diff, and then apply F_PL1_pre0.diff on top of that, you have my tree. As usual, this is not a hint to apply.

CHANGELOG (for rpc_F_PL1_pre0 only):
dlls/rpcrt4: ndr_marshall.c, ndr_midl.c, ndr_misc.h; include: rpcndr.h, wine/rpcfc.h:
Greg Turner

• make explicit some hidden include dependencies
• Implement NdrGetBuffer, NdrFreeBuffer, and NdrConformantStringBufferSize
• define the RPC_FC_C_CSTRING constant
• perhaps I don't want those MIDL structs after all. removed.

With my latest W-series patches, the listview should now be a pleasure to work with: fast, *no* flicker, etc. It should be a lot better than before I started working on it. If this is not the case (there are regressions, there is nasty flicker *anywhere*, it's slow, or in general it's not a pleasure to interact with it, i.e. you don't get a warm and fuzzy feeling) let me know now.

Internally, the code is a lot cleaner. I have started on Sep. 9, 2002, at revision 1.138. A month and a half, and almost 150 revisions later, most of the code has changed multiple times. Large number of visible, and mostly invisible bugs have been fixed, a lot of corner cases covered, features implemented, listview has been made scalable, flicker has been eliminated by redrawing the absolute minimum, etc. We are now on solid ground to implement more stuff.

This has been an extenuating exercise. I am tired, and on top of it all, real life has knocked on my door. This does not mean I'll stop working on it, but it probably means that I will not be able to put as much time into it.

For the above mentioned reasons, I think it's best for everybody if we stabilize the code as much as possible, before we start working on the large number of missing features. For this I need your help -- the few apps that I test with work just fine now.

I would like to thank everybody that helped me with testing, patches, or reporting bugs. I couldn't have done the half of it without that support.

This sounds like this is a done deal. It's not. There's a lot of stuff that remains to be done, but I needed some closure. :)

After my latest X-series patches (currently at X6), I am aware of the following listview bugs:

Yes, you read correctly: NONE. :)

So I ask you for one of two things: bug reports or success stories

Otherwise, I'm gonna declare listview the coolest, nicest, most huggable piece of code out there <g>.

This code was audited for completeness against the documented features of Comctl32.dll version 6.0 on Oct. 21, 2002, by Christian Neumair. Unless otherwise noted, we believe this code to be complete, as per the specification mentioned above. If you discover missing features, or bugs, please note them below.

TODO

• implement GetMUILanguage + InitMUILanguage
• LibMain => DLLMain ("DLLMain takes over the functionality of both the LibMain and the WEP function.", MSDN)
• finish NOTES for MenuHelp, GetEffectiveClientRect and GetStatusTextW
• FIXMEs + BUGS (search for them)

Control Classes

• ICC_ANIMATE_CLASS
• ICC_BAR_CLASSES
• ICC_COOL_CLASSES
• ICC_DATE_CLASSES
• ICC_HOTKEY_CLASS
• ICC_INTERNET_CLASSES
• ICC_LINK_CLASS (not yet implemented)
• ICC_LISTVIEW_CLASSES
• ICC_NATIVEFNTCTL_CLASS
• ICC_PAGESCROLLER_CLASS
• ICC_PROGRESS_CLASS
• ICC_STANDARD_CLASSES (not yet implemented)
• ICC_TAB_CLASSES
• ICC_TREEVIEW_CLASSES
• ICC_UPDOWN_CLASS
• ICC_USEREX_CLASSES
• ICC_WIN95_CLASSES

as I'm currently in my studies duties again and the AppDB submissions are piling up enormously (> 20 new entries in less than two weeks), I'm looking for one or two additional AppDB maintainers to do the Beowulf thingy ;-) (I'm talking about http://appdb.winehq.org , here)

The job description can be found at http://www.winehq.org/about/index.php?contrib#active Sadly enough, this description page has been online for several months now, with (almost ?) nobody applying for any jobs listed.

PR manager

Currently we almost have no Public Relationship management at all. This should change for the better.

Currently almost the only form of PR is "preaching to the choir", since we're having articles on online IT sites (by far most are Linux only !). We should have much more coverage on traditional Windowsish sites and, most importantly, in dead-tree newspapers, to enlighten the general public also known as The Great Unwashed Masses !

Wine users, CodeWeavers, & WineX customers could do Previews/Demo's at their local lug meetings as well.. This is what I did a couple months back and it was a huge success there were Windows users at the meeting to see Linux and Win app's being run on Linux ... Also it gives Linux users a look at wine as well. So I suggest that we try to encourage wine users to volinteer to show Wine at their local user groups/Installfest/Computer shows and so on.

This is not a PR manager but it is PR......

I have now completed using the eTax program from the Australian Taxation Office ( http://www.ato.gov.au/ ) under wine, and have some concluding remarks.

• Yellow Note Popups over buttons: these notes pop up almost immediately you put your mouse over a button, and if you click on them, the button does not respond. This causes great user frustration, as you point the mouse at a button, click the mouse, and nothing happens because the popup note appeared and stole the mouse click. Perhaps this could be solved by moving the popup note position so that it's not directly under the mouse pointer? I don't know if this is an etax problem or a wine problem. Workaround: move mouse over button and click again, or be very quick with your mouse click the first time.
• ListView (tree): when hovering over items with long names, the same popup note appears, and also greedily steals mouse clicks, preventing you from selecting the item underneath. The note must pass the mouse click through for proper handling by the list item. Workaround: Wait for popup to disappear and then click on list item.
• I had some refresh issues with the print preview section of the program. When it draws a page for the first time, all form fields appear to be filled in correctly, but when scrolling the form fields are often left blank when they should be filled in. This may be verified by going forward and then back a page, to force a complete re-draw of the original page, and verifying that fields which were previously blank are now drawn properly.
• I didn't try to submit the tax return under wine, as I did not know about the wine integration of the web browser which would be used to perform the submission. (I failed to download the security codes under Mozilla, so I resorted to a Windows box for downloanding security codes and submission.)
• Help problems, partly to do with launching winhelp from within etax, and also partly because WINE help can't yet read the etax help file properly.

I used etax in the desktop windowing mode, as I had problems with both the managed and unmanaged modes. I set all dlls to builtin (except for "*").

This is the first year that I have been able to use eTax to do the tax return. I want to thank all of the wine contributors for making it possible! Last year I gave up and used a Windows box for the whole thing.

I know I must be missing something very simple, but I cannot seem to get native regedit to run. The builtin version always runs instead. The only thing I could think of was an entry in DllOverrides:

"regedit.exe" = "native, builtin".

That did not work.

Found something: it works if I fully qualify the command name.

I was trying this in the DllOverrides / command-line respectively:

"regedit.exe" = "native, builtin"
--dll regedit.exe=n,b

What I have to do for it to work is this:

"C:\\Windows\\regedit.exe" = "native, builtin"
--dll C:\\Windows\\regedit.exe=n,b

; you can specify applications too
; this one will apply for all notepad.exe
;"*notepad.exe" = "native, builtin"
; this one will apply only for a particular file
;"C:\\windows\\regedit.exe" = "native, builtin"