wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

err:opengl:X11DRV_ChoosePixelFormat Flag not supported
by Tobias Burnus 30 Jun '04

30 Jun '04

Hello, I have the following problems with WINE, CVS version as of yesterday and Crystal Impact's Diamond http://www.crystalimpact.com/diamond/ http://www.crystalimpact.com/download/diamond/demo/dm2demo.exe, which installs flawlessly. a) I get a err:opengl:X11DRV_ChoosePixelFormat Flag not supported when I open e.g. ./Samples/Minerals/Copper.dsf and a dialogbox with the following text is shown: ChoosePixelFormat() returns 0 (last error = 0) SetPixelFormat() returns 1 (last error = 0) wglCreateContext() returns 0 (last error 2000) wglMakeCurrent() returns 1 (last error = 0) (Workaround: disable rendering) b) Some data is displayed as list, e.g. like http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list.png under WINE this is completely mangled: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list_wine.png Sometimes some spread numbers appear, but in this case one can only mark cells. Any ideas how to fix/debug this? (I have unfortunally no experience at all in programming in Wine/Windows.) Anyone volunteering to look at this? I'm willing to spend some $$ (but not $$$) on that (I know that this is not much, but some rewarding of volunteer work doesn't hurd either). Regards, Tobias

1 0

Re: Typo in winedbg
by Mike Hearn 30 Jun '04

30 Jun '04

On Mon, 28 Jun 2004 20:45:35 -0400, Andrei Barbu wrote: > This fixes debuggee to debugger. I think debuggee is the right word, it means "the one that is being debugged". Ctrl-C doesn't interrupt winedbg, it interrupts the process you are currently attached to.

2 1

Failed to compile on Sparc/Solaris 9
by John O'Donnell 30 Jun '04

30 Jun '04

make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/export/home/root/wine/wine/dlls/newdev' make[2]: Entering directory `/export/home/root/wine/wine/dlls/ntdll' ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./ntdll.spec cdrom.o critsection.o debugbuffer.o debugtools.o directory.o env.o error.o exception.o file.o heap.o large_int.o loader.o loadorder.o misc.o nt.o om.o path.o process.o reg.o relay.o resource.o rtl.o rtlbitmap.o rtlstr.o sec.o server.o signal_i386.o signal_powerpc.o signal_sparc.o string.o sync.o version.o thread.o time.o virtual.o wcstring.o relay32.o ntdll.dll.dbg.o -o ntdll.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port -lresolv -lsocket -lnsl ntdll.dll-IHmocZ.spec.c:20:1: warning: "__stdcall" redefined <command line>:17:1: warning: this is the location of the previous definition thread.o: In function `NtCurrentTeb': /export/home/root/wine/wine/dlls/ntdll/thread.c:582: undefined reference to `wine_pthread_get_current_teb' collect2: ld returned 1 exit status winegcc: gcc failed. make[2]: *** [ntdll.dll.so] Error 2 make[2]: Leaving directory `/export/home/root/wine/wine/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/export/home/root/wine/wine/dlls' make: *** [dlls] Error 2 root@gold251:/root/wine/wine# This is CVS'ed a day ago. Any ideas? Any more info needed?

1 0

[RFC] Wine upgrade procedure (spec)
by Dimitrie O. Paun 30 Jun '04

30 Jun '04

Hi folks, It seems that we are getting ever so closer to 0.9. Slow, but steady. Looking at the TODO, it looks like upgrading is one of the big showstoppers, in that it will affect (1) the end-user experience, and (2) how we deal with the configuration. So this seems like a good time to start discussing this topic, as we need to eventually reach the elusive 0.9. This seems to be a difficult topic, so we need to approach the problem well prepared. That is, we need to first define (and agree) on what we need to solve here. So after a tumultuous discussion on IRC, I decided to get the ball rolling. Intuitively, upgrading wine is simple to understand: once a new version is installed, we need to get users in a state where they can use it. While simple to state, this problem is complicated by the various corner cases that can appear in Real Life (TM): -- native vs. builtin DLLs handling -- multiple Wine installations on a box -- updating only some DLLs -- integrating into the Unix environment -- dealing with Windows software We can also look at some important use-cases that we need to support, but before we do, the following must hold true in all cases: -- administrators should be able to install a new Wine on the system easily with "rpm -U" (or equivalent). -- the upgrade should not erase registry settings that are managed by the user Let's look at the use-cases: A. Global Install In this case, both Wine code, as well as applications are installed globally, for all users to access. This is the most Unix-like setup, but unfortunately the most difficult to support, due to the fact that Win32 apps simply expect a different environment. Since we can't control application's code, this setup may present some limitations, but it may be sufficient for sites that need a limited set of applications. For this to work, it is acceptable that we ship special scripts that know about the applications that are supported, so that they can work around inherent limitations in the applications themselves. Users should transparently be able to use the new version of wine, the next time they start wine. B. Mixed Install Here, Wine code is installed globally, but applications are installed in the user's account. In a way is like (A) but with some additional applications installed directly into the user's account. Same requirements apply to this case as well. C. Local Install Both Wine code, as well as applications are installed locally, into the user's account. The Wine code is still installed globally by the administrator (as in A & B), but it is copied locally before it's being used. An upgrade in this case may require an explicit action by the user, so the upgrade can happen at a controlled time, when the user desires it. In all of the above, there is always state in the user directory. Thus, it is imperative that the upgrade process makes sure that after the upgrade, the user-private state is consistent with the new code base. Also, any solution must take into account that the registry must be created on the fly, as it is created when registering the DLLs. Before we go any further, I'd like to ask everybody to contribute their thoughts/requirements/desires so that we get a conprehensive view of the problem we are trying to solve. Thanks for reading this far! -- Dimi.

3 3

A wine magic trace key
by Andrei Barbu 29 Jun '04

29 Jun '04

I'm about to implement a set of keys that lets me enable disable traces any time. Seems to me like it's a good idea, like that I can get traces for exactly what I need. Especially when I'm faced with weird debugger output that's 10 minutes into the game and I can't turn traces on to begin with. Is there another way, possibly existing, to do this? Is this a really bad idea? If people are interested I can post a patch later on today or tomorrow with it. It'll be implemented in the x11 driver and calling the existing wine_dbg_parse_options with a new options string. It can even be made a commandline option to enable and disable that key combination (and possibly the key combination could be set in wineconfig) but that's if enough people are interested in the idea. Thanks, Andrei

3 4

Temporary moderator needed
by Duane Clark 29 Jun '04

29 Jun '04

Howdy, Someone is needed for the period June 30-July 5 to handle moderation of the Wine lists. If you are willing to do it, please email me off list. Thanks.

1 0

Re: Missing declaration for MSVCRT_div_t and MSVCRT_ldiv_t
by Dimitrie O. Paun 29 Jun '04

29 Jun '04

On Tue, Jun 29, 2004 at 01:27:23PM +0200, Pierre d'Herbemont wrote: > Hi! > > On non-i386 we have to define MSVCRT_div_t and MSVCRT_ldiv_t. Please also add the appropriate tests to tests/headers.c. -- Dimi.

1 0

Re: parameter checking in CoMarshalInterface
by Uwe Bonnes 29 Jun '04

29 Jun '04

>>>>> "Aric" == Aric Stewart <aric(a)codeweavers.com> writes: Aric> Changlog: return an error if the IUnknown pointer is NULL and dont Aric> crash tested with win2k and this is proper behavior Index: The test is welcome in the test suite... Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: Mandrake RPMs
by Ivan 29 Jun '04

29 Jun '04

> It turns out the reason they don't work on Fedora is because they don't > work at all No, wine segfaulted, so it probably wasn't a packaging related problem. > wine.inf is in /usr/share/doc/wine-20040615 which is wrong, > it needs to be in /usr/share/wine. This is strange because I tested both RPMs on multiple versions of Mandrake before releasing them. Anyway, new RPMs will be up soon. Ivan.

2 1

Mandrake RPMs
by Mike Hearn 29 Jun '04

29 Jun '04

Hi, Ivans comment that the Mandrake RPMs didn't work on Red Hat/Fedora surprised me, so after encountering a stuck Mandrake user for whom the RPMs weren't working either on IRC I decided to check them out. It turns out the reason they don't work on Fedora is because they don't work at all - wine.inf is in /usr/share/doc/wine-20040615 which is wrong, it needs to be in /usr/share/wine. As this file is in the wrong place Wine refuses to start on a new users account. Once I manually copied the file to the right place Wine worked just fine. Could somebody please fix the Mandrake RPMs, and maintainers of other packages please ensure you have details like this right. thanks -mike

1 0

Re: fix typo in wwn
by Brian Vincent 29 Jun '04

29 Jun '04

> -A few other people were in favor of saving it to support a > +A few other people were in favour of saving it to support a "The Americans are identical to the British in all respects except, of course, language." - Oscar Wilde Brian

3 2

How to handle odbc/registry
by Bill Medland 29 Jun '04

29 Jun '04

The builtin odbc32.dll basically simply proxies the underlying unix ODBC provider (e.g. unixODBC or iODBC). I have just discovered that somewhere in the compilation/link phase under Windows some standard ODBC function calls somehow actually get translated into direct registry calls. For example the SQLGGetInstalledDrivers call actually gets translated into an OpenKey and EnumerateKey on the HKLM/Software/ODBC/ODBCINST.INI/ODBC Drivers So should we have code within the registry code that recognises access to the ODBC tree when odbc32 is builtin and redirects it to the corresponding calls to the unix ODBC manager? -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

2 1

Re: objects/region.c: REGION_FrameRgn
by Alexandre Julliard 29 Jun '04

29 Jun '04

Filip Navara <xnavara(a)volny.cz> writes: > Indeed Dimtry was right about the cause of the balloon tooltips > drawing issue. Here is the code for FrameRgn ported from ReactOS that > actaully does the right thing. I don't think you should modify the source region at all, even temporarily; it could be in use somewhere else. -- Alexandre Julliard julliard(a)winehq.org

1 0

AT_SYSINFO under RedHat 8
by Bill Medland 28 Jun '04

28 Jun '04

preloader.c doesn't make due to the most recent change. Presumably AT_SYSINFO is supposed to be in the Elf.h? Bill -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

Crash when resizing window in Desktop mode
by Uwe Bonnes 28 Jun '04

28 Jun '04

Hallo, resizing the window of ISE (Xilinx FPGA programming suite), the mouse remains captured inside the wine desktop and following backtrace can be requested: Backtrace: =>1 0x404fdc04 DebugBreak+0x4 [debugger.c:274] in kernel32 (0x406ef1fc) 2 0x41f11067 error_handler+0x87(display=0x78089550, error_evt=0x406ef248) [x11drv_main.c:186] in x11drv (0x406ef210) 3 0x4114fc6b (0x406ef2c0) 4 0x4114e086 (0x406ef300) 5 0x41148f15 (0x406ef340) 6 0x41148ff5 (0x406ef360) 7 0x41130269 (0x406ef380) 8 0x41ee08a1 BITBLT_InternalStretchBlt+0x6e1(physDevDst=0x403d8f60, xDst=0x53, yDst=0x64, widthDst=0x286, heightDst=0x4, physDevSrc=0x0, xSrc=0x0, ySrc=0x0, widthSrc=0x0, heightSrc=0x0, rop=0x5a0049) [bitblt.c:1429] in x11drv (0x406ef424) 9 0x41ee0d93 X11DRV_PatBlt+0x43(physDev=0x403d8f60, left=0x53, top=0x64, width=0x286, height=0x4, rop=0x5a0049) [bitblt.c:1533] in x11drv (0x406ef470) 10 0x408a34ec PatBlt+0x5c(hdc=0xb38, left=0x53, top=0x64, width=0x286, height=0x4, rop=0x5a0049) [bitblt.c:42] in gdi32 (0x406ef49c) 11 0x41f0d8f7 draw_moving_frame+0x67(hdc=0xb38, rect=0x406ef58c, thickframe=0x1) [winpos.c:1763] in x11drv (0x406ef4cc) 12 0x41f0e7b4 X11DRV_SysCommandSizeMove+0xae4(hwnd=0x20028, wParam=0xf008) [winpos.c:2062] in x11drv (0x406ef5c8) 13 0x407c03e1 NC_HandleSysCommand+0x1b1(hwnd=0x20028, wParam=0xf008, lParam=0x25302d3) [../../windows/nonclient.c:1499] in user32 (0x406ef5f4) 14 0x407b0b5f DEFWND_DefWinProc+0x98f(hwnd=0x20028, msg=0x112, wParam=0xf008, lParam=0x25302d3) [../../windows/defwnd.c:528] in user32 (0x406ef684) 15 0x407b10c3 DefWindowProcA+0xa3(hwnd=0x20028, msg=0x112, wParam=0xf008, lParam=0x25302d3) [../../windows/defwnd.c:916] in user32 (0x406ef6b0) 16 0x407ba2d2 DefFrameProcA+0x42(hwnd=0x20028, hwndMDIClient=0x1002a, message=0x112, wParam=0xf008, lParam=0x25302d3) [../../windows/mdi.c:1272] in user32 (0x406ef6d4) 17 0x6c376a27 (0x406ef7bc) 18 0x6c371cea (0x406ef7dc) 19 0x40e41ccc (0x0000f008) 20 0x00000000 (0x00000000) This is with today's CVS -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 3

Re: fix typo in wwn
by Ivan 28 Jun '04

28 Jun '04

> And they don't use the metric system. Shame. The matric system is way more used in the UK than in the US, where it's hardly used at all. Ivan.

1 0

Re: Change REFIID to IID* for stack declarations in oaidl_p.c to avoid initializers being discarded
by Mike Hearn 27 Jun '04

27 Jun '04

On Sun, 27 Jun 2004 21:13:17 +0200, Marcus Meissner wrote: >> + It is usually generated directly by MIDL, however this file has >> + been tweaked since then to account for slight differences in the way >> + gcc and MSVC++ compile it. In particular, in some functions REFIIDs >> + declared on the stack have been converted to plain IID* in order to eliminate >> + the constness of the REFIID type, ensuring that the zero initializer is not >> + discarded. >> + >> + Therefore, please do not regenerate this file. >> +*/ > > The comment is not understandable. > > Shouldn't it read '"REFIID" should not be used, because the value is not "const"'? I don't understand that wording of the comment either unfortunately :( It's not that it shouldn't be used, it's more that in the original generated code (I think) it was written like this: REFIID riid; (REFIID ) riid = 0; I'm not sure why MIDL did this, but as REFIID is simply #define REFIID const IID* const changing those instances to IID* should "fix" it without any warnings about assigning to a readonly variable. REFIID can still be used elsewhere though. thanks -mike

1 0

Re: Tooltips: Start of Balloon Support
by Dmitry Timoshkov 27 Jun '04

27 Jun '04

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> wrote: > This patch marks the start of balloon tip support. Note that it also has > the same bug as native due to regions not being handled the same as on > Windows. Do you mean a bug in FrameRgn? If yes, ReactOS might have that bug fixed in their implementation. Could you have a look? -- Dmitry.

2 1

Re: Change REFIID to IID* for stack declarations in oaidl_p.c to avoid initializers being discarded
by Marcus Meissner 27 Jun '04

27 Jun '04

On Sun, Jun 27, 2004 at 05:23:27PM +0100, Mike Hearn wrote: > This can cause a subtle marshalling failure in some cases > (inter-thread IDispatch, native MSI, etc) > > > Mike Hearn <mh(a)codeweavers.com> > Change REFIID to IID* for stack declarations in oaidl_p.c to avoid > initializers being discarded > Index: oaidl_p.c > =================================================================== > RCS file: /home/wine/wine/dlls/oleaut32/oaidl_p.c,v > retrieving revision 1.2 > diff -u -p -w -r1.2 oaidl_p.c > --- oaidl_p.c 5 Sep 2003 23:08:33 -0000 1.2 > +++ oaidl_p.c 27 Jun 2004 16:17:04 -0000 > @@ -1,5 +1,14 @@ > -/* this ALWAYS GENERATED file contains the proxy stub code */ > +/* This file contains the proxy/stub code for core COM interfaces. > > + It is usually generated directly by MIDL, however this file has > + been tweaked since then to account for slight differences in the way > + gcc and MSVC++ compile it. In particular, in some functions REFIIDs > + declared on the stack have been converted to plain IID* in order to eliminate > + the constness of the REFIID type, ensuring that the zero initializer is not > + discarded. > + > + Therefore, please do not regenerate this file. > +*/ The comment is not understandable. Shouldn't it read '"REFIID" should not be used, because the value is not "const"'? Ciao, Marcus

1 0

Wine/WineX and subfs
by Uwe Bonnes 27 Jun '04

27 Jun '04

Hallo, when trying to install programs from subfs mounted CDROMS, wine stumbled on several occasions (GetVolumenInformation?), running on Suse 9.1. I had not yet time to investigate deeper. However the announcement for WineX 3.3.2 tells explicit about changes for CDROMs and subfs for Suse9.1. Anybody from Transgaming reading hear, willing to submit a patch or explain the changes? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

FILE_GetNtStatus Converting errno 38 to STATUS_UNSUCCESSFUL
by Jürgen Leibner 27 Jun '04

27 Jun '04

Hi there, i'm trying to install a Software for Schools using wine-20040505-SuSELinux90.i586.rpm. After launching wine as user with: # wine setup.exe i get this message: .... # fixme:ntdll:FILE_GetNtStatus Converting errno 38 to STATUS_UNSUCCESSFUL Is anybody out there, who is able to explain what happens and what to do to get succsess? Thanks, Jürgen

3 3

Re: Change Desktopsize for _INS5576._MP in config
by Uwe Bonnes 27 Jun '04

27 Jun '04

>>>>> "Uwe" == Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: Uwe> Changelog: documentation/samples/config: Uwe> [AppDefaults\\_INS5576._MP\\x11drv] Change Desktop size to 800x600 Uwe> With a desktop siye of 640y480, Sage PC Kaufmann Setup aborts, Uwe> asking for higher resolution. Looking at http://frankscorner.org/modules.php?op=modload&name=Sections&file=index&req… the small desktopsize used until now for _INS5576._MP seems to cause problems with the photoshop installer too... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Suppressing NTDLL Relay messages
by Uwe Bonnes 27 Jun '04

27 Jun '04

Hallo, as the include and exclude lists for relay logging are initialized later than our ntdll is loader, relay logs contain all ntdll calls, even if the user didn't request them. Does anybody have an idea how to make the ntdll relay behave better? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: dbghelp crashes
by Eric Pouech 27 Jun '04

27 Jun '04

Jon Griffiths a écrit : > Hi, > > Some overly long stabs cause crashes when debug tracing is enabled. > > Cheers, > Jon > > +dlls/dbghelp/stabs.c > Prevent the debug buffer from overflowing on long stabs You shouldn't use debugstr_an with a fixed value, since all strings are '\0' terminated. Either fix dlls/ntdll/debugtools.c to handle properly those long string conditions (and remove the ugly call to abort()), or use min(256, strlen(ptr)) as the actual length of the string in debugstr_an calls. I'd prefer the first solution. A+

1 0

Re: wine/loader preloader.c
by Mike Hearn 27 Jun '04

27 Jun '04

On Sat, 2004-06-26 at 08:25 -0500, Mike McCormack wrote: > I think a better fix is to define it if it's missing. This commit by Alexandre should fix the segfaults people have been seeing on Fedora Core 2. Either of the two patches just sent are correct BTW, Red Hat 9/Fedora Core 1 do not place AT_SYSINFO* headers in the ELF startup auxiliary vector. thanks -mike

2 1

Jump to page:

2025

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