New winetricks 20080309: new verb 'icodecs'
Intel codecs are needed to run Tonka Search & Rescue 2 (which my son likes), so I added them to winetricks as 'icodecs'. I also renamed allvcodecs to be allcodecs (since it's hard to separate audio from video codecs sometimes) and removed a spurious warning from wsh56. As always, winetricks is at http://kegel.com/wine/winetricks and http://winezeug.googlecode.com
Please remove/block DARKGuy user from the forum and user mailing list!
What the subject say.
Processes and ioctl's
Hi all, I am hitting a snag with moving ioctl handling into mount manager. I got the ioctl's working and itunes fairly satisfied, but now I'm hitting another problem: The mount manager is not in the same process any more as the application. This is an issue because one of the ioctl's is passing a pointer in the struct itself, which gives a messy situation if it doesn't run in the current application any more. A workaround would be to use ReadProcessMemory and WriteProcessMemory, then fudge the wineserver ioctl request to somehow pass a handle of the calling process around so I can use that. This looks like it is not a clean solution. Does anyone know how to do it cleanly? Cheers, Maarten.
Re: [PATCH] qedit: use skip in MediaDet test
On Thu, Feb 21, 2008 at 5:15 PM, Lei Zhang <[EMAIL PROTECTED]> wrote: > Hi, > > Dank pointed out the qedit test crashes with an old .wine directory. > Adding a skip(). > Any reason why this wasn't committed?
Re: [PATCH 3/3] shell32: use well known directories from xdg-user-dirs (try 2)
On Wed, Mar 5, 2008 at 8:41 PM, Lei Zhang <[EMAIL PROTECTED]> wrote: > Hi, > > This sets the shell folders using values from xdg-user-dirs. The > existing shell folder code checks the shell folder registry keys, and > will not overwrite the values we set here. > > This version converts the Unix paths to Unicode when needed. > It just occurred to me that I need to convert the Unix path to a dos path. Should I just send the updated version of this patch, or resend the first two patches in the series as well?
Re: Fwd: Re: RegOverridePredefKey stub - Take 2
Jens Nestler wrote: > Hello, > six weeks ago I've sent this patch for a basic implementation of the > RegOverridePredefKey function. > Unfortunately the patch was not considered till now. > Can everybody help me ? > You have some extra pieces in this patch. When you are submitting patch - make sure only one thing is being changed. Here you have some irrelevant changes in your patch. Vitaliy.
Fwd: Re: RegOverridePredefKey stub - Take 2
Hello,
six weeks ago I've sent this patch for a basic implementation of the
RegOverridePredefKey function.
Unfortunately the patch was not considered till now.
Can everybody help me ?
Jens
--- Begin Message ---
Am Dienstag, 29. Januar 2008 14:44:35 schrieb Dmitry Timoshkov:
> "Jens Nestler" <[EMAIL PROTECTED]> wrote:
> > Sorry, I haven't seen it.
> > Can you please change it, or should I deliver a changed patch ?
>
> Please resend and updated patch with a 'Take 2' in the subject and
> an explanation in the body what's changed.
Stub implementation for RegOverridePredefKey.
The added prototype in the winreg.h is now in alphabetical order.
Jens
diff -urN wine-0.9.54_org/dlls/advapi32/advapi32.spec wine-0.9.54/dlls/advapi32/advapi32.spec
--- wine-0.9.54_org/dlls/advapi32/advapi32.spec 2008-01-25 17:05:38.0 +0100
+++ wine-0.9.54/dlls/advapi32/advapi32.spec 2008-02-05 23:42:46.0 +0100
@@ -499,7 +499,7 @@
@ stdcall RegOpenKeyExW(long wstr long long ptr)
@ stdcall RegOpenKeyW(long wstr ptr)
@ stdcall RegOpenUserClassesRoot(ptr long long ptr)
-@ stub RegOverridePredefKey
+@ stdcall RegOverridePredefKey(long long)
@ stdcall RegQueryInfoKeyA(long ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr)
@ stdcall RegQueryInfoKeyW(long ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr)
@ stdcall RegQueryMultipleValuesA(long ptr long ptr ptr)
diff -urN wine-0.9.54_org/dlls/advapi32/registry.c wine-0.9.54/dlls/advapi32/registry.c
--- wine-0.9.54_org/dlls/advapi32/registry.c 2008-01-25 17:05:38.0 +0100
+++ wine-0.9.54/dlls/advapi32/registry.c 2008-02-05 23:42:46.0 +0100
@@ -2408,6 +2408,31 @@
}
/**
+ * RegOverridePredefKey [EMAIL PROTECTED]
+ *
+ * Map a predefined key to another key.
+ *
+ * PARAMS
+ * hkey [I] Handle of a key to map, could be:
+ * HKEY_CLASSES_ROOT / HKEY_CURRENT_CONFIG / HKEY_CURRENT_USER / HKEY_LOCAL_MACHINE / HKEY_PERFORMANCE_DATA / HKEY_USERS
+ * hNewHKey [I] Handle to an open key hkey is mapped to.
+ * RegOverridePredefKey restores the original mapping, if NULL is given
+ *
+ * RETURNS
+ * Success: ERROR_SUCCESS
+ * Failure: nonzero error code from Winerror.h
+ *
+ * FIXME
+ * function must be implemented
+ */
+
+LSTATUS WINAPI RegOverridePredefKey(HKEY hKey, HKEY hNewHKey)
+{
+FIXME("(%p, %p) stub\n", hKey, hNewHKey);
+return ERROR_CALL_NOT_IMPLEMENTED;
+}
+
+/**
* load_string [Internal]
*
* This is basically a copy of user32/resource.c's LoadStringW. Necessary to
diff -urN wine-0.9.54_org/dlls/kernel32/path.c wine-0.9.54/dlls/kernel32/path.c
--- wine-0.9.54_org/dlls/kernel32/path.c 2008-01-25 17:05:38.0 +0100
+++ wine-0.9.54/dlls/kernel32/path.c 2008-01-28 22:59:19.0 +0100
@@ -1042,15 +1042,6 @@
goto error;
}
-if (info.FileAttributes & FILE_ATTRIBUTE_DIRECTORY)
-{
-if (flag & MOVEFILE_REPLACE_EXISTING) /* cannot replace directory */
-{
-SetLastError( ERROR_INVALID_PARAMETER );
-goto error;
-}
-}
-
/* we must have write access to the destination, and it must */
/* not exist except if MOVEFILE_REPLACE_EXISTING is set */
@@ -1061,7 +1052,7 @@
}
status = NtOpenFile( &dest_handle, GENERIC_READ | GENERIC_WRITE, &attr, &io, 0,
FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT );
-if (status == STATUS_SUCCESS)
+if (status == STATUS_SUCCESS) /* destination exists */
{
NtClose( dest_handle );
if (!(flag & MOVEFILE_REPLACE_EXISTING))
@@ -1070,6 +1061,11 @@
RtlFreeUnicodeString( &nt_name );
goto error;
}
+else if (info.FileAttributes & FILE_ATTRIBUTE_DIRECTORY) /* cannot replace directory */
+{
+SetLastError( ERROR_ACCESS_DENIED );
+goto error;
+}
}
else if (status != STATUS_OBJECT_NAME_NOT_FOUND)
{
diff -urN wine-0.9.54_org/include/winreg.h wine-0.9.54/include/winreg.h
--- wine-0.9.54_org/include/winreg.h 2008-01-25 17:05:38.0 +0100
+++ wine-0.9.54/include/winreg.h 2008-02-05 23:44:46.0 +0100
@@ -143,6 +143,7 @@
WINADVAPI LSTATUS WINAPI RegOpenKeyExA(HKEY,LPCSTR,DWORD,REGSAM,PHKEY);
#defineRegOpenKeyEx WINELIB_NAME_AW(RegOpenKeyEx)
WINADVAPI LSTATUS WINAPI RegOpenUserClassesRoot(HANDLE,DWORD,REGSAM,PHKEY);
+WINADVAPI LSTATUS WINAPI RegOverridePredefKey(HKEY,HKEY);
WINADVAPI LSTATUS WINAPI RegQueryInfoKeyW(HKEY,LPWSTR,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPFILETIME);
WINADVAPI LSTATUS WINAPI RegQueryInfoKeyA(HKEY,LPSTR,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPDWORD,LPFILETIME);
#defineRegQueryInfoKey WINELIB_NAME_AW(RegQueryInfoKey)
--- End Message ---
Re: [PATCH 6/6] wined3d: Dirtify p8 textures when device palettes change.
> Hi Stefan, > > About implementing ddraw-style palette on top of device palettes - I think > this > way we would create more issues than we solve by it. As far as I'm > concerned, I > don't feel like there's a lot of confusion coming from the fact there are > two > palette interfaces, although there is some confusion primarily because > device > palettes are used for ddraw purposes, mainly storing p8 primary surface's > palette. That isn't a big trouble to avoid, as same can be done by > accessing > dds_primary, I believe. > > If ddraw palettes are mapped onto d3d8 style ones, then we need a > mechanism of > allocating palette numbers and freeing them as needed. For example, AVP1 > does > palette creation/destruction a LOT (every frame or every few frames), so > it's > not an unrealistic possibility to run out of palettes, if 65536 limit is > kept > and something is done wrong. > > You may be right about checking palette in IWineD3D*Texture::PreLoad. I > guess > the palette9_changed call could simply be moved to PreLoad and it would > accomplish something like that. > > Stefan Dösinger wrote: > > Am Sonntag, 9. März 2008 15:10:54 schrieb Alexander Dorofeyev: > >> Fixes problems with properly updating wine's P8 textures, when it is > >> required because of device palette change. > > Instead of iterating over all resources and finding P8 textures I think > it > > would be nicer to store the palette the texture/surface was loaded with > in > > each P8 / A8P8 surface and compare this stored palette to the current > device > > palette in IWineD3DSurface::PreLoad(non-texture path) and > > IWineD3D*Texture::PreLoad. > > > > With this, patch 4 could maybe be made nicer as well. If we have to > verify the > > palettes anyway, we can remove the DDraw-Style IWineD3DPalette interface > from > > WineD3D altogether, and just give each ddraw palette in ddraw.dll a > WineD3D > > palette number and use the d3d8/9 palette management exclusively in > WineD3D > > and avoid the confusion of having two palette interfaces. > > I think we should continue splitting the ddraw and d3d8/9 palette interfaces. It took me a long time to get the ddraw in a reasonable shape (there are a few small issues left). There are differences and I think we get issues down the road if we don't explicitly split it like it is now. (at least you would get a lot of dxversion checks). It is just that right now a few places which don't need the device palette code have it in (I mean there are places left which use the device palette when there is none set e.g. read_from_framebuffer, RealizePalette and others). Roderick -- Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! http://games.entertainment.gmx.net/de/entertainment/games/free
Re: oleacc: add GetOleaccVersionInfo
On 09/03/2008, Reece Dunn <[EMAIL PROTECTED]> wrote: > On 09/03/2008, Louis. Lenders <[EMAIL PROTECTED]> wrote: > > > > Hi, this fixes crash in DietPower: > > http://bugs.winehq.org/show_bug.cgi?id=10102 > > > > +@ stdcall GetOleaccVersionInfo(long long) > > Since both these arguments are DWORD*, they need to be ptr, not long. Sorry for spamming wine-patches. I hit Reply to all without checking the CC list. - Reece
Re: oleacc: add GetOleaccVersionInfo
On 09/03/2008, Louis. Lenders <[EMAIL PROTECTED]> wrote: > > Hi, this fixes crash in DietPower: > http://bugs.winehq.org/show_bug.cgi?id=10102 > +@ stdcall GetOleaccVersionInfo(long long) Since both these arguments are DWORD*, they need to be ptr, not long. - Reece
Re: [PATCH 6/6] wined3d: Dirtify p8 textures when device palettes change.
Hi Stefan, About implementing ddraw-style palette on top of device palettes - I think this way we would create more issues than we solve by it. As far as I'm concerned, I don't feel like there's a lot of confusion coming from the fact there are two palette interfaces, although there is some confusion primarily because device palettes are used for ddraw purposes, mainly storing p8 primary surface's palette. That isn't a big trouble to avoid, as same can be done by accessing dds_primary, I believe. If ddraw palettes are mapped onto d3d8 style ones, then we need a mechanism of allocating palette numbers and freeing them as needed. For example, AVP1 does palette creation/destruction a LOT (every frame or every few frames), so it's not an unrealistic possibility to run out of palettes, if 65536 limit is kept and something is done wrong. You may be right about checking palette in IWineD3D*Texture::PreLoad. I guess the palette9_changed call could simply be moved to PreLoad and it would accomplish something like that. Stefan Dösinger wrote: > Am Sonntag, 9. März 2008 15:10:54 schrieb Alexander Dorofeyev: >> Fixes problems with properly updating wine's P8 textures, when it is >> required because of device palette change. > Instead of iterating over all resources and finding P8 textures I think it > would be nicer to store the palette the texture/surface was loaded with in > each P8 / A8P8 surface and compare this stored palette to the current device > palette in IWineD3DSurface::PreLoad(non-texture path) and > IWineD3D*Texture::PreLoad. > > With this, patch 4 could maybe be made nicer as well. If we have to verify > the > palettes anyway, we can remove the DDraw-Style IWineD3DPalette interface from > WineD3D altogether, and just give each ddraw palette in ddraw.dll a WineD3D > palette number and use the d3d8/9 palette management exclusively in WineD3D > and avoid the confusion of having two palette interfaces.
Re: Implementing a new Direct3D function
Le Sunday 09 March 2008 18:35:16 [EMAIL PROTECTED], vous avez écrit : > D3DXGetImageInfoFromFile takes the D3DXIMAGE_INFO structure as parameter, > which has changed between d3dx8 an dd3dx9_36 though. > This means you can't forward the D3DXGetImageInfoFromFile calls from d3dx9 > to d3dx8, (even if it is done like that atm, you should fix that an you > patch) so you'll have to write two versions of each. > Our plan for implementing d3dx was to keep any d3dx code away from wined3d, > so you don't have to change anything about that. > So basically all you have to do is > (1) implement the d3dx8 version of each function > (2) add them to the d3dx8 specfile > (3) implement the d3dx9_36 version of each function > (3) correct the d3dx9_36 specfile (i.e. remove the forwarding to d3dx8) > > The d3dx9_24 to 35 dlls forward their calls to d3dx9_36, so they are okay, > too. > > > Tony > > > > > Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain > inkl. > http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i >ndex.html OK, then I'll do this that way. Also, d3dx9 provides support for multiple file format (PNG, TGA, BMP...). I assume I'll have to add those dependencies in the build process. ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Re: Implementing a new Direct3D function
Am Sonntag, 9. März 2008 11:48:08 schrieb Jérôme Gardou: > I'm trying to implement some direct3d functions, more precisely the > GetImageInfoFromFile* ones. > > These are present in directX 8 and in d3dx9_xx.dll > > I wondered what is the best way to do this : > 1)Implementing it in d3dx8.dll and forward everything to this one. This is the way that was chosen for the other functions, so I think it is the way to go in this case as well signature.asc Description: This is a digitally signed message part.
Re: [PATCH 6/6] wined3d: Dirtify p8 textures when device palettes change.
Am Sonntag, 9. März 2008 15:10:54 schrieb Alexander Dorofeyev: > Fixes problems with properly updating wine's P8 textures, when it is > required because of device palette change. Instead of iterating over all resources and finding P8 textures I think it would be nicer to store the palette the texture/surface was loaded with in each P8 / A8P8 surface and compare this stored palette to the current device palette in IWineD3DSurface::PreLoad(non-texture path) and IWineD3D*Texture::PreLoad. With this, patch 4 could maybe be made nicer as well. If we have to verify the palettes anyway, we can remove the DDraw-Style IWineD3DPalette interface from WineD3D altogether, and just give each ddraw palette in ddraw.dll a WineD3D palette number and use the d3d8/9 palette management exclusively in WineD3D and avoid the confusion of having two palette interfaces. signature.asc Description: This is a digitally signed message part.
Re: [PATCH 4/6] wined3d: Make code safe if there are no device palettes.
Roderick Colenbrander wrote: > First of all it appears that this patch contains multiple patches (e.g. the > direct3d9 getdc p8 check is one). I'll mention some others below. The p8 code > is very sensitive to bugs and those are most of the time very hard to fix, so > I'm quite strict. Various things need to be tested using testcases before > this patch (cut in pieces) can make it in. All changes are functionally related (direct3d9 format check ensures any palette-related code below it will be ddraw/d3d <= 7 only), but ok, I guess it's possible to cut it into several pieces. > In case of read_from_framebuffer when there is no palette set, just return > directly instead of adding an if(pal) check. The function won't do anything > useful without a palette. Further read_from_framebuffer shouldn't get called > from d3d8/9 games anyway as there aren't p8 render targets. Agree about this. > I wonder if we need SetDibColorTable at all in case of GetDC as the data the > app will receive in the hdc is 8bit. It wants to draw in it by hand, so I > would say that the palette won't matter. It might require a testcase. I have no idea if any app actually uses it, but, hypothetically, it can call GetDIBColorTable, which seems to return meaningful results on native. > The removal of the device palette code from RealizePalette can be done in a > separate patch. > > I'm not sure if change in SetColorKey is correct in the case a surface > doesn't have a palette and uses the primary surface its palette. It doesn't > feel right. I think it should fail but this requires a testcase. > > Second even if the call to SetDibColorTable is needed I wonder what should > happen on surfaces which don't have a palette set. It might be correct to use > the palette of the primary surface but it might also just be an illegal > situation. I assume you mean GetDC because I didn't change SetColorKey. I did some tests in windows XP, if you obtain a dc from offscreen surface without a palette, then call GetDIBColorTable on this dc, you get a color table that matches palette of primary surface. I just replicated the existing functionality in Wine which was doing the same only using device palette as intermediary storage of primary palette: when setting palette to primary surface, entries were copied to current device palette, but when palette is missing in GetDC it was using current device palette that's the same as primary surface palette. I guess it's most likely obscure and unused functionality, but who knows if there's something that may rely on it. I can integrate a test for this scenario (GetDC/GetDIBColorTable with offscreen surface that has not palette and compare it to primary surface palette) into ddraw testcases, if needed. Do you have ideas what else can be tested?
Re: [comctl32/tests #3] Use GetModuleHandleA instead of LoadLibraryA
Mikołaj Zalewski wrote: > I've changed GetModuleHandle to LoadLibrary because when I compiled > only tests/rebar.c as standalone, the comctl32 wasn't loaded and > GetModuleHandle returned NULL. Are there advantages from using > GetModuleHandle? > > Mikołaj Zalewski > Well, I was checking whether LoadLibrary was accompanied by a FreeLibrary. In this case it wasn't and I thought GetModuleHandle does the trick as well. It did for the other stuff in the comctl32 tests. I'm not in favor of LoadLibrary or GetModuleHandle. I think the general rule could be: If dll is already imported use GetModuleHandle unless compilation excludes the dll because there are no reference to the dll. Does that look a bit sane? The question that remains is should the full -tests be able to be compiled and run or should we have this to be correct for every single test? I mean that are no issues if you compile the whole comctl32 "testsuite". If LoadLibrary is indeed needed it should be accompanied with a FreeLibrary and we probably need a comment for the why as well. -- Cheers, Paul.
Re: [comctl32/tests #3] Use GetModuleHandleA instead of LoadLibraryA
I've changed GetModuleHandle to LoadLibrary because when I compiled only tests/rebar.c as standalone, the comctl32 wasn't loaded and GetModuleHandle returned NULL. Are there advantages from using GetModuleHandle? Mikołaj Zalewski
Re: [PATCH 4/6] wined3d: Make code safe if there are no device palettes.
> There are two types of palettes in wined3d: directx <= 7 style palettes as > separate interface and d3d >= 8 style device palettes. Some code was > defaulting > to device palettes in several places if there's no "old" style palette and > using > device palettes to store ddraw primary surface's palette. This patch > avoids use > of device palettes for anything else than their direct purpose. It is a > necessary preparation for making device palettes dynamically allocated as > needed > (next patch), that prevents ddraw apps from crashing with the latter. > --- > dlls/wined3d/palette.c | 11 > dlls/wined3d/surface.c | 109 > ++ > dlls/wined3d/surface_base.c | 20 ++-- > dlls/wined3d/surface_gdi.c | 51 > 4 files changed, 82 insertions(+), 109 deletions(-) First of all it appears that this patch contains multiple patches (e.g. the direct3d9 getdc p8 check is one). I'll mention some others below. The p8 code is very sensitive to bugs and those are most of the time very hard to fix, so I'm quite strict. Various things need to be tested using testcases before this patch (cut in pieces) can make it in. In case of read_from_framebuffer when there is no palette set, just return directly instead of adding an if(pal) check. The function won't do anything useful without a palette. Further read_from_framebuffer shouldn't get called from d3d8/9 games anyway as there aren't p8 render targets. I wonder if we need SetDibColorTable at all in case of GetDC as the data the app will receive in the hdc is 8bit. It wants to draw in it by hand, so I would say that the palette won't matter. It might require a testcase. The removal of the device palette code from RealizePalette can be done in a separate patch. I'm not sure if change in SetColorKey is correct in the case a surface doesn't have a palette and uses the primary surface its palette. It doesn't feel right. I think it should fail but this requires a testcase. Second even if the call to SetDibColorTable is needed I wonder what should happen on surfaces which don't have a palette set. It might be correct to use the palette of the primary surface but it might also just be an illegal situation. Roderick -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
Implementing a new Direct3D function
I'm trying to implement some direct3d functions, more precisely the GetImageInfoFromFile* ones. These are present in directX 8 and in d3dx9_xx.dll I wondered what is the best way to do this : 1)Implementing it in d3dx8.dll and forward everything to this one. 2) Make some useful functions in wined3d and then use them from d3dx8. 3) Implement them directly in wined3d, forwarding everything to it. 4) An other way ? Cheers. Jérôme ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
