World Wine News

Beginning December, customers of SUSE LINUX 9.0 Personal or Professional will be able to purchase an add on called SUSE LINUX Wine Rack. For $ 39.99 you will get WineX, CrossOver Office, CrossOver Plugin and the game Marble Blast.

I know we've discussed this before, but I feel things have changed and it's worth another try :) Namely, have the winehq.org name be the default one. It seems virtually everybody (except you) prefer the .org name over the .com name, it's way more community friendly, and it seems to be the default one on WineHQ for a while, without any negative side effects. As we are gearing up for the .9 release, I feel we should clean up this annoying bit. Quite frankly, I think that the .com suffix raises all sorts of nasty questions that are better avoided.

We wouldn't be the first project to have two related names for their site, and I see no potential danger in making the change, just an upside. Please consider it.

ChangeLog

Make the winehq.org domain the official one.

This time, I actually installed a spell checker. Believe it or not. http://www.shemesh.biz/wine holds the PDF and the openoffice of the slides. I'm hoping this is the last draft. You know you've stayed up for too long when you start putting stuff into your sig.

A huge thanks to everyone for their input.

Photoshop plugins are DLLs, with all calls from the host using 1 entry point ( main ). But hopefully, we won't have to look at the P$ internals, because: The GIMP for Windows has partial support for P$ plugins; the plugin host being pspi.exe (source is available, but you need the SDK's header files to compile it). My thought is to look into altering pspi to work with the UNIX gimp

By "partial support", I mean it handles many PiPL filter plugins (.8BF). To my knowledge, it does not support pre-P$ v2.5 plugins (PiKI), nor does it support the Automation, Selection, or Color Picker modules that are sometimes a part of P$ plugins. Also some filter functionality is missing (likely missing the system and Adobe color pickers, for example). Otherwise it works great (at least partial success with Flaming Pear, Xeno's (compiled FilterMeister) filters, Luce, Stroik's Rubber, etc). Notable for not working is Nic's various filters (which work in a checkboard fashion, some regions with filter applied/applied only partially, some without).

Based on the date of the pspi source on his webpage, I'd bet he used either the 5.x SDK or the 6.0 SDK.

In pspi's README, he says:

"It might be possible to make it work also on i386 Unixes (Linux, FreeBSD, Solaris), using Wine (www.winehq.org) to aid in running the code in the Photoshop plug-in. (Or some similar commercial software.) (No, I have no idea how this would actually be implemented, it's just my intuition that tells me it might be possible to attach a Windows DLL to a Unix process using Wine.)"

"Pspi also now uses g_markup* functionality to parse its settings file. I don't think GLib 1.2.x had that, so if you really intend to run this on Unix through Wine, you have to extract the g_markup* functions from GLib 1.3.x."

"Pspi requires a GIMP that implements the init_proc functionality in the GimpPlugInInfo struct. As of now (2001-12-20), only GIMP 1.2.3 on Windows does that. For the patch to GIMP 1.2.3 to implement it, see http://bugzilla.gnome.org/show_bug.cgi?id=66859 ."

[see that thread; GimpPlugInInfo is documented in /build-dir/devel-docs/libgimp/html/libgimp-gimp.html#GimpPlugInInfo, but it is not the solution Tor used for gimp-pspi-1.0.2, which is the latest I could find]

So, a (the) big question is, how can we get this windows app to compunicate with UNIX processes?

Well, indeed, this is the $10000 question. I don't much care at this point whether Gimp can work with the Plugins or not, what I care about is to export their interface in a an ELF library so that Unix processes can call them. This is non-trivial, so the first question is:

What is the Plugin interface?

Well! It would do this project no good if I were to break the agreement I made with Adobe in regards these SDKs (I have the AE and Premiere ones too). So, until I get a response from Adobe or their maillist (I lost that agreement), I won't directly provide any details from the SDK itself. There's still plenty of information available online, though.

To answer your question, check out this link: http://partners.adobe.com/asn/tech/plugin/index.jsp

The PICA API document is still freely available, and is a pie-in-the-sky review of plugin programming (containing none of the headers, etc, that one needs to actually build a plugin, or investigate specifics). Section 2.3 describes the interface.

The actual prototype for the main entry point is not in this section (of course, it is in the API guide in the SDK), but it is a pretty good and basic read.

You'll also want to review the gimp-pspi (v1.0.2) source... it's available at Cinepaint's sourceforge downloads page, among other sites. The /pspi-source-root/src/pspi.c has the struct for the entry point.

We certainly won't get 100% compatibility: some/maybe many P$ filters call other DLLs ... not just windows DLLs but their own ; possibly to extend their functionality, but likely as a part of copy protection.

But the idea of implementing the entirety of interaction between host and plugin first seems a bad way to go about this (don't you think?). I would suggest we build a minimal DLL that is interactive (returns ++integer), and work on the UNIX end and Wine-dows host application from there. Afterwards, we can come back and make the Adobe plugin host... this has some notable advantages:

• not quite so dramatically "non-trivial"
• we would have all the source code for both the host and the module
• we can modularize the interface, for different windows-linux interaction.
• this would allow us to 'pitch' a working prototype to other projects' programmers (ie, we could get more resources to attack the problem)

Either way, is fine really ... I'll happily follow your lead. Just my 2 cents.

I'm looking at the loader section of MPlayer now ... (all docs plus the archive still barely give you any idea what it is they are doing) They have what is called mini-wine (in the list it was referred to as this, at least)

Since the documentation is so sparse, I was going to look around in other projects. Xine uses their win32 stuff, so I'll start looking there. In the meantime, any other projects you can think of that do this sort of thing? (ndiswrapper is a kernel module).

Just for some basic info ... MPlayer fakes responses to system API on a per-codec-DLL basis, which means, for each new DLL, they add the necessary callbacks. I think this could eventually wind them into trouble if the dlls they want to use grew in the wrong way. But, the advantage, they don't have to process a video stream through a full wine, which gives them speed enough to make the DLLs useful.

I don't know if speed will be such an issue for my purposes; I'm not outputting unencoded video ... hopefully this flexability (a full wine) lends enough compatibility that I only need .specs for supporting DLLs for the plugins. Since their port includes the interface to the DLLs, it's still another resource to look at.

That brings up the second question I have ... I'm not a windows person. Is there some tool that can query a DLL, kinda like objdump?

Apologies for the size of the patch, I didn't see any useful way to shrink it.

ChangeLog: implement rather a lot of Netbios()

I could say a bit more than that, but it wouldn't mean much to most people. Where there was nearly none, now there is some.

Saying a little more may help.

What's needed to test you patch? What programs show improvement? Any configuration items needed in a .ini file or the registry?

Just some thoughts.

And thanks for your work :-)

Good questions. I have little test programs that I've been using, but NetBIOS is hard to test without knowing something about your network configuration, so they're not much use for netapi32/tests.

I don't know of any programs that work now that didn't, except what I'm working on: I'm trying to implement the Network Neighborhood. I've been tweaking WINE's SMB code to use Netbios() rather than implementing the netbios-over-tcpip stuff directly. That work isn't done yet, watch this space for more :)

There was an article a while back linked here about some HP management program (for their NAS appliance) that didn't discover their box under WINE because of lack of NetBIOS support. I suspect this may now work, but I don't know.

Currently the default printer is read from win.ini - setting this is annoying and doesn't work out of the box. I think it'd make more sense to have it also in the wine configuration, so if no win.ini string is retrieved it'll still work. I have an app here that dies if there is no default printer. Is it acceptable to make a fallback in the registry/config branch? The default would be "Wine Postscript Driver", though I guess we could be clever - enumerate the printers actually installed and pick the first. I don't know enough about printing to say. Huw?

We should be doing this already. If cups is installed then we use the cups default, otherwise for printcap systems we use the PRINTER env variable or if that isn't set the first entry in /etc/printcap . Take a look at dlls/winspool/info.c

Well, at least in the copy I have WINSPOOL_EnumPrinters has this:

/* PRINTER_ENUM_DEFAULT is only supported under win9x, we behave like NT */
if(dwType == PRINTER_ENUM_DEFAULT)
return TRUE;

ie it's a no-op. Bear in mind I don't have any printers installed, the only driver available is the Wine PostScript driver so neither CUPs nor printcap is set up.

The reason I've been so quiet on the winecfg front lately (ignoring university) is because I'm working on porting an app commercially. As a part of that process, I'm generating patches and committing to a private branch. However, I'm not sure how best to manage patch submission. There are a few alternatives:

a) Just keep them "secret" until I get paid, at which point I send them in all together. Pros: Simple, Cons: people might duplicate my work.

b) Notify the Wine community of what the patches do/are but keep their contents secret. Pros: Less chance of duplication, Cons: if people need the patch, knowing I have one won't be much use and it'd be hard to notify people without spamming the mailing list. Not enough people monitor bugzilla for me to be sure it'd work.

c) Post them all to wine-devel but under a license that prevents them being merged unless you get a special exception from me. That way people can see, peer review the patches etc but they don't get committed. Of course, as this is just supposed to be insurance anyway, that seems a bit worthless.

d) Say "screw it", submit as usual and just hope I'm dealing with trustworthy people (unfortunately no contract in this case, the job isn't really big enough to warrant one).

Does anybody have any experience of this? What is the best approach?

Don't do that. Patches that aren't released under a free license should be treated as if they didn't exist; we don't want to discourage people from working on something just because someone has a patch that may or may not be released at some indeterminate point in the future.

This may cause some duplication, but it's always better to have two implementations of something than to risk having none at all if it turns out that you can't release the patch in the end.

Also make sure that you get the customer's agreement before releasing anything; most likely if you are doing work for hire they own the copyright and you can't release it without their permission (of course once they distribute the result it has to be LGPL, but they don't necessarily want to distribute it).

I am told this is what the Internet Explorer icon looks like after winetests.exe is run. Strange eh?

http://vmlinux.org/~jakov/crazy-icon.jpg

It does on my W2K SP4. At random the icon cache gets mixed up and suddenly a lot of icons don't match anymore. It is especially bad with Icon Overlays.

I use Tortoise CVS, a CVS shell extension, and their newest version has a special command built into their context menu to rebuild the icon cache. I do have some suspicions that Tortoise CVS may be responsible for some of the icon distortion but it happens regularly even when using normal MS applications.

I decided to give KDE 3.2-beta1 a try (just for reference I'm using the Gentoo ebuild), and found a problem with compiling winearts

under KDE 3.1 "artsc-config --cflags" gives me

-I/usr/kde/3.1/include/artsc

but under KDE 3.2-beta1 I get

-I/usr/kde/3.2/include/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include

which causes a problem because this value is passed to makedep during compilation, which fails with "Unknown option '-pthread'"

Quick and dirty patch:

--- tools/makedep.c 2003-11-27 20:06:41.597740232 +0100
+++ tools/makedep.new 2003-11-01 00:05:38.000000000 +0100
@@ -500,6 +500,8 @@
    case 'I':
       if (opt[2]) add_include_path( opt + 2 );
       break;
+   case 'p':
+      break;
    case 'C':
       if (opt[2]) SrcDir = opt + 2;
       else SrcDir = NULL;