wine-devel

wine-devel@winehq.org

11 participants
84462 discussions

Re: user32: stub implementations for WINNLS* functions
by Diego 'Flameeyes' Pettenò 26 Dec '04

26 Dec '04

On Sunday 26 December 2004 01:57, Mike Hearn wrote: > They were commented out, which implies some software does a GetProcAddress > on them. Adding these sorts of stubs can break apps: have you found a > program or DLL that actually needs them? Yu Gi Oh Power of Chaos refuses to execute without them. It also seems not to call them, at least not before crash for other reasons. I thought that the spec-stubs was the ones which breaks things, for this I tried to have implementation-stubs. Regards, -- Diego "Flameeyes" Pettenò flameeyes(a)users.berlios.de - http://flameeyes.web.ctonet.it/

1 0

Determining the color depth of X?
by d13f00l 25 Dec '04

25 Dec '04

Hey. I've been trying to iron out a couple bugs running some programs in wine. Running ZSNES reports that ZSNES cannot run in 24 bit depth mode. I'm also running an old game that uses dibs, I took a profiler to wine. We repeatedly call convert_888_to_0888_asis on a surface per blit. The game determines the color depth by what depth you're running windows at. Basicaly, where/how does wine determine your bit depth? Isn't 24 actually 3 significacant bytes + a worthless one in X? XRGB. I didn't see any code determining the bit depth trying to follow what happens when you CreateCompatibleDC(0). Anyone have any ideas? This could be potential for a nice speedup. Thanks. -Dylan

1 0

is WIDL a sutable replacement for microsoft MIDL?
by Jonathan Wilson 24 Dec '04

24 Dec '04

Could WIDL be used alongside MingW to generate IDL files on windows? What changes, if any, would be needed to WIDL to get it working on win32 and compiling IDL files in a way that MingW can use? Does MingW have enough of the OLE header files for WIDL to work? Having an IDL compiler for MingW would be a very usefull thing for those doing COM development IMO.

2 1

Wine Bug Busters @ 7pm GMT
by Brian Vincent 24 Dec '04

24 Dec '04

The first ever Wine Bug Busters hacking session is coming up in an hour - 7pm GMT or 2pm EST for you North American folks. A few people are already sitting in irc. If you want to join, fire up your favorite IRC and log into irc.freenode.net, channel #winehackers. -Brian

5 5

Re: [QUARTZ] Some fixes
by Robert Shearman 24 Dec '04

24 Dec '04

Christian Costa wrote: > Hi, > > With this patch, the indeo codec feels a little better. > > Changelog: > Initialize the COM libraries for the newly created worker thread in > the AVI splitter. > Fixed some returned error codes. > Show refcount in the AddRef/Release traces in filter. > Added 24 bits source in the video renderer. > > Christian Costa titan.costa(a)wanadoo.fr > >------------------------------------------------------------------------ > >Index: avidec.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/avidec.c,v >retrieving revision 1.11 >diff -u -r1.11 avidec.c >--- avidec.c 20 Dec 2004 17:07:17 -0000 1.11 >+++ avidec.c 24 Dec 2004 13:31:39 -0000 > > Why make things difficult for Alexandre? It is Christmas after all. Provide a diff relative to the root of the wine tree. ... >Index: pin.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/pin.c,v >retrieving revision 1.9 >diff -u -r1.9 pin.c >--- pin.c 16 Dec 2004 14:25:15 -0000 1.9 >+++ pin.c 24 Dec 2004 13:31:52 -0000 >@@ -1134,6 +1134,8 @@ > REFERENCE_TIME rtCurrent; > ALLOCATOR_PROPERTIES allocProps; > >+ CoInitialize(NULL); >+ > SetEvent(This->hEventStateChanged); > > hr = IMemAllocator_GetProperties(This->pAlloc, &allocProps); > > Good catch, but it would probably be better to use CoInitializeEx(NULL, COINIT_MULTITHREADED). This seems to be what Microsoft uses for the pull thread. Rob

3 5

Re: [MSVCRT] Fix get/set pos (fixes Supreme Snowboarding demo).
by Dmitry Timoshkov 24 Dec '04

24 Dec '04

"Lionel Ulmer" <lionel.ulmer(a)free.fr> wrote: > Basically, there was two issues: the first is that the 'fpos_t' is 64 bits > in Windows (Mike M. checked on VC++ and I checked on MinGW and both > confirmed this). The situation with fpos_t is even worse. Both VC++ (Win32) and Platform SDK (Win64 part) define it as follows (stdio.h): #ifndef _FPOS_T_DEFINED #undef _FPOSOFF #if defined (_POSIX_) typedef long fpos_t; #define _FPOSOFF(fp) ((long)(fp)) #else /* _POSIX_ */ #if !__STDC__ && _INTEGRAL_MAX_BITS >= 64 typedef __int64 fpos_t; #define _FPOSOFF(fp) ((long)(fp)) #else typedef struct fpos_t { unsigned int lopart; int hipart; } fpos_t; #define _FPOSOFF(fp) ((long)(fp).lopart) #endif #endif /* _POSIX_ */ #define _FPOS_T_DEFINED #endif -- Dmitry.

2 1

Re: [MSVCRT] Fix get/set pos (fixes Supreme Snowboarding demo).
by Mike Hearn 24 Dec '04

24 Dec '04

On Fri, 24 Dec 2004 15:42:30 +0100, Lionel Ulmer wrote: > With the help of Mike (M.) on IRC to point me to the right direction, I > finally managed to nail down the problem that was plaguing TD's snowboarding > game demo (oh well, it's better doing it in real life but well, if you are > blocked in England it's better than nothing :-) ). YAY! Great work guys, wonderful Christmas present :) Now I suppose I should fix the launcher creation problem. Then the only one left is the black sky bug but like you said, it's likely to be a driver issue. thanks -mike

1 0

Re: wine/dlls shell32/shlfileop.c shell32/shlexec. ...
by Christian Costa 24 Dec '04

24 Dec '04

Hi Michael, This is typically the kind of patches that breaks everything. The code you find useless, is often use in lazy allocation or error handling. I doubt the current wine code is so bad designed even if there is some cases where the test is useless. For example in memallocator.c, this is wrong because you can release the allocator even before allocating the memory with the SetProperties method. Looking at your other patches, there is some changes that seems suspect to me (in winmm and directx). I think, this kind of cleanup should be done very carefully by understanding what the code really does. Morever, sending large patches that involves several dll makes it appears as obvious cleanups which they are not. Bye, Christian PS: Alexandre, please, could you remove all theses patches ? Alexandre Julliard wrote: >ChangeSet ID: 15010 >CVSROOT: /opt/cvs-commit >Module name: wine >Changes by: julliard(a)wine.codeweavers.com 2004/12/23 11:12:07 > >Modified files: > dlls/shell32 : shlfileop.c shlexec.c shelllink.c > shell32_main.c pidl.c brsfolder.c > autocomplete.c > dlls/setupapi : setupx_main.c parser.c > dlls/serialui : confdlg.c > dlls/rsaenh : rsaenh.c handle.c > dlls/rpcrt4 : rpc_server.c rpc_message.c rpc_binding.c > dlls/richedit : reader.c > dlls/quartz : memallocator.c > >Log message: > Michael Stefaniuc <mstefani(a)redhat.de> > Do not check for non NULL pointer before HeapFree'ing it. It's > redundant. > >Patch: http://cvs.winehq.org/patch.py?id=15010 > >Old revision New revision Changes Path > 1.49 1.50 +1 -2 wine/dlls/shell32/shlfileop.c > 1.58 1.59 +1 -1 wine/dlls/shell32/shlexec.c > 1.79 1.80 +17 -40 wine/dlls/shell32/shelllink.c > 1.141 1.142 +2 -2 wine/dlls/shell32/shell32_main.c > 1.123 1.124 +1 -1 wine/dlls/shell32/pidl.c > 1.53 1.54 +1 -4 wine/dlls/shell32/brsfolder.c > 1.11 1.12 +2 -4 wine/dlls/shell32/autocomplete.c > 1.29 1.30 +3 -3 wine/dlls/setupapi/setupx_main.c > 1.14 1.15 +1 -2 wine/dlls/setupapi/parser.c > 1.19 1.20 +1 -2 wine/dlls/serialui/confdlg.c > 1.7 1.8 +4 -4 wine/dlls/rsaenh/rsaenh.c > 1.2 1.3 +1 -2 wine/dlls/rsaenh/handle.c > 1.33 1.34 +1 -1 wine/dlls/rpcrt4/rpc_server.c > 1.11 1.12 +2 -5 wine/dlls/rpcrt4/rpc_message.c > 1.29 1.30 +1 -1 wine/dlls/rpcrt4/rpc_binding.c > 1.18 1.19 +1 -2 wine/dlls/richedit/reader.c > 1.5 1.6 +1 -2 wine/dlls/quartz/memallocator.c > > > > > >

2 2

gmail invitation
by Ivan Leo Puoti 24 Dec '04

24 Dec '04

I have 6 gmail invitations, I'm giving them out to Wine developers only. If you want one drop me a line, first come first served. Ivan.

4 3

Re: Systray patch but explorified
by Mike Hearn 24 Dec '04

24 Dec '04

On Mon, 13 Dec 2004 21:58:07 +0000, Mike Hearn wrote: > - Use freedesktop.org system tray protocol, remove legacy KDE support > - Introduce new Explorer process > - Rewrite system tray handling to be out of process Hi Alexandre, What needs doing next for this patch? thanks -mike

2 5

Interface for working directories/launchers
by Mike Hearn 24 Dec '04

24 Dec '04

Hi, Wine currently creates launchers (.desktop files) with an Exec line like this: Exec=wine 'c:\games\supreme\supreme.exe' But, some games expects to be run from its working directory. As working directory typically doesn't matter to UNIX apps, some desktop environments like GNOME don't let you set it. Really, this is a Wine specific issue. So I'm wondering how we should fix this. The most obvious is a way to tell Wine to change the working directory to the path of the EXE file before running it, but we can't introduce command line switches any more and an environment variable for this doesn't make much sense. My proposal is to have a new winelib app "winemenulauncher" which simply takes the working directory, program and arguments, and runs the program but switching current directory first, ie the menu entry would look like: Exec=wine winemenulauncher c:\games\supreme supreme.exe Hopefully this should let us fix the case of games like Dungeon Keeper which actually crash when run from their install directory. Does this sound sensible? thanks -mike

3 3

Re: [AppDB] CODING_STANDARD
by Paul van Schayck 24 Dec '04

24 Dec '04

Jonathan, On Fri, 24 Dec 2004 10:43:45 +0100, Jonathan Ernst <Jonathan(a)ernstfamily.ch> wrote: > This patch sets variable naming convention that should be used in the > appDB code. Why would we change it. I think it just clutters up the source without adding value. PHP is a variable-type decleration less language. We often just change string in booleans without thinking about it. And I think I'm just lazy. I don't like typing more characters. What are your argument for it? Paul

2 1

AppDB Templates
by Stefan Pflüger 24 Dec '04

24 Dec '04

Hello, I attached my really simple template class that mainly replaces special tags in template files by some reasonable text. The file should go to appdb/include/template.php. I already rewrote most of index.php to use the template class, I'll submit a seperate patch for that when finished. The same then needs to be done for every PHP file in appdb/ and appdb/admin as well as some files in include/, for example include/menu.php. In the end, the whole design will be changeable by editing some HTML-like template files in appdb/template/. Stefan

1 0

Re: tests: add more listbox tests
by Mike Hearn 24 Dec '04

24 Dec '04

On Thu, 23 Dec 2004 17:01:09 +0200, Lauri Tulmin wrote: > Add tests for LBS_EXTENDEDSE and LBS_EXTENDEDSEL | LBS_MULTIPLESEL > listboxes. Some of these test don't pass on wine. Thanks for the tests! If they don't pass in Wine though you need to surround them in todo_wine {} blocks, or ideally fix them. thanks -mike

2 1

Patch to README
by Stefan Pflüger 23 Dec '04

23 Dec '04

This patch adds the default admin account data (user: admin, password: testing) to the README file. The account data was mentioned nowhere before, only in tables/user_list.sql Stefan Pflüger Index: README =================================================================== RCS file: /home/wine/appdb/README,v retrieving revision 1.4 diff -u -r1.4 README --- README 13 Dec 2004 03:50:11 -0000 1.4 +++ README 23 Dec 2004 20:23:33 -0000 @@ -32,6 +32,12 @@ 'magic_quotes_gpc = Off' (you would end up with \ everywhere) 'session.bug_compat_42' = On' (Problem with auto-globals and session variables) +# An AppDB admin user has been automatically created while running + the create_tables script + username: admin + password: testing + You should change the password as soon as possible! + #------------------------------------------------------------------------# You can create ether set up a real bugzilla database or a fake one

1 0

Re: Correct use of the ok function in user/tests and kernel/tests
by Jakob Eriksson 23 Dec '04

23 Dec '04

Aren't arguments always evaluated left to right? Rein Klazes wrote: >Hi, > >82 cases, most a variation of: > >ok( !Foo(), "Foo failed, error %ld\n", GetLastError()); > >Changelog: > dlls/kernel/tests : change.c, file.c, process.c, > thread.c, time.c > dlls/user/tests : clipboard.c, msg.c, text.c win.c > > Correct cases where arguments of ok() calls depend on the order > in which they are evaluated. > > >

3 2

Re: Implemented CreateUrlCacheEntryW and DeleteUrlCacheEntryW
by Robert Shearman 23 Dec '04

23 Dec '04

Jacek Caban wrote: > Changelog: > Implemented CreateUrlCacheEntryW and DeleteUrlCacheEntryW > >------------------------------------------------------------------------ > >Index: dlls/wininet/urlcache.c >=================================================================== >RCS file: /home/wine/wine/dlls/wininet/urlcache.c,v >retrieving revision 1.22 >diff -u -p -r1.22 urlcache.c >--- dlls/wininet/urlcache.c 3 Sep 2004 18:30:28 -0000 1.22 >+++ dlls/wininet/urlcache.c 23 Dec 2004 11:08:39 -0000 >@@ -616,14 +616,14 @@ static BOOL URLCache_DeleteEntry(CACHEFI > static BOOL URLCache_LocalFileNameToPathW( > const URLCACHECONTAINER * pContainer, > LPCURLCACHE_HEADER pHeader, >- LPCSTR szLocalFileName, >+ LPCWSTR szLocalFileName, > BYTE Directory, > LPWSTR wszPath, > LPLONG lpBufferSize) > { > LONG nRequired; > int path_len = strlenW(pContainer->path); >- int file_name_len = MultiByteToWideChar(CP_ACP, 0, szLocalFileName, -1, NULL, 0); >+ int file_name_len = lstrlenW(szLocalFileName); > > MultiByteWideChar returns the number of characters, including the NULL terminator. lstrlenW does not. Also, since the local file name can only ever be stored in ANSI, there is very little benefit in converting that function to Unicode. In fact, there is very little benefit in making the ANSI API functions convert everything to Unicode strings, only for them to be immediately converted back to ANSI for storage on disk. > if (Directory >= pHeader->DirectoryCount) > { > *lpBufferSize = 0; >@@ -638,7 +638,7 @@ static BOOL URLCache_LocalFileNameToPath > memcpy(wszPath, pContainer->path, path_len * sizeof(WCHAR)); > dir_len = MultiByteToWideChar(CP_ACP, 0, pHeader->directory_data[Directory].filename, DIR_LENGTH, wszPath + path_len, DIR_LENGTH); > wszPath[dir_len + path_len] = '\\'; >- MultiByteToWideChar(CP_ACP, 0, szLocalFileName, -1, wszPath + dir_len + path_len + 1, file_name_len); >+ memcpy(wszPath + dir_len + path_len + 1, szLocalFileName, file_name_len*sizeof(WCHAR)); > *lpBufferSize = nRequired; > return TRUE; > } >@@ -762,9 +762,18 @@ static BOOL URLCache_CopyEntry( > LPSTR lpszLocalFileName; > lpszLocalFileName = (LPSTR)lpCacheEntryInfo + dwRequiredSize; > nLocalFilePathSize = *lpdwBufferSize - dwRequiredSize; >- if ((bUnicode && URLCache_LocalFileNameToPathW(pContainer, pHeader, (LPCSTR)pUrlEntry + pUrlEntry->dwOffsetLocalName, pUrlEntry->CacheDir, (LPWSTR)lpszLocalFileName, &nLocalFilePathSize)) || >- URLCache_LocalFileNameToPathA(pContainer, pHeader, (LPCSTR)pUrlEntry + pUrlEntry->dwOffsetLocalName, pUrlEntry->CacheDir, lpszLocalFileName, &nLocalFilePathSize)) >- { >+ if (bUnicode) { >+ LPWSTR tmpstrw; >+ int len = MultiByteToWideChar(CP_ACP, 0, (LPCSTR)pUrlEntry + pUrlEntry->dwOffsetLocalName, -1, NULL, 0); >+ tmpstrw = HeapAlloc(GetProcessHeap(), 0, len*sizeof(WCHAR)); >+ MultiByteToWideChar(CP_ACP, 0, (LPCSTR)pUrlEntry + pUrlEntry->dwOffsetLocalName, -1, tmpstrw, len); >+ if(URLCache_LocalFileNameToPathW(pContainer, pHeader, tmpstrw, pUrlEntry->CacheDir, >+ (LPWSTR)lpszLocalFileName, &nLocalFilePathSize)) { >+ lpCacheEntryInfo->lpszLocalFileName = lpszLocalFileName; >+ } >+ HeapFree(GetProcessHeap(), 0, tmpstrw); >+ }else if(URLCache_LocalFileNameToPathA(pContainer, pHeader, (LPCSTR)pUrlEntry + pUrlEntry->dwOffsetLocalName, >+ pUrlEntry->CacheDir, lpszLocalFileName, &nLocalFilePathSize)) { > lpCacheEntryInfo->lpszLocalFileName = lpszLocalFileName; > } > dwRequiredSize += nLocalFilePathSize; >@@ -1550,36 +1559,38 @@ BOOL WINAPI UnlockUrlCacheEntryFileA( > } > > /*********************************************************************** >- * CreateUrlCacheEntryA (WININET.@) >+ * CreateUrlCacheEntryW (WININET.@) > * > */ >-BOOL WINAPI CreateUrlCacheEntryA( >- IN LPCSTR lpszUrlName, >+BOOL WINAPI CreateUrlCacheEntryW( >+ IN LPCWSTR lpszUrlName, > IN DWORD dwExpectedFileSize, >- IN LPCSTR lpszFileExtension, >- OUT LPSTR lpszFileName, >+ IN LPCWSTR lpszFileExtension, >+ OUT LPWSTR lpszFileName, > IN DWORD dwReserved > ) > { > URLCACHECONTAINER * pContainer; > LPURLCACHE_HEADER pHeader; >- CHAR szFile[MAX_PATH]; >- CHAR szExtension[MAX_PATH]; >- LPCSTR lpszUrlPart; >- LPCSTR lpszUrlEnd; >- LPCSTR lpszFileNameExtension; >- LPSTR lpszFileNameNoPath; >+ WCHAR szFile[MAX_PATH]; >+ WCHAR szExtension[MAX_PATH]; >+ LPCWSTR lpszUrlPart; >+ LPCWSTR lpszUrlEnd; >+ LPCWSTR lpszFileNameExtension; >+ LPWSTR lpszFileNameNoPath; > int i; > int countnoextension; > BYTE CacheDir; > LONG lBufferSize; > BOOL bFound = FALSE; > int count; >+ static const WCHAR strWWW[] = {'w','w','w',0}; >+ static const WCHAR strFormat[] = {'[','%','u',']','%','s',0}; > > No need to pollute an already congested function header with something that can be put into the appropriate block below. Also, "wsz" is the prefix usually used for Wide Character string constants. > > TRACE("(%s, 0x%08lx, %s, %p, 0x%08lx)\n", >- debugstr_a(lpszUrlName), >+ debugstr_w(lpszUrlName), > dwExpectedFileSize, >- debugstr_a(lpszFileExtension), >+ debugstr_w(lpszFileExtension), > lpszFileName, > dwReserved); > >@@ -1607,16 +1618,14 @@ BOOL WINAPI CreateUrlCacheEntryA( > break; > } > } >- if (!strcmp(lpszUrlPart, "www")) >- { >- lpszUrlPart += strlen("www"); >- } >+ if (!lstrcmpW(lpszUrlPart, strWWW)) >+ lpszUrlPart += sizeof(strWWW)/sizeof(WCHAR) -1; > > count = lpszUrlEnd - lpszUrlPart; > > if (bFound && (count < MAX_PATH)) > { >- memcpy(szFile, lpszUrlPart, count * sizeof(CHAR)); >+ memcpy(szFile, lpszUrlPart, count * sizeof(WCHAR)); > szFile[count] = '\0'; > /* FIXME: get rid of illegal characters like \, / and : */ > } >@@ -1625,9 +1634,9 @@ BOOL WINAPI CreateUrlCacheEntryA( > FIXME("need to generate a random filename\n"); > } > >- TRACE("File name: %s\n", szFile); >+ TRACE("File name: %s\n", debugstr_w(szFile)); > >- if (!URLCacheContainers_FindContainerA(lpszUrlName, &pContainer)) >+ if (!URLCacheContainers_FindContainerW(lpszUrlName, &pContainer)) > return FALSE; > > if (!URLCacheContainer_OpenIndex(pContainer)) >@@ -1638,32 +1647,33 @@ BOOL WINAPI CreateUrlCacheEntryA( > > CacheDir = (BYTE)(rand() % pHeader->DirectoryCount); > >- lBufferSize = MAX_PATH * sizeof(CHAR); >- URLCache_LocalFileNameToPathA(pContainer, pHeader, szFile, CacheDir, lpszFileName, &lBufferSize); >+ lBufferSize = MAX_PATH * sizeof(WCHAR); >+ URLCache_LocalFileNameToPathW(pContainer, pHeader, szFile, CacheDir, lpszFileName, &lBufferSize); > > URLCacheContainer_UnlockIndex(pContainer, pHeader); > >- lpszFileNameNoPath = lpszFileName + lBufferSize / sizeof(CHAR) + DIR_LENGTH + 1; >+ lpszFileNameNoPath = lpszFileName + lBufferSize / sizeof(WCHAR) + DIR_LENGTH + 1; > >- countnoextension = strlen(lpszFileNameNoPath); >- lpszFileNameExtension = PathFindExtensionA(lpszFileNameNoPath); >+ countnoextension = lstrlenW(lpszFileNameNoPath); >+ lpszFileNameExtension = PathFindExtensionW(lpszFileNameNoPath); > if (lpszFileNameExtension) >- countnoextension -= strlen(lpszFileNameExtension); >+ countnoextension -= lstrlenW(lpszFileNameExtension); > *szExtension = '\0'; > > if (lpszFileExtension) > { > szExtension[0] = '.'; >- strcpy(szExtension+1, lpszFileExtension); >+ lstrcpyW(szExtension+1, lpszFileExtension); > } > > for (i = 0; i < 255; i++) > { > HANDLE hFile; >- strncpy(lpszFileNameNoPath, szFile, countnoextension); >- sprintf(lpszFileNameNoPath + countnoextension, "[%u]%s", i, szExtension); >- TRACE("Trying: %s\n", lpszFileName); >- hFile = CreateFileA(lpszFileName, GENERIC_READ, 0, NULL, CREATE_NEW, 0, NULL); >+ int len = lstrlenW(szFile)+1; >+ memcpy(lpszFileNameNoPath, szFile, (len<countnoextension ? len : countnoextension)*sizeof(WCHAR)); > > The strncpyW function exists for a reason. Also, it is better to use strlenW than lstrlenW. >+ wsprintfW(lpszFileNameNoPath + countnoextension, strFormat, i, szExtension); >+ TRACE("Trying: %s\n", debugstr_w(lpszFileName)); >+ hFile = CreateFileW(lpszFileName, GENERIC_READ, 0, NULL, CREATE_NEW, 0, NULL); > if (hFile != INVALID_HANDLE_VALUE) > { > CloseHandle(hFile); >@@ -1674,6 +1684,45 @@ BOOL WINAPI CreateUrlCacheEntryA( > return FALSE; > } > >+ >+/*********************************************************************** >+ * CreateUrlCacheEntryA (WININET.@) >+ * >+ */ >+BOOL WINAPI CreateUrlCacheEntryA( >+ IN LPCSTR lpszUrlName, >+ IN DWORD dwExpectedFileSize, >+ IN LPCSTR lpszFileExtension, >+ OUT LPSTR lpszFileName, >+ IN DWORD dwReserved >+) >+{ >+ int len; >+ BOOL ret; >+ LPWSTR lpszUrlNamew = NULL; >+ LPWSTR lpszFileExtensionw = NULL; >+ WCHAR lpszFileNamew[MAX_PATH+1]; >+ >+ if(lpszUrlName) { >+ len = MultiByteToWideChar(CP_ACP, 0, lpszUrlName, -1, NULL, 0); >+ lpszUrlNamew = HeapAlloc(GetProcessHeap(), 0, len*sizeof(WCHAR)); >+ MultiByteToWideChar(CP_ACP, 0, lpszUrlName, -1, lpszUrlNamew, len); >+ } >+ >+ if(lpszFileExtension) { >+ len = MultiByteToWideChar(CP_ACP, 0, lpszFileExtension, -1, NULL, 0); >+ lpszFileExtensionw = HeapAlloc(GetProcessHeap(), 0, len*sizeof(WCHAR)); >+ MultiByteToWideChar(CP_ACP, 0, lpszFileExtension, -1, lpszFileExtensionw, len); >+ } >+ >+ ret = CreateUrlCacheEntryW(lpszUrlNamew, dwExpectedFileSize, lpszFileExtensionw, lpszFileNamew, 0); >+ >+ WideCharToMultiByte(CP_ACP, 0, lpszFileNamew, -1, lpszFileName, -1, 0, 0); >+ HeapFree(GetProcessHeap(), 0, lpszUrlNamew); >+ HeapFree(GetProcessHeap(), 0, lpszFileExtensionw); >+ return ret; >+} >+ > /*********************************************************************** > * CommitUrlCacheEntryA (WININET.@) > * >@@ -1999,12 +2048,11 @@ BOOL WINAPI UnlockUrlCacheEntryStream( > return TRUE; > } > >- > /*********************************************************************** >- * DeleteUrlCacheEntryA (WININET.@) >+ * DeleteUrlCacheEntryAW (internal) > > Bad name for the function. This convention is used in shell32 to indicate a function that is implemented as ANSI only on Win9x and Unicode on WinNT. > * > */ >-BOOL WINAPI DeleteUrlCacheEntryA(LPCSTR lpszUrlName) >+BOOL WINAPI DeleteUrlCacheEntryAW(LPCWSTR lpszUrlName, BOOL bUnicode) > { > URLCACHECONTAINER * pContainer; > LPURLCACHE_HEADER pHeader; >@@ -2012,11 +2060,15 @@ BOOL WINAPI DeleteUrlCacheEntryA(LPCSTR > DWORD dwStartBlock; > DWORD dwBlock; > BYTE * AllocationTable; >+ LPSTR lpszUrlNamea = NULL; > >- TRACE("(%s)\n", debugstr_a(lpszUrlName)); >- >- if (!URLCacheContainers_FindContainerA(lpszUrlName, &pContainer)) >- return FALSE; >+ if(bUnicode) { >+ if (!URLCacheContainers_FindContainerW(lpszUrlName, &pContainer)) >+ return FALSE; >+ } else { >+ if (!URLCacheContainers_FindContainerA((LPSTR)lpszUrlName, &pContainer)) >+ return FALSE; >+ } > > if (!URLCacheContainer_OpenIndex(pContainer)) > return FALSE; >@@ -2024,11 +2076,20 @@ BOOL WINAPI DeleteUrlCacheEntryA(LPCSTR > if (!(pHeader = URLCacheContainer_LockIndex(pContainer))) > return FALSE; > >- if (!URLCache_FindEntryInHash(pHeader, lpszUrlName, &pEntry)) >+ if(bUnicode) { >+ lpszUrlNamea = (LPSTR)lpszUrlName; >+ } else { >+ int len = WideCharToMultiByte(CP_ACP, 0, lpszUrlName, -1, NULL, -1, 0, 0); >+ WideCharToMultiByte(CP_ACP, 0, lpszUrlName, -1, lpszUrlNamea, len, 0, 0); >+ } >+ >+ if (!URLCache_FindEntryInHash(pHeader, lpszUrlNamea, &pEntry)) > { > URLCacheContainer_UnlockIndex(pContainer, pHeader); >- TRACE("entry %s not found!\n", lpszUrlName); >+ TRACE("entry not found!\n"); > SetLastError(ERROR_FILE_NOT_FOUND); >+ if(bUnicode) >+ HeapFree(GetProcessHeap(), 0, lpszUrlNamea); > return FALSE; > } > >@@ -2041,11 +2102,34 @@ BOOL WINAPI DeleteUrlCacheEntryA(LPCSTR > > URLCache_DeleteEntry(pEntry); > >- URLCache_DeleteEntryFromHash(pHeader, lpszUrlName); >+ URLCache_DeleteEntryFromHash(pHeader, lpszUrlNamea); > > URLCacheContainer_UnlockIndex(pContainer, pHeader); > >+ if(bUnicode) >+ HeapFree(GetProcessHeap(), 0, lpszUrlNamea); >+ > return TRUE; >+} >+ >+/*********************************************************************** >+ * DeleteUrlCacheEntryA (WININET.@) >+ * >+ */ >+BOOL WINAPI DeleteUrlCacheEntryA(LPCSTR lpszUrlName) >+{ >+ TRACE("(%s)\n", debugstr_a(lpszUrlName)); >+ return DeleteUrlCacheEntryAW((LPCWSTR)lpszUrlName, FALSE); >+} >+ >+/*********************************************************************** >+ * DeleteUrlCacheEntryW (WININET.@) >+ * >+ */ >+BOOL WINAPI DeleteUrlCacheEntryW(LPCWSTR lpszUrlName) >+{ >+ TRACE("(%s)\n", debugstr_w(lpszUrlName)); >+ return DeleteUrlCacheEntryAW(lpszUrlName, TRUE); > } > > /*********************************************************************** > > Rob

2 1

Re: Moved some strings to resources
by Juan Lang 23 Dec '04

23 Dec '04

Hi Jacek, small suggestion: > @@ -1391,8 +1393,11 @@ static LRESULT FILEDLG95_InitControls(HW > /* change Open to Save FIXME: use resources */ > if (fodInfos->DlgInfos.dwDlgProp & FODPROP_SAVEDLG) > { The comment is out of date, you did use resources. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250

1 0

winetest failing on Windows 2000, VIA AC 97 audio
by Jakob Eriksson 23 Dec '04

23 Dec '04

http://test.winehq.org/data/200412231000/2000_MarcelHekman/winmm:wave.txt Can we blacklist this driver somehow? AFAIK I submitted a black list patch before for this driver but it was silently dropped. regards, Jakob

1 0

MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)
by Mike Hearn 23 Dec '04

23 Dec '04

Hi ho, Every so often I try out my favourite game to see how well it runs in Wine. This time, I found the demo (I have the full game but the demo is easier to debug) was working well! The following snowboarding game: http://www.housemarque.com/games/supremesb/ssb_demo.exe is not only a lot of fun but also Very Nearly There in Wine. There are only two problems preventing it from running perfectly: 1) There seems to be a bug in our msvcrt file reading APIs. I've chased this one before and got nowhere, but maybe somebody more familiar with the code can find it. We seem to pass back corrupt data: with builtin msvcrt the demo complains with a nicely detailed assertion that it can't find a file marker it's looking for. Native MSVCRT from WinXP makes it work (once you set winver=winxp) 2) When racing, the sky is black. An OpenGL bug perhaps? Weirdly when it's showing the pre-recorded demos the sky is just fine. The rest of the graphics are perfect. Finally if you put it in desktop mode, an X protocol error occurs initialising OpenGL. The XGetWindowAttributes call complains of a bad window. I debugged this for a bit and got nowhere, it wasn't as straightforward as it looked. Suffice to say that at the point it died opengl32.dll had been initialised several times already with the same value for root_window, and it worked each time previously (yes sync was enabled). I think this definitely used to work, so it feels like some WM rewrite regression to me. I could well be wrong though. This seems to affect all OpenGL+desktop mode apps. To make the game let you choose OpenGL in the setup program it has to be run in win2k/winxp mode. I do not know why. If you get it going, see if you can beat my best time (when playing on Linux) of 2:02. Have fun! :) thanks -mike

3 5

MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)
by Jesse Allen 23 Dec '04

23 Dec '04

On Thu, 23 Dec 2004 00:43:20 +0000, Mike Hearn <mh(a)codeweavers.com> wrote: > > 2) When racing, the sky is black. An OpenGL bug perhaps? Weirdly when it's > showing the pre-recorded demos the sky is just fine. The rest of the > graphics are perfect. What graphics card and driver do you use? This is important. I use a Radeon 9200 and DRI. In Warcraft III+opengl under wine, things would "disappear", but then re-appear under different conditions. I have screen shots I can upload that shows this in action. I used to use an nvidia card with the official driver. Comparatively, the nvidia graphics setup rendered everything perfectly. > > Finally if you put it in desktop mode, an X protocol error occurs > initialising OpenGL. The XGetWindowAttributes call complains of a bad > window. I debugged this for a bit and got nowhere, it wasn't as > straightforward as it looked. Suffice to say that at the point it died > opengl32.dll had been initialised several times already with the same > value for root_window, and it worked each time previously (yes sync was > enabled). > > I think this definitely used to work, so it feels like some WM rewrite > regression to me. I could well be wrong though. > > This seems to affect all OpenGL+desktop mode apps. You are correct, it used to work. I just tried it yesterday and it didn't work for me either. > > To make the game let you choose OpenGL in the setup program it has to be > run in win2k/winxp mode. I do not know why. > > If you get it going, see if you can beat my best time (when playing on > Linux) of 2:02. Have fun! :) > > thanks -mike > > Unfortunately I can't try your game at the moment cause it will take me too long to download -- 2 KB/s down only =( Jesse

2 1

Re: MSI: First go at thread safety for MSI records
by Alexandre Julliard 23 Dec '04

23 Dec '04

Mike McCormack <mike(a)codeweavers.com> writes: > Index: dlls/msi/msipriv.h > =================================================================== > RCS file: /home/wine/wine/dlls/msi/msipriv.h,v > retrieving revision 1.32 > diff -u -r1.32 msipriv.h > --- dlls/msi/msipriv.h 22 Dec 2004 15:05:07 -0000 1.32 > +++ dlls/msi/msipriv.h 23 Dec 2004 01:43:40 -0000 > @@ -54,6 +54,7 @@ > UINT magic; > UINT type; > UINT refcount; > + CRITICAL_SECTION cs; > msihandledestructor destructor; Do you really need a separate critical section for every single MSI object? That seems a bit overkill to me. -- Alexandre Julliard julliard(a)winehq.org

4 3

Going forward with fixing up tests failing because not run on visible desktop.
by Jakob Eriksson 23 Dec '04

23 Dec '04

Followup on tests failing because they are run as an invisible service on Windows: ---------------------------------------------------------------------------------- Now that we have bRunningOnVisibleDesktop=0 in the report, how do we make use of it? Do we mark on the server side which tests fail because of it, or should we add a flag to the ok() macro? I would like to have the information stored in the test code somehow. It would document implicitly which functions only work in visible mode. If we had a global variable named "running_on_visible_desktop", we would have code like this in the tests: if (running_on_visible_desktop) { ok(EnumEnhMetaFile(hdcDisplay, hMetafile, emf_enum_proc, dx, &rc), "EnumEnhMetaFile error %ld\n", GetLastError()); } Or we could mark them like this: expect_to_fail_if_running_on_visible_desktop { ok(EnumEnhMetaFile(hdcDisplay, hMetafile, emf_enum_proc, dx, &rc), "EnumEnhMetaFile error %ld\n", GetLastError()); } Where expect_to_fail_if.... should do some magic... regards, Jakob

1 0

Re: [OLE #10] Make out of process COM work with OXID based marshal ids
by Robert Shearman 23 Dec '04

23 Dec '04

Mike Hearn wrote: >This patch makes InstallShield work again, and should let you get >further Bill. > >- Ensure all intermediate threads join the original apartment >- Make the listener thread fully apartment scoped (one per apt not per > process) >- Improve "already have mid" error message >- Rename _StubReaderThread to stub_dispatch_thread >- Improve tracing > > Can you submit this patch again, but without the local server changes? You have persuaded me that this is the only way to keep things working for the moment. I'll submit a seperate patch for the local server problem, if that's ok with you. Rob

1 0

Looking for a Wine consultant
by Raetus Egli 23 Dec '04

23 Dec '04

I am sending this message for a friend of mine. I am the head of a company that is trying to migrate a VB6 system on WinNT to Linux. We would like to use this application under Debian Sarge using Wine. If you have experience in porting VB6 applications using Wine and have some free time to consult with an in-house developer it would be greatly appreciated. We would like to get the project up and running as soon as possible. If you are interested please get back to me at pyadegar(a)honeymae.com as soon as possible. Thanks.

1 0

Jump to page:

2025

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