wine-devel

wine-devel@winehq.org

3 participants
84481 discussions

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@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

Re: Make serial fd blocking mode depend on FILE_FLAG_OVERLAPPED
by Mike McCormack 08 Oct '01

08 Oct '01

Hi Eric, Probably a bit of overzealous use of occam's razor. It was being set to zero on the client side, and passed into the server. I wasn't quite sure what to do with it ... so i removed it. There's no harm in leaving it there i guess... Mike >hi Mike, > >I don't understand why you got read of the inherit flag in the protocol >definition for serial handles. Even, if security attribute isn't pass >around yet for file/comm port creation, it should be kept for comm port > >A+ >-- >--------------- >Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) >"The future will be better tomorrow", Vice President Dan Quayle ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: Make serial fd blocking mode depend on FILE_FLAG_OVERLAPPED
by eric pouech 08 Oct '01

08 Oct '01

Mike McCormack wrote: > > This patch causes a serial port's fd to be put into blocking mode if > FILE_FLAG_OVERLAPPED is not specified and non-blocking mode if it is. > > ReadFile should block on serial ports for non-overlapped reads. The > next step is to refuse overlapped reads and writes if the file isn't > opened with FILE_FLAG_OVERLAPPED specified. hi Mike, I don't understand why you got read of the inherit flag in the protocol definition for serial handles. Even, if security attribute isn't pass around yet for file/comm port creation, it should be kept for comm port A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: err:edit:EDIT_LockBuffer no buffer ... please report
by lawson_whitney＠juno.com 08 Oct '01

08 Oct '01

On Sun, 7 Oct 2001 whit(a)giftie.alien.org wrote: > Well, ... yes. The err: goes away. File and directory names still > disappear from the winhelp file dialog (?) as they did before, but > still, if you select the right empty space, the operation proceeds to a > satisfying crash. If I thought that little err: was all that was wrong > with winhelp, that was silly of me. I _think_ this is a good patch. > > Regards, > > Lawson > ---cut here--- So as not to damn you with faint praise, I think winhelp is more nearly usable with this patch than without. I can actually select and see a topic in terminal.hlp before winhelp crashes. Lawson ---slowly, but with considerable uncertainty--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

1 0

err:edit:EDIT_LockBuffer no buffer ... please report
by lawson_whitney＠juno.com 08 Oct '01

08 Oct '01

Good day! Okay, I reported it, attached is an unexpurgated --debugmsg +edit trace of me trying to open the lcc-win/lccpub/bin/wedit.hlp file from ftp://ftp.mathematik.tu-darmstadt.de/pub/linux/bonnes/lcc-bin-alpha.tar.gz with wine's builtin winhelp program. Current cvs, no windows, no fat nor nt filesystems. Kernel 2.4.10 with devfs and devfsd. [DllOverrides] "*" = "builtin, so, native" I would be happy to make other traces, but probably this is easy to duplicate. Just to add insult to injury, I will attach a backtrace of winhelp trying to work with terminal.hlp (from wfw 3.11, I think). In case anyone is really short on things to debug. Regards, Lawson

2 2

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