WWN: wn20031031_194.xml

Fri Oct 31 01:32:15 CST 2003

wn20031031_194.xml

-Brian
-------------- next part --------------
<?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> 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> </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&#233;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&#252;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>

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.

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:
<quote who="Dan Kegel">
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>
</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&#233;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.

Tests built with MSVC 7 from CVS 20031027.

(Testing shell cross built with mingw32.)
<ul>
 <a href="http://vmlinux.org/jakov/Wine/">http://vmlinux.org/jakov/Wine/</a>
</ul></quote>

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.

</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></quote>

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:
<quote who="Shachar Shemesh">
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.
</quote>
Dmitry wondered how that info could be queried from X. Shachar 
tossed out some ideas: 
<quote who="Shachar Shemesh">
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>

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

Mike also found some info:
<quote who="Mike Hearn">
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>