wine-devel March 2007

wine-devel@winehq.org

162 participants
368 discussions

Re: [try3, 1/4] msi: Added handlers for JScript/VBScript actions that call one script function.
by James Hawkins 01 Mar '07

01 Mar '07

On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > I am resending the entire patchset as James Hawkins suggested. The only > changes from my previous patchset are in patch #2 (add full IDL from > Windows Installer 3.0 vs 2.0 in the old patchset) and patch #3 (added > more proper variant handling using GetDispId as per Rob's suggestion and > removed unnecessary comments as per James' suggestion). > > Just as a reminder, these patches add JScript/VBScript support for > MSI (as the MSI specs specifically state that applications that need > this functionality must install Windows Script themselves) and partial > but easily expandable OLE automation functionality for MSI. As a proof > of concept, sufficient automation support is added to fix bug #7357. > > Patch #1 creates custom action handlers for all 8 script custom action > types using a framework similar to that used for calling DLL functions. > These custom action handlers all converge on one function that is passed > a script and a function to be called (if any), and it outputs these in a > FIXME. > > Changelog: > > * msi: Added handlers for JScript/VBScript actions that call one script > function. > +static DWORD WINAPI ACTION_CallScript( const LPGUID guid ) +{ + msi_custom_action_info *info; + MSIHANDLE hPackage; + UINT r = ERROR_FUNCTION_FAILED; + + info = find_action_by_guid( guid ); + if (!info) + { + ERR("failed to find action %s\n", debugstr_guid( guid) ); + return r; + } + + FIXME("function %s, script %s\n", debugstr_w( info->function ), debugstr_w( info->dllname ) ); + + hPackage = alloc_msihandle( &info->package->hdr ); + if (hPackage) + { + r = S_OK; + MsiCloseHandle( hPackage ); + } + else + ERR("failed to create handle for %p\n", info->package ); + + return r; +} Looks like you're leaking info. If you're going to go down this route, leaving a stub ACTION_CallScript, then just print the FIXME and be on your way. Each patch should be atomic, and assuming this patch gets applied but none of the others do, you're left with some weird code that allocates a handle then frees it for no apparent reason. + r = MSI_RecordReadStream(row, 2, buffer, &sz); + if (r != ERROR_SUCCESS) + { + msi_free(buffer); + return r; + } + + buffer[sz] = 0; + szw = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, -1, bufferw, 0); + bufferw = msi_alloc(sizeof(WCHAR)*szw); + if (!szw) + { + msi_free(bufferw); + return ERROR_FUNCTION_FAILED; + } + + r = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, -1, bufferw, szw); + msi_free(buffer); + if (!r) + { + msi_free(bufferw); + return ERROR_FUNCTION_FAILED; + } This would be a lot cleaner if you used a 'goto done;' at each of these error points. Also, is there a reason you're not using strdupAtoW? done: msi_free(bufferw) ... return r; -- James Hawkins

2 1

re: Forum proposal
by Dan Kegel 01 Mar '07

01 Mar '07

Wojciech wrote: >But there's one thing with forums that IMVHO mailing-lists can't do. TBMS >forums build better comunities than mailing-lists. Mailing lists are just >concentrated on the topics, disallowing any OT. Good. Let's keep it that way. I think we have a great community as it is. If you really want a web interface that makes posting to the mailing list easy, maybe we could get Google Groups to carry wine-devel. It's as close to a nice web interface as you're going to get, I think. The other gateways I've seen between 'forums' and mailing lists all sucked, IMHO. - Dan

1 0

Re: [final, sorry] msi: Expand IDL file to contain all OLE automation interfaces.
by James Hawkins 01 Mar '07

01 Mar '07

On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > Ok, sorry about posting patches to uncomitted patches, I have > reintegrated these changes back into my patches. The change in this > patch is the IDL file now contains all OLE automation interfaces as of > native installer version 3.0 (as opposed to 2.0). > > As a reminder this is part 2 of 4 of my patchset: > > 1. > http://www.winehq.org/pipermail/wine-patches/2007-February/036359.html > 2. This patch > 3. Next patch > 4. > http://www.winehq.org/pipermail/wine-patches/2007-February/036362.html > You need to resubmit the whole series if you resubmit parts of it. -- James Hawkins

2 3

Unknown issue with test.winehq.org
by Paul Vriens 01 Mar '07

01 Mar '07

Hi, So finally we have a working winetest executable and the test.winehq.org scripts should be able to handle the new reports. Could someone have a look what the issue currently is on the webserver as I've sent several reports (a few hours ago) and they are not handled yet? Cheers, Paul.

3 5

Re: Re: Forum proposal
by brettholcomb＠bellsouth.net 01 Mar '07

01 Mar '07

I fully agree with Jonathan - the mail lists that have gone to forums I've dropped off. I can check the mail lists quickly, easily, filter as necessary and get what I need without having to sign on and wade through a bunch of posts. If people really want forums setup a forum and let those who want it use it. > > From: Jonathan Allen <jonathan(a)barumtrading.co.uk> > Date: 2007/03/01 Thu AM 11:20:18 EST > To: wine-devel(a)winehq.org > Subject: Re: Forum proposal > > On Thu, Mar 01, 2007 at 05:15:03PM +0100, Luis Carlos Busquets Pérez wrote: > > Instead of having the mailing lists, I think that a "forum" would increase > > and facilitate the group working. > > I could agree less. IMHO a mailing list works well by making sure that > everyone gets everything, without them needing to go anywhere to get it. > A forum wil immediately disenfranchise all thsoe who have no immediate > need to go and visit the forum site every day and so will miss important > annoucements and so on. Bad idea. > > Jonathan > > >

2 1

Forum proposal
by Luis Carlos Busquets Pérez 01 Mar '07

01 Mar '07

Dear all, Instead of having the mailing lists, I think that a "forum" would increase and facilitate the group working. I wonder if you share my view and who is in charge of the web serving so that trying to set up the forum. Luis C. Busquets Pérez T. +34 93 796 05 81 M. +32 473 353 128 M. +34 620501328

2 1

Error Invalid EXE Format when executing a exe.so built with winelib
by Roger Wimbert 01 Mar '07

01 Mar '07

Here is the Debug output: warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": /bb/home/.wine/dosdevices/z:/bb/s/bc/wine/dmsw.exe.so: cannot allocate memory in static TLS block warn:module:load_dll Failed to load module L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so"; status=c000007b warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": /bb/home/.wine/dosdevices/z:/bb/s/bc/wine/dmsw.exe.so: cannot allocate memory in static TLS block warn:module:load_dll Failed to load module L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so"; status=c000007b wine: could not load L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": Fehlerhaftes EXE-Format f³r It has something to do with TLS memory or threads, but the /lib/tls/libc.so is linked in: (rw 8 amd64) /bb/s/bc/wine 105>ldd dmsw.exe.so linux-gate.so.1 => (0xffffe000) libwine.so.1 => /usr/local/lib/libwine.so.1 (0x557be000) libm.so.6 => /lib/tls/libm.so.6 (0x558e8000) libc.so.6 => /lib/tls/libc.so.6 (0x5590a000) libdl.so.2 => /lib/libdl.so.2 (0x55a1f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x56555000) Our system: (rw 8 amd64) /bb/s/bc/wine 106>uname -a Linux amd64 2.6.5-7.193-smp #1 SMP Wed Jul 20 14:39:18 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux glibc has version 2.3.3 A simple program does work, but no program which uses threads. wine is created with the 32 bit libraries. If I use the original exe of my program with wine, it does work. Does anyone has an idea what is going wrong? The makefile is attached. Thanks a lot. ### Generated by Winemaker TOPSRCDIR = /bb/s TOPOBJDIR = /bb/s/bc/wine SRCDIR = . SUBDIRS = DLLS = EXES = dmsw.exe ### Common settings CEXTRA = -mno-cygwin -fno-pic -fno-PIC CXXEXTRA = -mno-cygwin CFLAGS = -D_DMSW RCEXTRA = RCFLAGS = -DBB_WINE INCLUDE_PATH = -I. -I/bb/nt/wine -I/bb/s/i -I/bb/fg/i -I/bb/ze/i -I/bb/fe/i -I/bb/pbm/i -I/bb/wb1/i DLL_PATH = LIBRARY_PATH = LIBRARIES = -lmsvcrt40 -lws2_32 -lversion -lnetapi32 -liphlpapi -lcomctl32 -lshlwapi -lwinmm ### dmsw.exe sources and settings dmsw_exe_MODULE = dmsw.exe dmsw_exe_C_SRCS = /bb/s/c/bbcrypt.c \ /bb/s/c/bbdes.c \ /bb/s/c/bbmalloc.c \ /bb/s/c/bbmd5.c \ /bb/s/c/bbo.c \ /bb/s/c/bbtwofish.c \ /bb/s/c/cmp.c \ /bb/s/c/costri.c \ /bb/s/c/cpy.c \ /bb/s/c/datec.c \ /bb/s/c/dfa.c \ /bb/fg/c/dgcode.c \ /bb/fg/c/dgvar.c \ /bb/s/c/dhinfo.c \ /bb/s/c/dholz.c \ /bb/fg/c/digcte.c \ /bb/fg/c/digecm.c \ /bb/fg/c/digranox.c \ /bb/fg/c/digvec.c \ /bb/s/c/dirview.c \ /bb/s/c/dirwalk.c \ /bb/s/c/dmsb.c \ /bb/s/c/dmsc.c \ /bb/s/c/dmsca.c \ /bb/s/c/dmse.c \ /bb/s/c/dmsf.c \ /bb/s/c/dmsfr.c \ /bb/s/c/dmsg.c \ /bb/s/c/dmsh.c \ /bb/s/c/dmshc.c \ /bb/s/c/dmsl.c \ /bb/s/c/dmsliz.c \ /bb/s/c/dmsm.c \ /bb/s/c/dmsmv.c \ /bb/s/c/dmsp.c \ /bb/s/c/dmsr.c \ /bb/s/c/dmss.c \ /bb/s/c/dmssb.c \ /bb/s/c/dmst.c \ /bb/s/c/dmstast.c \ /bb/s/c/dmsw.c \ /bb/s/c/dmswf.c \ /bb/s/c/dmswicon.c \ /bb/s/c/dmsy.c \ /bb/s/c/encode.c \ /bb/s/c/fileleng.c \ /bb/s/c/fordat.c \ /bb/s/c/gtypes.c \ /bb/fg/c/image.c \ /bb/fg/c/imgprint.c \ /bb/s/c/itoa.c \ /bb/fg/c/jpegconv.c \ /bb/s/c/lru.c \ /bb/s/c/ltoa.c \ /bb/s/c/map.c \ /bb/s/c/msleep.c \ /bb/s/c/packbits.c \ /bb/s/c/packdiff.c \ /bb/s/c/pfad.c \ /bb/fg/c/rgbtools.c \ /bb/s/c/rtt.c \ /bb/s/c/scrinfo.c \ /bb/s/c/set.c \ /bb/s/c/sockcom.c \ /bb/s/c/softdum.c \ /bb/s/c/swap.c \ /bb/s/c/syslog.c \ /bb/s/c/textino.c \ /bb/fg/c/tiffconv.c \ /bb/s/c/udpcom.c \ /bb/s/c/utoa.c \ /bb/s/c/vgl.c \ /bb/s/c/w32argv.c \ /bb/fg/c/w32bmp.c \ /bb/s/c/w32error.c \ /bb/s/c/w32font.c \ /bb/fg/c/w32ico.c \ /bb/s/c/w32macadr.c \ /bb/s/c/w32pfad.c \ /bb/s/c/w32pipe.c \ /bb/s/c/w32print.c \ /bb/s/c/w32puts.c \ /bb/s/c/w32reg.c \ /bb/fg/c/w32scalebmp.c \ /bb/s/c/w32screen.c \ /bb/s/c/w32scroll.c \ /bb/s/c/w32toolbar.c \ /bb/s/c/w32tools.c \ /bb/s/c/w32winms.c \ /bb/s/c/wsinit.c \ /bb/s/c/zeitc.c dmsw_exe_CXX_SRCS= dmsw_exe_RC_SRCS = /bb/nt/rc/dmsw/dmsw_wine.rc dmsw_exe_LDFLAGS = -mwindows \ -mno-cygwin dmsw_exe_DLL_PATH= dmsw_exe_DLLS = odbc32 \ ole32 \ oleaut32 \ winspool dmsw_exe_LIBRARY_PATH= dmsw_exe_LIBRARIES= uuid dmsw_exe_OBJS = $(dmsw_exe_C_SRCS:.c=.o) \ $(dmsw_exe_CXX_SRCS:.cpp=.o) \ $(dmsw_exe_RC_SRCS:.rc=.res) ### Global source lists C_SRCS = $(dmsw_exe_C_SRCS) CXX_SRCS = $(dmsw_exe_CXX_SRCS) RC_SRCS = $(dmsw_exe_RC_SRCS) ### Tools CC = winegcc CXX = wineg++ RC = wrc ### Generic targets all: $(SUBDIRS) $(DLLS:%=%.so) $(EXES:%=%.so) ### 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 *.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:%=%.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) $(dmsw_exe_MODULE).so: $(dmsw_exe_OBJS) $(CC) $(dmsw_exe_LDFLAGS) -o $@ $(dmsw_exe_OBJS) $(dmsw_exe_LIBRARY_PATH) $(DEFLIB) $(dmsw_exe_DLLS:%=-l%) $(dmsw_exe_LIBRARIES:%=-l%)

2 2

Re: [PATCH] generate stand alone AC_CONFIG_FILES() lines.
by Saulius Krasuckas 01 Mar '07

01 Mar '07

* On Tue, 27 Feb 2007, Marcus Meissner wrote: > Another try to generate stand alone AC_CONFIG_FILES lines > to make git merges easier. Thank you Marcus (and others) very much for that :)

1 0

Re: [9/12] WineD3D: When multithreading, call glFinish after drawing
by H. Verbeet 01 Mar '07

01 Mar '07

Would GL_NV_fence be usefull here?

2 1

Re: ntdll: implement NtAllocateLocallyUniqueId with server call (resend)
by Alexandre Julliard 01 Mar '07

01 Mar '07

Juan Lang <juan_lang(a)yahoo.com> writes: > Any feedback on this one? > > ChangeLog: implement NtAllocateLocallyUniqueId with server call In general it's better to define server-specific types based on simple C types instead of using Windows data types in server requests. This gives us more control about the data layout, and avoids confusion with things like long/LONG etc. -- Alexandre Julliard julliard(a)winehq.org

1 0

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