Re: [PATCH] windowscodecs: Add support for DIB format.
Christian Costa titan.co...@gmail.com wrote: cpp_quote(DEFINE_GUID(CLSID_WICBmpDecoder, 0x6b462062,0x7cbf,0x400d,0x9f,0xdb,0x81,0x3d,0xd1,0x0f,0x27,0x78);) +cpp_quote(DEFINE_GUID(CLSID_WICDibDecoder, 0x6b462062,0x7cbf,0x400d,0x9f,0xdb,0x81,0x3d,0xd1,0x0f,0x27,0x79);) cpp_quote(DEFINE_GUID(CLSID_WICPngDecoder, 0x389ea17b,0x5078,0x4cde,0xb6,0xef,0x25,0xc1,0x51,0x75,0xc7,0x51);) cpp_quote(DEFINE_GUID(CLSID_WICIcoDecoder, 0xc61bfcdf,0x2e0f,0x4aad,0xa8,0xd7,0xe0,0x6b,0xaf,0xeb,0xcd,0xfe);) cpp_quote(DEFINE_GUID(CLSID_WICJpegDecoder, 0x9456a480,0xe88b,0x43ea,0x9e,0x73,0x0b,0x2d,0x9b,0x71,0xb1,0xca);) @@ -1002,6 +1003,7 @@ cpp_quote(DEFINE_GUID(CLSID_WICWmpEncoder, 0xac4ce3cb,0xe1c1,0x44cd,0x82,0x15,0 cpp_quote(DEFINE_GUID(CLSID_WICDefaultFormatConverter, 0x1a3f11dc,0xb514,0x4b17,0x8c,0x5f,0x21,0x54,0x51,0x38,0x52,0xf1);) cpp_quote(DEFINE_GUID(GUID_ContainerFormatBmp, 0x0af1d87e,0xfcfe,0x4188,0xbd,0xeb,0xa7,0x90,0x64,0x71,0xcb,0xe3);) +cpp_quote(DEFINE_GUID(GUID_ContainerFormatDib, 0x0af1d87e,0xfcfe,0x4188,0xbd,0xeb,0xa7,0x90,0x64,0x71,0xcb,0xe4);) Is this mocked up names? I couldn't find WIC DIB decoder definitions in the PSDK headers. -- Dmitry.
Re: [1/2] netstat: Implement the TCP stats output
On Sun, Jan 20, 2013 at 8:09 PM, André Hentschel n...@dawncrow.de wrote: --- + IDS_TCP_SEGM_RECV, Segments Recieved Typo here: should be Received (same issue on the 2nd patch) Frédéric
Re: dbghelp: Implement rudimentary stack walk for ARM64
+if ((frame-AddrPC.Mode == AddrModeFlat) +(frame-AddrFrame.Mode != AddrModeFlat)) this looks strange to me. I guess, you want to check that both mode address modes are AddrModeFlat A+ -- Eric Pouech
Re: [PATCH] windowscodecs: Add support for DIB format.
Christian Costa titan.co...@gmail.com wrote: Oupsss. I forgot to explain. No it's not it native windowscodecs. It's a wine extension to support DIB files used in d3dx9_36. Everything was already in place. I just had to hook things up. I asked to Vincent who told to do this way. At least it's what I understood. I'd suggest to use public APIs instead of inventing extenstions. CreateBitmapFromMemory should work for this purpose if you really need to do it using windowscodecs, otherwise GDI APIs may work as well. -- Dmitry.
Re: [PATCH] windowscodecs: Add support for DIB format.
Oupsss. I forgot to explain. No it's not it native windowscodecs. It's a wine extension to support DIB files used in d3dx9_36. Everything was already in place. I just had to hook things up. I asked to Vincent who told to do this way. At least it's what I understood. Christian 2013/1/21 Dmitry Timoshkov dmi...@baikal.ru: Christian Costa titan.co...@gmail.com wrote: cpp_quote(DEFINE_GUID(CLSID_WICBmpDecoder, 0x6b462062,0x7cbf,0x400d,0x9f,0xdb,0x81,0x3d,0xd1,0x0f,0x27,0x78);) +cpp_quote(DEFINE_GUID(CLSID_WICDibDecoder, 0x6b462062,0x7cbf,0x400d,0x9f,0xdb,0x81,0x3d,0xd1,0x0f,0x27,0x79);) cpp_quote(DEFINE_GUID(CLSID_WICPngDecoder, 0x389ea17b,0x5078,0x4cde,0xb6,0xef,0x25,0xc1,0x51,0x75,0xc7,0x51);) cpp_quote(DEFINE_GUID(CLSID_WICIcoDecoder, 0xc61bfcdf,0x2e0f,0x4aad,0xa8,0xd7,0xe0,0x6b,0xaf,0xeb,0xcd,0xfe);) cpp_quote(DEFINE_GUID(CLSID_WICJpegDecoder, 0x9456a480,0xe88b,0x43ea,0x9e,0x73,0x0b,0x2d,0x9b,0x71,0xb1,0xca);) @@ -1002,6 +1003,7 @@ cpp_quote(DEFINE_GUID(CLSID_WICWmpEncoder, 0xac4ce3cb,0xe1c1,0x44cd,0x82,0x15,0 cpp_quote(DEFINE_GUID(CLSID_WICDefaultFormatConverter, 0x1a3f11dc,0xb514,0x4b17,0x8c,0x5f,0x21,0x54,0x51,0x38,0x52,0xf1);) cpp_quote(DEFINE_GUID(GUID_ContainerFormatBmp, 0x0af1d87e,0xfcfe,0x4188,0xbd,0xeb,0xa7,0x90,0x64,0x71,0xcb,0xe3);) +cpp_quote(DEFINE_GUID(GUID_ContainerFormatDib, 0x0af1d87e,0xfcfe,0x4188,0xbd,0xeb,0xa7,0x90,0x64,0x71,0xcb,0xe4);) Is this mocked up names? I couldn't find WIC DIB decoder definitions in the PSDK headers. -- Dmitry.
Re: x11drv: Return true when handling SPI_SETSCREENSAVEACTIVE
C.W. Betts computer...@hotmail.com writes: I noticed in my research that the X11 driver doesn't return true in SystemParametersInfo when handling SPI_SETSCREENSAVEACTIVE. This patch fixes this. That's on purpose, it also needs to update the registry entry. -- Alexandre Julliard julli...@winehq.org
Re: configure.ac: check for a good enough version of libv4l1.h (try 2)
Damjan Jovanovic damjan@gmail.com writes:
@@ -676,6 +676,22 @@ AC_CHECK_HEADERS([linux/videodev.h linux/videodev2.h
libv4l1.h],,,
#include asm/types.h
#endif])
+dnl Check for libv4l1.h
+if test x$with_v4l != xno
+then
+ac_save_CPPFLAGS=$CPPFLAGS
+if test $PKG_CONFIG != false
+then
+ac_libv4l1_libs=`$PKG_CONFIG --libs libv4l1 2/dev/null`
+ac_libv4l1_cflags=`$PKG_CONFIG --cflags libv4l1 2/dev/null`
+CPPFLAGS=$CPPFLAGS $ac_libv4l1_cflags
+AC_CHECK_TYPES([struct video_picture],,,[#include libv4l1.h])
+fi
+CPPFLAGS=$ac_save_CPPFLAGS
+WINE_NOTICE_WITH(libv4l1,[test x$ac_cv_type_struct_video_picture =
x],
+[libv4l1 ${notice_platform}development files not found or too old.])
+fi
It doesn't make sense to use pkg-config for the test since we don't use
it when including the header.
--
Alexandre Julliard
julli...@winehq.org
Re: macdrv: implement getting and setting the screen saver state, version 2
On Jan 20, 2013, at 11:06 PM, Ken Thomases k...@codeweavers.com wrote: Hi, On Jan 20, 2013, at 2:00 PM, C.W. Betts wrote: This version implements changes and advice from Ken Thomases, including using kIOPMAssertionTypePreventUserIdleDisplaySleep on Lion and later. Also, some comments were added. +//Get pre-Lion no display sleep counts C++-style comments (//) are not allowed in Wine C code. They aren't portable. Oops, forgot about that. Fixed. +CFNumberRef count = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypeNoDisplaySleep); +CFNumberRef count2 = NULL; +long longCount = 0; +long longCount2 = 0; +CFNumberGetValue(count, kCFNumberLongType, longCount); +//If available, get Lion and later no display sleep counts +count2 = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypePreventUserIdleDisplaySleep); +if (count2) +CFNumberGetValue(count2, kCFNumberLongType, longCount2); The issue discussed for the previous patch is still present. For example, the following code would be internally consistent and also safe: CFNumberRef count = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypeNoDisplaySleep); CFNumberRef count2 = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypePreventUserIdleDisplaySleep); long longCount = 0; long longCount2 = 0; if (count) CFNumberGetValue(count, kCFNumberLongType, longCount); if (count2) CFNumberGetValue(count2, kCFNumberLongType, longCount2); (Note that this reorganization also eliminates a dead store. You were initializing count2 and then unconditionally assigning it, making the initialization redundant. Such unnecessary initializations also defeat potentially valuable compiler warnings.) Fixed +if (longCount || longCount2 ) There's an extraneous space before the closing parenthesis. Fixed +//Release power assertion +IOReturn success = IOPMAssertionRelease(powerAssertion); The comment is useless. It tells us nothing that the code doesn't. Please don't do that. In fact, most of the comments you added are like this. Done +//Are we running Lion or later? +if (kCFCoreFoundationVersionNumber = kCFCoreFoundationVersionNumber10_7) +//If so, use Lion's name +assertName = kIOPMAssertionTypePreventUserIdleDisplaySleep; +else +//If not, use old name +assertName = kIOPMAssertionTypeNoDisplaySleep; I'm not sure it's correct that these are two different names for roughly the same thing. I think the two assertion types do slightly different things. NoDisplaySleep seeks to prevent display sleep for any (non-forced) reason. PreventUserIdleDisplaySleep only seeks to prevent display sleep that is due to user idleness. From the header for kIOPMAssertionTypeNoDisplaySleep: Deprecated in 10.7; Please use assertion type kIOPMAssertionTypePreventUserIdleDisplaySleep. From Apple Docs, kIOPMAssertionTypePreventUserIdleDisplaySleep is only available on 10.7 or later. I don't think kIOPMAssertionTypePreventUserIdleDisplaySleep will do anything on 10.6 As I suggested previously, I do want us to use PreventUserIdleDisplaySleep when it's available, so that's good. (Thank you for making that change.) What I'm saying now is mostly just that the comments are misleading. I suggest just removing the comments within the if. The code is understandable without them. Also, this bit of code uses tabs to indent when none of the rest does. Please be consistent with the surrounding code. Oops, I'll look into getting rid of those. Thanks, Ken
Re: [PATCH] windowscodecs: Add support for DIB format.
I'd suggest to use public APIs instead of inventing extenstions. CreateBitmapFromMemory should work for this purpose if you really need to do it using windowscodecs, otherwise GDI APIs may work as well. I've been of the opinion that we should have a separate dll for Wine extensions to WIC, which could also work on WIndows, but I was told to put them in the same dll. We have two extensions already: the ICNS encoder and the TGA decoder. Yes, there are other ways we could do this. Probably GDI is the next simplest way. However, this is a case where we can very easily reuse code that was already written to support the BMP and ICO decoders as well as the code in d3dx9 that uses WIC decoders, so to me it still seems like the best option. (I was setting up for this when I was working on the ICO decoder, but that was only a matter of keeping separate the two changes I had to make in the logic for reading ICO frames, and writing DibDecoder_CreateInstance so anyone who went to implement a new one would see it.) The GUIDs for the other extensions are defined in private headers rather than wincodecs.idl, so I guess we should do that here.
Re: macdrv: implement getting and setting the screen saver state, version 2
On Jan 21, 2013, at 9:31 AM, C.W. Betts wrote: On Jan 20, 2013, at 11:06 PM, Ken Thomases k...@codeweavers.com wrote: I'm not sure it's correct that these are two different names for roughly the same thing. I think the two assertion types do slightly different things. NoDisplaySleep seeks to prevent display sleep for any (non-forced) reason. PreventUserIdleDisplaySleep only seeks to prevent display sleep that is due to user idleness. From the header for kIOPMAssertionTypeNoDisplaySleep: Deprecated in 10.7; Please use assertion type kIOPMAssertionTypePreventUserIdleDisplaySleep. From Apple Docs, kIOPMAssertionTypePreventUserIdleDisplaySleep is only available on 10.7 or later. I can't be certain, because Apple hasn't documented this API very well, but I believe that NoDisplaySleep is deprecated because Apple doesn't like its semantics. It's not because it's just an old name for PreventUserIdleDisplaySleep; it's because PreventUserIdleDisplaySleep has better semantics. I don't think kIOPMAssertionTypePreventUserIdleDisplaySleep will do anything on 10.6 Right. I wasn't suggesting that you use PreventUserIdleDisplaySleep on 10.6. The code itself is fine. I'm just saying that your comments were misleading because they suggest there are two different names for the same thing. -Ken
Re: [PATCH] windowscodecs: Add support for DIB format.
Vincent Povirk madewokh...@gmail.com wrote: I'd suggest to use public APIs instead of inventing extenstions. CreateBitmapFromMemory should work for this purpose if you really need to do it using windowscodecs, otherwise GDI APIs may work as well. I've been of the opinion that we should have a separate dll for Wine extensions to WIC, which could also work on WIndows, but I was told to put them in the same dll. We have two extensions already: the ICNS encoder and the TGA decoder. That's fine to have WIC support for really useful image formats if there is no other way to handle them, I was thinking to add PCX support at some point. But adding this support should not break other things. For instance using native gdiplus or windowscodecs for testing already breaks in some ways winemenubuilder, and adding a DIB decoder will break d3dx9 by adding a dependency that could be easily avoided. Yes, there are other ways we could do this. Probably GDI is the next simplest way. However, this is a case where we can very easily reuse code that was already written to support the BMP and ICO decoders as well as the code in d3dx9 that uses WIC decoders, so to me it still seems like the best option. Personally I don't see why DIB handling needs a WIC codec in the first place, GDI supports it just fine. (I was setting up for this when I was working on the ICO decoder, but that was only a matter of keeping separate the two changes I had to make in the logic for reading ICO frames, and writing DibDecoder_CreateInstance so anyone who went to implement a new one would see it.) The ICO decoder probably could be replaced by CreateBitmapFromHICON on the client side, since the latter one is implemented now. For other cases CreateBitmapFromHBITMAP or CreateBitmapFromMemory should work. -- Dmitry.
Re: [PATCH] windowscodecs: Add support for DIB format.
If there's really a demand for using native windowscodecs without breaking d3dx9 (which already happens because of the TGA decoder), I can supply a win32 build of our WIC extensions that winetricks could install with it. I can't do anything about ICNS. Yes, there are other ways we could do this. Probably GDI is the next simplest way. However, this is a case where we can very easily reuse code that was already written to support the BMP and ICO decoders as well as the code in d3dx9 that uses WIC decoders, so to me it still seems like the best option. Personally I don't see why DIB handling needs a WIC codec in the first place, GDI supports it just fine. Sure, but we ALREADY HAVE CODE for packed dibs that was essentially free and that is currently maintained. To do this from GDI, we still have to write code in d3dx9 that parses the packed DIB enough that we can pass it so some GDI function, then write code that converts a GDI bitmap to a D3DX surface. It gets a little more complicated when you consider things like palettes and rle encoding. (I was setting up for this when I was working on the ICO decoder, but that was only a matter of keeping separate the two changes I had to make in the logic for reading ICO frames, and writing DibDecoder_CreateInstance so anyone who went to implement a new one would see it.) The ICO decoder probably could be replaced by CreateBitmapFromHICON on the client side, since the latter one is implemented now. For other cases CreateBitmapFromHBITMAP or CreateBitmapFromMemory should work. So now we need code in WIC that copies ICO streams into a file on disk so we can get an HICON for the bitmap frames (they could all be PNG) so we can pass that to CreateBitmapFromHICON? No thanks.
Re: [PATCH] windowscodecs: Add support for DIB format.
Vincent Povirk madewokh...@gmail.com wrote: If there's really a demand for using native windowscodecs without breaking d3dx9 (which already happens because of the TGA decoder), I can supply a win32 build of our WIC extensions that winetricks could install with it. I can't do anything about ICNS. TGA is the simplest format I've ever seen, CreateBitmapFromMemory is the straight way to handle it. I haven't looked at ICNS support, but probably it could be implemented using public APIs as well. Yes, there are other ways we could do this. Probably GDI is the next simplest way. However, this is a case where we can very easily reuse code that was already written to support the BMP and ICO decoders as well as the code in d3dx9 that uses WIC decoders, so to me it still seems like the best option. Personally I don't see why DIB handling needs a WIC codec in the first place, GDI supports it just fine. Sure, but we ALREADY HAVE CODE for packed dibs that was essentially free and that is currently maintained. To do this from GDI, we still have to write code in d3dx9 that parses the packed DIB enough that we can pass it so some GDI function, then write code that converts a GDI bitmap to a D3DX surface. It gets a little more complicated when you consider things like palettes and rle encoding. DIB sections and things like SetDIBits should take care of all of this. (I was setting up for this when I was working on the ICO decoder, but that was only a matter of keeping separate the two changes I had to make in the logic for reading ICO frames, and writing DibDecoder_CreateInstance so anyone who went to implement a new one would see it.) The ICO decoder probably could be replaced by CreateBitmapFromHICON on the client side, since the latter one is implemented now. For other cases CreateBitmapFromHBITMAP or CreateBitmapFromMemory should work. So now we need code in WIC that copies ICO streams into a file on disk so we can get an HICON for the bitmap frames (they could all be PNG) so we can pass that to CreateBitmapFromHICON? No thanks. I don't see why you need to write anything to a file at all for a decoder if you already have bitmap bits. -- Dmitry.
Adding DECLSPEC_ALIGN(4) to structs for atomic DWORD access
Hi, there are some places in Wine where I believe atomic access to 32bit entities is expected by the programmer, yet I see little or no measures to ensure this. DWORD-Alignment is essential when several threads can access the same DWORD variable outside of a mutex (or within the implementation of the mutex). DECLSPEC_ALIGN(4) is the declaration that could be used to enforce it within a struct, assuming the struct itself is somehow aligned. E.g. shouldn't CRITICAL_SECTION objects be aligned when used within other (non-public) structs? (Presumably public MS structs cannot be augmented with alignment declarations) DECLSPEC_ALIGN is hardly used in Wine http://source.winehq.org/ident?i=RTL_CRITICAL_SECTION Other examples where I'm considering adding DWORD-alignment to read DWORD-sized objects atomically: - MCI position values (for MCI_STATUS_POSITION) - MIDI end_thread control variable - mmdevapi GetCurrentPadding (as part of lock-less patch) Would such patches be welcome? Are they superfluous, assuming that DWORD-alignment is granted and using DECLSPEC_ALIGN() only for larger alignments, e.g. 8 or 16 (that seems to be the current use)? One benefit I see is to highlight those variables shared among several threads. Regards, Jörg Höhle
Re: [PATCH] winebuild: Use Clang to assemble if found.
Charles Davis cdavi...@gmail.com writes: @@ -319,26 +341,27 @@ char *find_tool( const char *name, const char * const *names ) names = alt_names; } -while (*names) +/* If we have a target triple, we really need to try the list of names + * twice: once with the triple, and once without. + */ This doesn't make sense, if we have a target it means we are cross-compiling, and we need to use the correct tool. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] windowscodecs: Add support for DIB format.
If there's really a demand for using native windowscodecs without breaking d3dx9 (which already happens because of the TGA decoder), I can supply a win32 build of our WIC extensions that winetricks could install with it. I can't do anything about ICNS. TGA is the simplest format I've ever seen, CreateBitmapFromMemory is the straight way to handle it. I haven't looked at ICNS support, but probably it could be implemented using public APIs as well. The main reason I put the TGA decoder in WIC is that I know nothing about d3dx9 and wanted to help solve the problem without having to learn a new codebase. I don't know enough about d3dx9 to say whether it makes sense to put new image format handling code in there (other than DDS, which has features WIC can't support), but I can't imagine it making sense to move an existing, working format there. Sure, but we ALREADY HAVE CODE for packed dibs that was essentially free and that is currently maintained. To do this from GDI, we still have to write code in d3dx9 that parses the packed DIB enough that we can pass it so some GDI function, then write code that converts a GDI bitmap to a D3DX surface. It gets a little more complicated when you consider things like palettes and rle encoding. DIB sections and things like SetDIBits should take care of all of this. SetDIBits still requires us to calculate the offset of the bitmap bits, which requires understanding of the format. Which we would have to duplicate between WIC and D3DX, because we already need that logic in the WIC ICO decoder. And it definitely does not give us any usable D3DX structures without further work. These aren't very hard problems, sure, but I can't see the justification for writing new solutions to any problems when we already have something that should work with no extra effort. So now we need code in WIC that copies ICO streams into a file on disk so we can get an HICON for the bitmap frames (they could all be PNG) so we can pass that to CreateBitmapFromHICON? No thanks. I don't see why you need to write anything to a file at all for a decoder if you already have bitmap bits. Writing to a file is the only way I can see to make the standard icon handling functions (ExtractIcon) handle the format. If we don't use those, we have to handle the quirks of masks and double heights, at which point GDI doesn't help us very much. Maybe if we were starting from scratch it would've made sense to solve these problems differently. Obviously I disagree or I wouldn't have done things the way I did. But the ICO/BMP decoder we have now works (and probably works for DIB as well) and has no known problems that we can't solve with the current design. Why would we want to tear it down and replace it with three new things, or even just add one new thing to d3dx to handle a case the decoder can handle now?
Re: dbghelp: Implement rudimentary stack walk for ARM64
Am 21.01.2013 10:50, schrieb Eric Pouech: +if ((frame-AddrPC.Mode == AddrModeFlat) +(frame-AddrFrame.Mode != AddrModeFlat)) this looks strange to me. I guess, you want to check that both mode address modes are AddrModeFlat A+ it's the same as for the other architectures -- Best Regards, André Hentschel
Re: macdrv: implement getting and setting the screen saver state, version 3
On Jan 21, 2013, at 11:50 AM, C.W. Betts wrote: This version gets rid of redundant comments. According to Alexandre's comment on your X11 driver patch, you should be returning FALSE from the SET case so that user32 will update the registry. Otherwise, looking good. -Ken
Re: Adding DECLSPEC_ALIGN(4) to structs for atomic DWORD access
On Mon, Jan 21, 2013 at 06:52:23PM +0100, joerg-cyril.hoe...@t-systems.com wrote: Hi, there are some places in Wine where I believe atomic access to 32bit entities is expected by the programmer, yet I see little or no measures to ensure this. DWORD-Alignment is essential when several threads can access the same DWORD variable outside of a mutex (or within the implementation of the mutex). DECLSPEC_ALIGN(4) is the declaration that could be used to enforce it within a struct, assuming the struct itself is somehow aligned. 32bit items will be 32bit aligned unless the structure is 'packed' (or similar). David -- David Laight: da...@l8s.co.uk
Re: x11drv: Return true when handling SPI_SETSCREENSAVEACTIVE
Perhaps a comment should be added so new people will know about it? On Jan 21, 2013, at 4:24 AM, Alexandre Julliard julli...@winehq.org wrote: C.W. Betts computer...@hotmail.com writes: I noticed in my research that the X11 driver doesn't return true in SystemParametersInfo when handling SPI_SETSCREENSAVEACTIVE. This patch fixes this. That's on purpose, it also needs to update the registry entry. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] windowscodecs: Add support for DIB format.
Vincent Povirk madewokh...@gmail.com wrote: TGA is the simplest format I've ever seen, CreateBitmapFromMemory is the straight way to handle it. I haven't looked at ICNS support, but probably it could be implemented using public APIs as well. The main reason I put the TGA decoder in WIC is that I know nothing about d3dx9 and wanted to help solve the problem without having to learn a new codebase. I don't know enough about d3dx9 to say whether it makes sense to put new image format handling code in there (other than DDS, which has features WIC can't support), but I can't imagine it making sense to move an existing, working format there. So instead of writing much less code in d3dx9 to support TGA you've decided to write the whole new WIC decoder (even if it ended in a lot much more code) just because you know WIC code base better? And now you are proposing to do the same to support DIB? I object to this approach. -- Dmitry.
Re: Adding DECLSPEC_ALIGN(4) to structs for atomic DWORD access
joerg-cyril.hoe...@t-systems.com wrote: there are some places in Wine where I believe atomic access to 32bit entities is expected by the programmer, yet I see little or no measures to ensure this. Then it's a bug, and should be fixed by adding appropriate locking. -- Dmitry.
Re: [PATCH] windowscodecs: Add support for DIB format.
TGA is the simplest format I've ever seen, CreateBitmapFromMemory is the straight way to handle it. I haven't looked at ICNS support, but probably it could be implemented using public APIs as well. The main reason I put the TGA decoder in WIC is that I know nothing about d3dx9 and wanted to help solve the problem without having to learn a new codebase. I don't know enough about d3dx9 to say whether it makes sense to put new image format handling code in there (other than DDS, which has features WIC can't support), but I can't imagine it making sense to move an existing, working format there. So instead of writing much less code in d3dx9 to support TGA you've decided to write the whole new WIC decoder (even if it ended in a lot much more code) just because you know WIC code base better? And now you are proposing to do the same to support DIB? I object to this approach. Yes, it is possible that I wrote more code than was necessary to support TGA because I knew WIC better and because I thought it'd be cool (in theory the decoder can now be used outside the context of d3dx9, for instance on windows with the builtin image viewer - not all that useful but still pretty cool imo). For DIB it is less code because all of the logic involved is already used to support BMP or ICO, and all of the real work for it was done at the same time as adding ICO support.
Re: [PATCH] windowscodecs: Add support for DIB format.
Vincent Povirk madewokh...@gmail.com wrote: Yes, it is possible that I wrote more code than was necessary to support TGA because I knew WIC better and because I thought it'd be cool (in theory the decoder can now be used outside the context of d3dx9, for instance on windows with the builtin image viewer - not all that useful but still pretty cool imo). Adding Wine specific extensions should be slightly more justified IMHO. For DIB it is less code because all of the logic involved is already used to support BMP or ICO, and all of the real work for it was done at the same time as adding ICO support. I'd argue that it's even less code to load a DIB since gdi32 has full built-in support for it. Taking into account all the overhead that COM adds (although in d3dx9 case it's already there) writing a new WIC codec is not always justified. -- Dmitry.
Re: macdrv: implement getting and setting the screen saver state, version 4
Hi, On Jan 21, 2013, at 6:21 PM, C.W. Betts wrote: This version falls through in SPI_SETSCREENSAVEACTIVE. Sadly, you used C++ style for the fall-through comment. :-/ Also, you have some trailing whitespace and the patch no longer applies cleanly after today's commits of mine. It should be easy to fix that though. There aren't any serious conflicts. -Ken
Re: user32/tests: Test standard scrollbar's initialization (try 2).
Sergey Guralnik ser...@etersoft.ru wrote: Subject: user32/tests: Test standard scrollbar's initialization (try 2). If it matters the test looks good to me. -- Dmitry.
