wine-devel August 2007

wine-devel@winehq.org

121 participants
249 discussions

Re: [2/2] winex11: Don't use context-specific info when initializing
by Roderick Colenbrander 10 Aug '07

10 Aug '07

I would like to keep this GL_RENDERER/GL_VENDOR stuff around although it might not be 100% correct in all cases (on some cards there's indeed a difference between direct and indirect rendering). To be correct also add similar code to the glx context creation code. Roderick On Friday 10 August 2007 11:29, Chris Robinson wrote: > Doesn't make much sense to use info from a temporary context when the > context the app eventually sets may be different (such is the case for > direct vs. indirect rendering on certain drivers, or multiple > screens/output devices).

1 0

[programs] add winerun for starting programs from wine.desktop
by Kirill K. Smirnov 10 Aug '07

10 Aug '07

>+/* >+ * Wordpad implementation >+ * >+ * Copyright 2007 by Damjan Jovanovic >+ * It is not wordpad, is it? >+ ok = CreateProcessW(exePath, NULL, NULL, NULL, FALSE, 0, NULL, currentDirectory, >+ &startupInfo, &processInfo); This code does not run console apps correctly (use CREATE_NEW_CONSOLE flag). -- Kirill

1 0

Re: [2/2] winex11: Don't use context-specific info when initializing
by Christoph Frick 10 Aug '07

10 Aug '07

On Fri, Aug 10, 2007 at 02:29:49AM -0700, Chris Robinson wrote: @@ -137,7 +132,7 @@ typedef struct wine_glpbuffer { } Wine_GLPBuffer; static Wine_GLContext *context_list; -static struct WineGLInfo WineGLInfo = { 0 }; +static struct WineGLInfo WineGLInfo; static int use_render_texture_emulation = 1; static int use_render_texture_ati = 0; static int swap_interval = 1; why is this changed? its a Good Thing to have global structs initialized so they fail earlier under abuse. -- cu

2 1

Re: [1/2] winex11: NV_texture_rectangle and NV_vertex_array_range do not have WGL extension names
by Roderick Colenbrander 10 Aug '07

10 Aug '07

Both are 'fake' WGL extensions. I agree that no string should be displayed in either case and that we don't need a check for NV_texture_rectangle. The loading of the NV vertex array range stuff depending on the presence of the GL extension of which it is part is fine. Yes, GL extensions are context dependend but relying on glXGetProcAddress is even more evil (as it doesn't have to return NULL). Upto now I haven't seen problems with this. On Friday 10 August 2007 11:15, Chris Robinson wrote: > This patch and the next are designed to remove the need for > context-specific information taken from a temporary context. For this one, > the aforementioned extensions don't have WGL extension names. Their > respective specs and a recent nvidia card/driver's WGL extension output > confirms this.

1 0

Re: winex11: added missing sync_current_drawable calls
by Kai Blin 09 Aug '07

09 Aug '07

On Thursday 09 August 2007 15:59:59 plams wrote: > Here's a patch to fix a regression since 0.9.28 (in response to bug > 9029). OpenGL scissoring had apparently been wrapped in commit > 715d0e84097cb2dc07369c4e1cec8cf8a41e9035 but it seems that it made it > possible to make a glDisable(GL_SCISSOR_TEST) call that would leave GL > in some pseudo-state where the scissor test was STILL active (and vice > versa for glEnable) until e.g. a wglMakeCurrent or wglViewport call > was made. This patch should fix that (and thus resolve bug 9029). You need to provide your real name for the change log, otherwise your patch can't be accepted. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

re: ANNOUNCE: Wine/Mono Regression Test Suite
by Dan Kegel 09 Aug '07

09 Aug '07

Matt wrote: > ...I've found that running the mono regression test suite has > given me a better idea of how to approach debugging mono/wine. > ... > http://mhjones.org/wine/wine-tests/wine-test-reader.tar.gz I downloaded this and had a look just now. The instructions still refer to the deprecated 1.1 branch of mono, and I hear to run on wine, one needs something newer than the latest released version of mono. So I tried building mono from the trunk. My dapper system was missing some things mono seems to need, so I expanded on the script in the readme a bit, and came up with #!/bin/sh set -xe MONOBUILDDIR=/data/dkegel/mono-cvs mcs --version || sudo apt-get install mono-devel libtool --version || sudo apt-get install libtool automake-1.9 --version || sudo apt-get install automake1.9 automake --version | grep 1.9 || sudo update-alternatives --set automake /usr/bin/automake-1.9 mkdir -p $MONOBUILDDIR cd $MONOBUILDDIR svn co svn://anonsvn.mono-project.com/source/trunk/mono cd mono ./autogen.sh --build i486-linux-gnu make This goes well for a while, but fails with /bin/sh: line 1: cd: ../../mcs: No such file or directory if test -w ../../mcs; then :; else chmod -R +w ../../mcs; fi chmod: cannot access `../../mcs': No such file or directory make[2]: *** [all-local] Error 1 make[2]: Leaving directory `/usr/local/google/bigdata/dkegel/mono-cvs/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/google/bigdata/dkegel/mono-cvs/mono' make: *** [all] Error 2 Can you update your README to show how to build some flavor of mono-1.2 that runs under Wine? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: Wine Kernel Handle Support Module
by Michael Ost 09 Aug '07

09 Aug '07

>>> I know there is some discussion of what should be put in the kernel >>> module, so I am asking for advice on what to implement... ie. just >>> handles, everything wineserver does, etc. >> The first question is: >> Why do you want to do that and what specifically do >> you want to achieve? > > A small step towards less overhead in client <-> server calls? One _big_ vote for putting thread sync primitives --- events, semaphores, mutexes and critical sections --- in. We had to build a custom Wine to get acceptable realtime performance (thanks, Ulrich!). The client <-> server were causing high priority threads to block on low priority ones. I guess a test case would be something that shows how a high priority thread blocking on a sync primitive, while some low priority thread is doing some unrelated server heavy stuff, like lots of graphics updates. Cheers... mo

1 0

[SNMPAPI] How to fix the tests for win98 and NT4?
by Paul Vriens 09 Aug '07

09 Aug '07

Hi, There are several functions in the util.c test that are not available on win98 and NT4. That can be dealt with easily. Almost all tests with a NULL parameter crash on win98/NT4. I know that a few weeks back we talked about ignoring win98 if it would mean skipping a lot of tests, but now NT4 is involved as well. I could introduce a variable of course that's set when we are on NT4 or lower (because of the missing functions) and don't run the 'NULL' tests. Any ideas, comments? Cheers, Paul.

2 1

Re: exporting file associations for linux desktops
by Misha Koshelev 09 Aug '07

09 Aug '07

> To register those verbs for Linux desktops, some sort of command-line > wrapper around ShellExecute would be needed. I think this is a good > idea anyway. Does Windows have anything like that? Is it worth it for > me to try writing something like that based on winelib? Well this is exactly the start program which is already implemented. In fact I thought about this problem myself a bit, the problems with start right now for this purpose (starting wine associated files from linux) are: 1. start currently doesn't understand a simple UNIX path, easily fixed by prepending a Z: (assuming this is the drive the user has mapped to the UNIX root dir) 2. there is no standalone winestart program, and at least from my experimentation with Right Click->Open File With... on GNOME (or whatever the menu item is called), it won't let you put in "wine start" or wine start or the sort. What I actually do right now is use this shell script (I almost started working on this problem but then since the shell script was so easy I decided to focus on other things, but am still very interested in seeing it solved): #!/bin/sh wine start Z:$* And just associating it with my file type (well the problem with doing what I am doing is I am just associating it with a file .gb which I guess GNOME puts into some kind of text/plain type, so anything that is a text file ends up being opened with notepad on wine instead of gedit... I am too lazy to make it any more complex on my computer for now). Anyway, just though this info might help if you were not already aware, as the start program is definitely this wrapper around ShellExecute that already exists. One possibility would be to extend it to handle UNIX paths and then have it compiled and installed as a standalone winestart - like the other wine standalone programs we install, another is just to have the shell script somewhat like above installed (dangerous as Z: may not be mapped to the root so this would have to figured out) - I believe wineshelllink which is installed is a shell script, or maybe even go the route of letting the wine binary itself ShellExecute things (haven't really looked at it/thought this out in detail). Anyway, just my two cents. Thanks for thinking about/hopefully working on this. Misha > > > -- > Vincent Povirk

4 6

[Winetest] Possible removal of LoadLibrary and friends in the conformance tests
by Paul Vriens 09 Aug '07

09 Aug '07

Hi, With the current version of winetest, conformance tests for which the main dll is not available will not run anymore. This will be reported on test.winehq.org. We will be seeing the new approach as of 12:00 GMT when the new winetest.exe is available and the first tests come in. Several tests currently check for the existence of the dll via LoadLibrary and do a lot of GetProcAddress calls to retrieve function pointers. This should not be needed anymore in most cases. The tests that come to mind: d3d8 d3d9 d3drm gdiplus localspl localui pdh uxtheme and there are (and will be in the future) others. My plan, and this is open for discussion of course, is to: 1. Add the main dll back as part of the IMPORTS in the Makefile.in files 2. Change LoadLibrary to GetModuleHandle and still use GetProcAddress to catch unexported functions (for a short period). We do need to reporting missing functions. 3. Remove GetModuleHandle and/or GetProcAddress's if possible and make more use of 'skip' if needed. This will be a lengthy process so if there are volunteers, please step up. Eventhough this is some considerable amount of work to be done, in the end the code will be cleaner (and several lines shorter). Comments/remarks ? Cheers, Paul.

5 8

← Newer
1
...
15
16
17
18
19
20
21
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel August 2007