Wine Traffic #194 For 31�Oct�2003

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

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

"Configuration ... is about as simple as humanly possible. There is, however, one minor annoyance for a system designed to be experienced as an applince: All of the management software is designed to run on Windows, and only Windows. ... we were able to run -- albeit not completely-- POPassist on SuSE Linux Desktop with the help of CrossOver Office. The only glitch comes in actually fiding the POPnetserver. That function would not work, which left us manually inputting the new address e discovered with LiSA and My Network Places."

Winesetuptk 0.7 is at the wine sourceforge page

http://sourceforge.net/project/showfiles.php?group_id=6241

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!

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

http://vmlinux.org/jakov/Wine/

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

• http://developer.kde.org/~sewardj/
• http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2

this is based on the latest stable valgrind release.

use a current CVS or the latest snapshot of WINE.

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:

[DllOverrides]
"oleaut32" = "native"
"ole32" = "native"
"rpcrt4" = "native"

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:

"Managed" = "N"
"Desktop" = "640x480"
"Desktop" = "Y"

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:

/* default: not managed */
return FALSE;
}

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.

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.

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.

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.

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

• SDK: http://longhorn.msdn.microsoft.com/
• Articles/Info: http://msdn.microsoft.com/longhorn

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

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

http://www.microsoft.com/msj/0199/com/com0199.aspx

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.