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

Re: Any experts on IsDialogMessage

by Dmitry Timoshkov

"Bill Medland" <billmedland(a)mercuryspeed.com> wrote: > I am just about to start concentrating on IsDialogMessage, especially in the > non-dialog context. Our program (suite) uses ActiveX controls extensively > and is difficult to use because the TAB handling in particular is totally > wrong. Probably what really makes Tab handling wrong is a not correct behaviour of GetNextDlgTabItem and GetNextDlgGroupItem. I was intending to fix them at some point, but it seems I have no time to work on them and won't have it in the near future. It would be great to have a test suite for that APIs as well. -- Dmitry.

Jan. 3, 2004

Re: Printing bugfixes

by Dmitry Timoshkov

"Mike Hearn" <mike(a)theoretic.com> wrote: > + num = sizeof(PrinterName); > + if (!GetDefaultPrinterW(PrinterName, &num)) > + WCHAR default_name[255]; > + DWORD default_name_size = sizeof(default_name); > + > + if (GetDefaultPrinterW(default_name, &default_name_size) == 0) { You should pass the size of buffer in characters, not in bytes to GetDefaultPrinter. -- Dmitry.

Jan. 3, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Mike McCormack

Juan Lang wrote: > File I/O, fine. But how about named pipes? > Mailslots? They are implemented with nearly the same > SMBs, and belong in kernel32 or ntdll. netapi32 needs > 'em too, for these two functions. I'm happy to work with you (or even do most of the work) to put named pipes and mailslots into the kernel. We just need to figure out a way to reuse what's already in the kernel (smbfs) in a sensible way. I was thinking of making a new socket family or something along those lines... Mike

Jan. 3, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Juan Lang

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > As I said already, IMO the file I/O stuff should go > in the kernel. The > current approach is broken, as you noted in your > FIXMEs. File I/O, fine. But how about named pipes? Mailslots? They are implemented with nearly the same SMBs, and belong in kernel32 or ntdll. netapi32 needs 'em too, for these two functions. I'll be happy to address the FIXMEs, but the most egregious of them (potential buffer overruns) are still in the Wine tree--I modified the existing code, and fixed some of them as I was at it. This isn't an argument to get this stuff committed as-is. I just want to find out what direction to take, so that this can be committed. > Yes it breaks parallel makes. Okay, I'll put it into a static lib. --Juan __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 3, 2004

Using winebuild explicitly

by Ralf Juengling

Hi Dimi, On Wed, 2003-12-31 at 16:47, Dimitrie O. Paun wrote: > On December 31, 2003 07:42 pm, Ralf Juengling wrote: > > okay, now it's as before: > > As I said, I think there's something wrong with your > ld setup. You need to have /usr/local/lib (where > the libwine library is) in your /etc/ld.so.conf: I tried this today, (adding /local/lib to /etc/ld.so.conf) but it didn't make a difference. I then looked into winegcc.c and winewrap.c to find out what winwgcc is actually doing. It is creating a shared library (dll) and a little wrapper executable to load the shared library. This should not be necessary with the code in question and I would rather like to build just one executable. So I wrote a Makefile that does this (not using winegcc & co) by calling winebuild explicitly (see below). It seems to work, but when I start the executable by wine phaeaco.exe.so I see the application's windows appearing and immediately disappearing and get the following error messages: err:win:WIN_FindWndPtr window 0x20030 belongs to other process err:win:WIN_FindWndPtr window 0x20030 belongs to other process I wonder whether this error has to do with the way I built the executable. The Makefile is as follows: ------ Makefile ------------------------------------------ INCLUDE_PATH = /local/include/wine LIBRARY_PATH = /local/lib # This should be replaced by wildcard expression as soon as all # sources actually participate in the built. PHAEACO_CSRCS = ../gensrc/Statist.c PHAEACO_CXXSRCS = Experim.cpp Login.cpp Phaeaco.cpp TextWnd.cpp \ Intrface.cpp Mentor.cpp Solver.cpp List.cpp ... (some more) PHAEACO_RCSRCS = phaeaco.rc PHAEACO_DLLS = advapi32 comdlg32 gdi32 kernel32 odbc32 ole32 \ oleaut32 shell32 user32 winspool winmm comctl32 DEFINES = -D__WINE__ INCLUDES = -I. -I../geninc -I../coginc -I$(INCLUDE_PATH) -I$(INCLUDE_PATH)/windows CC = gcc CFLAGS = -g -fpack-struct $(DEFINES) CXX = g++ CXXFLAGS = -g -fpack-struct $(DEFINES) CPPFLAGS = $(INCLUDES) OBJS = $(PHAEACO_CSRCS:.c=.o) $(PHAEACO_CXXSRCS:.cpp=.o) RESS = $(PHAEACO_RCSRCS:.rc=.res) LDFLAGS = -L$(LIBRARY_PATH) -L$(LIBRARY_PATH)/wine LIBS = -lwine -lm WBLIBS = $(patsubst %,-l%,$(PHAEACO_DLLS)) phaeaco.exe.so : $(OBJS) winebuild -o phaeaco.spec.c --exe $(@) -mgui $(OBJS) $(RES) $(LDFLAGS) $(WBLIBS) gcc -o phaeaco.spec.o -c phaeaco.spec.c $(CXX) -shared -Wl,-Bsymbolic,-z,defs -o $@ phaeaco.spec.o $(OBJS) $(LDFLAGS) $(LIBS) strip --strip-all $(@) %.o : %.cpp $(CXX) -c $(CXXFLAGS) $(CPPFLAGS) -o $@ $< %.res : %.rc wrc $(DEFINES) $(INCLUDES) -o $@ $< clean: rm -f ./*.o ../gensrc/*.o ../cogsrc/*.o -- Ralf Juengling <juenglin(a)cse.ogi.edu>

Jan. 3, 2004

Winetest progress bar

by Ferenc Wagner

Hi, I put together a feedback window for winetest. The code is somewhat inside-out to make it less intrusive, and the dialog is ugly. Where can one find a dialog editor? Anyway: 1. If compiled with Winelib, the dialog stays on screen after the main thread finishes with the tests; under Windows, it disappears at once. 2. I am not sure what to do with the console which pops up under Windows. Under Wine it comes and goes. 3. When the cross-compiled version run under Wine the GUI thread throws an exception at the very end. It seems to come from the statusbar's WM_PAINT. I am clueless. 4. How can I convert the icons into ASCII to put them into the resource script? 5. Do we actually need textual output at all? Comments are welcome. Find the programs/winetest directory enclosed. A cross-compiled binary is also available at <http://afavant.elte.hu/~wferi/wine>. Feri.

Jan. 2, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> writes: > Yeah, that's why I emailed the list twice before > asking how to go about it. Is making a static SMB > library preferrable? I haven't yet discovered the > interface MS uses to SMB (public or private), so I > haven't been able to hide it in the real place. As I said already, IMO the file I/O stuff should go in the kernel. The current approach is broken, as you noted in your FIXMEs. > As far as not building properly, umm.. it builds and > runs for me. You think one dll might link stale .o's, > or?? Yes it breaks parallel makes. -- Alexandre Julliard julliard(a)winehq.com

Jan. 2, 2004

Re: Hack for the '-pthread' at make depend

by Alexandre Julliard

"P. Christeas" <p_christ(a)hol.gr> writes: > On my configuration, the 'artsc-config' script outputs '-pthread' along with > the '-Isth' entries. That broke the 'makedep' procedure. > It's trivial. The following patch handles this. The right fix is to get rid of that option at configure time (or better get rid of the config script at all, this stuff is broken anyway). -- Alexandre Julliard julliard(a)winehq.com

Jan. 2, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Juan Lang

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > You can't share C files across dlls, this violates > dll separation and it won't build properly. Yeah, that's why I emailed the list twice before asking how to go about it. Is making a static SMB library preferrable? I haven't yet discovered the interface MS uses to SMB (public or private), so I haven't been able to hide it in the real place. As far as not building properly, umm.. it builds and runs for me. You think one dll might link stale .o's, or?? --Juan __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 2, 2004

Re: Endless WM_PAINT loop fix

by Alexandre Julliard

Rein Klazes <rklazes(a)xs4all.nl> writes: > Changelog: > windows : painting.c > If RedrawWindow is called with the RDW_INVALIDATE flag, if the > UpdateRgn parameter is a NULLREGION and the Window has no update > region yet, ignore the call. This should be integrated with the update region calculations, we shouldn't add such special cases outside of the main code. -- Alexandre Julliard julliard(a)winehq.com

Jan. 2, 2004