wine-devel

wine-devel@winehq.org

7 participants
84405 discussions

Re: Duplicate: Listview update - LVM_GETITEMRECT
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

On September 10, 2002 10:26 pm, Guy L. Albertelli wrote: > +#if !LISTVIEW_DEBUG > + if (infoPtr->clrBk != CLR_NONE) > +#endif > + { > + HBRUSH hBrush = CreateSolidBrush(clrbrsh); > + FillRect(hdc, rc, hBrush); > + DeleteObject(hBrush); > + } > +} I *really* don't like these #ifs. Do we really have to have them? listview.c is already such a big file, and it's not easy to work with. Let's not make it harder... -- Dimi.

1 0

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Of course potentially all types could teoretically be used so that > > would be VERY ugly... > > In theory maybe, but in practice I think there are very few structures > where this would be a problem. Yes. None of the structures in mssip have this problem AFAICS. > So we can simply fix the alignment > explicitly in these structures, either with padding or with > __attribute__. Yes. Thinking again. You can IIRC apply __attribute__((aligned(n))) to a specific field, you doesn't need to do it per type. However the only easy way to dectect automatically where you should add it will be using something like below. > A nice thing to have would be a script that parses the headers and > generates code to dump the size of all structures and the offsets of > all their members. Then we can build that code under Windows and > Winelib and compare the results. It has been in my TODO list for quite some time. I just never got around to do it. > I'm sure it's a 10 minute hack for > you to extend winapi_check to do this <g> winapi_check can't currently parse data structures so I have to teach it that first. That will take a lot more time than 10 minutes...

1 0

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Patrik Stridvall wrote: > > > So it seems that if we add a -malign-double to CFLAGS we can > > remove the warning in pshpack8.h since now it will hopefully > > work correctly. > > Yes. However, the -malign-double option obviously causes GCC > to produce code that in some cases does not conform to the > Linux/i386 ABI. So, if Wine were to call any standard > library routines whose ABI is affected by -malign-double > (because a parameter is a structure type which is layed > out differently), we'd have a problem here ... Arrgggghhhhhhhh!!! :-( The alternative would be to add an explict __attribute__((aligned(8))) to all types larger than 4 bytes that can be used by #pragma pack(8) aligned structures. Of course potentially all types could teoretically be used so that would be VERY ugly...

2 1

Brazilian ABNT-2 Keyboard - DeadKeys not operates properly
by Salatiel-Robson Oliveira 10 Sep '02

10 Sep '02

Francois, I am using the last version --> Wine-20020904 (Setember) and unfortunately the problem continues. What can we to change in the file keyboard.c to solve this problem? Thank you for attention!!! Salatiel Robson Francois Gouget Para: Salatiel-Robson Oliveira <fgouget(a)free.fr> <salatiel-robson.oliveira(a)serpro.gov.br> 10/09/2002 16:49 cc: wine-devel(a)winehq.com Assunto: Re: Brazilian ABNT-2 Keyboard - DeadKeys not operates properly - On Tue, 10 Sep 2002, Salatiel-Robson Oliveira wrote: > > Hi !!! > > For start, I want to say that I'm Brazilian and my english is terrible. > Excuse me for mistakes. > > My question: > > I have a keyboard Brazilian-ABNT2, the WINE recognize the layout perfectly, > but the "DeadKeys" doesn't operates properly. > > For example: I want that appear à ã â á , but appear `a ~a ^a ´a Dead-key support is relatively recent (2 months, maybe 3). Which version of Wine are you using? If it's more than a month old I would recommend upgrading to the latest version. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

1 0

Brazilian ABNT-2 Keyboard - DeadKeys not operates properly
by Salatiel-Robson Oliveira 10 Sep '02

10 Sep '02

Hi !!! For start, I want to say that I'm Brazilian and my english is terrible. Excuse me for mistakes. My question: I have a keyboard Brazilian-ABNT2, the WINE recognize the layout perfectly, but the "DeadKeys" doesn't operates properly. For example: I want that appear à ã â á , but appear `a ~a ^a ´a Do you understand? Can you help me!!! Thanks!!! (See attached file: keyboard.c) Salatiel Robson

2 1

unhandled exception does not longer raise the winedbg
by Stefan Leichter 10 Sep '02

10 Sep '02

Hello, i have posted this message to cemw before, but the message appeared only partly there (checked on google) and this mailing list might be the better place for the problem. Here is my problem: In the past when i ran Paintshop Pro 5/6 in wine a wineconsole had opened with the debugger after an unhandled exception. This is broken for me in the current release (20020904). The exception occures but the debugger does not start as you can see in the attached trace. Does anyone else have this problem or know a fix? After i have noticed the problem i rebuilt the previous release (20020804) from scratch again to be sure that this is not a problem of my installation and winedbg appears as expected. Thanks for answer Stefan PS: for the record System is SuSE Linux 7.3 wine 20020904 build from source, updated by the patch file from the tiger.informatik.hu-berlin.de mailing list

1 0

Re: patches policy
by Jeff Smith 10 Sep '02

10 Sep '02

I prefer the attaching text method, to be *sure* the patch is not mangled, but that *anyone* can read it (e.g. I may want to review a patch from a location that does not offer me gzip or whatever the compression scheme de jour is). Also, have you tried adjusting the "Screen Width" settings in "General Preferences" in Yahoo Mail? -- Jeff S >From: Andriy Palamarchuk <apa3a(a)yahoo.com> >To: dimi(a)bigfoot.com, Wine Devel <wine-devel(a)winehq.com> >Subject: Re: patches policy >Date: Mon, 9 Sep 2002 11:30:37 -0700 (PDT) > >--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > Hi all, > > > > There is something concerning submitting patches > > that bothers me > > to no end: inlining vs. attaching them. >[skipped] > >I have to attach the patches :-( because I use Yahoo >online mail client and it wraps long lines. >I also usually compress patches with size >= 20-30kb >to save everybody's bandwith. > >It is good idea to add these recommendations to the >Starter's guide, even if we are not going to enforce >them. > >Andriy, >Boston, MA _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

2 1

[PATCH] winemaker: fix catch() and throw() in winelib DLLs
by Martin Wilck 10 Sep '02

10 Sep '02

Patch: winemaker-wrapper.diff Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> Patch against: CVS 2002-09-10 Modified files: - tools: winemaker * A wrapper binary should not be linked to any library passed with "-l". [ I am forwarding this to wine-devel because the problem may be deeper than I think, see below ]. Rationale: This fixes a delicate problem with catch() and throw() in a DLL used by a winelib application that has a wrapper app. I have written this small, hopefully self-explaining, shell script that demonstrates the problem. (Note that my previous winemaker patches are necessary otherwise there'll be other errors before this one comes into play). #! /bin/sh # throwtest.sh - test winemaker with catch()/throw() in a DLL # Change this to the location of your wine installation (DLL will also be installed there) WINEDIR=$HOME/exp # Extra winemaker options to build EXE: CORE DUMP with --wrap, fine without EXEOPTS="--wrap" # Extra winemaker options to build DLL DLLOPTS="" errexit () { echo "** Error $1 !! **" >&2 exit 1 } export PATH=$WINEDIR/bin:$PATH export LD_LIBRARY_PATH=$WINEDIR/lib:$LD_LIBRARY_PATH echo "Building library ..." >&2 mkdir -p trylib cd trylib rm -f * # BEWARE !!! cat > trylib.cpp <<EOF int do_try (void) { int ret = 0; try { throw(1); } catch (int e) { ret = e; } return ret; } EOF winemaker --dll $DLLOPTS . > winemaker.out 2>&1 || errexit "running winemaker for library" ## remove the "init DllMain" declaration winemaker generates echo "" >libtrylib.spec ./configure --with-wine=$WINEDIR --prefix=$WINEDIR > conf.log 2>&1 || errexit "during library configure" make >make.log 2>&1 || errexit "building library" make install >>make.log 2>&1 || errexit "installing library" cd .. echo "Building program ..." >&2 mkdir -p tryexe cd tryexe rm -f * # BEWARE !!! cat > tryexe.cpp <<EOF #include <stdio.h> extern int do_try (void); void main (void) { printf ("Result: %d\n", do_try()); } EOF winemaker --cuiexe $EXEOPTS -ltrylib . > winemaker.out 2>&1 || errexit "running winemaker for program" ./configure --with-wine=$WINEDIR --prefix=$WINEDIR > conf.log 2>&1 || errexit "during program configure" make >make.log 2>&1 || errexit "building program" echo "Running program ..." >&2 ./tryexe >run.out 2>&1 || errexit "running program" echo "** Success !! **" >&2 # EOF throwtest.sh On my system, this yields the following output: Building library ... Building program ... Running program ... throwtest.sh: line 65: 14430 Aborted (core dumped) ./tryexe >run.out 2>&1 ** Error running program !! ** The reason is that "-ltrylib" becomes part of the DLL_LINK make variable and the wrapper app is thus linked with "libtrylink.so". If my analysis is correct, this leads to a situation where the gcc-generated exception code for throw() jumps into the wrapper app rather than into the wrapped app - i.e. to nowhere. IMO it makes no sense to include any additional libraries in the link list for the wrapper app (=> patch). If this isn't done, the test runs fine. This may point to a conceptual problem with the wrapper app approach, but at least it seems to run fine with the patch below. Index: tools/winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.47 diff -u -r1.47 winemaker --- tools/winemaker 10 Sep 2002 00:42:43 -0000 1.47 +++ tools/winemaker 10 Sep 2002 18:21:57 -0000 @@ -1993,7 +1993,11 @@ } else { print FILEO "\t\$(LDSHARED)"; } - print FILEO " \$(LDDLLFLAGS) -o \$\@ \$(${canon}_OBJS) \$(${canon}_SPEC_SRCS:.spec=.spec.o) \$(${canon}_LIBRARY_PATH) \$(${canon}_LIBRARIES:%=-l%) \$(DLL_LINK) \$(LIBS)\n"; + if (@$target[$T_FLAGS] & $TF_WRAPPER) { + print FILEO " \$(LDDLLFLAGS) -o \$\@ \$(${canon}_OBJS) \$(${canon}_SPEC_SRCS:.spec=.spec.o) \$(${canon}_LIBRARY_PATH) \$(${canon}_LIBRARIES:%=-l%) \$(WRAPPER_DLL_LINK) \$(LIBS)\n"; + } else { + print FILEO " \$(LDDLLFLAGS) -o \$\@ \$(${canon}_OBJS) \$(${canon}_SPEC_SRCS:.spec=.spec.o) \$(${canon}_LIBRARY_PATH) \$(${canon}_LIBRARIES:%=-l%) \$(DLL_LINK) \$(LIBS)\n"; + } if (@$target[$T_TYPE] ne $TT_DLL) { print FILEO "\ttest -f @$target[$T_NAME] || \$(INSTALL_SCRIPT) wineapploader @$target[$T_NAME]\n"; } @@ -3043,6 +3047,7 @@ ALLCFLAGS = $(CFLAGS) $(CEXTRA) $(OPTIONS) $(ALLFLAGS) ALLCXXFLAGS=$(CXXFLAGS) $(CXXEXTRA) $(OPTIONS) $(ALLFLAGS) ALLWRCFLAGS=$(WRCFLAGS) $(WRCEXTRA) $(OPTIONS) $(ALLFLAGS) +WRAPPER_DLL_LINK = $(LIBRARY_PATH) $(WINE_LIBRARY_PATH) -lwine -lwine_unicode -lwine_uuid DLL_LINK = $(LIBRARY_PATH) $(LIBRARIES:%=-l%) $(WINE_LIBRARY_PATH) -lwine -lwine_unicode -lwine_uuid LDCOMBINE = ld -r LDSHARED = @LDSHARED@ -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Patrik Stridvall wrote: > > > On MSVC it does matter in the following example whether n is 4 or 8. > > Or 16 for that matter eventhough that gives the same result as 8. > > > > #ifdef _MSC_VER > > typedef __int64 longlong_t; > > #else > > typedef long long longlong_t; > > #endif > > > > #pragma pack(n) > > typedef struct { > > char x; > > longlong_t y; /* offset is 4 if n = 4, but is 8 if n = > 8 or n = 16*/ > > } longlong_n; > > #pragma pack() > > I would assume that MSVC and GCC use different structure > layouts even without any #pragma pack(), because the > default aligment of 8-byte data types is different. > > As I mentioned in my other mail, GCC should use the same > layout as MSVC if you compile with -malign-double. As I mention in my other mail you are absolutely correct. :-) So it seems that if we add a -malign-double to CFLAGS we can remove the warning in pshpack8.h since now it will hopefully work correctly.

2 1

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Ah, I guess I see the problem: it doesn't really have > anything to do with #pragma pack(), but with the default > alignment of the 'long long' data type itself. > > GCC uses a default alignment of 4 bytes for 'long long', > so, if MSVC uses a default alignment of 8, that would be > the problem. You seem to be correct. With this code: #ifdef _MSC_VER typedef __int64 longlong_t; #else typedef __attribute__((aligned (8))) long long longlong_t; #endif GNU C now works the same as with MSVC. > However, I think you can get GCC on i386 to use a default > alignment of 8 for 8-byte sized types, by specifying the > compiler option -malign-double. Yes, that works with GNU C as well. Even without my hack above. > (Then you'll probably > have to use -mpreferred-stack-boundary=3 instead of > -mpreferred-stack-boundary=2 as well.) It doesn't seem to do any difference in my simple example either with -mpreferred-stack-boundary=2 or -mpreferred-stack-boundary=3. The only thing that matters is whether -malign-double is set.

1 0

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