June 2012 - Wine-Devel - list.winehq.org

Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability (try 4).

by Erich E. Hoover

On Thu, Jun 14, 2012 at 11:22 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > ... > > I don't see why you'd want to use ANSI code pages for this, since they > will be converted to Unicode anyway. It's important to use the ANSI code page because of the way the characters are handled internally (you can see this in part 4). If you just convert the characters straight to unicode then ê will become "ê" instead of "ę" in the Polish (?) code page (similar behavior in other code pages). You can see an example in the screenshot from Bug #27767 : http://bugs.winehq.org/attachment.cgi?id=35529 . If you converted straight to Unicode then you'd need to convert it a second time to get the proper character, unless I'm missing something. Erich

June 14, 2012

Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures

by Alexandre Julliard

Hilko Bengen <bengen(a)hilluzination.de> writes: > @@ -46,6 +46,8 @@ > > #include "pshpack1.h" > > +#include <endian.h> endian.h is not portable, you should use the endianness defines from the Wine headers instead. -- Alexandre Julliard julliard(a)winehq.org

June 14, 2012

Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability (try 4).

by Alexandre Julliard

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > Real Name: > Erich Hoover > > Description: > This patch adds the ability in HTML Help to convert HTML encoded > characters (e.g. ê) into the Unicode character equivalent. This > feature is needed by the table of contents and the index for > displaying international characters in some CHM files. As of version > 3 of the patch the decoding is done manually by parsing the HTML > characters instead of using the web browser control, the search is a > now a binary search, and it also includes some additional cleanup. It > is important to note that HTML Help only supports characters within > the ANSI code pages, so support for multi-byte characters is not > necessary. I don't see why you'd want to use ANSI code pages for this, since they will be converted to Unicode anyway. -- Alexandre Julliard julliard(a)winehq.org

June 14, 2012

Re: msvcrt/tests: Fix portuguese locale test on NT4

by Piotr Caban

On 06/14/12 11:41, Marvin wrote: > === WINEBUILD (build) === > Patch failed to apply Looks like wine source was not updated on testbot yesterday.

June 14, 2012

Re: msvcrt/tests: Fix portuguese locale test on NT4

by Marvin

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=19045 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

June 14, 2012

Re: msvcrt: Fix the name of the Portuguese locale alias.

by Michael Stefaniuc

Bruno, On 06/14/2012 11:25 AM, Piotr Caban wrote: > On 06/13/12 23:51, Bruno Jesus wrote: >> Just a side note. Although I'm not sure I think portuguese is "ptg", >> brazilian portuguese is "ptb". So the correct may be: >> >>> + "portuguese", "ptg", >> >> A Portugal user would be able to check that, or maybe it's easier to >> write a testcase. > There already is a test confirming current behavior. It passes on Win7, > fails on NT4. this behavior is consistent with Windows treating Brazilian Portuguese as the "default" Portuguese language: include/winnt.rh:#define SUBLANG_PORTUGUESE_BRAZILIAN 0x01 include/winnt.rh:#define SUBLANG_DEFAULT 0x01 bye michael

June 14, 2012

Re: msvcrt: Fix the name of the Portuguese locale alias.

by Piotr Caban

On 06/13/12 23:51, Bruno Jesus wrote: > Just a side note. Although I'm not sure I think portuguese is "ptg", > brazilian portuguese is "ptb". So the correct may be: > >> + "portuguese", "ptg", > > A Portugal user would be able to check that, or maybe it's easier to > write a testcase. There already is a test confirming current behavior. It passes on Win7, fails on NT4.

June 14, 2012

Re: DllMain() seems unused in ntoskrnl.exe

by Marcus Meissner

On Wed, Jun 13, 2012 at 07:46:47PM +0200, Francois Gouget wrote: > > The DllMain() function in ntoskrnl.exe appears to be unused: making > it static causes a compiler warning to that effect and removing it > entirely does not cause a compilation failure. Should it be removed or > is there a build issue with ntoskrnl.exe? I added a FIXME() at the beginning, then typed "notepad" and it showed fixme:ntoskrnl:DllMain called So it is called. Not exactly sure, but I guess somehow via the loader magic. Ciao, Marcus

June 14, 2012

Re: xbox 360 emulation with logitech cordless and dinput joy disable

by Roderick Colenbrander

On Wed, Jun 13, 2012 at 8:52 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > > The patch needs a few improvements before it can be accepted into Wine. I > can't comment on the dinput / xinput specifics of the patch, so this is a non- > exhaustive list of general suggestions. > > Concerning the big picture, this patch needs a few discussions about > xinput.dll design. There have been some discussions about that in the past, > and I hope that some dinput devs can help out. > > Am Dienstag, 12. Juni 2012, 23:48:53 schrieb Giovanni Ongaro: >> From: root <root(a)joe.(none)> > Please configure git correctly, see http://wiki.winehq.org/GitWine section > 3.3. > > Also consider using a non-root user, but that's your personal setup, so not > really my business. > >> + if (getenv("LINIXFORCENOJOY") != NULL) return FALSE; /*JoeFix disable > joystick*/ > The problem with dinput vs xinput conflicts should probably be solved in a > different manner. That aside, such configurations are usually done via > registry keys. Also comments like /* I changed this here */ are useless, the > git history stores this information anyway. > >> + <...> //JoeFix DEAD ZONE > This is a C++ comment and not allowed in Wine. See > http://wiki.winehq.org/SubmittingPatches > >> + fdJoy=open("/dev/input/js0",O_RDONLY | O_NONBLOCK); > Xinput.dll should not open joystick devices directy, and definitely not a > hardcoded one. I don't know if there's consensus about how xinput should be > implemented, but basing it on top of dinput might be a start. Xinput should not be layered on top of dinput. On Windows it is really a separate relatively low-level dll. The main problem with layering it on top of dinput is that we have to invent some Wine-specific extensions for force feedback which differs from dinput (as far as I remember). Definitely xbox support should not use the classic JS interface, but the event interface (that's also the only one which can be used for other xbox features like the rumble stuff, xbox leds, ..). > > A good start would be to write a few tests to test how Windows announces(or > doesn't announce) Xbox gamepads and other gamepads/joysticks to games. My > understanding is that xinput.dll only works for Xbox gamepads. Do those show > up in dinput on Windows? Xbox gamepads show up twice. Once the xbox360 gamepad driver is loaded, it 'injects' a fake USB Hid gamepad device which is used by dinput (and likely the legacy joystick API). There is no good way to differentiate between the two gamepads. Microsoft recommends applications which support both dinput and xinput to do enumeration through dinput and then use WMI to check if the gamepad is an xbox one. This doesn't work on Wine because we don't have proper WMI support (yet). > >> +#define DEAD_ZONE 4096 >> ... >> + if (e.number == 4) { >> + if (e.value == 1) { >> + FIXME("TRIGGER LEFT PRESSED\n"); >> + pState->Gamepad.bLeftTrigger=32767; >> + } >> + else { >> + pState->Gamepad.bLeftTrigger=0; >> + } >> ... >> +#define JOYMAX 30000 >> +#define JOYMIN -30000 > The hardcoded numbers look questionable. The 4 and 1 are probably specific to > the joystick, the 32767 might have a symbolic name like XINPUT_MAX or > something. The event interface provides proper limits for each axis. I think the js interface has too (forgot the specifics). Definitely axis and button names can't be hard coded to numbers. As I mention later on these numbers (especially through the js-interface) are device specific. Use BTN_A, ABS_X, and so on, but it is impossible to do this for different gamepads. > > A part of this seems to be needed due to the attempt to emulate an xbox > gamepad with a different device. Personally I'm not opposed to doing that, and > you might need some device specific tricks to pull this off. However, this > needs a more structured approach than hardcoding the values needed for one > specific Logitech device in the code. There are a lot of gamepads from different vendors which are xinput compatible. Supporting all of them is easy since they all use the same button names since they use the same driver. We can support non-xinput compatible ones, but it easily becomes tricky. What do you do if a gamepad doesn't have the same buttons? How do you map different button names (xpad devices use BTN_A/BTN_B, while others use BTN_BASE, BTN_BASE2, ..) to the layout of the gamepad? Further input ranges could in theory be different (you can scale values, but you could get still run into issues). Supporting non-xinput devices can be done, but I'm reluctant to doing it in Wine. It is impossible to get it right (every device is different) and it would be complicated for users too. Then there is the whole design part. We had this discussion a couple of times already. Alexandre used to be reluctant about adding OS-specific code to xinput. Personally I think it is the only way to properly implement xinput. Even though the xinput API is very easy (mostly a single poll call) implementing it is tricky. How are you going to open the device? There is nothing like a 'create device' and 'destroy device' call. Do you keep device handles open or do you open/close every call? How do you deal with plug-and-play? The API is designed for hot plugging devices and even the device number of a gamepad can change when you plug in more devices. The old event based interface patches floating around wine-patches were not bad. At some point I cleaned them up, but didn't submit them because we didn't finish the discussion on what the design should be. Roderick > Best regards, > Stefan > > >

June 14, 2012

Re: [11/11] windowscodecs: Implement GetMetadataFormat. Resend.

by Dmitry Timoshkov

Please ignore this patch, it doesn't really belong to this series, and correct implementation should use MetadataReaderInfo interface instead. -- Dmitry.

June 14, 2012