March 2005 - Wine-Devel - list.winehq.org

Re: [WINEALSA] use real name for wave also
by Robert Reif March 17, 2005

March 17, 2005

Robert Reif wrote: > Use real names for wave device also. Please disregard this patch. I will present a better one shortly.

1 0

WineConf: book your hotel now
by Brian Vincent March 17, 2005

March 17, 2005

I'm just sending this out as a reminder for everyone to book your hotel room for WineConf. For more information, check out: 1. http://www.winehq.com/site/wineconf 2. http://www.winehq.com/site/wineconf/travel The last day to reserve a room is tomorrow - March 17th. There's no guarantee rooms will be available after that, and I don't have any indication the hotel will allow reservations after that. If you haven't looked at the details, it's a great deal - 81EUR for Friday and Saturday night and it includes breakfast in the morning. If you're thinking to yourself, "I'd like to go to Wineconf, but I don't think I'm cool enough." Well, you should try to attend. You'll probably really enjoy it. PS - still looking for ideas for the agenda, if you have any, let me know. Also let me know if you'd like to present something. -Brian

9 19

Suggestion for a couple of additional janitorial projects
by Dmitry Timoshkov March 17, 2005

March 17, 2005

Hi all, I'd like to suggest to add the following janitorial projects for Wine: 1. Fix Wine to be compilable by a 64-bit compiler a) before accomplishing this task read a good article about porting Win32 code to Win64. b) inspect and fix all public Win32 headers to match PSDK definitions. c) make sure that pointers do not get truncated. d) add support for Win64. 2. Fix wrong assumptions in Wine about endianess. a) inspect all Wine code and public headers to eliminate endianess dependent constructs (low/high parts of a field, bit fileds), add WORDS_BIGENDIAN when appropriate. b) make sure that Wine code handles data in an endianess independent way. -- Dmitry.

2 2

Re: ole32: begin implementing IPropertyStorage
by Alexandre Julliard March 17, 2005

March 17, 2005

Juan Lang <juan_lang(a)yahoo.com> writes: > This is getting big enough I might as well float a patch by. > > ChangeLog: start of implementation of IPropertyStorage This breaks the tests: storage32.c:481: Test failed: failed to create property set storage storage32.c:489: Test failed: failed to create property set storage storage32.c:496: Test failed: open failed storage32.c:534: Test failed: ref count wrong storage32.c:537: Test failed: ref count wrong make[1]: *** [storage32.ok] Error 5 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: SHELL32: minor fix in debughlp.c (crash in file dialogs)
by Mike McCormack March 17, 2005

March 17, 2005

This following patch breaks the file open dialog, so if your file open dialog box crashes in the CVS, this is the thing to revert. _dbg_ILGetNext doesn't seem to return NULL if pidl->mkid.cb is zero... Mike Filip Navara wrote: > _dbg_ILGetNext returns NULL if pidl->mkid.cb is zero, fix the > loops accordingly. > > > ------------------------------------------------------------------------ > > --- dlls/shell32/debughlp.c > +++ dlls/shell32/debughlp.c > @@ -215,7 +215,7 @@ > > pidltemp = _dbg_ILGetNext(pidltemp); > > - } while (pidltemp->mkid.cb); > + } while (pidltemp); > } > else > { > @@ -275,7 +275,7 @@ > } > } > pidltemp = _dbg_ILGetNext(pidltemp); > - } while (pidltemp->mkid.cb); > + } while (pidltemp); > } > return ret; > }

1 0

Re: SHELL32: use structure defined in standard headers for advertised shortcut info
by Dmitry Timoshkov March 17, 2005

March 17, 2005

"Mike McCormack" <mike(a)codeweavers.com> wrote: > - LINK_ADVERTISEINFO buffer; > + EXP_DARWIN_LINK buffer; ... > - TRACE("magic %08lx string = %s\n", buffer.magic, debugstr_w(buffer.bufW)); > + TRACE("magic %08lx string = %s\n", buffer.dbh.dwSignature, debugstr_w(buffer.szwDarwinID)); > > - if( (buffer.magic&0xffff0000) != 0xa0000000 ) > + if( (buffer.dbh.dwSignature&0xffff0000) != 0xa0000000 ) After reading your patch I inspected ShlObj.h from PlatformSDK and found out the following: typedef struct { DWORD cbSize; // Size of this extra data block DWORD dwSignature; // signature of this extra data block CHAR szTarget[ MAX_PATH ]; // ANSI target name w/EXP_SZ in it WCHAR swzTarget[ MAX_PATH ]; // UNICODE target name w/EXP_SZ in it } EXP_SZ_LINK, *LPEXP_SZ_LINK; #define EXP_SZ_LINK_SIG 0xA0000001 // LPEXP_SZ_LINK (target) #define EXP_SZ_ICON_SIG 0xA0000007 // LPEXP_SZ_LINK (icon) Is it a better choice? -- Dmitry.

5 4

AW: WineConf: book your hotel now
by Hans-Ulrich Schmid March 17, 2005

March 17, 2005

Hi, there are enough rooms left in the hotel. Please use "WineConf" as keyword. See you in Stuttgart Hans-Ulrich Schmid Wirtschaftsförderung Region Stuttgart GmbH Stuttgart Region Economic Development Corporation FIR_st - Forum IT-Region Stuttgart Friedrichstr. 10 70174 Stuttgart www.first.region-stuttgart.de www.opensource.region-stuttgart.de www.competenzatlas.de www.region-stuttgart.de Tel ++49.711.22835 - 27 Tel mobil ++49.172.7310463 Fax ++49.711.22835 - 55 > -----Ursprüngliche Nachricht----- > Von: Brian Vincent [mailto:brian.vincent(a)gmail.com] > Gesendet: Mittwoch, 16. März 2005 22:41 > An: Paul van Schayck > Cc: wine-devel(a)winehq.org; Hans-Ulrich Schmid > Betreff: Re: WineConf: book your hotel now > > > On Wed, 16 Mar 2005 21:08:29 +0100, Paul van Schayck > <polleke(a)gmail.com> wrote: > > They are already completely booked... they replied "At this time we > > have not any rooms" this afternoon. > > This happened a few weeks ago and they did have rooms available. Did > you include the keyword "WINECON" with your reservation request? As > far as I know we're still ok - the RSVP list is still slightly less > than the number of rooms we've got, plus we know some people on the > RSVP list aren't staying there. > > I'm CC'ing our local contact to see if he can find out what's going > on. Hopefully we're still ok on rooms. Mr. Schmid - can you email > Paul as well as cc the wine-devel(a)winehq.org list when you find out? > > -Brian >

1 0

Re: Problems with VirtualAlloc/Lock
by Michael Ost March 17, 2005

March 17, 2005

On Mon, 2005-03-14 at 20:13, you wrote: > > * VirtualLock does nothing in Wine > VirtualLock does nothing in win95,98,ME as well :) > > I bet the correct behaviour for wine is to do anything in VirtualLock > only if you set windows version to NT/2000/XP. Did you do it? Good point. But the setting is "winxp". I played with the setting and it doesn't change the behavior. > Anyway, mlock() seems to work fine, so this should be implementable. That would be the natural call to use. The absence of mlock in the wine source tree was one of my early clues that there was a problem! %) > > * Wine makes no distinction between MEM_RESERVE and MEM_COMMIT > Assuming that we're talking about VirtualAlloc(). Yes, but I wasn't specific enough. VirtualAlloc(MEM_RESERVE) and MEM_COMMIT are handled differently in the code. I don't understand the code, the design, or Linux mmap() sufficiently to say if they work correctly or not. They both end up calling mmap() which looks right. What I was trying to say is that in winxp MEM_RESERVE and MEM_COMMIT will VirtualAlloc() and/or VirtualLock very different amounts of memory than wine, even on the same (dual booting) machine. Here were my results when I tried to see how much winxp and wine would allocate and lock. The machine has 368M of RAM on it and a ~1GB paging file in Windows. winxp: 1. VirtualAlloc(MEM_RESERVE) -> 2,086,912k 2. SetProcessWorkingSetSize(260,000k) + VirtualAlloc(MEM_COMMIT) + VirtualLock() -> 259,072k 3. VirtualAlloc(MEM_COMMIT) -> 1,011,712k wine: 1. VirtualAlloc(MEM_RESERVE) -> 1,020,928k 2. SetProcessWorkingSetSize(260,000k) + VirtualAlloc(MEM_COMMIT) + VirtualLock() -> 1,020,928k 3. VirtualAlloc(MEM_COMMIT) -> 1,020,928k What I meant by "makes no distinction" is that wine always lets you MEM_RESERVE or MEM_COMMIT 1,020,928k no matter what. In winxp, * VirtualAlloc(MEM_COMMIT) seems bounded by the size of the paging file * VirtualAlloc(MEM_RESERVE) seems just to be 2GB * VirtualLock() is bounded by GetProcessWorkingSet * GetProcessWorkingSet is bounded by how much RAM you have > > * Wine has no implementation of Windows' process working sets > Linux doesn't either. At least I don't know of a documented API that > could > reliably implement semantics of Windows working sets. Maybe it could be > implemented on other OSes like some BSDs if they have such APIs. Maybe > there's something in /proc/sys/vm or somesuch to tweak those, but then > it > would probably be system-wide. I'm no expert here I'm afraid :( I was wondering about getrtlimit/setrlimit. The upper bound of the working set size seems to map well to RLIMIT_MEMLOCK. However I can't see what the parallel would be for the lower bound. Also RLIMIT_AS could be the limit for how much memory you can MEM_RESERVE. These are process based values. They are available in Linux. Not sure about other platforms. > > * Wine limits MEM_RESERVE to 1GB, but WinXP goes up to 2GB > Wine? Maybe linux, but I doubt wine would do anything like that. Yep, it does. Give it a try. As far as I can tell: int total = 0; for (;;) { LPVOID* leak = ::VirtualAlloc(NULL, 1048576, MEM_RESERVE, PROT_NOACCESS); if (leak) { total += 1048576/1024; printf("Allocated %ldk\r", total); } else { printf("\n"); PrintWindowsError("VirtualAlloc", ::GetLastError(); break; } } will stop at 1,022,976k (1GB) on any wine machine. In winxp it goes up to 2GB, as it ought to. > > Further, these DLLs are audio processing plugins. The apparent fact > that > > VirtualLock doesn't _actually_ lock memory into RAM for real time > I didn't look into the code, but anyway a prerequisite for it would be > to set > windows version to NT/2000/XP. Or at least wine should behave like that, > assuming that MSDN doesn't lie here. > > Apart from that, I bet you didn't raise ulimits for your processes. On > my FC3 > system, ulimit -l gives a meager 32 pages. So that's how many mlock() > could > lock anyway. There's not a problem there. My ulimit -l is "unlimited". BTW we are using an old kernel which required a hack to mlock to allow us to lock more than half the ram (regardless of the ulimit), but that doesn't change any of this behavior. Thanks for your feedback... mo

4 9

Re: [SETUPAPI] fix bug 1140
by Alexandre Julliard March 17, 2005

March 17, 2005

Raphael <fenix(a)club-internet.fr> writes: > patch who correct bug 1140 (http://bugs.winehq.org/show_bug.cgi?id=1140) > htmlhelp install is success :) > > Changelog: > - fix GenFormStrWithoutPlaceHolders16 > ie fix PARSER_string_substW to only keep valid texts entries (no comments > or tabs) This is wrong, comments should have already been taken into account when PARSER_string_substW is called. The right fix is to make GenFormStrWithoutPlaceHolders16 properly split the line like the 32-bit functions do. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: dlls/user/button.c - fix AUTO3STATE with BS_OWNERDRAW
by Tony Lambregts March 17, 2005

March 17, 2005

Michael Lin wrote: > AUTO3STATE control with BS_OWNERDRAW set will not get created. > > ChangeLog: > * fix AUTO3STATE with BS_OWNERDRAW set > > > ------------------------------------------------------------------------ > > Index: dlls/user/button.c > =================================================================== > RCS file: /home/wine/wine/dlls/user/button.c,v > retrieving revision 1.6 > diff -r1.6 button.c > 183c183,186 > < return (window_style & 0x0f); > --- > >> if ((window_style & BS_OWNERDRAW) == BS_OWNERDRAW) >> return BS_OWNERDRAW; >> else >> return (window_style & 0x0f); Patches should be in diff -u format (cvs diff -u) please resubmit.. -- Tony Lambregts

1 0