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

Re: Fix the PropSysFreeString() prototype
by Marcus Meissner April 20, 2005

April 20, 2005

On Wed, Apr 20, 2005 at 05:05:54PM +0200, Francois Gouget wrote: > > PropSysFreeString() is declared as stdcall both in the .spec file and in > the ole2prop.h but it was missing the WINAPI qualifier in ole2.c. > > Changelog: > > * dlls/ole32/ole2.c > > Francois Gouget <fgouget(a)free.fr> > Specify the proper call convention in the PropSysFreeString() > implementation. > Fixes a winapi_check warning. gcc should have already warned here ... interesting. Ciao, Marcus

2 1

Tooltips in own windows
by Duane Clark April 20, 2005

April 20, 2005

I just wanted to make sure folks were aware of a tooltip regression, since I don't think I have seen mention of it here. It is easily seen in any Control Spy, but effects other apps (though not all, curiously). It manifests itself as a complete window border around tooltips. I have not tracked down where the regression occured, but could do so if no one else was looking at this.

1 0

Re: Ugly dclipper winapi_check hack
by Vincent Béron April 20, 2005

April 20, 2005

Le mer 20/04/2005 à 05:29, Francois Gouget a écrit : > > winapi_check assumes that all the functions declared in a given spec > file are implemented in a C file located in the same directory. This > seems to hold true except for DirectDrawCreateClipper() which is > implemented in a sub-directory. > > This causes winapi_check to not notice the DirectDrawCreateClipper() > implementation and to complain that it's missing. So I hacked it so it > also takes into account C files located in ddraw/dclipper/ for > ddraw.spec. > > If anyone has an idea for a better fix (or if you know of other APIs > that should have the same problem) I'm all ears as I don't like this > solution much. If you're heading that way (a bit of spring cleaning of winapi_check), could you also look at how it thinks api names are unique? It complains about ValidateVertexShader (in d3d8 and d3d9), but that function takes 1 arg in d3d8 and 2 in d3d9. I'm not sure if it read one of the spec file before the other or what. Vincent

3 3

Re: Ugly dclipper winapi_check hack
by Christian Costa April 20, 2005

April 20, 2005

Hi Francois, I plan to flatten the ddraw directory and perform some file renaming. This will fix the problem once done. Bye, Christian > Message du 20/04/05 11:39 > De : "Francois Gouget" > A : wine-patches(a)winehq.org > Copie à : > Objet : Ugly dclipper winapi_check hack > > > winapi_check assumes that all the functions declared in a given spec > file are implemented in a C file located in the same directory. This > seems to hold true except for DirectDrawCreateClipper() which is > implemented in a sub-directory. > > This causes winapi_check to not notice the DirectDrawCreateClipper() > implementation and to complain that it's missing. So I hacked it so it > also takes into account C files located in ddraw/dclipper/ for > ddraw.spec. > > If anyone has an idea for a better fix (or if you know of other APIs > that should have the same problem) I'm all ears as I don't like this > solution much. > > > Changelog: > > * tools/winapi_check/modules.pm > > Francois Gouget > Hack so winapi_check finds the DirectDrawCreateClipper() > implementation in ddraw/dclipper/main.c. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY> > [ p20050420-dclipper.diff (0.8 Ko) ]

2 1

Wine 20050419 + DX9
by Benjamin Cutler April 20, 2005

April 20, 2005

I spent most of the night trying to merge the old 20050310 patch into the 20050419 release, and I came up with the diff linked below. Keep in mind that I only attempted to get it to compile, I did not attempt to make sure it was stable or correct. For what it's worth, I *was* able to get my test games to launch and they ran pretty much exactly as they did with the old patches, but that's no guarantee of anything. Oliver seems to be MIA. His home page has disappeared and nobody I've asked has been able to successfully contact him. If somebody wants to clean this up and merge it back into the main WINE tree, please do, because I don't know enough about DX9 to even think of attempting such an undertaking myself. http://www.cs.colostate.edu/~cutler/d3d9patch.2005-04-19.diff Of course, I'll feel rather foolish if Oliver pops up tomorrow and has a real patch, but here's what I can offer for now.

1 0

set ver = ?
by Wesley Parish April 20, 2005

April 20, 2005

Addendum: I got past the unloading into temporary folder stage of MicrosoftVirtualPC2004EnglishTrial.exe, before it told me I should read the documents to see what the minimum system requirements were. Then it died on me. Bummer. // does Wine have anything that does that? I've just tried "wine MS\ .net\ framework\ SDK\ -\ with\ C-sharp\ compiler\ Setup.exe" and it told me that it couldn't install on Win95, Win98 etc, and I'd have to upgrade to NT 4.0 before it would install. Any hints, ideas, previous experience on configuring Wine for suchlike? Thanks Wesley Parish -- Clinersterton beademung, with all of love - RIP James Blish ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.

4 6

ie6install richedit regression
by Paul van Schayck April 20, 2005

April 20, 2005

http://cvs.winehq.org/patch.py?id=17049 This richedit patch broke ie6install.exe (doesn't start). As far as I can see the character stream is not setuped correctly. There is an endless loop of ME_PropagateCharOffset. This is going wrong somewhere in ME_Stream*. Paul

2 1

Segmentation Fault
by Mark Greenbank April 20, 2005

April 20, 2005

Hi all, I'm getting a Segmentation Fault when building wine on Solaris 10: The command itself is: ../tools/winebuild/winebuild -w --def \ -o advapi32/advapi32.spec.def --export advapi32/advapi32.spec gdb stack strace shows: #0 0xfef229ec in strlen () from /lib/libc.so.1 (gdb) where #0 0xfef229ec in strlen () from /lib/libc.so.1 #1 0xfef77cbe in _ndoprnt () from /lib/libc.so.1 #2 0xfef7a837 in fprintf () from /lib/libc.so.1 #3 0x0805b7e5 in BuildDef32File (outfile=0x8074e98, spec=0x8075450) at spec32.c:851 #4 0x08053f34 in main (argc=7, argv=0x80471d0) at main.c:474 For some reason, the input_file variable is NULL upon entry to BuildDef32File. Any help would be appreciated. mark

2 2

Re: Status and (nearby) future of wined3d
by Oliver Stieber April 20, 2005

April 20, 2005

--- Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > Hi, > > what will happen to the wined3d stuff, now Oliver > has some 'problems' > staying on-line? > Thanks to everyone I should be ok for a while, now. > > If the sole reason for that is that it couldn't be > merged/applied to CVS > I could give it a try. But that's about the only > thing I can do > regarding wined3d stuff. > I've just merged with wine head and am about to resend the patches, and another couple for stateblocks and sampler states. After that there's vertex declarations and resource tracking, pointsprites , non-power2 textures, memory management, D3DPOOL_DEFAULT texture operations and a few more tidyups. Then I should have all the stable work synced with winehead. After that stateblocks need to be refactored to get offscreen textures, swapchains and multiple devices/threads working properly which may take a while to stabalise. A software vertex pipeline also needs writing to fill in the gaps in the hardware support which is faily easy, and d3d8 interfaces need to wrap up wined3d. Shaders needs moving across from d3d8 which is faily simple and shader 2.0 support needs writing which is a little tricker. > Cheers, > > Paul. > > > Send instant messages to your online friends http://uk.messenger.yahoo.com

3 2

Re: Make VIRTUAL_SetFaultHandler an internal function
by Alexandre Julliard April 20, 2005

April 20, 2005

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > I guess this has no chance of going away until we have a DIB engine, > which is not even on the horizon. Actually it should be possible to handle the fault using a vectored handler, without requiring internal functions at all. -- Alexandre Julliard julliard(a)winehq.org

5 15