October 2001 - Wine-devel - list.winehq.org

Re: CommandLineToArgvW fix
by Alexandre Julliard 09 Oct '01

09 Oct '01

Francois Gouget <fgouget(a)free.fr> writes: > Grrr, HGLOBAL is not a void* pointer... yet => casts :-( GlobalLock would be better... -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/windows painting.c
by Alexandre Julliard 08 Oct '01

08 Oct '01

Duane Clark <dclark(a)leewardfpga.com> writes: > This patch, despite being very simple, has the surprising affect of > causing names of files and icons in the file open dialog of one of my > apps to become invisible when I change directories. I can get individual > names to show up again if I click in the general area of the name, and > all of them show up if I click in the general area of where I know the > scrollbar to be (it is also invisible). Does this make any difference? Index: windows/painting.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/painting.c,v retrieving revision 1.58 diff -u -r1.58 painting.c --- windows/painting.c 2001/10/05 19:47:42 1.58 +++ windows/painting.c 2001/10/08 20:19:22 @@ -712,8 +712,6 @@ if (flags & RDW_UPDATENOW) { - /* process pending events and messages before painting */ - MsgWaitForMultipleObjects( 0, NULL, FALSE, 0, QS_ALLINPUT ); if (wndPtr->hrgnUpdate) /* wm_painticon wparam is 1 */ SendMessageW( hWnd, (bIcon) ? WM_PAINTICON : WM_PAINT, bIcon, 0 ); } @@ -818,6 +816,11 @@ r.top, r.right, r.bottom, hrgnUpdate, flags ); } } + + + /* process pending events and messages before painting */ + if (flags & RDW_UPDATENOW) + MsgWaitForMultipleObjects( 0, NULL, FALSE, 0, QS_ALLINPUT ); /* prepare an update region in window coordinates */ -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: Make serial fd blocking mode depend on FILE_FLAG_OVERLAPPED (Updated)
by lawson_whitney＠juno.com 08 Oct '01

08 Oct '01

On Mon, 8 Oct 2001, Mike McCormack wrote: > > Hi Eric, > > Same patch as before, with the inherit flag added back in to the > server protocol. > > Mike > > ChangeLog: > * make serial fd blocking mode depend on FILE_FLAG_OVERLAPPED > I don't expect this will bother juno version 2. If you get this, it doesn't. Lawson --- >> Build a better mousetrap, and the world will build a better mouse.>> - Proverbs of Hell Revisited

1 1

Re: PATCH: shut up pthread fixme
by Alexandre Julliard 08 Oct '01

08 Oct '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > Changelog: > Remove the harmless and confusing pthread locking fixme messagess. Agreed for pthread_kill_other_threads_np, but I don't think the pthread_rwlock ones are really harmless. We should really do some kind of locking in there, we can't just ignore them. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/windows painting.c
by Duane Clark 08 Oct '01

08 Oct '01

> ChangeSet ID: 1002311262337796173989773 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine2. 01/10/05 15:47:42 > > Modified files: > windows : painting.c > > Log message: > Process pending events before sending WM_PAINT on RDW_UPDATENOW. > > Patch: http://cvs.winehq.com/patch.py?id=1002311262337796173989773 > This patch, despite being very simple, has the surprising affect of causing names of files and icons in the file open dialog of one of my apps to become invisible when I change directories. I can get individual names to show up again if I click in the general area of the name, and all of them show up if I click in the general area of where I know the scrollbar to be (it is also invisible). Duane

4 3

Re: CommandLineToArgvW fix
by Alexandre Julliard 08 Oct '01

08 Oct '01

Francois Gouget <fgouget(a)free.fr> writes: > On Mon, 8 Oct 2001, Malte Starostik wrote: > > > Don't free cmdline as the return values point into that string. It's the > > caller's responsibility to GlobalFree() this according to msdn. > > Ok, I tested my patch and it works. So I propose it here. If the caller is supposed to call GlobalFree on the returned value, it would be much cleaner to allocate it with GlobalAlloc. -- Alexandre Julliard julliard(a)winehq.com

1 0

CVS mirror
by davep 08 Oct '01

08 Oct '01

Checking CVS for the first time in several weeks today, I was surprised to discover that there had been no commits in all that time. Surprising since many changes had been discussed here over that period. Anyway I re-discovered that a long while ago I had put this in my /etc/hosts: 130.225.13.222 cvs.winehq.com presumably at a time when the main CVS was inaccessible. This address still holds a CVS repository for Wine but doesn't seem to be kept up to date. I hope no-one else has made the same mistake ;-) Dave Pickles

1 0

Re: CommandLineToArgvW fix
by eric pouech 08 Oct '01

08 Oct '01

Malte Starostik wrote: > > Don't free cmdline as the return values point into that string. It's the > caller's responsibility to GlobalFree() this according to msdn. I don't understand what you've done. cmdline is a copy of the passed lpCmdLine parameter used for getting the different bits of the argv, so it should be freed however, what's wrong with current implementation (hence your issues) is that when freeing cmdline the argv array points to garbage it means that the argv array and cmdline should be allocated in a single memory block suh that argv[i] points to the part of the string wouldn't the (completly untested but) attached patch work better ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Index: dlls/shell32/shell32_main.c =================================================================== RCS file: /usr/share/cvs/cvsroot/wine/wine/dlls/shell32/shell32_main.c,v retrieving revision 1.85 diff -u -r1.85 shell32_main.c --- dlls/shell32/shell32_main.c 2001/10/03 18:42:16 1.85 +++ dlls/shell32/shell32_main.c 2001/10/08 18:06:34 @@ -1,3 +1,4 @@ + /* * Shell basics * @@ -88,15 +89,10 @@ return argv; } - /* to get a writeable copy */ - cmdline = HeapAlloc(GetProcessHeap(), 0, (strlenW(lpCmdline)+1) * sizeof(WCHAR)); - if (!cmdline) - return NULL; - strcpyW(cmdline, lpCmdline); argc=0; bcount=0; in_quotes=0; - s=cmdline; + s=(LPWSTR)lpCmdline; while (1) { if (*s==0 || ((*s==0x0009 || *s==0x0020) && !in_quotes)) { /* space */ @@ -122,7 +118,12 @@ } s++; } - argv=HeapAlloc(GetProcessHeap(), 0, (argc+1)*sizeof(LPWSTR)); + argv=HeapAlloc(GetProcessHeap(), 0, (argc+1)*sizeof(LPWSTR) + strlenW(lpCmdline) + 1); + if (!argv) + return NULL; + /* to get a writeable copy */ + cmdline = (LPWSTR)((char*)argv + (argc+1)*sizeof(LPWSTR)); + strcpyW(cmdline, lpCmdline); argc=0; bcount=0; @@ -178,7 +179,6 @@ if (numargs) *numargs=argc; - HeapFree(GetProcessHeap(), 0, cmdline); return argv; }

1 1

Fwd: Re: CommandLineToArgvW fix
by Malte Starostik 08 Oct '01

08 Oct '01

Sorry, meant reply-to-all ---------- Weitergeleitete Nachricht ---------- Subject: Re: CommandLineToArgvW fix Date: Mon, 8 Oct 2001 20:23:57 +0200 From: Malte Starostik <malte(a)kde.org> To: eric pouech <eric.pouech(a)wanadoo.fr> Am Monday 08 October 2001 20:08 schrieben Sie: > Malte Starostik wrote: > > Don't free cmdline as the return values point into that string. It's the > > caller's responsibility to GlobalFree() this according to msdn. > > I don't understand what you've done. > cmdline is a copy of the passed lpCmdLine parameter used for getting the > different bits of the argv, so it should be freed > however, what's wrong with current implementation (hence your issues) is > that when freeing cmdline the argv array points to garbage > it means that the argv array and cmdline should be allocated in a single > memory block suh that argv[i] points to the part of the string You're definately right, I mixed up argv with argv[i] there. > wouldn't the (completly untested but) attached patch work better ? Didn't test it either, will do so somewhen later, looks right to me. -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787] -------------------------------------------------------

2 1

Re: Q&D rundll32 implementation
by Marcus Meissner 08 Oct '01

08 Oct '01

On Mon, Oct 08, 2001 at 11:14:00AM +0200, Malte Starostik wrote: > I'm currently trying to get the WMP installer running. One of the things it > needs is rundll32.exe. Attached is a very basic implementation of it. > However, it doesn't work out of the box, as it's lacking an .exe suffix which > the installer explicitly specifies. What's the preferred way to handle such > cases? Not that the installer would work, when it comes to the actual .inf > parsing, it hits the SetupAPI stubs and nothing is actually copied. > Do with it what you like. I do not see a reason we could not name a linux binary .exe in this case. Ciao, Marcus

1 0