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 line:
[windows]
device=...
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:
notepad.exe
mspaint.exe
winhelp.exe
uedit32.exe

Printing now works out of the box, if you have [afmdirs] set up and .afms available.

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?

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:

• shift the x11drv and wineps over to using the DDK Font Engine APIs that are currently just stubs.
• Implement a FreeType font driver that links to Freetype and uses the FreeType APIs for all font metrics data as well as rasterization.
• Implement an X11-dependant font driver in the Font Engine to rely on as a backup if FreeType isn't available.

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.

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:

$ wine c:\\windows\\sol.exe
No built-in EXE module loaded! Did you create a .spec file?

Obviously sol.exe doesn't need a .spec file to run. When/Why do I get such an error?

right there on the WineHQ site:

• there's a big 'Help!' heading with 'WINE Documentation and Support, FAQ and HOWTO.' as the subtitle. Click on it.
• there, the first item is 'Official Wine documentation', click on it
• and then you have the choice of:
• the 'Wine User Guide' http://www.winehq.com/Docs/wine-user
• the 'Winelib User Guide' http://www.winehq.com/Docs/winelib-user
• the 'Wine Developers Guide' http://www.winehq.com/Docs/wine-devel
• the 'Wine Packagers Guide' http://www.winehq.com/Docs/wine-pkg/

It should even be up to date but I'm not entirely sure. If not then something must be done about it.

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?

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...

For the curious:
Snooping on his conversation using google.com, I see it's patent number 5297284 he's worried about.

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

Hmmm - a few points to consider:

1. 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.
2. 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.
3. At least some of the g++ people seem to know something about this patent. There's a small thread here:

   http://gcc.gnu.org/ml/gcc/1999-08/msg00862.html And there's some further discussion wrt the ia64 C++ abi here:

   http://reality.sgi.com/dehnert_engr/cxx/cxx-closed.html

4. 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:

   http://planetmirror.com/pub/gcc/old-releases/gcc-1/?N=D

Anyhow, this is just from a very cursory analysis, but I'd say that the Mainsoft FUD is just that: FUD.

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.