December 2004 - Wine-devel - list.winehq.org

Some performance stats
by Dmitry Timoshkov 21 Dec '04

21 Dec '04

Hello all, while debugging one of applications I'm working on I noticed a lot of GetPrivateProfileString calls with the same file name but in different case causes profile code to open and parse system.ini again. I sent a patch which helps to find a cached file in that case and do not parse it again. I had a thought that another speed improvement might be to use FindFirstFileW instead of CreateFileW/GetFileTime to retrieve last modification time of a file. I wrote a test under Windows to see which of FindFirstFileW or CreateFileW is faster. The test is attached. Here are the results (for 10000 loops) running the same binaries in Wine and Windows 2000 SP4 (hard disks are the same in both systems): =================================================================== Win2k SP4/NTFS volume: test_CreateFileW: P3/1GHz time elapsed 363 ms test_FindFirstFileW: P3/1GHz time elapsed 547 ms Wine/ext3 volume: test_CreateFileW: P3/1GHz time elapsed 543 ms test_FindFirstFileW: P3/1GHz time elapsed 1650 ms =================================================================== CreateFileW is only 1.5 times slower in Wine than in Windows, that's really not bad (especially taking into account Wine boot time), but still there is a possibility for an improvement. FindFirstFileW is 3 times slower in Wine than CreateFileW, while it's only 1.5 times slower in Windows. This needs to be optimized. -- Dmitry.

1 0

wine-alsa gives compile errors
by Joris Huizer 21 Dec '04

21 Dec '04

Hello, I'm not sure where to post this, so posting to wine-users and wine-devel; I got wine sources from cvs and tried compiling it -- something seems to be wrong in the alsa code - it gives compile errors about functions getting too many arguments (I attached an error log) Hopefully this is fixed soon regards, Joris

1 0

Re: [OLE #3] Tests For COM Functions (Try 2)
by Dmitry Timoshkov 21 Dec '04

21 Dec '04

"Robert Shearman" <rob(a)codeweavers.com> wrote: > This differs from the previous send of this patch by not using some > functions that are not present on Win9x and without DCOM95 and by > disabling the out-of-process COM tests, which seems to need more work, > but is useful for me testing locally. Dmitry, you reported to me before > that Win95 w/o DCOM95 does not export CoResumeClassObjects, but MSDN > claims that it does. Is MSDN wrong? Just checked Win95 OSR2 again: ole32.dll does not export CoResumeClassObjects. That's a clean system, without MS Office, DCOM95 or something like that. -- Dmitry.

1 0

My "Helping Applications Work" Guide
by Scott Ritchie 21 Dec '04

21 Dec '04

I've recently finished up my "helping applications work" guide. It's meant to be something an end user with a problem application can read, and if he has the will to learn how to help. However, I'm not exactly sure where to put it on the winehq website. Perhaps it should be linked from the main page of the applications database, or from the support tab, or something. Anyway, I'm posting it here for peer review. I've also sent it to wine-patches, but as I said nothing yet links to it. Thanks, Scott Ritchie ----helping_applications.template---- <h1>How to help get applications working in Wine</h1> <p>If you want to help get an application working in Wine, the first thing you should do is register yourself in the applications database and use one of your votes to indicate that you'd like more effort to be spent on the application. Every once in a while, a wine developer will finish a project and look for something to do - combing through the higher voted apps to find one that people need work on is a great way to spend one's time and fill up a todo list.</p> <p>If the application that you want working is not listed in the applications database, there is an easy to use form available for you to add it.  If the application is in the database, but lacks a maintainer you should consider becoming one. If you are familiar with wine and have a desire to test the application and help get or keep it working, please apply by clicking the link in the application's page. Each application should have a supermaintainer, and, if different versions of the application are substantially different (such as in Internet Explorer), each subversion should have a maintainer. Please don't feel deterred by the need to apply to become a maintainer - the application form is largely a formality to prevent abuse and we can virtually guarantee your acceptance.</p> <p>If you are the developer or publisher of the application, you obviously have a very big incentive to help get your application working under wine. Fortunately, there are many options available to you other than reporting bugs and hoping someone will fix them. By far the easiest way is to simply send free copies of your software to wine developers and hope they'll take an interest in getting it working. You'd be amazed how effective this approach can be, particularly for games. An alternative option, perhaps more effective and expensive, is to pay wine developers for their work on your application, either directly through a negotiated contract or indirectly by posting a bounty. The most direct method, however, is to help develop wine itself and contribute code directly, which is exactly what Corel did for WordPerfect several years ago. In any case, making a post on the wine developers <a href="http://www.winehq.org/site/forums">email list</a> can go a long way. <h2>If your application doesn't work:</h2> <p>If your application experiences problems in a particular area, or fails to even run at all, there are a number of steps you can take to help us. The most important thing is to find out where exactly the application is failing. To diagnose application problems, the first step is to run the program from the console using wine, rather than from a gui shortcut. This will allow wine to output error messages to the console, the understanding of which are key to solving the problem and getting the application to work.</p> <p>An application may not work because Wine doesn't yet fully implement one of the DLL files the application is trying to use. If you encounter a DLL not found error, or see a lot of "FixMe:" messages while running the application in wine, this is likely the case. When this occurs, you can try using native (non-wine) DLL files in place of Wine's builtin ones. Check the application database page for the program. There may be special configuration options or instructions for installing native DLL files there that you can try to get the application working. For further configuration help, please see the <a href="http://www.winehq.org/site/docs/wine-user/running">Running Wine</a> section of the User Guide.</p> <p>If the application still doesn't work, it's probably due to a bug or deficiency in Wine and we'd like to hear about it. Please see the <a href="http://bugs.winehq.org/">reporting bugs</a> page for instructions on how to best report bugs with applications.</p> <h2>If your application does work, but with some difficulty:</h2> <p>Sometimes, applications run under wine but they don't function quite as smoothly as they do in windows. They may have display errors, a feature may be broken, or they may run unusually slow. These applications should receive a lower rating from their maintainers of between 2 and 4 stars in the Application's Database, depending on the degree of difficulty encountered.</p>  <p>If you have found a way to make an application work that is more complicated than simply installing it, please share that information by posting on the application's page in the database. If you are the maintainer for the application, please post the instructions in a "howto," which will appear inside green bars at the top of the application's page.</p> <h2>If your application used to work, but has since broken in a new version of wine:</h2> <p>Wine is a large and complex project, composed of many files written by different authors. Sometimes, an attempt to change a file and expand support for one application will unexpectedly cause another application to stop functioning. These changes are known as "regressions", and they are unfortunately sometimes found in the wine source code because the author of a patch that causes a regression is quite simply unaware of it. Since the wine developers can't possibly test every application with every patch, we have to rely on the community to inform us of when regressions occur so that the problem can be easily identified and ultimately fixed. Without community involvement, regressions can go unfixed for potentially very long periods of time.</p> <p>If your application has experienced a regression, please try and provide us with as much information as you can about when and how it broke. This allows us to isolate the exact thing we screwed up in the code and provide a fix. Please provide as much as you know about which version of wine worked, and which version didn't, including the version number and how you installed it (from source, binary packages, etc.) Finally, please post these things in the Application Database page for the app.</p> <p>If you wish to be extremely helpful, you can try to isolate the exact patch which broke your application. This takes quite a bit of time and effort, but it is quite simply the best way to get your application working again. When it comes to fixing regressions, the only thing more helpful to the wine developers than knowing exactly which patch caused a regression is receiving a fix for the patch itself. For help with isolating problem patches, please see the documentation on <a href="http://www.winehq.org/site/docs/wine-devel/x1375">regression testing</a>.</p>

2 1

Re: [LOSTWAGES]New short About blurb on the Front Page
by Scott Ritchie 20 Dec '04

20 Dec '04

http://www.winehq.org/hypermail/wine-patches/2004/12/0343.html Is there a reason why this little update hasn't been committed? I think it makes the front page a bit more user-friendly, as well as updating some of the links. Thanks, Scott Ritchie

1 0

Re: Make winetest.exe detect if it is running on a visible desktop. Now without the linewrap.
by Ferenc Wagner 20 Dec '04

20 Dec '04

Jakob Eriksson <jakov(a)vmlinux.org> writes: > Now without the linewrap. I hate to say this, but it's still wrapped... :( -- Feri.

1 0

Janitorial: HeapFree of NULL
by Michael Stefaniuc 20 Dec '04

20 Dec '04

Hello, there is a lot (my attached smatch script found 234 occurences) of code like if (this) HeapFree(GetProcessHeap(), 0, this); HeapFree(GetProcessHeap(), 0, that); which is redundant because after Win2000 (if i can trust the comment in RtlFreeHeap) freeing a NULL pointer isn't an error. I've checked it Win2000 and can confirm that. I've also checked Win95 and Win98 and both don't crash when HeapFree'ing a NULL but they return an error and SetLastError to 212 "ERROR_LOCKED". In the above code the return code of HeapFree isn't checked so this wouldn't matter if somebody would run the Wine code on that Win versions. So i propose to shorten that code to HeapFree(GetProcessHeap(), 0, this); HeapFree(GetProcessHeap(), 0, that); I've done this already for the wininet dll (see patch to wine-patches) and if it gets accepted i'll take care of the rest. Advantages: - less (redundant) code - more pleasant to the eye - for the wininet.dll it saves 1.1kB (FC2, gcc-3.3.3-7) in the generated code (ok, the wininet.dll.so is 1.6 MB but still) Disadvantages: - if the pointer is NULL it takes longer for that code path. But i don't think it matters cause this happens mostly only on the (unlikely) error path. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: OpenSCManager() bug
by Ivan Leo Puoti 20 Dec '04

20 Dec '04

>Hello, > >initially i tested this stuff under XP and it raised exception if lpDatabaseName >is invalid pointer. But after you noticed the bug i run the test under 2000 and >it has been returned ERROR_NOACCESS. > >Both versions return ERROR_INVALID_NAME if lpDatabaseName is empty string. > >I think the patch should look like this: In Age of Empires 2 lpDatabaseName is just an empty string, so I've sent a patch to wine-patches that allows the database name to be '\0'. Ivan.

1 0

Re: TopLevelWindow Maximize
by Dmitry Timoshkov 20 Dec '04

20 Dec '04

"Katia Maculan" <katia.maculan(a)isis-papyrus.com> wrote: > + switch (message) > + { > + case WM_SHOWWINDOW: > + case WM_SIZE: > + DefWindowProc(hWnd, message, wParam, lParam); > + PostMessage (hWnd, WM_PAINT, 0, 0); If you wish to schedule a WM_PAINT message you have to invalidate a window. -- Dmitry.

2 1

Re: OpenSCManager() bug
by Alexander Yaworsky 19 Dec '04

19 Dec '04

Hello, initially i tested this stuff under XP and it raised exception if lpDatabaseName is invalid pointer. But after you noticed the bug i run the test under 2000 and it has been returned ERROR_NOACCESS. Both versions return ERROR_INVALID_NAME if lpDatabaseName is empty string. I think the patch should look like this: @@ -750,6 +750,11 @@ if( lpDatabaseName ) { + if( IsBadStringPtrW( lpDatabaseName, -1 ) ) + { + SetLastError( ERROR_NOACCESS ); + return NULL; + } if( strcmpiW( lpDatabaseName, SERVICES_ACTIVE_DATABASEW ) == 0 ) { /* noop, all right */ On the other hand i think that all this stuff is a kind of masturbation. When i implemented this, i used some tests (i'm going to put them into shape of unit tests) to investigate the real behaviour. The last patch establishes that behaviour replacing fixme that was an eyesore, but in reality the database name is not used and IMO will never be used. Ivan Leo Puoti wrote: > This patch http://cvs.winehq.org/patch.py?id=14769 had caused a problem with Age > of Empires. The game uses a copy protection system that is installed as a > service, before your patch, the service tried to load the copy protection driver > (This fails, but that's another story), after your patch wine goes straight to > the debugger after calling OpenSCManager. I added a trace and found that this > code is executed > { > FIXME("ERROR_INVALID_NAME"); > return NULL; > } > and causes the crash. The value of lpDatabaseName that AoE passes to the > function is 1; also according to MSDN > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba… > lpDatabaseName can be NULL, and in this case SERVICES_ACTIVE_DATABASE is opened. > As it's late here the only idea I get at the moment is to print the value as a > FIXME or ERR or whatever, and not return NULL, as this doesn't appear to be the > correct behavior. As you've implemented this stuff and I don't know much about > it I would like to know what you think.

1 0