wine-devel April 2012

wine-devel@winehq.org

76 participants
181 discussions

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

← Newer
1
2
3
4
5
6
7
...
19
Older →

Jump to page:

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