uxtheme efforts (wanted/needed ?)
Hi, I've sent 2 emails that are (for now) silently ignored: http://www.winehq.org/pipermail/wine-patches/2006-June/027253.html http://www.winehq.org/pipermail/wine-patches/2006-June/027350.html They both have to do with uxtheme and were meant as a starter for conformance tests and of course the fixes to it. I first wanted to start with input/return paramater and value testing before I touch any functional part (maybe not mutually exclusive). Was there anything wrong with the patches? How can I improve or what do I have to change? Cheers, Paul
Re: iphlpapi: forward Icmp* functions to icmp.dll
Dmitry Timoshkov wrote: In XP SP2 it's icmp.dll who forwards its entry points to iphlpapi.dll, so we need to move some code around to accomplish the same thing. Curious; what happens when this is implemented and wine is running in eg. win98 mode? Won't there technically be a discrepancy of some sort?
Re: iphlpapi: forward Icmp* functions to icmp.dll
"Steven Edwards" <[EMAIL PROTECTED]> wrote: On 6/11/06, Simon Kissane <[EMAIL PROTECTED]> wrote: In WinXP, these functions are implemented in iphlpapi.dll as well as icmp.dll (Win2000). They are already in Wine's icmp.dll, so forward the iphlpapi to icmp.dll Being its a small amount of code in icmp.dll I think we should just duplicate it. Our dependancies should really match windows and the last time I looked iphlpapi did not depend on icmp.dll in win2k. In XP SP2 it's icmp.dll who forwards its entry points to iphlpapi.dll, so we need to move some code around to accomplish the same thing. -- Dmitry.
Gnome and KDE wine configuration tools
Hi, I was just looking at browsing net for some linux stuff. I just happend to see some news related to wine Wine-doors : -- Its just a wine installation utility for GNOME with preliminary(very basic and primitive) wine configuration.It has support for multiple installations, from screenshots i think so. I got this news from here http://gnomedesktop.org/node/2689, and more information can be got from its web site http://www.wine-doors.org/ Guidance : --- Its not completely wine configuration utility, but a general purpose system configuration utility for KDE. It now has got some module for configuring WINE also. I got this news from http://dot.kde.org/1150047999/. I havent tested it, but it can be got from here http://www.simonzone.com/software/guidance/ Conclusion, its for you all to decide which is the best tool. And not to forget give some valuable inputs to the developers to improve. Thanks, Vijay
Re: iphlpapi: forward Icmp* functions to icmp.dll
On 6/11/06, Simon Kissane <[EMAIL PROTECTED]> wrote: In WinXP, these functions are implemented in iphlpapi.dll as well as icmp.dll (Win2000). They are already in Wine's icmp.dll, so forward the iphlpapi to icmp.dll Being its a small amount of code in icmp.dll I think we should just duplicate it. Our dependancies should really match windows and the last time I looked iphlpapi did not depend on icmp.dll in win2k. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: WM_GETICON patch
On Sunday 11 June 2006 13:42, Mike Hearn wrote: > Well I guess this is a slight improvement but obviously WM_GETICON > requires inter-process bitmaps to be supported in some fashion, which is a > fair bit of work. Aren't icons already created on the global heap? They're created with GlobalAlloc16, and (optionally) added to a link list of shared icons. Since HICONs are really just void pointers, would something need to be done to transform the pointer for the receiving thread to see the same memory (assuming different processes need different pointers to see the same memory area)? I'm not too read up on how shared memory actually works.
Re: Broken FC5 packages - stay clear.
On Sun, 11 Jun 2006 21:39:30 +0100 Mike Hearn <[EMAIL PROTECTED]> wrote: > We had this problem with Debian, where people didn't install the "utils" > package and apps broke mysteriously. Unless you have a lot of experience > of Wine debugging you cannot detect this easily ... please, there's no > reason to split this stuff up as Wine will load everything in a failsafe > fashion so there is no need to mark the package as depending on a million > things. Well from a wine perspective I see that this makes sense, but if you take a look at all the dependencies it is another story... installing wine is one thing... ending up with zillion dependencies is a whole different story for lots of people where e.g. bandwidth is still a problem or which rather want to have a slim system. I as a packager sit between the chairs and in this case I see why splitting up wine made sense in debian and why it made sense for Fedora Extras as well. The question is what to split and what to leave in. The stuff that has been split from just having one 'wine' package is stuff that made sense and in ways interacts best with what Fedora Core ships with the distro. Sure there are improvements to be made and suggestions are always welcome :) but doing it the way it is done now made lots of people happy (and gave me positive feedback). > Out of interest what are the 11 packages? wine wine-arts wine-capi wine-cms wine-esd wine-jack wine-ldap wine-nas wine-tools wine-twain These are the 10 packages which are relevant for a 'normal' user where wine and wine-tools are the major ones. They are build from the wine sources (without winemp3). Then there is: wine-debuginfo wine-devel These two are more or less only interesting for packagers/developers etc. For more details take a look here: http://cvs.fedora.redhat.com/viewcvs/rpms/wine/FC-5/?root=extras And of course build from the wine-docs sources is the wine-docs rpm: wine-docs http://cvs.fedora.redhat.com/viewcvs/rpms/wine-docs/?root=extras > thanks -mike no problem. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB [EMAIL PROTECTED] | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043| mail preferred signature.asc Description: PGP signature
Re: DDraw: New ddraw lib
On 6/11/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Hi, > Oops, I didn't know about the option. It's running with GDI. But just > replacing the DDraw library sped it up. Probably depth conversion? > OpenGL don't work. Hmm. No idea. SURFACE_GDI should be as fast as the old ddraw code, the rendering is the same. There is a registry key, HKLU\software\wine\direct3d\DirectDrawRenderer. It can be set to "gdi" to force gdi surfaces, or "opengl" to force opengl surfaces. If "gdi" is set, Direct3D is mutually disabled. But still it is interesting that it is faster... The slowness is observed in the multiplayer mode with another peer, not single player, and without your patch. With your patch, the slowness is gone. When you have another peer, the game fires off many udp packets to keep each other in sync. So each game packet basically tells the peers what actions the user it performing. Once you get packets from all the peers for each game "second" it updates the state of the game, and probably draws the screen accordingly. So the net code in the game while in this mode directly affects the drawing speed. Perhaps it is something with our net code causing the slowness, but your patch counteracts somehow, perhaps architechurely since you really made no code changes to the GDI part. (Note with DGA, I believe fixes the slowness too so...) Jesse
Re: WM_GETICON patch
On Sat, 10 Jun 2006 16:35:45 -0700, Chris wrote: > Originally GeoShell would show no icon on the taskbar and print > a lot of fixme messages about it being unsupported. With this patch it now > (always) shows the Wine glass icon for programs, with no such fixme messages. Well I guess this is a slight improvement but obviously WM_GETICON requires inter-process bitmaps to be supported in some fashion, which is a fair bit of work. Maybe for efficiency reasons even requiring the dreaded remote thread creation/service thread :) thanks -mike
Re: Icmp* functions in iphlpapi.dll
On Sat, 10 Jun 2006 21:37:01 -0500, Carl Fongheiser wrote: > Bad, bad idea. In Windows programming, you *never* call LoadLibrary from > DllMain. Inside of DllMain, you can't call anything which uses the loader > lock, because the loader lock is already taken out. As best as I read the > Wine code, it has the same limitation. Loader lock is a recursive critical section so it's OK to do that from the same thread and actually, the Wine loader code is written to allow that to work. That said it's quite dangerous to do much of anything inside a DllMain because so much stuff in Win32 relies on multiple threads or inter-thread messaging behind your back. thanks -mike
Re: Broken FC5 packages - stay clear.
On Sun, 11 Jun 2006 11:09:10 +0200, Andreas Bierfert wrote: > Yes it is (ok more like 11 but ok). For me it works for the programs it should > work on... We had this problem with Debian, where people didn't install the "utils" package and apps broke mysteriously. Unless you have a lot of experience of Wine debugging you cannot detect this easily ... please, there's no reason to split this stuff up as Wine will load everything in a failsafe fashion so there is no need to mark the package as depending on a million things. Out of interest what are the 11 packages? thanks -mike
Re: My new hero...
On Tue, 06 Jun 2006 22:43:27 -0700, Dan Kegel wrote: > Mike, what was that you were saying about > there not being any wine hackers who fixed > problems all around the wine tree anymore? I consider myself joyfully corrected! :) Go Qingdao!
Re: wined3d: Another GLSL shader status update
On Tue, 06 Jun 2006 13:55:15 -0400, Jason Green wrote: > FYI - I just added a bunch to this page to get us started: > > http://wiki.winehq.org/DirectX-Shaders That's awesome, exactly the sort of thing I was looking for. This sort of high level overview is very useful for new hackers! :) thanks -mike
Re: winmm: Add support for "open new" commands.
Peter Åstrand wrote: On Sat, 10 Jun 2006, Eric Pouech wrote: ChangeLog: winmm: Add support for "open new" commands. looks globally good, except that you don't enforce that you got a correct device name ie I'm not sure that 'open new type waveaudio' works (without the alias) I'm not sure I understand what you mean, how is the alias related to the verification of a correct device name? it's not. but I don't think a command like 'open new type waveaudio' shall work (as the name of the MCI device would be new in that case, which is a reserved keyword). In other words, I think that 'open new' should fail if no alias is given. Perhaps the patch can be applied with a FIXME for the case you are talking about, since we would then at least have partial support for "open new"? that shouldn't be too hard to add. A+
Re: winmm: Add support for "open new" commands.
On Sat, 10 Jun 2006, Eric Pouech wrote: ChangeLog: winmm: Add support for "open new" commands. looks globally good, except that you don't enforce that you got a correct device name ie I'm not sure that 'open new type waveaudio' works (without the alias) I'm not sure I understand what you mean, how is the alias related to the verification of a correct device name? Perhaps the patch can be applied with a FIXME for the case you are talking about, since we would then at least have partial support for "open new"? Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 LinköpingPhone: +46-13-21 46 00
Re: user[3/5]: handle special cases for SPI_SETDESKWALLPAPER (FIXED)
Andrey Turkin wrote:
Andrew Ziem wrote:
Please use this patch instead of previous "user3.patch". Thanks to
Andrey Turkin for catching the uninitialized variable.
changelog:
user: handle special cases for SPI_SETDESKWALLPAPER
The special cases remove the wallpaper or set it to default.
Previously, these cases were ignored, so Wine would crash.
-if (filename == (LPSTR)-1)
+if ((LPCSTR)SETWALLPAPER_DEFAULT == filename || (LPCSTR)NULL ==
filename || '\0' == filename[0])
{
-GetProfileStringA( "desktop", "WallPaper", "(None)", buffer, 256 );
-filename = buffer;
+ /* set default wallpaper or remove wallpaper*/
+ if (hbitmapWallPaper)
+ DeleteObject( hbitmapWallPaper );
+ return TRUE;
}
hdc = GetDC( 0 );
According to MSDN, if
- pvParam==SETWALLPAPER_DEFAUL || pvParam==NULL, then wallpaper will be
set to default one
- pvParam[0]=='\0', then wallpaper will be removed.
I cannot see any signs of such distinction in your code :)
When I ran the unit test on Windows 2000, that's what it did: in all
three cases (SETWALLPAPER_DEFAULT, NULL, or '\0'), Windows 2000 removed
the wallpaper. So, it seems the default wallpaper is no wallpaper, and
a test could be added to show that. (I already have a test that checks
the default wallpaper is the same on both SETWALLPAPER_DEFAULT and NULL).
Beyond the cosmetics of changing the wallpaper, the purpose of the new
code is to keep Wine from crashing on SETWALLPAPER_DEFAULT.
Andrew
Re: DDraw: New ddraw lib
Hi, > Oops, I didn't know about the option. It's running with GDI. But just > replacing the DDraw library sped it up. Probably depth conversion? > OpenGL don't work. Hmm. No idea. SURFACE_GDI should be as fast as the old ddraw code, the rendering is the same. There is a registry key, HKLU\software\wine\direct3d\DirectDrawRenderer. It can be set to "gdi" to force gdi surfaces, or "opengl" to force opengl surfaces. If "gdi" is set, Direct3D is mutually disabled. But still it is interesting that it is faster... pgpEImrU4mR0P.pgp Description: PGP signature
Re: Broken FC5 packages - stay clear.
On Sat, 10 Jun 2006 17:31:22 -0600
Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
> It seems that FC5 packager created a broken Wine distribution.
I don't think I did... ;)
> Instead of being 1-3 packages it's 15 (from what user told me on #winehq.
> And it doesn't work at all:
> "Application tried to create a window, but no driver could be loaded."
Yes it is (ok more like 11 but ok). For me it works for the programs it should
work on...
> Which tells me it's compiled without X headers. I didn't even new Wine could
> compile without X, since we don't have tty driver.
Be sure it is compiled with everything that FC/FE{3,4,5,devel} can support. The
only thing is that some stuff is split out into subpackages and if users want
that support they need to install it. Take a look at debian for example. Fedora
Extras wine layout is basically the same. For the X driver... that should work
out of the box so I suspect that the user has a different problem. In any way
direct FE wine users to http://bugzilla.redhat.com to file bug against wine.
This way I can easily track such bugs and decide if they should be filed
against wine or if it really is a packaging but.
- Andreas
--
Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB
[EMAIL PROTECTED] | http://lowlatency.de | signed/encrypted
phone: +49 2402 102373 | cell: +49 173 5803043| mail preferred
signature.asc
Description: PGP signature
Re: user[3/5]: handle special cases for SPI_SETDESKWALLPAPER (FIXED)
Andrew Ziem wrote:
Please use this patch instead of previous "user3.patch". Thanks to
Andrey Turkin for catching the uninitialized variable.
changelog:
user: handle special cases for SPI_SETDESKWALLPAPER
The special cases remove the wallpaper or set it to default.
Previously, these cases were ignored, so Wine would crash.
-if (filename == (LPSTR)-1)
+if ((LPCSTR)SETWALLPAPER_DEFAULT == filename || (LPCSTR)NULL == filename
|| '\0' == filename[0])
{
- GetProfileStringA( "desktop", "WallPaper", "(None)", buffer, 256 );
- filename = buffer;
+ /* set default wallpaper or remove wallpaper*/
+ if (hbitmapWallPaper)
+ DeleteObject( hbitmapWallPaper );
+ return TRUE;
}
hdc = GetDC( 0 );
According to MSDN, if
- pvParam==SETWALLPAPER_DEFAUL || pvParam==NULL, then wallpaper will
be set to default one
- pvParam[0]=='\0', then wallpaper will be removed.
I cannot see any signs of such distinction in your code :)
