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

Re: include/winsplp.h added
by Detlef Riekenberg Aug. 7, 2005

Aug. 7, 2005

Am Sonntag, den 07.08.2005, 20:52 +0200 schrieb Detlef Riekenberg: > Changelog: > - File "include/winsplp.h" added Upps.. I did not remove an unneeded pair of: #if 1 #endif Is a resend needed? -- By By ... ... Detlef

1 0

SMB for FUSE
by Boaz Harrosh Aug. 7, 2005

Aug. 7, 2005

*Is anybody familiar with this project?: SMB for FUSE <http://freshmeat.net/projects/fusesmb/?branch_id=45268&release_id=203494> It looks like a way to send users who need (Semi-transparent) UNC support. I was thinking of linking the .wine/dosdevices/unc to the above mount point. ** Free Life Boaz *

1 0

re: SMB for FUSE
by Dan Kegel Aug. 7, 2005

Aug. 7, 2005

Boaz wrote: > *Is anybody familiar with this project?: > SMB for FUSE > <http://freshmeat.net/projects/fusesmb/?branch_id=45268&release_id=203494> > > It looks like a way to send users who need (Semi-transparent) UNC > support. I was thinking of linking the .wine/dosdevices/unc to the above > mount point. In general, I like the idea of use FUSE from within other projects. e.g. somebody's doing it with KDE; see http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway But FUSE is not yet part of the standard kernel.org kernels; see http://kerneltrap.org/node/5329 for recent comments on this. It's kind of a shame that there isn't a way to use FUSE without a kernel portion. One ought to be able to run it as a daemon or something, at least. And that would let you use it with Solaris or BSD, not just Linux. Anyway, since FUSE is not widely used or very portable, Wine should be very careful about relying on it. There be dragons here. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

test case demonstrating PeekMessage give up timeslices
by Oliver Mössinger Aug. 6, 2005

Aug. 6, 2005

Hi wine-devel, attached i have a test case whitch demonstates the differece between Windows and wine. There is also a sample program 'TEST.CPP' attached. On Windows XP - Start 'test.exe' from a dos-box... you see some FAST counting integers - Start a other (loop.pl) program witch consumes mutch cpu time. - the output of 'test.exe' is slower but FAST On wine - Start 'test.exe' from a dos-box... you see some FAST counting integers - Start a other (loop.pl) program witch consumes mutch cpu time. - the output of 'test.exe' is very slow This different behavior starts from wine version 20041201. The version before was ok. I have no patch and it would be nice if someone can write a patch to fix this. Thanks Oliver Mössinger

4 15

Re: compile error in current cvs
by Adam D. Moss Aug. 6, 2005

Aug. 6, 2005

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. It fixes the compile problem, thanks. However, the other half of the problem is that WINE isn't detecting libxml2 'properly'. It should be using `xml2-config --cflags` etc, which puts the correct -I on the command-line without having to link the libxml2/libxml include directory to libxml. Note that a 'raw' libxml2 make-install doesn't make any such link -- some distros have presumably done it to help really old apps compile. Cheers, --Adam

1 0

Re: Wine printer configuration
by Andreas Mohr Aug. 6, 2005

Aug. 6, 2005

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

2 1

Re: compile error in current cvs
by Stefan Leichter Aug. 6, 2005

Aug. 6, 2005

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

2 2

theming idea
by Joris Huizer Aug. 5, 2005

Aug. 5, 2005

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

1 0

Wine passes WGA test
by Ivan Leo Puoti Aug. 5, 2005

Aug. 5, 2005

You can now validate for WGA downloads using wine and the Microsoft WGA validation tool, and you'll get a thank you message from Microsoft for using Microsoft genuine downloads. 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. In any case some EU officials have already expressed an interest in these checks, so if they enable them someone may end up getting another super fine. Ivan.

5 5

Re: Standardize the DllGetClassObject prototypes
by Robert Shearman Aug. 5, 2005

Aug. 5, 2005

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

1 0