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

Re: wine/dlls shell32/shlfileop.c shell32/shlexec. ...

by Christian Costa

Robert Shearman wrote: > Christian Costa wrote: > >> Hi Michael, >> >> This is typically the kind of patches that breaks everything. > > > > It cannot break anything. > >> 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. > > > > I think you are a little confused. HeapFree can be called with a NULL > pointer. On Win9x, this causes an error to be set, but from Windows > 2000 onwards and Wine, it is allowed and is not an error. Ok! I didn't know that. :-( I feel better now. :-) > > >> Looking at your other patches, there is some changes that seems >> suspect to me (in winmm and directx). > > > > The new code is perfectly correct, and is cleaner. > Yes it is. :-) It's true that if this code was so bad, Alexandre would have not accepted it. Bye, Christian

Dec. 24, 2004

Re: wine/dlls shell32/shlfileop.c shell32/shlexec. ...

by Christian Costa

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

Dec. 24, 2004

Re: wine/dlls shell32/shlfileop.c shell32/shlexec. ...

by Robert Shearman

Christian Costa wrote: > Hi Michael, > > This is typically the kind of patches that breaks everything. It cannot break anything. > 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. I think you are a little confused. HeapFree can be called with a NULL pointer. On Win9x, this causes an error to be set, but from Windows 2000 onwards and Wine, it is allowed and is not an error. > Looking at your other patches, there is some changes that seems > suspect to me (in winmm and directx). The new code is perfectly correct, and is cleaner. Rob

Dec. 24, 2004

Re: gmail invitation

by Shachar Shemesh

Izak Burger wrote: > http://ars.userfriendly.org/cartoons/?id=20041013 > > I have another six if anyone else desperately wants one... > > :-) You think that's good? I got this one http://ars.userfriendly.org/cartoons/?id=20040622 Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Dec. 24, 2004

Re: Systray patch but explorified

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > On Thu, 23 Dec 2004 19:06:04 +0100, Alexandre Julliard wrote: > > The other thing that needs to be done differently is that the > > WS_EX_TRAYWINDOW flag has to go, that's not Windows compatible. We > > need to define an appropriate interface that doesn't involve > > overloading Win32 flags. > > OK, would an atom set on the window be appropriate here? It's not even clear that we want a window at all. I think the right way is to first design a stand-alone systray (which we'll need for desktop mode anyway) and then plug XEMBED into that. -- Alexandre Julliard julliard(a)winehq.org

Dec. 24, 2004

Re: Interface for working directories/launchers

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > 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? The right way is to use start.exe on the .lnk file. -- Alexandre Julliard julliard(a)winehq.org

Dec. 24, 2004

Re: [AppDB] CODING_STANDARD

by Jonathan Ernst

By using superglobals we already achieved to have a better security and a better readability. Now we easily know which vars are comming from outside of the script ("parameters") and which vars are used inside the script (this is only true if we don't copy superglobals in local vars which is bad imo). This is already a good thing. But now to improve it even more and make it easy to know what a variable contains without having to read the whole code that precedes it we could just tell the developer what it contains by adding these thre letters to variables we use internally. It's very nice to know at the first sight if we are dealing with an array ([]) or an object for example. As you said we sometimes use integer or string as booleans. As your patches shows imo you also think it's a bad idea as we should use isset or (if it's an integer) logical operators (if($i>2)). Using strings and integers as boolean to know if they contain a value is bad as it can lead to semantical errors (you never know, someday your database could contain an entry whose id is 0 and then your if($id) check will be wrong). Migrating to superglobals already makes us add some more characters, why don't we add some more for local vars too (but we don't need to rewrite all the code now, it's just something we can keep in mind when rewriting code or writing new code) ? However if most of you think it just clutters the code and don't help future AppDB hackers to read the code more easily we could just drop this suggestion. Jonathan Le vendredi 24 décembre 2004 à 11:11 +0100, Paul van Schayck a écrit : > 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 > >

Dec. 24, 2004

[AppDB] Get rid of value fillers in appSubmit.php for a new version

by Paul van Schayck

Those value fillers are not used. We never send users back to the page when errors are found (maybe we should). Changelog: Remove registered globals from the new-version submit. They are not used.

Dec. 24, 2004

Re: [AppDB] CODING_STANDARD

by Paul van Schayck

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

Dec. 24, 2004

Re: gmail invitation

by Izak Burger

http://ars.userfriendly.org/cartoons/?id=20041013 I have another six if anyone else desperately wants one... :-) MediaHost (TM) wrote: > I have another 9....if somebody needs one :-) > > Ivan Leo Puoti wrote: > >> 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. >> >> >> > -- Technically speaking, if you receive this email, you are the intended recipient. Unless specifically stated otherwise I speak for myself. I am not responsible for anything you do with or without this email. By replying to this message you or any software agent acting on your behalf agree that I am the intended recipient. You also agree that I shall be free to use the contents of such a message as I see fit.

Dec. 24, 2004

AppDB Templates

by Stefan Pflüger

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

Dec. 23, 2004

Re: tests: add more listbox tests

by Ferenc Wagner

Mike Hearn <mike(a)navi.cx> writes: > 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. Actually (not ideally) you should just stick 1's into the appropriate TODO fields. -- Feri.

Dec. 23, 2004

Re: Interface for working directories/launchers

by Mike Hearn

On Thu, 23 Dec 2004 16:03:13 -0500, Dimitrie O. Paun wrote: > Why not just: > > Exec=winemenulauncher c:\games\supreme supreme.exe Could be, but we already dump lots of programs into the path. The other thing is that win32 launchers have "working directory" and "command": we should reproduce them faithfully IMHO. So if command is just "supreme.exe" then great, but if it's a full path then it would go in.

Dec. 23, 2004

Re: clean-up

by Jonathan Ernst

Le jeudi 23 décembre 2004 à 22:39 +0100, Paul van Schayck a écrit : > Hey Eric, > > On Thu, 23 Dec 2004 01:38:02 -0800 (PST), Eric Blade <ekdikeo4(a)yahoo.com> wrote: > > The attached patch includes a lot of cleaning up, > > mostly to HTML, a bit to some PHP. > > What's this supposed to do: > if(!$tempResult) > { > - echo "$query \n"; > + echo "$query < >\n"; > echo "An error occurred: ".mysql_error().""; > exit; > } > @@ -68,7 +68,7 @@ > if(debugging()) > { > echo $query; > - echo " "; > + echo "< >< >"; > } > Same question: what are those < > ??? > And: > > -if(!loggedin()) > +if(!loggedin() || (!havepriv("admin")) If you are not loggeddin() you can't havepriv("admin") btw So we have: _old version_ C=A A=TRUE => C=TRUE A=FALSE => C=FALSE _your version_ C=(A OR B) A=TRUE => B=TRUE => C=TRUE A=FALSE, B=TRUE => C=TRUE A=FALSE, B=FALSE => C=FALSE So your version doesn't mean the same as the old one, is that correct ? If it is what we need, why don't you simple use: if(!havepriv("admin")) C=B B=TRUE => C=TRUE B=FALSE => C=FALSE Which means the same as your version. > > Shouldn't this be > if(!loggedin() AND (!havepriv("admin")) C=(A AND B) A=TRUE => B=TRUE => C=TRUE A=FALSE, B=TRUE => C=FALSE A=FALSE, B=FALSE => C=FALSE So this version means the same as the old one but then why do we make it more complicated ?

Dec. 23, 2004

Re: clean-up

by Paul van Schayck

Hey Eric, On Thu, 23 Dec 2004 01:38:02 -0800 (PST), Eric Blade <ekdikeo4(a)yahoo.com> wrote: > The attached patch includes a lot of cleaning up, > mostly to HTML, a bit to some PHP. What's this supposed to do: if(!$tempResult) { - echo "$query \n"; + echo "$query < >\n"; echo "An error occurred: ".mysql_error().""; exit; } @@ -68,7 +68,7 @@ if(debugging()) { echo $query; - echo " "; + echo "< >< >"; } And: -if(!loggedin()) +if(!loggedin() || (!havepriv("admin")) Shouldn't this be if(!loggedin() AND (!havepriv("admin")) Rest looks good. Kind regards, Paul

Dec. 23, 2004

Patch to README

by Stefan Pflüger

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

Dec. 23, 2004

Re: MSI: First go at thread safety for MSI records

by Mike McCormack

Alexandre Julliard wrote: > Do you really need a separate critical section for every single MSI > object? That seems a bit overkill to me. What do you suggest? Mike

Dec. 23, 2004

Re: Interface for working directories/launchers

by Dimitrie O. Paun

On Thu, Dec 23, 2004 at 06:14:09PM +0000, Mike Hearn wrote: > Exec=wine winemenulauncher c:\games\supreme supreme.exe > > Does this sound sensible? Why not just: Exec=winemenulauncher c:\games\supreme supreme.exe -- Dimi.

Dec. 23, 2004

Re: gmail invitation

by MediaHost (TM)

I have another 9....if somebody needs one :-) Ivan Leo Puoti wrote: > 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. > > > -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390

Dec. 23, 2004

Re: Correct use of the ok function in user/tests and kernel/tests

by Lionel Ulmer

On Thu, Dec 23, 2004 at 09:35:14PM +0100, Rein Klazes wrote: > I can not remember the rule in C that say so. There is a rule that > specifies that each argument is evaluated fully before evaluating the > next one, but the order in winch this happens is free to the compiler I am pretty sure that the order of evaluation is not fixed because I once had to fix some bugs in ScummVM because the order of evaluation on the ARM platform was not the same as the one on X86 (which lead to all sort of crazy stuff with code like 'foo(pop(), pop());' :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 23, 2004

Re: Correct use of the ok function in user/tests and kernel/tests

by Rein Klazes

On Thu, 23 Dec 2004 17:13:26 +0100, you wrote: > > Aren't arguments always evaluated left to right? I can not remember the rule in C that say so. There is a rule that specifies that each argument is evaluated fully before evaluating the next one, but the order in winch this happens is free to the compiler Moreover I only do this exercise because on my wine (compiled with gcc 3.4) they were not. Rein.

Dec. 23, 2004

Re: tests: add more listbox tests

by Mike Hearn

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

Dec. 23, 2004

Re: Implemented CreateUrlCacheEntryW and DeleteUrlCacheEntryW

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > The strncpyW function exists for a reason. Also, it is better to use > strlenW than lstrlenW. Actually strncpy(W) is almost always the wrong thing to use. If you want to copy a fixed length (like in that case) memcpy is a much better choice; if you want to copy and possibly truncate a string lstrcpynA/W is preferable. -- Alexandre Julliard julliard(a)winehq.org

Dec. 23, 2004

gmail invitation

by Ivan Leo Puoti

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.

Dec. 23, 2004

Re: Implemented CreateUrlCacheEntryW and DeleteUrlCacheEntryW

by Robert Shearman

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

Dec. 23, 2004

Re: Systray patch but explorified

by Mike Hearn

On Thu, 23 Dec 2004 19:06:04 +0100, Alexandre Julliard wrote: > The other thing that needs to be done differently is that the > WS_EX_TRAYWINDOW flag has to go, that's not Windows compatible. We > need to define an appropriate interface that doesn't involve > overloading Win32 flags. OK, would an atom set on the window be appropriate here? thanks -mike

Dec. 23, 2004

Interface for working directories/launchers

by Mike Hearn

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

Dec. 23, 2004

Re: Systray patch but explorified

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > That's a bit vague, how should it be done? I also don't understand why > the XEMBED code has to be split off, that's the standard way to dock > tray icons in all modern desktops. If we don't dock the icons, what > else can we do with them? The code has to be split off from the explorer patch because it's independent, you don't need XEMBED to add an explorer process, and you don't need an explorer process to support XEMBED; and the rule is that separate changes should be done as separate patches, for many good reasons. The other thing that needs to be done differently is that the WS_EX_TRAYWINDOW flag has to go, that's not Windows compatible. We need to define an appropriate interface that doesn't involve overloading Win32 flags. > > Also the 16-bit calls need to be removed. > > I did it that way because when I last asked you how to marshal an > HICON you said to use the 16-bit functions to get the data. How can I > marshal the HICON without using GlobalLock16 and friends? You should be able to do it with GetIconInfo and friends. -- Alexandre Julliard julliard(a)winehq.org

Dec. 23, 2004

Re: Systray patch but explorified

by Mike Hearn

On Thu, Dec 23, 2004 at 06:10:50PM +0100, Alexandre Julliard wrote: > I'm still hoping to see a version that doesn't include the xembed > stuff, this will have to be done differently anyway. That's a bit vague, how should it be done? I also don't understand why the XEMBED code has to be split off, that's the standard way to dock tray icons in all modern desktops. If we don't dock the icons, what else can we do with them? > Also the 16-bit calls need to be removed. I did it that way because when I last asked you how to marshal an HICON you said to use the 16-bit functions to get the data. How can I marshal the HICON without using GlobalLock16 and friends? thanks -mike

Dec. 23, 2004

Re: Moved some strings to resources

by Juan Lang

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

Dec. 23, 2004

winetest failing on Windows 2000, VIA AC 97 audio

by Jakob Eriksson

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

Dec. 23, 2004

Re: Systray patch but explorified

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > 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? I'm still hoping to see a version that doesn't include the xembed stuff, this will have to be done differently anyway. Also the 16-bit calls need to be removed. -- Alexandre Julliard julliard(a)winehq.org

Dec. 23, 2004

Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Robert Reif

Eric Pouech wrote: > Jonathan Gevaryahu a écrit : > >> Eric Pouech <pouech-eric(a)wanadoo.fr> wrote: >> >>> To: Anish Mistry <mistry.7(a)osu.edu> >>> Cc: wine-devel(a)winehq.org >>> Subject: Re: Wine regression caused by 12/02 18:05:37 UTC commit: >>> breaks Total >>> Annihilation >>> >>> and if you remove the entire line (if (!is_version_nt()) access = >>> TIMER_ALL_ACCESS;)? >>> A+ >>> >>> >>> --__--__-- >>> >> >> That doesn't fix the problem here. Still the same trace response... >> I haven't run it enough times to see if it will still occasionally >> work with that line altered or removed... I know it does work >> (without any changes from the version in CVS) about 5% of the time. > > hmm it don't see where this could come from > could someone of you try to apply the patch in parts (semaphore, > event, timer, mutex), just to narrow a bit where this could come from > A+ > > > Is anyone still looking into this? I'm seeing the same problem here (below messages repeated and 100% CPU usage) on RH 9 with the direct sound regression test and some games. 0009: select( flags=4, cookie=0x4084f930, timeout=0, handles={0x64} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4084f930, timeout=0, handles={0x64} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4084f930, timeout=0, handles={0x64} ) 0009: select() = ACCESS_DENIED

Dec. 23, 2004

Re: Correct use of the ok function in user/tests and kernel/tests

by Jakob Eriksson

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. > > >

Dec. 23, 2004

Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)

by Lionel Ulmer

On Thu, Dec 23, 2004 at 02:22:36PM +0000, Robert Shearman wrote: > What about just not using desktop mode? Ah no, we won't re-start the Desktop mode flame-war :-) Lionel PS: and yes, as it works just fine in non-Desktop mode, it's not a 'severe' bug at all. -- Lionel Ulmer - http://www.bbrox.org/

Dec. 23, 2004

Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)

by Tom

Jesse Allen wrote: > > Unfortunately I can't try your game at the moment cause it will take > me too long to download -- 2 KB/s down only =( Hello, You may want to look here if you only get 2 KB/s http://www.krasu.ru/soft/chuchelo/download.php3 Tom > > > Jesse > > >

Dec. 23, 2004

Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)

by Robert Shearman

Lionel Ulmer wrote: >On Thu, Dec 23, 2004 at 01:14:17PM +0000, Mike Hearn wrote: > > >>Atoms set on the window should be process scoped not global. I think >>this is something for Alexandre to look at. >> >> > >Well, after some more additional TRACEs, it's not an atom problem after >all... It's just that the HWND for the desktop window is the same for both >processes (which is normal) but that means that the second process just >overwrites the 'whole_window' atom for the 'common' desktop window and >corrupts it for the first process started. > >So I do not have an easy fix in mind except the merging of the various >'winedesktop' work that was done some time ago to have only one X11 window. > > What about just not using desktop mode? Rob

Dec. 23, 2004

Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)

by Lionel Ulmer

On Thu, Dec 23, 2004 at 01:14:17PM +0000, Mike Hearn wrote: > Atoms set on the window should be process scoped not global. I think > this is something for Alexandre to look at. Well, after some more additional TRACEs, it's not an atom problem after all... It's just that the HWND for the desktop window is the same for both processes (which is normal) but that means that the second process just overwrites the 'whole_window' atom for the 'common' desktop window and corrupts it for the first process started. So I do not have an easy fix in mind except the merging of the various 'winedesktop' work that was done some time ago to have only one X11 window. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 23, 2004

Re: Systray patch but explorified

by Mike Hearn

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

Dec. 23, 2004

Re: MSI: First go at thread safety for MSI records

by Mike Hearn

On Thu, 23 Dec 2004 21:11:41 +0000, Mike McCormack wrote: > What do you suggest? Prove you're a real man by doing everything including linked lists using the Interlocked functions and busy-wait loops. Critical sections are for wimps ;)

Dec. 23, 2004

Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)

by Mike Hearn

On Thu, 2004-12-23 at 13:53 +0100, Lionel Ulmer wrote: > Yeah, I already tried once to debug this and was a bit stuck... I had no > idea how to progress further on this though. I sunk quite a few hours into it and didn't see anything. I think the only way to find this one will be by writing lots of unit tests and hoping one trips. > Did you try with a 'reference driver' (like Mesa) ? It's pretty rare that a > bug is specifically in Wine's implementation of OpenGL but rather in > interactions between Wine and the GL driver. Nope. I did think it may be a driver issue, I'm using the nVidia binary drivers (latest release). I will go back to "nv" which should force Wine to use Mesa, and see if it still happens. > And more important, it's a bitch to find out exactly which graphic > primitives are responsible to display something like the sky in thousands of > GL traces so it's almost impossible to debug. Ah :( I was wondering how you did it, I thought there may be some magic tool or technique you had. I suppose not :( > And as one can see, the Desktop window 'atom' seems to have been changed by > the 'graphic chooser' application which means that 'Supreme.exe' tries to > get the Window attributes of a window that is now deleted => nice X11 > crash. Atoms set on the window should be process scoped not global. I think this is something for Alexandre to look at. Maybe we need some unit tests for window atoms if we don't already have them. It doesn't really matter for me. The game (for once) works perfectly in full screen mode. Now I have a launcher on my panel and desktop with the right icon, that launches the app in fullscreen mode, and runs (nearly) perfectly with native performance. That's how Wine should be! Merry Christmas everybody :D thanks -mike

Dec. 23, 2004

Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)

by Lionel Ulmer

> 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) Yeah, I already tried once to debug this and was a bit stuck... I had no idea how to progress further on this though. > 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. Did you try with a 'reference driver' (like Mesa) ? It's pretty rare that a bug is specifically in Wine's implementation of OpenGL but rather in interactions between Wine and the GL driver. And more important, it's a bitch to find out exactly which graphic primitives are responsible to display something like the sky in thousands of GL traces so it's almost impossible to debug. > 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). The bug was actually not that hard to find. Basically, what happens is the following (with some additionnal TRACEing added in X11DRV): 0009:trace:x11drv:X11DRV_create_desktop created 4800007 'Supreme.exe' starts and gets its own Desktop window 000c:trace:x11drv:X11DRV_create_desktop created 4e00007 Now the 'graphic chooser' application starts and creates its own Desktop window 000c:trace:opengl:process_attach 0x78052988 04e00007 000c:trace:opengl:process_attach 0x78052988 04e00007 (...) In the case of the 'graphic chooser', one can see it uses the correct window. 0009:trace:opengl:process_attach 0x78054910 04e00007 But then the main games does a 'LoadLibrary' on OpenGL and the 'process_attach' function is called. And as one can see, the Desktop window 'atom' seems to have been changed by the 'graphic chooser' application which means that 'Supreme.exe' tries to get the Window attributes of a window that is now deleted => nice X11 crash. This will surely be fixed by any proper 'only one window' Desktop patches (for which I lust for since a long time :-) )... I will see how I could 'hack' this while waiting for the proper Desktop fix (maybe having some 'process-local' atom to store the Desktop window instead of a global one). > This seems to affect all OpenGL+desktop mode apps. It only affects applications which do start 'helper' applications before doing OpenGL stuff. For example, 'TreeMark' works fine in Desktop mode. Lionel PS: are the 'TID' globally unique or are they only 'process unique' ? -- Lionel Ulmer - http://www.bbrox.org/

Dec. 23, 2004

Re: MSI: First go at thread safety for MSI records

by Robert Shearman

Mike McCormack wrote: > Alexandre Julliard wrote: > >> Do you really need a separate critical section for every single MSI >> object? That seems a bit overkill to me. > > > What do you suggest? > Keep the msiobj_lock/msiobj_unlock functions, but make them use a process-wide critical section. It will then be simple to add a per object critical section if it is proved that performance is suffering. Rob

Dec. 23, 2004

Going forward with fixing up tests failing because not run on visible desktop.

by Jakob Eriksson

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

Dec. 23, 2004

Re: Approving of the WINEprobe initiative

by Izak Burger

Stefan Munz wrote: > as my partner David Gümbel is travelling much these days and thus is badly > online available, I thought I add a few lines here :-) Boy it is good to see someone struggle as much with English as I struggle with German :-) Badly online? You either mean "hardly" online (ie not many times, which I think would be wenig auf Deutsch) or that his connection speed is low. > As this is a german project, actually a swabian project ;-) it is important > for us, that the name sounds good in german. And yes, there are some english > alternatives that sound funny in german too or that people who only speak > german would'nt even understand. I think I understand. Probe obviously means the same as "proef" in my mother tongue which means "to test" or "to be tested". I don't think there is an English word that will do justice, and "probing" makes sense even in English, even if it does not generate excitement. But that is just me, being bored at work two days before Christmas and looking for some email to answer... Schönes Weinacht, Izak -- Technically speaking, if you receive this email, you are the intended recipient. Unless specifically stated otherwise I speak for myself. I am not responsible for anything you do with or without this email. By replying to this message you or any software agent acting on your behalf agree that I am the intended recipient. You also agree that I shall be free to use the contents of such a message as I see fit.

Dec. 23, 2004

Re: [OLE #10] Make out of process COM work with OXID based marshal ids

by Robert Shearman

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

Dec. 23, 2004

Re: MSI: First go at thread safety for MSI records

by Alexandre Julliard

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

Dec. 23, 2004

Re: Approving of the WINEprobe initiative

by David Gümbel

Scott Ritchie schrieb am 22.12.2004 um 12:41 Uhr: > On Wed, 2004-12-22 at 11:39 +0100, David Gümbel wrote: > > Hi everybody, > > > > Yep, I think you all made a point when saying "probe" in english is really > > not quite... optimal ;) I personally like the PortWine idea very much - > > we'll consider renaming the initiative accordingly. > > > > I request 20% of all name-change related fan-mail ;) Sure - I hope you have a high bandwidth connection ?-) Cheers, David

Dec. 23, 2004

Re: Approving of the WINEprobe initiative

by Stefan Munz

as my partner David Gümbel is travelling much these days and thus is badly online available, I thought I add a few lines here :-) > <david.guembel(a)itomig.de> wrote: > > Jep, its actually a pun: WINEprobe means be something like WINEtasting in > > english an maybe "degustation de WINE" in french. It's a little hard to > > translate puns, sorry ;) Maybe this is helpful: > > http://dict.leo.org/?search=weinprobe > > I saw that reference later in the email. That does make sense and I > guess WINEprobe is a good name. Not so good when said in English, but > then again that doesn't really matter. Puns are fun. I'm sure > there's plenty of English words that don't sound so good in German :) As this is a german project, actually a swabian project ;-) it is important for us, that the name sounds good in german. And yes, there are some english alternatives that sound funny in german too or that people who only speak german would'nt even understand. > > By the way, didn't we standardize on "Wine" rather than "WINE" a few > years ago? Would "WineProbe" be more appropriate? I think this is originally me fault as I created the first draft for this project. WineProbe or Wine-Probe would be at least as good as WINEProbe, so I'll change it this way. <snip> > If you do contribute to Wine, we'll gladly add you to our acknowledgements > page ( http://www.winehq.org/site/acknowledgement ). Then you can say > things in press releases like, "WRS, an acknowledged Wine contributor, > ....." Anyone disagree with that idea? this sounds great, but the WRS would not contribute to Wine (besides they host the WineConf, but the decision is still pending as far as I know), this would be ITOMIG. And I would appreciate the idea very much. Stefan Munz > > -Brian Vincent

Dec. 23, 2004

MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)

by Jesse Allen

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

Dec. 22, 2004