WWN #93 - #96
Brian Vincent
vinn at theshell.com
Mon Jun 9 00:31:26 CDT 2003
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
-------------- next part --------------
<?xml version="1.0" ?>
<kc>
<title>Wine Traffic</title>
<author contact="mailto:brianv at 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>
-------------- next part --------------
<?xml version="1.0" ?>
<kc>
<title>Wine Traffic</title>
<author contact="mailto:brianv at 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>
-------------- next part --------------
<?xml version="1.0" ?>
<kc>
<title>Wine Traffic</title>
<author contact="mailto:brianv at 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>
-------------- next part --------------
<?xml version="1.0" ?>
<kc>
<title>Wine Traffic</title>
<author contact="mailto:brianv at 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>
More information about the wine-patches
mailing list