December 2002 - Wine-Devel - list.winehq.org

Re: PathCreateFromUrlW

by Dimitrie O. Paun

On December 31, 2002 02:06 pm, Matthew Mastracci wrote: > Sorry, here's the unified diff. Thanks! However, please generate the diff relative to wine's root, as I suggested: cvs diff -u dlls/shlwapi/path.c What you did is this: cd dlls/shlwapi; cvs diff -u path.c which just makes things harder for Alexandre when applying the patch. -- Dimi.

Dec. 31, 2002

Re: Visual-MinGW: Winelib patch

by Dimitrie O. Paun

On December 31, 2002 01:52 pm, Manu wrote: > -mno-cygwin don't have much sense, since Visual-MinGW is built with > MinGW, under Windows, not Cygwin. Yes, I know, but -mno-cygwin should be a noop in that case. And if someone has cygwin installed, it will ensure that Visual-MinGW is not linked against the cygwin libs. I think we are in agreement here that Visual-MinGW should not depend on cygwin, no? If so, it makes sense to make this explicit with -mno-cygwin. > > -- Do not use -pedantic, the code does not compile with gcc 3.2 > > on Linux with that flag. > > -- Do not use -fvtable-thunks, it is deprecated in gcc 3.2 > > > > Please apply this patch with 'patch -p1 < winelib.diff'. > > Apparently, the patch refuses to be applied, probably due to > the fact that I changed a few things in makefiles formating. OK, I can create a new patch for you. > BTW, makefiles are generated by Visual-MinGW, so I > suggest to add dedicated makefiles for Winelib. > eg: "makefile.wine". I can certainly do that, but then they will drift appart. The ideal situation is to support both mingw and wine out of the same makefile, so that everything "just works". If makefile is generated by Visual-MinGW, I think it's worth modifying Visual-MinGW so that it generates the right makefile for both mingw and wine, don't you think so? This way, all programs that use Visual-MinGW can benefit from this support. -- Dimi.

Dec. 31, 2002

Re: PathCreateFromUrlW

by Dimitrie O. Paun

On December 31, 2002 01:46 pm, Matthew Mastracci wrote: > Can someone review this and check it in (if it doesn't require any > fixes)? Please send uniffied diff patches like so: cvs diff -u dlls/shlwapi/path.c -- Dimi.

Dec. 31, 2002

Re: XP Conformance Test Results: Round 3...

by Chris Morgan

On Monday 30 December 2002 11:58 pm, Kye Lewis wrote: > Windows XP Results: Round 3 > More tests added. Some Previous tests fail differently.. 1 regression in > kernel32:locale as far as I can see... > ... These are just the new locale tests that were recently added that are failing. The new tests cover almost every capability of GetTime/DateFormat(). There is a patch in the queue that should fix a few of these issues, the rest appear to be due to different behavior between NT4, W2k, WinME and WinXP. The NT4 machine I use at work is where I did all of my testing, all of the tests pass there. Once the latest locale patch is in I'll see if I can clean up the rest of these errors. Both GetTime/DateFormat() are in better shape than ever. > locale.c:154: Test failed: GetTimeFormat got '' instead of '4' > locale.c:155: Test failed: GetTimeFormat: got 1 instead of 2 > locale.c:181: Test failed: GetTimeFormat got '8.@:56AM' instead of > '8.@:56.@:AM' > locale.c:182: Test failed: GetTimeFormat: got 9 instead of 12 > locale.c:190: Test failed: GetTimeFormat got '' instead of '3' > locale.c:191: Test failed: GetTimeFormat: got 1 instead of 2 > locale.c:474: Test failed: GetDateFormat got '5/4/2002' instead of > '5/4/02' > locale.c:475: Test failed: GetDateFormat: got 9 instead of 7 > locale.c:499: Test failed: GetDateFormat check DATE_YEARMONTH with null > format expected ERROR_INVALID_FLAGS got return of '10' and error of '0' > locale.c:530: Test failed: GetDateFormatW allowed flags and format > locale.c:539: Test failed: GetDateFormatW did not permit null buffer > pointer when counting. > > locale: 109 tests executed, 0 marked as todo, 11 failures. > path: 1730 tests executed, 0 marked as todo, 0 failures. Chris

Dec. 31, 2002

RE: Fixing include quotes (was: Re: conformance test for ShellExecute)

by Patrik Stridvall

> On December 30, 2002 03:41 pm, Patrik Stridvall wrote: > > I'm already on it by improving winapi_cleanup. > > Very well, I've put you up for it instead. But make sure > you don't over do it :) Well, for the future I have planned grouping and automatic addition of #ifdef HAVE_ and that sort of things. That is overdoing a little perhaps but it will look nicer. :-) > It seems to me the algo is simple > (if the include can not be accessed relative to the dir in > which the .c file is, change it to <>), This is that it already does I think. Please try it out yourself. > and the operation > is really one time. It depends what you mean by one time. People make mistakes. winapi_cleanup does C++ comment to C comment conversion and this is "one time" as well... > So if you have something that works, > let's just get the patch (and here I'm referring to the one > that does the actual "" to <> change) in, and check this off. I think it is better than Alexandre runs winapi_cleanup --include-quotes himself if he thinks it does the correct things. If not please inform me what the problem is. In my tree, the patch is over 800k.

Dec. 31, 2002

Putty: Winelib support (take 2)

by Dimitrie O. Paun

On December 18, 2002 04:59 am, Simon Tatham wrote: > That said, I also agree your revised patch is a huge amount better > by comparison! So if you'd rather I wait until that's ready, I'm > fine with that too. Hi Simon, I've managed to cleanup my changes. Currently only this 3-line patch is required to compile putty under Winelib. The way it works is that you simply uncomment 2 (two) lines in the Makefile.cyg file, and do the usual: make -f Makefile.cyg to compile under Wine. This has the advantage that you don't need to maintain a Wine-only Makefile that is quite likely to get bitrotten sooner rather than later. Please let me know if you need any other changes. Happy New Year! Index: mkfiles.pl =================================================================== RCS file: /home/cvs/putty/mkfiles.pl,v retrieving revision 1.38 diff -u -r1.38 mkfiles.pl --- mkfiles.pl 30 Dec 2002 23:14:11 -0000 1.38 +++ mkfiles.pl 31 Dec 2002 09:31:29 -0000 @@ -293,6 +293,9 @@ "# TOOLPATH = /pkg/mingw32msvc/i386-mingw32msvc/bin/\n". "CC = \$(TOOLPATH)gcc\n". "RC = \$(TOOLPATH)windres\n". +"# Uncomment the following two lines to compile under Winelib\n". +"# CC = winegcc\n". +"# RC = wrc\n". "# You may also need to tell windres where to find include files:\n". "# RCINC = --include-dir c:\\cygwin\\include\\\n". "\n". -- Dimi.

Dec. 31, 2002

Re: Make RECT === RECTL, fix compile warnings, use uniform format

by Dan Kegel

Dimitrie O. Paun wrote: > On December 29, 2002 04:10 pm, Dan Kegel wrote: > >>(BTW it might worth looking into a change to debugrect() to get >>its storage on the stack, in a local variable of the TRACE() macro. >>That'd avoid possible thread clashes (if you have too many threads, >>the current way debugrect() gets storage might break...)) > > > Yes, in theory the current implementation has that problem, but > in practice is OK. And besides, it's for debugging only. But how > can you get that local var without changing the current interface? You could do something cheezy like --- debug.h 2002-07-05 14:22:09.000000000 -0700 +++ debug.h.new 2002-12-31 00:01:33.000000000 -0800 @@ -80,6 +80,8 @@ #define __WINE_DPRINTF(dbcl,dbch) \ do { if(__WINE_GET_DEBUGGING(dbcl,(dbch))) { \ + char __wine_dprintf_buf[2048]; \ + char *__wine_dprintf_ptr = __wine_dprintf_buf; \ const char * const __dbch = (dbch); \ const enum __WINE_DEBUG_CLASS __dbcl = __WINE_DBCL##dbcl; \ __WINE_DBG_LOG @@ -87,6 +89,8 @@ #define __WINE_DBG_LOG(...) \ wine_dbg_log( __dbcl, __dbch, __func__, __VA_ARGS__); } } while(0) +#define debugrect(r) __debugrect((r), &__wine_dprintf_ptr) + #define __WINE_PRINTF_ATTR(fmt,args) #else /* !__GNUC__ && !__SUNPRO_C */ BTW debugrect() isn't a great name... can't think of a snappy replacement offhand, though. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 31, 2002

Re: File locking ... need info

by Dan Kegel

Bill Medland wrote: > If you do intend working on it then you are going to have to address some of > the following issues: > 1. Windows region locking has different behaviour with regard to merging > regions etc. than Unix. > 2. Remember that fcntl locks are on the actual file, not on the handle; and > closing one handle drops all the locks on all other handles to the same file. > (I am being almost criminally lax with my wording here but it will do for > now). > 3. The timeouts are going to be an interesting task. However the structure of > the wine server should help immensely > 4. To the best of my knowledge SMB file systems don't handle it. No one has > yet told me differenly on the several occasions I have tried to ask. (I know > that Samba serves out locks to Windows machines successfully but if you put > an fcntl lock on a file on a SMB share to the best of my knowledge it doesn't > translate to an SMB lock request). > 5. The whole issue of advisory and mandatory locking. Ah, yes, file locking. I was one of the folks who advised Sun as they were bringing file locking to Java (in "JSR-51"), and we had some fun discussions about how to define file locking in Java so it would map properly onto either Windows or Unix. One thing I recall is that W. Richard Stevens has a nice discussion of Unix locking in chapter 12 of "Advanced Programming in the Unix environment", published 1993. It aged fairly well, I think, and provides a bit of insight into how locking evolved -- and some problems with mandatory locking (e.g. mandatory locking didn't prevent ed from editing a file!) Note that mandatory locking is not part of Posix (http://www.opengroup.org/onlinepubs/007904975/toc.htm) JSR-51 decided to map Java file locks to mandatory locks on Windows, and advisory locks on Unix. I'm afraid that's about the only real option. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 31, 2002

Visual-MinGW: Winelib patch

by Dimitrie O. Paun

Hi Manu, I got around getting Visual-MinGW to compile under Winelib. This patch touches only your makefile, and I hope the changes are not controversial: -- Use forward slash instead of backslash -- Explicitly list the DLLs you link against (shell32, comdlg32, advapi32) -- It make sense to specify -mno-cygwin For some reason, the code seems to require it. Please check that it works under Windows as well. If it does, if makes sense to have it as Visual-MinGW should not have a dependency on Cygwin, as far as I can tell. -- Do not use -pedantic, the code does not compile with gcc 3.2 on Linux with that flag. -- Do not use -fvtable-thunks, it is deprecated in gcc 3.2 Please apply this patch with 'patch -p1 < winelib.diff'. Note that I still need to get some changes integrated into the official Wine tree before you can actually compile Visual-MinGW under Winelib. The changes are not controversial, and I hope to get them in real soon. I will let you know when that happens. Regardless, I think the changes I'm proposing are logical in and of themselves, so I figured they can be integrated regardless. Enjoy! --- Visual-MinGW.orig/Projects/vmingw/src/makefile 2002-06-08 06:07:10.000000000 -0400 +++ Visual-MinGW/Projects/vmingw/src/makefile 2002-12-31 01:43:29.000000000 -0500 @@ -1,25 +1,25 @@ # Generated automatically by Visual-MinGW. # http://visual-mingw.sourceforge.net/ -CC = g++ +CXX = g++ WRES = windres DLLWRAP = dllwrap CPPFLAGS = -D_WIN32_IE=0x0400 -LDBASEFLAGS = -mwindows -lcomctl32 -lole32 +LDBASEFLAGS = -mwindows -mno-cygwin -lcomctl32 -lole32 -lshell32 -lcomdlg32 -ladvapi32 INCDIRS = -I ../include OPTIMIZ = -O2 STRIP = -s ifeq ($(MAKECMDGOALS),debug) -CXXFLAGS = -W -Wall -pedantic $(INCDIRS) -g -fvtable-thunks -fno-rtti +CXXFLAGS = -W -Wall $(INCDIRS) -g -mno-cygwin -fno-rtti LDFLAGS = $(LDBASEFLAGS) else -CXXFLAGS = -W -Wall -pedantic $(INCDIRS) $(OPTIMIZ) -fvtable-thunks -fno-rtti +CXXFLAGS = -W -Wall $(INCDIRS) $(OPTIMIZ) -mno-cygwin -fno-rtti LDFLAGS = $(STRIP) $(LDBASEFLAGS) endif -SRCDIR = .\src -BINDIR = ..\bin +SRCDIR = ./src +BINDIR = ../bin LIBDIRS = %.o : %.rc @@ -51,7 +51,7 @@ # Dependency rules $(TARGET): $(OBJS) - $(CXX) -o $(BINDIR)\visual-mingw.exe $(OBJS) $(INCDIRS) $(LIBDIRS) $(LDFLAGS) + $(CXX) -o $(BINDIR)/visual-mingw.exe $(OBJS) $(INCDIRS) $(LIBDIRS) $(LDFLAGS) rsrc.o: rsrc.rc -- Dimi.

Dec. 31, 2002

Re: Make RECT === RECTL, fix compile warnings, use uniform format

by Dimitrie O. Paun

On December 31, 2002 03:03 am, Dan Kegel wrote: > +#define debugrect(r) __debugrect((r), &__wine_dprintf_ptr) Yeah, that can work too, but it does increase stack usage by quite a bit. But if we are to do this for RECTs only we don't need as much space anyway... Nevertheless, it's an alternative solution, and it does not require exporting more stuff out of ntdll. Let's wait for Alexandre's take on it. :) > BTW debugrect() isn't a great name... can't think of a snappy replacement > offhand, though. True, but it has the following nice caracteristics: -- uses the debug prefix -- easy to remember if we have the naming convention: debug<struct-name-to-lower-case> -- it is short Would be nice to have such std functions for a bunch of structures, like I did in listview.c. They are extremely handy, and can save you quite a bit of time when you want to dump stuff out. And if more of these become standard, a simple naming convention like this one pays. Feel free to suggest something else though! :) -- Dimi.

Dec. 31, 2002