July 2002 - Wine-Devel - list.winehq.org

Re: Dinput - Keyb Bug

by Steven Edwards

You need to use the windows dinput.dll as ours is (still) not up to spec. I used to play this game all the time under linux till tribes2. I dont know if this will work with the directx 8.1 but if you can find a dinput.dll from dx5 or 6 it should work. I will add this information to the wine application database if its not already there and if someone working on directx can figure out what is going on that would rock long term. Thanks Steven --- Kristoffer Ericson <kristoffer_e1(a)hotmail.com> wrote: > I'm trying to get StarSiege Tribes (1) to work, and from what i gather is it > suffering from a quite common wine-gaming-problem (both wine & winex). > > The game starts smoothly enough but keyboard is dead. When i press any key > it will instantly drop out and quit. No error message or breaks. > Considering the keyboard makes you move it basicly leaves you jumping up and > down shooting at everything that comes..=) Other than the keyboard error > tribes runs fine. > > I daily run updates from winex & wine but been working at this problem for > about 2 weeks. > > I've read all the info i could find on the subject and from what i can > gather is that tribes used to work on older wine. So can anyone give me some > futher info about where i could find older wine-archives or if the dinput (i > guess the problem is due to dinput) problem is about to be solved�, tweaks, > patches, ideas.. > > With respect Ken > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com

July 23, 2002

Re: CallNextHookEx16 strageness

by Michael Stefaniuc

On Tue, Jul 23, 2002 at 12:01:25PM -0700, Alexandre Julliard wrote: > Michael Stefaniuc <mstefani(a)redhat.com> writes: > > > I don't know what the right fix would be, I'm seeing two possibilities: > > - remove in CallNextHookEx16 the check > > if (HIWORD(hhook) != HOOK_MAGIC) return 0; > > - or transform in DefHookProc16 and ShellHookProc16 the first parameter > > passed to CallNextHookEx16 to a real HHOOK with the HIWORD set to 'HC' > > The second is right, we should always pass a real HHOOK. In fact a > hook handle is 32 bit even in Win16, so it's never correct to assign > it to a HANDLE16; we do this at a few other places too, that should > probably be fixed. I've changed DECLARE_OLD_HANDLE(HHOOK) to DECLARE_HANDLE(HOOK) and I'm compiling wine with -DSTRICT and the two above functions were the only ones that did an implicit conversion from a HANDLE16 to a HHOOK. There is only one cast to HHANDLE but that should be ok: return (HHOOK)( handle? MAKELONG( handle, HOOK_MAGIC ) : 0 ); It seems that we don't have an implicit transformation of a HHOOK to a HANDLE16. Most of the internal HOOK_* functions are using HANDLE16's and the few functions that accepts as parameter a HHOOK are checking for the presence of the HOOK_MAGIC and are doing the conversion to a HANDLE16 with LOWORD(hhook). I've also looked over the casts to a HANDLE16 and it seems that no HHOOK is transformed this way. The attached patch fixes the bug and also converts HHOOK to a void* License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - fix the calls to CallNextHookEx16() - convert HHOOK to a void* bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

July 23, 2002

Re: Winelib and documentation

by Francois Gouget

On Tue, 23 Jul 2002 steve_lustbader(a)hsgmed.com wrote: > I've been having some trouble using winelib (with spec files) > following the documentation on the web site. A few people in the IRC > channel were under the impression that winelib had changed and the > docs aren't really relevant anymore. You should look into winemaker. winemaker has been updated recently and I believe it should work though I did not have time to test it recently. > Is the documentation going to be > updated to the current status of the source? This is one of the things I would like to do during my next vacation at the beginning of August. But of course there is no garantee I will get to it. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

July 23, 2002

Re: Configure.in

by Gregg Mattinson

Same thing is defined on my system, so I think it is correct. LD_PATH is used to add paths infront of LD_LIBRARY_PATH for when wrc and winebuild are run. On my system, before the line you mentioned, LD_PATH is set to $wine/library:$wine/dlls. Then, it is changed to prepend itself to the environment variable LD_LIBRARY_PATH. Gregg Mattinson Co-op Developer Sun Microsystems of Canada >From: steve_lustbader(a)hsgmed.com >To: wine-devel(a)winehq.com >Subject: Configure.in >Date: Tue, 23 Jul 2002 14:20:53 -0600 > >In the configure.in that winemaker generates for me, LD_PATH gets defined as LD_PATH="LD_LIBRARY_PATH=\"$LD_PATH:\$\$LD_LIBRARY_PATH\"" It seems like it's missing a linebreak, or it's doing something very weird. Is this right? > >****************************** >Steve Lustbader > >Philips Medical Systems E-mail: steve_lustbader(a)hsgmed.com >3000 Minuteman Road, MS 0105 Voice: 978 659 3713 >Andover, MA 01810 >

July 23, 2002

Re: PATCH: [Bug 19] - font enumeration problems for aliased gdi fonts

by Huw D M Davies

On Tue, Jul 23, 2002 at 01:00:59PM -0700, Rafael Kitover wrote: > This patch fixes the "Invalid Property Value" message box that pops up > in older visual basic programs on startup when they try to call > ENUMFONTS on the default "MS Sans Serif" font for example. > > (reference: http://www.winehq.com/hypermail/wine-bugs/2002/05/0116.html) > > License: LGPL, X11 > > Changelog: > Rafael Kitover <caelum(a)debian.org> > Fix ENUMFONTS on aliased gdi fonts What's exactly the problem here? Is it lack of support of 16bit EnumFonts ? Huw.

July 23, 2002

Configure.in

by steve_lustbader＠hsgmed.com

In the configure.in that winemaker generates for me, LD_PATH gets defined as LD_PATH="LD_LIBRARY_PATH=\"$LD_PATH:\$\$LD_LIBRARY_PATH\"" It seems like it's missing a linebreak, or it's doing something very weird. Is this right? ****************************** Steve Lustbader Philips Medical Systems E-mail: steve_lustbader(a)hsgmed.com 3000 Minuteman Road, MS 0105 Voice: 978 659 3713 Andover, MA 01810

July 23, 2002

Re: wine/dlls crtdll/crtdll.spec crtdll/crtdll_mai ...

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > Anyway, the real problem seems to be that the the functions you > implemented in crtdll_main.c were already implemented in msvcrt. Yes, I didn't notice they were already there. I'll take them out. -- Alexandre Julliard julliard(a)winehq.com

July 23, 2002

Re: CallNextHookEx16 strageness

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.com> writes: > I don't know what the right fix would be, I'm seeing two possibilities: > - remove in CallNextHookEx16 the check > if (HIWORD(hhook) != HOOK_MAGIC) return 0; > - or transform in DefHookProc16 and ShellHookProc16 the first parameter > passed to CallNextHookEx16 to a real HHOOK with the HIWORD set to 'HC' The second is right, we should always pass a real HHOOK. In fact a hook handle is 32 bit even in Win16, so it's never correct to assign it to a HANDLE16; we do this at a few other places too, that should probably be fixed. -- Alexandre Julliard julliard(a)winehq.com

July 23, 2002

Re: PATCH: SetParent optimization

by Ann and Jason Edmeades

> Probably SetWindowLong(GWL_HWNDPARENT) should not do a full SetParent, > but just set the window owner. Looks like this needs more testing > under Windows to find out exactly what it's supposed to do. Interestingly I took out that SetParent call as a hack to get beyond bug#825 which is exactly what VB is doing for 'modal' windows (setting GWL_HWNDPARENT) which basically means modal windows become unusable. Jason

July 23, 2002

RE: Winelib and documentation

by Andriy Palamarchuk

Steve, if you don't mind lets continue the discussion in public. --- "LUSTBADER,STEVE (Non-A-hsgAndover,ex1)" <steve_lustbader(a)hsgmed.com> wrote: > > > Is the > > > documentation going to be updated to the current > > > status of the source? > > > > Yes, but I do not know when. As far as I know > nobody > > is working on the guide right now. > > If you provide information which part of the guide > is > > outdated somebody may want to fix it. > > > > The problem I was specifically having was with spec > files and import statements - it seems like imports > don't belong in specs anymore. Yes, you are right here. Now it is done by the following definition in Makefile.in file: ... IMPORTS = advapi32 kernel32 ... As an example of using Winelib I advise you to look into Wine programs (see programs subdirectory of the Wine source tree). These programs are compiled as Winelib programs, you probably will want to do something similiar. Andriy __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com

July 23, 2002