May 2007 - Wine-Devel - list.winehq.org

Old Autocad trials?
by Dan Kegel May 6, 2007

May 6, 2007

http://wiki.winehq.org/LinuxApplicatonRequestSurvey says that Autocad is the #2 most requested application on Linux. The latest version might be a challenge to support, since it depends on .net 2.0, but we could start by supporting older versions. http://appdb.winehq.org/appview.php?iAppId=86 shows that R14 ran ok at one point, and I've seen a tutorial for how to run 2000 on wine, so there's hope. I couldn't find any source of Autocad R14 or '97, but looking on amazon.com I think books with trial CD-ROMs are available from autocad 2000 on (if only for LT and other hacked down variants, but I'm not picky). Before I go wild buying old autocad books from Amazon, does anyone out there have old copies of Autocad (full or trial) they'd be willing to send me for testing? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 3

Re: shell32: check cbSize in Shell_NotifyIconW to make apps sending garbage work (fixes bug #7940)
by Dmitry Timoshkov May 6, 2007

May 6, 2007

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > + /* The validation is also done in explorer. However we must also do it > + * on the client size so that WM_COPYDATA doesn't crash the application > + */ > + if (nid->cbSize != NOTIFYICONDATAW_V1_SIZE && > + nid->cbSize != NOTIFYICONDATAW_V2_SIZE && > + nid->cbSize != NOTIFYICONDATAW_V3_SIZE && > + nid->cbSize != sizeof(NOTIFYICONDATAW)) > + { > + WARN("Invalid size\n"); > + return FALSE; > + } Do you have a test case for this? -- Dmitry.

2 1

change generic.ppd file
by Alisson Gomes May 6, 2007

May 6, 2007

Mrs, I do can recompile wine with change generic.ppd file? only change the generic.ppd? Or exist a version of wine i can configure? thanks, Alisson Gomes

2 1

Re: Console output with different codepages - the result.
by Kirill K. Smirnov May 6, 2007

May 6, 2007

> just a dummy question... does the different fonts your tests refer to > have all the glyphs required ? (or said differently, isn't this a font > issue about the required glyphs for russian ?) > A+ By default (in 866 OEM codepage) wine console renderer behaves just like windows does, the difference appears iff I change codepage to 1251 ANSI. So it is not missing glyphs problem - I do not change font while changing codepage. -- Kirill

1 0

dbghelp performance
by Markus Amsler May 6, 2007

May 6, 2007

I've played around with dbghelp performance. My test case was breaking at an unknown symbol (break gaga) while WoW was loaded in the debugger (wine winedbg WoW.exe). The time was hand stopped, memory usage measured with ps -AF and looked at the RSS column. Test Time(s) Memory Usage(MB) current git 4.5 54 pool_heap.patch 4.5 63 process_heap.patch 4.5 126 insert_first.patch 4.5 54 current git, r300 115 146 pool_heap.patch, r300 17 119 process_heap.patch, r300 17 260 insert_first.patch, r300 27 167 insert_first is the patch from Eric Pouech. r300 means with the debug version of Mesas r300_dri.so, which has a total compilation unit size of around 9.2M (compared to the second biggest Wines user32 with 1.1M). Conclusions: - current git wins with small debug files (<2M or so), pool_heap wins with bigger files. insert_first, process_heap are out. - small pools have less memory overhead than small heaps - big pools have more memory overhead than big heaps. - big pools are a lot slower than big heaps. IMO the best results would give removing the pools (like in process_heap) and freeing unused memory manually, the other way round it was allocated. But at a first glance it looks like quite a bit of work, which I'm not sure is worth the result. I think the best approach would be to code some destroy functions in storage.c which would free the allocated vector, sparse_array and hash_table memory. And then gradually replace pool_alloc calls with HeapAlloc/HeapFree pairs. Markus

2 6

Re: Initial Mixer support on Mac OS X (1/7)
by Maarten Lankhorst May 6, 2007

May 6, 2007

"Emmanuel Maillard" <mahanuu(a)free.fr> wrote: > Changelog : > - inital Mixer support on Mac OS X > - find all lines and initialize controls Looking through it you seemed to have used OSS as base, which means some of the comments on my earlier code also apply to your code: - 64 bits safety (use DWORD_PTR's) - the code that normalizes to 65535 should be changed by a MulDiv if possible. Also if coreaudio has a way to notify the sound driver that a mixer control has changed you might want to notify the program, see elem_callback in alsa's mixer, and alsa's mix_open. Cheers, Maarten

1 0

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)
by Dmitry Timoshkov May 6, 2007

May 6, 2007

"Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > Make use of the Triangle Inequality Nearest Neighbour algorithm to find the > nearest colour more efficiently than a simple linear search. The improvements > are most noticeable with a palette of 256 colours. Testing shows approximately > 3-4x performance increase for 256 colours. Now that you got rid of sqrt calls usage of float numbers internally doesn't look justified (to me) anymore. -- Dmitry.

1 0

InternetCanonicalizeURLA / W - Missing some flags?
by Chris Howe May 6, 2007

May 6, 2007

I noticed a FIXME cropping up in the logs when working on EQ2, related to InternetCanonicalizeURL not fully parsing the flags that it is called with. Looking a bit closer, it offloads the grunt work to UrlCanonicalize anyway, and the missing flags seem to have analogs defined for UrlCanonicalize to use, and adding support for them makes the message go away: no problems that I can see, either. However, I seem to be having trouble running the test for wininet, as it just hangs for me (before I made the alterations, that is)... would somebody care to check that the attatched patch is correct?

1 0

RE: Initial Mixer support on Mac OS X (2/7)
by Amy Fox May 6, 2007

May 6, 2007

oi >From: Emmanuel Maillard <mahanuu(a)free.fr> >Reply-To: wine-devel(a)winehq.org >To: wine-patches(a)winehq.org >Subject: Initial Mixer support on Mac OS X (2/7) >Date: Sun, 6 May 2007 11:53:48 +0200 > >Changelog : > - implement MIX_Open and MIX_GetNumDevs > ><< 0002-implement-MIX_Open-and-MIX_GetNumDevs.patch >> > _________________________________________________________________ Reserve your place in history - Email Britain! http://www.emailbritain.co.uk/

1 0

Re: winmm: Use a pipe for timer
by Steven Edwards May 6, 2007

May 6, 2007

Hi, On 5/5/07, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > This avoids expensive server calls in a time critical timer. > > Without priority patch it drops stddev in winmm timer tests to < 2 ms as > compared to ~7 ms before. With priority patch it drops to < .20 ms. > > Backwards compatibility code is kept just in case. Even though backward compatibility is kept I worry about a couple of things. A lot of work was done on WinMM to make it portable to windows for testing and I don't like seeing new code to tie it back to unix even with the old code left in place. Also shouldn't there be a way to speed up the server performance instead? If this is accepted here then what about other areas of wine such as directx where timers similar may be used? Should we make this sort of patch global? I don't think so but then I don't know enough to no what the proper fix would be. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

3 2