Re: urlmon: add stub for CoInternetSetFeatureEnabled
Louis. Lenders [EMAIL PROTECTED] wrote:
+HRESULT WINAPI CoInternetSetFeatureEnabled(INTERNETFEATURELIST Feature,
DWORD flags, BOOL fEnable)
+{
+FIXME(%p, 0x%08x, %x, stub\n, Feature, flags, fEnable);
+return E_NOTIMPL;
+}
diff --git a/dlls/urlmon/urlmon.spec b/dlls/urlmon/urlmon.spec
index 1fa2f94..e89e049 100644
--- a/dlls/urlmon/urlmon.spec
+++ b/dlls/urlmon/urlmon.spec
@@ -19,6 +19,7 @@
@ stdcall CoInternetGetSession(long ptr long)
@ stdcall CoInternetParseUrl(wstr long long wstr long ptr long)
@ stdcall CoInternetQueryInfo(ptr long long ptr long ptr long)
+@ stdcall CoInternetSetFeatureEnabled(ptr long long)
The first parameter of CoInternetSetFeatureEnabled is not a pointer even
if you pretend it is in the FIXME. Also Please use consistent spacing and
naming of variables (preferring 1 space and no hungarian/upper cased names).
--
Dmitry.
Desktop, x11drv, and _NET_WM_WINDOW_TYPE_DIALOG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to xprop, Wine is creating the desktop window with _NET_WM_WINDOW_TYPE = _NET_WM_WINDOW_TYPE_DIALOG. This is problematic for me, because of the way my window manager (Matchbox) handles dialogs. Is there a reason that the desktop is not _NET_WM_WINDOW_TYPE_NORMAL? I have tried to trace this through the code, and I wind up at x11drv/desktop.c, but I don't see any reference to DIALOG there. Alternatively, perhaps it is set with MAKEINTATOM at the top of explorer/desktop.c, but I'm not sure how to interpret that constant. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIAiGiUJT6e6HFtqQRAvgmAJ0XJohI9u7VYzorTgKenG1qJpJzeACdEiqR dUAVRyREOtjfx/bAgrUUeQ8= =PkkE -END PGP SIGNATURE-
Re: d3dx9_36: Add stubs and implementations for D3DXCreateTexturexx
Hi, Are you still working on the texture functions? I'd need them for completing my ID3DXSprite implementation, so if you don't mind I could complete your started patches. Best regards, Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html
Re: Including Mono within a Wine package - should Wine expect this?
On Fri, Apr 11, 2008 at 8:50 AM, Roderick Colenbrander [EMAIL PROTECTED] wrote: For a part the issue is that lots of programs are hybrid ones. Some of them behave 'nicely' in the way they just call a few functions from a native win32 dll. I think apps that embed COM objects (like a Word viewer, ..) are worse as mono doesn't offer this at all. The most problematic thing is that mono's windows.forms is fully managed while microsoft just layered it on top of gdi32/gdiplus/user32. This allows you to use standard win32 apis on most windows.forms controls to override behavior. A lot of apps do this, so even if you could access native win32 dlls, magic like this won't work at all. Second COM objects might also rely on evil win32 magic. Rather than ignoring mono these issues make it sound like Wine and mono should try to work together again. The EULA for the .NET runtime prohibits distributing it and using it on non-windows licensed systems so we are in much the same legal situation with IE where we have to have a replacement. -- 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: loader: print a better message about reserving memory
Austin English wrote: With ubuntu updating to the 2.6.24 kernel, a lot more people are running into errors about reserving memory. This patch adds a suggestion to check /etc/sysctl.conf. You may need to edit /etc/sysctl.conf to give Wine access to this memory.\n, Can you be more specific what did Ubuntu do to break Wine? Vitaliy.
Re: dinput: Convert keyboard buffer from internal data format to user data format
Sergey Khodych wrote: Any particular reason for this? Do you have a program that sets different data format? The reason I ask - copying 256 bytes is much faster then iterating over the whole data format and copying one byte at a time. Vitaliy.
Re: dinput: Implement DIPROP_KEYNAME property for keyboard device
Sergey Khodych wrote: +static HRESULT WINAPI SysKeyboardAImpl_GetProperty( ... +if (TRACE_ON(dinput)) +_dump_DIPROPHEADER(pdiph); Please drop the TRACE_ON check - it's being done in dump function. ... +hr = SysKeyboardWImpl_GetObjectInfo( (LPDIRECTINPUTDEVICE8W)iface , didoi, + ps-diph.dwObj, ps-diph.dwHow ); You mixing unicode and ascii. Also if you are implementing SysKeyboardAImpl_GetProperty you should also implement it's unicode counterpart SysKeyboardWImpl_GetProperty. And please use 4-space indent. Vitaliy.
Re: d3dx9_36: Add stubs and implementations for D3DXCreateTexturexx
The files that I have for textures are attached.
[EMAIL PROTECTED] escribió:
Hi,
Are you still working on the texture functions?
I'd need them for completing my ID3DXSprite implementation,
so if you don't mind I could complete your started patches.
Best regards,
Tony
Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl.
http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html
/*
* Direct3D X 9 texture file
*
* Copyright (C) 2008 Luis Busquets
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
*
*/
#include config.h
#include wine/port.h
#include stdarg.h
#include windef.h
#include winbase.h
#include wingdi.h
#include winuser.h
#include wine/debug.h
#include d3dx9.h
typedef enum D3DXIMAGE_FILEFORMAT
{
D3DXIFF_BMP = 0,
D3DXIFF_JPG = 1,
D3DXIFF_TGA = 2,
D3DXIFF_PNG = 3,
D3DXIFF_DDS = 4,
D3DXIFF_PPM = 5,
D3DXIFF_DIB = 6,
D3DXIFF_HDR = 7,
D3DXIFF_PFM = 8,
D3DXIFF_FORCE_DWORD = 0x7fff,
} D3DXIMAGE_FILEFORMAT, *LPD3DXIMAGE_FILEFORMAT;
typedef struct D3DXIMAGE_INFO {
UINT Width;
UINT Height;
UINT Depth;
UINT MipLevels;
D3DFORMAT Format;
D3DRESOURCETYPE ResourceType;
D3DXIMAGE_FILEFORMAT ImageFileFormat;
} D3DXIMAGE_INFO, *LPD3DXIMAGE_INFO;
WINE_DEFAULT_DEBUG_CHANNEL(d3dx);
HRESULT WINAPI D3DXCreateCubeTextureFromFileInMemoryEx(
LPDIRECT3DDEVICE9 pDevice,
LPCVOID pSrcData,
UINT SrcDataSize,
UINT Size,
UINT MipLevels,
DWORD Usage,
D3DFORMAT Format,
D3DPOOL Pool,
DWORD Filter,
DWORD MipFilter,
D3DCOLOR ColorKey,
D3DXIMAGE_INFO *pSrcInfo,
PALETTEENTRY *pPalette,
LPDIRECT3DCUBETEXTURE9 *ppCubeTexture
)
{
FIXME(Stub\n\n\n!);
return D3D_OK;
}
HRESULT D3DXCreateCubeTextureFromFileInMemory(
LPDIRECT3DDEVICE9 pDevice,
LPCVOID pSrcData,
UINT SrcDataSize,
LPDIRECT3DCUBETEXTURE9 * ppCubeTexture
)
{
FIXME(Stub\n\n\n!);
return D3D_OK;
}
HRESULT D3DXCreateCubeTextureFromFileExW(
LPDIRECT3DDEVICE9 pDevice,
LPCSTR pSrcFile,
UINT Size,
UINT MipLevels,
DWORD Usage,
D3DFORMAT Format,
D3DPOOL Pool,
DWORD Filter,
DWORD MipFilter,
D3DCOLOR ColorKey,
D3DXIMAGE_INFO * pSrcInfo,
PALETTEENTRY * pPalette,
LPDIRECT3DCUBETEXTURE9 * ppCubeTexture
)
{
FIXME(Stub\n\n\n!);
return D3D_OK;
}
HRESULT D3DXCreateCubeTextureFromFileExA(
LPDIRECT3DDEVICE9 pDevice,
LPCSTR pSrcFile,
UINT Size,
UINT MipLevels,
DWORD Usage,
D3DFORMAT Format,
D3DPOOL Pool,
DWORD Filter,
DWORD MipFilter,
D3DCOLOR ColorKey,
D3DXIMAGE_INFO * pSrcInfo,
PALETTEENTRY * pPalette,
LPDIRECT3DCUBETEXTURE9 * ppCubeTexture
)
{
FIXME(Stub\n\n\n!);
return D3D_OK;
}
HRESULT WINAPI D3DXCreateCubeTextureFromFileW(
LPDIRECT3DDEVICE9 pDevice,
LPCSTR pSrcFile,
LPDIRECT3DCUBETEXTURE9 *ppCubeTexture
)
{
FIXME(Stub\n\n\n!);
return D3D_OK;
}
HRESULT WINAPI D3DXCreateCubeTextureFromFileA(
LPDIRECT3DDEVICE9 pDevice,
LPCSTR pSrcFile,
LPDIRECT3DCUBETEXTURE9 *ppCubeTexture
)
{
FIXME(Stub\n\n\n!);
return D3D_OK;
}
/*
* Direct3D X 9 texture file
*
* Copyright (C) 2008 Luis Busquets
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
*
*/
#include config.h
#include wine/port.h
#include stdarg.h
#include windef.h
#include winbase.h
#include wingdi.h
#include winuser.h
#include wine/debug.h
#include d3dx9.h
WINE_DEFAULT_DEBUG_CHANNEL(d3dx);
HRESULT D3DXCreateTextureFromFileInMemory(
LPDIRECT3DDEVICE9 pDevice,
LPCVOID pSrcData,
UINT SrcDataSize,
LPDIRECT3DTEXTURE9 * ppTexture
)
{
FIXME (stub\n);
return
Re: Trying to get a grip on how to handle bug reports.
James Hawkins wrote: On Sat, Apr 12, 2008 at 5:14 PM, Kai Blin [EMAIL PROTECTED] wrote: Hi folks, I seem to have done something wrong referring a user to a closed bug report that seemed to be related to the problem he was having. (See bug 11639 for more context) So in order to avoid me being the cause a user defiles the holy status of a closed bug, I'd like to have some clear rules on how to handle related bug reports. It's actually a lot simpler than that. While we don't want users filing duplicate bug reports, a bug can't be a duplicate of another bug that is already fixed. The right thing to do would be to tell that user to file a new bug report, referring to the closed bug report if he really feels like it. Sure they very well maybe be related, but the fact remains that one bug is fixed, while another bug is not fixed. Thus, they're not the same bug. By the way, if you really want to help this situation, I don't recommend the sarcasm. And you folks wonder why we don't have a healthy user community. Sometimes I feel like talking to a brick wall. http://bugs.winehq.org/show_bug.cgi?id=11639#c16 http://bugs.winehq.org/show_bug.cgi?id=11639#c18 Those are links to my comments for the bug report in question. The user was told to file a new bug report. Once the user kept commenting in the closed bug report (and not filing a new bug report), I told him to stop posting in a closed bug. Since when is this not standard? I think bugzilla operators are a bit too trigger happy lately, in particular with abandoning bugs. For example: http://bugs.winehq.org/show_bug.cgi?id=12437 The tests aren't time consuming, but if you choose to not do the tests, we'll have to close this bug as abandoned. And there's a link mentioned in comments to downloadable trial that can (reportedly) be used to reproduce. Sure, the user should've filled the URL field. But, it's pointless to expect users to 1) do everything right 2) follow their bugs indefinitely (sometimes for years). 3) always be willing to do time consuming and otherwise demanding operations like regression test. If a user submitted enough info to make it possible for developer to reproduce or otherwise make sense of a bug, he has already done a commendable job. IMHO care should be taken not to abandon bugs without good reason, such as bug description that makes no sense, absence of any useful logs and obscure app for which no download can be googled and user not responding for a long period of time.
Re: WineD3D: WineD3D: Use the shader backend to enable / disable atifs and nvts
Am Samstag, 12. April 2008 04:27:01 schrieb Ivan Gyurdiev: Stefan Dösinger wrote: Alexandre didn't commit the patch, I think we should come to an agreement on this issue, otherwise it is going to come up again and again. The fundamental issue is pretty straightforward - not sure why it's so difficult to come to an agreement. - You want to mix and match vertex and fragment GL backends - The only maintainable way to do that is to define an interface between vertex and fragment objects I certainly see the advantages of a constrained interface, I just don't see(and still don't see) how it can be designed cleanly without greatly limiting functionality of the pipeline / shader implementation. I discussed the topic with Henri on IRC again(@Henri: Please correct me if I missunderstood you), and he explained that his plans consider making GLSL vertex shaders, GLSL vertex replacement, GLSL fragment replacement and GLSL fragment replacement one object with different interfaces. So we can have backchannel communication between the various interface implementations(e.g. flags or private data) which keeps everything flexible. It's not precisely nice(backchannel communication somewhat defeats the point of interfaces), but my design has ugliness as well, so I can live with that. What's most important to me about this is that we don't have to close any bug as WONTFIX due to design constraints. So I can stop feeling strongly against splitting up the interface since the implementations remain the same. Now the main issue with not splitting up the interfaces I see is that it is unclear what code in state.c(or the shader backend's state table) changes which GL state. If state_something changes both vertex and fragment GL states I can't overwrite it properly in the ATIFS/NVRC code without messing with the vertex side as well. I have a few remaining issues though: - With splitting up the state table there are now 5 root states which have to be polled for changes in CTXUSAGE_DRAWPRIM setting, also the GL_TEXTURE_SHADER_NV and GL_FRAGMENT_SHADER_ATI states need to be polled for enabling/disabling. Is there no way to avoid that? - Some cross pipeline part communication issues are still remaining, see below - Increased state dirtification complexity: Now each Set*State has to find out which part of the pipeline it has to dirtify(a switch-case statement or probably table referencing), and has to dirtify up to 3 pipelines. That's not precicely going to help performance. I know that Ivan doesn't really care about that, especially since it's not an algorithmic complexity change. However, performance is a top priority issue, and no gamer will accept the next-gen hardware excuse for inefficient code. I mainly want to avoid more bad PR like this: http://www.phoronix.com/scan.php?page=articleitem=938 http://www.phoronix.com/scan.php?page=articleitem=crossover_games The 2nd article would be good for me if it was due to a tuneup in cxgames, but it is a regression in wine instead. Yes, that's phoronix and all, and the first article's regressions are technically perfectly explainable. Still new features don't have to come with performance costs. I have a ~5% performance regression myself which I don't know where it comes from. So I propose the following plan: 1) We commit the patch to fix fglrx 2) We keep the shader / ffp interface as it is for Wine 1.0. We freeze in two weeks. I am away for one week now, so if anyone wants any shader interface changes in 1.0 he'll have to do it himself 3) We investigate where the recent performance regression(s) came from 4) We audit the state handlers in state.c and find out which D3D state handler changes which parts of the GL pipeline and find states that touch more than one part and why. 5) Build a battle plan how to separate the following D3D states in various GL pipeline parts: - Vertex shaders - streams. The tricky part here is that the fixed function GL vertex pipeline needs named arrays, while an ARB/GLSL vertex pipeline needs numbered arrays(otherwise no vertex blending emulation). How do we communicate the need for numbered arrays, and the choosen assignment? - vertex decl - loaded pointers. We're currently checking the vertex shader and fog states when a vertex buffer offset it changed, that is not needed - Samplers - GL_TEXTURE_xD enable - colorop. That's a major pain for ATIFS and even more NVTS. I haven't found a nicer implementation using split up interfaces - How do we deal with the depth blit shaders? Do they belong to the shader backend, or to something else? - Should we move the SetupForBlit to some of the shader code? The blitting and state switching might be more efficient if we're using shaders for it and just set a ARB / GLSL shader instead of falling back to the absolute low level limit and killing all states - Texture transform flags, clipping, more? My ultimate hope is to have a clean assignment for
Re: Including Mono within a Wine package - should Wine expect this?
On Sun, Apr 13, 2008 at 10:11 AM, Steven Edwards [EMAIL PROTECTED] wrote: Rather than ignoring mono these issues make it sound like Wine and mono should try to work together again. The EULA for the .NET runtime prohibits distributing it and using it on non-windows licensed systems so we are in much the same legal situation with IE where we have to have a replacement. Yes, exactly. I've been discussing this a bit on the mono list. There are two big pieces of work needed: 1) support for mixed assemblies in Mono for Windows 2) porting Mono's WinForms on top of Wine gdiplus instead of Mono gdiplus (and making it more win32-ish as a result) This would be a fine summer project for somebody properly motivated. There will be more incentive to do this as we get Microsoft .NET working better, and it becomes clearer just how many applications need one or the other of the two items above to run. In short: I think the path to Mono+Wine nivana at the moment leads directly through enemy territory: we have to get MS .net working better first before it's clear it'll be worth it. - Dan
Re: Trying to get a grip on how to handle bug reports.
On Sun, Apr 13, 2008 at 2:01 PM, Alexander Dorofeyev [EMAIL PROTECTED] wrote: James Hawkins wrote: On Sat, Apr 12, 2008 at 5:14 PM, Kai Blin [EMAIL PROTECTED] wrote: Hi folks, I seem to have done something wrong referring a user to a closed bug report that seemed to be related to the problem he was having. (See bug 11639 for more context) So in order to avoid me being the cause a user defiles the holy status of a closed bug, I'd like to have some clear rules on how to handle related bug reports. It's actually a lot simpler than that. While we don't want users filing duplicate bug reports, a bug can't be a duplicate of another bug that is already fixed. The right thing to do would be to tell that user to file a new bug report, referring to the closed bug report if he really feels like it. Sure they very well maybe be related, but the fact remains that one bug is fixed, while another bug is not fixed. Thus, they're not the same bug. By the way, if you really want to help this situation, I don't recommend the sarcasm. And you folks wonder why we don't have a healthy user community. Sometimes I feel like talking to a brick wall. http://bugs.winehq.org/show_bug.cgi?id=11639#c16 http://bugs.winehq.org/show_bug.cgi?id=11639#c18 Those are links to my comments for the bug report in question. The user was told to file a new bug report. Once the user kept commenting in the closed bug report (and not filing a new bug report), I told him to stop posting in a closed bug. Since when is this not standard? I think bugzilla operators are a bit too trigger happy lately, in particular with abandoning bugs. For example: http://bugs.winehq.org/show_bug.cgi?id=12437 The tests aren't time consuming, but if you choose to not do the tests, we'll have to close this bug as abandoned. Can we all stop with the sensationalist comments? Seriously. If you'll actually read what I said, I made no threats, nor was I rude. I also didn't change the resolution of the bug, so where's the trigger-pulling you refer to? The only mistake I made, which was a mistake on the part of everyone triaging this bug, was that I didn't know the bug was freely reproducible. That's the worst I did, and that's not a big deal, and certainly not worth your reply. And there's a link mentioned in comments to downloadable trial that can (reportedly) be used to reproduce. Sure, the user should've filled the URL field. But, it's pointless to expect users to 1) do everything right 2) follow their bugs indefinitely (sometimes for years). 3) always be willing to do time consuming and otherwise demanding operations like regression test. On behalf of the regular bugzilla moderators (of which there are very few), I'll go over the policy we have in place to keep, or strive to attain, a manageable bugzilla database. There are only a few conditions that warrant abandoning a bug: a) the bug must not be freely reproducible b) the reporter has not responded to a request for more information in at least 3 months, or c) the reporter will not or can not provide the information requested, usually not doing the regression testing If you have a problem with any of these policies, bring it up in wine-devel, but don't single me out. We devote so much of our free time to keep our bugzilla manageable, and a big part of that is weeding out bugs which we can do nothing about (abandoned). If a user submitted enough info to make it possible for developer to reproduce or otherwise make sense of a bug, he has already done a commendable job. IMHO care should be taken not to abandon bugs without good reason, such as bug description that makes no sense, absence of any useful logs and obscure app for which no download can be googled and user not responding for a long period of time. Besides the reproducible part of this last paragraph, you're describing an invalid bug, not abandoned. -- James Hawkins
re: Trying to get a grip on how to handle bug reports.
James wrote: If you'll actually read what I said, I made no threats, nor was I rude. IMHO the cumulative attitude of your comments, especially http://bugs.winehq.org/show_bug.cgi?id=11639#c18 Stop posting in a closed bug report! You've already been told to open a new bug report.. was in fact somewhat rude. - Dan
re: loader: print a better message about reserving memory
Vitaliy wrote: Austin English wrote: With ubuntu updating to the 2.6.24 kernel, a lot more people are running into errors about reserving memory. This patch adds a suggestion to check /etc/sysctl.conf. You may need to edit /etc/sysctl.conf to give Wine access to this memory.\n, Can you be more specific what did Ubuntu do to break Wine? It would have been helpful if Austin had linked to the bug report from his patch. I went and filed a (very well documented :-) bug report http://bugs.winehq.org/show_bug.cgi?id=12548 that turned out to be a dup of the one Austin had been discussing the bug in. Austin's patch is helpful, but I think we can do better. For instance, we could ship a helper app that pops up a gui and asks whether the user wants us to work around the problem (by doing gksudo sysctl -w vm.mmap_min_addr=0, say) and run it in the preloader if we can't map the lowest page.
Re: Including Mono within a Wine package - should Wine expect this?
Hi, 1) support for mixed assemblies in Mono for Windows I'm trying to do some work on that. 2) porting Mono's WinForms on top of Wine gdiplus instead of Mono gdiplus (and making it more win32-ish as a result) Mono is using MS GDI+ on Windows since it uses GDI+. Mono's libgdiplus is only used on non-Windows platforms. If Wine's GDI+ is not supported by Mono (I haven't tried) it's Wine's GDI+ that has to be fixed because Mono works perfectly with MS GDI+. I also suggested on mono-devel-list that process creation and module loading for managed modules should be supported by ntdll.dll via callbacks to mscoree.dll as described in http://lists.ximian.com/pipermail/mono-devel-list/2008-April/027491.html Kornél
Re: loader: print a better message about reserving memory
On Sun, Apr 13, 2008 at 2:43 PM, Dan Kegel [EMAIL PROTECTED] wrote: Vitaliy wrote: Austin English wrote: With ubuntu updating to the 2.6.24 kernel, a lot more people are running into errors about reserving memory. This patch adds a suggestion to check /etc/sysctl.conf. You may need to edit /etc/sysctl.conf to give Wine access to this memory.\n, Can you be more specific what did Ubuntu do to break Wine? It would have been helpful if Austin had linked to the bug report from his patch. I went and filed a (very well documented :-) bug report http://bugs.winehq.org/show_bug.cgi?id=12548 that turned out to be a dup of the one Austin had been discussing the bug in. Austin's patch is helpful, but I think we can do better. For instance, we could ship a helper app that pops up a gui and asks whether the user wants us to work around the problem (by doing gksudo sysctl -w vm.mmap_min_addr=0, say) and run it in the preloader if we can't map the lowest page. I had started to notice it whenever ubuntu upgraded the hardy kernel to 2.6.24. A helper app would be good, but in the meantime, I think a link to a wiki page with links to the bug #'s, etc would be helpful. I wrote the patch before your (very detailed :-D) report, however.
RE: Trouble in compiling Wine 0.9.57 and 0.9.58 on Solaris 10 08/07
Petr Sumbera [mailto:[EMAIL PROTECTED] isinf is a function / macro which returns wether or not a float is positive infinite or negative infinite. I think it is a standard C function. Maybe solaris declares it in some header that needs to be included, like math.h? I have logged for this bug: http://bugs.winehq.org/show_bug.cgi?id=12008 Not sure where to find it exactly. But isinf seems to be defined by ISO 99 (not by standard C). Following link might give some details about Sun Solaris support of infinintes and also ideas how to solve that problem. http://www.google.nl/codesearch?q=isinfie=UTF-8oe=utf-8rls=org.mozilla:en -US:officialclient=firefox-aum=1sa=Xoi=codesearch_groupresnum=4ct=titl e Rolf Kalbermatter
Re: Including Mono within a Wine package - should Wine expect this?
On Sun, Apr 13, 2008 at 12:55 PM, Kornél Pál [EMAIL PROTECTED] wrote: 1) support for mixed assemblies in Mono for Windows I'm trying to do some work on that. Cool! 2) porting Mono's WinForms on top of Wine gdiplus instead of Mono gdiplus (and making it more win32-ish as a result) Mono is using MS GDI+ on Windows since it uses GDI+. Mono's libgdiplus is only used on non-Windows platforms. I guess I assumed that Mono used native WinForms on Windows, and that its winforms code was only used on Linux. I clearly don't know enough about Mono to discuss it intelligently :-) I also suggested on mono-devel-list that process creation and module loading for managed modules should be supported by ntdll.dll via callbacks to mscoree.dll as described in http://lists.ximian.com/pipermail/mono-devel-list/2008-April/027491.html That's interesting info, thanks. At the moment you seem to be taking the lead on these issues. Please let us know how it goes. - Dan
Re: cachedmetrics - still used?
Austin English wrote: Looking at documentation/PACKAGING, it seems there's quite a bit of outdated info (hasn't been updated in 2-3 years...). Anywho, I'm preparing a few updates for it, but wanted to verify that cachedmetrics is no longer used. There's a few references to it on AppDB, but only one reference in the code, and a few on wine-devel (all of which are pretty old). Is it safe to remove this info? -Austin That documentation really should be deleted and moved to the wiki. Thanks, Scott Ritchie
Lots of input messages lingering in server slowing down wine tremendously?
Hi.
There was a problem found recently in a fan-made mod of Forsaken (game), that
certain input combinations were slowing wine very seriously. Holding down a
keyboard button and moving mouse was found to be especially devastating to
performance (200 fps to 10fps in a matter of 10-20 seconds).
With help from people who develop this mod, I was able to isolate it in a very
small and simplistic testcase, which shows this same problem. It will be
included as attachment. Holding a key and moving mouse over the window steadily
increases main loop latency from 10 to 50 (and even 100) in a short time,
especially so if quickly clicking both mouse buttons as well. In a game this
means going from 100 fps to 20 or 10 just because of input messages. Has to be
noted that in the actual game the rate of slowdown seemed at least 2-3 times
faster for reasons I don't know, but the testcase still should enough to show
the problem.
Now, I do realize that what the testcase is doing is bad practice, it's
basically refusing to process certain types of messages, and PeekMessage just
once during a loop is probably bad as well, but that's what the game was
originally doing in its main game loop. They do plan to fix it in the game.
Still, there are several concerns about it:
1) No slowdown happens of Windows as far as I can tell. No matter how much I
move the mouse holding key and clicking madly, it shows same stable 15-16 ticks
latency in the testcase. I don't know what it does, but somehow it handles this
situation better than Wine.
2) Can this (broken) way of doing things be exposing some inefficiency in
message handling, maybe something that could use optimization? I tried to put
debug hacks into queue_hardware_message(), it seems that when slowdown is
already VERY bad in Forsaken (10fps), message queue in wine server has about 400
or maybe 600 messages. Is that kind of processing overhead per message
inevitable? (This is happening on AMD Athlon(tm) 3200+). Perhaps somebody who
knows that part of code well may be interested in looking into performance
issues in this case. Because, if 400-600 messages in the queue slow down the
application to a crawl, then who knows, perhaps it decreases performance of more
well-behaved but input-intensive apps as well, just less drastically (holding
one or several keys to move, all the while aiming with mouse and abusing mouse
buttons is a common thing in games, so there can be quite a few input messages
flooding the server).
The reason I decided to post it to wine-devel is because I'm not sure if this
kind of thing is expected and unavoidable or a bug that can be fixed, so better
to hear some comments first, then a bug entry can be opened if needed.
#include windows.h
HWND window;
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow)
{
WNDCLASS wc = {0};
MSG msg;
DWORD ticks, ticks2;
HHOOK kbd_hook, mouse_hook;
wc.lpfnWndProc = DefWindowProc;
wc.lpszClassName = testwc;
RegisterClass(wc);
window = CreateWindow(testwc, test, WS_OVERLAPPED | WS_VISIBLE | WS_CAPTION
, 0, 0, 640, 480, 0, 0, 0, 0);
ticks = GetTickCount();
for (;;) {
if (PeekMessage(msg, NULL, WM_NULL, WM_KEYFIRST, PM_REMOVE)) {
if (msg.message == WM_QUIT) {
DestroyWindow(window);
break;
}
TranslateMessage(msg);
DispatchMessage(msg);
}
//simulated work
ticks2 = GetTickCount();
for (;;) {
UINT i;
volatile int dummy = 1;
for (; i 1 dummy; i++) ;
if (GetTickCount() - ticks2 = 10) break;
}
printf(main loop %u tick latency\n, GetTickCount() - ticks);
ticks = GetTickCount();
}
}
Re: [2/6] winspool/tests: Add tests for AddForm
On So, 2008-04-13 at 02:18 +0200, Marcel Partap wrote: Subject: [PATCH] winspool/tests: Add tests for AddForm A test for AddForm / DeleteForm can't work with the stubs in our winspool.drv. The implementation is needed first. +SetLastError(MAGIC_DEAD); Plase do not use MAGIG_DEAD, it was a mistake in my first Patchset. Use the real Value instead. +res = AddFormA(NULL, 0, NULL); +RETURN_ON_DEACTIVATED_SPOOLER(res); +ok( !res (GetLastError() == ERROR_INVALID_LEVEL), +returned %d with %d (expected '0' with ERROR_INVALID_LEVEL)\n, res, GetLastError()); + +SetLastError(MAGIC_DEAD); +res = AddFormA((HANDLE)MAGIC_DEAD, 1, NULL); +RETURN_ON_DEACTIVATED_SPOOLER(res); Use this macro only once. I did not test, which AddFormA return RPC_S_SERVER_UNAVAILABLE. Did you test the code with a non - admin account? Many functions in winspool.drv return ERROR_ACCESS_DENIED -- By by ... Detlef
Re: [3/6] winspool: Implement AddFormA/W for level 1 forms
On So, 2008-04-13 at 02:18 +0200, Marcel Partap wrote: + * + * FIXME: no level 2 support + * */ BOOL WINAPI AddFormW(HANDLE hPrinter, DWORD Level, LPBYTE pForm) FIXME: is not a valid section in our API-Documentation Please use NOTES or BUGS -- By by ... Detlef
Re: [5/6] winspool: Implement DeleteFormA/W
On So, 2008-04-13 at 02:18 +0200, Marcel Partap wrote: +formNameW = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); +MultiByteToWideChar(CP_ACP, 0, pFormName, -1, formNameW, len); +return DeleteFormW(hPrinter, formNameW); Memory-leak: formnameW -- By by ... Detlef
Re: cachedmetrics - still used?
On Sun, Apr 13, 2008 at 4:05 PM, Scott Ritchie [EMAIL PROTECTED] wrote: Austin English wrote: Looking at documentation/PACKAGING, it seems there's quite a bit of outdated info (hasn't been updated in 2-3 years...). Anywho, I'm preparing a few updates for it, but wanted to verify that cachedmetrics is no longer used. There's a few references to it on AppDB, but only one reference in the code, and a few on wine-devel (all of which are pretty old). Is it safe to remove this info? -Austin That documentation really should be deleted and moved to the wiki. Thanks, Scott Ritchie I just created http://wiki.winehq.org/Packaging I just dumped my updated PACKING file, which is still incomplete. I removed some old stuff, e.g., references to using windows partitions, cachedmetrics, etc. Added info on optional packages, but it still needs quite a bit of work (as well as wiki formatting). Wine components definitely needs updating, as well as the general info about where to install files/etc.
Re: urlmon: add stub for CoInternetSetFeatureEnabled
Dmitry Timoshkov wrote:
Louis. Lenders [EMAIL PROTECTED] wrote:
+HRESULT WINAPI CoInternetSetFeatureEnabled(INTERNETFEATURELIST Feature,
DWORD flags, BOOL fEnable)
+{
+FIXME(%p, 0x%08x, %x, stub\n, Feature, flags, fEnable);
+return E_NOTIMPL;
+}
diff --git a/dlls/urlmon/urlmon.spec b/dlls/urlmon/urlmon.spec
index 1fa2f94..e89e049 100644
--- a/dlls/urlmon/urlmon.spec
+++ b/dlls/urlmon/urlmon.spec
@@ -19,6 +19,7 @@
@ stdcall CoInternetGetSession(long ptr long)
@ stdcall CoInternetParseUrl(wstr long long wstr long ptr long)
@ stdcall CoInternetQueryInfo(ptr long long ptr long ptr long)
+@ stdcall CoInternetSetFeatureEnabled(ptr long long)
The first parameter of CoInternetSetFeatureEnabled is not a pointer even
if you pretend it is in the FIXME. Also Please use consistent spacing and
naming of variables (preferring 1 space and no hungarian/upper cased names).
oh, I just made the same comment
(http://bugs.winehq.org/show_bug.cgi?id=12406#c7 ):
I had a look at this - INTERNETFEATURELIST is a enum, not a long pointer;
oh, and the stub code itself should go into internet.c (where similiarly
named/used functions resides), instead of urlmon_main.c .
Other than these, the patch took the doc explorer further, so
I think basically just needs a 'FIXME(Not implemented\n);' to be sent off...
Re: Trouble in compiling Wine 0.9.57 and 0.9.58 on Solaris 10 08/07
Am Sonntag, 13. April 2008 22:28:16 schrieb Rolf Kalbermatter: Following link might give some details about Sun Solaris support of infinintes and also ideas how to solve that problem. Yes, that would work. Any build system guru who could implement that? I think it is not a good idea to put that into wined3d
Re: Better sound support
On Fri, 11 Apr 2008, Kacper Pluta wrote: [...] I'd also suggest correcting MIDI handling and integrating wine with wineasio, which would enable using VST and VSTi on a quite high level, as well as use other programmes. There's a wineasio project which is in a separate tree, partly for licensing reasons. See http://sourceforge.net/projects/wineasio for more details. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Demander si un ordinateur peut penser revient
Wine 1.0 status: T minus 61 days, 69 bugs to go
19 days to code freeze (!) Big news of the week is an apparant regression in one of the release criteria apps. Also, happily, two bugs I had pushed off to 1.2 got fixed anyway (demonstrating the honorary nature of the release manager position :-) Changes since last week: Deferred earlier, but fixed anyway: 3534user32 14 Systray icons are not transparent... Deferred earlier, but patch that really fixes it submitted, so undeferred: 10905 shell32 0 thinstall firefox demo requires native msvcrt Deferred: 6254 richedit4 Installer infinite loop from rich text error New: 12561 -unknown 0 Photoshop CS alt key for clone/healing - possible regression Here's the full list of current bugs: 11420 advapi32 0 service control manager API problem: name of named objects might differ (client vs. service process) 556 build-en 1 Reconcile the Windows and Wine spec files 1114 comctl32 3 Winrar2.90/3.00: Comboex doesn't trigger a event when you mouse-click in some value of it 2493 comctl32 2 Multi-select listview: Shift-arrow up only selects top two items 4372 comctl32 1 listview: cannot drag several items 11509 crypt32 0 Wordviewer 2003 is unable to open documents encrypted with AES 5535 directx- 17 Planescape:Torment doesn't work 9030 directx- 0 army men hangs on black screen 11681 directx- 17 Add support for video overlay 3270 gdi32 15 Problem with minimized top-level windows 6519 gdi32 7 Wine blacks out rotated font bitmap 7571 gdi32 1 Accented character glyphs are mixed up with TrueType fonts (affects e.g. Lotus Notes R5) 9771 gdi32 42 Steam Friends doesn't work (fails to render correctly or refresh) 5024 kernel32 4 Thief: Deadly Shadows crashes:page fault on read access to 0x040c 5351 kernel32 11 Windows Installer 3.1 cannot install because of non-standard drive labeling 5541 kernel32 0 WriteConsole can't write to stdout; affects e.g. wsh's cscript's usage message 9039 kernel32 0 GS-Auftrag Professional SQL aborts on startup 9484 kernel32 19 Program refuses to run because of ProtectCD/ProtectDISC copy-protection 7098 mscoree 1 RufzXP crashes on startup, needs mscoree.dll.CorBindToRuntimeEx 8783 ntdll 13 USB serial ports do not work 9356 ntdll 8 Serial communication not working since wine-0.9.33 2539 ole 3 XDND (Drag and drop for X Windows) doesn't copy text 6607 ole 10 Drag and Drop not working 8095 ole 0 PQ Teaching toy crashes 9942 ole 2 Powerpoint Viewer 2007 crashes opening .pptx files 5926 programs 1 Wine does not provide an implementation of winhlp32.exe 5163 setupapi 13 Office XP 2002 crashes on installation 3546 shdocvw 2 CLSID_InternetShortcut not available... 6095 shdocvw 13 MOTD in counter-strike 1.6 and counter-strike source does not render 8898 shdocvw 0 Run Time Error 445: Object doesn't support this action in Europa Knowledgebase 9304 shdocvw 4 Temple of Elemental Evil demo doesn't start - gui irresponsive 8439 shell32 8 Visual Studio .NET (7) install fails 9809 shell32 4 Autodesk Revit Architecture 2008 install fails 10905 shell32 0 thinstall firefox demo requires native msvcrt 11742 shlwapi 9 Small .net 1.1 app (FastMD5 1.3) fails to start up 12074 testcase 2 The conformance tests fail on Windows 6604 tools 3 Ship icons for the wine-tools that can be used in .desktop files 12561 -unknown 0 Photoshop CS alt key for clone/healing - possible regression 5055 -unknown 5 Deleting files from a window in wine doesn't send them to the Trash 5061 -unknown 6 Copying from Windows Firefox in Wine and pasting to Linux OpenOffice pastes metadata as data 5402 -unknown 0 Trying to run PhotoStitch 3.1 5844 -unknown 12 tray minimize 5948 -unknown 1 Star Trek: Armada does not install 7404 -unknown 3 ShowWindow(SW_MINIMIZE) should not generate a WM_PAINT message 7477 -unknown 1 Uplink demo crashes 8125 -unknown 0 Marratech 6.1 crashes on start 9178 -unknown 8 hello world dos program hangs 9916 -unknown 6 make test usually fails 9959 -unknown 9 Make wine updates work even if the registry changed 10147 -unknown 1 Word Viewer 2003 - Tab behavior differs from Windows 10815 -unknown 2 Cannot drag images into Adobe Photoshop 7 from the web / desktop 11281 -unknown 4 CJK input many issues 12097 -unknown 3 Wine 1.0 should not ship out-of-sync resource translations 12246 -unknown 2 make test gives different results with and without warn+heap 664 user327 The help menu functionality inside programs is broken (messaging problem) 3023 user325 Orcad - Place Part never tries to put down a part 4523 user325 Can't copy from Firefox 1.5 and paste into OpenOffice 2 under Wine 124 wineserv 2 Review of Wine Server Protocol 1990 winex11. 1 modifier keys not released when switching desktop 2368 winex11. 7 Wine loses its X-Window when switching to another virt. desktop in Fvwm 3297
Re: Wine 1.0 status: T minus 61 days, 69 bugs to go
On Monday 14 April 2008 04:15:49 Dan Kegel wrote: New: 12561 -unknown 0Photoshop CS alt key for clone/healing - possible regression This is probably related to http://bugs.winehq.org/show_bug.cgi?id=12543 which in turn seems to be caused by the fix for http://bugs.winehq.org/show_bug.cgi?id=11639 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: implement SHGetFolderPathAndSubDirA/W [2nd resend]
On Mon, Mar 31, 2008 at 10:01 AM, Alexandre Julliard
[EMAIL PROTECTED] wrote:
Stefan Leichter [EMAIL PROTECTED] writes:
+if (pszSubPath (length = MultiByteToWideChar(CP_ACP, 0,
pszSubPath, -1, NULL, 0))) {
+pszSubPathW = HeapAlloc(GetProcessHeap(), 0, length *
sizeof(WCHAR));
+if(!pszSubPathW)
+return HRESULT_FROM_WIN32(ERROR_NOT_ENOUGH_MEMORY);
You are leaking memory on error. Also I don't think it makes sense to
test the return value of MultiByteToWideChar, it shouldn't fail in this
case (or if you test it, then you need to handle the error properly, not
use an empty path instead).
--
Alexandre Julliard
[EMAIL PROTECTED]
Stefan,
Any progress on this?
--
Zachary Goldberg
Computer Science Engineering
Electrical Captain of Penn Electric Race Team
School of Engineering at the University of Pennsylvania
