wn20030829_185.xml -brian
<?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>
