wine-devel January 2018

wine-devel@winehq.org

62 participants
503 discussions

Re: widl: Set name return value (passed by reference) in the alias case alias case in get_user_type.
by Alexandre Julliard 23 Nov '20

23 Nov '20

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > So, I admit I don't really know this code, but looking at it (triggered > by a warning issued by GCC development versions), I noticed that this > variable passed by reference is not initialized here. It's initialized when we return a type, and it doesn't need to be initialized on NULL return. The code is correct, but you could probably set the variable to NULL in the caller to silence the warning. -- Alexandre Julliard julliard(a)winehq.org

2 1

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer 22 Nov '20

22 Nov '20

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong 28 Sep '18

28 Sep '18

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

COM tracing ...
by Michael Meeks 21 Aug '18

21 Aug '18

Hi guys, Rather a peripheral question; apologies for that - but I'd imagine there are experts here that may be able to help. I have a black-box problem - a Windows app dealing with confidential data that I can't easily touch (and thus can't get to run under Wine) - which does some small but critical automation of MS Office - using VBS / COM scripting. I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far): http://www.rohitab.com/apimonitor which, while closed, looks interesting; but traces a lot in a hard-to-search way and doesn't appear to do the trick. https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-d… Sounds useful: using Event Tracing for Windows (ETW) but has this rather unhelpful property: "The binary file must be formatted by Microsoft so that it can be analyzed. Please forward the .etl files to your support contact. ..." ;-) Component models used to be all the rage in my youth ;-) surely someone solved the "strace for COM calls" problem elegantly some-when ! Crazily - might it be possible to instrument, interpose and use Wine's COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ? Anyhow - help much appreciated & sorry for the noise ! Regards, Michael. -- michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot

2 4

ODBC Databases: Jet/Access success
by Barry Bird 14 Jun '18

14 Jun '18

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

Google Summer of Code 2018
by André Hentschel 04 Mar '18

04 Mar '18

Hi, I'm currently doing the Org application for Wine, hopefully we'll have a great GSoC year! For now, I need two things from you: - Go through https://wiki.winehq.org/Summer_Of_Code and add/cleanup/remove ideas - Send me a mail if you would like to be a mentor (I will also invite usual mentor candidates to catch the lazy people :) )

5 5

[PATCH] windowscodecs: tiffformat: Fix TiffFrameDecode_GetResolution, add test
by joachim.priesner＠web.de 16 Feb '18

16 Feb '18

From: Joachim Priesner <joachim.priesner(a)web.de> The behavior for the invalid resolution case is different for Windows XP and Server 2003. Implement the behavior of current Windows versions, but allow the old behavior in the test. Signed-off-by: Joachim Priesner <joachim.priesner(a)web.de> --- dlls/windowscodecs/tests/tiffformat.c | 137 +++++++++++++++++++++++++++++++++- dlls/windowscodecs/tiffformat.c | 60 +++++++-------- 2 files changed, 162 insertions(+), 35 deletions(-) diff --git a/dlls/windowscodecs/tests/tiffformat.c b/dlls/windowscodecs/tests/tiffformat.c index e4a4b66ea8..f00b20f7bb 100644 --- a/dlls/windowscodecs/tests/tiffformat.c +++ b/dlls/windowscodecs/tests/tiffformat.c @@ -16,6 +16,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA */ +#include <math.h> #include <stdarg.h> #include <stdio.h> @@ -84,8 +85,8 @@ static const struct tiff_1bpp_data { 0x115, IFD_SHORT, 1, 1 }, /* SAMPLESPERPIXEL */ { 0x116, IFD_LONG, 1, 1 }, /* ROWSPERSTRIP */ { 0x117, IFD_LONG, 1, 1 }, /* STRIPBYTECOUNT */ - { 0x11a, IFD_RATIONAL, 1, FIELD_OFFSET(struct tiff_1bpp_data, res) }, - { 0x11b, IFD_RATIONAL, 1, FIELD_OFFSET(struct tiff_1bpp_data, res) }, + { 0x11a, IFD_RATIONAL, 1, FIELD_OFFSET(struct tiff_1bpp_data, res) }, /* XRESOLUTION */ + { 0x11b, IFD_RATIONAL, 1, FIELD_OFFSET(struct tiff_1bpp_data, res) }, /* YRESOLUTION */ { 0x128, IFD_SHORT, 1, 2 }, /* RESOLUTIONUNIT */ }, 0, @@ -124,8 +125,8 @@ static const struct tiff_8bpp_alpha { 0x115, IFD_SHORT, 1, 2 }, /* SAMPLESPERPIXEL */ { 0x116, IFD_LONG, 1, 2 }, /* ROWSPERSTRIP */ { 0x117, IFD_LONG, 1, 8 }, /* STRIPBYTECOUNT */ - { 0x11a, IFD_RATIONAL, 1, FIELD_OFFSET(struct tiff_8bpp_alpha, res) }, - { 0x11b, IFD_RATIONAL, 1, FIELD_OFFSET(struct tiff_8bpp_alpha, res) }, + { 0x11a, IFD_RATIONAL, 1, FIELD_OFFSET(struct tiff_8bpp_alpha, res) }, /* XRESOLUTION */ + { 0x11b, IFD_RATIONAL, 1, FIELD_OFFSET(struct tiff_8bpp_alpha, res) }, /* YRESOLUTION */ { 0x11c, IFD_SHORT, 1, 1 }, /* PLANARCONFIGURATION */ { 0x128, IFD_SHORT, 1, 2 }, /* RESOLUTIONUNIT */ { 0x152, IFD_SHORT, 1, 1 } /* EXTRASAMPLES: 1 - Associated alpha with pre-multiplied color */ @@ -134,6 +135,81 @@ static const struct tiff_8bpp_alpha { 96, 1 }, { 0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88 } }; + +static const struct tiff_resolution_test_data +{ + struct IFD_rational resx; + struct IFD_rational resy; + LONG resolution_unit; + double expected_dpi_x; + double expected_dpi_y; + /* if != 0: values for different behavior of some Windows versions */ + double broken_dpi_x; + double broken_dpi_y; +} tiff_resolution_test_data[] = +{ + { { 100, 1 }, { 50, 1 }, 0, 100.0, 50.0, 0, 0 }, /* invalid resolution unit */ + { { 50, 1 }, { 100, 1 }, 0, 50.0, 100.0, 0, 0 }, + + { { 100, 1 }, { 50, 1 }, 1, 100.0, 50.0, 0, 0 }, /* RESUNIT_NONE */ + { { 50, 1 }, { 100, 1 }, 1, 50.0, 100.0, 0, 0 }, + + { { 49, 1 }, { 49, 1 }, 2, 49.0, 49.0, 0, 0 }, /* same resolution for both X and Y */ + { { 33, 1 }, { 55, 1 }, 2, 33.0, 55.0, 0, 0 }, /* different resolutions for X and Y */ + { { 50, 2 }, { 66, 3 }, 2, 25.0, 22.0, 0, 0 }, /* denominator != 1 */ + + { { 100, 1 }, { 200, 1 }, 3, 254.0, 508.0, 0, 0 }, /* unit = centimeters */ + + /* XP and Server 2003 do not discard both resolution values if only one of them is invalid */ + { { 0, 1 }, { 29, 1 }, 2, 96.0, 96.0, 0, 29.0 }, /* resolution 0 */ + { { 58, 1 }, { 29, 0 }, 2, 96.0, 96.0, 58.0, 0 }, /* denominator 0 (division by zero) */ + + /* XP and Server 2003 convert the fallback value of 96 dpi to 243.84 dots per centimeter. */ + { { 0, 1 }, { 100, 1 }, 3, 96.0, 96.0, 243.84, 254.0 }, /* resolution 0 and unit = centimeters */ + { { 50, 1 }, { 72, 0 }, 3, 96.0, 96.0, 127.0, 243.84 } /* denominator 0 and unit = centimeters */ +}; + +static struct tiff_resolution_image_data +{ + USHORT byte_order; + USHORT version; + ULONG dir_offset; + USHORT number_of_entries; + struct IFD_entry entry[13]; + ULONG next_IFD; + struct IFD_rational resx; + struct IFD_rational resy; + BYTE pixel_data[4]; +} tiff_resolution_image_data = +{ +#ifdef WORDS_BIGENDIAN + 'M' | 'M' << 8, +#else + 'I' | 'I' << 8, +#endif + 42, + FIELD_OFFSET(struct tiff_resolution_image_data, number_of_entries), + 13, + { + { 0xff, IFD_SHORT, 1, 0 }, /* SUBFILETYPE */ + { 0x100, IFD_LONG, 1, 1 }, /* IMAGEWIDTH */ + { 0x101, IFD_LONG, 1, 1 }, /* IMAGELENGTH */ + { 0x102, IFD_SHORT, 1, 1 }, /* BITSPERSAMPLE */ + { 0x103, IFD_SHORT, 1, 1 }, /* COMPRESSION: XP doesn't accept IFD_LONG here */ + { 0x106, IFD_SHORT, 1, 1 }, /* PHOTOMETRIC */ + { 0x111, IFD_LONG, 1, FIELD_OFFSET(struct tiff_resolution_image_data, pixel_data) }, /* STRIPOFFSETS */ + { 0x115, IFD_SHORT, 1, 1 }, /* SAMPLESPERPIXEL */ + { 0x116, IFD_LONG, 1, 1 }, /* ROWSPERSTRIP */ + { 0x117, IFD_LONG, 1, 1 }, /* STRIPBYTECOUNT */ + { 0x11a, IFD_RATIONAL, 1, FIELD_OFFSET(struct tiff_resolution_image_data, resx) }, /* XRESOLUTION */ + { 0x11b, IFD_RATIONAL, 1, FIELD_OFFSET(struct tiff_resolution_image_data, resy) }, /* YRESOLUTION */ + { 0x128, IFD_SHORT, 1, 1 }, /* RESOLUTIONUNIT -- value will be filled with test data */ + }, + 0, + { 72, 1 }, /* value will be filled with test data */ + { 72, 1 }, /* value will be filled with test data */ + { 0x11, 0x22, 0x33, 0 } +}; #include "poppack.h" static IWICImagingFactory *factory; @@ -370,6 +446,58 @@ static void test_tiff_8bpp_alpha(void) IWICBitmapDecoder_Release(decoder); } +static void test_tiff_resolution(void) +{ + HRESULT hr; + IWICBitmapDecoder *decoder; + IWICBitmapFrameDecode *frame; + double dpi_x, dpi_y; + int i; + + for (i = 0; i < sizeof(tiff_resolution_test_data)/sizeof(tiff_resolution_test_data[0]); i++) + { + const struct tiff_resolution_test_data *test_data = &tiff_resolution_test_data[i]; + tiff_resolution_image_data.resx = test_data->resx; + tiff_resolution_image_data.resy = test_data->resy; + tiff_resolution_image_data.entry[12].value = test_data->resolution_unit; + + decoder = create_decoder(&tiff_resolution_image_data, sizeof(tiff_resolution_image_data)); + ok(decoder != 0, "%d: Failed to load TIFF image data\n", i); + if (!decoder) continue; + + hr = IWICBitmapDecoder_GetFrame(decoder, 0, &frame); + ok(hr == S_OK, "%d: GetFrame error %#x\n", i, hr); + + hr = IWICBitmapFrameDecode_GetResolution(frame, &dpi_x, &dpi_y); + ok(hr == S_OK, "%d: GetResolution error %#x\n", i, hr); + + if (test_data->broken_dpi_x != 0) + { + ok(fabs(dpi_x - test_data->expected_dpi_x) < 0.01 || broken(fabs(dpi_x - test_data->broken_dpi_x) < 0.01), + "%d: x: expected %f or %f, got %f\n", i, test_data->expected_dpi_x, test_data->broken_dpi_x, dpi_x); + } + else + { + ok(fabs(dpi_x - test_data->expected_dpi_x) < 0.01, + "%d: x: expected %f, got %f\n", i, test_data->expected_dpi_x, dpi_x); + } + + if (test_data->broken_dpi_y != 0) + { + ok(fabs(dpi_y - test_data->expected_dpi_y) < 0.01 || broken(fabs(dpi_y - test_data->broken_dpi_y) < 0.01), + "%d: y: expected %f or %f, got %f\n", i, test_data->expected_dpi_y, test_data->broken_dpi_y, dpi_y); + } + else + { + ok(fabs(dpi_y - test_data->expected_dpi_y) < 0.01, + "%d: y: expected %f, got %f\n", i, test_data->expected_dpi_y, dpi_y); + } + + IWICBitmapFrameDecode_Release(frame); + IWICBitmapDecoder_Release(decoder); + } +} + START_TEST(tiffformat) { HRESULT hr; @@ -384,6 +512,7 @@ START_TEST(tiffformat) test_tiff_palette(); test_QueryCapability(); test_tiff_8bpp_alpha(); + test_tiff_resolution(); IWICImagingFactory_Release(factory); CoUninitialize(); diff --git a/dlls/windowscodecs/tiffformat.c b/dlls/windowscodecs/tiffformat.c index a0eec53f5f..e7d4d444c7 100644 --- a/dlls/windowscodecs/tiffformat.c +++ b/dlls/windowscodecs/tiffformat.c @@ -529,21 +529,17 @@ static HRESULT tiff_get_decode_info(TIFF *tiff, tiff_decode_info *decode_info) decode_info->resolution_unit = 0; pTIFFGetField(tiff, TIFFTAG_RESOLUTIONUNIT, &decode_info->resolution_unit); - if (decode_info->resolution_unit != 0) + + ret = pTIFFGetField(tiff, TIFFTAG_XRESOLUTION, &decode_info->xres); + if (!ret) { - ret = pTIFFGetField(tiff, TIFFTAG_XRESOLUTION, &decode_info->xres); - if (!ret) - { - WARN("missing X resolution\n"); - decode_info->resolution_unit = 0; - } + WARN("missing X resolution\n"); + } - ret = pTIFFGetField(tiff, TIFFTAG_YRESOLUTION, &decode_info->yres); - if (!ret) - { - WARN("missing Y resolution\n"); - decode_info->resolution_unit = 0; - } + ret = pTIFFGetField(tiff, TIFFTAG_YRESOLUTION, &decode_info->yres); + if (!ret) + { + WARN("missing Y resolution\n"); } return S_OK; @@ -893,26 +889,28 @@ static HRESULT WINAPI TiffFrameDecode_GetResolution(IWICBitmapFrameDecode *iface { TiffFrameDecode *This = impl_from_IWICBitmapFrameDecode(iface); - switch (This->decode_info.resolution_unit) + if (This->decode_info.xres == 0 || This->decode_info.yres == 0) { - default: - FIXME("unknown resolution unit %i\n", This->decode_info.resolution_unit); - /* fall through */ - case 0: /* Not set */ *pDpiX = *pDpiY = 96.0; - break; - case 1: /* Relative measurements */ - *pDpiX = 96.0; - *pDpiY = 96.0 * This->decode_info.yres / This->decode_info.xres; - break; - case 2: /* Inch */ - *pDpiX = This->decode_info.xres; - *pDpiY = This->decode_info.yres; - break; - case 3: /* Centimeter */ - *pDpiX = This->decode_info.xres / 2.54; - *pDpiY = This->decode_info.yres / 2.54; - break; + } + else + { + switch (This->decode_info.resolution_unit) + { + default: + FIXME("unknown resolution unit %i\n", This->decode_info.resolution_unit); + /* fall through */ + case 0: /* Not set */ + case 1: /* Relative measurements */ + case 2: /* Inch */ + *pDpiX = This->decode_info.xres; + *pDpiY = This->decode_info.yres; + break; + case 3: /* Centimeter */ + *pDpiX = This->decode_info.xres * 2.54; + *pDpiY = This->decode_info.yres * 2.54; + break; + } } TRACE("(%p) <-- %f,%f unit=%i\n", iface, *pDpiX, *pDpiY, This->decode_info.resolution_unit); -- 2.15.1

3 4

Re: [PATCH] arm64: Use __builtin_ms_va_list and __attribute__((ms_abi)) on arm64
by André Hentschel 13 Feb '18

13 Feb '18

Am 14.08.2017 um 12:35 schrieb Martin Storsjo: > Windows uses a different ABI for va_list on arm64 just like on x86_64. > > On x86_64, the calling convention for windows functions is completely > different from the one on other platforms. On arm64, they're mostly the > same, with the only exception being variadic functions (where all float > arguments are passed in integer registers, since the va_list is a single > pointer). > > Any functions using __builtin_ms_va_start need to be decorated with > __attribute__((ms_abi)). > > Add a check in configure for the support of __builtin_ms_va_list > (both features appared in clang at the same time, in the 5.0 release). > > This fixes running binaries that use e.g. printf style functions > (e.g. midl.exe from the windows 10 sdk), fixing > https://bugs.winehq.org/show_bug.cgi?id=38886. > > Signed-off-by: Martin Storsjo <martin(a)martin.st> > --- > clang 5.0, which this requires, isn't yet released, but is in RC2 and > will probably be released pretty soon. > --- > configure.ac | 7 +++++++ > include/msvcrt/crtdefs.h | 6 +++++- > include/windef.h | 6 +++++- > include/wine/test.h | 4 ++-- > 4 files changed, 19 insertions(+), 4 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 7d52b24..c33221f 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -179,6 +179,13 @@ case $host in > CFLAGS="$CFLAGS -marm" > AC_SUBST(TARGETFLAGS,"-marm") > ;; > + aarch64*) > + AC_MSG_CHECKING([whether $CC supports __builtin_ms_va_list]) > + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <stdarg.h>]], [[void func(__builtin_ms_va_list *args);]])], > + [AC_MSG_RESULT([yes])], > + [AC_MSG_RESULT([no]) > + AC_MSG_ERROR([You need clang >= 5.0 to build Wine for arm64.])]) Hi, The upstreamed variadic function handling is terrific, thanks for that! I also like this patch as logical next step, I'm just a bit worried because it locks out current builds without upgrading to an RC... At the moment I'm doing winelib builds with gcc for Linux/ARM64 and clang builds for Android/ARM64. It's quite easy on Linux to pick up a new clang version, not sure how long it takes until clang5 is picked up in the Android NDK... On the other hand, there are not much people building Wine for ARM64, and those can pretty easily revert your patch until they are at clang5 OK... We need this improvement, I'll sign it off :) Now, we only need to convince distributions to avoid x18

3 4

[PATCH 0/8] Initial dhtmled.ocx implementation
by Alex Henrie 09 Feb '18

09 Feb '18

See https://bugs.winehq.org/show_bug.cgi?id=29709 This patchset gets RSSeditor to show its user interface before exiting, which is as much as it does on Wine with native dhtmled.ocx and native triedit.dll. Jacek would be a good person to review these patches. Alex Henrie (8): include: Add dhtmled.idl dhtmled.ocx: Add stub DLL and stub DHTMLEdit object dhtmled.ocx: Add IQuickActivate interface to DHTMLEdit object dhtmled.ocx: Add IViewObject interface to DHTMLEdit object dhtmled.ocx: Add IOleObject interface to DHTMLEdit object dhtmled.ocx: Add IOleControl interface to HTMLEdit object dhtmled.ocx: Add IPersistStreamInit interface to HTMLEdit object dhtmled.ocx: Add IConnectionPointContainer interface to HTMLEdit object configure.ac | 1 + dlls/dhtmled.ocx/Makefile.in | 8 + dlls/dhtmled.ocx/dhtmled.ocx.spec | 4 + dlls/dhtmled.ocx/dhtmled_classes.idl | 39 ++ dlls/dhtmled.ocx/dhtmled_private.h | 19 + dlls/dhtmled.ocx/dhtmled_tlb.idl | 21 + dlls/dhtmled.ocx/edit.c | 1124 ++++++++++++++++++++++++++++++++++ dlls/dhtmled.ocx/main.c | 162 +++++ include/Makefile.in | 1 + include/dhtmled.idl | 330 ++++++++++ 10 files changed, 1709 insertions(+) create mode 100644 dlls/dhtmled.ocx/Makefile.in create mode 100644 dlls/dhtmled.ocx/dhtmled.ocx.spec create mode 100644 dlls/dhtmled.ocx/dhtmled_classes.idl create mode 100644 dlls/dhtmled.ocx/dhtmled_private.h create mode 100644 dlls/dhtmled.ocx/dhtmled_tlb.idl create mode 100644 dlls/dhtmled.ocx/edit.c create mode 100644 dlls/dhtmled.ocx/main.c create mode 100644 include/dhtmled.idl -- 2.15.1

4 15

[PATCH] gdiplus: Use the global HeapAlloc() wrappers
by Michael Stefaniuc 05 Feb '18

05 Feb '18

Signed-off-by: Michael Stefaniuc <mstefani(a)winehq.org> --- dlls/gdiplus/gdiplus_private.h | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/dlls/gdiplus/gdiplus_private.h b/dlls/gdiplus/gdiplus_private.h index 76e5b9b378..ea79f1183c 100644 --- a/dlls/gdiplus/gdiplus_private.h +++ b/dlls/gdiplus/gdiplus_private.h @@ -30,6 +30,7 @@ #include "objbase.h" #include "ocidl.h" #include "wincodecsdk.h" +#include "wine/heap.h" #include "wine/list.h" #include "gdiplus.h" @@ -49,25 +50,6 @@ #define GIF_DISPOSE_RESTORE_TO_BKGND 2 #define GIF_DISPOSE_RESTORE_TO_PREV 3 -static inline void* __WINE_ALLOC_SIZE(1) heap_alloc(size_t size) -{ - return HeapAlloc(GetProcessHeap(), 0, size); -} - -static inline void* __WINE_ALLOC_SIZE(1) heap_alloc_zero(size_t size) -{ - return HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size); -} - -static inline void* __WINE_ALLOC_SIZE(2) heap_realloc(void *mem, size_t size) -{ - return HeapReAlloc(GetProcessHeap(), 0, mem, size); -} - -static inline BOOL heap_free(void *mem) -{ - return HeapFree(GetProcessHeap(), 0, mem); -} COLORREF ARGB2COLORREF(ARGB color) DECLSPEC_HIDDEN; HBITMAP ARGB2BMP(ARGB color) DECLSPEC_HIDDEN; -- 2.14.3

2 1

Jump to page:

2025

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 January 2018