Re: vartest.c - major pain in the build process
Dmitry Timoshkov wrote: Why? What prevents someone to run the tests manually in interactive mode once a day? If that someone can't or won't do it, then we have to find another someone. I'm pretty sure that there are enough not lazy people wishing to help we could to choose from. We can just have winrash run in interactive mode. Once tests are ready to run, a message pops up saying new tests available or something of the sort, the user then chooses to run them now or later, like the windows automatic updates. Like this we could test both visible and invisible desktops, and could have a fair amount of results for both environments. Ivan.
Use of Favourite instead a Favorite in our regedit
Hi, while looking through some registries (via regedit) on several windows versions and Wine, I saw that we use Favourites/Favourite etc.. instead of Favorites/Favorite in our regedit implementation. Is this deliberate or should I create a patch for this? The patch will also change ID_FAVOURITES_MENU, ID_FAVOURITES_ADDTOFAVOURITES,ID_FAVOURITES_REMOVEFAVOURITE. I know it's not a functional change, but hey, one has to be busy. Cheers, Paul
Re: invisible desktops - major pain in the testing process
Dmitry Timoshkov [EMAIL PROTECTED] writes: Ferenc Wagner [EMAIL PROTECTED] wrote: I was under the impression that most of the tests are independent of desktop visibility. Not really. Any API which directly or indirectly creates windows or uses GDI is affected by the desktop visibility. Roughly checking the latest results shows that the following tests are affected seriously by desktop visibility: ddraw:ddrawmodes gdi32:metafile ntdll:reg user32:input user32:msg user32:sysparams Some pretty important ones, I agree, but hardly a majority. Also, as I already pointed out, Wine doesn't run in that mode at all, so we can't compare apples to apples in that case. You are absolutely right in the cases where it makes any difference (more than the above list) And the apps most of the developers/users care about should be run on a visible desktop anyway. Yes. I don't argue that testing on a visible desktop is a must. Some people are actually doing that, it seems. Or maybe that's just you alone... :) Anyway, I tried to make such results visually distinctive so that we shouldn't drop all the rest. Too bad it doesn't work. figuring out why it doesn't work is completely useless IMO, since the results of the tests running on an invisible desktop can't be used for a reasonable comparison. I see your point, even if find it a bit strong. Ivan's suggestion is nice, but that requires a probably not so trivial change in winrash. I wonder if Chris will do it. And the winrash service is the only way to get several reports quickly for a new test. Why? What prevents someone to run the tests manually in interactive mode once a day? Nothing. Somebody is actually doing it for NT4, 2000 and XP. I did it now and then for Win98, but this one can't really be told apart from the invisible ones (not considering error counts). From http://winehq.org/site/janitorial: Volunteers who will run the tests their Windows platform of choice on a regular basis so that we quickly fix incorrect tests * Win95: Michael Stefaniuc, Fabian Cenedese * Win98: Tony Lambregts, Jeff Smith (SE) * WinNT: Luke Stras * WinME: James K Whiting * Win2k: Tom Wickline, Kye Lewis * WinXP: David Miller, Kye Lewis If that someone can't or won't do it, then we have to find another someone. I'm pretty sure that there are enough not lazy people wishing to help we could to choose from. OK. -- Feri.
Re: vartest.c - major pain in the build process
Ivan Leo Puoti [EMAIL PROTECTED] wrote: We can just have winrash run in interactive mode. Once tests are ready to run, a message pops up saying new tests available or something of the sort, the user then chooses to run them now or later, like the windows automatic updates. Like this we could test both visible and invisible desktops, and could have a fair amount of results for both environments. I have to repeat again: Winword, Photoshop, Internet Explorer or any other application I and most (if not all) developers and users are care about do not run on an invisible desktop, therefore I don't care about tests running in that mode at all. It's not simply an optional mode, that's a mode completely useless for vast majority of Wine users/developers. -- Dmitry.
Re: vartest.c - major pain in the build process
Dmitry Timoshkov wrote: Ivan Leo Puoti [EMAIL PROTECTED] wrote: We can just have winrash run in interactive mode. Once tests are ready to run, a message pops up saying new tests available or something of the sort, the user then chooses to run them now or later, like the windows automatic updates. Like this we could test both visible and invisible desktops, and could have a fair amount of results for both environments. I have to repeat again: Winword, Photoshop, Internet Explorer or any other application I and most (if not all) developers and users are care about do not run on an invisible desktop, therefore I don't care about tests running in that mode at all. It's not simply an optional mode, that's a mode completely useless for vast majority of Wine users/developers. OK, then we can have winrash only run them in interactive mode, end of story. Ivan.
Tools for identifying what a DLL provides?
I have a DLL from a manufacturer that I don't have the source for, nor do I have the header or the import library for. Since Wine developers frequently have to reverse engineer what a given DLL provides, does anybody have a good recommendation for a tool that can scan the DLL and report what functions it exports, and their arg types and return types?
Re: status of winetest.exe
Hi Stefan, Yes, things are broken due some behind-the-scenes that turned out not to be the case. I've been a bit busy these past five days, but I'm back in the country (and, more importantly, with net connectivity) so should get these problems fixed soon. Cheers, Paul. On Friday 25 February 2005 22:13, Stefan Leichter wrote: i have noticed that the winetest are not longer built since the middle of the week. Can you take a look if something is broken? pgp4SH0lxMrm4.pgp Description: PGP signature
Re: [PATCH] Added 2 functions to shell32
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dmitry Timoshkov wrote:
| Gianluigi Tiesi [EMAIL PROTECTED] wrote:
|
|
|+BOOL WINAPI PathIsEqualOrSubFolder(LPCWSTR path1, LPCWSTR path2)
|+{
|+ int i;
|+ int len;
|+ if (!path1 || !path2) return FALSE;
|+
|+ len = strlenW(path1);
|+ if (len strlenW(path2)) return FALSE;
|+
|+ for (i=0; i len; i++)
|+ if (path1[i] != path2[i]) return FALSE;
|+ return TRUE;
|+}
|
|
| You need to do a case insensitive comparison of paths.
|
| Also, if you could use a usual for Wine formatting style with 4 space
| indentation that would be very nice.
|
This version does case insensitive check, I'm using tolowerW instead of
standard windows towlower,
hope it's correct. I've used one tab indentation since the other code uses the
same indentation.
I may provide other documented/undocumented functions if you like.
Bye
- --
Gianluigi Tiesi [EMAIL PROTECTED]
EDP Project Leader
Netfarm S.r.l. - http://www.netfarm.it/
Free Software: http://oss.netfarm.it/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCIoqy3UE5cRfnO04RAlAiAJ4igIRlGRlXKSaRyi5VJsL/UzdVzwCgkn2c
vB/SAxWHX1hkDn2BEe6MEUo=
=449f
-END PGP SIGNATURE-
Index: dlls/shell32/shell32.spec
===
RCS file: /home/wine/wine/dlls/shell32/shell32.spec,v
retrieving revision 1.96
diff -u -r1.96 shell32.spec
--- dlls/shell32/shell32.spec 23 Feb 2005 15:41:14 - 1.96
+++ dlls/shell32/shell32.spec 28 Feb 2005 03:03:45 -
@@ -250,6 +250,7 @@
# = NT5
714 stdcall @(ptr) SHELL32_714 # PathIsTemporaryW
730 stdcall -noname RestartDialogEx(long wstr long long)
+ 755 stdcall -noname PathIsEqualOrSubFolder(wstr wstr)
1217 stub FOOBAR1217 # no joke! This is the real name!!
@@ -456,3 +457,4 @@
# _WIN32_IE = 0x600
@ stdcall SHDefExtractIconA(str long long ptr ptr long)
@ stdcall SHDefExtractIconW(wstr long long ptr ptr long)
+@ stub SHCreateShellItem
Index: dlls/shell32/shellpath.c
===
RCS file: /home/wine/wine/dlls/shell32/shellpath.c,v
retrieving revision 1.98
diff -u -r1.98 shellpath.c
--- dlls/shell32/shellpath.c14 Feb 2005 11:07:55 - 1.98
+++ dlls/shell32/shellpath.c28 Feb 2005 03:03:49 -
@@ -411,6 +411,23 @@
}
/*
+ * PathIsEqualOrSubFolder [SHELL32.755]
+ */
+BOOL WINAPI PathIsEqualOrSubFolder(LPCWSTR path1, LPCWSTR path2)
+{
+ int i;
+ int len;
+ if (!path1 || !path2) return FALSE;
+
+ len = strlenW(path1);
+ if (len strlenW(path2)) return FALSE;
+
+ for (i=0; i len; i++)
+ if (tolowerW(path1[i]) != tolowerW(path2[i])) return FALSE;
+ return TRUE;
+}
+
+/*
* PathFileExists [SHELL32.45]
*/
BOOL WINAPI PathFileExistsAW (LPCVOID lpszPath)
Index: dlls/shell32/undocshell.h
===
RCS file: /home/wine/wine/dlls/shell32/undocshell.h,v
retrieving revision 1.28
diff -u -r1.28 undocshell.h
--- dlls/shell32/undocshell.h 13 Dec 2004 21:19:01 - 1.28
+++ dlls/shell32/undocshell.h 28 Feb 2005 03:03:49 -
@@ -410,6 +410,8 @@
BOOL WINAPI PathIsExeAW(LPCVOID lpszPath);
+BOOL WINAPI PathIsEqualOrSubFolder(LPCWSTR path1, LPCWSTR path2);
+
BOOL WINAPI PathIsDirectoryAW(LPCVOID lpszPath);
BOOL WINAPI PathFileExistsAW(LPCVOID lpszPath);
[SOLVED] Re: Picasa2- works great, one font issue
Okay - I checked out the latest Wine from CVS and it seems to be fixed. I think this patch was the one that fixed it: revision 1.82 date: 2005/02/25 13:59:22; author: julliard; state: Exp; lines: +9 -9 TANABE Hiroshi [EMAIL PROTECTED] wrote: Remove (buf !buflen) checking. Fixed outline rendering with GGO_GRAY?_BITMAP option. Improved fixed-pitch fonts detection. Here's some screenshots from the program while running: http://www.grack.com/news/Picasa2underWine.html Note that clicking the email button in Picasa will crash it - probably the MAPI stubs that cause it: err:mapi:MAPILogon Stub fixme:seh:EXC_RtlRaiseException call (from 0x53e297) to unimplemented function mapi32.dll.MAPISendMail Thanks, Matt. Matthew Mastracci wrote: I tried out the latest Picasa2 (picasa2-setup-1884.exe) on a whim against the Wine 20050111 package and it works great. There don't seem to be any major functionality issues and the app is very responsive - it almost feels like a native gnome app. The one visual issue with the program is that certain fonts within the program seem to be blitted incorrectly: http://www.grack.com/news/Picasa2underWine.html It appears that Picasa 2 might ship with some pre-computed alpha-blended fonts in the form of .ytf files in the runtime directory. When I move these fonts out of the way, all the fonts (including those fonts used to create the Import/Slideshow/Timeline/etc. buttons) within the program appear screwed up like the album-title fonts do when those files are present. Note that after copying the generated .ytf files from a Windows '98 installation, all of the characters within Picasa are rendered perfectly. Where might I start looking for the problem? I think it has something to do with drawing to backbuffer that eventually gets flushed to disk, since copying the cached font files from a standard Windows install seems to fix the problem. WINEDEBUG=+gdi doesn't yield much, but I think WINEDEBUG=+bitmap or WINEDEBUG=+font is where I'm supposed to be looking. Matt.
Re: vartest.c - major pain in the build process
On Mon, Feb 28, 2005 at 01:10:25PM +0100, Ivan Leo Puoti wrote: OK, then we can have winrash only run them in interactive mode, end of story. Don't need to do that, there are plenty of tests that run fine with an invisible desktop, there's enough value in having some automated tests. Maybe we need to separate the results... -- Dimi.
Re: vartest.c - major pain in the build process
Dimitrie O. Paun wrote: Don't need to do that, there are plenty of tests that run fine with an invisible desktop, there's enough value in having some automated tests. Maybe we need to separate the results... I don't really care at all, I just think winrash should be kept and should be improved to run interactive tests too. Ivan.
Re: dsound questions
tor, 24,.02.2005 kl. 22.56 -0600, skrev Jeremy White: Case 1: In the first case, in DSOUND_MixOne, we compute a 'probably_valid_to' based on the 'write_pos', which seems quite wrong; I believe the logic should be testing whether or not there is sufficient data in the mixing buffer, not whether or not there is sufficient room in the buffer overall. The probably_valid_to check is for whether there's likely to be sufficient data in the *source* streaming buffer to warrant filling the destination buffer. If the app has only half-filled the streaming buffer, then it's a better idea to only mix what we know it put there, and mix the rest of the buffer only after the app has written more stuff to the buffer, rather than mix everything we can, including invalid data, then having to backtrack and do a full mix reset when the app overwrites the invalid data with valid data. The existing code should be correct. Then, to my great joy, I found two separate apparent OSS bugs on two different systems. In one, the result of DSP_GETOPTR would temporarily 'go backwards' when doing mmaped transfers; in the other, my laptop would just stop reading data out of an mmapped buffer, for no apparent reason. Questions: 1) Is there a good set of OSS test programs (particularly for mmap) I could/should use to simply validate that my system is rational wrt OSS? 2) Are the performance gains from DMA mmap really worthwhile? I wonder if mmap mode is buggy and if we wouldn't be better off swtiching to a pure 'write' approach. In my experience mmap is the only way to get all of good latency, good precision, minimal sound choppage, reduced CPU usage, and reduced Linux scheduler issues. But Cedega's wineoss still have mmap disabled by default since a lot of OSS drivers have bugs. Since ALSA is supposed to be better, mmap is enabled by default for its winealsa.
Re: Wine cabinet.dll FDI Conformace Test Patch
Hi, On Sun, Feb 27, 2005 at 10:21:15PM -0800, Rizwan Kassim wrote: Folks, Aleksandr Liber and I have put together a set of tests for cabinet.dll. Before we submit them to wine-patches, can anyone offer any critiques/input? We plan to submit in a day or two. Cool stuff! It's wonderful to have people work on OSS projects such as Wine during study tasks. (your project has been announced before, but I'm commenting on this now only) Any advice you can offer will be greatly appreciated! It's an unspoken rule that preprocessor directives (#ifdef, ...) always start at the very beginning of a line to make sure one recognizes immediately which parts of the code are being processed and which ones aren't. AFAICS you're not using wine test suite infrastructure, e.g. ok() etc. Using printf() directly strikes me as being quite bad, too... Apart from that it appears to be very good. Thanks! Andreas Mohr
Re: Tools for identifying what a DLL provides?
Hi, On Mon, Feb 28, 2005 at 09:48:40AM -0600, David D. Hagood wrote: I have a DLL from a manufacturer that I don't have the source for, nor do I have the header or the import library for. Since Wine developers frequently have to reverse engineer what a given DLL provides, does anybody have a good recommendation for a tool that can scan the DLL and report what functions it exports, and their arg types and return types? You really want http://www.dependencywalker.com/ , trust me. But probably http://www.pe-explorer.com/ is very useful, too... Or maybe even winedump... Andreas Mohr
Re: dsound questions
Ove Kaaven wrote: tor, 24,.02.2005 kl. 22.56 -0600, skrev Jeremy White: Case 1: In the first case, in DSOUND_MixOne, we compute a 'probably_valid_to' based on the 'write_pos', which seems quite wrong; I believe the logic should be testing whether or not there is sufficient data in the mixing buffer, not whether or not there is sufficient room in the buffer overall. The probably_valid_to check is for whether there's likely to be sufficient data in the *source* streaming buffer to warrant filling the destination buffer. If the app has only half-filled the streaming buffer, then it's a better idea to only mix what we know it put there, and mix the rest of the buffer only after the app has written more stuff to the buffer, rather than mix everything we can, including invalid data, then having to backtrack and do a full mix reset when the app overwrites the invalid data with valid data. The existing code should be correct. Whoops; I think I see the source of the confusion. I meant to say that the computation of 'probably_valid_left' was incorrect (which is what my patch addressed); the use and computation of 'probably_valid_to' is correct afaict. In fact, I believe my code more properly enforces the use of 'probably_valid_to'. In other words, afaict, the current code computes the difference between the number of bytes that have been played from the input source stream (buf_writepos) and the end of the data the app has written (probably_valid_to). It then clips the mixing length to that size. But what it should really be interested is the amount of as yet unmixed data in the source stream buffer, and that would be properly computed by taking the difference of probably_valid_to and dsb-buf_mixpos. Does that make sense? Cheers, Jeremy
Re: Tools for identifying what a DLL provides?
On February 28, 2005 08:55 am, Andreas Mohr wrote: Hi, On Mon, Feb 28, 2005 at 09:48:40AM -0600, David D. Hagood wrote: I have a DLL from a manufacturer that I don't have the source for, nor do I have the header or the import library for. Since Wine developers frequently have to reverse engineer what a given DLL provides, does anybody have a good recommendation for a tool that can scan the DLL and report what functions it exports, and their arg types and return types? You really want http://www.dependencywalker.com/ , trust me. But probably http://www.pe-explorer.com/ is very useful, too... Or maybe even winedump... Andreas Mohr Yes, but they aren't going to throw the arguments and return types out are they? The only way to do that, surely, is disassembly to see what is referenced off the stack and returned? -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
Re: dsound questions
man, 28,.02.2005 kl. 11.23 -0600, skrev Jeremy White: In other words, afaict, the current code computes the difference between the number of bytes that have been played from the input source stream (buf_writepos) and the end of the data the app has written (probably_valid_to). It then clips the mixing length to that size. But what it should really be interested is the amount of as yet unmixed data in the source stream buffer, and that would be properly computed by taking the difference of probably_valid_to and dsb-buf_mixpos. It is true that probably_valid_left is the distance between writepos and probably_valid_to, and that this is used to cut off the mixlen. But the original mixlen (before cutting it) is *also* measured from the writepos (in the primary buffer's frame of reference, of course). The value you're apparently after, the amount of as yet unmixed data, is computed from the mixlen shortly after this, by subtracting primary_done (done above the remaining mixlen trace). So this should already be taken care of.
Re: invisible desktops - major pain in the testing process
Yes. I don't argue that testing on a visible desktop is a must. Some people are actually doing that, it seems. Or maybe that's just you alone... :) Anyway, I tried to make such results visually distinctive so that we shouldn't drop all the rest. Too bad it doesn't work. figuring out why it doesn't work is completely useless IMO, since the results of the tests running on an invisible desktop can't be used for a reasonable comparison. I see your point, even if find it a bit strong. Ivan's suggestion is nice, but that requires a probably not so trivial change in winrash. I wonder if Chris will do it. What change do you want? The ability for winetest to be able to interact with the desktop? I've tried enabling this before but it didn't seem to have any effect. I've been quite busy lately and haven't had the time to keep on on winrash development. I'd like to turn over maintenance on winrash to someone else, if anyone is interested feel free to email me and I can set you up as an admin on the project. Chris
Patch 16316 causes regression in Irfan View
Patch 16316 causes regression in Irfan View. When I attempt to put Irfan View ( http://appdb.winehq.org/appview.php?appId=163 ) into slide show mode (Menu: File - Slideshow, add some files and Play) Irfan View locks up and needs a control-c at the console to kill it. I will investigate further tomorrow... ChangeSet ID: 16316 CVSROOT:/opt/cvs-commit Module name:wine Changes by: [EMAIL PROTECTED] 2005/02/24 13:42:08 Modified files: dlls/user : painting.c Log message: Repaint the non-client area to work around broken WM_PAINT handlers also when doing a synchronous update with RDW_UPDATENOW. Patch: http://cvs.winehq.org/patch.py?id=16316 Old revision New revision Changes Path 1.19 1.20 +19 -3 wine/dlls/user/painting.c
OpenGL _client regression with ATI.
Hi, after the whole _client, _window changes for VisualID's DirectX started displaying a bit of garbage at the top of the screen, which I toughed was because the window frames weren't taken into account in the view-port. This is sort of what's happening but it's worse. When I'm using ATI's driver, the viewport comes up as the whole screen, so as I move the window from the top left of my desktop so the clipping changes. It also affects non-DirectX stuff, e.g. with a desktop set in ~/.wine/config some windows come up centred as if the whole screen is taken into account and not just the desktop view, and sometimes a window that should be a given size resizes to the whole screen. With mesa the openGL problems don't appear. I haven't had any problems with any other openGL applications so I can only assume that it's a problem in wine. Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [programs/regedit] Use Favorit* instead of Favourit*
Paul Vriens wrote: Hi, Our regedit displays Favourites in the menu. This patch changes that to use Favorites. The patch also changes the variables with FAVOURITE in the name. The reasoning is: a. Windows uses Favorite(s) all over the place. b. We do too. That's the only reasoning and not if either one is better (UK/US etc..) No functional changes btw. Changelog Change Favourite(s) into Favorite(s) Fair enough for strings in the English, US resources, as long as the strings in the English, Neutral resources are still spelt correctly. Change variables containing FAVOURITE into FAVORITE Why do this? Rob
Re: [SOLVED] Re: Picasa2- works great, one font issue
On Mon, 28 Feb 2005 11:27, Matthew Mastracci wrote: Okay - I checked out the latest Wine from CVS and it seems to be fixed. I think this patch was the one that fixed it: revision 1.82 date: 2005/02/25 13:59:22; author: julliard; state: Exp; lines: +9 -9 TANABE Hiroshi [EMAIL PROTECTED] wrote: Remove (buf !buflen) checking. Fixed outline rendering with GGO_GRAY?_BITMAP option. Improved fixed-pitch fonts detection. Yes, that would be what fixed it. Many DirectX games also had font problems fixed by that patch. In fact any application where the fonts looked like random noise is likely to have been fixed to that extent by that patch.
Re: Implements OleLoadPicturePath
Maxime Belleng wrote:
Hello, here is an implementation of OleLoadPicturePath.
The filename can be either a local file or an url.
In case of a url, I needed a user-agent for wininet. I put a dummy value
as I didn't find a default wine value. Is there a default value
somewhere for the whole project ?
a+
Max
ChangeLog:
* Implements OleLoadPicturePath
Index: wine/dlls/oleaut32/olepicture.c
===
RCS file: /home/wine/wine/dlls/oleaut32/olepicture.c,v
retrieving revision 1.55
diff -u -r1.55 olepicture.c
--- wine/dlls/oleaut32/olepicture.c 25 Feb 2005 14:07:57 - 1.55
+++ wine/dlls/oleaut32/olepicture.c 27 Feb 2005 10:51:43 -
@@ -71,7 +71,9 @@
#include olectl.h
#include oleauto.h
#include connpt.h
+#include wininet.h
#include wine/debug.h
+#include wine/unicode.h
#include wine/wingdi16.h
#include cursoricon.h
@@ -1998,11 +2000,122 @@
DWORD dwReserved, OLE_COLOR clrReserved, REFIID riid,
LPVOID *ppvRet )
{
- FIXME((%s,%p,%ld,%08lx,%s,%p): stub\n,
+ static const WCHAR file[] = { 'f','i','l','e',':','/','/',0 };
+ static const WCHAR name[] = { 'w','i','n','e','-','a','g','e','n','t',0};
+ IPicture *ipicture;
+ HANDLE hFile;
+ DWORD dwFileSize;
+ HGLOBAL hGlobal = NULL;
+ DWORD dwBytesRead = 0;
+ IStream *stream;
+ BOOL bRead;
+ IPersistStream *pStream;
+ HRESULT hRes;
+
+ TRACE((%s,%p,%ld,%08lx,%s,%p): stub\n,
debugstr_w(szURLorPath), punkCaller, dwReserved, clrReserved,
debugstr_guid(riid), ppvRet);
- return E_NOTIMPL;
+ if (!ppvRet) return E_POINTER;
+
+ if (strncmpW(szURLorPath, file, 7) == 0) {
+ szURLorPath += 7;
+
+ hFile = CreateFileW(szURLorPath, GENERIC_READ, 0, NULL, OPEN_EXISTING,
+ 0, NULL);
+ if (hFile == INVALID_HANDLE_VALUE)
+ return E_UNEXPECTED;
+
+ dwFileSize = GetFileSize(hFile, NULL);
+ if (dwFileSize != INVALID_FILE_SIZE )
+ {
+ hGlobal = GlobalAlloc(GMEM_FIXED,dwFileSize);
+ if ( hGlobal)
+ {
+ bRead = ReadFile(hFile, hGlobal, dwFileSize, dwBytesRead, NULL);
+ if (!bRead)
+ {
+ GlobalFree(hGlobal);
+ hGlobal = 0;
+ }
+ }
+ }
+ CloseHandle(hFile);
+ } else {
+ HINTERNET hInternet;
+ BOOL res = FALSE;
+
+ hInternet = InternetOpenW(name, INTERNET_OPEN_TYPE_PRECONFIG, NULL,
+NULL, 0);
+ if (hInternet)
+ {
+ HINTERNET hFile;
+ hFile = InternetOpenUrlW(hInternet, szURLorPath, NULL, -1L,
+ INTERNET_FLAG_RESYNCHRONIZE, (DWORD_PTR)NULL);
+ if (hFile)
+ {
+ DWORD total = 4096;
+ DWORD nbRead;
+
+ hGlobal = GlobalAlloc(GMEM_FIXED, 4096);
+ if (hGlobal)
+ {
+ do {
+ res = InternetReadFile(hFile, hGlobal, 4096, nbRead);
+ if (res (nbRead0))
+ {
+ HGLOBAL hNewGlobal;
+ hNewGlobal = GlobalReAlloc(hGlobal, total+4096, 0);
+ if (!hNewGlobal)
+ {
+ res = FALSE;
+ break;
+ }
+ }
+ } while (res (nbRead0));
+ }
+ }
+
+ InternetCloseHandle(hInternet);
+ }
+ if (!res)
+ {
+ GlobalFree(hGlobal);
+ }
+ }
+
+ if (!hGlobal)
+ return E_UNEXPECTED;
+
+ hRes = CreateStreamOnHGlobal(hGlobal, TRUE, stream);
+ if (FAILED(hRes))
+ {
+ if (stream != NULL) IStream_Release(stream);
A valid stream will not be returned on failure, so no need for the extra
check here.
+ GlobalFree(hGlobal);
+ return hRes;
+ }
+
+ hRes = CoCreateInstance(CLSID_StdPicture, punkCaller, CLSCTX_INPROC_SERVER,
+ IID_IPicture, (LPVOID*)ipicture);
+ if (hRes != S_OK) {
Lack of cleanup code here.
+ return hRes;
+ }
+
+ hRes = IPicture_QueryInterface(ipicture, IID_IPersistStream, (LPVOID*)pStream);
+ if (hRes) {
+ IPicture_Release(ipicture);
And here.
+ return hRes;
+ }
+
+ IPersistStream_Load(pStream, stream);
You should probably check the return value from this function as it is
kinda vital to the function you are implementing.
+ IPersistStream_Release(pStream);
+ IStream_Release(stream);
+ hRes = IPicture_QueryInterface(ipicture,riid,ppvRet);
+ if (hRes)
+ FIXME(Failed to get interface %s from IPicture.\n,debugstr_guid(riid));
+
+ IPicture_Release(ipicture);
+ return hRes;
}
/***
Index: wine/dlls/oleaut32/Makefile.in
===
RCS file: /home/wine/wine/dlls/oleaut32/Makefile.in,v
retrieving revision 1.57
diff -u -r1.57 Makefile.in
--- wine/dlls/oleaut32/Makefile.in 27 Oct 2004 00:47:53 - 1.57
+++ wine/dlls/oleaut32/Makefile.in 27 Feb 2005 10:52:08 -
@@ -4,7 +4,7 @@
SRCDIR= @srcdir@
VPATH = @srcdir@
MODULE= oleaut32.dll
-IMPORTS = ole32 rpcrt4 user32 gdi32 advapi32 kernel32 ntdll
+IMPORTS =
Re: [QUARTZ] Handle End Of Stream notifications
Christian Costa wrote:
Index: dlls/quartz/dsoundrender.c
===
RCS file: /home/wine/wine/dlls/quartz/dsoundrender.c,v
retrieving revision 1.6
diff -u -r1.6 dsoundrender.c
--- dlls/quartz/dsoundrender.c 6 Jan 2005 19:36:47 - 1.6
+++ dlls/quartz/dsoundrender.c 27 Feb 2005 20:48:17 -
@@ -550,8 +550,8 @@
static HRESULT WINAPI DSoundRender_JoinFilterGraph(IBaseFilter * iface,
IFilterGraph *pGraph, LPCWSTR pName)
{
-HRESULT hr;
DSoundRenderImpl *This = (DSoundRenderImpl *)iface;
+HRESULT hr = S_OK;
TRACE((%p/%p)-(%p, %s)\n, This, iface, pGraph, debugstr_w(pName));
@@ -563,7 +563,14 @@
*This-filterInfo.achName = '\0';
This-filterInfo.pGraph = pGraph; /* NOTE: do NOT increase ref. count */
- hr = IFilterGraph_QueryInterface(pGraph, IID_IMediaEventSink, (LPVOID*)This-pEventSink);
+This-pEventSink = NULL;
+if (pGraph)
+{
+/* Cache IMediaEventSink interface w/o increasing filtergraph refcount */
I appreciate that this works perfectly fine at the moment, but these
kind of assumptions can lead to difficult to track memory corruptions,
so it would be best to avoid caching the object here and querying for it
when it's needed.
+hr = IFilterGraph_QueryInterface(pGraph, IID_IMediaEventSink, (LPVOID*)This-pEventSink);
+if (SUCCEEDED(hr))
+IMediaEventSink_Release(This-pEventSink);
+}
}
LeaveCriticalSection(This-csFilter);
Rob
Re: [PATCH] Added 2 functions to shell32
I doubt shell32 function on windows does this check, also original windows
shell32
function is a lot more complicated and longer, I've compared the results between
real and my code and they are correct.
I wrote a small test for this function showing that your implementation is
almost
correct. It failes in two cases:
1. If a path ends with '\' and is compared with one that doesn't, then it's
length is
less than the other one, but both are the same paths.
2. If a path doesn't end with '\' and is compared with a longer one that has
the same
first len chars, but is not the same, ex:
c:\test
c:\test123
Changelog:
Added test for PathIsEqualOrSubFolder
Index: dlls/shell32/tests/shellpath.c
===
RCS file: /home/wine/wine/dlls/shell32/tests/shellpath.c,v
retrieving revision 1.6
diff -u -p -r1.6 shellpath.c
--- dlls/shell32/tests/shellpath.c 10 Feb 2005 19:19:35 - 1.6
+++ dlls/shell32/tests/shellpath.c 28 Feb 2005 21:19:31 -
@@ -871,6 +871,55 @@ static void testNonExistentPath(void)
userShellFolders);
}
+typedef BOOL (WINAPI*fnPathIsEqualOrSubFolder)(LPCWSTR path1, LPCWSTR path2);
+
+static void test_PathIsEqualOrSubFolder()
+{
+fnPathIsEqualOrSubFolder pPathIsEqualOrSubFolder;
+BOOL ret;
+static const WCHAR path1[] = {'c',':','\\','t','e','s','t',0};
+static const WCHAR path2[] =
{'c',':','\\','t','e','s','t','\\','t','e','s','t',0};
+static const WCHAR path3[] = {'c',':','\\','t','e','s','t','1','2','3',0};
+static const WCHAR path4[] = {'c',':','\\','t','e','s','t','\\',0};
+static const WCHAR path5[] =
{'c',':','\\','t','e','s','t','\\','t','e','s','t','2',
+'\\','.','.','\\','t','e','s','t',0};
+
+pPathIsEqualOrSubFolder = GetProcAddress(hShell32, (LPSTR)755);
+if(!pPathIsEqualOrSubFolder)
+return;
+
+#define TEST_PATH(p1, p2, r) \
+ret = pPathIsEqualOrSubFolder(p1, p2); \
+ok(ret == r, PathIsEqualOrSubFolder( #p1 #p2 ) failed, expected:
%x\n, r);
+
+TEST_PATH(path1, path1, TRUE);
+TEST_PATH(path1, path2, TRUE);
+TEST_PATH(path1, path3, FALSE);
+TEST_PATH(path1, path4, TRUE);
+TEST_PATH(path2, path1, FALSE);
+TEST_PATH(path2, path2, TRUE);
+TEST_PATH(path2, path3, FALSE);
+TEST_PATH(path2, path4, FALSE);
+TEST_PATH(path3, path1, FALSE);
+TEST_PATH(path3, path2, FALSE);
+TEST_PATH(path3, path3, TRUE);
+TEST_PATH(path3, path4, FALSE);
+TEST_PATH(path4, path1, TRUE);
+TEST_PATH(path4, path2, TRUE);
+TEST_PATH(path4, path3, FALSE);
+TEST_PATH(path4, path4, TRUE);
+TEST_PATH(path5, path1, FALSE);
+TEST_PATH(path5, path2, FALSE);
+TEST_PATH(path5, path3, FALSE);
+TEST_PATH(path5, path4, FALSE);
+TEST_PATH(path5, path5, TRUE);
+TEST_PATH(NULL, path1, FALSE);
+TEST_PATH(path1, NULL, FALSE);
+TEST_PATH(NULL, NULL, FALSE);
+
+#undef TEST_PATH
+}
+
START_TEST(shellpath)
{
if (!init()) return;
@@ -892,5 +941,6 @@ START_TEST(shellpath)
testWinDir();
testSystemDir();
testNonExistentPath();
+test_PathIsEqualOrSubFolder();
}
}
Re: Implements OleLoadPicturePath
Thanks for your reply, I will fix the places you mentioned to clean
things up correctly. But other places in olepicture should also be fixed
in this case. I will check that.
Max
On Mon, 2005-02-28 at 15:22 -0600, Robert Shearman wrote:
Maxime Belleng wrote:
Hello, here is an implementation of OleLoadPicturePath.
The filename can be either a local file or an url.
In case of a url, I needed a user-agent for wininet. I put a dummy value
as I didn't find a default wine value. Is there a default value
somewhere for the whole project ?
a+
Max
ChangeLog:
* Implements OleLoadPicturePath
Index: wine/dlls/oleaut32/olepicture.c
===
RCS file: /home/wine/wine/dlls/oleaut32/olepicture.c,v
retrieving revision 1.55
diff -u -r1.55 olepicture.c
--- wine/dlls/oleaut32/olepicture.c 25 Feb 2005 14:07:57 - 1.55
+++ wine/dlls/oleaut32/olepicture.c 27 Feb 2005 10:51:43 -
@@ -71,7 +71,9 @@
#include olectl.h
#include oleauto.h
#include connpt.h
+#include wininet.h
#include wine/debug.h
+#include wine/unicode.h
#include wine/wingdi16.h
#include cursoricon.h
@@ -1998,11 +2000,122 @@
DWORD dwReserved, OLE_COLOR clrReserved, REFIID riid,
LPVOID *ppvRet )
{
- FIXME((%s,%p,%ld,%08lx,%s,%p): stub\n,
+ static const WCHAR file[] = { 'f','i','l','e',':','/','/',0 };
+ static const WCHAR name[] = { 'w','i','n','e','-','a','g','e','n','t',0};
+ IPicture *ipicture;
+ HANDLE hFile;
+ DWORD dwFileSize;
+ HGLOBAL hGlobal = NULL;
+ DWORD dwBytesRead = 0;
+ IStream *stream;
+ BOOL bRead;
+ IPersistStream *pStream;
+ HRESULT hRes;
+
+ TRACE((%s,%p,%ld,%08lx,%s,%p): stub\n,
debugstr_w(szURLorPath), punkCaller, dwReserved, clrReserved,
debugstr_guid(riid), ppvRet);
- return E_NOTIMPL;
+ if (!ppvRet) return E_POINTER;
+
+ if (strncmpW(szURLorPath, file, 7) == 0) {
+ szURLorPath += 7;
+
+ hFile = CreateFileW(szURLorPath, GENERIC_READ, 0, NULL, OPEN_EXISTING,
+ 0, NULL);
+ if (hFile == INVALID_HANDLE_VALUE)
+ return E_UNEXPECTED;
+
+ dwFileSize = GetFileSize(hFile, NULL);
+ if (dwFileSize != INVALID_FILE_SIZE )
+ {
+ hGlobal = GlobalAlloc(GMEM_FIXED,dwFileSize);
+ if ( hGlobal)
+ {
+ bRead = ReadFile(hFile, hGlobal, dwFileSize, dwBytesRead, NULL);
+ if (!bRead)
+ {
+ GlobalFree(hGlobal);
+ hGlobal = 0;
+ }
+ }
+ }
+ CloseHandle(hFile);
+ } else {
+ HINTERNET hInternet;
+ BOOL res = FALSE;
+
+ hInternet = InternetOpenW(name, INTERNET_OPEN_TYPE_PRECONFIG, NULL,
+NULL, 0);
+ if (hInternet)
+ {
+ HINTERNET hFile;
+ hFile = InternetOpenUrlW(hInternet, szURLorPath, NULL, -1L,
+ INTERNET_FLAG_RESYNCHRONIZE, (DWORD_PTR)NULL);
+ if (hFile)
+ {
+ DWORD total = 4096;
+ DWORD nbRead;
+
+ hGlobal = GlobalAlloc(GMEM_FIXED, 4096);
+ if (hGlobal)
+ {
+ do {
+ res = InternetReadFile(hFile, hGlobal, 4096, nbRead);
+ if (res (nbRead0))
+ {
+ HGLOBAL hNewGlobal;
+ hNewGlobal = GlobalReAlloc(hGlobal, total+4096, 0);
+ if (!hNewGlobal)
+ {
+ res = FALSE;
+ break;
+ }
+ }
+ } while (res (nbRead0));
+ }
+ }
+
+ InternetCloseHandle(hInternet);
+ }
+ if (!res)
+ {
+ GlobalFree(hGlobal);
+ }
+ }
+
+ if (!hGlobal)
+ return E_UNEXPECTED;
+
+ hRes = CreateStreamOnHGlobal(hGlobal, TRUE, stream);
+ if (FAILED(hRes))
+ {
+ if (stream != NULL) IStream_Release(stream);
A valid stream will not be returned on failure, so no need for the extra
check here.
+ GlobalFree(hGlobal);
+ return hRes;
+ }
+
+ hRes = CoCreateInstance(CLSID_StdPicture, punkCaller,
CLSCTX_INPROC_SERVER,
+ IID_IPicture, (LPVOID*)ipicture);
+ if (hRes != S_OK) {
Lack of cleanup code here.
+ return hRes;
+ }
+
+ hRes = IPicture_QueryInterface(ipicture, IID_IPersistStream,
(LPVOID*)pStream);
+ if (hRes) {
+ IPicture_Release(ipicture);
And here.
+ return hRes;
+ }
+
+ IPersistStream_Load(pStream, stream);
You should probably check the return value from this function as it is
kinda vital to the function you are implementing.
+ IPersistStream_Release(pStream);
+
Re: Crash in Polar Precision Performance Software
Ron Jensen wrote: Hello, This trace is from Polar's Precision Performance Software http://www.codeweavers.com/site/compatibility/browse/name?app_id=681 running on CVS wine. This crash happens with CVS wine, and wine I compiled from http://ftp.codeweavers.com/pub/crossover/office/source/office-src-4.1.0.tgz It does not happen with the precompiled binaries in CXOffice's Loki installer. Can someone give me a clue as to were to start looking to fix this? What version of the precompiled binaries are you using? Rob
Re: Tools for identifying what a DLL provides?
Andreas Mohr wrote: On Mon, Feb 28, 2005 at 09:48:40AM -0600, David D. Hagood wrote: I have a DLL from a manufacturer that I don't have the source for, nor do I have the header or the import library for. Since Wine developers frequently have to reverse engineer what a given DLL provides, does anybody have a good recommendation for a tool that can scan the DLL and report what functions it exports, and their arg types and return types? You really want http://www.dependencywalker.com/ , trust me. But probably http://www.pe-explorer.com/ is very useful, too... This would be probably good additions to the Wine resource page ... bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Crash in Polar Precision Performance Software
On Mon, 2005-02-28 at 16:11 -0600, Robert Shearman wrote: Ron Jensen wrote: Hello, This trace is from Polar's Precision Performance Software http://www.codeweavers.com/site/compatibility/browse/name?app_id=681 running on CVS wine. This crash happens with CVS wine, and wine I compiled from http://ftp.codeweavers.com/pub/crossover/office/source/office-src-4.1.0.tgz It does not happen with the precompiled binaries in CXOffice's Loki installer. Can someone give me a clue as to were to start looking to fix this? What version of the precompiled binaries are you using? Rob 20040716 according to the About WINE dialog box... This is the same version in the sources mentioned above, unless there were patches or CVS updates applied... Perhaps I should pull down a copy of 200406xx and see if that works? Which version of GCC does (did) Code Weavers use to make the 4.1.0 release? Thanks, Ron
Re: vartest.c - major pain in the build process
Jakob Eriksson [EMAIL PROTECTED] wrote: I have to repeat again: Winword, Photoshop, Internet Explorer or any other application I and most (if not all) developers and users are care about do not run on an invisible desktop, therefore I don't care about tests running in that mode at all. It's not simply an optional mode, that's a mode completely useless for vast majority of Wine users/developers. For example file APIs many applications depend upon, and these are totally unaffected by desktop visibility. We can't really separate the tests, but still want the tests to show reasonable results in order to compare behaviour with Wine and to track the regressions. I don't see the point of publishing broken tests, and why running tests interactively can't be made a mandatory requirement. -- Dmitry.
AppDB SQL Errors
Here: http://www.swissarmygeek.com/winesqlerr.gif
Re: Wine cabinet.dll FDI Conformace Test Patch
Andreas wrote: It's an unspoken rule that preprocessor directives (#ifdef, ...) always start at the very beginning of a line to make sure one recognizes immediately which parts of the code are being processed and which ones aren't. Good point. I should have caught that style violation when I reviewed their code for them this weekend. AFAICS you're not using wine test suite infrastructure, e.g. ok() etc. Using printf() directly strikes me as being quite bad, too... I think they're using the wine test infrastructure properly everywhere. The only exception is the disabled self-test in tvfs.c, but I think that's fine. It's not even built, it was just used while developing the test harness. Apart from that it appears to be very good. Cool! - Dan
Re: USER32: Sysparams unit tests fixes and additions
On Tue, 2005-03-01 at 05:53, [EMAIL PROTECTED] wrote:
Changelog:
* Created SPI_{GET,SET}KEYBOARDPREF and SPI_{GET,SET}SCREENREADER unit tests
* Removed a trace that shouldn't have been there
* Add return checking to SPI_{GET,SET}WHEELSCROLLLINES and
SPI_{GET,SET}MENUSHOWDELAY unit tests so they no longer run on Windows 95
where they aren't supported
* Changed minimum hovertime in SPI_{GET,SET}MOUSEHOVERTIME to 10 as Windows
XP
defaults to 10 any value below that
Hi,
the extra trace was my doing :-(. I've added this and after that I
realized that SPI_{GET|SET} doesn't clean the LastError after a correct
call. That's why I think it's necessary to do a SetLastError(0) before
every check of GetLastError.
That's the reason I had these failures on win98 and
SPI_GETICONTITLEWRAP. The Error was still set by one of the previous
called functions (I think a ..W call, the ..A call was fine).
That still leaves us with the questions, whether it would be good to
check for ERROR_CALL_NOT_IMPLEMENTED after each call?
Cheers,
Paul Vriens.
