Re: Some considerations about the Wine FUSE project for GSoC
On Monday 31 March 2008 16:08:00 Kai Blin wrote: On Monday 31 March 2008 15:30:17 Marc Andre Tanner wrote: First, I haven't yet applied for the project mainly because i will probably not be able to work full time on a GSoC project due to real life issues (part time job, family related things etc). On the other hand I doubt that it will require ~3 months to implement, I have done my prototype over more or less a weekend. That's why there's more than one FUSE file systems on the list ;) I miss the technical discussion on how the problem should be solved. I think the idea of keeping the original filename in an extended attribute and storing everything in lower case is a pretty good one. Andrew Tridgell also listed it on one of his slides from WineConf05 [1]. The tricky part is convincing Alexandre Julliard, as always when working on Wine. I prototyped something and thought this way I would at least get some feedback (after all Talk is cheap. Show me the code. is common practice in the open source world). But this wasn't really the case, so i am still wondering what should be done differently? Whoops, I didn't see that url. Sorry, but things were a bit busy recently. I'll give that a whirl later today. I'm seeing some funny behaviour in a directory containing the files foo.txt, Foo.txt and bAr.tXt After mounting, I can only see a foo.txt in the directory, containing the Foo.txt contents. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: shell32: Handle a few cases in FO_COPY that arise from not double-NULL terminating the input
James Hawkins wrote: Hi, Fix for bug 9809. Changelog: * Handle a few cases in FO_COPY that arise from not double-NULL terminating the input. dlls/shell32/shlfileop.c | 11 +++- dlls/shell32/tests/shlfileop.c | 122 2 files changed, 130 insertions(+), 3 deletions(-) Hi James, +/* no double-NULL terminator for pTo */ +memset(to, 'a', MAX_PATH); +lstrcpyA(to, two.txt); +shfo.pFrom = one.txt\0; +shfo.pTo = to; +shfo.fFlags = FOF_NOCONFIRMATION | FOF_SILENT | FOF_NOERRORUI; +retval = SHFileOperation(shfo); +ok(retval == ERROR_SUCCESS, Expected ERROR_SUCCESS, got %d\n, retval); +ok(DeleteFileA(one.txt), Expected file to exist\n); +ok(DeleteFileA(two.txt), Expected file to exist\n); + +createTestFile(one.txt); + +/* no FOF_MULTIDESTFILES, two files in pTo */ +shfo.pFrom = one.txt\0; +shfo.pTo = two.txt\0three.txt\0; +shfo.fFlags = FOF_NOCONFIRMATION | FOF_SILENT | FOF_NOERRORUI; +retval = SHFileOperation(shfo); +ok(retval == ERROR_SUCCESS, Expected ERROR_SUCCESS, got %d\n, retval); +ok(DeleteFileA(one.txt), Expected file to exist\n); +ok(DeleteFileA(two.txt), Expected file to exist\n); + +createTestFile(one.txt); + +/* no double-NULL terminator for pTo */ +memset(to, 'a', MAX_PATH); +lstrcpyA(to, two.txt); +shfo.pFrom = one.txt\0; +shfo.pTo = to; +shfo.fFlags = FOF_NOCONFIRMATION | FOF_SILENT | FOF_NOERRORUI; +retval = SHFileOperation(shfo); +ok(retval == ERROR_SUCCESS, Expected ERROR_SUCCESS, got %d\n, retval); +ok(DeleteFileA(one.txt), Expected file to exist\n); +ok(DeleteFileA(two.txt), Expected file to exist\n); Isn't the last test the same as the first (in the above piece of code) ? -- Cheers, Paul.
Minor regression introduced in user32
There is a regression introduced into the git tree that is causing some minor issues with Anarchy Online atleast(should be other applications affected aswell). On login, if you press enter instead of pushing Login a box will come up stating You must select a charactername before playing! [OK], this is before checking if the password is correct, or actually logging in to the account. I have never seen this box in the 2.5 years I've been playing Anarchy, so I can only speculate it's trying to select a character without actually having one selected in the drop-down box(ie. Sending the enter twice to the application). I bisected down to the following commit: # ~/tmp/wine-git $ git bisect good 41ea8f0e8a6fab93fa08da16ecc24260dbad327c is first bad commit commit 41ea8f0e8a6fab93fa08da16ecc24260dbad327c Author: Lei Zhang [EMAIL PROTECTED] Date: Tue Mar 25 19:09:38 2008 -0700 user32: Tweak how the edit control handles WM_GETDLGCODE. :04 04 5583dc91d4f658340fcab6169c5be12b18c5d862 114715be44f79ddf45a9c61a01b90ee624504c1a M dlls I didn't want to file a bug-report on it, due to it beeing in the current git, and 0.9.58 is ok, and my knowledge on this part of wine is rather limited. - Kolbjørn Fredheim You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com
Re: Minor regression introduced in user32
Kolbjørn Fredheim [EMAIL PROTECTED] wrote: I didn't want to file a bug-report on it, due to it beeing in the current git, and 0.9.58 is ok, and my knowledge on this part of wine is rather limited. This is not an appropriate place to report the bugs. Also please search the bugzilla first: #12319 -- Dmitry.
Re: imm: Keep track of context associations between HWND and HIMC
Aric Stewart [EMAIL PROTECTED] writes: It would be but I could not find evidence that such a property existed for all windows in Window. If you are proposing a wine internal property then it would work well. Sure, a Wine internal property would be fine. -- Alexandre Julliard [EMAIL PROTECTED]
Re: mshtml: Added registry configuration to allow using Active Script engine for JavaScript scripts.
Jacek Caban [EMAIL PROTECTED] writes:
+static const WCHAR key_nameW[] =
+{'S','o','f','t','w','a','r','e',
+ '\\','W','i','n','e',
+ '\\','M','S','H','T','M','L',
+ '\\','S','c','r','i','p','t','O','v','e','r','r','i','d','e','s',0};
+
+/* @@ Wine registry key: HKCU\Software\Wine\MSHTML\ScriptOverrides */
+res = RegOpenKeyW(HKEY_CURRENT_USER, key_nameW, hkey);
+if(res != ERROR_SUCCESS)
+return ret;
Why do we need a configuration option for this? When would a user want
to change it?
--
Alexandre Julliard
[EMAIL PROTECTED]
How can i bypass my bug?
Hi! Some time ago i fille din a bug report because a game (The Sims : Pet Stories) couldn't lanch, after some mails the problem was that Wine doesn't gave vertex shaders, is there anything i can do to have this game running on my linux box? The bug has been reported as duplicate, but her's the correct one: http://bugs.winehq.org/show_bug.cgi?id=8051 Is there any way t have the game running (vertex sharders emulation running?), by adding dlls maybe, installing DirectX and disable some dlls? Anything? Thanks, kind regards!
Nice feature?
Hello! I have a little proposition for Wine 1.0! Why not creating an error dialog when a dll is missing, it would help a lot of users! For example there's a dialog to install geck, why not a dialog that simply says you have to add a dll in the correct directory?
Re: How can i bypass my bug?
Hi! Some time ago i fille din a bug report because a game (The Sims : Pet Stories) couldn't lanch, after some mails the problem was that Wine doesn't gave vertex shaders, is there anything i can do to have this game running on my linux box? The bug has been reported as duplicate, but her's the correct one: http://bugs.winehq.org/show_bug.cgi?id=8051 Is there any way t have the game running (vertex sharders emulation running?), by adding dlls maybe, installing DirectX and disable some dlls? Anything? Thanks, kind regards! Easy buy a simple videocard with vertex shader support we offer it on any card equal or better to a geforcefx / radeon 9500. Roderick
Re: winex11.drv: Connect to XIM server dynamically. [take 2]
Kusanagi Kouichi [EMAIL PROTECTED] writes: + +if (data-xic) +return data-xic; + +xim = x11drv_thread_data()-xim; +if (!xim) +return NULL; + +return X11DRV_CreateIC(xim, data-whole_window, data-xic); You shouldn't store a pointer to an internal field of the win_data structure, that makes things hard to follow. You should store win_data or hwnd in the pointer field and dereference it in the callback. @@ -651,7 +651,10 @@ struct x11drv_thread_data *x11drv_init_thread_data(void) if (TRACE_ON(synchronous)) XSynchronize( data-display, True ); wine_tsx11_unlock(); -if (use_xim !(data-xim = X11DRV_SetupXIM( data-display, input_style ))) +data-xim = NULL; +if (use_xim +!XRegisterIMInstantiateCallback(data-display, NULL, NULL, NULL, +X11DRV_SetupXIM, (XPointer)data-xim)) The XRegisterIMInstantiateCallback should go in xim.c, the initialization code in x11drv_main.c shouldn't need to know about such implementation details. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [2/5] setupapi: Changing pointers on SP_DEVINFO_DATA
Alexander Morozov [EMAIL PROTECTED] writes: SETUPDI_AddDeviceToSet: changing pointers on SP_DEVINFO_DATA after allocating new memory block for their array We shouldn't have to do that sort of thing. The data structure should be fixed to store pointers that don't have to be moved around. -- Alexandre Julliard [EMAIL PROTECTED]
Pulse Audio -- Wine should have instructions on this web site
This site purports to give instructions on how to run certain applications, including Skype (which is 32-bit). I think wine should have instructions here too. http://www.pulseaudio.org/wiki/PerfectSetup It doesn't look like pulseaudio is going away from Ubuntu anytime soon. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453
Re: Recent imm changes triggered widespread valgrind errors?
Thanks for the heads up, With Alexandre's latest fix to the code do the valgrind errors persist? -aric Dan Kegel wrote: Aric, can you have a look? Any call to CreateWindow now spews lots of Valgrind errors. For instance, http://kegel.com/wine/valgrind/logs-2008-04-01/vg-advpack_install-diff.txt contains: + Conditional jump or move depends on uninitialised value(s) +at RtlInitUnicodeString (unicode.h:212) +by LoadLibraryExW (module.c:924) +by LoadLibraryW (module.c:968) +by ImmCreateContext (imm.c:143) +by X11DRV_SetupXIM (xim.c:510) +by x11drv_init_thread_data (x11drv_main.c:654) +by X11DRV_SetWindowPos (x11drv.h:517) +by set_window_pos (winpos.c:1919) +by WIN_CreateWindowEx (win.c:1121) +by CreateWindowExW (win.c:1351) +by manage_desktop (desktop.c:224) +by WinMain (explorer.c:136) +by main (exe_main.c:48)
Re: How can i bypass my bug?
Am Mittwoch, 2. April 2008 13:12:58 schrieb Roderick Colenbrander: Easy buy a simple videocard with vertex shader support we offer it on any card equal or better to a geforcefx / radeon 9500. This game *needs* SW emulation - 2048 D3D vertex shader constants. A geforce 8 might do the job though
Re: WINEX11.DRV: workaround for unstable window state while handling MapNotify (fixes bug 12196)
Alex Villacís Lasso [EMAIL PROTECTED] writes: Is this patch incorrect? Nobody has commented on it, and it has not been applied either. The concept is OK, but the implementation needs more work since PropertyNotify is also triggered while waiting for the withdrawn state, and you don't want to send messages to the window at that point. I'm looking into it. -- Alexandre Julliard [EMAIL PROTECTED]
Any particular reason we are using printf in the shlwapi/istream tests?
Hi, Should these printf's be turned into trace/skip? -- Cheers, Paul.
Re: Any particular reason we are using printf in the shlwapi/istream tests?
Paul Vriens [EMAIL PROTECTED] writes: Should these printf's be turned into trace/skip? Yes. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Some considerations about the Wine FUSE project for GSoC
Kai Blin wrote: On Monday 31 March 2008 16:08:00 Kai Blin wrote: On Monday 31 March 2008 15:30:17 Marc Andre Tanner wrote: I prototyped something and thought this way I would at least get some feedback (after all Talk is cheap. Show me the code. is common practice in the open source world). But this wasn't really the case, so i am still wondering what should be done differently? Whoops, I didn't see that url. Sorry, but things were a bit busy recently. I'll give that a whirl later today. Thanks for testing btw. I'm seeing some funny behaviour in a directory containing the files foo.txt, Foo.txt and bAr.tXt After mounting, I can only see a foo.txt in the directory, That's intended, filenames which aren't all lower case are ignored. This makes sure that there won't be conflicts. Ideally you should start with an empty directory mount the fs and then untar your actual content in mountpoint. containing the Foo.txt contents. This would be a bug, are you really sure you are getting the contents of Foo.txt and not foo.txt? I ask because i can't reproduce it here. If so could you please compile in debug support make debug and then run ciopfs with option -d. This should print some debug information to stderr. Thanks, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: Recent imm changes triggered widespread valgrind errors?
On Wed, Apr 2, 2008 at 5:25 AM, Aric Stewart [EMAIL PROTECTED] wrote: Thanks for the heads up, With Alexandre's latest fix to the code do the valgrind errors persist? Things look rather better today.
Re: mshtml: Added registry configuration to allow using Active Script engine for JavaScript scripts.
Alexandre Julliard wrote:
Jacek Caban [EMAIL PROTECTED] writes:
+static const WCHAR key_nameW[] =
+{'S','o','f','t','w','a','r','e',
+ '\\','W','i','n','e',
+ '\\','M','S','H','T','M','L',
+
'\\','S','c','r','i','p','t','O','v','e','r','r','i','d','e','s',0};
+
+/* @@ Wine registry key: HKCU\Software\Wine\MSHTML\ScriptOverrides */
+res = RegOpenKeyW(HKEY_CURRENT_USER, key_nameW, hkey);
+if(res != ERROR_SUCCESS)
+return ret;
Why do we need a configuration option for this? When would a user want
to change it?
This is for IE-specific scripts in HTMLs. We currently use Gecko for
doing everything with scripts for us. It means that IE only pages won't
work mainly due to incompatibilities in DOM API. Even worse case are
apps that communicate with hosting apps via window.extern object. To
make them work we need to run script in a real Active Script engine.
What we can do is quite tricky, but it already works for other script
languages in current Git (well, not much more than Hello World scripts
work ATM, but I'm working on this). The problem is that in case of
JavaScript we have to choose if we want Gecko or our JavaScript engine.
There is no way to determine it automatically, so configurable option is
needed. I've chosen to use per URL configuration as it seems to be the
best way. Due to number of DOM API to be implemented and security issues
I don't think we'll ever make Active Script mode default and it's not
the goal, but when we'll have our own jscript.dll implementation
(currently one needs to use native version for tests), we may consider
some heuristics like using Active Script for c:/Program Files/Common
Files/* HTMLs.
Jacek
Re: Some considerations about the Wine FUSE project for GSoC
On Wednesday 02 April 2008 17:18:27 Marc Andre Tanner wrote: containing the Foo.txt contents. This would be a bug, are you really sure you are getting the contents of Foo.txt and not foo.txt? My bad, I must have misread. It's the contents of the lower case file. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Pulse Audio -- Wine should have instructions on this web site
I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control. Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect. ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use. Sorry for expanding the topic so much. On 4/2/08, Susan Cragin [EMAIL PROTECTED] wrote: This site purports to give instructions on how to run certain applications, including Skype (which is 32-bit). I think wine should have instructions here too. http://www.pulseaudio.org/wiki/PerfectSetup It doesn't look like pulseaudio is going away from Ubuntu anytime soon. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453
Re: Pulse Audio -- Wine should have instructions on this web site
On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins [EMAIL PROTECTED] wrote: I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control. Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect. ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use. Sorry for expanding the topic so much. On 4/2/08, Susan Cragin [EMAIL PROTECTED] wrote: This site purports to give instructions on how to run certain applications, including Skype (which is 32-bit). I think wine should have instructions here too. http://www.pulseaudio.org/wiki/PerfectSetup It doesn't look like pulseaudio is going away from Ubuntu anytime soon. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453 This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0.
Re: Pulse Audio -- Wine should have instructions on this web site
On Wed, Apr 2, 2008 at 1:05 PM, Austin English [EMAIL PROTECTED] wrote: On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins [EMAIL PROTECTED] wrote: I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control. Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect. ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use. Sorry for expanding the topic so much. On 4/2/08, Susan Cragin [EMAIL PROTECTED] wrote: This site purports to give instructions on how to run certain applications, including Skype (which is 32-bit). I think wine should have instructions here too. http://www.pulseaudio.org/wiki/PerfectSetup It doesn't look like pulseaudio is going away from Ubuntu anytime soon. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453 This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0. And I believe Julliard rejected the idea of adding a pulseaudio driver. -- James Hawkins
Re: [PATCH 4/7] widl: Support __fastcall and __pascal calling conventions.
On Wed, Apr 02, 2008 at 12:56:21PM +0100, Robert Shearman wrote:
@@ -186,13 +186,19 @@ static const struct keyword keywords[] = {
{FALSE, tFALSE},
{TRUE,tTRUE},
{__cdecl, tCDECL},
+ {__fastcall, tFASTCALL},
+ {__pascal,tPASCAL},
{__int64, tINT64},
{__stdcall, tSTDCALL},
__pascal should come after __int64.
Re: How can i bypass my bug?
I don't understand, it is a wine bug, not a hardware problem? I have a geforce 7600GT and knows it works, but don't have windows anymore... 2008/4/2, Stefan Dösinger [EMAIL PROTECTED]: Am Mittwoch, 2. April 2008 13:12:58 schrieb Roderick Colenbrander: Easy buy a simple videocard with vertex shader support we offer it on any card equal or better to a geforcefx / radeon 9500. This game *needs* SW emulation - 2048 D3D vertex shader constants. A geforce 8 might do the job though
Re: Pulse Audio -- Wine should have instructions on this web site
On Wed, Apr 2, 2008 at 1:52 PM, Michael Stefaniuc [EMAIL PROTECTED] wrote: James Hawkins wrote: On Wed, Apr 2, 2008 at 1:05 PM, Austin English [EMAIL PROTECTED] wrote: On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins [EMAIL PROTECTED] wrote: I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control. Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect. ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use. Sorry for expanding the topic so much. This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0. And I believe Julliard rejected the idea of adding a pulseaudio driver. Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment. I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant. No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers. -Julliard http://winehq.org/pipermail/wine-devel/2008-March/063755.html -- James Hawkins
Re: Pulse Audio -- Wine should have instructions on this web site
James Hawkins wrote: On Wed, Apr 2, 2008 at 1:05 PM, Austin English [EMAIL PROTECTED] wrote: On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins [EMAIL PROTECTED] wrote: I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control. Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect. ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use. Sorry for expanding the topic so much. This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0. And I believe Julliard rejected the idea of adding a pulseaudio driver. Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment. I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant. bye michael
Re: Pulse Audio -- Wine should have instructions on this web site
This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0. And I believe Julliard rejected the idea of adding a pulseaudio driver. Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment. I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant. No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers. -Julliard http://winehq.org/pipermail/wine-devel/2008-March/063755.html ... I also guess no one is stopping people from writing a pulseaudio driver. Its just that it needs to make certain criteria before inclusion, after we got burned with esound, arts, nas, etc etc etc etc. Ciao, Marcus
Re: Pulse Audio -- Wine should have instructions on this web site
Marcus Meissner wrote: ... I also guess no one is stopping people from writing a pulseaudio driver. Its just that it needs to make certain criteria before inclusion, after we got burned with esound, arts, nas, etc etc etc etc. Ciao, Marcus Correct. There is a pulse driver for Wine being worked on, but outside the Wine project (ie not us).
testing 3d graphics with vmware workstation 6.5 beta?
I just got an email about the next vmware workstation beta: Improved 3D graphics Support — Workstation 6.5 can now support DirectX9.0 accelerated 3D with shaders so you can run more applications inside your VM. Maybe this will help with running the 3d graphics test suite in virtual machines? http://communities.vmware.com/community/beta/workstation6.5
Re: Pulse Audio -- Wine should have instructions on this web site
James Hawkins wrote: On Wed, Apr 2, 2008 at 1:52 PM, Michael Stefaniuc [EMAIL PROTECTED] wrote: James Hawkins wrote: And I believe Julliard rejected the idea of adding a pulseaudio driver. Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment. I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant. No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers. -Julliard http://winehq.org/pipermail/wine-devel/2008-March/063755.html Right, forgot about that one. But I am still sure he would accept a perfect full featured and beautiful written pulseaudio driver. What he doesn't wants at all is wasting precious Wine developer time on creating one in his Wine git repository. And having it rot there because in 1-2 years all of todays pulseaudio proponents will complain how broken pulseaudio is and how much better this yet another audio system 2.0 is and why Wine _needs_ to implement that one. So if one of the proponents of pulseaudio for Wine would just go ahead and start writing one, for example on git.or.cz Alexandre wouldn't mind at all. Convincing the distributions to include the pulseaudio driver should be an easy selling especially for Fedora and Ubuntu who seem to move to pulseaudio will fix everything. bye michael who fixed the sound on his desktop by removing pulseaudio
Re: How can i bypass my bug?
Am Mittwoch, 2. April 2008 20:57:29 schrieb Warren Dumortier: I don't understand, it is a wine bug, not a hardware problem? I have a geforce 7600GT and knows it works, but don't have windows anymore... Correct, it is a Wine bug. A Geforce 8 might work around it though
Re: MinGW cross compilation fails for d3dx9_36/tests
On Fri, Mar 28, 2008 at 6:05 AM, John Klehm [EMAIL PROTECTED] wrote: Well let me know how this works for you. I'll refactor my script a bit later today but for right now you have to run this one after the winetest script, as this one counts on the environment that the Here's the refactored script [1]. With some inspiration from winetricks ;) Example uses: $crossbuild_tricks winetest $crossbuild_tricks d3d = builds d3d8,d3d9,wined3d, libwine $crossbuild_tricks test cabinet = use test verb for individual tests $crossbuild_tricks dll wintrust = use dll verb for individual dlls First release and I've tested it some, seems to work but let me know if it breaks for you. Regards, John [1] http://klehm.net/wine/crossbuild_tricks.sh
Re: Nice feature?
On Wed, Apr 2, 2008 at 4:45 AM, Warren Dumortier [EMAIL PROTECTED] wrote: Hello! I have a little proposition for Wine 1.0! Why not creating an error dialog when a dll is missing, it would help a lot of users! For example there's a dialog to install geck, why not a dialog that simply says you have to add a dll in the correct directory? When you say a missing dll, that could mean a few things. I'm assuming you mean the typical case of a dll that should have been redistributed with an app, but was not, and the application expects it to already be present. Or the case of a failing installer failing to copy all files? If so, these errors are already put out to stderr, like most other warnings.
Re: testing 3d graphics with vmware workstation 6.5 beta?
Am Mittwoch, 2. April 2008 20:51:40 schrieb Lei Zhang: I just got an email about the next vmware workstation beta: Improved 3D graphics Support — Workstation 6.5 can now support DirectX9.0 accelerated 3D with shaders so you can run more applications inside your VM. Maybe this will help with running the 3d graphics test suite in virtual machines? Just give it a try I'd say. I doubt they got the shader stuff right on the first try, even if they tested with DCT(which is not available any more)
Re: Pulse Audio -- Wine should have instructions on this web site
Michael Stefaniuc [EMAIL PROTECTED] writes: Right, forgot about that one. But I am still sure he would accept a perfect full featured and beautiful written pulseaudio driver. What he doesn't wants at all is wasting precious Wine developer time on creating one in his Wine git repository. And having it rot there because in 1-2 years all of todays pulseaudio proponents will complain how broken pulseaudio is and how much better this yet another audio system 2.0 is and why Wine _needs_ to implement that one. What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead. Once this is done and we have demonstrated that we can actually make one driver work 100% correctly, then we can consider adding another one. -- Alexandre Julliard [EMAIL PROTECTED]
New winetricks 20080402: new verbs dotnet20, win2k, flash, msls31; updated mono, liberation
Big news: as of today or so, wine doesn't need any patches to install the .net 2.0 runtime or run trivial .net 2.0 apps, so I've added a dotnet20 verb. No more futzing with recipes to try out simple .net 2 apps, huzzah! There are lots of other little changes, too: 20080402 r21 Added dotnet20, removed one kludge from dotnet11, added win2k verb, plus shorthand for winver=foo r20 Updated liberation fonts. 20080328 r19 Added flash. 20080326 r18 Fix i18n problem reported by Ricardo Cabral 20080321 r17 Added msls31 (seems to be needed by e-Sword) 20080317 r16 update mono12 to 1.2.9 ... As always, winetricks is downloadable from http://kegel.com/wine/winetricks and change history is at http://code.google.com/p/winezeug Thanks to the folks who keep feeding me improvements and suggestions! - Dan
Make test - opengl regression
Running on my virtualbox feisty vm, seems make test is making some progress: [EMAIL PROTECTED]:~/wine-git$ cat wine-0.9.58-439-g73bd68c.txt | grep 'make.*Error' make[2]: *** [exception.ok] Error 1 make[1]: *** [ntdll/tests/__test__] Error 2 make[2]: *** [opengl.ok] Error 1 make[1]: *** [opengl32/tests/__test__] Error 2 make[2]: *** [msg.ok] Error 24 make[1]: *** [user32/tests/__test__] Error 2 make: *** [dlls/__test__] Error 2 The visual.c's are skipping properly now for me, but there's a regression in opengl/opengl.c. ../../../tools/runtest -q -P wine -M opengl32.dll -T ../../.. -p opengl32_test.exe.so opengl.c touch opengl.ok err:wgl:X11DRV_wglCreateContext Cannot get FB Config for iPixelFormat 0, expect problems! opengl.c:248: Test failed: Unable to confirm DONTCARE behavior of unset pixelformatdescriptor flags err:wgl:X11DRV_SetPixelFormat Invalid operation on root_window opengl.c:323: Tests skipped: No suitable pixel formats found make: *** [opengl.ok] Error 1 I haven't ran a regression test yet, but if you want more logs or a regression test, let me know.
Re: msi: Remove tentative definition of static array with no size specifier
Andrew Talbot wrote: strictly, when the static storage specifier is applied, the size must be specified: static char ar[5]; /* tentative definition */ static char ar[5] = hello; /* actual definition */ Of course, the size need not be specified in the case of the actual definition, so the following is what I should have typed. static char a[] = hello; /* actual definition */ -- Andy.
Re: msi: Remove tentative definition of static array with no size specifier
On Wed, Apr 2, 2008 at 5:07 PM, Andrew Talbot [EMAIL PROTECTED] wrote: Whereas for a non-static array a tentative definition does not require a size to be specified, for example: char ar[];/* tentative definition */ char ar[] = hello; /* actual definition */ strictly, when the static storage specifier is applied, the size must be specified: static char ar[5]; /* tentative definition */ static char ar[5] = hello; /* actual definition */ This patch avoids using a magic number by moving the definition of an array and adding forward declarations for the functions affected, instead. -- Andy. --- Changelog: msi: Remove tentative declaration of static array with no size specifier. diff --git a/dlls/msi/action.c b/dlls/msi/action.c index 982c9f0..8cc36a0 100644 --- a/dlls/msi/action.c +++ b/dlls/msi/action.c @@ -47,6 +47,64 @@ WINE_DEFAULT_DEBUG_CHANNEL(msi); static UINT ACTION_ProcessExecSequence(MSIPACKAGE *package, BOOL UIran); static UINT ACTION_ProcessUISequence(MSIPACKAGE *package); static UINT ACTION_PerformActionSequence(MSIPACKAGE *package, UINT seq, BOOL UI); +static UINT ACTION_AllocateRegistrySpace( MSIPACKAGE *package ); +static UINT ACTION_BindImage( MSIPACKAGE *package ); +static UINT ACTION_CostFinalize(MSIPACKAGE *package); +static UINT ACTION_CostInitialize(MSIPACKAGE *package); +static UINT ACTION_CreateFolders(MSIPACKAGE *package); +static UINT ACTION_CreateShortcuts(MSIPACKAGE *package); +static UINT ACTION_DeleteServices( MSIPACKAGE *package ); +static UINT ACTION_ExecuteAction(MSIPACKAGE *package); +static UINT ACTION_FileCost(MSIPACKAGE *package); +static UINT ACTION_InstallExecute(MSIPACKAGE *package); +static UINT ACTION_InstallFinalize(MSIPACKAGE *package); +static UINT ACTION_InstallInitialize(MSIPACKAGE *package); +static UINT ACTION_InstallSFPCatalogFile( MSIPACKAGE *package ); +static UINT ACTION_InstallValidate(MSIPACKAGE *package); +static UINT ACTION_IsolateComponents( MSIPACKAGE *package ); +static UINT ACTION_LaunchConditions(MSIPACKAGE *package); +static UINT ACTION_MigrateFeatureStates( MSIPACKAGE *package ); +static UINT ACTION_MoveFiles( MSIPACKAGE *package ); +static UINT ACTION_MsiPublishAssemblies( MSIPACKAGE *package ); +static UINT ACTION_MsiUnpublishAssemblies( MSIPACKAGE *package ); +static UINT ACTION_InstallODBC( MSIPACKAGE *package ); +static UINT ACTION_InstallServices( MSIPACKAGE *package ); +static UINT ACTION_PatchFiles( MSIPACKAGE *package ); +static UINT ACTION_ProcessComponents(MSIPACKAGE *package); +static UINT ACTION_PublishComponents(MSIPACKAGE *package); +static UINT ACTION_PublishFeatures(MSIPACKAGE *package); +static UINT ACTION_PublishProduct(MSIPACKAGE *package); +static UINT ACTION_RegisterComPlus( MSIPACKAGE *package ); +static UINT ACTION_RegisterProduct(MSIPACKAGE *package); +static UINT ACTION_RegisterTypeLibraries(MSIPACKAGE *package); +static UINT ACTION_RegisterUser(MSIPACKAGE *package); +static UINT ACTION_RemoveDuplicateFiles( MSIPACKAGE *package ); +static UINT ACTION_RemoveEnvironmentStrings( MSIPACKAGE *package ); +static UINT ACTION_RemoveExistingProducts( MSIPACKAGE *package ); +static UINT ACTION_RemoveFolders( MSIPACKAGE *package ); +static UINT ACTION_RemoveIniValues( MSIPACKAGE *package ); +static UINT ACTION_RemoveODBC( MSIPACKAGE *package ); +static UINT ACTION_RemoveRegistryValues( MSIPACKAGE *package ); +static UINT ACTION_RemoveShortcuts( MSIPACKAGE *package ); +static UINT ACTION_ResolveSource(MSIPACKAGE* package); +static UINT ACTION_RMCCPSearch( MSIPACKAGE *package ); +static UINT ACTION_SelfRegModules(MSIPACKAGE *package); +static UINT ACTION_SelfUnregModules( MSIPACKAGE *package ); +static UINT ACTION_StartServices( MSIPACKAGE *package ); +static UINT ACTION_StopServices( MSIPACKAGE *package ); +static UINT ACTION_UnpublishComponents( MSIPACKAGE *package ); +static UINT ACTION_UnpublishFeatures(MSIPACKAGE *package); +static UINT ACTION_UnregisterClassInfo( MSIPACKAGE *package ); +static UINT ACTION_UnregisterComPlus( MSIPACKAGE *package ); +static UINT ACTION_UnregisterExtensionInfo( MSIPACKAGE *package ); +static UINT ACTION_UnregisterFonts( MSIPACKAGE *package ); +static UINT ACTION_UnregisterMIMEInfo( MSIPACKAGE *package ); +static UINT ACTION_UnregisterProgIdInfo( MSIPACKAGE *package ); +static UINT ACTION_UnregisterTypeLibraries( MSIPACKAGE *package ); +static UINT ACTION_ValidateProductID( MSIPACKAGE *package ); +static UINT ACTION_WriteEnvironmentStrings( MSIPACKAGE *package ); +static UINT ACTION_WriteIniValues(MSIPACKAGE *package); +static UINT ACTION_WriteRegistryValues(MSIPACKAGE *package); I object. Also, RFCs should be sent to wine-devel, not wine-patches. -- James Hawkins
Re: Pulse Audio -- Wine should have instructions on this web site
Hi Alexandre, 2008/4/2, Alexandre Julliard [EMAIL PROTECTED]: Michael Stefaniuc [EMAIL PROTECTED] writes: Right, forgot about that one. But I am still sure he would accept a perfect full featured and beautiful written pulseaudio driver. What he doesn't wants at all is wasting precious Wine developer time on creating one in his Wine git repository. And having it rot there because in 1-2 years all of todays pulseaudio proponents will complain how broken pulseaudio is and how much better this yet another audio system 2.0 is and why Wine _needs_ to implement that one. What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead. Once this is done and we have demonstrated that we can actually make one driver work 100% correctly, then we can consider adding another one. Apart from the horrible waveout playback code that was directly copied from wineoss, and to a lighter degree the wavein code is there anything seriously broken in winealsa? Nothing comes to mind at the moment. Cheers, Maarten.
Re: msi: Remove tentative definition of static array with no size specifier
James Hawkins wrote: I object. Also, RFCs should be sent to wine-devel, not wine-patches. I was submitting a patch with a prelude explaining why, not making a request for comment. But on what grounds are you objecting? -- Andy.
Re: msi: Remove tentative definition of static array with no size specifier
On Wed, Apr 2, 2008 at 5:19 PM, Andrew Talbot [EMAIL PROTECTED] wrote: James Hawkins wrote: I object. Also, RFCs should be sent to wine-devel, not wine-patches. I was submitting a patch with a prelude explaining why, not making a request for comment. But on what grounds are you objecting? It's ugly. What warning are you trying to fix? -- James Hawkins
Re: Pulse Audio -- Wine should have instructions on this web site
Alexandre Julliard wrote: Michael Stefaniuc [EMAIL PROTECTED] writes: Right, forgot about that one. But I am still sure he would accept a perfect full featured and beautiful written pulseaudio driver. What he doesn't wants at all is wasting precious Wine developer time on creating one in his Wine git repository. And having it rot there because in 1-2 years all of todays pulseaudio proponents will complain how broken pulseaudio is and how much better this yet another audio system 2.0 is and why Wine _needs_ to implement that one. What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead. Right but you _cannot_ force people to do that. If they just go ahead and setup a separate Wine repo they can work on pulseaudio all the day and nobody can stop them. That's the OSS reality and git makes that very easy to do. Once this is done and we have demonstrated that we can actually make one driver work 100% correctly, then we can consider adding another one. It is your tree and given the history the only sane approach for your (The Wine) git tree. But that's the centralized approach and I would love if people would start moving away from that. Compare Hey guys, pulseaudio is the uber cool must have audio system of the future. I went ahead and added a pulseaudio driver to Wine. Here is the link to my git tree. to Bitch bitch moan everything else sucks but pulseaudio bitch bitch so you guys go ahead and implement it in Wine. I prefer the first version but i probably listened to often to Linus about the advantages of git and the distributed development model. bye michael
Re: msi: Remove tentative definition of static array with no size specifier
James Hawkins wrote: It's ugly. What warning are you trying to fix? Although I imagine that gcc doesn't do anything particularly adverse as a result of the existing code, if the pedantic switch were applied it would cause a message of the following type to be generated. action.c:236: error: array size missing in ?StandardActions? I believe it is also likely to show up under lint-like tools and I believe it is actually an error, though compilers are not required to generate any message, apparently. I couldn't say whether the resultant behaviour is undefined, implemenation defined, or what. And I don't know whether gcc places any surplus baggage in any segment as a result. The fix was just to make the code correct and hence more portable. -- Andy.
Re: msi: Remove tentative definition of static array with no size specifier
James Hawkins wrote: That's fine, but it's not worth it to me, and I'm pretty sure Julliard won't accept it either. I understand and suspect you are right. Maybe I should have made an RFC rather than opting for trial by patch. :) Thanks for your comments. -- Andy.
Re: msi: Remove tentative definition of static array with no size specifier
On Wed, Apr 2, 2008 at 5:40 PM, Andrew Talbot [EMAIL PROTECTED] wrote: James Hawkins wrote: It's ugly. What warning are you trying to fix? Although I imagine that gcc doesn't do anything particularly adverse as a result of the existing code, if the pedantic switch were applied it would cause a message of the following type to be generated. action.c:236: error: array size missing in ?StandardActions? I believe it is also likely to show up under lint-like tools and I believe it is actually an error, though compilers are not required to generate any message, apparently. I couldn't say whether the resultant behaviour is undefined, implemenation defined, or what. And I don't know whether gcc places any surplus baggage in any segment as a result. The fix was just to make the code correct and hence more portable. That's fine, but it's not worth it to me, and I'm pretty sure Julliard won't accept it either. -- James Hawkins
Re: Pulse Audio -- Wine should have instructions on this web site
On Wednesday 02 April 2008 03:26:40 pm Michael Stefaniuc wrote: Alexandre Julliard wrote: What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead. Right but you _cannot_ force people to do that. If they just go ahead and setup a separate Wine repo they can work on pulseaudio all the day and nobody can stop them. That's the OSS reality and git makes that very easy to do. But that still doesn't make it The Right Thing to do. Who's to say PulseAudio will really stick around and continue to be useful? Phonon has a good chance of that, too (as it's backed by Trolltech/Qt, and is useable on several OSs). And I'm sure people said some of the same thing about aRts. But we know how that ended up. And it's not even like PA's main feature (software mixing) isn't available through ALSA (dmix). Sure it has some other features, but they're hardly something that Wine needs to make such a shift for (most apps have their own volume control, and people that need device hot-plugging can still get it through the ALSA-PulseAudio plugin; or even the OSS-PulseAudio plugin). I'm sure I'm not alone in feeling like we're getting jerked around with audio APIs in Linux (use OSS! no, use ESD! no, use ALSA! no, use PulseAudio!). IMO, we have to set down and just pick something.
Re: Pulse Audio -- Wine should have instructions on this web site
Am Mittwoch, 2. April 2008 17:08:06 schrieb Bryan Haskins: I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people wine is treated as one big audio blob. Pulse sees it as one thing. Isn't that a PulseAudio limitation? I am sure that Wine opens a new Alsa connection for each Windows application that uses sound. I don't know how PA groups the input, but it can surely find different Wine inputs from Alsa.
Re: [PATCH 4/7] widl: Support __fastcall and __pascal calling conventions.
On Wed, Apr 02, 2008 at 11:46:27AM -0700, Dan Hipschman wrote:
On Wed, Apr 02, 2008 at 12:56:21PM +0100, Robert Shearman wrote:
@@ -186,13 +186,19 @@ static const struct keyword keywords[] = {
{FALSE, tFALSE},
{TRUE,tTRUE},
{__cdecl, tCDECL},
+ {__fastcall, tFASTCALL},
+ {__pascal,tPASCAL},
{__int64, tINT64},
{__stdcall, tSTDCALL},
__pascal should come after __int64.
I sent a patch.
Re: [PATCH 04/10] wined3d: Add ENTER_GL/LEAVE_GL in IWineD3DSurfaceImpl_Release.
Perhaps the call to ActivateContext should be moved outside of the if block since there are other gl calls in the function. Then you could move the glDeleteRenderbuffers block before the gdi section and combine the ENTER_GL/LEAVE_GL blocks into one. - Allan
batmeter exported functions
André Renato Furtado, [EMAIL PROTECTED] add documentation for exported functions of the win32 batmeter library... BOOL BatMeterCapabilities(PUINT *ppuiBatCount) *\ description:is used to determine if the batmeter lib can run on the host machine. return true on success (battery meter can run).params:out - ppuiBatCount - points to a pointer which will be filled in with a pointer to the global battery count.*\ HWND CreateBatMeter(HWNDhWndParent,HWND hWndFrame,BOOLbShowMulti,PBATTERY_STATE pbsComposite) *\ description:create, fetch data for and draw the batmeter window. returns a handle to the newly created battery meter window on success, null on failure.param:hWndParent - parent of the battery meter dialog. hWndFrame- frame to locate the battery meter dialog.bShowMulti - display mode (true - multiple battery).opt - pbsComposite- pointer to composite battery state.*\ HWND DestroyBatMeter(HWND hWnd) *\ description: destroy the batmeter window created with CreateBatMeter function. returns the handle of the batmeter parent window. params: hWnd - handle to the window to be destroyed. *\ BOOL PowerCapabilities() *\ description:is used to determine if the system has any power management capabilities which require ui support. return true if power management ui should be displayed. *\ BOOL UpdateBatMeter(HWNDhWnd,BOOLbShowMulti, BOOLbForceUpdate,PBATTERY_STATE pbsComposite) *\ description:this function should be called when the battery meter parent windowreceives a WM_POWERBROADCAST, PBT_APMPOWERSTATUSCHANGE message, it willupdate the data in the global battery state list. if needed the displaywill also be updated. PARAMETERS:hWndBatMeter, hwnd of the battery meter dialogbShowMulti,display mode bForceUpdate, forces a ui updateopt - pbsComposite,pointer to composite battery state. *\ WM_POWERBROADCAST == 0x218 PBT_APMPOWERSTATUSCHANGE == 0xa _ Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o Messenger! É GRÁTIS! http://www.msn.com.br/emoticonpack
