Re: Patch to limit testing results in AppDB
Oooh a new appdb hacker. Welcome :-)
> // Show the Test results for a application version
> function ShowVersionsTestingTable($iVersionId, $iCurrentTest, $link)
> {
The maximum number of versions to show should be a parameter to this function.
> -$hResult = query_appdb("SELECT *
> +global $showAll;
We don't want to use globals. Looking at $_REQUEST['showAll'] should work.
> +
> +$hResult = query_appdb("SELECT *
> +FROM testResults
> +WHERE versionId = '".$iVersionId."'
> +ORDER BY testedDate DESC;");
> +if(mysql_num_rows($hResult) <= 5 || is_string($showAll)) {
> +$hResult = query_appdb("SELECT *
> FROM testResults
> WHERE versionId = '".$iVersionId."'
> ORDER BY testedDate DESC;");
> +}
> +else{
> +$hResult = query_appdb("SELECT *
> +FROM testResults
> +WHERE versionId = '".$iVersionId."'
> +ORDER BY testedDate DESC LIMIT 0,5;");
> +}
This is simplier if you do:
$sQuery = "select * from testResults WHERE versionId = '".$iVersionId."' ORDER
BY testedDate DESC";
if(!$showAll)
$sQuery.=" LIMIT 0,"$maxEntries;
It saves a db query and reduces duplicate code.
> if(!$hResult || mysql_num_rows($hResult) == 0)
> return;
> echo 'Testing Results',"\n";
> @@ -379,7 +394,9 @@
> if ($oTest->iTestingId == $iCurrentTest)
> echo ' class="color2">Current',"\n";
> else
> -echo '[ href="'.$link.$oTest->iTestingId.'">Show]',"\n";
> +echo '[ href="'.$link.$oTest->iTestingId;
> +if(is_string($showAll)) echo
> '&showAll='.$showAll.'">Show]',"\n";
> +else echo '">Show]',"\n";
> echo '',"\n";
> echo '',"\n";
> echo $oDistribution->sName.'',"\n";
> @@ -393,6 +410,20 @@
> }
>
> echo '',"\n";
> +
> +if(mysql_num_rows($hResult) >= 5 AND !is_string($showAll)) {
> +echo '';
> +echo ' />';
> +echo '';
> +echo '';
> +}
> +if(is_string($showAll)) {
> +echo '';
> +echo ' />';
> +echo ' value="Limit to 5 Tests" />';
> +echo '';
> +unset($showAll);
> +}
>
The common code should be factored out of these conditionals. The only line
that differs appears to be the one that generates the form button.
Oh, and can you attach the patch to the email? It came through as inlined
here which makes it difficult to save to a file, although maybe I just don't
know what I'm doing with kmail.
Chris
Re: DINPUT: Enforce single mouse acquire
On Wed, 2006-01-25 at 19:11 -0500, Alex Villacís Lasso wrote: > > But if you disallow nested acquires the check for This being NULL in > > the hook proc should not be needed, right? > > > > > Good point. But it doesn't hurt either. This might be changed into an > assertion, since that is what the hook expects. What do you think? Yes, I think an assert would be more appropriate. -- Dmitry.
Re: DINPUT: Enforce single mouse acquire
Dmitry Timoshkov wrote: On Wed, 2006-01-25 at 18:19 -0500, Alex Villacís Lasso wrote: The easiest way out of this (the one the patch implements) is to disallow nested acquires. It is a little more complicated if DirectInput actually requires support for nested acquires (why? I have only one mouse...) But if you disallow nested acquires the check for This being NULL in the hook proc should not be needed, right? Good point. But it doesn't hurt either. This might be changed into an assertion, since that is what the hook expects. What do you think? Alex Villacís Lasso
Re: DINPUT: Enforce single mouse acquire
On Wed, 2006-01-25 at 18:19 -0500, Alex Villacís Lasso wrote: > The easiest way out of this (the one the patch implements) is to > disallow nested acquires. It is a little more complicated if DirectInput > actually requires support for nested acquires (why? I have only one > mouse...) But if you disallow nested acquires the check for This being NULL in the hook proc should not be needed, right? -- Dmitry.
Re: DINPUT: Enforce single mouse acquire
Dmitry Timoshkov wrote: On Wed, 2006-01-25 at 17:55 -0500, Alex Villacís Lasso wrote: The problem is that if (This == NULL), then This->hook cannot be evaluated (for CallNextHookEx) without generating a segmentation fault. This is the very situation the patch is trying to prevent. Sorry for not spotting it earlier. 'This' can't be NULL, that's an impossible situation. You need to debug it and find out why hook proc is being called without This->hook being set. I already did. The scenario is as follows: 1) Start Fate/Stay Night (current_lock starts as NULL) 2) Mouse gets acquired (current_lock becomes valid), and mouse function gets hooked 3) User selects About dialog. 3) About dialog attempts a second (nested) mouse acquire, which (before my patch) succeeds because there is no check on whether current_lock is already set. Again, current_lock is assigned (overwriting the previous value), and the mouse function gets hooked (again). Notice that the mouse function is now hooked twice. 4) User dismisses the About dialog. Second acquire is released. The current_lock pointer gets set to NULL, and the second instance of the mouse function gets unhooked, but the first instance (the one hooked at program startup) remains hooked, now with current_lock == NULL. 5) Mouse event happens. Function hook gets called, and tries to use the NULL pointer. Instant segmentation fault. The easiest way out of this (the one the patch implements) is to disallow nested acquires. It is a little more complicated if DirectInput actually requires support for nested acquires (why? I have only one mouse...) Alex Villacís Lasso
Re: DINPUT: Enforce single mouse acquire
On Wed, 2006-01-25 at 17:55 -0500, Alex Villacís Lasso wrote: > The problem is that if (This == NULL), then This->hook cannot be > evaluated (for CallNextHookEx) without generating a segmentation fault. > This is the very situation the patch is trying to prevent. Sorry for not spotting it earlier. 'This' can't be NULL, that's an impossible situation. You need to debug it and find out why hook proc is being called without This->hook being set. -- Dmitry.
Re: DINPUT: Enforce single mouse acquire
Dmitry Timoshkov wrote:
On Wed, 2006-01-25 at 17:32 -0500, Alex Villacís Lasso wrote:
+if (This == NULL) {
+ERR("mouse hook called with no current lock!\n");
+return 0;
+}
+
if (code != HC_ACTION) return CallNextHookEx( This->hook, code,
wparam, lparam );
You need to call CallNextHookEx in any case, otherwise it might break
other hooks in the chain. Probably just add a check for This being NULL
in the same place as the code checks for HC_ACTION.
The problem is that if (This == NULL), then This->hook cannot be
evaluated (for CallNextHookEx) without generating a segmentation fault.
This is the very situation the patch is trying to prevent.
Alex Villacís Lasso
Re: DINPUT: Enforce single mouse acquire
On Wed, 2006-01-25 at 17:32 -0500, Alex Villacís Lasso wrote:
> +if (This == NULL) {
> +ERR("mouse hook called with no current lock!\n");
> +return 0;
> +}
> +
> if (code != HC_ACTION) return CallNextHookEx( This->hook, code,
wparam, lparam );
You need to call CallNextHookEx in any case, otherwise it might break
other hooks in the chain. Probably just add a check for This being NULL
in the same place as the code checks for HC_ACTION.
--
Dmitry.
Re: wine and jack => segfault? / wine and OSS not working
Joachim Förster wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Pouech wrote:
can you post a +winmm,+oss,+wave trace ?
A trace of wine using OSS-output driver and oss2jack:
that's because oss2jack doesn't provide a proper mixer interface
does the attached patch help ?
A+
--
Eric Pouech
diff --git a/dlls/winmm/wineoss/audio.c b/dlls/winmm/wineoss/audio.c
index 7df0bca..596190b 100644
--- a/dlls/winmm/wineoss/audio.c
+++ b/dlls/winmm/wineoss/audio.c
@@ -740,9 +740,7 @@ static BOOL OSS_WaveOutInit(OSS_DEVICE*
}
close(mixer);
} else {
-ERR("open(%s) failed (%s)\n", ossdev->mixer_name ,
strerror(errno));
-OSS_CloseDevice(ossdev);
-return FALSE;
+WARN("open(%s) failed (%s)\n", ossdev->mixer_name ,
strerror(errno));
}
}
#endif /* SOUND_MIXER_INFO */
@@ -892,9 +890,7 @@ static BOOL OSS_WaveInInit(OSS_DEVICE* o
}
close(mixer);
} else {
-ERR("open(%s) failed (%s)\n", ossdev->mixer_name, strerror(errno));
-OSS_CloseDevice(ossdev);
-return FALSE;
+WARN("open(%s) failed (%s)\n", ossdev->mixer_name,
strerror(errno));
}
}
#endif /* SOUND_MIXER_INFO */
@@ -2254,6 +2250,7 @@ static DWORD wodGetVolume(WORD wDevID, L
return MMSYSERR_NOTENABLED;
}
if (ioctl(mixer, SOUND_MIXER_READ_PCM, &volume) == -1) {
+close(mixer);
WARN("ioctl(%s, SOUND_MIXER_READ_PCM) failed (%s)\n",
WOutDev[wDevID].ossdev->mixer_name, strerror(errno));
return MMSYSERR_NOTENABLED;
@@ -2297,12 +2294,12 @@ DWORD wodSetVolume(WORD wDevID, DWORD dw
return MMSYSERR_NOTENABLED;
}
if (ioctl(mixer, SOUND_MIXER_WRITE_PCM, &volume) == -1) {
+close(mixer);
WARN("ioctl(%s, SOUND_MIXER_WRITE_PCM) failed (%s)\n",
WOutDev[wDevID].ossdev->mixer_name, strerror(errno));
return MMSYSERR_NOTENABLED;
-} else {
-TRACE("volume=%04x\n", (unsigned)volume);
}
+TRACE("volume=%04x\n", (unsigned)volume);
close(mixer);
/* save requested volume */
Re: user: fix DrawTextExA/W on empty strings.
From: "Paul Vriens" <[EMAIL PROTECTED]> > But there's an if in between: > > if (count == -1) count = strlenW(str); Yeap, missed that one. Which proves that the code should be improved, since it managed to confuse 2 people already ;) -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: user: fix DrawTextExA/W on empty strings.
On Wed, 2006-01-25 at 14:03 -0500, Dimi Paun wrote: > From: "Rein Klazes" <[EMAIL PROTECTED]> > > Wrong, look again. > > You must be kidding. Care to explain how 'stmt' > can ever be executed in: > > ... >if (A || B) return; >if (B) stmt; > ... > But there's an if in between: if (count == -1) count = strlenW(str); Paul.
Re: HW address w/o connection in iphlpapi
On Wed, 2006-01-25 at 11:13 -0800, Juan Lang wrote: > I'm not the decider here, really. Alexandre is. While I'd like to see my > recent patch get in because it removes a lot of unnecessary junk from > ifenum.c and improves the situation for most people, it's not the end of > the story. Wine's policy is to try to run on as many systems as possible, > regardless of what system it was built on. From that perspective, using > your approach is more correct. Assuming my patch from today gets in, feel > free to improve on it. Got it. I have something that works for my product (rh8 based, wine 20050419). I'll keep an eye on this when we get around to upgrading. I think what makes most sense is to use if_nameindex() unless it is known not to work, using if_indextoname() only as a work around. Seems like this could be done with a config flag, given that the only time you'll see the problem is on a system with the old libc which means that the wine was also built against the old libc. So a compile time flag would do the trick. Does that sound right, or does it have to be detected at runtime? - mo
Re: HW address w/o connection in iphlpapi
> The function does seem to be provided by libc. And so the diff must be > in the implementations of that. Is there any precedent in Wine of making > a runtime decision based on the c library? Probably, but see below.. > Would you be OK with a patch that uses if_indextoname() only in the > special case of glibc-2.2.93 (I believe that's the RH8 libc), but > if_nameindex() otherwise? I'm not the decider here, really. Alexandre is. While I'd like to see my recent patch get in because it removes a lot of unnecessary junk from ifenum.c and improves the situation for most people, it's not the end of the story. Wine's policy is to try to run on as many systems as possible, regardless of what system it was built on. From that perspective, using your approach is more correct. Assuming my patch from today gets in, feel free to improve on it. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: HW address w/o connection in iphlpapi
On Wed, 2006-01-25 at 10:42 -0800, Juan Lang wrote: > > > Although I don't like the idea of predefined limits :) I'll probably > > > > Me neither, which is why I used that prominent macro > > MOST_INTERFACES_IMAGINABLE. Can you even imagine a system with 50 (or > > 100?) ethernet interfaces? How about an application that needs more than > > 256K (showing my age with that one... %)? > > Yes, you're right, it is changeable, but it's less the number of > interfaces than the value of the indexes. The interface implies that > there will never be an interface with index 0, since if_nametoindex > returns 0 to indicate no such interface, but what's to prevent interface > indexes to be something other than 1, 2, 3, 4? They don't happen to be at > the moment, but if some enterprising kernel guy decides to randomize them > for some cute reason, this approach won't work. Agreed. I can't find any docs explaining what indexes are legal or their order. I guess the reality is that it isn't specified. The function does seem to be provided by libc. And so the diff must be in the implementations of that. Is there any precedent in Wine of making a runtime decision based on the c library? Would you be OK with a patch that uses if_indextoname() only in the special case of glibc-2.2.93 (I believe that's the RH8 libc), but if_nameindex() otherwise? - mo
Re: user: fix DrawTextExA/W on empty strings.
From: "Rein Klazes" <[EMAIL PROTECTED]> > Wrong, look again. You must be kidding. Care to explain how 'stmt' can ever be executed in: ... if (A || B) return; if (B) stmt; ... -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: user: fix DrawTextExA/W on empty strings.
On Wed, 25 Jan 2006 07:49:57 -0800 (PST), you wrote:
>Hi Rein,
>
>-if (!str) return 0;
>+if (!str || count == 0) return 0;
> if (count == -1) count = strlenW(str);
>-if (count == 0) return 0;
>+if (count == 0) {
>+if( flags & DT_CALCRECT) {
>+rect->right = rect->left;
>+rect->bottom = rect->top;
>+}
>+return 0;
>+}
>
>This block will never be reached because of the if (!str || count == 0)
>test above.
Wrong, look again.
It can be coded a little bit more efficiently though. I will make a
different patch.
Rein.
Rein.
Re: HW address w/o connection in iphlpapi
> > Although I don't like the idea of predefined limits :) I'll probably > > Me neither, which is why I used that prominent macro > MOST_INTERFACES_IMAGINABLE. Can you even imagine a system with 50 (or > 100?) ethernet interfaces? How about an application that needs more than > 256K (showing my age with that one... %)? Yes, you're right, it is changeable, but it's less the number of interfaces than the value of the indexes. The interface implies that there will never be an interface with index 0, since if_nametoindex returns 0 to indicate no such interface, but what's to prevent interface indexes to be something other than 1, 2, 3, 4? They don't happen to be at the moment, but if some enterprising kernel guy decides to randomize them for some cute reason, this approach won't work. > Well... that's not too thrilling since it doesn't actually fix the > problem I found. Yep, that's the other side of the coin: your approach works on all known systems, whereas mine only works more often than the SIOCGIFCONF approach. > Maybe we need to drill down into which systems if_nameindex works and > doesn't work with and have alternate versions of enumerateInterfaces > based on that. I have a FC4 system and I'll see how it behaves and let > you know. ... mo Yeah, maybe so. Portability always sucks, doesn't it? --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: HW address w/o connection in iphlpapi
On Tue, 2006-01-24 at 21:44 -0800, Juan Lang wrote: > > Right. if_nameindex does not return eth0 if I boot up without an > > ethernet connection. Maybe this is a system dependent thing? > > I am running on a RH8 based system. > > Or a libc thing? I'm running on FC2. > > > The if_nameindex code looked a little nicer, but a loop on > > if_indextoname() is not so bad. > > Although I don't like the idea of predefined limits :) I'll probably Me neither, which is why I used that prominent macro MOST_INTERFACES_IMAGINABLE. Can you even imagine a system with 50 (or 100?) ethernet interfaces? How about an application that needs more than 256K (showing my age with that one... %)? > submit a patch based on if_nameindex in the meantime, hopefully tomorrow Well... that's not too thrilling since it doesn't actually fix the problem I found. Maybe we need to drill down into which systems if_nameindex works and doesn't work with and have alternate versions of enumerateInterfaces based on that. I have a FC4 system and I'll see how it behaves and let you know. ... mo
commdlg patch
Hi!
Here is quick&dirty (TM :) patch (against wine-0.9.6) that changes
explorer-like Open/Save file dialogs to be more 3.11-like dialog/Windows
compatible:
1) set view window control id to 1121
2) set inner list window control id to 1 instead of 2000 (anyone know
why 2000 was chosen?)
This patch is really not very good because of my 1) implementation, but
it fixes Macromedia Director cast import!
I've done 1) by placing SetWindowLong(hwndView,GWLP_ID, lst2) after each
IShellBrowser_BrowseObject call. Better approach is to set view vindow's
control id inside of IShellBrowser_BrowseObject but I don't sure if it safe.
Regards,
Andrey Turkin.
diff -cr wine-0.9.6/dlls/commdlg/filedlg.c wine-0.9.6p/dlls/commdlg/filedlg.c
*** wine-0.9.6/dlls/commdlg/filedlg.c 2006-01-19 17:13:54.0 +0300
--- wine-0.9.6p/dlls/commdlg/filedlg.c 2006-01-25 19:37:26.0 +0300
***
*** 1486,1491
--- 1486,1492
/* Browse to the initial directory */
IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser,pidlItemId,
SBSP_ABSOLUTE);
+ SetWindowLongA(fodInfos->ShellInfos.hwndView, GWLP_ID, lst2);
/* Free pidlItem memory */
COMDLG32_SHFree(pidlItemId);
***
*** 1997,2002
--- 1998,2004
if( ! COMDLG32_PIDL_ILIsEqual(pidlCurrent,
fodInfos->ShellInfos.pidlAbsCurrent))
{
IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser,
pidlCurrent, SBSP_ABSOLUTE);
+ SetWindowLongA(fodInfos->ShellInfos.hwndView, GWLP_ID, lst2);
}
else if( nOpenAction == ONOPEN_SEARCH )
{
***
*** 2260,2265
--- 2262,2268
NULL,
SBSP_PARENT)))
{
+ SetWindowLongA(fodInfos->ShellInfos.hwndView, GWLP_ID, lst2);
SendCustomDlgNotificationMessage(hwnd, CDN_FOLDERCHANGE);
return TRUE;
}
***
*** 2282,2287
--- 2285,2291
SHGetSpecialFolderLocation(0,CSIDL_DESKTOP,&pidl);
hres = IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser, pidl,
SBSP_ABSOLUTE);
+ SetWindowLongA(fodInfos->ShellInfos.hwndView, GWLP_ID, lst2);
SendCustomDlgNotificationMessage(hwnd, CDN_FOLDERCHANGE);
COMDLG32_SHFree(pidl);
return SUCCEEDED(hres);
***
*** 2758,2763
--- 2762,2768
tmpFolder->pidlItem,
SBSP_ABSOLUTE)))
{
+ SetWindowLongA(fodInfos->ShellInfos.hwndView, GWLP_ID, lst2);
SendCustomDlgNotificationMessage(hwnd, CDN_FOLDERCHANGE);
return TRUE;
}
***
*** 3435,3440
--- 3440,3446
' ','n','o','t',' ','e','x','i','s','t',0};
MessageBoxW( hwnd, notexist, fodInfos->title, MB_OK |
MB_ICONEXCLAMATION );
}
+ SetWindowLongA(fodInfos->ShellInfos.hwndView, GWLP_ID, lst2);
bBrowseSelFolder = TRUE;
SendCustomDlgNotificationMessage(hwnd,CDN_FOLDERCHANGE);
}
diff -cr wine-0.9.6/dlls/shell32/shlview.c wine-0.9.6p/dlls/shell32/shlview.c
*** wine-0.9.6/dlls/shell32/shlview.c 2006-01-19 17:14:17.0 +0300
--- wine-0.9.6p/dlls/shell32/shlview.c 2006-01-25 19:37:45.0 +0300
***
*** 146,152
#define IDM_VIEW_IDW(FCIDM_SHVIEWFIRST + 0x501)
#define IDM_MYFILEITEM (FCIDM_SHVIEWFIRST + 0x502)
! #define ID_LISTVIEW 2000
#define SHV_CHANGE_NOTIFY WM_USER + 0x
--- 146,152
#define IDM_VIEW_IDW(FCIDM_SHVIEWFIRST + 0x501)
#define IDM_MYFILEITEM (FCIDM_SHVIEWFIRST + 0x502)
! #define ID_LISTVIEW 1
#define SHV_CHANGE_NOTIFY WM_USER + 0x
Re: Problems with references to drive Z: in registry's User Shell Folders
On Wednesday 25 January 2006 17:36, Alexandre Julliard wrote: > Maybe what we should do is to always have the paths point into the c: > drive, and then play with symlinks at the Unix level to redirect > things to $HOME. This way it would keep working even if the drive > config is changed after the initial setup. For some reason I thought that by default wine isn't following symbolic links to directories, but that doesn't seem to be true any more. Is this option still available? Do we still have to consider this? I would go on to extend winecfg then, to support setting symbolic links for the "Desktop" and the "My Documents" folders. And add a command line option to set reasonable defaults in a GUI-less mode to be called from wineprefixcreate. Is it ok to rename winecfg's "Appearance" tab to "Desktop Integration" and put this stuff there? Bye, -- Michael Jung [EMAIL PROTECTED]
Re: wine and jack => segfault? / wine and OSS not working
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Pouech wrote:
> can you post a +winmm,+oss,+wave trace ?
A trace of wine using OSS-output driver and oss2jack:
trace:winmm:DllMain 0x7ec3 0x1 0x1
trace:winmm:WINMM_CreateIData Initialized IData (0x7eca68c0)
trace:winmm:MMDRV_Init ()
trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N);
trace:wave:OSS_DriverProc (, 0x7fdb7288, 0001, ,
)
trace:wave:OSS_drvLoad ()
trace:wave:OSS_WaveInit ()
trace:wave:OSS_WaveOutInit (0x7d59dac0) /dev/dsp
trace:wave:OSS_OpenDevice (0x7d59dac0,1,(nil),0,-1,-1,)
trace:wave:OSS_RawOpenDevice (0x7d59dac0,0)
trace:wave:OSS_RawOpenDevice open_access=O_WRONLY
err:wave:OSS_WaveOutInit open(/dev/mixer) failed (No such file or directory)
trace:wave:OSS_CloseDevice (0x7d59dac0)
trace:wave:OSS_WaveOutInit (0x7d59de80) /dev/dsp1
trace:wave:OSS_OpenDevice (0x7d59de80,1,(nil),0,-1,-1,)
trace:wave:OSS_WaveOutInit (0x7d59e240) /dev/dsp2
trace:wave:OSS_OpenDevice (0x7d59e240,1,(nil),0,-1,-1,)
trace:wave:OSS_WaveOutInit (0x7d59e600) /dev/dsp3
trace:wave:OSS_OpenDevice (0x7d59e600,1,(nil),0,-1,-1,)
trace:wave:OSS_WaveOutInit (0x7d59e9c0) /dev/dsp4
trace:wave:OSS_OpenDevice (0x7d59e9c0,1,(nil),0,-1,-1,)
trace:wave:OSS_WaveOutInit (0x7d59ed80) /dev/dsp5
trace:wave:OSS_OpenDevice (0x7d59ed80,1,(nil),0,-1,-1,)
trace:wave:OSS_WaveInInit (0x7d59dac0) /dev/dsp
trace:wave:OSS_OpenDevice (0x7d59dac0,0,(nil),0,-1,-1,)
trace:wave:OSS_RawOpenDevice (0x7d59dac0,0)
trace:wave:OSS_RawOpenDevice open_access=O_RDONLY
err:wave:OSS_WaveInInit open(/dev/mixer) failed (No such file or directory)
trace:wave:OSS_CloseDevice (0x7d59dac0)
trace:wave:OSS_WaveInInit (0x7d59de80) /dev/dsp1
trace:wave:OSS_OpenDevice (0x7d59de80,0,(nil),0,-1,-1,)
trace:wave:OSS_WaveInInit (0x7d59e240) /dev/dsp2
trace:wave:OSS_OpenDevice (0x7d59e240,0,(nil),0,-1,-1,)
trace:wave:OSS_WaveInInit (0x7d59e600) /dev/dsp3
trace:wave:OSS_OpenDevice (0x7d59e600,0,(nil),0,-1,-1,)
trace:wave:OSS_WaveInInit (0x7d59e9c0) /dev/dsp4
trace:wave:OSS_OpenDevice (0x7d59e9c0,0,(nil),0,-1,-1,)
trace:wave:OSS_WaveInInit (0x7d59ed80) /dev/dsp5
trace:wave:OSS_OpenDevice (0x7d59ed80,0,(nil),0,-1,-1,)
trace:wave:OSS_WaveFullDuplexInit (0x7d59dac0) /dev/dsp
trace:wave:OSS_OpenDevice (0x7d59dac0,2,(nil),0,-1,-1,)
trace:wave:OSS_RawOpenDevice (0x7d59dac0,0)
trace:wave:OSS_RawOpenDevice open_access=O_RDWR
trace:wave:OSS_WaveFullDuplexInit
trace:wave:OSS_Info Formats=0010 ( AFMT_S16_LE )
trace:wave:OSS_Info Caps=3100
trace:wave:OSS_Info Revision: 0
trace:wave:OSS_Info Duplex: true
trace:wave:OSS_Info Realtime: false
trace:wave:OSS_Info Batch: false
trace:wave:OSS_Info Coproc: false
trace:wave:OSS_Info Trigger: true
trace:wave:OSS_Info Mmap: true
trace:wave:OSS_Info Multi: false
trace:wave:OSS_Info Bind: false
trace:wave:OSS_WaveFullDuplexInit DSP_SAMPLESIZE: rc=0 returned 0x10 for 0x8
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 96000 for
96000x16x1
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 48000 for
48000x16x1
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 44100 for
44100x16x1
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 22050 for
22050x16x1
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 11025 for
11025x16x1
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 96000 for
96000x16x2
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 48000 for
48000x16x2
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 44100 for
44100x16x2
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 22050 for
22050x16x2
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 11025 for
11025x16x2
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 96000 for
96000x16x3
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 48000 for
48000x16x3
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 44100 for
44100x16x3
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 22050 for
22050x16x3
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 11025 for
11025x16x3
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 96000 for
96000x16x4
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 48000 for
48000x16x4
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 44100 for
44100x16x4
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 22050 for
22050x16x4
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 11025 for
11025x16x4
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 96000 for
96000x16x5
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 48000 for
48000x16x5
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 44100 for
44100x16x5
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 22050 for
22050x16x5
trace:wave:OSS_WaveFullDuplexInit DSP_SPEED: rc=0 returned 1102
Re: Fwd: Re: Fwd: MBR was destroyed
> >> I was part of the disk group when my MBR was overwritten because I'd > >> been doing some work on the > >> drives and don't like sudo. Isn't it still a bug in wine that the MBR > >> was overwritten in the first > >> place, even if I'm in the disks group or running as root? If sudo is too much pain (and it must be since I have never really used it), just do $ su - # I guess Oliver got what he had asked for :( Wine bug nothwithstanding ;) > > Yes of course that's a bug in Wine. But what I meant is that the > > security model of Linux if correctly applied (i.e. people don't have > > rights to make things they are not supposed to do) would prevent such > > things to happen. > > So is the conclusion that users need to set up a special new user with > super restrictive rights to protect the system from bugs in wine?! My > confidence in wine has just taken a knock. Nope. I don't think that any decent distribution comes with world-writable raw hard drive devices. Even if "world writable" really means "everyone is in the group that has write rights". My FC4 system (hand upgraded through the ages from RH7, through everything in between) sets the raw hard drive devices with read only for disk group, and no users are in that group anyway. I'm puzzled as to what distribution would have user-writeable raw devices. I'd bet that someone somewhere messed things up for the users that were affected by that problem. The "super restrictive" rights that you're talking about are *default* on every self-respecting distro. It actually takes some work to change them. Cheers, Kuba PS. Just in case: I don't buy the argument that having access to cd burner requires such hacks. Either manually set hdwhatever to be writeable by you, or (on udev systems) change udev device permissions in relevant config files.
Re: Problems with references to drive Z: in registry's User Shell Folders
> Maybe what we should do is to always have the paths point into the c: > drive, and then play with symlinks at the Unix level to redirect > things to $HOME. This way it would keep working even if the drive > config is changed after the initial setup. I like this suggestion, though I'm hoping someone else will code it :) --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Problems with references to drive Z: in registry's User Shell Folders
Juan Lang <[EMAIL PROTECTED]> writes: > I'm of the opinion that all this fancy CSIDL_PERSONAL mapping doesn't > belong in shell32, even though I put it there. shell32 should default to > creating paths that are part of the profiles directory if nothing else > exists, since the shell won't work without them. But creating > Linux-environment-friendly defaults should perhaps go in wineprefixcreate. > I actually rather liked the idea of putting it in winecfg, and launching > winecfg in a GUI-less mode from wineprefixcreate. The advantage is that > the drive mappings and shell folder creation would be in the same app, and > so would have some hope of staying consistent. Maybe what we should do is to always have the paths point into the c: drive, and then play with symlinks at the Unix level to redirect things to $HOME. This way it would keep working even if the drive config is changed after the initial setup. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Global hooks problems (WH_MOUSE_LL)
On Tue, 2006-01-24 at 23:50 -0700, Vitaliy Margolen wrote: > Attached is the small program to test part of this. Fixing problems (1) & > (2) made it work. But it still not enough for the game (for some reason). Vitaliy, could you transform hook_test.c to an appropriate Wine test suite while leaving hook.dll a PE dll with all the ok()s which show what's wrong with current implementation? -- Dmitry.
Re: Problems with references to drive Z: in registry's User Shell Folders
Hey Juan, On Wednesday 25 January 2006 17:03, you wrote: > > I'm proposing to add two more environment variables: %PERSONAL%, > > which would be expanded to the DOS path corresponding to $HOME if > > this exists, or to %USERPROFILE%\\My Documents if not (with "My > > Documents" resource based, of course). And %DESKTOP%, which would > > be expanded to DOS_PATH_OF($HOME)\\Desktop if existent and to > > %USERPROFILE%\\Desktop, if not. > > So the environment variable expansion would be based on shell32? Ouch. I > don't think that'll fly. Just submitted a patch for the %DESKTOP% case. Could you have a look at it and tell me what you think? Are you afraid of name clashes? Bye, -- Michael Jung [EMAIL PROTECTED]
Re: Problems with references to drive Z: in registry's User Shell Folders
> when shell32.dll is registered during wineprefixcreate, it puts a > lot of paths based on Z:\ in HKLM/HKCU > Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User > Shell Folders. This is due to resolving CIDL_PERSONAL to the DOS > path corresponding to $HOME. > > If people remove the Z: drive afterwards, this leads to a lot > problems (One being that the Desktop shellfolder won't initialize > any more, which breaks the complete shell namespace and thus the file > dialogs). Yeah, that is painful. > I'm proposing to add two more environment variables: %PERSONAL%, > which would be expanded to the DOS path corresponding to $HOME if > this exists, or to %USERPROFILE%\\My Documents if not (with "My > Documents" resource based, of course). And %DESKTOP%, which would > be expanded to DOS_PATH_OF($HOME)\\Desktop if existent and to > %USERPROFILE%\\Desktop, if not. So the environment variable expansion would be based on shell32? Ouch. I don't think that'll fly. I'm of the opinion that all this fancy CSIDL_PERSONAL mapping doesn't belong in shell32, even though I put it there. shell32 should default to creating paths that are part of the profiles directory if nothing else exists, since the shell won't work without them. But creating Linux-environment-friendly defaults should perhaps go in wineprefixcreate. I actually rather liked the idea of putting it in winecfg, and launching winecfg in a GUI-less mode from wineprefixcreate. The advantage is that the drive mappings and shell folder creation would be in the same app, and so would have some hope of staying consistent. If a user breaks it through direct registry manipulation, his fault. If she breaks it through normal use of our tools, our fault. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: user: fix DrawTextExA/W on empty strings.
Hi Rein,
-if (!str) return 0;
+if (!str || count == 0) return 0;
if (count == -1) count = strlenW(str);
-if (count == 0) return 0;
+if (count == 0) {
+if( flags & DT_CALCRECT) {
+rect->right = rect->left;
+rect->bottom = rect->top;
+}
+return 0;
+}
This block will never be reached because of the if (!str || count == 0)
test above.
--Juan
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Can't compile with vc7: oleauto.h(229) : error C2719: 'function-parameter': formal parameter with __declspec(align('8')) won't be aligned
Dan Kegel <[EMAIL PROTECTED]> writes:
> A UCLA student trying to compile wine conformance tests on Windows
> ran into this:
>
>> [Compiling wine tests with VC7 or
>> the server 2003 sdk gets] this error when compiling.
>>
>> ..\..\..\include\oleauto.h(229) : error C2719: 'function-parameter':
>> formal parameter with __declspec(align('8')) won't be aligned
>
> (See http://msdn2.microsoft.com/en-us/library/373ak2y1.aspx )
>
> Examining oleauto.h line 229, I saw the bad parameter was
> of type DOUBLE.
> I then went looking for the typedef for DOUBLE:
> ~/wine/include$ grep 'typedef.*DOUBLE' *.h
> The interesting hit was:
> wtypes.h:typedef double DECLSPEC_ALIGN(8) DOUBLE;
>
> The patch that introduced the change was
> http://www.winehq.com/hypermail/wine-cvs/2004/05/0027.html
>
> I told him to try replacing DOUBLE and DATE with double
> and date in the formal parameters in oleauto.h
> for now. Is that generally the right thing to do?
I committed a change to add a #ifdef MSVC around that typedef,
hopefully that will work for you.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: user32: make menu tests pass on Win 9x/ME -- RESENT
Rein Klazes <[EMAIL PROTECTED]> writes: > Changelog: > dlls/user : menu.c > dlls/user/tests : menu.c > > - make menu tests pass on Win9x/ME; > - rename the macro IS_STRING_ITEM to IS_STRING_ITEM_ONLY, which better > reflects what it is doing: absence of other item type flags. You should not check the Windows version, you should only check the actual behavior. Also I think IS_STRING_ITEM is fine, there's no reason to add _ONLY since there's no other macro that would do a less specific test. -- Alexandre Julliard [EMAIL PROTECTED]
Re: CVS build error
On Wed, Jan 25, 2006 at 02:37:09PM +0100, Peter Åstrand wrote: > > I can't build the CVS version anymore, I get: > > gcc -g -O2 -o widl client.o hash.o header.o proxy.o server.o typegen.o > typelib.o utils.o widl.o write_msft.o parser.tab.o lex.yy.o -L../../libs > -lwpp -lwine_port -lfl > ../../libs/libwpp.a(lex.yy.o)(.text+0x624): In function > `_yy_dummy_uses_of_static_functions_b2f4_517d_02ff_b30c_3e5a_47d7_aaa3_3b5d_': > /home/peter/wine/libs/wpp/lex.yy.c:3357: multiple definition of > `_yy_dummy_uses_of_static_functions_b2f4_517d_02ff_b30c_3e5a_47d7_aaa3_3b5d_' > lex.yy.o(.text+0x58c):/home/peter/wine/tools/widl/lex.yy.c:1796: first > defined here > collect2: ld returned 1 exit status > make[2]: *** [widl] Error 1 > make[2]: Leaving directory `/home/peter/wine/tools/widl' > > Any ideas? It's a bug in FC4's flex that's now been fixed. Update to http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/flex-2.5.4a-36.fc4.i386.rpm Huw. -- Huw Davies [EMAIL PROTECTED]
CVS build error
I can't build the CVS version anymore, I get: gcc -g -O2 -o widl client.o hash.o header.o proxy.o server.o typegen.o typelib.o utils.o widl.o write_msft.o parser.tab.o lex.yy.o -L../../libs -lwpp -lwine_port -lfl ../../libs/libwpp.a(lex.yy.o)(.text+0x624): In function `_yy_dummy_uses_of_static_functions_b2f4_517d_02ff_b30c_3e5a_47d7_aaa3_3b5d_': /home/peter/wine/libs/wpp/lex.yy.c:3357: multiple definition of `_yy_dummy_uses_of_static_functions_b2f4_517d_02ff_b30c_3e5a_47d7_aaa3_3b5d_' lex.yy.o(.text+0x58c):/home/peter/wine/tools/widl/lex.yy.c:1796: first defined here collect2: ld returned 1 exit status make[2]: *** [widl] Error 1 make[2]: Leaving directory `/home/peter/wine/tools/widl' Any ideas? -- Peter Åstrand ThinLinc Chief Developer Cendio www.cendio.se Teknikringen 3 583 30 LinköpingPhone: +46-13-21 46 00
Re: d3d8: CreateDevice should try the parent if the current window fails
On Tue, Jan 24, 2006 at 08:36:15PM +0100, H. Verbeet wrote: > On 24/01/06, Jan Zerebecki <[EMAIL PROTECTED]> wrote: > > Changelog: > > d3d8: CreateDevice should try the parent if the current window fails > > because it doesn't have the property __wine_x11_whole_window . > > Fixes bug #4341 . > Does that happen in wined3d as well? If so, it's probably usefull to > fix wined3d as well, considering the idea is to make d3d8 use wined3d > eventually. I guess as it has similar code: grep 'GetPropA\(.*"__wine_x11_whole_window"' dlls/wined3d/* http://source.winehq.org/source/dlls/wined3d/device.c?v=wine-0.9.6#L1193 http://source.winehq.org/source/dlls/wined3d/directx.c?v=wine-0.9.6#L91 http://source.winehq.org/source/dlls/wined3d/swapchain.c?v=wine-0.9.6#L164 There are three locations and I have no d3d9 stuff that exposes the exact same bug. So if nobody else checks/fixes it in wined3d, I'll just wait till either the d3d8 on wined3d stuff is in origin or has a git repository and then test again. Jan
RE: Global hooks problems (WH_MOUSE_LL)
Vitaliy Margolen [EMAIL PROTECTED] wrote: > So my question is to anyone who knows. What is the proper way > to deliver > these messages to global hooks that are in a different thread/process? Just an observation I did in a Windows program running under WinXP. Not sure if this is related somehow but it seems quite like the opposite of what you describe here although with windows message hooks. I had a program that was hooking window messages for a particular window. When using SendMessage from the same thread as in which the Windows message loop was running (doesn't make much sense of course but it was just for testing purposes) I could not receive any events above WM_USER, lower events did seem to get received properly though. When placing SendMessage in a different thread the events did come through. Not exactly sure yet what this is all about but message handling and especially hooking in Windows for sure can be a tricky business. Rolf Kalbermatter
Re: wine and jack => segfault? / wine and OSS not working
On Mon, 23 Jan 2006, Joachim Förster wrote: [...] some days ago I sent some mails to the wine-users list. My problem: the JACK output driver of wine does not work => wine segfaults; and the OSS output driver does not work, too. Windows Media Player (used for testing) says, it cannot find the audio hardware. I have read on the wine-devel list that Jack >=1.0 was not binary compatible with older version that winejack was designed for. Could that be the reason why winejack segfaults? Did you try compiling Wine yourself on your system? -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.
Problems with references to drive Z: in registry's User Shell Folders
Hi, when shell32.dll is registered during wineprefixcreate, it puts a lot of paths based on Z:\ in HKLM/HKCU Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders. This is due to resolving CIDL_PERSONAL to the DOS path corresponding to $HOME. If people remove the Z: drive afterwards, this leads to a lot problems (One being that the Desktop shellfolder won't initialize any more, which breaks the complete shell namespace and thus the file dialogs). I'm proposing to add two more environment variables: %PERSONAL%, which would be expanded to the DOS path corresponding to $HOME if this exists, or to %USERPROFILE%\\My Documents if not (with "My Documents" resource based, of course). And %DESKTOP%, which would be expanded to DOS_PATH_OF($HOME)\\Desktop if existent and to %USERPROFILE%\\Desktop, if not. Does someone see a problem with this approach? Bye, -- Michael Jung [EMAIL PROTECTED]
