- Wine-Devel - list.winehq.org

Wine and raw printing
by André Carvalho June 21, 2005

June 21, 2005

I posted the same message on wine-user list , but got no help. Hi, I was wondering if someone could help me on this issue. I use a windows program that print direct to the printer, but it uses the printer from the printer list, it doesn't use the port directly. On Windows, to use the program I have to install a "Generic / Only Text" printer to work. The program runs on wine without problems. The only problem is to print. I created a raw printer in CUPS, but when I select the printer in the program, wine still uses the WinePS driver and generate a PS, giving me an error on the printer, of course. I tried to install a driver tty.drv on wine but couldn't get it to work. Is there a way to disable WinePS ? or another way to get the program to print ? Thanks Andre Carvalho

4 5

unicode.h and -Wcast-qual
by Stefan Huehner June 21, 2005

June 21, 2005

Hi, i am currently trying to fix the -Wcast-qual warnings. In include/wine/unicode.h there a 4 function: static inline int strncmpW( const WCHAR *str1, const WCHAR *str2, int n) static inline WCHAR *strchrW( const WCHAR *str, WCHAR ch ) static inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch ) static inline WCHAR *strpbrkW( const WCHAR *str, const WCHAR *accept ) whose signatures forces us to discard the const of an parameter while returning it as the function value. Compiling with -Wcast-qual gives (correctly) this warning: ../../include/wine/unicode.h:218: warning: cast discards qualifiers from pointer target type Together these four functions account for a total of 1400 (!) warnings. In samba_4 sourcecode i discovered the following macros, which are apparently a hack but silences these warnings: #define discard_const(ptr) ((void *)((intptr_t)(ptr))) #define discard_const_p(type, ptr) ((type *)discard_const(ptr)) an crude proof of concept is attached as a patch. I am not sure how portable this solution is... Any comments are welcome... Regards, Stefan

4 3

Re: World of Warcraft
by Aric Cyr June 20, 2005

June 20, 2005

> > fixme:opengl:wglQueryPbufferARB unsupported WGL_PBUFFER_LOST_ARB > > (need > > glXSelectEvent/GLX_DAMAGED work) > > Arg, > i didn't expect this fixme :( I don't think we have to worry about this fixme. We can always return GL_FALSE, since that is the way the OpenGL surfaces were created. >From http://oss.sgi.com/projects/ogl-sample/registry/SGIX/pbuffer.txt: If the GLX_PRESERVED_CONTENTS_SGIX attribute is set to False in <attrib_list>, then an "unpreserved" pbuffer is created and the contents of the pbuffer may be lost at any time. If this attribute is not specified, or if it is specified as True in <attrib_list>, then when a resource conflict occurs the contents of the pbuffer will be preserved (most likely by swapping out portions of the buffer to main memory). In either case, the client can register to receive a "buffer clobber" event which is generated when the pbuffer contents have been preserved or have been damaged. (See the event description.) So the fixme should be fixed to always return GL_FALSE I think. Also, there is an interesting workaround for the clicking problem as well on the Gentoo forums. Seems to be working for the majority of people (including myself). It seems to reaffirm that the problem is indeed the memory layout. http://forums.gentoo.org/viewtopic-p-2509340.html#2509340 -- Aric Cyr <acyr at alumni dot uwaterloo dot ca> (http://acyr.net) gpg fingerprint: 943A 1549 47AC D766 B7F8 D551 6703 7142 C282 D542

1 0

Mime type Desktop integration
by Stefan Dösinger June 20, 2005

June 20, 2005

Hello, I am working on a small tool which reads mime types and linked applications from the registry and generates .desktop files for the unix desktop. This integrates Windows Applications better into the native Desktop. I've written this code in the last days without much planning, so the code is quite a mess IMO. There are still things missing and a few bugs are left, but I thoght I show what I'm doing here. So, the usage: *Compile with 'make'. *You have to copy the winestart script somewhere in the path, otherwise you can't open any files *Specify the target path for the .desktop files in $WINEAPPLNKPATH. This tool will create a sub-directory where it will place the files. BUG: This directory has only read rights, and this causes a crash later. Up to now you have to give yourself +wx rights and run again *Copy the created .desktop files somewhere to your applink path(e.g. ~/.kde/share/applnk) or set $WINEAPPLNKPATH to ~/.kde/share/applnk. Your Desktop(tested with KDE) should read this files and assign them to the file types. So for example, if you have Internet explorer installed you get a new "htmlfile" application which opens the file in Internet Explorer if you really want this. Missing things *Get icon extraction working. Code taken from winemenubuilder, but it fails on many files, and it can't extract 32Bit icons. *Mime type exportation: Currently only Application entries are created, but no mime types. If the Desktop doesn't know the mime type, the Application is useless. *Rework some parts of the code and make it more Wine-Stylish(Heap...) *Integrate Unix apps into the Windows Registry. *Other things? Greetings, Stefan Dösinger

1 0

Using SVK and Subversion to manage distributed branches to Wine CVS
by Troy Rollo June 20, 2005

June 20, 2005

Over the past few weeks I have been experimenting with SVK and Subversion managing a handful of branches to Wine CVS, and it appears to be working well. The system is based on a "central" Subversion repository that mirrors the Wine CVS tree without any modifications (publicly readable at svn://wine-svn.troy.rollo.name/wine/wine/) and is kept up to date within a day or so. Branches are stored in separate Subversion repositories. I am finding this very convenient. If you have converted from CVS to Subversion on other projects, you are probably aware of the huge difference it makes. Adding SVK on top of Subversion is another giant leap when you have distributed development. In the case of Wine, however, with the CVS repository being read-only except to Alexandre, the difference between read-only CVS and the combination of Subversion and SVK is even more dramatic (I would compare it to the difference between chiselling documents into stone tablets and using a word processor). For anybody who is interested in moving their own Wine development to Subversion and SVK, there is a page on the Wiki describing what to do at <http://wiki.winehq.com/SVK>

2 1

Guild Wars
by cyrix12＠cox.net June 20, 2005

June 20, 2005

I'm back, and with another game that will (hopefully) be playable in wine soon. Guild Wars, another extremely popular MMORPG, is fairly close to working in wine right now (I'm running latest cvs). It installs flawlessly, opens to the login screen, and then crashes when it should be connecting to the server (much like WoW used to). Attached is a +opengl trace and a plain warn+dll,fixme+all trace. Hopefully that's enough info for now. Thanks as always, Darckness

5 7

Re: [PATCH] FCI work for cabinet.dll [cabinet-fci-patch-02c.diff]
by Alexandre Julliard June 20, 2005

June 20, 2005

"Gerold J. Wucherpfennig" <gjwucherpfennig(a)gmx.net> writes: > Please apply, it seems to be fine, so far. > > There is still some work to be done: > > - currently no support for big-endian machines > - the ERF error structure aren't used on error > - no real compression yet > - unknown behaviour if files>4GB or cabinet >4GB > - incorrect status information > - check if the maximum size for a cabinet is too small to store any data > - call pfnfcignc on exactly the same position as MS FCIAddFile in every case You should get rid of all the PFCI_INT macro uses, that's making the code really ugly and hard to read. You should do the cast once at the start of the function (preferably as part of the handle validation routine) and then pass around a pointer of the appropriate type. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Make Instruction Emulation Code More Tolerant of Bad Addresses
by Alexandre Julliard June 20, 2005

June 20, 2005

Robert Shearman <rob(a)codeweavers.com> writes: > Therefore this patch aids in debugging. It isn't perfect because of > x86's variable length instructions, but it is fairly unlikely that an > instruction will straddle a page boundary and the first page be > readable and the second not. Putting an exception handler around the whole function would probably be a better choice, this way it would catch data accesses too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Added XEmbed embedder support
by Dimi Paun June 20, 2005

June 20, 2005

On Mon, 2005-06-20 at 00:05 +0200, Jacek Caban wrote: > Hello. > > This patch adds support for XEmbed embedder > It implements most of it (remaining todos > are listed in comments of xembed.c). Cool stuff, I'm really excited about this work. Not to mention that this might prove useful outside of the MSHTML context. I will not comment on the fundamentals of the approach, that's more Alexandre's alley, but just a few style nits. > +struct xembed_list > +{ > + struct xembed_list *next; > + HWND hwnd; > +}; What about using the standard list from wine/list.h? > /* DIB Section sync state */ > @@ -590,6 +601,8 @@ enum x11drv_atoms > XATOM_XdndSelection, > XATOM_XdndTarget, > XATOM_XdndTypeList, > + XATOM__XEMBED, > + XATOM__XEMBED_INFO, > XATOM_WCF_DIB, > XATOM_image_gif, > XATOM_text_html, > @@ -649,6 +662,10 @@ struct x11drv_win_data > struct dce *dce; /* DCE for CS_OWNDC or CS_CLASSDC windows */ > HBITMAP hWMIconBitmap; > HBITMAP hWMIconMask; > + union { > + struct xembed_list *list; > + ULONG_PTR cnt; > + } xembed; > }; Do we really need the union? We're not that hard pressed for memory. What about just @@ -649,6 +662,10 @@ struct x11drv_win_data struct dce *dce; /* DCE for CS_OWNDC or CS_CLASSDC windows */ HBITMAP hWMIconBitmap; HBITMAP hWMIconMask; + struct xembed_list *list; + ULONG_PTR cnt; }; Also, instead of having explicit tests like these: > + if(data->xembed.cnt) Maybe we can have a BOOL win_has_embedded_children(struct x11drv_win_data *data) function to make it more explicit what we're testing for. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

Re: [Patch] winsock.h inclusion
by Alexandre Julliard June 20, 2005

June 20, 2005

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > Alexandre, > > Using the current CVS on Darwin/Mac OS X, there are still compilation > errors related to winsock.h inclusion. The error was: > > ../../../include/winsock.h:414: error: redefinition of 'struct timeval' > > My solution is to include "wine/test.h" after every other header. You should fix wine/test.h and/or winsock.h to work properly in all cases. Otherwise the problem will keep coming back. -- Alexandre Julliard julliard(a)winehq.org

1 0