January 2007 - Wine-Devel - list.winehq.org

Re: skipping incompatible libwine build problem.

by Matthew Watchinski

Yup that works. Thanks for the help. Cheers, -matt Robert Shearman wrote: > Matthew Watchinski wrote: >> simpleapp_exe_LDFLAGS = -mwindows \ >> -mno-cygwin \ >> -municode \ >> -mconsole \ >> -Wb,--verbose >> > > I think you need to add "-m32" here. >

Jan. 31, 2007

Re: test.winehq.com status

by Paul Vriens

Felix Nawothnig wrote: > Hi. Anyone knows what happened to test.winehq.com/data? There has been > no new crossbuilds for quite some time now... > > Felix > > > Hi, I did sent an email to Paul Millar, but no reply yet. You can see what goes wrong with the build btw.: http://quisquiliae.ph.gla.ac.uk/crossbuild-logs/ Cheers, Paul.

Jan. 31, 2007

Re: Donation for your work on Direct 3D

by Stefan Dösinger

Hi, Thanks for the offer :-) I am employed by CodeWeavers, so its cw where you should donate to. I think the best way of doing so is to just buy a copy of CrossOver :-) Stefan > 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?

Jan. 31, 2007

Donation for your work on Direct 3D

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

Jan. 31, 2007

re: Please help me debug wineserver

by Misha Koshelev

I guess I should have replied to the whole list. On Tue, 2007-01-30 at 11:03 -0800, Dan Kegel wrote: > 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? http://bugs.winehq.org/show_bug.cgi?id=6992 > > > 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. Have submitted a patch to wine-patches. The problem occurs because end_wait does not modify thread->wait in any meaningful way until it is done processing it, so if a user APC is sent to the same thread that causes the thread to be woken again from one of the destroy_object functions (or anything else that causes the thread to be woken again from one of the destroy/release_object functions that end_wait calls), end_wait will try to process the same thread->wait and will get in trouble because it is already being processed by the end_wait that called it. This patch fixes that by saying that a process will not be woken when it is in the middle of being woken again. If anyone has comments about the patch, I would appreciate to hear them (I have attached it here too just in case). > > > 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. Same behavior on git, 0.9.30, 0.9.29, and 0.9.22. > - Dan Misha

Jan. 31, 2007

Re: skipping incompatible libwine build problem.

by Robert Shearman

Matthew Watchinski wrote: > simpleapp_exe_LDFLAGS = -mwindows \ > -mno-cygwin \ > -municode \ > -mconsole \ > -Wb,--verbose > I think you need to add "-m32" here. -- Rob Shearman

Jan. 31, 2007

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);'

Jan. 31, 2007

Re: skipping incompatible libwine build problem.

by Matthew Watchinski

Sure, attached. Thanks -matt Robert Shearman wrote: > Matthew Watchinski wrote: >> Linux ebx 2.6.17-10-generic #2 SMP Tue Dec 5 21:16:35 UTC 2006 x86_64 >> GNU/Linux >> >> > ... >> 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 >> >> > ... >> 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? >> > > The CXXFLAGS you specified aren't getting used. Can you send the entire > makefile? > ### Generated by Winemaker SRCDIR = . SUBDIRS = DLLS = simpleapp.exe EXES = simpleapp.exe ### Common settings CXXFLAGS = -Wall -Wextra -Wwrite-strings -Wcast-align -Wsign-compare -pedantic -m32 CEXTRA = -mno-cygwin -municode -mconsole -Wb,--exe -Wb,-w CXXEXTRA = -mno-cygwin -municode -mconsole -Wb,--exe -Wb,-w RCEXTRA = INCLUDE_PATH = DLL_PATH = LIBRARY_PATH = LIBRARIES = DEFINES = -DCOMMAND_LINE -DWINDOWSNATIVE -DBUILD_CLI ### simpleapp.exe sources and settings simpleapp_exe_MODULE = simpleapp.exe simpleapp_exe_C_SRCS = simpleapp_exe_CXX_SRCS= simpleapp.cpp bugList.cpp simpleapp_exe_RC_SRCS = simpleapp_exe_LDFLAGS = -mwindows \ -mno-cygwin \ -municode \ -mconsole \ -Wb,--verbose simpleapp_exe_DLL_PATH= simpleapp_exe_DLLS = odbc32 \ ole32 \ oleaut32 \ winspool simpleapp_exe_LIBRARY_PATH= simpleapp_exe_LIBRARIES= uuid simpleapp_exe_OBJS = $(simpleapp_exe_C_SRCS:.c=.o) \ $(simpleapp_exe_CXX_SRCS:.cpp=.o) \ $(simpleapp_exe_RC_SRCS:.rc=.res) ### Global source lists C_SRCS = $(simpleapp_exe_C_SRCS) CXX_SRCS = $(simpleapp_exe_CXX_SRCS) RC_SRCS = $(simpleapp_exe_RC_SRCS) ### Tools CC = winegcc CXX = wineg++ RC = wrc ### Generic targets all: $(SUBDIRS) $(DLLS:%=%.so) $(EXES:%=%.exe) test: ./run-tests.sh ### Build rules .PHONY: all clean dummy $(SUBDIRS): dummy @cd $@ && $(MAKE) # Implicit rules .SUFFIXES: .cpp .rc .res DEFINCL = $(INCLUDE_PATH) $(DEFINES) $(OPTIONS) .c.o: $(CC) -c $(CFLAGS) $(CEXTRA) $(DEFINCL) -o $@ $< .cpp.o: $(CXX) -c $(CXXFLAGS) $(CXXEXTRA) $(DEFINCL) -o $@ $< .cxx.o: $(CXX) -c $(CXXFLAGS) $(CXXEXTRA) $(DEFINCL) -o $@ $< .rc.res: $(RC) $(RCFLAGS) $(RCEXTRA) $(DEFINCL) -fo$@ $< # Rules for cleaning CLEAN_FILES = y.tab.c y.tab.h lex.yy.c core *.exe *.orig *.rej \ \\\#*\\\# *~ *% .\\\#* clean:: $(SUBDIRS:%=%/__clean__) $(EXTRASUBDIRS:%=%/__clean__) $(RM) $(CLEAN_FILES) $(RC_SRCS:.rc=.res) $(C_SRCS:.c=.o) $(CXX_SRCS:.cpp=.o) $(RM) $(DLLS:%=%.so) $(EXES:%=%.exe.so) $(EXES:%.exe=%) $(SUBDIRS:%=%/__clean__): dummy cd `dirname $@` && $(MAKE) clean $(EXTRASUBDIRS:%=%/__clean__): dummy -cd `dirname $@` && $(RM) $(CLEAN_FILES) ### Target specific build rules DEFLIB = $(LIBRARY_PATH) $(LIBRARIES) $(DLL_PATH) $(simpleapp_exe_MODULE).so: $(simpleapp_exe_OBJS) $(CXX) $(simpleapp_exe_LDFLAGS) -o $@ $(simpleapp_exe_OBJS) $(simpleapp_exe_LIBRARY_PATH) $(DEFLIB) $(simpleapp_exe_DLLS:%=-l%) $(simpleapp_exe_LIBRARIES:%=-l%) $(simpleapp_exe_MODULE).exe: $(simpleapp_exe_OBJS) $(CXX) $(simpleapp_exe_LDFLAGS) -o $@ $(simpleapp_exe_OBJS) $(simpleapp_exe_LIBRARY_PATH) $(DEFLIB) $(simpleapp_exe_DLLS:%=-l%) $(simpleapp_exe_LIBRARIES:%=-l%)

Jan. 31, 2007

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

Jan. 31, 2007

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.

Jan. 31, 2007