- Wine-Devel - list.winehq.org

wsock32 conformance test
by Thomas Kho Feb. 25, 2005

Feb. 25, 2005

Hi, We're working on a set of tests for wsock32.dll. So far we've completed a test of blocking network I/O with multiple threads. Before we post to wine-patches, we'd appreciate any critiques/input. Fredy, Doug, and I are UCLA undergraduates in a software engineering course. Thanks for your help, Thomas Kho cc: Fredy Garcia, Douglas Rosenberg (group members) Files available at: http://www.geekymedia.com/viewcvs/cgi/viewcvs.cgi/wine4/wine/dlls/wsock32/t…

1 0

Re: [RESEND] Uninstaller localization
by Dmitry Timoshkov Feb. 25, 2005

Feb. 25, 2005

"Jonathan Ernst" <Jonathan(a)ErnstFamily.ch> wrote: > This time I didn't translate the WINE_ERR messages and translated another messagebox. It would be better to not touch WINE_ERR lines at all then. > Changelog: > - localization of uninstaller > + /* We load the strings */ > + LoadString( hInst, IDS_APPNAME, sAppname, sizeof(sAppname)); ... > - wc.hIcon = LoadIcon( hInst, appname ); > + wc.hIcon = LoadIcon( hInst, sAppname ); LoadIcon will always fail in the localized case. -- Dmitry.

1 0

Re: Fix recently introduced SEGV in DOCFILE IStorage implementation
by Troy Rollo Feb. 24, 2005

Feb. 24, 2005

On Thursday 24 February 2005 20:39, Paul Vriens wrote: > Could you send the patch to wine-patches :-). Damn, another typo on my part (I meant it to go there in the first place) On Friday 25 February 2005 03:26, Mike McCormack wrote: > Thanks for finding this problem. I think the root cause of the problem > is that three structures that need to be the same require 3 seperate > tweaks. > > Can you confirm that this patch also fixes the problem for you? I probably could, but given the nature of your patch there's a much more efficient test that should give much greater confidence in it - compiling the affected source files without debugging information using your patch and mine should give identical object files (except for time stamps in the object file headers).

1 1

broken faq.sgml
by Vitaly Lipatov Feb. 24, 2005

Feb. 24, 2005

Patch http://cvs.winehq.org/patch.py?id=16300 breaks faq.sgml in line <question id="Can-I-bundle-everything-in-one-huge-executable"> during compiling: jade:/home/lav/RPM/BUILD/wine-20050224/documentation/faq.sgml:1716:66:Q: length of name token must not exceed NAMELEN (44) -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

Re: Fix recently introduced SEGV in DOCFILE IStorage implementation
by Paul Vriens Feb. 24, 2005

Feb. 24, 2005

On Thu, 2005-02-24 at 17:26, Mike McCormack wrote: > Troy Rollo wrote: > > After changing StorageBaseImpl, StorageInternalImpl was not updated to reflect > > the change. > > Thanks for finding this problem. I think the root cause of the problem > is that three structures that need to be the same require 3 seperate tweaks. > > Can you confirm that this patch also fixes the problem for you? > > thanks, > > Mike > Hi Mike, this fixes one of the problems I had with the Uru_Ages_Beyond_Myst_Demo. I still have problems with InstallShield but that's a known problem, and worked on ;-). Cheers, Paul.

1 0

Re: Child windows require IsWindowVisible() test in DestroyWindow()
by Dmitry Timoshkov Feb. 24, 2005

Feb. 24, 2005

"Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > in the msg.c,test_DestroyWindow() test case adding WS_VISIBLE to all > windows except a parent shows that behaviour doesn't change for child > windows but a popup window starts to receive WM_WINDOWPOSCHANGING and > friends indicating that child windows require IsWindowVisible() test. > > I don't want to add that to the real test in order to keep the test > as simple as possible. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > A test shows that child windows require IsWindowVisible() test > in DestroyWindow() in order to suppress ShowWindow() call. Alexandre, please do not apply this patch, it's wrong. -- Dmitry.

1 0

Re: Uninstaller localization
by Dmitry Timoshkov Feb. 24, 2005

Feb. 24, 2005

"Jonathan Ernst" <Jonathan(a)ErnstFamily.ch> wrote: > Changelog: > - localization of uninstaller You should not localize WINE_ERR messages, encoding of strings might be incompatible in Wine and underlying system. Also, is it possible to use normal dialog for uninstaller's main window? We could use conventional dialog templates in resources for different locales then. Right now localization will look ugly if lengths of strings in various locales are different. -- Dmitry.

1 0

Fwd: Invitation to the mediation manual
by Duane Clark Feb. 24, 2005

Feb. 24, 2005

Oops, I inadvertently deleted this from the queue, sorry. Robert Schuster wrote: Dear Wine developers, I wrote some guidelines that should help FOSS projects getting more lively and lowering the barrier for new developers to join. You can find them in form of a small manual here http://projects.mi.fu-berlin.de/w/bin/view/SE/ThesisFOSSIMMediationManual. These ideas are the result of work for my bachelor thesis and have been used successfully at the GNU Classpath project. If the topic is of interest to you, I would be happy to receive criticism and comments concerning the manual or the general idea. For further discussion I have set up a mailing-list (use http://lists.spline.inf.fu-berlin.de/mailman/listinfo/mediation_manual to subscribe or mediation_manual(a)lists.spline.inf.fu-berlin.de to post unsubscribed). Please send your feedback to this list but if you have reasons to contact me directly then just reply to this mail. In case you answer to your project's mailing list please CC me. Best regards Robert Schuster

1 0

Re: Poor performance when using Texas Instruments code generation tools in Wine
by Jan Tore Korneliussen Feb. 24, 2005

Feb. 24, 2005

We found a simple solution (workaround?) to make this application perform well under WINE. Typical running time of the linking process is down from 30min to 15sec (!). A short explanation: The TI linker allocates and frees a lot of small buffers, typical size 24-32 bytes - but we have not seen allocation of buffers smaller than 24 bytes. Due to fragmentation of the heap in WINE, the number of free buffers smaller than 24 bytes gradually increases. Since the free buffers are organized in 4 lists based on their size, the small (<24 bytes) buffers will go in the first list (which in the current version holds buffers of size <= 32), and each new allocation will have to search past these small buffers. After a while this consumes all processor time, due to the large number of allocations done by the linker. A sufficient fix for this particular application is to introduce a new free list for buffers smaller than 24 bytes. In this way the small buffers will simply be skipped for each allocation, keeping allocation time relatively constant. Note that this is a custom fix for this application, but maybe introducing more free list for small buffers can help other applications which allocate a lot of small buffers. I guess one has to collect data from a lot of apps to make a good tradeoff here. Anyway it was a good thing for us that the heap is "tunable". The diff is with respect to Wine-20050211.tar.gz dlls/ntdll/heap.c -- Jan Tore Korneliussen R&D Engineer TANDBERG Phone +47 6783 8514 mail jan.tore.korneliussen(a)tandberg.net 85c85 < #define HEAP_NB_FREE_LISTS 5 /* Number of free lists */ --- > #define HEAP_NB_FREE_LISTS 4 /* Number of free lists */ 90c90 < 0x10, 0x20, 0x80, 0x200, ~0UL --- > 0x20, 0x80, 0x200, ~0UL

1 0

Re: SHELL32: fix SHSimpleIDListFromPath to do the correct thing for non-existing pathes
by Alexandre Julliard Feb. 24, 2005

Feb. 24, 2005

Mike McCormack <mike(a)codeweavers.com> writes: > ChangeLog: > * fix SHSimpleIDListFromPath to do the correct thing for non-existing pathes This is causing some test failures (and also some extra successes, I guess we are on the right track...) shelllink.c:177: Test succeeded inside todo block: path_to_pidl returned a NULL pidl shelllink.c:197: Test failed: GetPath returned 'C:\nonexistent\file' shelllink.c:234: Test succeeded inside todo block: GetIconLocation failed (0x00000000) shelllink.c:236: Test failed: GetIconLocation returned 'c:\windows\system\shell32.dll' shelllink.c:238: Test succeeded inside todo block: GetIconLocation returned 0 -- Alexandre Julliard julliard(a)winehq.org

1 0