Re: gmail invitation
http://ars.userfriendly.org/cartoons/?id=20041013 I have another six if anyone else desperately wants one... :-) MediaHost (TM) wrote: I have another 9if 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.
Re: tests: add more listbox tests
Mike Hearn <[EMAIL PROTECTED]> 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.
AppDB Templates
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 template.php Description: application/httpd-php
Re: Interface for working directories/launchers
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.
Re: clean-up
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 <[EMAIL PROTECTED]>
> 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 ?
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: tests: add more listbox tests
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
Re: clean-up
Hey Eric,
On Thu, 23 Dec 2004 01:38:02 -0800 (PST), Eric Blade <[EMAIL PROTECTED]> 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
Re: Interface for working directories/launchers
On Thu, Dec 23, 2004 at 06:14:09PM +, 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.
Re: gmail invitation
I have another 9if 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 MediaHost™ at www.mediahost.org Skype: startcom Phone: +1.213.341.0390
Re: Correct use of the ok function in user/tests and kernel/tests
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/
gmail invitation
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.
Re: Correct use of the ok function in user/tests and kernel/tests
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.
Patch to README
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 - 1.4 +++ README 23 Dec 2004 20:23:33 - @@ -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
Re: Implemented CreateUrlCacheEntryW and DeleteUrlCacheEntryW
Robert Shearman <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Re: Systray patch but explorified
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
Re: Implemented CreateUrlCacheEntryW and DeleteUrlCacheEntryW
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 - 1.22
+++ dlls/wininet/urlcache.c 23 Dec 2004 11:08:39 -
@@ -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 a
Going forward with fixing up tests failing because not run on visible desktop.
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
winetest failing on Windows 2000, VIA AC 97 audio
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
Re: Correct use of the ok function in user/tests and kernel/tests
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.
Looking for a Wine consultant.
I am the head of a company that is trying to migrate a VB6 system on WinNT and would like to use that application under Debian Sarge using Wine. If you have experience in porting VB6 applications using Wine and have some free time to consult an in house developer it would be appreciated. We would like to get the project up and running as soon as possible. If your interested please get back to me at [EMAIL PROTECTED] as soon as possible. Thanks.
Re: Approving of the WINEprobe initiative
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
Re: Systray patch but explorified
Mike Hearn <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Interface for working directories/launchers
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
Re: Moved some strings to resources
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
Re: Systray patch but explorified
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
Re: Systray patch but explorified
Mike Hearn <[EMAIL PROTECTED]> writes: > On Mon, 13 Dec 2004 21:58:07 +, 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 [EMAIL PROTECTED]
Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation
Eric Pouech wrote:
Jonathan Gevaryahu a écrit :
Eric Pouech <[EMAIL PROTECTED]> wrote:
To: Anish Mistry <[EMAIL PROTECTED]>
Cc: wine-devel@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
Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)
On Thu, Dec 23, 2004 at 02:22:36PM +, 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/
Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)
Lionel Ulmer wrote: On Thu, Dec 23, 2004 at 01:14:17PM +, 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
Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)
On Thu, Dec 23, 2004 at 01:14:17PM +, 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/
Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)
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
Re: Systray patch but explorified
On Mon, 13 Dec 2004 21:58:07 +, 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
Re: MSI: First go at thread safety for MSI records
On Thu, 23 Dec 2004 21:11:41 +, 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 ;)
Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)
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
Re: MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)
> 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 487 'Supreme.exe' starts and gets its own Desktop window 000c:trace:x11drv:X11DRV_create_desktop created 4e7 Now the 'graphic chooser' application starts and creates its own Desktop window 000c:trace:opengl:process_attach 0x78052988 04e7 000c:trace:opengl:process_attach 0x78052988 04e7 (...) In the case of the 'graphic chooser', one can see it uses the correct window. 0009:trace:opengl:process_attach 0x78054910 04e7 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/
Re: MSI: First go at thread safety for MSI records
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
Re: MSI: First go at thread safety for MSI records
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
Re: Approving of the WINEprobe initiative
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.
Re: [OLE #10] Make out of process COM work with OXID based marshal ids
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
Re: MSI: First go at thread safety for MSI records
Mike McCormack <[EMAIL PROTECTED]> 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.h22 Dec 2004 15:05:07 - 1.32 > +++ dlls/msi/msipriv.h23 Dec 2004 01:43:40 - > @@ -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 [EMAIL PROTECTED]
Re: Approving of the WINEprobe initiative
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 :-) > <[EMAIL PROTECTED]> 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. > 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
