Wine Traffic #194 For 31�Oct�2003

By Brian Vincent

Table Of Contents

Introduction

This is the 194th issue of the Wine Weekly News publication. Its main goal is to slip on scree. 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.com (http://www.winehq.com)

Mailing List Stats For This Week

We looked at 161 posts in 519K.

There were 62 different contributors. 34 posted more than once. 36 posted last week too.

The top posters of the week were:

1. News: CrossOver Office 2.1

25�Oct�2003�-�31�Oct�2003 (1 post) Archive Link: "News"

Topics: News

People: Codeweavers,�Dan Kegel,�CodeWeavers,�,�News,�TransGaming

CodeWeavers rolled out an updated CrossOver Office this week adding support for Macromedia products:

"Now, with additional support for Macromedia Dreamweaver MX and Flash MX, combined with our existing support for Adobe Photoshop, CrossOver Office 2.1 gives web developers and design firms the first Linux solution for their most important design applications."

I missed reporting a TransGaming deal offered to subscribers. Last week they had discounts on their products. Of course, if you're subscribed I'm sure you received an email. Also in the news is the appointment (http://www.transgaming.com/news.php?newsid=89) of Leonard Brody to the TransGaming Board of Directors.

Also this week, Dan Kegel pointed out that HP World magazine (available with registration (http://www.interex.org/myjsppages/subupp.jsp) ) has references for using CrossOver Office to run Windows programs:

On page 20 of the Nov 2003 issue, for instance, titled "POPping Up Terrabytes", they reviewed FIA's POPnetserver NAS 4600 model 720, and said in part

2. Winesetuptk 0.7 Released

28�Oct�2003 (1 post) Archive Link: "Winesetuptk 0.7 released"

Topics: Configuration

People: Ivan Leo Murray-Smith,�Alex Pasadyn,�

Ivan Leo Murray-Smith announced:

Winesetuptk 0.7 is at the wine sourceforge page

This new version contains an updated winedefault.reg, you don't need to run regedit winedefault.reg any more, and it's updated to configurate all the latest and greatest features of wine.

This release was possible thanks to the help and contributions of Vincent B�ron and Alex Pasadyn. Without them, winesetuptk 0.7 wouldn't exist. Download and enjoy!

3. Updated Winetests

27�Oct�2003 (1 post) Archive Link: "New winetests.exe"

Topics: Testing

People: Jakob Eriksson,�

Wanna run some conformance tests on Windows? Jakob Eriksson updated his testing program:

Since winetests has not yet made it to CVS and I found some spare time, I have now compiled a new winetests.exe.

Tests built with MSVC 7 from CVS 20031027.

(Testing shell cross built with mingw32.)

All you have to do is download winetests.exe and just run it. All of the collected results get displayed in a browser window with the option of submitting them to the wine-tests-results mailing list.

4. New Valgrind For Wine

29�Oct�2003 (2 posts) Archive Link: "New tarball of valgrind for WINE available"

Topics: Debugging

People: Adam Gundy,�

Valgrind has helped developers find lots of problems with Wine over the past few months. Adam Gundy announced this week:

A new tarball of valgrind modified to work with WINE is available from the valgrind home page:

this is based on the latest stable valgrind release.

use a current CVS or the latest snapshot of WINE.

5. Installshield 7 Notes

29�Oct�2003 (2 posts) Archive Link: "Installshield7 notes"

Topics: Fixes

People: Carlos Lozano,�,�Greg Turner

Carlos Lozano shared some info concerning apps using Installshield 7:

Here goes some notes about how to install installshield 7 programs with the actual wine releases (sorry, i haven't been able to install without some natives DLLs).

You need 3 native DLLs (ole32.dll, oleaut32.dll and rpcrt4.dll), and 2 .tlb files (stdole32.tlb and stdole2.tlb). Copy this 5 files to your windows/system directory, and edit your ~/.wine/config, using:

Even using this natives dlls, you will have problems with the windows order, what you will not leave you see the windows and install the program. The easier way to install it, should be enable the Desktop mode, in ~/.wine/config:

I have found some programs, what give problems with Desktop mode, exiting during install with X11 errors (Praetoriams demo for example). In this cases you can use yet another trick. Disable Desktop, and enable "Managed" = "Y", then in the file the file "dlls/x11drv/window.c", you will find the function "inline static BOOL is_window_managed( WND *win )", in the end of this function, there are this 3 lines:

replace, "return FALSE;" to "return TRUE;", and run make install again. Remember after of install the program change again this line to "FALSE", because you could have problems later with other windows.

Greg Turner offered to look at the problems with Wine's builtin DLL's if someone could give a pointer to a free installer he could test with.

6. Keyboard Detection

27�Oct�2003�-�29�Oct�2003 (12 posts) Archive Link: "Re: French keyboard layout with Euro symbol"

Topics: Internationalization

People: Dmitry Timoshkov,�Shachar Shemesh,�,�Sylvain Petreolle

Sylvain Petreolle mentioned that although his keyboard works fine in Wine there seems to be problems detecting it. Dmitry Timoshkov explained someone of the issues:

I think that this topic was explained many times already. Anyway, here is yet another attempt.

  1. Keyboard detection code was introduced in order to make some picky DOS games (expecting key presses to have fixed scan codes) work with different X keyboard layouts. Since win32 apps do not depend on it that's not a problem at all for them.
  2. Another problem was that each keyboard layout in x11drv had its own code page for X event to unicode translations. That's now solved as well by introducing CP_UNIXCP support. Once the underlying system has a correctly configured locale, keyboard input in Wine (as well as a general locale support) should work just fine.
  3. Another (existing) problem is that each keyboard layout still has a virtual keyboard map attached to it. It's unavoidable and needed for correct support for QWERTY/AZERTY/etc. keyboard layouts, when some applications really depend on it.
  4. And the last problem I'm aware of is that we need to revamp the keyboard detection code to fill the real keyboard map first, and only then create keyc2vkey array depending on the real mapping, not a hardcoded one. That's a minor problem, which I discovered recently while debugging one of my supported apps.

Shachar Shemesh pointed out a related problem, " In the future, windows keyboard language APIs will need to be handled. For those to work, we must be aware of which is the current keyboard." He went on to explain:

The reason I listed it here is because in order for Wine to know what language the current keyboard is, it will also need to know what's the current keyboard.

I have thought of two ways for Wine to do that - either it checks what name the symbol files is loaded as, or it scans the keymap (as it does today). Either way - it will have to have some mapping between currently loaded keymap and language. Hence the affect it has over X keyboard detection.

Dmitry wondered how that info could be queried from X. Shachar tossed out some ideas:

I was thinking of one of two options. Unfortunately, both require us to know each keyboard layout we support (though, not necessarily know exactly).

  1. Use the current scheme. LCID is all we really need, IIRC.
  2. Use the XKB name

2 will mean that we reduce the keyboard source to a table of names, and their respective language IDs. I.e - "us" means English, "fr" means French, "he" means Hebrew etc. This will probably make adding new keyboard easier (and less error prone), but will ONLY work on XKB. Then again, keyboard selection (also part of the currently missing APIs) will only work on XKB anyways, so wer'e probably going to have to soft-depend on XKB whatever we do.

7. Longhorn Info

28�Oct�2003 (1 post) Archive Link: "Longhorn info"

Topics: Microsoft Windows

People: Mike Hearn,�,�Microsoft

Microsoft began unveiling parts of their next generation operating system (codenamed Longhorn) this week. Mike Hearn provided some links to some of the MSDN info that appeared:

Of course, as we don't actually implement the "new" XP APIs yet, this is all rather academic. Still, why not take a look at what we'll be reimplementing in 2010 ;)

8. Stubless Proxies

29�Oct�2003 (3 posts) Archive Link: "Misc wine debugging questions"

Topics: RPC / COM / OLE

People: Mike Hearn,�Greg Turner,�,�Microsoft

If I try to think about this too much I'll get a headache. However, given Greg's nice explanation it's probably worth saving this for reference. Mike Hearn asked, " Greg recently mentioned "stubless proxies". Does anybody know where I can read about these?"

Greg answered:

Unfortunately, there isn't a ton of documentation -- or, more accurately, the documentation that you may find is scattered throughout MSDN and the internet, instead of being in an "obvious" place. The MSDN documentation for NdrClientCall2, for example, is almost worthless from the wine implementer's perspective, just stating something like "This is the entry-point for stubless proxies." From the perspective of most users, stubless proxies are a behind-the-scenes implementation detail that isn't worth learning too much about.

The end-programmer's perspective is as follows: pass /Oicf to MIDL, and MIDL will magically generate stubless proxies. I forget if /Oic is considered "stubless" as well, I think it may be. The resulting client proxy code generated by MIDL will contain "NdrClientCall2" or "NdrClientCall" instead of the usual multi-step proxy code (there is no in-proxy marshalling, exception-handling, etc -- just the single call).

In wine, NdrClientCall2 (the more common entry-point) is totally unimplemented -- it simply emits a FIXME and returns indicating success.

The server side is analogous. You will see some code by Ove floating around to generate the manager entry-point thunks in asm, but I don't think they are used yet (?).

Unfortunately, stubless proxies have been the recommended (by Microsoft) mode of generating code from MIDL for many years. Increasingly, I see calls to NdrClientCall2. The only solution (aside from coding wine) is to use native rpcrt4/ole32 -- but this, in turn, means you must use Windows 98 dll's or else you will bump up against the missing "Ports" API if ncalrpc is used (it usually is -- this is why I keep musing that I want to take a crack at implementing this).

I think, the way to code those is to use the structures provided by MIDL (and eventually widl) to determine the necessary steps. In particular, I think this is where the format strings come in handy -- presumably, NdrClientCall2 should parse the format strings and determine what to marshall/unmarshall using those. My theory is that the steps taken in NdrClientCall2 would look very much like those MIDL would spit out in /Oi mode.

Stated succinctly, stubless proxies are the RPC/DCOM holy grail for wine.

Unfortunately, it doesn't make much sense to start working /Oic[f] until /Oi mode is working a lot better. Things like the OXID Resolver, IObjectExporter, RpcObjectSetType, etc, really ought to be in place before we start complicating matters by implementing subless proxies... of course, if someone wants to prove me wrong, be my guest ;)

Mike also found some info:

Your theory is correct. Somehow I stumbled upon this article:

which explains the whole thing. It also talks about how the MS typelib marshaller is implemented - basically it generates format strings from the typelib data then feeds that to the Ndr format string interpreters.

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.