WWN: wn20030829_185
vinn
vinn at arsenic.theshell.com
Fri Aug 29 13:38:26 CDT 2003
wn20030829_185.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="185" date="08/29/2003" />
<intro> <p>This is the 185th release of the weekly Wine Weekly News publication.
Its main goal is to spend the day recovering from last night's concert. 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="313" size="864" contrib="74" multiples="44" lastweek="33">
<person posts="47" size="149" who="Dimitrie O. Paun" />
<person posts="28" size="74" who="Alexandre Julliard" />
<person posts="19" size="52" who="Mike Hearn" />
<person posts="15" size="48" who="Francois Gouget" />
<person posts="15" size="31" who="Steven Edwards" />
<person posts="11" size="28" who="Duane Clark" />
<person posts="11" size="18" who=" <puoti_at_inwind.it>" />
<person posts="10" size="24" who="Eric Pouech" />
<person posts="8" size="27" who="Ferenc Wagner" />
<person posts="8" size="20" who="Jeremy Newman" />
<person posts="7" size="16" who="Lionel Ulmer" />
<person posts="7" size="14" who="Jakob Eriksson" />
<person posts="6" size="18" who="Todd Vierling" />
<person posts="6" size="14" who="Sylvain Petreolle" />
<person posts="6" size="14" who="Jon Bright" />
<person posts="5" size="14" who="Huw D M Davies" />
<person posts="5" size="13" who="Evalet Olivier" />
<person posts="4" size="10" who="Dustin Navea" />
<person posts="4" size="9" who="Gregory M. Turner" />
<person posts="4" size="7" who="BiGgUn" />
<person posts="4" size="7" who="Martin Fuchs" />
<person posts="3" size="13" who="Jukka Heinonen" />
<person posts="3" size="12" who="Martin Troester?=" />
<person posts="3" size="12" who="Boaz Harrosh" />
<person posts="3" size="9" who="Dan Brosemer" />
<person posts="3" size="8" who="Uwe Bonnes" />
<person posts="3" size="7" who="Gerald Pfeifer" />
<person posts="3" size="7" who="Dmitry Timoshkov" />
<person posts="3" size="6" who="Juan Lang" />
<person posts="3" size="6" who="Jonathan Wilson" />
<person posts="2" size="6" who="Vincent Béron" />
<person posts="2" size="5" who="David Laight" />
<person posts="2" size="5" who="Shachar Shemesh" />
<person posts="2" size="4" who="Jakob Eriksson" />
<person posts="2" size="4" who="P. Christeas" />
<person posts="2" size="4" who="James Tabor" />
<person posts="2" size="4" who="Marcus Meissner" />
<person posts="2" size="4" who="Steven Edwards" />
<person posts="2" size="4" who="Fabian Cenedese" />
<person posts="2" size="4" who="Matthew Caobhlaigh" />
<person posts="2" size="3" who="jeff_latimer" />
<person posts="2" size="3" who="Oleg Prokhorov" />
<person posts="2" size="3" who="Jon Griffiths" />
<person posts="1" size="22" who="Paul McNett" />
<person posts="1" size="6" who="Daniel O'Connor" />
<person posts="1" size="4" who="dd jj" />
<person posts="1" size="3" who="flyker" />
<person posts="1" size="3" who="Anand Kumria" />
<person posts="1" size="3" who="(thunderbird2k)" />
<person posts="1" size="3" who="Jonathan Fosburgh" />
<person posts="1" size="3" who="Jim White" />
<person posts="1" size="3" who="Drew 'dantealiegri' Ogle" />
<person posts="1" size="3" who="Lars Segerlund" />
<person posts="1" size="2" who="PETREOLLE Sylvain" />
<person posts="1" size="2" who="Keith Matthews" />
<person posts="1" size="2" who="Rein Klazes" />
<person posts="1" size="2" who="Gerold J. Wucherpfennig" />
<person posts="1" size="2" who="Ove Kaaven" />
<person posts="1" size="2" who="devNet" />
<person posts="1" size="2" who="flyker" />
<person posts="1" size="2" who="(wine)" />
<person posts="1" size="2" who="Ian Goldby" />
<person posts="1" size="2" who="(Warren_Baird)" />
<person posts="1" size="2" who="Troy Rollo" />
<person posts="1" size="2" who="Tom" />
<person posts="1" size="2" who="Louis" />
<person posts="1" size="2" who="Roderick Colenbrander" />
<person posts="1" size="2" who="Paul Millar" />
<person posts="1" size="2" who="David Orriss Jr" />
<person posts="1" size="2" who="Rolf Kalbermatter" />
<person posts="1" size="1" who="(tony_lambregts)" />
<person posts="1" size="1" who="(juergen.schmied)" />
</stats>
<section
title="News: AclereX"
subject="News"
archive="http://www.aclerex.com"
posts="1"
startdate="08/23/2003"
enddate="08/29/2003"
>
<topic>News</topic>
<p>Mike Hearn gave a pointer to a
<a href="http://www.linuxplanet.com/linuxplanet/reports/4780/1/">LinuxPlanet
story</a> about a new offering from TransGaming:
<a href="http://www.aclerex.com">AclereX</a>. I hesitated to put
this in the news section because as Mike pointed out it seems
like they haven't officially announced this yet. It does seem
fair game though since it's being announced in the trade press
and there's a public web site. From the datasheet on their web site:</p>
<quote who="Transgaming"><p>
AclereX® Enterprise Migrationware allows corporations to run existing
Windows applications on their Linux desktop - transparent and
seamlessly.</p><p>
For unique applications developed in-house or not supported out-of-the-box,
AclereX® can be customized to specifically meet your individual corporate
needs.
</p></quote>
<p>You might notice some threads that started Thursday and Friday aren't
covered here. I'll get to them next week. The end of this week has been
crazy and I haven't had enough time to devote to covering those. </p>
</section><section
title="Wine 0.9 Progress"
subject="Wine 0.9 progress"
archive="http://www.winehq.com/hypermail/wine-devel/2003/08/0574.html"
posts="19"
startdate="08/25/2003"
enddate="08/28/2003"
>
<topic>Project Management</topic>
<p>Mike Hearn started this thread:</p>
<quote who="Mike Hearn"><p>
Well, it's been a while since the last update, so I thought it'd be
worthwhile to write about where we're up to. Looking at the TODO list on
WineHQ, it seems the remaining work falls into two areas:
<ul>
<li> A bit of documentation stuff (rather worryingly "fix the docs build
system" says a patch was submitted last *year*, but is still labelled as
work in progress!).</li>
<li> Configuration, ie winecfg and an auto setup wizard thingy. John K Hohm
has been making great progress lately with making DLLs self register,
but unfortunately nobody has really stepped up to work on winecfg. We
may or may not get the patches from Mark it seems :| </li>
</ul></p><p>
There are a few other things, like DLL separation, and completing the
work to make DLLs self register.
</p><p>
I have a whole load of time with not much to do during September, so I
might sit down and try and get some patches off for winecfg, seeing as
merging in Oves OLE code is going to be slow work at my current rate of
patch committing :(
</p><p>
Is there anything else we might need? I'm tempted to say that having
InstallShield work is a priority, as it seems to have broken quite a bit
lately.
</p><p>
On the TODO list it says that some window management hacks exist but
more debugging work is needed - does anybody know the status of that? A
lot of InstallShield installers at the moment fail due to that X11
ConfigureWindow error - how hard is this to fix?
</p><p>
Having a wine.inf to set up a new installation, does anybody have
details on that? Is this just a case of eating our own dogfood, or is it
really a must have for 0.9?
</p></quote>
<p>Dimi replied and mentioned that the documentation item was not
a big deal. In fact, he had some patches ready to resubmit for that
item. Wine's configuration was another issue. He agreed that work
need to be done as soon as possible getting winecfg working. Mark Westcott
had mentioned he had some patches floating around for winecfg and Dimi
wondered what the status of those were. Mike went out in search of them
and then raised more questions (<i>ed note: this is two emails combined
together</i>):</p>
<quote who="Mike Hearn"><p>
So, Mark has sent me his work, unfortunately not as a patch against CVS
so I'll have to do some merging in. It implements the GUI (but not
backend) for drive editing.
</p><p>
I'm looking over the code now, and have a
few questions about how to proceed. The primary issue is that we can't
have the same setting pulled both from the config file and the registry,
can we? So, as winecfg gradually gets more functional, parts of the
config file will stop being referenced in favour of reg entries set via
winecfg, but not all parts of winecfg will actually do anything. So:
<ol>
<li> How do we stop users being confused because they updated and now
their config file doesn't seem to work anymore?</li>
<li> How do we stop users being confused because they started winecfg but
the changes they make don't always take effect? </li></ol></p><p>
Possibilities include:
<ul>
<li> Warnings on startup if a part of the config file exists. IE if we move
version settings into the registry, output err: lines if those keys are
in the config file to get the user to remove them.</li>
<li> Disabling any controls that don't do anything in the winecfg program,
so the user can't edit them. </li></ul>
</p></quote>
<p>Dimi thought the current warning that winecfg was incomplete would
suffice. As far as cutting over to the new system:</p>
<quote who="Dimitrie Paun"><p>
winecfg should not care at all about the config file. It should
get to the values through registry calls, as we do all over Wine ATM.
This calls will be routed to the values from the config file for now,
but we'll switch them to go to the real registry when we're ready.
</p><p>
For writing, we should also use the registry functions. I'm not sure
what would happen now if you're trying to write config values through
the registry, they may get saved in the registry. Which is just cool,
it just means that winecfg will not be really function until the big
switch, but that should be in the near future :)
</p></quote>
<p>Jakob Eriksson brought up another idea,
<quote who="Jakob Eriksson">
Well, if development after 0.9 is going to focus on correctness while
getting to 1.0,
lots of conformance testing is a must. I really was looking forward to
write a
testing application that runs all the tests, but I can't figure out why
make crosstest is not
working.</quote></p>
<p>Steven Edwards mentioned a simple solution that seemed to work,
<quote who="Steven Edwards">
Can you rename mingws libmsvcrt.a or libntdll.a and see if that fixes it? On Windows with
Mingw+MSYS I have to rename libmsvcrt.a to build the tests.
</quote></p>
<p>Concerning a testing application, Dimi gave some pointers:</p>
<quote who="Dimitrie Paun"><p>
Yes, that would be very nice indeed. Such a test shell should be
something like the JUnit stuff (http://www.junit.org). Here are
few things that I'd want in such an app:
<ul>
<li> it should be a single executable (.exe preferably)
containing all unit tests</li>
<li> when started, it should go through these steps:
<ul>
<li> display a dialog explaining what it is and what it
would do. The dialog would have OK/Cancel buttons</li>
<li> if OKed to proceed, the program should extract
the tests, run them, and collect results,
inspect the system.
While doing these, it should inform the user what
is going on ("Extracting tests...". "Running test X", etc.)
The failed tests should be listed below.</li>
<li> when done, it should present the user with 3 buttons:
<ul>
<li> View Report</li>
<li> Send Report</li>
<li> Cancel</li></ul>
<li> on "Send Report", the report should be emailed to a
special mailing list, from where it's later picked
up by some scripts and analysed.</li>
<li> We should be able to disable the UI via a command
line switch, to allow for automatic execution.</li>
</li></ul></li></ul></p></quote>
<p>From there discussion delved into where and how to send the results
of tests. </p>
</section><section
title="Porting ReWind To OpenBSD"
subject="Porting to OpenBSD 3.4-beta"
archive="http://www.winehq.com/hypermail/wine-devel/2003/08/0525.html"
posts="5"
startdate="08/23/2003"
enddate="08/24/2003"
>
<topic>Ports</topic>
<p>OpenBSD doesn't get mentioned a lot on the Wine lists. Perhaps
that's because most folks use it for bulletproof networking equipment
rather than desktops. There is somewhat active development with
FreeBSD and the port to that platform is known to work. This
week Dan Brosemer took a stab at OpenBSD and ran into problems:</p>
<quote who="Dan Brosemer"><p>
I have been trying to port Wine, WineX, or ReWind to OpenBSD 3.4-beta for
the past week. I've made the most progress with ReWind, so that is what
this post will focus on.
</p><p>
Where I'm stumbling right now, I believe, is in the dll loader:
<ul><code>
odin_at_sleipnir:p6[~/.wine/c]$ wine windows/Sol.exe <br />
err:module:BUILTIN32_LoadLibraryExA loaded .so but dll ntdll.dll still not found - library environment problem or version conflict, check your setup. <br />
err:module:PE_fixup_imports Module (file) ntdll.dll (which is needed by wine) not found
</code></ul>
</p><p>
Now, it _is_ actually loading libntdll.so, I can see this with ktrace:
<ul><code>
181 wine    NAMI    "/usr/local/lib/libntdll.so"<br />
181 wine    RET     open 3<br />
181 wine    CALL    read(0x3,0xcfbefdbc,0x1000)<br />
181 wine    GIO     fd 3 read 4088 bytes<br />
      "\^?ELF\^A\^A\^A\0\0\0\0\0\0 ......
</code></ul>
</p><p>
I see that message is in relay32/builtin32.c, printed if MODULE_FindModule
returns nothing.
</p><p>
In MODULE_FindModule in this loop:
<ul><code>
for ( wm = MODULE_modref_list; wm; wm = wm->next )<br />
{<br />
  .....<br />
}
</code></ul>
</p><p>
I added a <tt>printf("MOD: %s\n", wm->modname);</tt>
which prints out "MOD: wine" four times before the error message above.
</p><p>
I'm curious how MODULE_modref_list is seeded. That's where I think I'll
find a clue to my problem. Could anyone give me some pointers?
</p>
</quote>
<p>Ove K@#229;ven gave a pointer to how it's called,
<quote who="Ove Kaaven">
ntdll.spec.c (generated by winebuild) contains a global constructor to
automatically call __wine_spec_ntdll_init as soon as the .so is loaded,
this init routine calls __wine_dll_register which eventually adds the
DLL to that list. Perhaps you need to adapt the ".section .init" thing
in there.
</quote></p>
<p>Dan investigated and reported:</p>
<quote who="Dan Brosemer"><p>
I'm quite sure I've found my problem and it lies with OpenBSD's
ld.so, not with anything I've done compiling Wine. Quite simply, the .init
and .fini sections don't appear to be executed when a shared library is
loaded with dlopen.
</p><p>
I've posted on tech--at--openbsd.org about it and received a few private replies
confirming that observation and saying Wine isn't the only software that
misbehaves because of this, so I think I'm on the right track.
</p><p>
Of course, that may not be the only issue (it certainly wasn't the first) so
we'll see if I get bit by anything else once I get my ld.so working the way
I need it to.
</p></quote>
</section><section
title="Why Native DirectX Doesn't Work"
subject="interesting stuff I have been finding out about DirectX"
archive="http://www.winehq.com/hypermail/wine-devel/2003/08/0469.html"
posts="7"
startdate="08/22/2003"
enddate="08/23/2003"
>
<topic>DirectX</topic>
<p>Jonathon Wilson looked into whether Wine could use
native DirectX DLL's and was surprised by what he found:</p>
<quote who="Jonathon Wilson"><p>
After investigating the DirectX NT dlls as part of an investigation to see
if they would work on ReactOS, I discovered something.
</p><p>
The core DX dlls (like ddraw.dll, dsound.dll, dinput.dll and others) dont
seem to make kernel-mode or driver/hardware calls directly.
Most of it appears to be done via other places (such as winmm.dll, some
special thunks in gdl32.dll and others)
If my theory is correct (remember though, its just a theory), it may be
possible to not only use the directx userland dlls (like ddraw.dll &
friends) with ReactOS but it may be possible (if one were to implement the
lower-level stubs) in a meaningfull way) to use said dlls with WINE.
</p><p>
If it is possible to use native versions of some of the high-level bits,
that could really help get more games going...
One of the main things that would be needed is a proper implementation of
the GdiEntryxxx functions and the DdEntryxxx functions in gdi32.dll, they
are the "thunks" that allow DirectDraw and Direct3D to talk to kernel mode.
DirectSound & DirectMusic appear to go through winmm.dll to talk to the
sound hardware.
</p></quote>
<p>Lionel Ulmer rained on his parade:</p>
<quote who="Lionel Ulmer"><p>
Well, if you look at TransGaming DDraw code in Wine, you will see that they
mimic the way DirectX is doing this (ie by somehow using an Escape in the
GDI which returns a structure filled with function pointers and private
datas).
</p><p>
Now this is a debate we had in the current WineHQ D3D development team :
should we base our DirectX implementation on how Windows does the separation
between the DLL and the drivers or just implement the DLL and do our own
driver interface.
</p><p>
After some debate, we choose the second one :
<ul>
<li> to not be tied down to some MS APIs at both sides (ie at DLL entry points
and at DLL exit points).</li>
<li> DLL entry points are 1) documented pretty well in MSDN and 2) easily
testable by doing some simple Win32 programs. Compared to the MSDN, the
DDK I read was a lot more difficult to read (and I have no idea if it's
even 'legal' to implement something using the DDK without MS' aproval as
it's not really a published API).</li>
<li> finally, as the ultimate goal of Wine is to reimplement Wine and as no
applications should use these low-level calls directly, the current
solution used in Wine works fine :-)</li>
</ul></p><p>
Anyway, if people from ReactOS want to use our DirectX calls with Windows
drivers, the way we choose is not the way to go...
</p></quote>
<p>Concerning the DLL entry points, Jonathon found some other MSDN docs that
looked useful,
<quote who="Jonathon Wilson">
See this:
<a href=" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/WindowsUserInterface/LowLevelClientSupport/dxlowlevelclientsupport.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/WindowsUserInterface/LowLevelClientSupport/dxlowlevelclientsupport.asp</a>
That explains some stuff about the DdEntry and GdiEntry stuff...
</quote></p>
<p>Lionel still didn't think it would be worth pursuing:</p>
<quote who="Lionel Ulmer"><p>
Oh well, they added some DDK docs in the MSDN (which were not really there
last time I looked)...
</p><p>
But it's as we feared : they explicitely tells us that this interface may
change on each DirectX revision (which is normal as the driver interface
need to change to accomodate more advanced graphic options). So we may have
to rewrite 'old' DirectX code each time a new revision of the DDK comes out.
</p><p>
Anyway, the current code is current not written at all with a DLL / Driver
separation in mind (there are some plans about it, but nothing has been done
yet from what I know). And you should speak to Raphael about this, he's the
one motivated to do this (I am not, as getting more games to run is more fun
than to rewrite everything :-) ).
</p><p>
And more people to code would be welcome of course. And I think if you
really want us to go the DDK way, you would need to at least do part of the
work yourself :-)
</p></quote>
<p>Specifically, Microsoft places this warning at the top of their page:</p>
<quote who="Microsoft"><p>
<u>Warning</u> Microsoft DirectDraw and Microsoft Direct3D use several kernel-mode
routines to communicate with the operating system and the display driver.
These entry points are subject to change with each operating system revision.
Applications are advised to use the DirectDraw/Direct3Dapplication programming
interfaces (APIs). The DirectDraw/Direct3DAPIs insulate the application from
such operating system changes, and hide many other difficulties involved in
interacting directly with display drivers. For more information, see
<a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/vidintro_65yf.asp">Windows DDK</a>.
</p></quote>
</section><section
title="Devel Lists and Viruses"
subject="Viruses in the wine-devel archive ??"
archive="http://www.winehq.com/hypermail/wine-devel/2003/08/0443.html"
posts="15"
startdate="08/22/2003"
>
<topic>Project Management</topic>
<p>Wine-devel was hit pretty hard with viruses last week.
Duane Clark described the precautions taken:</p>
<quote who="Duane Clark"><p>
The Wine lists are currently getting about 1000
Sobig.F viruses per day, some of them supposedly from Alexandre ;)
</p><p>
I have temporarily changed the maximum message size on wine-patches to
40KB. So any emails with valid forged "From" headers will be caught for
moderation. Since all the other lists were already set at 40KB by
default, no viruses were able to make it through.
</p></quote>
<p>
Several messages in the archives were found to be infected and
removed.
Jeremy Newman wanted to know if the offending party should
be unsubsribed from the list as well. Duane didn't think so,
<quote who="Duane Clark">
Please don't remove anyone from the lists. The "From" is always forged,
so you should ignore it. </quote></p>
<p>Of course the obvious question was asked (by P. Christeas),
<quote who="P. Christeas">
Does SoBig.F run under wine? If yes, how bad can it get?
</quote></p>
<p>Marcus Meissner tried running it and reported that it crashed.
Sylvain Petreolle wondered how long it would take for virus
writers to begin complaining their code didn't work under Wine.
Shachar Shemesh warned against using Wine as a sandbox for testing
such things:</p>
<quote who="Shachar Shemesh"><p>
We've been through this discussion before too. Wine is not a VM, and the
isolation between Win32 and Unix code is the result of application's
ignorance, rather than a deliberate design decision. As such, it is
highly NOT recommended for cases where hostile code of unknown qualities
is tested.
</p><p>
For all you know, sobig may be checking whether it is runnning on wine,
and then issuing the correct interrupts (static linking dlopen) and
infecting your Unix system.
</p></quote>
</section></kc>
More information about the wine-patches
mailing list