In the beginning WWN relied on a custom markup language that was generated into HTML. Eric did strange and mystical things to post WWN issues. Then, Zack decreed all issues on his web site would be written in XML. But the XML was evil and horribly malformed. The tools were primitive and I was ignorant. It was decided that the entire backend of the Kernel Traffic site would be redesigned. All was good. (With the exception of the fact I had to manually edit about 100 back issues of WWN to make them XML compliant.) The correct markup is now: <?xml version="1.0" ?> <kc> I doubt Zack or Jeremy's parsers would care if you threw in some extra attributes on the kc tag. Strangely enough, the scripts I use to generate issues seem to have reverted to an older version of this.. hm.. I should fix that. I suppose those early issues of WWN should be preserved, so here they are in all their ugliness. I'm fairly certain I had no idea what I was writing about when I created them. (I think 92 was the first issue I did.) If anyone is bored I'm sure there's a lot of hyperlinks that could be fixed in old issues. I considered doing it, but decided it's not worth the time. -brian
<?xml version="1.0" ?> <kc> <title>Wine Traffic</title> <author contact="mailto:brianv@REMOVETHIS.ski-copper.com"; date="29 Apr 2001 00:00:00 -0800" /> <intro> <p>This is the 93rd release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (a port of the Windows API to Unix-based operating systems).</p> <p>I'm currently having major ISP problems. If you've sent me an email in the last few weeks I haven't gotten it. As a result I've changed the address above to one that will work, however it's not a permanent solution for me.</p> </intro> <stats posts="58" size="159" contrib="27" multiples="13" lastweek="12"> <person posts="5" size="14" who="Francois Gouget <fgouget>" /> <person posts="5" size="13" who="lawson_whitney" /> <person posts="5" size="12" who="Andreas Mohr <a.mohr>" /> <person posts="5" size="11" who="eric pouech <eric.pouech>" /> <person posts="4" size="12" who="Mike Bond <mbond.com>" /> <person posts="4" size="17" who="Dan Engel <dengel>" /> <person posts="3" size="8" who="Dmitry Timoshkov <dmitry>" /> <person posts="4" size="9" who="gerard patel <gerard.patel>" /> <person posts="3" size="6" who="Alexandre Julliard <julliard>" /> <person posts="2" size="10" who="Marcus Meissner <marcus.de>" /> <person posts="2" size="5" who="Jeremy White <jwhite>" /> <person posts="2" size="4" who="Uwe Bonnes <bon.physik.tu-darmstadt.de>" /> <person posts="2" size="4" who="Ove Kaaven <ovehk.no>" /> <person posts="1" size="3" who="Mike Bond <mbond.com>" /> <person posts="1" size="3" who="Gavriel State <gav>" /> <person posts="1" size="2" who="Michael Mauch <michael.mauch>" /> <person posts="1" size="2" who="Marcus Meissner <Marcus.Meissner>" /> <person posts="1" size="2" who="Juergen Schmied <juergen.schmied>" /> <person posts="1" size="2" who="Mike McCormack <mike_mccormack.au>" /> <person posts="1" size="2" who="Dan Kegel <dank>" /> <person posts="1" size="2" who="Martin Pilka <mpilka>" /> <person posts="1" size="2" who="Matthew Cline <matt>" /> <person posts="1" size="2" who="juergen.schmied" /> <person posts="1" size="1" who="Stefan Leichter <Stefan.Leichter>" /> </stats> <section title="Dropping Syslevel Checks from Debugging" subject="GDI syslevel held during psdrv init ... bad" archive="http://www.winehq.com/hypermail/wine-devel/2001/04/0156.html"; posts="6" startdate="24 Apr 2001 00:00:00 -0800" enddate="25 Apr 2001 00:00:00 -0800" > <mention>Marcus Meissner</mention> <p>Marcus Meissner was doing some debugging and ran across a problem and asked for thoughts on how to fix it. Alexandre Julliard replied with, <quote who="Alexandre Julliard">We could probably get rid of the check. Syslevel locking is reasonably stable now, and dll separation will cause more and more false alarms here.</quote> So soon in the CVS changelog an entry came across that read:</p> <quote who=""> <p> Changelog:<br /> Drop SYSLEVEL checks from relay debugging, since they break debugging builtin GDI dlls.</p> </quote> <p>The effect of this is you get less information printed out when debugging. Andreas Mohr felt it was simply not appropriate to take this out and responded to the change with:</p> <quote who="Andreas Mohr"> <p>Hmm, do we really want to do this ?<br /> (I know it's already been applied)</p> <p>Shouldn't we create a different SYSLEVEL_CheckNotLevel_unenforced() function instead which simply doesn't call DebugBreak() ?</p> <p>That way we don't lose the important information about possible syslevel violations.</p> <p>Syslevel violations are an *ongoing* problem. They are not simply "solved". OTOH I could take Alexandre's cvs commit as his firm promise to go through every future patch line by line to check for syslevel mishaps/omissions ;-)</p> <p>Oh yeah, and in case you didn't notice: it's me again complaining about yet another silencing ;-)</p> <p>This patch is not even "too early", it's simply "wrong" IMHO, as it is an ongoing problem (I did mention this before, didn't I ? :).</p> <p>Sorry for me being of such an opposing nature ;-) </p> </quote> <p>A few more messages went back and forth between Marcus and Andreas about other ways to get around dropping the check, but the change stayed in CVS.</p> </section> <section title="Fault Handling?" subject="fault handling - oof" archive="http://www.winehq.com/hypermail/wine-devel/2001/04/0149.html"; posts="10" startdate="24 Apr 2001 00:00:00 -0800" enddate="26 Apr 2001 00:00:00 -0800" > <mention>Alexandre Julliard</mention> <mention></mention> <p>Lawson Whitney was working on a mail application and suddenly had problems with its fault handling. He suspected it was because of something recently added to Wine and began reverting patches until it seemed to be narrowed down. Lawson wrote:</p> <quote who="Lawson Whitney"> <p> It _might_ be a local misconfiguration, so don't waste too much time on it, but if you spot something that could be a bit wrong in one of these patches, please let me know.</p> <p> N 1 Apr 23 Alexandre Julliard (2,414) wine/dlls/msvcrt time.c<br /> N 2 Apr 23 Alexandre Julliard (2,089) wine/include/msvcrt stddef.h<br /> N 3 Apr 23 Alexandre Julliard (2,071) wine/debugger types.c<br /> </p> </quote> <p>This report generated a fair number of emails that left a lot of people scratching their heads. Francois Gouget first wondered, <quote who="Francois Gouget">If you're using native msvcrt then the first two should have no impact. If you meant that the crash only occurs when you try using the builtin msvcrt then maybe it's the patch to time.c. But I would still don't see why... quite the opposite.</quote></p> <p>Eric Pouech then questioned the debugger patch and asked, <quote who="Eric Pouech">I don't see how a fix in the debugger could change the way an app work when the debugger is not launched... did you try to run the app with the debugger started before the crash to see where you get the first fault ?</quote></p> <p>Lawson began messing around and narrowed it down to what he thought was the patch to the debugger. He took a break and when he came back to working on it discovered the problem, <quote who="Lawson Whitney"> If you get this, it comes by wine with the debugger patch in. It seems I was getting HD errors which were causing wine to hang and otherwise misbehave. Load a library, and when you are done there is nothing there, so when the init code gets called, it faults. reverting moved the files to sectors that happened to work. I should have known when the same version of wine worked on one box and not on the other for the same app (shared by nfs) but at the time it only made my head hurt. e2fsck -c has fixed it for now, but sterner measures may become necessary.</quote></p> <p>Looks like its time to start trying to find that warranty information..</p> </section> </kc>
<?xml version="1.0" ?> <kc> <title>Wine Traffic</title> <author contact="mailto:brianv@REMOVETHIS.ski-copper.com";>Brian Vincent</author> <issue num="94" date="06 May 2001 00:00:00 -0800" /> <intro> <p>This is the 94th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).</p> </intro> <stats posts="58" size="172" contrib="23" multiples="11" lastweek="10"> <person posts="10" size="22" who="Alexandre Julliard <julliard>" /> <person posts="7" size="24" who="Gerard Patel <gerard.patel>" /> <person posts="7" size="20" who="Ian Pilcher <ian.pilcher>" /> <person posts="4" size="13" who="Francois Gouget <fgouget>" /> <person posts="4" size="11" who="Andreas Mohr <a.mohr>" /> <person posts="3" size="17" who="Dmitry Timoshkov <dmitry>" /> <person posts="3" size="7" who="Eric Pouech <eric.pouech>" /> <person posts="3" size="6" who="Bang Jun-Young <bjy>" /> <person posts="2" size="8" who="Gavriel State <gav>" /> <person posts="2" size="4" who="Marcus Meissner <marcus>" /> <person posts="2" size="3" who="David Howells <dhowells>" /> <person posts="1" size="2" who="Dan Kegel <dank>" /> <person posts="1" size="1" who="Chris Morgan <cmorgan>" /> <person posts="1" size="1" who="David.Goodenough" /> <person posts="1" size="1" who="Christopher Morgan <cmorgan>" /> </stats> <section title="Headlines" subject="CUPS Support" archive="http://www.winehq.com/hypermail/wine-cvs/2001/04/0158.html"; posts="2" startdate="27 Apr 2001 00:00:00 -0800" enddate="27 Apr 2001 00:00:00 -0800" > <mention></mention> <p>Gerard Patel, quite rightly, pointed out that I had missed an interesting CVS commit last week. In particular Gerard wrote, <quote who="Gerard Patel"> I noticed on LinuxToday that the last Kernel Cousin Wine was showing a 'slow week' - the week where Marcus posted CUPS support - IMHO the more interesting patch since months for all non-games apps. He is not following wine-patches and wine-cvs it seems :-/ </quote></p> <p>That patch by Marcus Meissner was posted with the following note:</p> <quote who="Marcus Meissner"><p> I have implemented CUPS support in WINE.</p> <p>Rerun autoconf ; autoheader -l include</p> <p>The only dangerous option currently is that in win.ini it modifies the line: <br /> [windows] <br /> device=... <br /> marking the default printer.</p> <p>I used a hack with 'CUPS:CupsPrinterName' to pass the information on which printer to use down to the spooling code, since this appears to be otherwise impossible.</p> <p>I have also added some gotos to get rid of the huge unnecessary code duplication in PSDRV_FindPrinterInfo().</p> <p>I have tested it with: <br /> notepad.exe <br /> mspaint.exe <br /> winhelp.exe <br /> uedit32.exe <br /></p> <p>Printing now works out of the box, if you have [afmdirs] set up and .afms available.</p></quote> <p>In addition to this, in the last few weeks there has been other work done on printing. Changes have affected getting the page setup dialogs functional, work on font handling (see below), and fixes to the Postscript driver.</p> </section> <section title="Font Handling Issues" subject="TrueType font metrics for PostScript driver" archive="http://www.winehq.com/hypermail/wine-devel/2001/04/0199.html"; posts="9" startdate="29 Apr 2001 00:00:00 -0800" enddate="30 Apr 2001 00:00:00 -0800"> <mention></mention> <p>Ian Pilcher was working on on the Postscript driver and ran into the following dilemna:</p> <quote who="Ian Pilcher"><p> In order to Unicode-enable the PostScript driver, it needs information about about font encodings that isn't present in Adobe's AFM file format (glyph names for character encodings greater than 256). For Type 1 fonts with a standard encoding, the driver can use the encoding in the Adobe Glyph List. (There's no other choice.)</p> <p> TrueType font designers, however, seem to regard glyph naming as an opportunity to express their creativity. Besides, the information is present in the TrueType font files, so the driver might as well use it.</p> <p> The driver could read this information directly from the font files, but this would make Wine dependant on the FreeType libraries, and that doesn't strike me as a wonderful idea. Instead, I have cobbled together a small program which reads a TrueType font file and creates a "TrueType Font Metrics" file, which is very similar to an AFM file. (This program does use the FreeType library.)</p> <p> Anyone have any objections to using this approach as a interim measure? </p> </quote> <p>Gavriel State responded to this by describing a general framework for working with fonts:</p> <quote who="Gavriel State"><p> From the end user perspective, printing in Wine sucks right now due to the fact that you've got to manually make all these AFM files (or now your proposed TT equivalent), and then just kind of hope that the printer has the font available. If you're printing to a local inkjet or something and you have Ghostscript set up just so, it'll work, but it acts horribly if you're printing to a remote PS device.</p> <p> The only way that that problem can be solved is if we can automatically upload a T1 version of any given font to the PS file. We can only do that if we have access to the glyph outline data, which would require linking to something like FreeType in some way.</p> <p> When we were doing WPO2K for Linux at Corel, we used Bitstream's commercial font server for this purpose. It had an extended API that you could use to get at additional font characteristics and glyph outlines. It was a major pain to use, and it appears to be the top reason that end users have problems with the product (font server configuration is a nightmare for newbies). It's a shame that we didn't use FreeType instead.</p> <p> What I'd love to see happen with fonts in Wine is this:</p> <p><ul> <li> shift the x11drv and wineps over to using the DDK Font Engine APIs that are currently just stubs.</li> <li> Implement a FreeType font driver that links to Freetype and uses the FreeType APIs for all font metrics data as well as rasterization.</li> <li> Implement an X11-dependant font driver in the Font Engine to rely on as a backup if FreeType isn't available.</li></ul></p> <p> Using FreeType more directly would also allow Wine to do serious typography - the metrics data available from X is awful compared to what you can get directly from FreeType, and doing anything less gives you subtle variations in glyph placement that can completely mess up the decision of where to break a line. If we ever want to see people using Wine for serious graphics and page layout applications, we have no choice but to go for the FreeType approach.</p> <p> Now, all of that said, I don't actually have the time to help with any of this directly (unless someone wants to throw a contract my way, of course). All I can really do is cheer you on from the sidelines should you decide to go for it, and perhaps offer the occasional nugget of advice. Speaking of which, I do hope that you've seen the font & printing code in the Corel wine tree. It may not do you much immediate good, but I suspect that it could be a usefull reference point. </p></quote> <p>He also asked, <quote who="Gavriel State"> What do you find objectionable about making wine work more closely with FreeType? </quote> Ian replied, <quote who="Ian Pilcher"> Absolutely nothing. I just don't think the immediate benefit of getting at TrueType encodings justifies creating the dependency at this time. </quote> Ian also agreed with Gavriel's ideas, but pointed out that for now he was just interested in getting the driver Unicode-enabled.</p> <p>Alexandre Julliard wondered though, <quote who="Alexandre Julliard"> But doesn't your solution also require FreeType anyway? Linking it into Wine or into a separate program is not really different for the user, he still needs to install it. </quote> Ian responded, <quote who="Ian Pilcher"> With a separate program, FreeType is only required for people who want to print TrueType fonts. If I put FreeType calls directly into the driver, FreeType will be required to build/run Wine at all, even for users that derive no benefit from it. </quote></p> <p>Alexandre didn't seem to mind putting the calls right within the driver, noting that <quote who="Alexandre Julliard"> We will have to use FreeType at some point anyway, so we might as well start now. Besides it seems it will be easier to use if everything is built-in instead of having to run a separate tool. </quote></p> <p>From there the discussion evolved into ways of setting up the autoconf checks and exactly what versions of Freetype should be supported. Red Hat shipped FreeType 1.4 with their 7.0 distribution while with 7.1 they included FreeType 2.0.1 too. The concensus seemed to be that FreeType 2.0 API should be used. From there Ian went on to add autoconf checks for the FreeType header files.</p> </section> <section title="Wine and NetBSD" subject="Wine and NetBSD" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0004.html"; posts="5" startdate="01 May 2001 00:00:00 -0800" enddate="02 May 2001 00:00:00 -0800" > <mention></mention> <mention>Francois Gouget</mention> <mention>Eric Pouech</mention> <p>Bang Jun-Young posted an interesting message to the list:</p> <quote who="Bang Jun-Young"><p> For the last couple of weeks I spent some time doing porting Wine to NetBSD (there used to be a port but was too out of date). After applying patches my own, it has been successfully compiled and started running.</p> <p> The most serious problem occurs, however, whenever I try to run a Windows binary with it:</p> <p><ul> $ wine c:\\windows\\sol.exe<br /> No built-in EXE module loaded! Did you create a .spec file? </ul></p> <p> Obviously sol.exe doesn't need a .spec file to run. When/Why do I get such an error? </p></quote> <p>Eric Pouech thought the problem was a loader issue. At some point the native DLL's weren't being registered most likely because Wine's initialization functions weren't being called. </p> <p>Francois Gouget was digging through configure.in and noticed that for NetBSD it didn't really specify how to link a builtin DLL. Jun-Young noted that as of NetBSD 1.5 the native binary format had completely switched over to ELF so most GNU tools could be used just like on Linux and FreeBSD. Of course this also means that older versions of NetBSD likely won't work. </p> </section> <section title="Wine Manuals" subject="Script to get committed patches" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0005.html"; posts="7" startdate="01 May 2001 00:00:00 -0800" enddate="02 May 2001 00:00:00 -0800" > <mention></mention> <mention>Gerard Patel</mention> <p>Gerard Patel was trying to retrieve a patch and couldn't figure why it didn't look like the normal output from diff. Eric Pouech replied to that by mentioning, <quote who="Eric Pouech"> this type of issue has been introduced when I added the ability of listing the added files in a patch (before only the diffs to existing files were printed) </quote>. </p> <p>In the course of more discussion Gerard mentioned he had just read the Wine user manual. Francois Gouget then gave pointers to the official manuals:</p> <quote who="Francois Gouget"><p> right there on the WineHQ site:</p> <p><ul> <li>there's a big 'Help!' heading with 'WINE Documentation and Support, FAQ and HOWTO.' as the subtitle. Click on it.</li> <li>there, the first item is 'Official Wine documentation', click on it</li> <li>and then you have the choice of:</li> <ul> <li> the 'Wine User Guide' <a href="http://www.winehq.com/Docs/wine-user/";>http://www.winehq.com/Docs/wine-user</a></li> <li> the 'Winelib User Guide' <a href="http://www.winehq.com/Docs/winelib-user/";>http://www.winehq.com/Docs/winelib-user</a></li> <li> the 'Wine Developers Guide' <a href="http://www.winehq.com/Docs/wine-devel/";>http://www.winehq.com/Docs/wine-devel</a></li> <li> the 'Wine Packagers Guide' <a href="http://www.winehq.com/Docs/wine-pkg/";>http://www.winehq.com/Docs/wine-pkg/</a></li> </ul></ul></p> <p> It should even be up to date but I'm not entirely sure. If not then something must be done about it.</p></quote> <p>There's a lot of interesting reading in there for users and developers alike.</p> </section> <section title="Update: InstallShield and OLE Question..." subject="Re: InstallShield and ole question..." archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0105.html"; posts="18" startdate="18 Apr 2001 00:00:00 -0800" enddate="01 May 2001 00:00:00 -0800" > <mention></mention> <p>I was a bit premature in covering the InstallShield thread a few weeks ago <kcref subject="InstallShield and ole question..." startdate="17 Apr 2001 23:00:00 -0800"></kcref>. Shortly afterward the thread spun off in a few different directions. It was decided that some method of marshalling was needed to get InstallShield v6 installers to work because some method was needed to get function calls to go between processes. That led into various people discussing attempts to take a stab at supporting COM/DCOM protocols.</p> <p>Dan Kegel pointed to the FreeDCE project: </p> <quote who="Dan Kegel"> <p> <a href="http://freedce.sourceforge.net/";>http://freedce.sourceforge.net/</a> is an open source project to implement COM. It's been around quite some time, and started off from the same DCE sources that Microsoft based its stuff on. (See also <a href="http://linas.org/linux/corba.html";>http://linas.org/linux/corba.html</a></p> <p>I wonder if that might not be useful here?</p> </quote> <p>Jeremy White felt there were a lot of legal implications to consider:</p> <quote who="Jeremy White"><p> With COM, the other issue is that someone needs to look at the MS patents in this area. Mainsoft is telling people that they can't use Wine to port COM code, because Microsoft holds patents on some of the Vtable logic used in COM (and no, I don't have any more detail than that, this came to me third hand). I've also asked the FSF for help tracking this FUD down and refuting it.</p> <p>The upshot of my comment is that it's critical that we use our own marshalling/ipc protocol.</p> <p>DCOM is documented, and what's more it appears to be well documented, and what's more, it doesn't look as though the implementation will be particularly hard...</p></quote> <p>Dan Kegel provided some more information:</p> <quote who="Dan Kegel"><p> For the curious:<br /> Snooping on his conversation using google.com, I see it's patent number 5297284 he's worried about.</p> <p> <a href="http://164.195.100.11/netacgi/nph-Parser?Sect2=PTO1&p=1&u=%2Fnetahtml%2Fsearch-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN%2F5297284";>http://164.195.100.11/netacgi/nph-Parser?Sect2=PTO1&p=1&u=%2Fnetahtml%2Fsearch-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN%2F5297284</a> </p></quote> <p>Gavriel State pointed out the following problems with the relevancy of the patent: </p> <quote who="Gavriel State"> <p>Hmmm - a few points to consider:</p> <p><ol> <li> The patent seems very much oriented towards compilers for object oriented languages. I'm not sure how broadly that patent can be applied to code like ours that uses C to mimic the behaviour of a OO language. If there's an issue anywhere, I'd suspect that it's with g++, not Wine.</li> <li> Even with g++, the work described in the patent that's actually new (ie: wasn't implemented in other C++ compilers as of April 1991) mostly seems to cover multiple inheritance related issues - adjusting the this pointer to the right part of an MI object's vtable, etc. Since a COM interface is nothing but a flat array of function pointers, I fail to see any relevance at all to the Wine side of things.</li> <li> At least some of the g++ people seem to know something about this patent. There's a small thread here: <p> <a href="http://gcc.gnu.org/ml/gcc/1999-08/msg00862.html";>http://gcc.gnu.org/ml/gcc/1999-08/msg00862.html</a> And there's some further discussion wrt the ia64 C++ abi here: </p><p> <a href="http://reality.sgi.com/dehnert_engr/cxx/cxx-closed.html";>http://reality.sgi.com/dehnert_engr/cxx/cxx-closed.html</a></p></li> <li> G++ was around for quite some time prior to the patent application. You can download an archival copy of g++ 1.39.0, which predates the patent here: <p> <a href="http://planetmirror.com/pub/gcc/old-releases/gcc-1/?N=D";>http://planetmirror.com/pub/gcc/old-releases/gcc-1/?N=D</a></p></li> </ol> </p> <p> Anyhow, this is just from a very cursory analysis, but I'd say that the Mainsoft FUD is just that: FUD. </p> </quote> </section> <section title="Library Freeing" subject="FreeLibrary() library freeing" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0009.html"; posts="7" startdate="01 May 2001 00:00:00 -0800" enddate="02 May 2001 00:00:00 -0800" > <mention></mention> <p>Andreas Mohr received a trace of a crash from an install program. The root of the problem was that libraries weren't being freed in Freelibrary(). Andreas wrote:</p> <quote who="Andreas Mohr"><p> This happened because the program did some FileVersionGet*() calls before on uninst.exe, which do LoadLibrary()/FreeLibrary() internally, but of course the file handle didn't get freed any more.</p> <p> I believe the potential problems that this can cause are way more important than some claims that "there are some problems with library freeing". I've had that FreeLibrary() #if hack removed for a long time, and I haven't see any adverse effects (not that it's too easy to spot and attribute to this problem probably, though).</p> <p> Besides, Musicmatch Jukebox used zillions of MB (yes, that's a leak for you) due to that Wine "feature".</p> <p> I for one would truly like to see it fixed ASAP.</p> <p> If FreeLibrary() has a problem, then we need to fix it. Running away from the problem by implementing strange hacks does no good to anybody.</p></quote> <p>The main problems right now center on various versions of glibc and the fact that the DLL separation is continuing. Alexandre responded with, <quote who="Alexandre Julliard"> Agreed; I have uncommented the VirtualFree, and you are hereby volunteered to track down and fix any crash caused by this ;-)</quote></p> <p>Some discussion went back and forth concerning potential problems this might cause with older glibc versions. Alexandre clarified the change with, <quote who="Alexandre Julliard">Actually we still cannot dlclose builtin libraries; the change I made is to free memory used by PE dlls. Freeing builtins properly will require dll separation to be completed first. And once this is done we will no longer rely on glibc dlclose reference counting so the bug shouldn't impact us.</quote></p> </section> </kc>
<?xml version="1.0" ?> <kc> <title>Wine Traffic</title> <author contact="mailto:brianv@REMOVETHIS.ski-copper.com";>Brian Vincent</author> <issue num="95" date="13 May 2001 00:00:00 -0800" /> <intro> <p>This is the 95th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).</p> <p>Next week's issue will likely arrive on Tuesday, or possibly later depending on how many threads there are. I'll be on vacation next week. On a related note, does anyone have any suggestions as to what to see or do at Lake Powell, UT?</p> </intro> <stats posts="2" size="182" contrib="2" multiples="13" lastweek="0"> <person posts="9" size="32" who="Francois Gouget <gouget>" /> <person posts="8" size="35" who="Marcus Meissner <marcus.de>" /> <person posts="6" size="18" who="Ian Pilcher <ian.pilcher>" /> <person posts="3" size="8" who="Andreas Mohr <a.mohr>" /> <person posts="3" size="7" who="Alexandre Julliard <julliard>" /> <person posts="3" size="7" who="Eric Pouech <eric.pouech>" /> <person posts="3" size="6" who="Uhmmmm <uhmmmm>" /> </stats> <section title="Headlines" subject="A new vintage and some interesting press" archive="http://www.winehq.com/hypermail/wine-cvs/2001/05/0068.html"; posts="1" startdate="10 May 2001 00:00:00 -0800" enddate="10 May 2001 00:00:00 -0800" > <mention>CodeWeavers</mention> <mention></mention> <mention>Transgaming</mention> <mention>TransGaming</mention> <p>Alexandre has unleashed a new snapshot unto the world. On Thursday Wine-20010510 was cut and made available. The source is available via http at <a href="http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/Wine-20010510.tar.gz";> http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/Wine-20010510.tar.gz</a> or through ftp at <a href="ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/Wine-20010510.tar.gz";> ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/Wine-20010510.tar.gz</a>. </p> <p>The main changes include:</p> <p><ul> <li> a ton of printing enhancements (check out last weeks issue about the addition of CUPS support)</li> <li> graphics driver restructurations</li> <li> changes to facilitate a port to NetBSD</li> <li> and lots of other fixes for bugs</li> </ul> </p> <p>Also out this week were a pair of interesting stories in the press.</p> <p>The first one, from <a href="http://www.gamespy.com";>GameSpy.Com</a>, is titled <a href="http://www.gamespy.com/articles/may01/wine/";>Ports vs. Wine</a>. As <a href="http://www.linuxtoday.com";>Linux Today</a> describes it, "GameSpy takes on the question of whether Linux gamers are better off waiting for Linux ports (which aren't as plentiful as many would like) or getting behind Wine. Includes commentary from Gavriel State of Transgaming, which is working on bringing DirectX to Wine; and an assortment of pro-ports people including Scott Draeker of Loki, who maintain that compatibility layers are bad news". This is what Gavriel had to say in the article:</p> <quote who="Gavriel State"><p> TransGaming doesn't see WineX as competition for source level porting efforts from companies such as TribSoft and Loki. Rather the opposite: WineX compliments the existing Linux games market by keeping Linux users in Linux to play their games, even when the developer or publisher has decided against a direct Linux port. TransGaming is certainly not going to be spending any effort on games that have already been ported by Loki or TribSoft. </p> <p>Keep in mind also that WineX can be used for source level compatibility (aka Winelib) to speed up the process of recompiling games using Linux-based compilers and development tools, and thus taking advantage of Linux-specific features where they make sense. In fact, internally we use the Winelib approach for regression testing with the various Microsoft Direct3D samples. </p> <p>It's not an either/or situation. We'll see some games being played under the Wine binary loader, some ported"natively" to Linux using Winelib and some direct access to Linux APIs, and others rewritten from the ground up using APIs like SDL.</p> <p>The true strength of Linux and Open Source lies in diversity and choice, and having multiple approaches to game portability is just one more aspect of that strength. </p> </quote> <p>Also included in the article is a nice <a href="http://www.gamespy.com/asp/image.asp?/articles/may01/wine/1.jpg";>screenshot</a> of Shiny's Sacrifice running with WineX.</p> <p>The second article out this week is <a href="http://www.eet.com/story/OEG20010508S0061";>"Plug-ins to enhance browsers of Linux-based appliances"</a> from <a href="http://www.eet.com";>EETimes</a>. It starts off:</p> <quote who="eetimes"> <p>Looking to narrow the gap in features between Windows- and Linux-based platforms, CodeWeavers Inc. has developed a series of browser plug-ins such as Shockwave and QuickTime for Linux-based Internet appliances.</p> <p>CodeWeavers' Crossover plug-in software, scheduled for a May 15 launch, will be offered to Internet appliance manufacturers building platforms that run Linux or any Unix-like operating system. </p> </quote> <p>And then further down:</p> <p><quote who="eetimes">In addition to the Crossover plug-ins, CodeWeavers plans this fall to launch Crossover display, which will let an Internet appliance start up a Windows application installed on a nearby PC with a click of a button, but without a Windows OS. And Crossover server, scheduled for release in mid-2002, is a complete Windows-compatible Linux-based server. </quote></p> </section> <section title="doors IPC" subject="doors IPC" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0054.html"; posts="3" startdate="08 May 2001 00:00:00 -0800" enddate="09 May 2001 00:00:00 -0800"> <mention></mention> <p>Damjan Lango posted note about speeding up the wineserver:</p> <quote who="Damjan Lango"><p> Some time ago here was a discussion about speeding up the communication between the wineserver and the application with various kernel patches. I was reading "Unix Network Programming, volume 2 - IPC" and ran over a "doors" IPC api that is implemented on Solaris and has the lowest latency. According to the book it is ~3 times faster than pipe. Actual values for Solaris 2.6 in the book are: (in miliseconds)</p> <p><ul><code> doors: 121<br /> sysv msgq: 260<br /> pipe: 324<br /> unix dom. socket: 465<br /> posix msgq: 584<br /> </code></ul></p> ... <p>There is also a link to a Linux implementation of doors on: <a href="http://www.rampant.org/doors/";>http://www.rampant.org/doors/</a></p> <p>On this link you will find also more info on doors.</p> <p>But according to the performance tests that the author made, the linux pipe is somewhat the same speed as doors so maybe it could be optimized more or maybe is Linux's pipe already so optimized that doors are unnecesary.</p> <p>So what do you think, would this be useful for speeding up wine? I apologoize if you already know about this...</p></quote> <p>Marcus Meissner replied with:</p> <quote who="Marcus Meissner"><p>What a coincidence ;)</p> <p>I just did a patch changing the critical section handling to become more of a spinlock.</p> <p>I have attached it. This should reduce the critical section based reschedules between:<br /> <ul><code>wine <-> wineserver <-> wine</code></ul><br /> to:<br /> <ul><code>wine <-> wine</code></ul></p> <p>Since critical sections are thought to be 'fast' and 'short time' locking primitives, and Win32 threads should not sleep in a critical section, we can just give up our timeslice and wait for the other thread that has the lock to continue.</p> <p>This is a preliminary version, but it works. It uses 'LockSemaphore' as differentation between process-local and global critical sections.</p> <p>It uses 'sched_yield', which is a POSIX feature, to give up the timeslice. How does one force a reschedule on another UNIX? Is<br /> <blockquote><code>select(0,NULL,NULL,NULL,shorttimeout);</code></blockquote> reliable?</p> <p>This patch can give spinning processes on SMP systems, but I do not consider this a real problem at this time.</p> <p>I would like to know if there is something wrong with the concept ;)</p> <p>At least winword feels a bit snappier now.</p></quote> </section> <section title="Helping with Wine" subject="Re: where do I go to find out who needs help" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0068.html"; posts="2" startdate="09 May 2001 00:00:00 -0800" enddate="09 May 2001 00:00:00 -0800"> <mention></mention> <mention>codeweavers</mention> <p>Sean Callahan sent a message that asked what could be done to help out with Wine. Francois Gouget sent a lengthy reply that listed a lot of items:</p> <quote who="Francois Gouget"> <p> Hmmm, I think I can also find a list of bugs in bugzilla that could easily be fixed by someone new to Wine:</p> <p> Easy:</p> <p> <ul> <li> Builtin msvcrt mishandles the cmdline to argv conversion #234: <a href="http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=234";>http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=234</a> This prevents 'wine /mnt/win/Program\ Files\whatever\foo.exe' from working if you're using the builtin msvcrt!</li> <li> I'm almost 100% certain that there's another bug in the same function in its handling of the environment variable.</li> <li> PrgWin95/98: System metrics differ from the Win9x values #48: <a href="http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=48";>http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=48</a> One day I'll fix this one... I swear. Unless you want to work on it first. In that case I'll provide you with my test application and dumps of the metrics for Win95, Win98, NT4, ...</li> <li> The doc about the command line arguments and the config file is out of date. I'm sure there are plenty of other things that are out of date.</li> <li> Get the VXCL samples, test them with Wine and report the bugs in the bugzilla database. I know there's lots of them. Then people (or yourself) can start fixing these bugs in a distributed fashion.</li> <li> PrgWin95: Listbox getting a recessed border instead of a flat one #56: <a href="http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=56";> http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=56</a> (I can provide you with the sample application)</li> <li> I think it would be nice to add a tool that displays the dlls version information like 'About' does in the windows explorer. I have some code you could use as a starting point and I think it could be merged with winver. In fact this would be almost stabdard windows programming.</li> <li> There's a bug in the drawing of the border of the common control tabs. Fixing each of the four instances of the code is easy. It would be interesting to find a way to factorize some of this code.</li> </ul> </p> <p>Medium (I expect these would take longer or be a bit harder)</p> <p> <ul> <li> Provide a pedump utility #91: <a href="http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91";> http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91</a> I know there's sample code that does that already floating around so it should be relatively simple.</li> <li> wrc fails on preprocessed files #115: <a href="http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=115";> http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=115</a> I believe it's just a grammar problem. You'll need to know (or to get cozy with) lex/yacc...</li> <li> CreateIcon does not resize bitmaps #175: <a href="http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=175";> http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=175</a> I did a similar fix somewhere some time ago. I can provide a sample application and I might be able to point you in the right direction.</li> <li> winemaker: 'winemaker --nomfc' does not have the intended effect #227: <a href="http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=227";> http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=227</a> </li> <li> winemaker: Ignores the '--with-{mfc,wine}' options once they are cached #225: <a href="http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=225";> http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=225</a> If you're familiar with autoconf and know how configure scripts should behave...</li> <li> StrokePath ignores PS_JOIN_xxx #11: <a href="http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=11";> http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=11</a> This should not be too difficult to fix but it would certainly help if you are familiar with GDI.</li> <li> Checking the differences between what's in the Windows dlls and what's in our spec files... and fix the contents of our spec files as appropriate. I already have a list of all the APIs in each of the dlls for Win95, Win98, NT4 and Wine2000, plus a script that can show the differences.</li> <li> Enhancing the above perl script.</li> </ul> </p> <p> But let us know also what kind of work you would like to do and what kind of things you're best at:<br /> <ul> - C programming<br /> - Debugging<br /> - Windows programming<br /> - tweaking shell scripts<br /> - writing/fixing documentation<br /> - doing web stuff<br /> </ul> </p> <p> It also depends on what motivates you: getting an application to work, implementing some new functionality, getting applications to compile, fixing scripts, fixing documentation or writing new documentation...</p> <p> And the last parameter is how much time you have for Wine work. In any case it's probably better to start with something simple to see if you like it.</p> </quote> <p>And in a completely different thread it was asked how to submit code once something has been fixed. Francois also replied to that with:</p> <quote who="Francois Gouget"><p> > Have a look at http://www.winehq.com</p> <p> More precisely:</p> <p><ul> <li>CVS <a href="http://www.winehq.com/dev.shtml#CVS";>http://www.winehq.com/dev.shtml#CVS</a> The best way to stay up to date.</li> <li> wine-patches <a href="http://www.winehq.com/mailman/listinfo/wine-patches";> http://www.winehq.com/mailman/listinfo/wine-patches</a> It's best if you subscribe to wine-patches (otherwise each of your emails will go through the moderator)</li> <li> Wine Developer's Guide: Chapter 4. Submitting Patches <a href="http://www.winehq.com/Docs/wine-devel/patches.shtml";> http://www.winehq.com/Docs/wine-devel/patches.shtml</a> All you need to know about submitting patches (I hope)</li> </ul></p> <p> Should you run out of FIXMEs (!), don't hesitate to ask for ideas of things to hack on this list. </p> </quote> </section> <section title="GDB Remote Debugging" subject="GDB remote debugging" archive="http://www.winehq.com/hypermail/wine-patches/2001/05/0049.html"; posts="4" startdate="09 May 2001 00:00:00 -0800" enddate="09 May 2001 00:00:00 -0800"> <mention></mention> <mention>Ove Kåven</mention> <mention>Eric Pouech</mention> <p>Ove Kåven posted a patch on the wine-patches list with updates on some code he wrote for using gdb to debug Wine apps:</p> <quote who="Ove Kaaven"> <p>For any sufficiently disillusioned Wine hackers, here's my current experimental code for letting GDB attach to a Wine process. It's reasonably featured (exceptions are caught, changing threads work, single-stepping works, software breakpoints work, you can do backtraces, change registers and variables, etc). You can also do "info shared" to get a list of loaded .sos, and use the "sharedlibrary" command to load their symbols, but I strongly recommend against loading symbols for libpthread.so, or you'll destroy the neat "info thread" display.</p> <p>This code has helped me quite a bit in my debugging, actually, when winedbg couldn't be used...</p> <p>Apply autoconf after patching. Engage with ./configure --enable-remote-gdb</p> <p>I assume Alexandre isn't going to like some of the stuff in here, but I suppose it's up to him whether to take it or leave it...</p> </quote> <p>He was right, Alexandre responded with:</p> <quote who="Alexandre Julliard"> <p>How did you guess I wouldn't like it? ;-)</p> <p>Actually I think it's a neat hack, but it doesn't belong in the server at all. You should be able to do the same thing as a client-side process using the Win32 debugging API. It could be either a stand-alone Winelib app, or a special mode inside winedbg so that you can reuse some of the code in there.</p> <p>Ove responded to this and said that he could attach and detach gdb to a running process whereas the winedebugger can't do that. Eric Pouech cleared this up with some instructions:</p> <p>> winedbg can't, at least nobody knows<br /> > how to attach winedbg to a running process.</p> <p>well, winedbg can... and now everybody *SHOULD* know</p> <p>start winedbg without any argument on commande line then, use command <br /> <ul><code>walk process</code></ul></p> <p>you'll get a list of running processes using the command<br /> <ul><code>attach <pid></code></ul><br /> really attaches to the running process</p> <p>the only drawback of the method (compared to gdb interface) is that the Win32 API doesn't allow to detach the debugger from a running process the only issue is to kill the debuggee (or the debugger)</p> </quote> </section> </kc>
<?xml version="1.0" ?> <kc> <title>Wine Traffic</title> <author contact="mailto:brianv@ski-copper.com";>Brian Vincent</author> <issue num="96" date="26 May 2001 00:00:00 -0800" /> <intro> <p>This is the 96th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).</p> </intro> <stats posts="79" size="218" contrib="26" multiples="13" lastweek="14"> <person posts="12" size="27" who="Gerard Patel <gerard.patel>" /> <person posts="10" size="23" who="Alexandre Julliard <julliard>" /> <person posts="10" size="32" who="Francois Gouget <fgouget>" /> <person posts="9" size="19" who="Ove Kaaven <ovehk>" /> <person posts="4" size="12" who="Ian Pilcher <ian.pilcher>" /> <person posts="4" size="14" who="Heiko Nardmann <h.nardmann>" /> <person posts="4" size="9" who="Steve Fox <stevefx>" /> </stats> <section title="Wine.conf Addition" subject="Configuration/Announce" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0192.html"; posts="5" startdate="22 May 2001 00:00:00 -0800" enddate="23 May 2001 00:00:00 -0800" > <mention></mention> <mention>Mike Bond</mention> <p>Eric Pouech posted the following announcement concerning the addition of a new section to the wine.conf configuration file and some new registry keys:</p> <quote who="Eric Pouech"> <p> with today's CVS commit (for those who stay up to date with the latest developments), you'll have to modify your Wine configuration to reflect the changes.</p> <p>First of all, your Wine configuration file now needs a WinMM section containing the following:</p> <p><ul><code>[WinMM]<br /> "Drivers" = "wineoss.drv"<br /> "WaveMapper" = "msacm.drv"<br /> "MidiMapper" = "midimap.drv"<br /></code></ul></p> <p>Not adding this will print the following message</p> <p><ul><code> > You didn't setup properly the config file for the Wine multimedia modules.<br /> > Will use the hard-coded setup, but this will disapear soon.<br /> > Please add a WinMM section to your Wine config file.<br /> </code></ul></p> <p>Note that the above configuration will be shortly required, so don't wait before setting your configuration up</p> <p>Next, you have also to add a key to your registry. To do so, create a sample file (let's call it foo) containing the following text:</p> <p><ul><code> [HKEY_LOCAL_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap] 989041554<br /> "AutoScheme"=dword:00000000<br /> "CurrentInstrument"="#0"<br /> "UseScheme"=dword:00000000<br /></code></ul></p> <p>then goto the <wine>/programs/regapi and compile the program the run:</p> <p><ul><code>regapi setValue < foo</code></ul></p> <p>that's it</p> <p>Not applying the key in the registry will result in various errors in MIDIMAP_ functions (mainly if Wine is set up to use a native Windows system)</p> <p>Maintainers are welcome to update theirs packages accordingly (default values are in documentation/samples/config & winedefault.reg)</p> <p>Detailed information is available in documentation/multimedia.sgml.</p> </quote> <p>Mike Bond pointed out it should be <code>[HKEY_CURRENT_USER]</code> rather than <code>[HKEY_LOCAL_USER]</code>.</p> <p>In addition, Alexandre thought that it would be a bad idea to have the hard-coded setup disappear. He thought it wouldn't be very user friendly to make these values go away when Wine had a reasonable chance at guessing the configuration.</p> </section> <section title="What About XP?" subject="What about XP?" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0137.html"; posts="2" startdate="18 May 2001 00:00:00 -0800" enddate="20 May 2001 00:00:00 -0800" > <mention></mention> <p>A question was posted wondering what will happen with Wine with regards to Microsoft's latest XP incarnation. Basically this comes down to new applications taking advantages of additions to the Windows API. In the past a lot of vendors have avoided immediately using new stuff because they would break backwards capatibility with the older versions of Windows that users are inevitably using. Francois Gouget summed it up by saying:</p> <quote who="Francois Gouget"><p> I understand what you mean, but nope, I think we don't really care about XP.</p> <p> Sure, one day we'll have to implement whatever new APIs are in XP, but this will come when an application needs it.</p> <p> The Wine development is application driven, not Windows driven: what we want is for applications to run in Wine and the release of a new version of Windows changes nothing for the 99.99999% of applications that are already out there (and solitaire XP is not the most important app although I quite sure that it will be one of the first XP apps to run).</p> <p> Now, if you were to ask about Office XP (if such a thing exists)...</p> </quote> <p>In regards to Office XP, here's a little <a href="http://www.zdnet.com/products/stories/reviews/0,4161,2694583,00.html";> info</a> on it. </p> </section> <section title="Installing Office the Wrong Way" subject="problem starting winword 97SR2" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0170.html"; posts="7" startdate="21 May 2001 00:00:00 -0800" enddate="22 May 2001 00:00:00 -0800" > <mention></mention> <p>Heiko Nardmann was trying to get Office up and running by copying some of the required files and creating the registry entries. In particular he was copying winword.exe, mso97.dll, and wwintl32.dll. By trial and error he was putting files into place as the app required them. In addition he added a font alias to take care of the annoying message you get upon starting office, namely with <code>"Alias0" = "Tahoma,-adobe-helvetica-"</code>. But as James Juran pointed out, that doesn't always work:</p> <quote who="James Juran"><p> You will need to run the installation program or manually copy all the registry entries from an existing installation. The Microsoft Office applications put tons of stuff in the registry which is necessary for them to run.</p></quote> </section> <section title="Differences in FreeType Versions" subject="wineps include fix" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0156.html"; posts="5" startdate="20 May 2001 00:00:00 -0800" enddate="20 May 2001 00:00:00 -0800" > <mention></mention> <mention>David Hammerton</mention> <p>David Hammerton submitted a small change because the version of FreeType on his system had a different name for the header file. He was unable to #include <code><freetype/ftnames.h></code> because on his system it was <code><freetype/ftsnames.h></code>. After looking into the problem Ian Pilcher realized the difference in names between what he and David were using:</p> <quote who="Ian Pilcher"><p> I just checked, and they appear to have changed the name between 2.0.1 and 2.0.2. I can't help wondering how the FreeType people expect any- one to keep up with this.</p></quote> <p>I guess I can do an autoconf check specifically for 2.0.1. I simply refuse to try to #ifdef every point release of FreeType. Down that road lies madness.</p> </section> <section title="DLL Separation" subject="DLL separation and PROFILE functions" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0113.html"; posts="2" startdate="15 May 2001 00:00:00 -0800" enddate="16 May 2001 00:00:00 -0800" > <mention></mention> <mention>Ove Kåven</mention> <p>I won't comment on this too much because the two emails pretty much speak for themselves. If you've heard this term of "DLL separation" in past issues this kind of summarizes an example. Ian Pilcher wrote to the list with:</p> <quote who="Ian Pilcher"><p> DLL separation has been mentioned quite a few times on this list (usually as the ultimate solution to a problem), but I don't think I've ever seen it actually defined. Based on my own misadventures in this area, however, I would hazard a guess that is essentially the conversion of all inter-DLL function calls from OS-based dynamic linking to the Wine DLL loading mechanism.</p> <p>Under this assumption, adding 'IMPORTS = ntdll' to a DLL's Makefile.in file (in order to use one of the PROFILE functions) seems like a definite step backwards. I think that the proper approach is to add the function in question to dlls/ntdll/ntdll.spec and make sure that the importing DLL lists ntdll.dll as an import in its own SPEC file.</p> <p> All of which is wonderful until you consider the following in ntdll.spec:</p> <p><ul><code>##################<br /> # Wine extensions<br /> #<br /> # All functions must be prefixed with '__wine_' (for internal functions)<br /> # or 'wine_' (for user-visible functions) to avoid namespace conflicts.<br /> </code></ul></p> <p>This would seem to indicate that the PROFILE functions (in files/profile.c) need to have their names changed before they are exported. Is this an appropriate time to go crazy with grep and sed? (For example, PROFILE_EnumWineIniString would become __wine_EnumIniString.)</p></quote> <p>Ove Kåven replied that DLL separation is <quote who="Ove Kaaven">needed to be able to have Wine DLLs and Winelib apps be able to seamlessly import and use native PE DLLs</quote>. He also added:</p> <quote who="Ove Kaaven"><p> The profile functions are not exported and you should not use them. If you're trying to access the config file, use the registry API instead; for an example, see what Alexandre did in dlls/x11drv/x11drv_main.c. You'll see the reason Alexandre changed the .wine/config file format to the registry format.</p> <p>You could use #defines in a .h file too, but you shouldn't add wine extensions without a *very* good reason. Alexandre has even advocated code duplication in some instances to keep DLL separation tight.</p></quote> </section> <section title="Wine Networking With SuSE and Mandrake Distributions" subject="Networking with Mandrake 8.0 and SuSE 7.1" archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0117.html"; posts="7" startdate="17 May 2001 00:00:00 -0800" enddate="21 May 2001 00:00:00 -0800" > <mention></mention> <mention>Gerard Patel</mention> <p>Steve Fox was wondering why networking in Wine no longer worked after he upgraded to Mandrake 8.0:</p> <quote who="Steve Fox"><p> I'm running Lotus Notes 5.04a under WINE with one of the January releases and its been working great for months. However, any release since February does not seem to do reliable networking on my Mandrake 8.0 system. I can occassionally actually get into my inbox and even open up a message, but I've never been able to read more than one.</p> <p>Some cow-orkers using this same setup on Redhat 7.1 do not have this problem, but others using SuSE 7.1 do too.</p> <p>Does anyone have any ideas why only networking would be affected and only on select distributions? It stumps me because all three mentioned distros use glibc-2.2 and gcc-2.96 (SuSE may use 2.95...not sure). On a related note, another cow-orker who is using Mandrake Cooker (development distro) and his own compiled kernel does not have this problem. I am on a token ring network, which I don't think should matter.</p></quote> <p>Rob Maurizzi said he had experienced the same problem with SuSE and their 2.2.18 kernel. However, if he compiled a stock kernel it worked ok. Gerard Patel mentioned that it would be better to try out a 2.4 kernel and work from there. But Steve couldn't try that with Mandrake's distribution because they didn't have the PCMCIA token ring patch applied in the standard distribution. However, he did try out the kernel from Mandrake's "Cooker" distribution and discovered it worked: <quote who="Steve Fox">This weekend I upgraded to Mandrake's 2.4.4 kernel from Cooker (since it fixed both my mouse and token ring) and suddenly this problem has gone away (using Notes 5.0.7 and wine-20010305).</quote></p> </section> <section title="Exposing Non-Windows Functions from DLL's" subject="Question on exposing non-windows functions from dlls..." archive="http://www.winehq.com/hypermail/wine-devel/2001/05/0126.html"; posts="7" startdate="18 May 2001 00:00:00 -0800" enddate="18 May 2001 00:00:00 -0800" > <mention></mention> <mention>Ove Kåven</mention> <p>Mike Bond was wondering how to go about exposing functions:</p> <quote who="Mike Bond"><p> I just submitted a patch to wine-patches that provides the implementation of spawnl and spawnlp. I had been hoping to implement execl and execlp as well but found that the underlying functionality that I would need is not exposed outside scheduler/process.c. My question is what guidelines are there, if any, are there to exposing non-win functions, such as exec_wine_binary in scheduler/process.c?</p> <p>Also, from just a cursory glance at exec_wine_binary that I may need to wrap it to do some of the work that fork_and_exec and PROCESS_Create are doing, such as calling DOSFS_GetFullName. I'm not sure what, if anything, the server would need to know about this.</p></quote> <p>Ove Kåven replied, <quote who="Ove Kaaven"> The guidelines are pretty simple and easy to understand: with a very few *very* exceptional exceptions, never ever expose them. And definitely never to non-core DLLs such as msvcrt - there's no reason an application DLL like msvcrt can't be implemented on top of the Win32 API the same way it's implemented on Windows.</quote></p> <p>Mike wondered how to go about implementing those functions using the standard Win32 API. He wanted to know how to go about loading and running an image in-process. Ove reminded him to be careful of assuming that was what was actually happening (Unix semantics are not the same as Microsoft's). Similarly Alexandre mentioned:</p> <quote who="Alexandre Julliard"> <p>You cannot do this with the Win32 API, that's true. And since the native msvcrt is implemented on top of the Win32 API, this means that msvcrt exec functions cannot possibly behave exactly like the Unix ones.</p> <p>What you must do is find out the expected behavior of the msvcrt exec, and implement the same behavior; you should then be able to do this using the Win32 API, since this is how the native one does it.</p> </quote> <p>Mike wrote back:</p> <quote who="Mike Bond"> <p> I have gone ahead and implemented most of the exec variants as described just terminating the previous process, the internal spawn implementation already provided a flag to accomplish this easily.</p> <p>On the question of determining compatibility, what methods are we "allowed" to persue? For instance, I created a small test app for the exec variants, tested it under Windows NT then under Wine. I would hope this is a valid method, but with the way the lawyers work, it's sometimes hard to tell.</p> <p>As a note, it seems NT is doing the same thing as they end up with different address spaces and pids after execl.</p> </quote> <p>And with in regards to the old argument that goes into the extent to which backwards engineering is legal. Ian Pilcher responded with:</p> <quote who="Ian Pilcher"> <p>Big disclaimer: <b>I am not a lawyer;</b> if you end up in court because you pay attention to anything I say, that's just too darn bad.</p> <p>It depends on which country you're in. What you've done is classic "black box" reverse engineering, which has historically been protected by the U.S. legal system. Even the DMCA protects it as long as you don't decrypt anything.</p> <p>UCITA in its unaltered form, however, legitimizes all those software license agreements that U.S. courts have found unenforceable. So I guess it's starting to depends on what state you're in if you're in the U.S.</p> </quote> </section> </kc>
![http://www.gamespy.com/asp/image.asp?/articles/may01/wine/1.jpg"](http://www.gamespy.com/asp/image.asp?/articles/may01/wine/1.jpg"){kind=link}