April 2012 - wine-devel

Re: [1/3] d3dx9: Define DDS structures.
by Henri Verbeet 26 Apr '12

26 Apr '12

Is there no header that should define these?

2 2

Re: [2/3] d3dx9: Add partial DDS support implementation for D3DXGetImageInfo functions.
by Henri Verbeet 26 Apr '12

26 Apr '12

On 26 April 2012 11:47, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > +static HRESULT get_image_info_from_dds(LPCVOID buffer, DWORD length, D3DXIMAGE_INFO *info) Please avoid types like LPCVOID.

1 0

Re: [PATCH 1/2] amstream: Add stubbed implementation of DirectDrawStreamSample. (try 4)
by Marvin 26 Apr '12

26 Apr '12

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18050 Your paranoid android. === WVISTAADM (32 bit amstream) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Re: gdiplus: GdipDrawString is not supposed to use the layout rectangle for clipping. Take 2.
by Dmitry Timoshkov 25 Apr '12

25 Apr '12

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > There is a dedicated clip region in the graphics object. Please ignore that patch or mark it as rejected, the real problem has been fixed by 9b5b04c1c1a7b32dd3e1e453b6d739082c4ccede. -- Dmitry.

1 0

Re: [PATCH 1/2] amstream: Add stubbed implementation of DirectDrawStreamSample. (try 3)
by Alexandre Julliard 25 Apr '12

25 Apr '12

Christian Costa <titan.costa(a)gmail.com> writes: > Try3: Put sample stuff in stream_sample.c > Try2: Fix QueryInterface. It was better without creating a new file. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/4] make_unicode: Create tables with data needed by nameprep algorithm
by Alexandre Julliard 25 Apr '12

25 Apr '12

Piotr Caban <piotr(a)codeweavers.com> writes: > + dump_nameprep_range($INPUT, $nameprep_flags{"unassigned"}, \@flags_table) if (/A.1/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.1.2/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.2.2/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.3/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.4/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.5/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.6/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.7/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.8/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.9/); > + dump_nameprep_range($INPUT, $nameprep_flags{"bidi_ral"}, \@flags_table) if (/D.1/); > + dump_nameprep_range($INPUT, $nameprep_flags{"bidi_l"}, \@flags_table) if (/D.2/); > + > + dump_nameprep_map($INPUT, \@mapping_table) if (/B.1/); > + dump_nameprep_map($INPUT, \@mapping_table) if (/B.2/); These names are confusing, the functions are loading data not dumping it. > + for (my $i = 0; $i < 65536; $i++) > + { > + next unless defined $flags_table[$i]; > + $flags_table[$i] += $i; > + } > + > + open OUTPUT,">$filename.new" or die "Cannot create $filename"; > + print "Building $filename\n"; > + print OUTPUT "/* Nameprep algorithm related data */\n"; > + print OUTPUT "/* generated from $STRINGPREP */\n"; > + print OUTPUT "/* DO NOT EDIT!! */\n\n"; > + print OUTPUT "#include \"wine/unicode.h\"\n\n"; > + DUMP_CASE_TABLE( "nameprep_char_type", @flags_table ); It doesn't make sense to use a case table for this, it's just flags. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: 'property' may be both keyword and identifier
by Marvin 25 Apr '12

25 Apr '12

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18045 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/3] server: Revise completion behavior to allow completions for cancelled sockets (try 2).
by Alexandre Julliard 24 Apr '12

24 Apr '12

"Erich E. Hoover" <ehoover(a)mines.edu> writes: > Real Name: > Erich Hoover > > Description: > This patch changes how the close socket operation works so that if > an async operation is registered then closing the handle will be > deferred until the async operation has completed. I would find it very suprising if this were how it's supposed to work, particularly since multiple handles can of course be opened to the same socket. You'll need very convincing tests for this... -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [2/5] gdi32: Introduce a list of font file/data.
by Alexandre Julliard 24 Apr '12

24 Apr '12

Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: > @@ -962,6 +972,22 @@ static Family *find_family_from_any_name(const WCHAR *name) > return NULL; > } > > +static Font *find_font_file(const char *file) > +{ > + if (file != NULL) > + { > + Font *font; > + > + LIST_FOR_EACH_ENTRY(font, &font_list, Font, entry) > + { > + if (font->file != NULL && strcmp(font->file, file) == 0) > + return font; > + } > + } > + > + return NULL; > +} You can't compare files this way, different paths can point to the same file. > @@ -2927,7 +2988,8 @@ static BOOL get_fontdir( const char *unix_name, struct fontdir *fd ) > DWORD type; > > if (!ft_face) return FALSE; > - face = create_face( ft_face, 0, unix_name, NULL, 0, 0, FALSE ); > + font.file = (char *)unix_name; Don't do that. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: gdi32: Add support for emulating bold faces of bitmap fonts.
by Dmitry Timoshkov 24 Apr '12

24 Apr '12

Hello, Any feedback on this patch? -- Dmitry.

1 0

Re: winex11.drv: Windows always generates VK_DECIMAL for Del/. on a keypad.
by Dmitry Timoshkov 24 Apr '12

24 Apr '12

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Windows always generates VK_DECIMAL for Del/. on a keypad while some > X11 keyboard layouts generate XK_KP_Separator instead of XK_KP_Decimal > in order to produce a locale dependent numeric separator. > > X11 handles XK_KP_Separator same way as XK_KP_Decimal for all tested > keyboard layouts, so passing XK_KP_Separator instead of XK_KP_Decimal > to XKeysymToKeycode doesn't break things. Pressing Del/. with NumLock > turned on still correctly generates '.' or ',' depending on keyboard > layout and matches what Windows does. > > This patch fixes an application which uses VK_DECIMAL as a sign to break > the input string and insert a separator while entering a currency/price. Is there anything else I could provide in helping to get this patch accepted? -- Dmitry.

1 1

Re: [3/5] mapi32: Convert sendmail_extended_mapi to Unicode
by Alexandre Julliard 24 Apr '12

24 Apr '12

Owen Rudge <orudge(a)codeweavers.com> writes: > + > +/* Macro to test for validity before freeing a pointer */ > +#define mapi_heap_free(_ptr) if (_ptr) { HeapFree(GetProcessHeap(), 0, (_ptr)); } You don't need that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Mono packaging status
by Vincent Povirk 24 Apr '12

24 Apr '12

So, I've finally had some time to work on Mono packaging. I think I have a sort of "first draft" ready. The goal is to create an MSI package of Mono, similar to the one we use for Gecko, which Wine will install automatically when updating a prefix, unless native mscoree is installed. This package will include all the Mono runtime files, as well as any registry keys and files that need to be installed to the Windows system for .NET compatibility. Anything .NET that we want to replace (including XNA, WPF, and msvcm libraries) will be included. Ideally, with this package installed, any official installers for .NET components will decide they are already installed and do nothing. To install native .NET, it will be necessary to uninstall the Mono package (using "wine uninstaller --remove '{E45D8920-A758-4088-B6C6-31DBB276992E}'", which will continue to work for the foreseeable future). Before the Mono package is installed, and after it is removed, no .NET registry keys or files will be present, so in theory the installers will just work (but in practice they probably will require work-arounds for Wine bugs). There will be only one package for 32-bit and 64-bit. Most of the compiled code is architecture-independent, so it doesn't make much sense to have separate packages. The Mono package versions will be loosely tied to Wine version. On prefix creation time, Wine will attempt to install the version it "prefers". Due to limitations of MSI, this may mean that Wine will upgrade Mono automatically but never downgrade it. Because the Mono API is stable, it should be possible to use any Mono package with any Wine version back to 1.5.1, which was the first version to search for the Mono runtime dll based on architecture. I'm currently publishing the source code at https://github.com/madewokherd/wine-mono, but I'm not sure if that is a good permanent home. I do want to keep it on github so I can make and accept pull requests. I'm using submodules, so it will be necessary to clone with --recursive and update the submodules from time to time. The build process requires mingw-w64 (both 32-bit and 64-bit), Wine, and a version of the Mono C sharp compiler (gmcs or dmcs, I think), and not surprisingly is done by running build-winemono.sh. There should never be any more requirements, and I'd like to keep the version requirements on those as broad as I can. I want this to be easy to build, so other people can work on it. The 64-bit part appears to work on Windows, but it is not useful on Wine currently. I'll be working on fixing that, or at least getting Alexandre bug reports and test cases so he can work on it. I think that when it is fixed, we'll have a lot more 64-bit processes than we used to, for better or worse. For now, the only way to install the package is with msiexec. The current version is based on Mono 2.11.0, which has a serious deadlock bug on Windows. This will need to be resolved before I can do an actual release. Otherwise, I'm not expecting much difference from the official Mono 2.10 packages for Windows. The XNA, WPF, and msvcm stuff is not ready yet. So, I know it's kind of crappy right now, and I'm not asking for testing so much as comments. If you are a packager of Wine, I would like to make sure you can build it, and that the resulting build works apart from that deadlock bug. If for some reason you want to try it, the current version is at https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. I think I will need a new home for the binaries, because github only gives me enough space for about 5 of them. So, uh, don't count on that URL sticking around.

4 5

Re: [2/2] gdi32: Enumerated font size should not be too large.
by Huw Davies 23 Apr '12

23 Apr '12

On 23/04/2012 15:32, Dmitry Timoshkov wrote: > This reverts commit f4625d1ae1109ee9a30faa8254b10779853f0ac2. > --- > dlls/gdi32/freetype.c | 2 +- > dlls/gdi32/tests/font.c | 1 + > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c > index 3875e4f..401cfd1 100644 > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -5048,7 +5048,7 @@ static void GetEnumStructs(Face *face, LPENUMLOGFONTEXW pelf, > font = alloc_font(); > > if(face->scalable) { > - height = -2048; /* 2048 is the most common em size */ > + height = 100; > width = 0; > } else { > height = face->size.y_ppem>> 6; You'll need to fix the ntmTm.ntmCellHeight and ntmTm.ntmAvgWidth values. Huw.

2 3

Re: gdiplus: Use symbolic name of the font style.
by Nikolay Sivov 23 Apr '12

23 Apr '12

On 4/23/2012 17:31, Dmitry Timoshkov wrote: > --- > dlls/gdiplus/font.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c > index 169e28f..8157b0a 100644 > --- a/dlls/gdiplus/font.c > +++ b/dlls/gdiplus/font.c > @@ -767,7 +767,7 @@ GpStatus WINGDIPAPI GdipGetLineSpacing(GDIPCONST GpFontFamily *family, > static INT CALLBACK font_has_style_proc(const LOGFONTW *elf, > const TEXTMETRICW *ntm, DWORD type, LPARAM lParam) > { > - INT fontstyle=0; > + INT fontstyle = FontStyleRegular; > > if (!ntm) return 1; > Maybe it's better to make it 'enum FontStyle' after all.

2 1

Re: [PATCH 1/4] amstream: rename mediastream to ddrawmediastream. (resend)
by Alexandre Julliard 23 Apr '12

23 Apr '12

Christian Costa <titan.costa(a)gmail.com> writes: > --- > dlls/amstream/Makefile.in | 2 > dlls/amstream/amstream.c | 6 + > dlls/amstream/amstream_private.h | 2 > dlls/amstream/ddrawmediastream.c | 256 ++++++++++++++++++++++++++++++++++++++ > dlls/amstream/mediastream.c | 251 ------------------------------------- > 5 files changed, 263 insertions(+), 254 deletions(-) > create mode 100644 dlls/amstream/ddrawmediastream.c > delete mode 100644 dlls/amstream/mediastream.c There's no reason to rename the file. Just put everything in there. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: iphlpapi: Move get_pid_map() and find_owning_pid() under #ifdef #ifdef __linux__.
by Alexandre Julliard 23 Apr '12

23 Apr '12

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > ...like their sole user. > > Otherwise this warns on everything which is not __linux__. ;-) That's a feature. It needs to be implemented on other platforms. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] dmusic: Pass creation parameters to DMUSIC_CreateDirectMusicBufferImpl then allocate data buffer and set format accordingly.
by Alexandre Julliard 23 Apr '12

23 Apr '12

Christian Costa <titan.costa(a)gmail.com> writes: > +HRESULT WINAPI DMUSIC_CreateDirectMusicBufferImpl(LPDMUS_BUFFERDESC desc, LPVOID* ret_iface) > +{ > + IDirectMusicBufferImpl* dmbuffer; > + > + TRACE("(%p, %p)\n", desc, ret_iface); > + > + dmbuffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectMusicBufferImpl)); > + if (!dmbuffer) { > + *ret_iface = NULL; > + return E_OUTOFMEMORY; > + } > + > + dmbuffer->lpVtbl = &DirectMusicBuffer_Vtbl; > + dmbuffer->ref = 0; /* Will be inited by QueryInterface */ > + > + memcpy(&dmbuffer->format, &desc->guidBufferFormat, sizeof(GUID)); > + dmbuffer->size = (desc->cbBuffer + 3) & ~3; /* Buffer size must be multiple of 4 bytes */ > + > + dmbuffer->data = HeapAlloc(GetProcessHeap(), 0, sizeof(dmbuffer->size)); > + if (!dmbuffer->data) { > + HeapFree(GetProcessHeap(), 0, dmbuffer); > + *ret_iface = NULL; > + return E_OUTOFMEMORY; > + } > + > + return IDirectMusicBufferImpl_QueryInterface((LPDIRECTMUSICBUFFER)dmbuffer, &IID_IDirectMusicBuffer, ret_iface); While you are changing the function please also make it handle errors properly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] dmsynth: Check the rigth CLSID to create the DirectMusicSynthSink object. (resend)
by Marvin 21 Apr '12

21 Apr '12

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17990 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

winedbg and program stdout
by Ilya Basin 21 Apr '12

21 Apr '12

When I debug a program with winedbg, it's output never goes to the same terminal. If it's compiled with -mconsole, it goes to a new console window; if compiled with -mwindows, the output is discarded. Any way to change this behavior?

2 1

Re: d3dx9_36: Add adjacency for D3DXCreateCylinder
by Rico Schüller 20 Apr '12

20 Apr '12

Am 20.04.2012 16:20, schrieb David Adam: > > + if (adjacency) > > I'm not sure that this is correct, but why is adjacency not touched? What should be returned for adjacency, maybe a test will show it? I guess the temp ID3DXBuffer should be returned instead of leaked when all is successful... Cheers Rico

1 0

Re: jscript: Added regexp 'pre-parser' to support non-backslash-sequenced non-terminating '/' in characted classes
by Marvin 20 Apr '12

20 Apr '12

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17979 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Are we missing the small folder_open icons?
by Francois Gouget 20 Apr '12

20 Apr '12

In dlls/shell32/shell32.rc I see the following fixme: /* FIXME: Following three resources are not yet added */ /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_OPEN_SMALL ICON folder_open.ico /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_OPEN_LARGE ICON folder_open.ico /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_SMALL_XP ICON folder_open.ico However folder_open.ico is generated from an SVG file and we seem to be having it in multiple sizes. Also this fixme has been there forever. So is there really still something to be fixed? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

2 1

Updating GSoC proposal
by Jacek Caban 19 Apr '12

19 Apr '12

Hi all, GSoC is starting this year and, if we want to have good applications, we need to update our proposals. Usually the most attention is directed into adding new ones, while we keep obviously bad (or just bad IMO) proposals on the page. I'm planning to remove following project proposals: Security - implement sandboxing Theming - Implement Wine theming support NTDLL - support performance registry keys Winelib Aware Scons (or cmake) Cleanup Winemenubuilder to support generating Application Bundles on Mac OS X Wine-based application virtualization If someone knows a reason to not remove them, please reply. Cheers, Jacek

2 1

Re: d3dx9/tests: Add DDS pixel format tests for D3DXGetImageInfoFromFileInMemory.
by Matteo Bruni 19 Apr '12

19 Apr '12

Il 19 aprile 2012 19:37, Józef Kucia <joseph.kucia(a)gmail.com> ha scritto: > --- > dlls/d3dx9_36/tests/surface.c | 65 +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 65 insertions(+), 0 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/surface.c b/dlls/d3dx9_36/tests/surface.c > index 87aa03e..51d6ebd 100644 > --- a/dlls/d3dx9_36/tests/surface.c > +++ b/dlls/d3dx9_36/tests/surface.c > @@ -22,6 +22,8 @@ > #include "wine/test.h" > #include "d3dx9tex.h" > #include "resources.h" > +#undef MAKE_DDHRESULT > +#include "ddraw.h" > I'm not sure that's a good idea. ddraw.h is not included in recent DirectX SDKs and the relevant definitions are "gone", as far as I know. So I think d3dx9 or its tests should not depend on that header. I'd just (re)declare the stuff you need privately in the test source file instead. You don't even need to use the same types/defines/variables names as those from ddraw.h, you just have to keep them compatible. On that point, I see that MSDN mentions the equivalent DDS_HEADER and DDS_PIXELFORMAT structures (http://msdn.microsoft.com/en-us/library/windows/desktop/bb943991%28v=vs.85%…), except those don't seem to be defined in the MS headers either. I guess you are free to use whatever names you like...

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2012