April 2004 - Wine-Devel - list.winehq.org

DDraw issues, etc.

by Tim Hentenaar

Hi all, I've implemented SetClipList and GetClipList in the DirectDraw Clipper, and I'm wondering how I should go about implementing clipping in DirectDraw's Blt() (if it isn't already done somewhere). M$'s documentation isn't too great, so I figured I should ask around. There's a game one of my relatives wants to run under Linux (it's a children's program), and the major problem is that it dosen't seem to handle clipping properly when blitting. (e.g. every time you move the mouse, it calls SetClipList). FYI, the binkw32.dll that came with the program was originally causing it to hang, but I patched the DLL and it works fine. If anyone else has had such problems, I could provide a patch. Also, I'm going to take a look at some of the DirectSound stuff too. The sound isn't very good quality for some reason, but under the WineX 3.3 CVS, sound works perfectly. Tim

April 3, 2004

W95INF32 implementation, incase it's useful to anybody

by Mike McCormack

Hi All, In the process of understanding another bug, I did a little work to implement w95inf32, which appears to be a small IE/win9x only DLL and which is probably of not much use to Wine. It appears to be a think wrapper 32bit around 4 functions in SETUPX. So this is just for documentation purposes, and incase anybody is curious or finds a real need for this DLL. Mike --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/Makefile.in 2004-03-30 12:03:27.000000000 +0900 @@ -0,0 +1,20 @@ +#MKDLL_SKIP +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = w95inf32.dll +IMPORTS = setupapi kernel32 +ALTNAMES = w95inf16.dll + +SPEC_SRCS16 = $(ALTNAMES:.dll=.spec) + +C_SRCS = \ + w95inf32.c + +(a)MAKE_DLL_RULES@ + +w95inf16.spec.c: w95inf16.spec + $(WINEBUILD) $(DEFS) $(DLLFLAGS) -o $@ --main-module $(MODULE) --spec $(SRCDIR)/w95inf16.spec + +### Dependencies: --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/w95inf32.c 2004-03-29 17:07:20.000000000 +0900 @@ -0,0 +1,91 @@ +/* + * W95INF32 - This is a small 32bit interface to SETUPX + * + * Copyright 2004 Mike McCormack for CodeWeavers + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include <stdarg.h> +#include "windef.h" +#include "winbase.h" +#include "winuser.h" + +#include "setupapi.h" + +#include "wine/debug.h" + +WINE_DEFAULT_DEBUG_CHANNEL(w95inf32); + +BOOL WINAPI CtlSetLddPath32( LPSTR x, LPSTR y ) +{ + FIXME("%s %s\n", debugstr_a(x), debugstr_a(y) ); + return FALSE; +} + +BOOL WINAPI GenFormStrWithoutPlaceHolders32( LPSTR dst, LPCSTR src, LPCSTR filename ) +{ + HINF hinf; + DWORD ret = 0; + + FIXME("%p %s %s\n", dst, debugstr_a(src), debugstr_a(filename) ); + + hinf = SetupOpenInfFileA( filename, NULL, INF_STYLE_WIN4, NULL ); + if( !hinf ) + return GetLastError(); + + /* FIXME: call LookupStringInTable? */ + strncpy(dst, src, MAX_INF_STRING_LENGTH ); + + SetupCloseInfFile( hinf ); + + return ret; +} + +DWORD WINAPI GenInstall32(LPCSTR filename, LPCSTR section, LPCSTR directory, DWORD flags) +{ + HINF hinf; + void *context; + DWORD ret = 0; + + ERR("%s, %s, %s, %08lx\n", filename, section, directory, flags ); + + hinf = SetupOpenInfFileA( filename, NULL, INF_STYLE_WIN4, NULL ); + if( !hinf ) + return GetLastError(); + + context = SetupInitDefaultQueueCallback( 0 ); + if (!SetupInstallFromInfSectionA( 0, hinf, section, flags, 0, NULL, + SP_COPY_NEWER_OR_SAME, SetupDefaultQueueCallbackA, + context, 0, 0 )) + { + ret = GetLastError(); + ERR("Failed %08lx\n",ret); + } + + SetupTermDefaultQueueCallback( context ); + + SetupCloseInfFile( hinf ); + + return ret; +} + +BOOL WINAPI GetSETUPXErrorText32(long a, long b, long c) +{ + FIXME("\n"); + return FALSE; +} + --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/w95inf32.spec 2004-03-29 17:04:15.000000000 +0900 @@ -0,0 +1,9 @@ +# w95inf32 functions have @nn in their names... +# winebuild removes the last @xx in a function name. + +1 stdcall CtlSetLddPath32(a)8@8(str str) CtlSetLddPath32 +2 stdcall GenFormStrWithoutPlaceHolders32(a)12@12(ptr str str) GenFormStrWithoutPlaceHolders32 +3 stdcall GenInstall32(a)20@20(str str str long) GenInstall32 +4 stdcall GetSETUPXErrorText32(a)12@12(long long long) GetSETUPXErrorText32 +5 stub w95thk_ThunkData32 +

April 3, 2004

Re: Should winemaker be able to handle this

by Dimitrie O. Paun

On April 2, 2004 4:01 pm, Francois Gouget wrote: > These options are global, i.e. they are supposed to be effective in > every makefile makefile generated by winemaker. For this reason they > used to go in the Make.rules.in file. That way one could later modify > them in one place instead of having to manually edit tens or hundreds of > makefiles. OK, so let's look at the problem. We have basically two distinct use cases here: A. We have a .dsp that we can convert to a Makefile B. We don't have a .dsp, so we autoguess a Makefile For (A) to work, we need to integrate the dsp2make, this is in the works (or at least we plan on doing :)). For this case, we don't need those options, but rather we need a _reliable_ conversion from .dsp -> Makefile. By reliable I mean that the result need not be handedited, so that on updates to the .dsp we can regenerate the Makefile. Moreover, we can not assume this to be the real project Makefile, we should generate it in such a way that another GNU Makefile can include it (using the include GNU extension; other makefile systems support this extension BTW in some form on another). For (B), the generation of the Makefile is a one time thing. After first generation, it should be properly maintained manually. We can not pretend to autoguess any Makefile right, but the trivial ones, and encouraging regeneration like this is just dangerous. So for this case we don't need those options either, the user can simply edit the resulting Makefile and add them in there just as easily. In other words, I think we should get rid of those options altogether, and focus on supporting the .dsp2make stuff, this is where the money is. -- Dimi.

April 3, 2004

Re: Should winemaker be able to handle this

by Francois Gouget

On Fri, 2 Apr 2004, Bill Medland wrote: [...] > What I used toi have was: > #! /bin/bash > # Run this script in order to pass the correct arguments to winemaker so that > # it can set up the build environment > winemaker --nosource-fix --nogenerated-specs --dll --single-target mytarget > --nomfc -DMY_SETTING -I$MY_INC_DIR -L$MY_LIB_DIR -lmylinuxso . > > I see that we don't bother with generating spec files any longer. However I > see that the -D, -I, -L and -l options don't find their way into the Makefile > these days. Is that by design or a bug? (i.e. do I have to fix winemaker or > do I need to look at a different way of doing it) These options are global, i.e. they are supposed to be effective in every makefile makefile generated by winemaker. For this reason they used to go in the Make.rules.in file. That way one could later modify them in one place instead of having to manually edit tens or hundreds of makefiles. But ever since Dimitrie removed autoconf support we don't have a Make.rules.in file anymore and thus are completely ignored. Maybe we should re-add support for autoconf. Or maybe we should duplicate these settings in every makefile that we generate. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

April 2, 2004

Re: When saving a file with staroffice it is not saving with extension.

by Dimitrie O. Paun

On Fri, 2 Apr 2004, Mike Hearn wrote: > Interesting bug report. Not sure what might cause that, but it does beg > the question - why aren't you using the native Linux version of StarOffice? First, I think it's a good test case for wine, so it's good that he does it. Second, in terms of practical application, it may make sense to use the Windows version of cross platform apps like Mozilla and StarOffice, as they may be better optimized, less bugs, etc. So no, I don't think this is an unreasonable thing to do. -- Dimi. P.S. I always wanted to see how the Linux Mozilla compares to the Win32 Mozilla under Wine...

April 2, 2004

Should winemaker be able to handle this

by Bill Medland

I haven't been following the winemaker stuff so I don't know whether it is supposed to be able to handle this (and is broken) or not. I am having to play with the "build a builtin dll to wrap a linux so" concept again after a year or so since the last time, as discussed in the Winlib manual, chapter 5. I see that winemaker has changed since then. In particular the bit that is not working for my case is the -D, -I, -L and -l options. What I want is to run winemaker to generate the build environment and then do the build. What I used toi have was: #! /bin/bash # Run this script in order to pass the correct arguments to winemaker so that # it can set up the build environment winemaker --nosource-fix --nogenerated-specs --dll --single-target mytarget --nomfc -DMY_SETTING -I$MY_INC_DIR -L$MY_LIB_DIR -lmylinuxso . I see that we don't bother with generating spec files any longer. However I see that the -D, -I, -L and -l options don't find their way into the Makefile these days. Is that by design or a bug? (i.e. do I have to fix winemaker or do I need to look at a different way of doing it) -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

April 2, 2004

Re: When saving a file with staroffice it is not saving with extension.

by Mike Hearn

On Fri, 02 Apr 2004 18:03:05 +0800, Ravi Kumar wrote: > Hello Sir, > I am working with wine for some time now. I faced with a problem, > whenever i am saving a file from Windows version of Staroffice from wine > it is saved without extension. I think it is a problem with wine, as > staroffice in windows stores files with extensions. I am using > wine-20031118 version. Interesting bug report. Not sure what might cause that, but it does beg the question - why aren't you using the native Linux version of StarOffice? thanks -mike

April 2, 2004

Development CDs for Windows

by Steven Pignataro

I have a large amount of Windows Development CDs....i am wondering if these would be of any interest to the Development team of Wine.... I think that these would become very usefull at developing for Wine as well as alot of what Windows does is still most of the same. They are Windows NT 4 development kits and much much more. We where going to chuck them at my school...but salaviged them Please let me know Thanks -- Steven Pignataro A+ Partner/ CSO Computer Vision Networks, Inc. Toll Free: 866-897-8896 Phone: 269-979-5582 Fax: 269-288-0418 http://www.computervisions.net/ (c)2002-2004 --

April 2, 2004

Re: Developer's path to Windows/*NIX multi-platform?

by Mike Hearn

On Fri, 02 Apr 2004 14:54:30 +0000, greensh(a)knology.net wrote: > Well not to start a KDE vs Gnome debate, but Gnome is way behind KDE > development... hehe, hint, that's not a good way to "not start a KDE vs GNOME debate" > it doesn't even support Superkaramba (last I checked). SuperKaramba is KDE specific by the way it's coded. There is an equivalent in the form of GDesklets, and works much the same way. > You only pay licensing if your Qt app is commercial. ... or runs on Windows ... > The free version is perfect for opensource (ie GPL software) hence ... unless you want a non-X11 port ... > It requires too many code changes (at least in Python) for easy > cross-compiling. In Qt you simply generate a .pro file for the platform. Since when does Python require cross compiling? I think I was just trolled....

April 2, 2004

Personal tree with interesting patches

by Mike Hearn

Hi, As I'm pretty busy right now and won't have time to work on the various misc projects I've been working on up until recently for the foreseeable future, I'm checking them into my personal arch archive for people to play with and maybe work on themselves. My archive co-ordinates: http://navi.cx/~mike/archive/2004 mike(a)navi.cx--2004 so, you'd use: $ tla register-archive http://navi.cx/~mike/archive/2004 There are currently only two interesting branches: wine--mainline--0.9: misc patches that were never applied for whatever reason, debug delay, lockwindowupdate (disabled), that sort of thing as i find more patches around my system i'll check them in for safekeeping wine--loadarea-reserve--0.9 execshield/prelink work, see the log message in patch-1 for details on what remains to be done Have fun! thanks -mike

April 2, 2004