Re: ntdll: remove an unnecessary NULL check : Coverity
Jeff L [EMAIL PROTECTED] wrote: Looking a bit further it seems that NtCreateMailslotFile is only called from CreateMailslotW. If there is a problem with a NULL then it stems from there. http://source.winehq.org/ident?i=CreateMailslotW NtCreateMailslotFile is a public API, so probably it should handle the case when attr is NULL. I see the same problem at least in NtCreateNamedPipeFile. In general, handling of OBJECT_ATTRIBUTES in ntdll is not consistent, but fixing it properly most likely a test is needed to see what Windows does in that case. -- Dmitry.
Re: ntdll: remove an unnecessary NULL check : Coverity
Dmitry Timoshkov wrote: NtCreateMailslotFile is a public API, so probably it should handle the case when attr is NULL. I see the same problem at least in NtCreateNamedPipeFile. In general, handling of OBJECT_ATTRIBUTES in ntdll is not consistent, but fixing it properly most likely a test is needed to see what Windows does in that case. Thanks for that, I will see what I can do about creating a suitable test. Jeff
Re: dbghelp: Search for .gnu_debuglink file
Frank Richter a écrit : The .gnu_debuglink section contains only a bare filename, however, the debug file can be in a number of locations. These are stated in the GDB manual and are now searched when a .gnu_debuglink is encountered. Frank, a couple of remarks: - there are memory leaks in the code (moduleDir can be leaked, as well as the newly found pathname) - for the code to still be readable, I'd rather but in a single function all the processing required, ie. do it the same way as for the other debug information: if the .gnu_debuglink section is found, map it, and then let this new function handle the lot A+
World of Warcraft Progress
Ahoy! First off, I'd like to say happy 2007! Hope you all did some good celebrating. I know I did ;) Anyway, I've been doing some testing on World of Warcraft, and I noticed some things of interest (Latest wine version from cvs/git, no patches applied). First off, the D3D (DX9) runs MUCH better (faster and more smoothly) than the OGL mode. Big kudos to you guys; last time I played, the D3D mode was completely unusable because there was no D3D support in wine. Very impressive. The OGL performance isn't bad by any means, but it isn't great either. I was running some traces as I played, but nothing in particular seemed to be the culprit in terms of choppiness, so it's possible that it could just be my system. I'll write back soon when I have more conclusive evidence. Additionally, OGL mode crashes any time I attempt to change a video setting, something that does not happen in D3D mode. The load time (both startup and between zones/etc) is at least 10x faster than it used to be. I know that Blizzard has been working on this a bit, but based on what I've seen on systems running Windows, the load time reduction seems largely due to improvements in wine. I guess my only real complaint at this point, since the D3D mode woks so well, is that the X cursor still shows up in the game window along with the game cursor. I vaguely recall having this problem a long long time ago in OGL mode, but I can't remember exactly what caused it or how it was fixed. Anyone have a better memory than I do? That's pretty much the state of WoW at the moment. Comments/Questions/Solutions?
Re: wininet: ensure null check before dereference
On 1/1/07, Jeff Latimer [EMAIL PROTECTED] wrote: Coverity cid: 367 Do the null check before the dereference. Given that this is an simple internal function, do we need to check for null pointers? Generally we don't check for NULL params in internal functions. -- James Hawkins
Re: [9/16] WineD3D: Move decoding the vertex declaration to the device
Am 02.01.2007 um 05:38 schrieb Ivan Gyurdiev: +if (stateblock-wineD3DDevice-vs_selected_mode != SHADER_NONE stateblock-vertexShader + ((IWineD3DVertexShaderImpl *) stateblock-vertexShader)-baseShader.function != NULL) +memcpy(stateblock-wineD3DDevice-strided_streams, stateblock-wineD3DDevice-up_strided, sizeof(stateblock- wineD3DDevice-strided_streams)); +primitiveDeclarationConvertToStridedData ((IWineD3DDevice *) stateblock-wineD3DDevice, useVertexShaderFunction, +stateblock- wineD3DDevice-strided_streams, stateblock-wineD3DDevice- streamFixedUp); My eyes hurt - can we *please* store the device in a local variable. Ok, I can change that :-) Also, I am not sure how we got to the point where this many upward references to the device from the stateblock are necessary - there has to be something wrong with that: a stateblock captures the state of a device, so why is it referring back to its parent device and looking up state there? This type of thing was introduced into the shader code as well, and IIRC it was wrong there too. I knew you'd come up with that :-) . My plan is to remove all the upward references to the device later on and store most of the things stored in the device in a seperate context variable, which is passed to the state handlers. But for now I want to keep the code unchanged as much as possible, and thus work with the device everywhere. Also, all this transient data from the drawprim codepath moved into the device - can you explain again why that's necessary, does it really need to persist after the drawprim call? Yes, most of the data stays valid and can be used after the drawprim finished. The decoded vertex declaration is valid until the next SetStreamSource, SetVertexDeclaration, SetFVF or SetVertexShader call. Future drawprim calls can reuse it, and the Vertex Buffer Preload function can access it too(instead having to do its own decoding to get exactly the same result)
Re: World of Warcraft Progress
Am 02.01.2007 um 09:51 schrieb darckness: First off, the D3D (DX9) runs MUCH better (faster and more smoothly) than the OGL mode. Big kudos to you guys; last time I played, the D3D mode was completely unusable because there was no D3D support in wine. Very impressive. Nice :-) The OGL performance isn't bad by any means, but it isn't great either. I was running some traces as I played, but nothing in particular seemed to be the culprit in terms of choppiness, so it's possible that it could just be my system. I'll write back soon when I have more conclusive evidence. Additionally, OGL mode crashes any time I attempt to change a video setting, something that does not happen in D3D mode. The d3d renderer of wow is said to be much better than the ogl renderer, even under windows. And I think there is a bug in wow which causes performance issues with the GL_ARB_vertex_buffer_object extension, you can bypass this by blacklisting it with a registry key. I guess my only real complaint at this point, since the D3D mode woks so well, is that the X cursor still shows up in the game window along with the game cursor. I vaguely recall having this problem a long long time ago in OGL mode, but I can't remember exactly what caused it or how it was fixed. Anyone have a better memory than I do? Yes, that is a known problem. We haven't figured out yet when the cursor is shown or hidden exactly, but for wow it seems that we have to hide the cursor on the IDirect3DDevice9::SetCursorProperties call which sets a d3d cursor. Unfortunately wow only calls that if hw cursors are enabled, but wine doesn't do that yet. Henri Verbeet has some patches needed for that, but they are pretty huge and affect the core cursor handling down to wineserver.
Re: dlls/opengl32/wgl.c: minor dealloc fix
On Tuesday 02 January 2007 02:40, Nick Burns wrote: However, this seems dangerous if you wanted to take any of that code and run it under windows (but im guessing xp and 2k work this way -- and few people use 95/98/me anymore) There are win98 tests run on test.winehq.org. You can check there if the HeapFree() works there. Where is a good place for api docs other than the MSDN? (and no source does not count as good api docs) I'm afraid the Wine source is the most complete win32 api doc apart from MSDN. It seems like Microsoft should be notified of incorrect/incomplete api docs -- so they can correct them (but sadly this is a huge thankless task...) I sort of doubt they'll fix it for us. They didn't fix it for the EU. Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgptSS2lFqOQs.pgp Description: PGP signature
Re: systray [2]: transparent icons: let systray window responsible for background
Kirill K. Smirnov [EMAIL PROTECTED] writes: @@ -366,6 +366,7 @@ static void systray_dock_window( Display wine_tsx11_lock(); XSendEvent( display, systray_window, False, NoEventMask, ev ); +XSetWindowBackgroundPixmap(display, data-whole_window, ParentRelative); wine_tsx11_unlock(); This won't really do what you want. You have to set the window shape if you want the background to be properly transparent. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Resend: d3d9: fix failing tests on windows, when no 3d hardware acceleration is available
Louis. Lenders [EMAIL PROTECTED] writes:
Hi, is there anything wrong with this patch? If so, could you please tell me
what. Thx
I fixed it up, but next time please try to respect the indentation
style of the existing file. We don't have any place that uses a
strange style like this:
+if(FAILED(hr))
+ {
+ trace(could not create device, IDirect3D9_CreateDevice returned
%#x\n, hr);
+ goto cleanup;
+ }
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Resend: d3d9: fix failing tests on windows, when no 3d hardware acceleration is available
Louis. Lenders wrote: Hi, is there anything wrong with this patch? If so, could you please tell me what. Thx */Louis. Lenders [EMAIL PROTECTED]/* wrote: Hi, this patch should fix failing tests in d3d9, like you see for example here: http://test.winehq.org/data/200612231000/ Appearently the tests in stateblock.c didn't need to be modified, as they create the device with flag D3DDEVTYPE_NULLREF; these tests do not fail anywhere. thanks for some advice from stringfellow So why not fallback to REF or NULLREF type of device everywhere else if HAL is unavailable? Do those tests need HAL support in the first place?
Re: Resend: d3d9: fix failing tests on windows, when no 3d hardware acceleration is available
Am 02.01.2007 um 13:45 schrieb Ivan Gyurdiev: So why not fallback to REF or NULLREF type of device everywhere else if HAL is unavailable? Do those tests need HAL support in the first place? There are some differences between HAL and REF which are important to some games. Refcount tests are ok with NULLREF, but for other things we have to take the driver into account.
Re: World of Warcraft Progress
darckness wrote: First off, the D3D (DX9) runs MUCH better (faster and more smoothly) than the OGL mode. Big kudos to you guys; last time I played, the D3D mode was completely unusable because there was no D3D support in wine. Very impressive. The GLX_ARB_vertex_buffer_object is described on the AppDb page for World of Warcraft and has now been known for quite some time already. If you apply the hack, you'll see that running in OGL and D3D mode won't make a difference in the framerate. I also noticed the modeswitch crash, but I didn't investigate it. I always edit the Config.wtf file if I need to switch modes (or graphics settings). But I'll look into if if nobody else will ;) tom
Re: systray [2]: transparent icons: let systray window responsible for background
Kirill K. Smirnov [EMAIL PROTECTED] writes: @@ -366,6 +366,7 @@ static void systray_dock_window( Display wine_tsx11_lock(); XSendEvent( display, systray_window, False, NoEventMask, ev ); +XSetWindowBackgroundPixmap(display, data-whole_window, ParentRelative); wine_tsx11_unlock(); This won't really do what you want. You have to set the window shape if you want the background to be properly transparent. Now I understand, that the problem is more hard than I think before. 1) The code I sent is the solution... unless the application change icon. In this case new icon is painted over and produces a mixture. 2) If I set window shape to 'AND' bitmap of icon (do I correctly understand you?) then what to do with full transparent icons? E.g. some applications (qip) flashes the icons by changing the icon with full transparent icon and back. a) Will window with NULL shape be created? b) if a) is true, then when I click on null icon will I get any events? For some time I wonder, why kde icons looks good even when they are changing??? The answer is kde applications use KSystemTray directly without XEMBED. xmule to achieve the same goal, removes the icon from systray and adds new one (as I understand it, I may wrong). Shall we use the same mechanism? Any other suggestion?
Re: systray [2]: transparent icons: let systray window responsible for background
Kirill K. Smirnov [EMAIL PROTECTED] writes: 2) If I set window shape to 'AND' bitmap of icon (do I correctly understand you?) then what to do with full transparent icons? E.g. some applications (qip) flashes the icons by changing the icon with full transparent icon and back. a) Will window with NULL shape be created? b) if a) is true, then when I click on null icon will I get any events? No, you'd have to click while the icon is shown. I don't think there's any way to make a window transparent for output but not for input. Not sure it's a big problem though. -- Alexandre Julliard [EMAIL PROTECTED]
Re: quartz: add implementations for AmpFactorToDB and DBToAmpFactor
Hi, Why are you using a lookup table and not just a log10(x) and 10^(x) for the gain - dB conversions? That's how it should be done I think like 10x corresponding to 20dB (assuming signal gain). In your tests it is just: 2000*log10(gain) - 9630 for going to that dB-like scale. Regards, Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: [SPAM] Re: Looking for sound testers
Neil Skrypuch escribió: On Thursday, December 28, 2006 10:04, Maarten Lankhorst wrote: Hi all, I've forward ported the old patches of Davin McCall (dsound.patch). With them I have no more sound underruns etc, I'm therefore looking for other people to test them as well. I'm welcoming comments on how it works and possible issues with it. I also attached my patch to alsa, I'm aware of the things I need to fix for that, but I thought it might be good to test dsound with winealsa, to see if other things still need to be fixed. Cheers, Maarten I've given this a spin with Icewind Dale, and while it does seem to remove the underrun issues (at least I don't see them spit out anymore), the sound still stutters and crackles just as much as before. - Neil With both ALSA and dsound patches applied, the tests hang when trying to play from a 96000Hz buffer. Enabling direct access for the winealsa driver works around this. -- perl -e '$x = 2.4; print sprintf(%.0f + %.0f = %.0f\n, $x, $x, $x + $x);'
Re: atl: Declare some items static
Andrew Talbot wrote: -HRESULT WINAPI AtlModuleLoadTypeLib(_ATL_MODULEW *pM, LPCOLESTR lpszIndex, -BSTR *pbstrPath, ITypeLib **ppTypeLib) +static HRESULT WINAPI AtlModuleLoadTypeLib(_ATL_MODULEW *pM, LPCOLESTR lpszIndex, + BSTR *pbstrPath, ITypeLib **ppTypeLib) Did you try compiling linking this? WINAPI is usually only applied to exported functions. -- Rob Shearman
Re: rpc issues
On 1/1/07, Matthew Edlefsen [EMAIL PROTECTED] wrote: Hi, I've been trying to get a program that uses rpc to work on wine and I've been having some problems (my understanding is that isn't surprising). The goal is to be able to run a rpc server that sits and waits for connections over tcp/ip (It's for doing distributed computing). My first problem was that I was using RpcServerUseProtseq which after looking at the code noticed will always fail with tcp/ip since it passes RpcServerUseProtseqEp NULL for the endpoint which eventually causes rpcrt4_protseq_ncacn_ip_tcp_open_endpoint to call getaddrinfo with NULL for both the ip and port which I guess isn't allowed. Anyways I altered my code to use a given endpoint instead and now it tells me: fixme:rpc:RpcMgmtWaitServerListen not waiting for server calls to finish Ah yes - that one! Does this mean the function just doesn't work? Is there any way around it? It does work. After calling RpcMgmtWaitServerListen, just sleep forever. The RPC function calls come in on a different thread anyway. I assume if it was easy to implement it would have already but just in case what exactly needs to be done to get it working? I was wondering this too, Robert might know. I was also confused by the differences between the online git tree and the LXR/what actually gets downloaded to my computer. To be honest I'm pretty new to wine and linux in general but it would be absolutely wonderful to get this working. Good luck. Thanks in advance - Matt Edlefsen Damjan
Re: [SPAM] Re: Looking for sound testers
Hi all I dont know what you do there guys but ..BEFORE last ALSA related upgrade ( ubuntu feisty ) foobar2000 under wine cannot play mp3 files - AFTER the upgrade ( 2 files I think ) foobar2000 play my files and work EXACT like foobar2000 under XP. I use right now wine 0.9.27 Good job. Sorin 2007/1/2, Alex Villacís Lasso [EMAIL PROTECTED]: Neil Skrypuch escribió: On Thursday, December 28, 2006 10:04, Maarten Lankhorst wrote: Hi all, I've forward ported the old patches of Davin McCall (dsound.patch). With them I have no more sound underruns etc, I'm therefore looking for other people to test them as well. I'm welcoming comments on how it works and possible issues with it. I also attached my patch to alsa, I'm aware of the things I need to fix for that, but I thought it might be good to test dsound with winealsa, to see if other things still need to be fixed. Cheers, Maarten I've given this a spin with Icewind Dale, and while it does seem to remove the underrun issues (at least I don't see them spit out anymore), the sound still stutters and crackles just as much as before. - Neil With both ALSA and dsound patches applied, the tests hang when trying to play from a 96000Hz buffer. Enabling direct access for the winealsa driver works around this. -- perl -e '$x = 2.4; print sprintf(%.0f + %.0f = %.0f\n, $x, $x, $x + $x);' -- Nemes Ioan Sorin
Re: [PATCH 1/3] [Msvcrt]: reset a signal to DFL after it's been used
Eric Pouech [EMAIL PROTECTED] writes:
@@ -455,13 +456,13 @@ static LONG WINAPI msvcrt_exception_filt
case EXCEPTION_FLT_OVERFLOW:
case EXCEPTION_FLT_STACK_CHECK:
case EXCEPTION_FLT_UNDERFLOW:
-if (sighandlers[MSVCRT_SIGFPE])
+if ((handler =3D sighandlers[MSVCRT_SIGFPE]) !=3D MSVCRT_SIG_DFL=
)
{
-if (sighandlers[MSVCRT_SIGFPE] !=3D MSVCRT_SIG_IGN)
+sighandlers[MSVCRT_SIGSEGV] =3D MSVCRT_SIG_DFL;
+if (handler !=3D MSVCRT_SIG_IGN)
You have to check for SIG_IGN first, the handler should not be reset
in that case.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [PATCH] [DbgHelp]: implemented 64 bit versions of EnumerateLoadedModules
Eric Pouech [EMAIL PROTECTED] writes:
+BOOL WINAPI EnumerateLoadedModulesW64(HANDLE hProcess,
+ PENUMLOADED_MODULES_CALLBACKW64 E=
numLoadedModulesCallback,
+ PVOID UserContext)
+{
+struct enum_load_mod64_W64 x;
+
+x.cb =3D EnumLoadedModulesCallback;
+x.user =3D UserContext;
+
+return EnumerateLoadedModules64(hProcess, enum_load_mod64_W64, x);
You should make the A function call the W one, not the other way
around.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [PATCH] [ImageHlp]: MapAndLoad
Eric Pouech [EMAIL PROTECTED] writes: @@ -199,7 +204,10 @@ BOOL WINAPI MapAndLoad(LPSTR pszImageNam ((LPBYTE) pNtHeader-OptionalHeader + pNtHeader-FileHeader.SizeOfOptionalHeader); pLoadedImage-NumberOfSections =3D pNtHeader-FileHeader.NumberOfSec= tions; -pLoadedImage-SizeOfImage =3D pNtHeader-OptionalHeader.SizeOfI= mage; +/* we need to return the size of image which has been mapped */ +pLoadedImage-SizeOfImage =3D pNtHeader-OptionalHeader.SizeOfH= eaders; +for (i =3D 0; i pLoadedImage-NumberOfSections; i++) +pLoadedImage-SizeOfImage +=3D pLoadedImage-Sections[i].SizeOf= RawData; There's no reason that the SizeOfRawData fields would add up to the size of the mapping. You have to use GetFileSize() if you need the true size. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [SPAM] Re: Looking for sound testers
On 1/2/07, SorinN [EMAIL PROTECTED] wrote: Hi all I dont know what you do there guys but ..BEFORE last ALSA related upgrade ( ubuntu feisty ) foobar2000 under wine cannot play mp3 files - AFTER the upgrade ( 2 files I think ) foobar2000 play my files and work EXACT like foobar2000 under XP. I use right now wine 0.9.27 Good job. Sorin 2007/1/2, Alex Villacís Lasso [EMAIL PROTECTED]: Neil Skrypuch escribió: On Thursday, December 28, 2006 10:04, Maarten Lankhorst wrote: Hi all, I've forward ported the old patches of Davin McCall (dsound.patch). With them I have no more sound underruns etc, I'm therefore looking for other people to test them as well. I'm welcoming comments on how it works and possible issues with it. I also attached my patch to alsa, I'm aware of the things I need to fix for that, but I thought it might be good to test dsound with winealsa, to see if other things still need to be fixed. Cheers, Maarten With Galactic Civilizations 2 Dark Avatar (just posted three patches that make it run mostly ok), everything sounds great. Only glitching I have is when I break into the debugger, even with a ton of trace output the sound is still smooth. This is using the git version, but it's been nice and smooth in several different versions I've pulled in the last two weeks.
help with dll
Hi there, My name is Jason. I am trying to compile my windows application under linux. I found that the dll file i use to build mu application links to some other dlls. i was just wondering that when i compile it under linux, do i need to compile with those dlls. if yes, it will be very troublesome since they are quite a lot and i have no access to the header files. thanks Jason Send instant messages to your online friends http://au.messenger.yahoo.com
Re: quartz: add implementations for AmpFactorToDB and DBToAmpFactor
Roderick Colenbrander wrote: Hi, Why are you using a lookup table and not just a log10(x) and 10^(x) for the gain - dB conversions? That's how it should be done I think like 10x corresponding to 20dB (assuming signal gain). In your tests it is just: 2000*log10(gain) - 9630 for going to that dB-like scale. Regards, Roderick That was the only way to get the exact same results as a native dll. For whatever reason Microsoft decided not to use the standard equations like the rest of the world. I assume it was to eliminate the need for floating point calculations. Actually you could use the same equation that the generated the table to go from dB to amp but you can't use an equation to go the other way around because of the weird roundoff errors that result from using a lookup table.
Re: Uniscribe improvements
On Tue, Jan 02, 2007 at 12:42:25PM -0600, * * wrote: Please use your real name. To avoid problems with ligitation later on we need it for tracking. Ciao, Marcus
Re: Uniscribe improvements
On Tuesday 02 January 2007 19:42, * * wrote: StringAnalysis should have a cache object, not save the HDC directly. I agree, although you shouldn't free the cache in ScriptStringFree, the caller is responsible for that. One of the important things about the cache, which wine currently doesn't do, is that the caller is free to select a different font into the HDC after calling ScriptStringAnalyse and Uniscribe is supposed to use the right one. Yes, cache handling is still very basic. If the font changes the cache should be invalidated. It also needs to be ref counted and locked. -Hans
Re: Uniscribe improvements
On 1/2/07, Hans Leidekker [EMAIL PROTECTED] wrote:
On Tuesday 02 January 2007 19:42, * * wrote:
StringAnalysis should have a cache object, not save the HDC directly.
I agree, although you shouldn't free the cache in ScriptStringFree, the
caller is responsible for that.
One of the important things about the cache, which wine currently
doesn't do, is that the caller is free to select a different font into
the HDC after calling ScriptStringAnalyse and Uniscribe is supposed to
use the right one.
Yes, cache handling is still very basic. If the font changes the cache
should be invalidated. It also needs to be ref counted and locked.
According to MSDN, the pending error is to give the calling app a
chance to select the matching font back into the DC if the information
wasn't cached. I think that the get_script_cache function is broken,
in that it should return the pending error if the HDC isn't provided,
since the HDC in the cache might no longer have the same font
selected. However maybe some applications don't deal with the pending
case properly.
{{ Seems with wine-devel the default action isn't reply to list, I've
got to be more careful when replying }}
-- Richard Voigt
-Hans
Re: systray icon questions
On Fri, 2006-12-29 at 11:33 +0300, Kirill K. Smirnov wrote I've tried kde, fluxbox and xfce4 (and fvwm, but it lacks systray). Now I can see that xfce4 suffers from it. I did not noticed that before. So, I suppose a new patch (attached). Does it work correct with GNOME? In xfce is OK. Thanks for pointing the path! I tried your patch, and on GNOME it doesn't seem to have much of an effect (the systray window still had a caption on it.) I also tried it on XFce, where for some weird reason it hung my box. Not sure what's going on there :( Anyway, I did try this once before, and it didn't work. So it seems that this isn't the solution you're hoping for :( Sorry to burst your bubble, James
Re: atl: Declare some items static
Robert Shearman wrote: Did you try compiling linking this? WINAPI is usually only applied to exported functions. Hi Rob, My patch was totally wrong: I think I must have compiled and linked the before version. I infer that an exported function (in the DLL sense) must have external linkage (in the C sense). Thanks, -- Andy.
RE: RFC: Patch better support for DevMode
Anyone have comments in this space?
I am sure that the behavior difference of EnumDisplaySettings{A,W} before
and after window creation is a bug.
I think I will submit this patch (barring any complaints) and try to fix the
behavior difference later.
This is still a solid fix afaict.
Any comments?
- Nick
From: Nick Burns [EMAIL PROTECTED]
To: wine-devel@winehq.com
Subject: RFC: Patch better support for DevMode Date: Mon, 01 Jan 2007
02:56:29 -0800
After looking at the behavior on xp and wine for EnumDisplaySettingsA and
EnumDisplaySettingsW before and after a window has been created (I wrote a
little program to dump the devmodes), I noticed that the devmode structs
that wine gives back are lacking some fields.
Attached is a patch that fills out the devmode structs out quite a bit more
(similar to how XP does it).
This does not fix the issue that when you do not create a window you get
different behavior if you have an emulated desktop (i would like soem help
with this part).
Also attached is log_dev_pfd.zi_ -- it is a zip file (sorry about this but
the log files are too big)
ogl_fullscreen.cpp: source for the app that I used to test
EnumDisplaySettings{A,W}
wine_log_dev_pfd.txt: wine log from app (using an emulated desktop)
nv34_log_dev_pfd.txt: log from nv34 using xp driver
rv250_log_dev_pfd.txt: log from rv250 using xp driver
I would like some help with the behavior difference before and after window
creation (visible in wine_log_dev_pfd.txt -- the fullscreen modes that are
supported should not change)
And would like any comments on the patch
Also -- I would like to get the correct driver names in there and not just
-- desktop/NoRes
- Nick
log_dev_pfd.zi_
winePatchDevModeFill.diff
Re: What to do about apps that require 256-color mode?
On Tuesday January 2 2007 00:43, Dan Kegel wrote: So what's Wine to do? Can we somehow tell Wine to emulate 256 color mode for particular apps? You can try to launch game like this: wine explorer /desktop=Game,800x600 game.exe At least for me this simple trick helps sometimes.
Re: Uniscribe improvements
* * wrote: According to MSDN, the pending error is to give the calling app a chance to select the matching font back into the DC if the information wasn't cached. I think that the get_script_cache function is broken, in that it should return the pending error if the HDC isn't provided, since the HDC in the cache might no longer have the same font selected. However maybe some applications don't deal with the pending case properly. The functionality tests ok in Windows the way it is implemented. What you are asking for is not the way it actually works. Having tested a few applications, they all seem to handle the E_PENDING ok. In Windows the cache contains font info to speed up the uniscribe processing so many apps only pass the psc and not the HDC. There is a rule that once you have an script_cache the caller can't change the font. If he does it is his fault and he can fix it. In our case we currently only seek conformance with Windows. Jeff Latimer
Re: ppviewer.exe MSI failure (PowerPoint 2k3): HowTo assemble a lynch mob?
James Hawkins wrote: On 1/1/07, Andreas Mohr [EMAIL PROTECTED] wrote: Hi all, http://www.microsoft.com/downloads/details.aspx?familyid=428D5727-43AB-4F24-90B7-A94784AF71A4displaylang=en failed to install with some nice MSI failures when I tried it last week on a current Wine version (Ubuntu package 0.9.28, I think). Does that mean that I'm entitled to assemble a capable lynch mob for the guys who were supposed to fix any and all MSI installer issues at CodeWeavers? ;) IMHO ppviewer.exe is important since those people who receive some scripted PowerPoint file (yes, that's even some games!) won't have much luck with OpenOffice Impress, so they're fully dependant on getting ppviewer.exe to work. This installer works fine for me with git wine. It is probably the -2140172307 bug (http://bugs.winehq.org/show_bug.cgi?id=6998 - Tested by me and Vitaliy) doing it. Basically it started happening after 0.9.27 to newer installshield apps. They simply stop installing without error but it wasn't always and was at a random point (then patches after .28 caused it to give a crazy error message and now a patch has been submitted to fix it). The errors seen in the terminal were normal, you tend to get a lot when installing things but they are rarely critical. Ex.
Re: wined3d: state_pointsprite should apply to all texture units
Chris Robinson wrote:
+for (i = 0; i GL_LIMITS(texture_stages); i++) {
+/* Note the WINED3DRS value applies to all textures, but GL has one
+ * per texture, so apply it now ready to be used!
+ */
+if (GL_SUPPORT(ARB_MULTITEXTURE)) {
+GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB + i));
+checkGLcall(glActiveTextureARB);
+} else if (i0) {
+FIXME(Program using multiple concurrent textures which this
opengl implementation doesn't support\n);
+}
I'd do that '} else if (i == 1) {', otherwise you'll print a whole lot
FIXME's, and maybe add a 'break', since it doesn't make sense to call
glTexEnvi() over and over for the same texture.
tom
Re: Uniscribe improvements
On 1/2/07, Jeff L [EMAIL PROTECTED] wrote: * * wrote: According to MSDN, the pending error is to give the calling app a chance to select the matching font back into the DC if the information wasn't cached. I think that the get_script_cache function is broken, in that it should return the pending error if the HDC isn't provided, since the HDC in the cache might no longer have the same font selected. However maybe some applications don't deal with the pending case properly. The functionality tests ok in Windows the way it is implemented. What you are asking for is not the way it actually works. Having tested a few applications, they all seem to handle the E_PENDING ok. In Windows the cache contains font info to speed up the uniscribe processing so many apps only pass the psc and not the HDC. There is a rule that once you have an script_cache the caller can't change the font. If he does it is his fault and he can fix it. In our case we currently only seek conformance with Windows. That's distinctly not what MSDN documentation and the associated example code reads: http://www.microsoft.com/typography/developers/uniscribe/uniscribe.htm http://msdn2.microsoft.com/en-gb/library/ms776467.aspx If the device context is passed as NULL and Uniscribe needs to access it for any reason, Uniscribe returns the error code E_PENDING. This code is returned quickly, allowing the application to avoid time-consuming SelectObject calls. Whereas the current implementation will silently access an HDC even if the application passed NULL, which means the application doesn't get a chance to SelectObject the right font. Jeff Latimer
Re: appdb rating inflation
As Chris Morgan pointed out, http://appdb.winehq.org/help/?sTopic=maintainer_ratings might need clarification. It now says -- snip -- Platinum An application can be rated as Platinum if it installs and runs out of the box No changes required to winecfg. Gold Application works flawlessly with some DLL overrides or other settings, crack etc. Silver Application works excellently for 'normal' use; a game works fine in single-player but not in multi-player, Windows Media Player works fine as a plug-in and stand-alone player, but can't handle DRM etc. -- snip -- I'd like to change this to make it clear that cracks are a no-no for anything Silver and above, and make Platinum and Gold rather more rigorous: -- snip -- Platinum Platinum applications install normally and run flawlessly. No manual editing of files, no winecfg settings, no native DLLs, no third-party install scripts, and no cracks are allowed for a Platinum rating. Gold Gold applications install normally and run well. Some cosmetic problems may be present, but they should not be noticable to the average user. No manual editing of files, no winecfg settings, no native DLLs, no third-party install scripts, and no cracks are allowed for a Gold rating. Silver Application installs and works well for 'normal' use, but some features may be broken. For instance, a game that works fine in single-player but not in multi-player, or a media player that works fine for mp3 files but not for DRM-protected files. No manual editing of files or cracks are allowed for Silver ratings, but winecfg settings, native DLLs, or third-party install scripts may be required. -- snip -- What do people think? - Dan
Re: appdb rating inflation
On 1/2/07, Dan Kegel [EMAIL PROTECTED] wrote: As Chris Morgan pointed out, http://appdb.winehq.org/help/?sTopic=maintainer_ratings might need clarification. It now says -- snip -- Platinum An application can be rated as Platinum if it installs and runs out of the box No changes required to winecfg. Gold Application works flawlessly with some DLL overrides or other settings, crack etc. Silver Application works excellently for 'normal' use; a game works fine in single-player but not in multi-player, Windows Media Player works fine as a plug-in and stand-alone player, but can't handle DRM etc. -- snip -- I'd like to change this to make it clear that cracks are a no-no for anything Silver and above, and make Platinum and Gold rather more rigorous: -- snip -- Platinum Platinum applications install normally and run flawlessly. No manual editing of files, no winecfg settings, no native DLLs, no third-party install scripts, and no cracks are allowed for a Platinum rating. Gold Gold applications install normally and run well. Some cosmetic problems may be present, but they should not be noticable to the average user. No manual editing of files, no winecfg settings, no native DLLs, no third-party install scripts, and no cracks are allowed for a Gold rating. How about still permitting required native DLLs, but only if an installer is available as a download from Microsoft or the application developer (but not third party), and no manual editing on the user's part, manual file copying, settings, or cracks? This would include, for instance, any program that installs and runs after installing MS Installer 3.0 Unicode package. Silver Application installs and works well for 'normal' use, but some features may be broken. For instance, a game that works fine in single-player but not in multi-player, or a media player that works fine for mp3 files but not for DRM-protected files. No manual editing of files or cracks are allowed for Silver ratings, but winecfg settings, native DLLs, or third-party install scripts may be required. -- snip -- What do people think? - Dan
Re: appdb rating inflation
On 03.01.2007 04:00, Dan Kegel wrote: No manual editing of files, no winecfg settings, no native DLLs, no third-party install scripts, and no cracks are allowed for a Platinum rating. Giving a set of points may lead to some people think hey to run MyApplication I just have to some obscure workaround. It's not in the list, so lets rate it platinum!. So maybe put some generalized criterium in front of that list: The application should install and run on a fresh, unmodified Wine, from original installation media. That means, among other things, no manual editing of files, ... OTOH, there are not much obscure workarounds not covered by that list. Manually editing the registry might be one that should be be disallowed. Also, you mentioned apps that only run as root; this might be worthwhile to disallow, too. -f.r.
Re: What to do about apps that require 256-color mode?
On 1/2/07, L. Rahyen [EMAIL PROTECTED] wrote: So what's Wine to do? Can we somehow tell Wine to emulate 256 color mode for particular apps? You can try to launch game like this: wine explorer /desktop=Game,800x600 game.exe At least for me this simple trick helps sometimes. Thanks for the tip. Doesn't help in this case, though. The app sits in a loop, waiting forever for the screen to do something magic, I suppose. +relay output appended for the curious. - Dan ... 000e:Call gdi32.CreateICA(00fae4fc DISPLAY,,,) ret=00f a28b7 000e:Ret gdi32.CreateICA() retval=1208 ret=00fa28b7 000e:Call gdi32.GetDeviceCaps(1208,0008) ret=00fa28ff 000e:Ret gdi32.GetDeviceCaps() retval=0320 ret=00fa28ff ... 000e:Call user32.ChangeDisplaySettingsA(0034f734,0002) ret=00fa21f9 000e:Call winex11.drv.ChangeDisplaySettingsEx(,0034f558,,000 2,) ret=7ec4bb39 000e:Ret winex11.drv.ChangeDisplaySettingsEx() retval= ret=7ec4bb39 000e:Ret user32.ChangeDisplaySettingsA() retval= ret=00fa21f9 000e:Call kernel32.lstrcatA(00fb0420 800 600 16 0 noninterlaced color dynamic\r 320 200 16 0 noninterlaced color dynamic\r400 300 16 0 noninterlaced color dynam ic\r512 384 16 0 noninterlaced color dynamic\r640 480 16 0 noninterlaced color d ynamic\r1024 768 16 0 noninterlaced color dynamic\r800 600 8 0 noninterlaced col or dynamic\r320 200...,00fae148 dynamic) ret=00fa226f 000e:Ret kernel32.lstrcatA() retval=00fb0420 ret=00fa226f 000e:Call user32.EnumDisplaySettingsA(,0012,0034f734) ret=00fa20ce 000e:Call winex11.drv.EnumDisplaySettingsEx(,0012,0034f548,) ret=7ec4bcde 000e:Ret winex11.drv.EnumDisplaySettingsEx() retval= ret=7ec4bcde 000e:Ret user32.EnumDisplaySettingsA() retval= ret=00fa20ce 000e:Call kernel32.GetTickCount() ret=00459289 000e:Ret kernel32.GetTickCount() retval=0002bc87 ret=00459289 000e:Call kernel32.GetTickCount() ret=0049b7c4 000e:Ret kernel32.GetTickCount() retval=0002bc87 ret=0049b7c4 000e:Call user32.PeekMessageA(0034fc58,,,,0001) ret= 0049b823 000e:Call winex11.drv.MsgWaitForMultipleObjectsEx(,,,000 004ff,) ret=7ec34c3b 000e:Ret winex11.drv.MsgWaitForMultipleObjectsEx() retval=0102 ret=7ec34c3b 000e:Ret user32.PeekMessageA() retval= ret=0049b823 000e:Call user32.GetAsyncKeyState(001b) ret=0049b8ab 000e:Call winex11.drv.GetAsyncKeyState(001b) ret=7ec16bb3 000e:Ret winex11.drv.GetAsyncKeyState() retval= ret=7ec16bb3 000e:Ret user32.GetAsyncKeyState() retval= ret=0049b8ab 000e:Call user32.GetAsyncKeyState(0011) ret=0049b8b4 000e:Call winex11.drv.GetAsyncKeyState(0011) ret=7ec16bb3 000e:Ret winex11.drv.GetAsyncKeyState() retval= ret=7ec16bb3 000e:Ret user32.GetAsyncKeyState() retval= ret=0049b8b4 ... repeat above over and over forever.
Re: What to do about apps that require 256-color mode?
On Wednesday January 3 2007 06:22, Dan Kegel wrote: On 1/2/07, L. Rahyen [EMAIL PROTECTED] wrote: So what's Wine to do? Can we somehow tell Wine to emulate 256 color mode for particular apps? You can try to launch game like this: wine explorer /desktop=Game,800x600 game.exe At least for me this simple trick helps sometimes. Thanks for the tip. Doesn't help in this case, though. The app sits in a loop, waiting forever for the screen to do something magic, I suppose. +relay output appended for the curious. Please file a bug report against this bug to bugzilla: http://bugs.winehq.org . If possible add link to demo-version of the game (if it is available of course).
Re: Uniscribe improvements
* * wrote: If the device context is passed as NULL and Uniscribe needs to access it for any reason, Uniscribe returns the error code E_PENDING. This code is returned quickly, allowing the application to avoid time-consuming SelectObject calls. Whereas the current implementation will silently access an HDC even if the application passed NULL, which means the application doesn't get a chance to SelectObject the right font. I have checked how this works by not selecting a font before the first ScriptShape. The test run works as as specified and Windows did not return E_PENDING in this case. My reading of uniscribe is that its not too fussy about what fonts you use and accepts what ever the default is in the HDC. The key thing is that once you have initialised a Script_Cache from a HDC then the font can't be changed cache. Jeff
