wine-devel May 2007

wine-devel@winehq.org

134 participants
311 discussions

Old Autocad trials?
by Dan Kegel 06 May '07

06 May '07

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 06 May '07

06 May '07

"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 06 May '07

06 May '07

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 06 May '07

06 May '07

> 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 06 May '07

06 May '07

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 06 May '07

06 May '07

"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 06 May '07

06 May '07

"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 06 May '07

06 May '07

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 06 May '07

06 May '07

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 06 May '07

06 May '07

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

← Newer
1
...
24
25
26
27
28
29
30
31
32
Older →

Jump to page:

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 May 2007