Table Of Contents
|2.||29�Apr�2001�-�30�Apr�2001||(9 posts)||Font Handling Issues|
|3.||1�May�2001�-�2�May�2001||(5 posts)||Wine and NetBSD|
|4.||1�May�2001�-�2�May�2001||(7 posts)||Wine Manuals|
|5.||18�Apr�2001�-�1�May�2001||(18 posts)||Update: InstallShield and OLE Question...|
|6.||1�May�2001�-�2�May�2001||(7 posts)||Library Freeing|
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).
Mailing List Stats For This Week
We looked at 58 posts in 172K.
There were 23 different contributors. 11 posted more than once. 10 posted last week too.
The top posters of the week were:
27�Apr�2001 (2 posts) Archive Link: "CUPS Support"
People: Gerard Patel,�Marcus Meissner,�
Gerard Patel, quite rightly, pointed out that I had missed an interesting CVS commit last week. In particular Gerard wrote, " 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 :-/ "
That patch by Marcus Meissner was posted with the following note:
I have implemented CUPS support in WINE.
Rerun autoconf ; autoheader -l include
The only dangerous option currently is that in win.ini it modifies the
marking the default printer.
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.
I have also added some gotos to get rid of the huge unnecessary code duplication in PSDRV_FindPrinterInfo().
I have tested it with:
Printing now works out of the box, if you have [afmdirs] set up and .afms available.
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.
2. Font Handling Issues
29�Apr�2001�-�30�Apr�2001 (9 posts) Archive Link: "TrueType font metrics for PostScript driver"
People: Ian Pilcher,�Gavriel State,�Alexandre Julliard,�
Ian Pilcher was working on on the Postscript driver and ran into the following dilemna:
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.)
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.
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.)
Anyone have any objections to using this approach as a interim measure?
Gavriel State responded to this by describing a general framework for working with fonts:
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.
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.
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.
What I'd love to see happen with fonts in Wine is this:
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.
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.
He also asked, " What do you find objectionable about making wine work more closely with FreeType? " Ian replied, " Absolutely nothing. I just don't think the immediate benefit of getting at TrueType encodings justifies creating the dependency at this time. " Ian also agreed with Gavriel's ideas, but pointed out that for now he was just interested in getting the driver Unicode-enabled.
Alexandre Julliard wondered though, " 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. " Ian responded, " 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. "
Alexandre didn't seem to mind putting the calls right within the driver, noting that " 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. "
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.
3. Wine and NetBSD
1�May�2001�-�2�May�2001 (5 posts) Archive Link: "Wine and NetBSD"
People: Bang Jun-Young,�,�Francois Gouget,�Eric Pouech
Bang Jun-Young posted an interesting message to the list:
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.
The most serious problem occurs, however, whenever I try to run a Windows binary with it:
Obviously sol.exe doesn't need a .spec file to run. When/Why do I get such an error?
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.
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.
4. Wine Manuals
1�May�2001�-�2�May�2001 (7 posts) Archive Link: "Script to get committed patches"
People: Eric Pouech,�Francois Gouget,�,�Gerard Patel
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, " 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) " .
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:
right there on the WineHQ site:
It should even be up to date but I'm not entirely sure. If not then something must be done about it.
There's a lot of interesting reading in there for users and developers alike.
5. Update: InstallShield and OLE Question...
18�Apr�2001�-�1�May�2001 (18 posts) Archive Link: "Re: InstallShield and ole question..."
People: Dan Kegel,�Jeremy White,�Gavriel State,�
I was a bit premature in covering the InstallShield thread a few weeks ago Issue�#92, Section�#2� (17�Apr�2001:�InstallShield and ole question) . 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.
Dan Kegel pointed to the FreeDCE project:
http://freedce.sourceforge.net/ 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 http://linas.org/linux/corba.html
I wonder if that might not be useful here?
Jeremy White felt there were a lot of legal implications to consider:
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.
The upshot of my comment is that it's critical that we use our own marshalling/ipc protocol.
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...
Dan Kegel provided some more information:
For the curious:
Snooping on his conversation using google.com, I see it's patent number 5297284 he's worried about.
Gavriel State pointed out the following problems with the relevancy of the patent:
Hmmm - a few points to consider:
http://gcc.gnu.org/ml/gcc/1999-08/msg00862.html And there's some further discussion wrt the ia64 C++ abi here:
Anyhow, this is just from a very cursory analysis, but I'd say that the Mainsoft FUD is just that: FUD.
6. Library Freeing
1�May�2001�-�2�May�2001 (7 posts) Archive Link: "FreeLibrary() library freeing"
People: Andreas Mohr,�Alexandre Julliard,�
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:
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.
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).
Besides, Musicmatch Jukebox used zillions of MB (yes, that's a leak for you) due to that Wine "feature".
I for one would truly like to see it fixed ASAP.
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.
The main problems right now center on various versions of glibc and the fact that the DLL separation is continuing. Alexandre responded with, " Agreed; I have uncommented the VirtualFree, and you are hereby volunteered to track down and fix any crash caused by this ;-)"
Some discussion went back and forth concerning potential problems this might cause with older glibc versions. Alexandre clarified the change with, "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."
Sharon And Joy