Fwd: Winehq donation and DATA COMPRESSION
correct from address -- Forwarded message -- From: Gert van den Berg On Sat, Jan 30, 2010 at 15:58, Gerold Jens Wucherpfennig wrote: > BTW I've done some cabinet.dll stuff some years ago. > Can anybody give me a hint to some easy-to-understand data compression > documentation? > I want to complete the cabinet.dll archive creation compression, > if I get the required knowledge. It's so difficult... :-( 7-zip might have some usable code under a LGPL license (many files are public domain as well)? (But is is mostly C++, but some codecs seem to have C implementations...) (p7zip might be easier..) http://www.7-zip.org/ Gert
Re: libpng dependency issue
On Fri, Feb 5, 2010 at 9:54 AM, Vincent Povirk wrote: > It's supported 32bpp with transparency from the start. The full list > of supported writing formats is here: > http://source.winehq.org/source/dlls/windowscodecs/pngformat.c#L680 > > GUID_WICPixelFormat32bppBGRA is the format you want, I think. > > You probably tried to use a format not on that list, which defaults to > 24-bit. I'm not sure what the behavior should be in that case. Thanks, I'll take another look. > That's odd. Both WIC and winemenubuilder appear to be using BGR for > 32-bit pixel formats and informing libpng of this . I don't know where > you could be getting RGB pixels. It was just a thought, as I said, my understand of the graphics manipulation is pretty limited, I just assumed that was the problem due to resulting images. I'll try to give it another shot with this information. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Display drivers
An idea that popped into my head when I was thinking about a Quartz (OS X) driver that perhaps there could be separate drivers for Quartz (OS X) and X11. Such drivers would include OpenGL and DirectX "Drivers".
Implement D3DXDeclaratorFromFVF
The patch is a copy/paste from the file d3d9/verdeclaration.c. So this file should be simplified too, if we simplify the d3dx9_36/mesh.c implementation. Obviously, to compute the size of the vertex, we can use D3DXGetDeclVertexSize, but we gain very few. So, what do you think about this? A+ David
Re: MDI client repaint issues (client and children) and conformance tests for this
Reece Dunn wrote: > And in terms of a fix, what is the best approach for fixing the issue? > That is, Alexandre does not like an explicit call to InvalidateRect in > the WM_MDICREATE handler, so I assume that the repaint logic should be > done in a more specific place or figure out why it is not being called > for the MDI client. Probably WM_SETREDRAW has something to do with redrawing bug. Before fixing the problem we need to understand what exactly is the sequence of events that leads to it, how Windows and Wine behaviours differ. -- Dmitry.
Re: Winehq donation and DATA COMPRESSION
Gerold Jens Wucherpfennig wrote: > > Hi, I've donated some bucks to winehq by PayPal and want to spend more... > Can I decide for which things will be spend? > When donating money, how much of it will go to PayPal? > Is there a better way than using PayPal (by the donate link of the > winehq front-page)? > > BTW I've done some cabinet.dll stuff some years ago. > Can anybody give me a hint to some easy-to-understand data compression > documentation? > I want to complete the cabinet.dll archive creation compression, > if I get the required knowledge. It's so difficult... :-( > > By the way, I was tasked at Wineconf with sprucing up the Donate page to answer questions like this in detail, however I had been putting it off until I got my actual reimbursement check from wineconf. That finally happened recently, so I'll be working on this. Thanks, Scott Ritchie
Status of USB patches?
I wanted to experiment with these, but I'm not sure of their current state. Do they still apply cleanly? Are they on track for eventual inclusion? I'm willing to help provide community testing by putting them in a special package repository. Thanks, Scott Ritchie
Re: CJK default fonts for packagers to set
--- On Fri, 5/2/10, Aric Stewart wrote: > Scott Ritchie wrote: > > My notes from Wineconf remind me that I need to create > some manual links in the registry to whatever default CJK > fonts are on the system. Can someone tell me what > these are supposed to look like? > > > > Thanks, > > Scott Ritchie > > > > > > Sure! (sorry for the delay) > > The important keys are the following: > HKLM,"Software\Microsoft\Windows > NT\CurrentVersion\FontLink\SystemLink","Tahoma" > > HKLM,"Software\Microsoft\Windows > NT\CurrentVersion\FontLink\SystemLink","Microsoft Sans > Serif" > > and > HKLM,"Software\Microsoft\Windows > NT\CurrentVersion\FontLink\SystemLink","Lucida Sans > Unicode" > > They are REG_SZ_MULTI type of either > ":" or > "" You meant ',' instead of ':' here, right, judging from your example below? (and my impression) > > so for example windows sets (in inf format for Japanese > Windows): > > HKLM,"Software\Microsoft\Windows > NT\CurrentVersion\FontLink\SystemLink","Tahoma",0x00010002,"MSGOTHIC.TTC,MS > UI > Gothic","gulim.ttc,gulim","SimSun.TTC,SimSun","mingliu.ttc,PMingLiU" > > The glyphs will be found in order. So if a glyph is > missing from Tahoma, then it tries MSGOTHIC.TTC next, if > still missing gulim.ttc and so on. I do not have > chinese windows to investigate but it may be that the order > of the fonts is different. This may not be an issue on > linux. > > Any other questions just ask. > thanks! > -aric > > >
Re: side-effects/type safe min/max (Was Re: [1/3] d3dx9: Partial implementation of D3DXAssembleShader function. [try 2])
On 02/05/2010 07:38 PM, Henri Verbeet wrote: On 5 February 2010 19:10, Michael Stefaniuc wrote: Henri Verbeet wrote: min and max are already defined in windef.h. Note that they're not safe for expressions with side-effects, but for simple expressions like the one here they're ok. We can lift the side-effects and type safe min/max macros from the Linux Kernel. Of course Alexandre would have to accept the use of typeof(); we can do a fallback for the compilers that don't support that. I imagine it can't be *that* hard to fix the macros, but wouldn't that make them incompatible with the PSDK ones? Not really, you can guard them with ifdef __WINESRC__. The Wine source already has stricter requirements than what the Win32 API would allow. Of course the real issue is getting to the point where Wine will compile without warnings with the strict min/max macros. Actually that was once a janitorial task to use the strict min/max macros and fixup the problems found by that. bye michael
Re: CJK default fonts for packagers to set
Hin-Tak Leung wrote: --- On Fri, 5/2/10, Aric Stewart wrote: Scott Ritchie wrote: My notes from Wineconf remind me that I need to create some manual links in the registry to whatever default CJK fonts are on the system. Can someone tell me what these are supposed to look like? Thanks, Scott Ritchie Sure! (sorry for the delay) The important keys are the following: HKLM,"Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink","Tahoma" HKLM,"Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink","Microsoft Sans Serif" and HKLM,"Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink","Lucida Sans Unicode" They are REG_SZ_MULTI type of either ":" or "" You meant ',' instead of ':' here, right, judging from your example below? (and my impression) correct! my mistake. -aric
Re: side-effects/type safe min/max (Was Re: [1/3] d3dx9: Partial implementation of D3DXAssembleShader function. [try 2])
On 5 February 2010 19:10, Michael Stefaniuc wrote: > Henri Verbeet wrote: >> min and max are already defined in windef.h. Note that they're not >> safe for expressions with side-effects, but for simple expressions >> like the one here they're ok. > We can lift the side-effects and type safe min/max macros from the Linux > Kernel. Of course Alexandre would have to accept the use of typeof(); we > can do a fallback for the compilers that don't support that. > I imagine it can't be *that* hard to fix the macros, but wouldn't that make them incompatible with the PSDK ones?
side-effects/type safe min/max (Was Re: [1/3] d3dx9: Partial implementation of D3DXAssembleShader function. [try 2])
Henri Verbeet wrote: > On 5 February 2010 18:19, Matteo Bruni wrote: >> Sure. Better to go with something like "len = len < (desc->size - >> desc->pos) ? len : desc->size - desc->pos" or creating a "min" >> function? >> > min and max are already defined in windef.h. Note that they're not > safe for expressions with side-effects, but for simple expressions > like the one here they're ok. We can lift the side-effects and type safe min/max macros from the Linux Kernel. Of course Alexandre would have to accept the use of typeof(); we can do a fallback for the compilers that don't support that. bye michael
Re: CJK default fonts for packagers to set
Scott Ritchie wrote: My notes from Wineconf remind me that I need to create some manual links in the registry to whatever default CJK fonts are on the system. Can someone tell me what these are supposed to look like? Thanks, Scott Ritchie Sure! (sorry for the delay) The important keys are the following: HKLM,"Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink","Tahoma" HKLM,"Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink","Microsoft Sans Serif" and HKLM,"Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink","Lucida Sans Unicode" They are REG_SZ_MULTI type of either ":" or "" so for example windows sets (in inf format for Japanese Windows): HKLM,"Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink","Tahoma",0x00010002,"MSGOTHIC.TTC,MS UI Gothic","gulim.ttc,gulim","SimSun.TTC,SimSun","mingliu.ttc,PMingLiU" The glyphs will be found in order. So if a glyph is missing from Tahoma, then it tries MSGOTHIC.TTC next, if still missing gulim.ttc and so on. I do not have chinese windows to investigate but it may be that the order of the fonts is different. This may not be an issue on linux. Any other questions just ask. thanks! -aric
Re: [1/3] d3dx9: Partial implementation of D3DXAssembleShader function. [try 2]
On 5 February 2010 18:19, Matteo Bruni wrote: > Sure. Better to go with something like "len = len < (desc->size - > desc->pos) ? len : desc->size - desc->pos" or creating a "min" > function? > min and max are already defined in windef.h. Note that they're not safe for expressions with side-effects, but for simple expressions like the one here they're ok. >> I don't think it's very nice to have the HeapAlloc() and HeapFree() on >> different levels of the code like that. I.e., either have both in >> wpp_open_mem()/wpp_close_mem() or have both in the caller. The current >> scheme has the allocation in the caller and the deallocation in >> wpp_close_mem(), except sometimes when wpp_parse() fails to call >> wpp_close_mem(). (Can that even happen? Looking at the source of >> wpp_parse() it's not clear to me how.) Also, does wpp_parse() really >> need the input to be zero-terminated? > > wpp_parse() doesn't call wpp_close_mem() if the call to > pp_push_define_state() fails (can fail in out-of-memory conditions), > so the extra HeapFree was there for this case. Right, I only looked if wpp_callbacks->open()/wpp_callbacks->close() matched. If the alloc/free calls are on the same level it can't happen.
Re: [1/3] d3dx9: Partial implementation of D3DXAssembleShader function. [try 2]
Seems like I'm unable to review my code...
>
>> + if(desc->pos + len > desc->size) len = desc->size - desc->pos;
> It's usually safer to write expressions like that as "if (len >
> desc->size - desc->pos)" because "desc->pos + len" can wrap around if
> len is large, while "desc->size - desc->pos" should always be safe.
> Perhaps the caller is expected to always pass sane values here, but
> it's a somewhat dangerous construction in the general case in terms of
> reading/writing past the end of buffers. It can also be simplified to
> "len = min(len, desc->size - desc->pos);" here.
Sure. Better to go with something like "len = len < (desc->size -
desc->pos) ? len : desc->size - desc->pos" or creating a "min"
function?
>
>> + if(wpp_output_size + len > wpp_output_capacity)
> Similar issue as above.
>
>> +int wpp_close_output(void)
>> +{
>> + /* trim buffer to the effective size */
>> + char *new_wpp_output = HeapReAlloc(GetProcessHeap(), 0, wpp_output,
>> + wpp_output_size + 1);
>> + if(!new_wpp_output) return 0;
>> + wpp_output[wpp_output_size]='\0';
>> + return 1;
>> +}
> This doesn't really make sense. The comment is misleading, because you
> actually grow the buffer if "wpp_output_size == wpp_output_capacity".
> If you didn't, you wouldn't care about HeapRealloc() failure because
> the worst thing that could happen was that the buffer was a bit larger
> than it strictly needed to be. More importantly though, you assume
> new_wpp_output is the same pointer as wpp_output after a successful
> HeapReAlloc(), which isn't necessarily true.
>
Yep, this is clearly broken. Will fix it.
>> + current_shader.buffer = HeapAlloc(GetProcessHeap(), 0, data_len + 1);
> ...
>> + ret = wpp_parse("", NULL);
>> + if(!wpp_close_output())
>> + ret = 1;
>> + if(ret)
>> + {
>> + TRACE("Error during shader preprocessing\n");
>> + HeapFree(GetProcessHeap(), 0, current_shader.buffer);
> I don't think it's very nice to have the HeapAlloc() and HeapFree() on
> different levels of the code like that. I.e., either have both in
> wpp_open_mem()/wpp_close_mem() or have both in the caller. The current
> scheme has the allocation in the caller and the deallocation in
> wpp_close_mem(), except sometimes when wpp_parse() fails to call
> wpp_close_mem(). (Can that even happen? Looking at the source of
> wpp_parse() it's not clear to me how.) Also, does wpp_parse() really
> need the input to be zero-terminated?
wpp_parse() doesn't call wpp_close_mem() if the call to
pp_push_define_state() fails (can fail in out-of-memory conditions),
so the extra HeapFree was there for this case. Anyway, as you noticed,
there is no need to null-terminate wpp input (while there is this need
for the shader parser), so the entire
allocation-copy-nulltermination-deallocation is useless...
Re: Git does not build properly after daily pull -- font errors
Susan Cragin writes: > What's up with the git repository? > I do the following: > > git pull > sudo make uninstall > ./configure --enable-win64 && make distclean > ./configure --enable-win64 && make depend && make > > and I get the following: > > warning: System 16: missing glyph for char f8c8 > make[1]: *** No rule to make target `marlett.ttf', needed by `all'. Stop. > make[1]: Leaving directory `/home/susan/wine/fonts' > make: *** [fonts] Error 2 > > So I delete the git repository and download a new one. A "git checkout -f" would be enough to recover the deleted files, but yes, it's a bug. -- Alexandre Julliard julli...@winehq.org
Re: Git does not build properly after daily pull -- font errors
>Susan Cragin wrote: >> ./configure --enable-win64 && make distclean >> ./configure --enable-win64 && make depend && make >Huh? Are you actually trying to build the 64-bit version of Wine? Why >would you want to do that? Especially when 64-bit Wine isn't mature yet. > >Did you try it without --enable-win64? >> >> and I get the following: >> >> warning: System 16: missing glyph for char f8c8 >> make[1]: *** No rule to make target `marlett.ttf', needed by `all'. Stop. >> make[1]: Leaving directory `/home/susan/wine/fonts' >> make: *** [fonts] Error 2 >Check out commit 8350aafd5495c77ad4ba005dc4ae3f61a1ad1147: > > Author: Alexandre Julliard > Date: Thu Feb 4 20:29:23 2010 +0100 > > fonts: Remove the rules for font symlinks and go back to standard VPATH >usage. > >I'll bet that has something to do with it... >> >> So I delete the git repository and download a new one. >OK? Then what happened? Did it work, or didn't it? The new git repository worked. I've been doing --enable-win64 because it has worked for me. I've been doing it for a couple of weeks and haven't had a problem. Susan
Re: confirm af48973b6246cef737c553415eed7349e89b5944
On 2010-02-02 (February, Tuesday) 15:00:01 wine-devel-requ...@winehq.org wrote: > Your membership in the mailing list wine-devel has been disabled due > to excessive bounces The last bounce received from you was dated > 26-Jan-2010. You will not get any more messages from this list until > you re-enable your membership. You will receive 2 more reminders like > this before your membership in the list is deleted. > > To re-enable your membership, you can simply respond to this message > (leaving the Subject: line intact), or visit the confirmation page at > > > http://www.winehq.org/mailman/confirm/wine-devel/af48973b6246cef737c553415 > eed7349e89b5944 > > > You can also visit your membership page at > > http://www.winehq.org/mailman/options/wine-devel/research%40science.su > > > On your membership page, you can change various delivery options such > as your email address and whether you get digests or not. As a > reminder, your membership password is > > xearaxon > > If you have any questions or problems, you can contact the list owner > at > > wine-devel-ow...@winehq.org >
MDI client repaint issues (client and children) and conformance tests for this
Hi, I have been looking at http://bugs.winehq.org/show_bug.cgi?id=14312 which shows up as the MDI client window not being repainted properly when a new child is created given an already maximised child window being present. There is a related issue here that sometimes the child window frames are not being redrawn properly. I am trying to understand where this problem is occurring, and am failing to see the big picture. As I understand it, WM_MDIRESTORE is sent for the maximised child window, which calls ShowWindow(SW_RESTORE) on the child. This is then (from what I can tell) is handled by the windowing code (with the client behaving like a desktop window), which is taking care of the positioning and layout of the child windows. For some reason, the parent window (the client) is not being updated properly (i.e. a WM_ERASEBKGND+WM_PAINT is not being sent). Likewise, the child windows don't appear to be handling and/or receiving a WM_NCPAINT message to redraw their frame. In addition to this, looking at the message trail tests in user32/tests/msg.c, only some of these are testing a WM_ERASEBKGND+WM_PAINT message is being sent. How accurate are these with respect to WM_PAINT messages (that is, are WM_PAINT messages ignored in message trails unless explicitly tested for?). And in terms of a fix, what is the best approach for fixing the issue? That is, Alexandre does not like an explicit call to InvalidateRect in the WM_MDICREATE handler, so I assume that the repaint logic should be done in a more specific place or figure out why it is not being called for the MDI client. - Reece
Re: Git does not build properly after daily pull -- font errors
Susan Cragin wrote: > ./configure --enable-win64 && make distclean > ./configure --enable-win64 && make depend && make Huh? Are you actually trying to build the 64-bit version of Wine? Why would you want to do that? Especially when 64-bit Wine isn't mature yet. Did you try it without --enable-win64? > > and I get the following: > > warning: System 16: missing glyph for char f8c8 > make[1]: *** No rule to make target `marlett.ttf', needed by `all'. Stop. > make[1]: Leaving directory `/home/susan/wine/fonts' > make: *** [fonts] Error 2 Check out commit 8350aafd5495c77ad4ba005dc4ae3f61a1ad1147: Author: Alexandre Julliard Date: Thu Feb 4 20:29:23 2010 +0100 fonts: Remove the rules for font symlinks and go back to standard VPATH usage. I'll bet that has something to do with it... > > So I delete the git repository and download a new one. OK? Then what happened? Did it work, or didn't it?
Git does not build properly after daily pull -- font errors
What's up with the git repository? I do the following: git pull sudo make uninstall ./configure --enable-win64 && make distclean ./configure --enable-win64 && make depend && make and I get the following: warning: System 16: missing glyph for char f8c8 make[1]: *** No rule to make target `marlett.ttf', needed by `all'. Stop. make[1]: Leaving directory `/home/susan/wine/fonts' make: *** [fonts] Error 2 So I delete the git repository and download a new one.
Re: libpng dependency issue
> I was looking in to the overall architectural issues but have not had > the time to really hack on it recently. As far as I understand, the > current png support in wine's windowscodecs does not support creation > of a 32bpp image with transparency, unless I missed some commit > messages or totally misunderstood our discussions. I believe from my > reading native does support doing the conversions, saving the alpha > channel information, applying the masking, etc. It's supported 32bpp with transparency from the start. The full list of supported writing formats is here: http://source.winehq.org/source/dlls/windowscodecs/pngformat.c#L680 GUID_WICPixelFormat32bppBGRA is the format you want, I think. You probably tried to use a format not on that list, which defaults to 24-bit. I'm not sure what the behavior should be in that case. > I was working on a patch for winemenubuilder so we would at least have > that part part done, even if it only spit out 24bpp images without > transparency but never got very far with it. If I recall correctly, > the current code parses the raw ico bitmapinfo, passes that to libpng, > applies the mask and generates the resulting image. I tried a few > different ways, using WIC to open a stream to the icon that was then > parsed by the icon decoder feeding the png encoder to generate the > image. I also tried using the existing parsing system, feeding that to > the bitmap decoder then the png encoder and never could get it to work > quite right. With the patch I had, the resulting png image was corrupt > possibly due to some RGB/BGR issue, I seem to recall Vincent > mentioning something about that as well. That's odd. Both WIC and winemenubuilder appear to be using BGR for 32-bit pixel formats and informing libpng of this . I don't know where you could be getting RGB pixels.
Re: [1/3] d3dx9: Partial implementation of D3DXAssembleShader function. [try 2]
On 4 February 2010 19:26, Matteo Bruni wrote:
> +void wpp_write_message_var(const char *fmt, ...) PRINTF_ATTR(1,2);
> +void wpp_write_message_var(const char *fmt, ...)
You can just do the following:
+void PRINTF_ATTR(1,2) wpp_write_message_var(const char *fmt, ...)
> +desc = HeapAlloc(GetProcessHeap(), 0, sizeof(struct mem_file_desc));
sizeof(*desc) is generally easier, but that's minor of course.
> +if(desc->pos + len > desc->size) len = desc->size - desc->pos;
It's usually safer to write expressions like that as "if (len >
desc->size - desc->pos)" because "desc->pos + len" can wrap around if
len is large, while "desc->size - desc->pos" should always be safe.
Perhaps the caller is expected to always pass sane values here, but
it's a somewhat dangerous construction in the general case in terms of
reading/writing past the end of buffers. It can also be simplified to
"len = min(len, desc->size - desc->pos);" here.
> +if(wpp_output_size + len > wpp_output_capacity)
Similar issue as above.
> +int wpp_close_output(void)
> +{
> +/* trim buffer to the effective size */
> +char *new_wpp_output = HeapReAlloc(GetProcessHeap(), 0, wpp_output,
> + wpp_output_size + 1);
> +if(!new_wpp_output) return 0;
> +wpp_output[wpp_output_size]='\0';
> +return 1;
> +}
This doesn't really make sense. The comment is misleading, because you
actually grow the buffer if "wpp_output_size == wpp_output_capacity".
If you didn't, you wouldn't care about HeapRealloc() failure because
the worst thing that could happen was that the buffer was a bit larger
than it strictly needed to be. More importantly though, you assume
new_wpp_output is the same pointer as wpp_output after a successful
HeapReAlloc(), which isn't necessarily true.
> +current_shader.buffer = HeapAlloc(GetProcessHeap(), 0, data_len + 1);
...
> +ret = wpp_parse("", NULL);
> +if(!wpp_close_output())
> +ret = 1;
> +if(ret)
> +{
> +TRACE("Error during shader preprocessing\n");
> +HeapFree(GetProcessHeap(), 0, current_shader.buffer);
I don't think it's very nice to have the HeapAlloc() and HeapFree() on
different levels of the code like that. I.e., either have both in
wpp_open_mem()/wpp_close_mem() or have both in the caller. The current
scheme has the allocation in the caller and the deallocation in
wpp_close_mem(), except sometimes when wpp_parse() fails to call
wpp_close_mem(). (Can that even happen? Looking at the source of
wpp_parse() it's not clear to me how.) Also, does wpp_parse() really
need the input to be zero-terminated?
Re: kernel32: Add support for InterlockedCompareExchange64, try 2
Hello Alexandre, Alexandre Julliard wrote: Maarten Lankhorst writes: --- Fix the definitions in winbase.h, and the inline assembly :) There are still several problems with your assembly, and I don't understand why you want to reinvent the wheel when we have a perfectly fine interlocked_cmpxchg64 implementation already I copied the 32-bits Interlocked64 definition from my patch, changed LONG64 to long long, and WINAPI to __attribute__((__stdcall__)) and then tried a few calls against the inline and it works fine and compare the returned and expected result, which seem to work for the case where it should replace, and where it shouldn't replace. Tests also run against the kernel32 assembly version. versionInterlockedCompareExchange64 when available. The 64-bits InterlockedCompareExchange64 assembly call is copied from InterlockedCompareExchangePointer What are the remaining problems then? Cheers, Maarten.
Re: d3dx9: Implement D3DXDeclaratorFromFVF
On 5 February 2010 05:09, David Adam wrote: > This patch is from Tony Wasserka. It comes from his git repertory. He > authorized to pick up patches (see Wine-devel) to submit to Wine. > I just cleanup it a little bit. I let Tony as the author of this patch. All > the tests pass in a real Windows Vista box. > Looks more complicated than needed.
Re: kernel32: Add support for InterlockedCompareExchange64, try 2
Maarten Lankhorst writes: > --- > Fix the definitions in winbase.h, and the inline assembly :) There are still several problems with your assembly, and I don't understand why you want to reinvent the wheel when we have a perfectly fine interlocked_cmpxchg64 implementation already. -- Alexandre Julliard julli...@winehq.org
Re: libpng dependency issue
2010/2/4 Vincent Povirk > > > As a side note, you need to do a similar work on winemenubuilder, as it > uses > > libpng and fails linking without modifications. to test this images i > > statically linked it to libpng, just to make it work, as it wasn't needed > in > > your test. > > Thank you for working on this, since i'm not really an expert on this > > dynamical loading code and couldn't help. > > Technically, winemenubuilder should be using windowscodecs for its png > support, like the rest of wine. I believe Steven Edwards has done some > work on this. > Don't know about this. What i know is that currently winemenubuilder shows this problem and it's needed to be worked out if you want to support builds on libpng 1.4.
Re: libpng dependency issue
2010/2/4 Vincent Povirk > > > * http://www.libpng.org/pub/png/PngSuite/basn4a16.png - This is a > > grayscale png with an alpha channel. That's the situation where we use > > the png_set_gray... function that was removed. > > Errr.. I may actually be thinking of > http://www.libpng.org/pub/png/PngSuite/tbbn1g04.png > Those two show correctly, while the other doesn't work, but it's the image's fault, as it's only 49 B and can't be open even in other programs. As a side note, you need to do a similar work on winemenubuilder, as it uses libpng and fails linking without modifications. to test this images i statically linked it to libpng, just to make it work, as it wasn't needed in your test. Thank you for working on this, since i'm not really an expert on this dynamical loading code and couldn't help.
