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. 2, 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. 2, 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. 2, 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. 2, 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. 2, 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

Re: netapi32: implement NetServerEnum and NetShareEnum

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> writes: > Relies on previously submitted SMB patch, > http://www.winehq.org/hypermail/wine-patches/2003/12/0231.html > > ChangeLog: partially implement NetServerEnum and > NetShareEnum using RAP over SMB You can't share C files across dlls, this violates dll separation and it won't build properly. -- Alexandre Julliard julliard(a)winehq.com

Jan. 2, 2004

Re: DMUSIC: my latest work

by Alexandre Julliard

Rok Mandeljc <rok.mandeljc(a)email.si> writes: > Hey everyone, > > I finally found some time to organise my dmusic work of last two months > in useful patch. Dmusic is now DX9 compatible, we have almost fully > implemented (but not working :( ) The dmusic_common.c thing is wrong, you can't use the same source file in multiple dlls, this won't build properly. Also you should not include private header files from other dlls, if definitions really have to be shared they should be in a common header somewhere in include/ or include/wine, though in most cases you should be able to avoid that. -- Alexandre Julliard julliard(a)winehq.com

Jan. 2, 2004

Re: Windows dll replacement with Linux library

by Dan Timis

Thanks Dimi, and "La multi ani" (Happy new year). I'm new to this so please bear with me. First I edited the Makefile and replaced gcc with winegcc. When I run "make" I get this error when it tries to link: could not open .def file for kernel32 Error: /usr/bin/winebuild failed. Error: /usr/bin/winewrap failed. Then, I ran ./configure --help and it says that you can use the "CC" var to specify the compiler. I started from scratch, set "export CC=winegcc", then ran configure again. The output looks like this: checking whether make sets {$MAKE}... yes checking for gcc... winegcc checking for C compiler default output... configure: error: C compiler cannot create executables Thanks, Dan On Wednesday, December 31, 2003, at 04:57 PM, Dimitrie O. Paun wrote: > On December 31, 2003 07:33 pm, Dan Timis wrote: >> I don't understand how Windows dlls and Linux libraries link and how >> functions are called. What am I missing? > > Please use winegcc to build the test app. It does a number of > housekeeping tasks behing the scene that might help. > > -- > Dimi. >

Jan. 2, 2004

wine-bugs Mailings Enhancement request

by Uwe Bonnes

A happy new year to everybody! As a lot of wine-bugs are reworked(mostly thanks to Markus), I get a lot of mails from wine-bugs. However it is hard to follow the threads by only getting information about the last status update. At least the information of the name of the originator of bug should be resent, perhaps even the last two or three status updates. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 2, 2004

Re: PATCH: Fix DLL constructors on OpenBSD

by Alexandre Julliard

wiml(a)underhill.hhhh.org (Wim Lewis) writes: > Use the GCC attribute((constructor)) syntax for DLL initializer hooks > if possible, instead of the inline-asm syntax. The dll init routine needs to be in the .init section in order to be called first, attribute((constructor)) is not good enough. Why doesn't it work on OpenBSD? Is the section name different? -- Alexandre Julliard julliard(a)winehq.com

Jan. 2, 2004

Re: Congradulations - windef.h

by Kirill Smelkov

On Thursday 01 January 2004 16:52, Mike Hearn wrote: > On Wed, 2003-12-31 at 17:26, Dimitrie O. Paun wrote: > > Are you using KDevelop to work on Wine? Is it OK? I'm a vim guy > > myself, and I've never used KDevelop, but I could maybe use some > > autocompletion :) > > If vim has something like emacs tag completion then you could use that - > I know etags works pretty well for me. I'm not saying you should use > emacs obviously, but I expect there is an equivalent or vimscript you > can use. > > Briefly, you can do "make etags" in the wine source root, wait a bit, > then two very useful features are available: > > M-. (find-tag) lets you locate any definition in the wine source tree > complete-tag lets you perform completion based upon those same tags. Mike, I'm not going to begin another flamewar, just decided to mention that vim too has all this features. In short you type 'CTRL-P' in insert mode to call autocomplete and :ta ... or 'CTRL-]' to locate a tag in source tree. Interested reader is refered to ":help i_CTRL-P" and ":help 'complete' " -- Kirill.

Jan. 2, 2004

Re: [WINEALSA] Fix compilation issue with ALSA 0.5

by Christian Costa

Christian Costa wrote: > Hi, > > This patch fixes a compilation issue with ALSA 0.5 (reported by Carl > Sopchak) > that appears when adding WaveIn support. > > Bye. > > Changelog : > Fix compilation issue with ALSA 0.5. > > Christian Costa titan.costa(a)wanadoo.fr > > > BTW: Happy new year to all! Bye, Christian

Jan. 2, 2004

Any experts on IsDialogMessage

by Bill Medland

Hi All Happy New Year to everyone and Welcome Back to Alexandre 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. I will be using a trivial program with IsDialogMessage inserted into the main loop and will be trying to figure out the undocumented behaviour of this function (e.g. I am sure it internally handles redirecting to children etc.) The only comments I've noticed so far (about a year back) suggest that we really don't know much about this function, but I thought I'd ask if someone else has notes about what is wrong with it, how it should work, alternative web sites etc. or has uncommitted patches etc., just so that I don't duplicate work. All comments welcome -- Bill Medland

Jan. 2, 2004

Re: Congradulations - windef.h

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > There's no reason it shouldn't work. However, if we have > a lot of defines, it becomes a bit hard to maintain them > embedded in winegcc. Also, it would allow people to use > gcc directly instead of winegcc (for whatever reason). > It would be a wine/ header, and to be honest, I can't see > any fundamental reason why we can't have a few well defined > wine/ private headers. I'm on the fence on this issue, I > don't need the header myself, but I can see a decent > argument why you'd want to externalize these things out > of winegcc... Sure, there are good arguments for both approaches. I was under the impression that Boaz was saying that the current way didn't work at all, in which case of course it needs to be changed. But otherwise it's just a winegcc implementation detail, and I see no compelling reason for changing it now, especially since winegcc is still going to need quite a bit of work. -- Alexandre Julliard julliard(a)winehq.com

Jan. 2, 2004

Re: #2 - Mdi Win16/32 Split

by Steven Edwards

Hello Dimi, --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > Any idea what the status of the Win16/32 split is? > What DLLs are still not properly split? Its hard for me to say but most of the problems lies in user/gdi/kernel now. The Win16/32 Cleanup is closely tied to the MS_VC+PSDK porting so even if we remove a dependancy on a Win16 function it does not really mean the cleanup is done. The Win32 functions may still depend on other Wineisms. I would say overall its at 50% or more now. There are still a few minor things to clean in shell32, comdlg32 and ole32 but I would rate them at 80 to 90% done. Some WINE functions support the Win16 and Win32 ANSI and Unicode case so in those cases we have to duplicate the code and or rewrite the 32bit cases. I think tools/winapi_check/winapi_check can check for Win16/32 Cross calls. Its hard to get a handle around the problems because WINE on Linux and ReactOS differ once you get in to User, GDI, Kernel and NTDLL. There are some cases where we can use WINE code in these modules and others where we cant so even if we split the Win16/32 code it doesnt mean we can make use of it. http://cvs.reactos.com/cvsweb.cgi/reactos/lib/user32/controls/ Is a good example of a place where we have been able to import a large chunck of WINE user32 code without a lot of nasty changes. I would like to break with NT compatiblity a bit and implement some WINEisms in ReactOS so when DLL seperation part 2 is done we can make use of Winedos for our NTVDM. In the long run we may end up adding all of the Win16 stuff back in if we ever want to create a WOW subsystem for ReactOS. Its still going to need to be split and cleaned up though because we dont want a dos or Win16 app to be able to crash the Win32 subsystem. Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 2, 2004

Re: Congradulations - windef.h

by Dimitrie O. Paun

On January 1, 2004 08:43 pm, Alexandre Julliard wrote: > You still haven't answered the real question: why > wouldn't it work to have them in winegcc? There's no reason it shouldn't work. However, if we have a lot of defines, it becomes a bit hard to maintain them embedded in winegcc. Also, it would allow people to use gcc directly instead of winegcc (for whatever reason). It would be a wine/ header, and to be honest, I can't see any fundamental reason why we can't have a few well defined wine/ private headers. I'm on the fence on this issue, I don't need the header myself, but I can see a decent argument why you'd want to externalize these things out of winegcc... -- Dimi.

Jan. 2, 2004

Re: #2 - Mdi Win16/32 Split

by Dimitrie O. Paun

On January 2, 2004 10:31 am, Steven Edwards wrote: > Split up the Win16/32 MDI support a bit. Any idea what the status of the Win16/32 split is? What DLLs are still not properly split? -- Dimi.

Jan. 2, 2004

Re: Printing bugfixes

by Huw D M Davies

On Fri, Jan 02, 2004 at 02:47:04PM +0000, Mike Hearn wrote: > Or that this line: > sprintf(buf,"%s,WINEPS,LPR:%s",name,devname); > should be > sprintf(buf,"%s,WINEPS,%s",devname,devname); Yes like that, but you'll then have to add the LPR: bit to devname for the printcap and CUPS cases before the function is called. Huw.

Jan. 2, 2004

Re: REBAR: on a RB_SETBANDINFO message only redraw the rebar if something changed

by Dimitrie O. Paun

On January 2, 2004 10:50 am, Mike McCormack wrote: > This stops IE's toolbar from flickering when moving the mouse over links. Happy, happy, joy, joy... Thanks Mike!!! -- Dimi.

Jan. 2, 2004

Re: #3 - shell32/systray.c

by Mike Hearn

On Fri, 2004-01-02 at 16:07, Steven Edwards wrote: > I am not 100% sure but I think your patch will be enough. We already > have some systray support in our Explorer when running on Windows. Take > a look at running explorer under WINE and see if it will help any. Could you send me an EXE of that, if it's convenient? I have no idea how easy/hard it is to build ReactOS but I doubt it's a configure, make, make install :) thanks -mike

Jan. 2, 2004