August 2005 - Wine-Devel - list.winehq.org

Re: Wine printer configuration

by Detlef Riekenberg

Am Freitag, den 05.08.2005, 16:07 +0200 schrieb Andreas Mohr: > > My problem is now that because wine is running on the server we had to > > configure the 350 IP based printers also at the server side. > > Can we filter out the printer for location X if there is a connection from > > location X? so that they only see that printer that is located in their > > location and not the other 349 printers. I doubt that it is possible but > > I have to figure out a way to fix it. Just to make sure ... - One Server with Wine and 350 Clients? - Every Client has a local Printer? - OS and Printing-System on the Clients? - OS and Printing-System on the Server? winspool.drv (wine) loads all local Printer (from CUPS and from /etc/printcap) every Time, a new Process is attached to the DLL. wspool.c: DllMain -> info.c:WINSPOOL_LoadSystemPrinters(void) Thats not fast/useful for such huge number of printers. Many Printing-Functions are incomplete and even fixed to WINEPS.DRV I'm working on this in my free time. -- By By ... ... Detlef

Aug. 6, 2005

Re: compile error in current cvs

by Jacek Caban

Jacek Caban wrote: > Hello. > > Stefan Leichter wrote: > >> Am Freitag, 5. August 2005 09:05 schrieben Sie: >> >> >> >> Hello Mike, >> >> after removing the link /usr/include/libxml >> >> my config.log has >> ac_cv_lib_xml2_xmlReadIO=no >> >> the patch fixes the problem with the missing header but compiling >> fails still with: >> >> >> > Attached patch is the correct solution. > > Changelog: > Fixed msxml compilation when libxml is not available. > Ops, I forgot to attach the patch... Index: dlls/msxml3/element.c =================================================================== RCS file: /home/wine/wine/dlls/msxml3/element.c,v retrieving revision 1.1 diff -u -p -r1.1 element.c --- dlls/msxml3/element.c 3 Aug 2005 10:58:47 -0000 1.1 +++ dlls/msxml3/element.c 5 Aug 2005 07:32:04 -0000 @@ -38,6 +38,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(msxml); +#ifdef HAVE_LIBXML2 + typedef struct _domelem { const struct IXMLDOMElementVtbl *lpVtbl; @@ -566,3 +568,5 @@ HRESULT DOMElement_create( IXMLDOMElemen return S_OK; } + +#endif Index: dlls/msxml3/msxml_private.h =================================================================== RCS file: /home/wine/wine/dlls/msxml3/msxml_private.h,v retrieving revision 1.2 diff -u -p -r1.2 msxml_private.h --- dlls/msxml3/msxml_private.h 3 Aug 2005 10:58:47 -0000 1.2 +++ dlls/msxml3/msxml_private.h 5 Aug 2005 07:32:04 -0000 @@ -21,7 +21,7 @@ #ifndef __MSXML_PRIVATE__ #define __MSXML_PRIVATE__ -#ifdef HAVE_LIBXML_PARSER_H +#ifdef HAVE_LIBXML2 #include <libxml/parser.h>

Aug. 6, 2005

Re: compile error in current cvs

by Jacek Caban

Hello. Stefan Leichter wrote: >Am Freitag, 5. August 2005 09:05 schrieben Sie: > > > >Hello Mike, > >after removing the link /usr/include/libxml > >my config.log has >ac_cv_lib_xml2_xmlReadIO=no > >the patch fixes the problem with the missing header but compiling fails still >with: > > > Attached patch is the correct solution. Changelog: Fixed msxml compilation when libxml is not available.

Aug. 6, 2005

Re: compile error in current cvs

by Stefan Leichter

Am Freitag, 5. August 2005 09:05 schrieben Sie: > >>>>current cvs does not compile for me. Im on SuSE 9.0 > >> > >>In Gentoo you need to create link: > >>/usr/include/libxml -> /usr/include/libxml2/libxml > > Please try the attached fix, and let me know if it works... > > Also check your config.log is as follows: > > bash-3.00$ grep ac_cv_lib_xml2_xmlReadIO config.log > ac_cv_lib_xml2_xmlReadIO=yes > > I guess it will be "no", as some older versions of libxml2 don't have > xmlReadIO. > > thanks, > > Mike Hello Mike, after removing the link /usr/include/libxml my config.log has ac_cv_lib_xml2_xmlReadIO=no the patch fixes the problem with the missing header but compiling fails still with: gcc -c -I. -I../../../wine/dlls/msxml3 -I../../include -I../../../wine/include -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o element.o ../../../wine/dlls/msxml3/element.c ../../../wine/dlls/msxml3/element.c:45: error: parse error before "xmlDocPtr" ../../../wine/dlls/msxml3/element.c:45: Warnung: no semicolon at end of struct or union ../../../wine/dlls/msxml3/element.c:46: Warnung: type defaults to `int' in declaration of `domelem' ../../../wine/dlls/msxml3/element.c:46: Warnung: data definition has no type or storage class ../../../wine/dlls/msxml3/element.c:48: error: parse error before '*' token ../../../wine/dlls/msxml3/element.c:49: Warnung: return type defaults to `int' ../../../wine/dlls/msxml3/element.c: In function `impl_from_IXMLDOMElement': ../../../wine/dlls/msxml3/element.c:50: error: parse error before ')' token ../../../wine/dlls/msxml3/element.c:50: error: parse error before ')' token ../../../wine/dlls/msxml3/element.c: In function `domelem_AddRef': ../../../wine/dlls/msxml3/element.c:78: error: `This' undeclared (first use in this function) ../../../wine/dlls/msxml3/element.c:78: error: (Each undeclared identifier is reported only once ../../../wine/dlls/msxml3/element.c:78: error: for each function it appears in.) ../../../wine/dlls/msxml3/element.c: In function `domelem_Release': ../../../wine/dlls/msxml3/element.c:85: error: `This' undeclared (first use in this function) ../../../wine/dlls/msxml3/element.c: At top level: ../../../wine/dlls/msxml3/element.c:553: error: parse error before "xmlDocPtr" ../../../wine/dlls/msxml3/element.c: In function `DOMElement_create': ../../../wine/dlls/msxml3/element.c:555: error: `elem' undeclared (first use in this function) ../../../wine/dlls/msxml3/element.c:562: error: `xmldoc' undeclared (first use in this function) ../../../wine/dlls/msxml3/element.c:565: error: `DOMElement' undeclared (first use in this function) make[2]: *** [element.o] Fehler 1 make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/msxml3' make[1]: *** [msxml3] Fehler 2 make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' make: *** [dlls] Fehler 2 Bye Stefan

Aug. 6, 2005

theming idea

by Joris Huizer

Hello, I just read some of the articles in winehq.org I thought of something to do with theming: instead of having theming use existing control functions, couldn't the code be made independent, meaning the "non-themed" code basically becomes just another theme among the others, calling the same (custom) control building functions which are designed for using a theme? just an idea, I don't know much about the code ;) HTH, Joris

Aug. 5, 2005

Re: Wine passes WGA test

by Felix Nawothnig

James Courtier-Dutton wrote: >> IIRC it's checking the location of the old Wine config registry key. >> This has all moved as part of the config file removal (and as was >> planned long before WPA came around). >> >> No doubt they will update their WPA checks at some point... > Would it be wiser to implement a wine feature to block a particular > application from seeing a particular registry key. I disagree. If Windows has such a feature and/or it's somehow useful in other situations it could be implemented but doing this to get around their Wine detection is just silly - we couldn't win that race as there are zillions of methods to detect Wine and most of them can't be avoided (the first thing that comes to my mind which can't be worked around in userspace is doing a unix syscall for example). Felix

Aug. 5, 2005

Re: Wine printer configuration

by Andreas Mohr

Hi, this posting has nothing whatsoever to do with wineconf discussion. Redirecting further discussion to wine-devel... On Fri, Aug 05, 2005 at 03:43:55PM +0200, Sven Jacobs wrote: > We are setting up an application that needs to be available at around > 350 locations. > Everything seems to work fine. We can start the application we can > print, etc... > My problem is now that because wine is running on the server we had to > configure the 350 IP based printers also at the server side. > > Can we filter out the printer for location X if there is a connection from > location X? so that they only see that printer that is located in their > location and not the other 349 printers. I doubt that it is possible but > I have to figure out a way to fix it. This problem sounds somewhat unusual, however I could easily imagine that it can be solved relatively easily. You could log printing related debug channels and try to figure out how Wine gathers the printer configuration information (perhaps via CUPS somehow). Then you could try to figure out a way to let Wine selectively know which particular printer to use. That could be done in a shell script that launches Wine and before launching Wine either sets an environment variable or modifies the registry file in some way or another (dirty) or something else. But then I better leave real ideas to real Wine printing experts... Andreas Mohr

Aug. 5, 2005

Re: Wine passes WGA test

by Ivan Leo Puoti

James Courtier-Dutton wrote: > Would it be wiser to implement a wine feature to block a particular > application from seeing a particular registry key. We could then only > allow the key to be visable to the application it would actually be > useful for. I think the MS windows registry already has this feature in > order to provide security for certain registry entries. Blocking wine would probably be against anti trust laws so I don't see the point. I'd prefer to see them forced to remove anti wine stuff by a court rather than work around stuff like that. Ivan.

Aug. 5, 2005

Re: Standardize the DllGetClassObject prototypes

by Robert Shearman

Francois Gouget wrote: > > According to MSDN the prototype of the DllGetClassObject() functions is: > > HRESULT WINAPI DllGetClassObject(REFCLSID pclsid, REFIID piid, LPVOID > *ppv); > > > But in Wine it has sometimes varied a bit, like returning a DWROD > instead of an HRESULT. Nothing too serious but I like order so I went > through them and made them all the same. > > There's one which is more seriously wrong though: > MSXML_DllGetClassObject() is missing the WINAPI. This cause > winapi_check to issue an error and is how I got into this. That wouldn't have happened if the function had been called DllGetClassObject instead of MSXML_DllGetClassObject. Is the uniqueness of the name really more important than the compiler being able to typecheck it? Can we please not introduce any more of the Dll* functions with DLLNAME_ prefixes? -- Rob Shearman

Aug. 5, 2005

Re: Wine passes WGA test

by James Courtier-Dutton

Francois Gouget wrote: > On Fri, 5 Aug 2005, Ivan Leo Puoti wrote: > [...] > >> Also the anti wine checks appear to be disabled as the tool works in >> both windows 2000 and windows 98 mode, however the wine registry key >> string is still in the binary, maybe it's just disabled. > > > IIRC it's checking the location of the old Wine config registry key. > This has all moved as part of the config file removal (and as was > planned long before WPA came around). > > No doubt they will update their WPA checks at some point... > Would it be wiser to implement a wine feature to block a particular application from seeing a particular registry key. We could then only allow the key to be visable to the application it would actually be useful for. I think the MS windows registry already has this feature in order to provide security for certain registry entries. James

Aug. 5, 2005