wn20031031_194.xml -Brian
<?xml version="1.0" ?> <kc> <title>Wine Traffic</title> <author contact="http://www.theshell.com/~vinn";>Brian Vincent</author> <issue num="194" date="10/31/2003" /> <intro> <p>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 <a href="http://www.winehq.com";>www.winehq.com</a></p> </intro> <stats posts="161" size="519" contrib="62" multiples="34" lastweek="36"> <person posts="12" size="33" who="Mike Hearn" /> <person posts="11" size="34" who="Sylvain Petreolle" /> <person posts="11" size="26" who="Alexandre Julliard" /> <person posts="9" size="23" who="Vincent Béron" /> <person posts="7" size="15" who="Dimitrie O. Paun" /> <person posts="6" size="20" who="Shachar Shemesh" /> <person posts="6" size="14" who="Marcus Meissner" /> <person posts="5" size="11" who="Rein Klazes" /> <person posts="4" size="19" who="Boaz Harrosh" /> <person posts="4" size="15" who="Ralf Juengling" /> <person posts="4" size="9" who="flyker" /> <person posts="3" size="15" who="Steven Edwards" /> <person posts="3" size="12" who="Rob" /> <person posts="3" size="8" who="Uwe Bonnes" /> <person posts="3" size="7" who="Jerry Jenkins" /> <person posts="3" size="7" who="Jakob Eriksson" /> <person posts="3" size="7" who="Dimitrie O. Paun" /> <person posts="3" size="7" who="Mike McCormack" /> <person posts="3" size="5" who="Jason Edmeades" /> <person posts="2" size="15" who="Subhobroto Sinha" /> <person posts="2" size="9" who="Ferenc Wagner" /> <person posts="2" size="9" who="Valentijn Sessink" /> <person posts="2" size="7" who="Gregory M. Turner" /> <person posts="2" size="6" who="Paul Millar" /> <person posts="2" size="6" who="Carlos Lozano" /> <person posts="2" size="6" who="Sami Aario" /> <person posts="2" size="5" who="Martin Troester" /> <person posts="2" size="5" who="Dan Kegel" /> <person posts="2" size="5" who="Bill Medland" /> <person posts="2" size="4" who="Martin Fuchs" /> <person posts="2" size="4" who="Hannu Valtonen" /> <person posts="2" size="3" who="Ivan Leo Murray-Smith" /> <person posts="2" size="3" who="David D. Hagood" /> <person posts="1" size="24" who="Vitaliy Margolen" /> <person posts="2" size="24" who="Raphael Junqueira" /> <person posts="1" size="14" who="Robert Reif" /> <person posts="1" size="3" who="Jeremy White" /> <person posts="1" size="3" who="Jan Sporbeck" /> <person posts="1" size="3" who="Huw D M Davies" /> <person posts="1" size="2" who="Robert Shearman" /> <person posts="1" size="2" who="Cogman" /> <person posts="1" size="2" who="Michael Günnewig" /> <person posts="1" size="2" who="Jerry Jenkins" /> <person posts="1" size="2" who="Marcelo Duarte" /> <person posts="1" size="2" who="Rolf Kalbermatter" /> <person posts="1" size="2" who="Adam Gundy" /> <person posts="1" size="2" who="Robert Shearman" /> <person posts="1" size="2" who="Orlando Feitosa" /> <person posts="1" size="2" who="James Lyon" /> <person posts="1" size="2" who="Ralf Juengling" /> <person posts="1" size="2" who="Rolf Kalbermatter" /> <person posts="1" size="2" who="Pavel S. Khmelinsky" /> <person posts="1" size="2" who="Bryan Gruneberg" /> <person posts="1" size="2" who="Andreas Mohr" /> <person posts="1" size="2" who="Gerald Pfeifer" /> <person posts="1" size="2" who="Hans Leidekker" /> <person posts="1" size="1" who="(RemiAssailly)" /> <person posts="1" size="1" who="Robert van Herk" /> <person posts="1" size="1" who="Jonathan Wilson" /> </stats> <section title="News: CrossOver Office 2.1" subject="News" archive="http://www.codeweavers.com/site/about/general/press/?id=20031027"; posts="1" startdate="10/25/2003" enddate="10/31/2003" > <topic>News</topic> <p>CodeWeavers rolled out an updated CrossOver Office this week adding support for Macromedia products:</p> <quote who="Codeweavers"><p> "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." </p></quote> <p>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 <a href="http://www.transgaming.com/news.php?newsid=89";>the appointment</a> of Leonard Brody to the TransGaming Board of Directors. </p> <p>Also this week, Dan Kegel pointed out that HP World magazine (available <a href="http://www.interex.org/myjsppages/subupp.jsp";>with registration</a>) has references for using CrossOver Office to run Windows programs:</p> <quote who="Dan Kegel"><p> 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 <ul> "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."</ul></p> </quote> </section> <section title="Winesetuptk 0.7 Released" subject="Winesetuptk 0.7 released" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0818.html"; posts="1" startdate="10/28/2003" > <topic>Configuration</topic> <p>Ivan Leo Murray-Smith announced:</p> <quote who="Ivan Leo Murray-Smith"><p> Winesetuptk 0.7 is at the wine sourceforge page <ul> <a href="http://sourceforge.net/project/showfiles.php?group_id=6241";> http://sourceforge.net/project/showfiles.php?group_id=6241</a></ul></p><p> 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. </p><p> 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!</p></quote> </section> <section title="Updated Winetests" subject="New winetests.exe" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0785.html"; posts="1" startdate="10/27/2003" > <topic>Testing</topic> <p>Wanna run some conformance tests on Windows? Jakob Eriksson updated his testing program:</p> <quote who="Jakob Eriksson"><p> Since winetests has not yet made it to CVS and I found some spare time, I have now compiled a new winetests.exe. </p><p> Tests built with MSVC 7 from CVS 20031027. </p><p> (Testing shell cross built with mingw32.) </p><p><ul> <a href="http://vmlinux.org/jakov/Wine/";>http://vmlinux.org/jakov/Wine/</a> </ul></p></quote> <p>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. </p> </section> <section title="New Valgrind For Wine" subject="New tarball of valgrind for WINE available" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0848.html"; posts="2" startdate="10/29/2003" > <topic>Debugging</topic> <p>Valgrind has helped developers find lots of problems with Wine over the past few months. Adam Gundy announced this week:</p> <quote who="Adam Gundy"><p> A new tarball of valgrind modified to work with WINE is available from the valgrind home page: <ul> <li><a href="http://developer.kde.org/~sewardj/";> http://developer.kde.org/~sewardj/</a></li> <li><a href="http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2";> http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2</a></li> </ul></p><p> this is based on the latest stable valgrind release. </p><p> use a current CVS or the latest snapshot of WINE. </p></quote> </section> <section title="Installshield 7 Notes" subject="Installshield7 notes" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0866.html"; posts="2" startdate="10/29/2003" > <topic>Fixes</topic> <p>Carlos Lozano shared some info concerning apps using Installshield 7:</p> <quote who="Carlos Lozano"><p> 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).</p><p> 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: <ul><code> [DllOverrides]<br /> "oleaut32" = "native"<br /> "ole32" = "native"<br /> "rpcrt4" = "native" </code></ul></p><p> 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: <ul><code> "Managed" = "N"<br /> "Desktop" = "640x480"<br /> "Desktop" = "Y" </code></ul></p><p> 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: <ul><code> /* default: not managed */<br /> return FALSE;<br /> } </code></ul></p><p> 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. </p></quote> <p>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.</p> </section> <section title="Keyboard Detection" subject="Re: French keyboard layout with Euro symbol" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0798.html"; posts="12" startdate="10/27/2003" enddate="10/29/2003" > <topic>Internationalization</topic> <p>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:</p> <quote who="Dmitry Timoshkov"><p> I think that this topic was explained many times already. Anyway, here is yet another attempt. <ol> <li> 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.</li> <li> 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.</li> <li> 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.</li> <li> 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. </li></ol></p></quote> <p>Shachar Shemesh pointed out a related problem, <quote who="Shachar Shemesh"> 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.</quote> He went on to explain:</p> <quote who="Shachar Shemesh"><p> 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. </p><p> 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. </p></quote> <p>Dmitry wondered how that info could be queried from X. Shachar tossed out some ideas:</p> <quote who="Shachar Shemesh"><p> I was thinking of one of two options. Unfortunately, both require us to know each keyboard layout we support (though, not necessarily know exactly). <ol> <li> Use the current scheme. LCID is all we really need, IIRC.</li> <li> Use the XKB name</li></ol></p><p> 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.</p></quote> </section> <section title="Longhorn Info" subject="Longhorn info" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0804.html"; posts="1" startdate="10/28/2003" > <topic>Microsoft Windows</topic> <p>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:</p> <quote who="Mike Hearn"><p> 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 ;) <ul> <li>SDK: <a href="http://longhorn.msdn.microsoft.com/";> http://longhorn.msdn.microsoft.com/</a></li> <li>Articles/Info: <a href="http://msdn.microsoft.com/longhorn";> http://msdn.microsoft.com/longhorn</a></li></ul></p></quote> </section> <section title="Stubless Proxies" subject="Misc wine debugging questions" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0893.html"; posts="3" startdate="10/29/2003" > <topic>RPC / COM / OLE</topic> <p>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, <quote who="Mike Hearn"> Greg recently mentioned "stubless proxies". Does anybody know where I can read about these?</quote></p> <p>Greg answered:</p> <quote who="Greg Turner"><p> 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. </p><p> 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). </p><p> In wine, NdrClientCall2 (the more common entry-point) is totally unimplemented -- it simply emits a FIXME and returns indicating success. </p><p> 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 (?). </p><p> 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). </p><p> 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. </p><p> Stated succinctly, stubless proxies are the RPC/DCOM holy grail for wine. </p><p> 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 ;) </p></quote> <p>Mike also found some info:</p> <quote who="Mike Hearn"><p> Your theory is correct. Somehow I stumbled upon this article: <ul><a href="http://www.microsoft.com/msj/0199/com/com0199.aspx";> http://www.microsoft.com/msj/0199/com/com0199.aspx</a></ul></p><p> 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. </p></quote> </section></kc>
