wine-devel January 2007

137 participants
274 discussions

by Mirek

Hi Stefan and Henry, i would like to send you 35 EUR or 45 USD for your work on Direct 3D in wine, how can i do that? Can you send me your account number and prefered currency? Mirek Slugeň Czech Republic

17 years, 3 months

Re: [Bug 6689] Created links do not reflect WINEPREFIX used

by Lei Zhang

Setting the Exec= line in a .desktop file to: WINEPREFIX=foo wine bar worked in KDE. In Gnome, it works if "run from the terminal" is set. Unfortunately the Freedesktop spec for desktop entries does not specify a way to add environment variables. So yes, it looks like we'll need a wrapper script, or perhaps add a --prefix option to Wine? On 1/27/07, Wine Bugs <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=6689 > > > > > > ------- Additional Comments From vitaliy(a)kievinfo.com 2007-28-01 01:49 ------- > This is not going to work - it's not standard compliant. And I think it won't > work on Gnome either. The only way this can be fixed atm is using some wrapper > script. > > -- > Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > >

17 years, 3 months

Detect screen resolution change errors

by Francois Gouget

When I run the dlls/d3d9/device conformance test on Windows in VMware, I get a trace telling me that IDirect3D9_CreateDevice() failed and returned 0x8876086c. This seems to be because Windows has trouble changing the screen resolution when running in VMware (though it's perfectly capable of doing it when I go through the control panel). But when I run the test in Wine I'm getting a test failure because: * IDirect3D9_CreateDevice() did not change the screen resolution * but it returned success so that the screen size checks fail That's because XRandR fails to change the resolution (for whatever reason, it's irrelevant here). Wine detects that but does not report the information to the upper layers. So I have made a couple of patches: * the first one detects when XRandR, XVidMode or some low level routine fails to change the screen resolution, and propagates this so ChangeDisplaySettingsEx() returns an error * the second one modifies IWineD3DDeviceImpl_CreateAdditionalSwapChain() so it detects when ChangeDisplaySettingsEx() propagates that error upstream too Now the dlls/d3d9/device test succeeds on my machine (all while loudly complaining something is wrong): [...] err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? fixme:d3d9:IDirect3DDevice9Impl_CreateAdditionalSwapChain (0x1c4358) call to IWineD3DDevice_CreateAdditionalSwapChain failed fixme:d3d9:IDirect3D9Impl_CreateDevice (0x171448) D3D Initialization failed for WineD3DDevice 0x174ee8 device.c:741:could not create device, IDirect3D9_CreateDevice returned 0x8876086c device.c: 245 tests executed (0 marked as todo, 0 failures), 0 skipped. I have attached the relevant patches. Does this look ok to the DirectX gurus? -- Francois Gouget fgouget(a)codeweavers.com

17 years, 3 months

Re: [lostwages] Update download-deb page with better information, error fixes

by Detlef Riekenberg

On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: > + > +<p>While there is currently no Wine package explicitly designed for > the 64-bit version > +of Ubuntu, there are several hacks that can be used to install the > 32-bit package > +into the 64-bit distribution and have it function normally. See > +<a href="https://wiki.ubuntu.com/I386WineInAmd64">this page on the > Ubuntu wiki</a> > +for more details.</p> IMHO, a link to our own Wiki should be placed on the download-deb page http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964c… And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and https://help.ubuntu.com/community/WineForAMD64 The provided automatic installation script includes the sidenet-script. Please include a BIG WARNING, that this is never supported by winehq and the users need a clean wine, before they ask for help on #winehq or wine-users(a)winehq.org You mention sidenet on that page: "If you followed the manual instructions you need to install the Sidenet script" This is wrong. Please remove that line! Even, when the sidenet-script might help some users to run an app, "you need to install the Sidenet script" is wrong! -- By by ... Detlef

17 years, 3 months

skipping incompatible libwine build problem.

by Matthew Watchinski

Hopefully this is the right mailing list to ask this. If not please point me to the correct list. I have a simple application that use to build just fine using libwine/wine-0.9.30 on ubuntu edgy 32-bit. I just upgraded to a 64 bit system and got wine-0.9.30 installed and working, however, now my application doesn't build. uname -a: Linux ebx 2.6.17-10-generic #2 SMP Tue Dec 5 21:16:35 UTC 2006 x86_64 GNU/Linux When i run make everything builds correctly but it won't link and it exits as follows: wineg++ -c -Wall -Wextra -Wwrite-strings -Wcast-align -Wsign-compare -pedantic -m32 -mno-cygwin -municode -mconsole -Wb,--exe -Wb,-w -DCOMMAND_LINE -DWINDOWSNATIVE -DBUILD_CLI -o simpleapp.o simpleapp.cpp wineg++ -c -Wall -Wextra -Wwrite-strings -Wcast-align -Wsign-compare -pedantic -m32 -mno-cygwin -municode -mconsole -Wb,--exe -Wb,-w -DCOMMAND_LINE -DWINDOWSNATIVE -DBUILD_CLI -o simpleappList.o simpleappList.cpp wineg++ -mwindows -mno-cygwin -municode -mconsole -o simpleapp.exe.so simpleapp.o simpleappList.o -lodbc32 -lole32 -loleaut32 -lwinspool -luuid /usr/bin/ld: skipping incompatible /usr/local/lib/libwine.so when searching for -lwine /usr/bin/ld: skipping incompatible /usr/local/lib/libwine.so when searching for -lwine /usr/bin/ld: skipping incompatible /usr/local/lib/libwine.so when searching for -lwine /usr/bin/ld: cannot find -lwine collect2: ld returned 1 exit status winegcc: g++ failed. make: *** [simpleapp.exe.so] Error 2 Everything in /usr/local/lib looks right to me. ebx:~/Downloads/cvs/sfeng/research/tools/doccheck$ file /usr/local/lib/libwine.so* /usr/local/lib/libwine.so: symbolic link to `libwine.so.1.0' /usr/local/lib/libwine.so.1: symbolic link to `libwine.so.1.0' /usr/local/lib/libwine.so.1.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped And the makefile is pretty simple The only lines I've modified from the original winemaker Makefile are these: CXXFLAGS = -Wall -Wextra -Wwrite-strings -Wcast-align -Wsign-compare -pedantic -m32 #CXXFLAGS = CEXTRA = -mno-cygwin -municode -mconsole -Wb,--exe -Wb,-w CXXEXTRA = -mno-cygwin -municode -mconsole -Wb,--exe -Wb,-w RCEXTRA = INCLUDE_PATH = simpleapp_exe_LDFLAGS = -mwindows \ -mno-cygwin \ -municode \ -mconsole I assume I'm missing some magic ld switch, but I'm not sure what. Can anyone point me in the right direction? Thanks -matt

17 years, 3 months

re: Please help me debug wineserver

by Dan Kegel

Misha wrote: > I am new to wine programming but have a fair amount of > experience with C/C++ programming in general. I have > recently decided to make the Vector NTI application work > on Wine, and after overcoming quite a few installation > difficulties by making an install shell script, Cool. Can you file a bug about those problems, and attach the shell script as a workaround? > I have run in to a problem that I have traced down to > wineserver. This problem occurs after repeatedly changing > folders in the Vector NTI "Open Molecule File" dialog, > which does not use the standard open file Windows dialog > (e.g., the "Open Shortcut" dialog in the same program works > fine). Wineserver crashes with the following error message: > > wineserver: object.c:274: release_object: Assertion `obj->refcount' failed. You also have a bug opened for this, http://bugs.winehq.org/show_bug.cgi?id=7286 I see you also have a possible workaround there. > On looking at the output of WINEDEBUG=+server, it seems > that the "Vector NTI" thread is woken up, and then receives > a USER_APC, at which time this crash occurs. What version of Wine? There were recent changes in APC handling in wine-0.9.30 (and perhaps 0.9.29) that may have broken this. If you can verify that this worked ok in earlier versions like 0.9.27, that would help. Alexandre is the expert on this. He's on vacation but he'll want to take a look when he gets back. - Dan

17 years, 3 months

Re: wine + visual basic

by Alex Villacís Lasso

Joshua Masiko escribió: > hello, > I got your email addresses off the wine bug database at > http://bugs.winehq.org/show_bug.cgi?id=6638. > I'm looking at moving a custom Visual Basic 6 windows application to > linux + > wine. > > However I cannot find any good step by step documentation on how to do > this. > I have SUSE 10, wine 0.9.29. > I tried a simple test case which throws an error "ActiveX can't create > object" > > dim cn as adodb.connection > set cn=new adodb.connection 'error on this statement > > > Can u give me any pointers on what i need in order to run a visual basic > application which > uses an ODBC DSN (postresql) and ADO>=2.5 successfully. > I intend to publish a detailed step by step howto on this topic for other > potential wine users if successfull > The very first step is to ensure ADO is actually installed in the Wine directory. Usually the MSVB6 installer for the application (created with the Package and Deployment Wizard) takes care of this, but installing MDAC 2.x works too (I have installed MDAC 2.8). Wine currently provides no replacements for ADO libraries or objects, so doing either of these options is mandatory. It seems that you are trying to connect via ADO and ODBC. You should first have an Unix ODBC driver installed, since the ODBC support in Wine is simply a pass-through layer to the Unix ODBC support in the system. If you are compiling Wine from sources, you should (for example) have *both* unixODBC and unixODBC-devel RPM packages installed (or the equivalent bundles in SUSE). Otherwise, Wine will be compiled without ODBC support. You should then create (in unixODBC, not Wine) an ODBC data source for your database of choice, and verify (/usr/bin/isql) that you can actually connect and read data from it before trying to do anything from within Wine. Also, please note that Wine (currently) only supports as much ODBC as the underlying ODBC support does. In particular, the following syntax: > Set oConexion = New ADODB.Connection ... > oConexion.Open ConnectionString:="Driver={Microsoft Access Driver > (*.mdb)};DBQ=..." in which the driver is specified within curly braces, is *NOT* supported under Wine, nor is any variation of this method. You must specify a data source that appears in your ODBC configuration file in /etc/odbc.ini . Of course, you might just bypass the ODBC layer and do something like this: > Set oConexion = New ADODB.Connection ... > oConexion.Provider = "Microsoft.Jet.OLEDB.4.0" > oConexion.Properties("Jet OLEDB:Database Password") = > "somepassword" > > oConexion.Open ConnectionString:=App.Path & "\" & DATABASE_FILE This method works as long as all the corresponding providers (which are also ActiveX objects) are correctly registered. In this way, no ODBC code is involved and the Windows code directly manages the database connection. However, all the necessary providers and drivers must be installed by your application installer (again, the Packaging and Deployment Wizard should take care of these dependencies). Hope this helps. Alex Villacís Lasso -- perl -e '$x = 2.4; print sprintf("%.0f + %.0f = %.0f\n", $x, $x, $x + $x);'

17 years, 3 months

Re: ras.h added szDeviceType pound defines

by Michael Stefaniuc

John Smith wrote: > This is my first patch uhh ever so I guess don't just throw it into the > source without wariness. =P Welcome to Wine. > That said it just updates the list of #define strings that are acceptable > device types for RASDEVINFO and RASENTRY. This will fix some compilation > issues against ras.h. > > There is more I could fix in ras.h but yeah my first time doing this, want > to see how the patch process works,blah blah. The Wine maintainer is this week on vacation so your patch would be probably commited earliest in 1 week. Do you know this page? http://www.winehq.org/site/sending_patches > Anyway if anything about how I did this is wrong please let me know I hope > to be a regular wino too =) Not really wrong but some nitpick. > ------------------------------------------------------------------------ > > From d294ed7e538a130ac10fad4bb2ac6a0f93120060 Mon Sep 17 00:00:00 2001 > From: John Klehm <xixsimplicityxix(a)gmail.com> > Date: Tue, 30 Jan 2007 15:24:56 -0600 > Subject: [PATCH] Added additional szDeviceType pound defines. These additions reflect > http://msdn2.microsoft.com/en-us/library/aa377274.aspx > and have been verified by a test program on Windows2000 and XP. > --- > include/ras.h | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/include/ras.h b/include/ras.h > index c1f6d5c..ef289f4 100644 > --- a/include/ras.h > +++ b/include/ras.h > @@ -43,6 +43,25 @@ extern "C" { > #define RASDT_Modem "modem" > #define RASDT_Isdn "isdn" > #define RASDT_X25 "x25" > +/* more szDeviceType strings for RASDEVINFO > + * from MSDN > + * http://msdn2.microsoft.com/en-us/library/aa377274.aspx > + * values taken from a test program on windows 2000 and XP > + * Following are Windows 2000 and Windows XP values > + * and above? > + */ You do not need this comment. MSDN is so often updated that the link will soon point to the void. Just document here the differences to MSDN or other outstanding info. Please use the same identing style like for the existing RASDT_* defines. > +#define RASDT_Vpn "vpn" > +#define RASDT_Pad "pad" > +#define RASDT_Generic "GENERIC" > +#define RASDT_Serial "SERIAL" > +#define RASDT_FrameRelay "FRAMERELAY" > +#define RASDT_Atm "ATM" > +#define RASDT_Sonet "SONET" > +#define RASDT_SW56 "SW56" > +#define RASDT_Irda "IRDA" > +#define RASDT_Parallel "PARALLEL" > +/* Windows XP values. And above? */ > +#define RASDT_PPPoE "PPPoE" > > #define RASBASE 600 > #define ERROR_BUFFER_TOO_SMALL (RASBASE+3) bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

17 years, 3 months

Re: advapi32: Fix prototypes for StartServiceCtrlDispatcher[AW]

by Francois Gouget

On Wed, 31 Jan 2007, Bang Jun-Young wrote: > Please ignore this patch. There are subtle differences between GCC and MSC I didn't > notice at the moment of producing this patch. It would be better to keep it local > in my own repos. ;-) [...] > > -BOOL WINAPI StartServiceCtrlDispatcherA( LPSERVICE_TABLE_ENTRYA servent ) > > +BOOL WINAPI StartServiceCtrlDispatcherA(CONST LPSERVICE_TABLE_ENTRYA servent) Maybe your troubles come from the fact that this should be: BOOL WINAPI StartServiceCtrlDispatcherA(CONST SERVICE_TABLE_ENTRYA* servent) The former means that you are not allowed to modify the servent pointer, while the latter means you are not allowed to modify the structure pointed to by servent. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

17 years, 3 months

Re: Patch for Bugzilla Bug 6323

by Dmitry Timoshkov

"Dean Kusler" <deankus(a)gmail.com> wrote: > In dlls/winex11.drv/keyboard.c, XmbLookupString was being called with > KeyRelease events, which has undefined behavior (in this case, it fails to > return a valid keysym for numpad key releases). By instead calling > XLookupString in the case of a KeyRelease, we can obtain a valid keysym. While reviewing your patch in bugzilla I overlooked that you have added a check for (e.type == KeyPress) X11DRV_ToUnicodeEx as well. There is no need for that, we explicitly set e.type = KeyPress there. -- Dmitry.

17 years, 3 months

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 January 2007