"Alexander Yaworsky" <[EMAIL PROTECTED]> wrote:
> recently i tried to install some application and it hung when i
> tried to select options.
> It uses listbox with ownerdraw items with checkboxes. When listbox
> is initially painted everything is ok. But when i try to select other
> item, an extra
Dmitry Timoshkov wrote:
"Mike McCormack" <[EMAIL PROTECTED]> wrote:
The flag (0x1000) passed to CompareString reverse the sort order of
a number of unicode characters. I've got no idea why it would want to
do that... maybe somebody can shed some light on what the reason behind
this would
Dmitry Timoshkov wrote:
That's my point here: we don't need an external unicode solution, we already
have one, we just need to add missing parts, and we really don't want to depened
on ICU or anything else.
I think the source of the problem is a small misunderstanding about what
LPK.DLL does on
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> I think the source of the problem is a small misunderstanding about what
> LPK.DLL does on windows. It's not where the reordering algorithm is.
> That's in uniscribe. What's there is how this reordering algorithm is
> used for ExtTextOut, DrawText,
On Monday 22 November 2004 09:48, Gerald Pfeifer wrote:
> gmake[2]: Entering directory `/.amd_mnt/nashira/files5/test/wine/dlls/mscms'
> /sw/gcc-3.3.4/bin/gcc -c -I. -I. -I../../include -I../../include
> -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2
> -fno-s
Shachar Shemesh wrote:
Dmitry Timoshkov wrote:
"Mike McCormack" <[EMAIL PROTECTED]> wrote:
The flag (0x1000) passed to CompareString reverse the sort order
of a number of unicode characters. I've got no idea why it would
want to do that... maybe somebody can shed some light on what the
reas
>> I know Dimi is against it, but that looks like a good thing to do to me.
>
>It's not that I'm against it, I don't much care for the sf.net download page,
>really. If people are willing to work on something that is less confusing,
>by all means, but let's try to not complicate our current downloa
On Monday 22 November 2004 12:15, you wrote:
> /usr/local/include/lcms.h, coming from a package called lcms-1.09.
Right, that's a very old version from 2001. Since then the number of APIs
has nearly doubled:
$ grep LCMSAPI tmp/lcms.h | wc -l
88
$ grep LCMSAPI /usr/include/lcms.h | wc -l
162
I'm
On Sun, 21 Nov 2004, Linus Torvalds wrote:
> void handler(int signo)
> {
> extern char smc;
> smc++;
> }
>
> asm volatile("\nsmc:\n\t"
> ".byte 0xb7\n\t"
> ".long function"
>
On Mon, 22 Nov 2004, Andreas Schwab wrote:
>
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > Now, try to "strace" it, or debug it with gdb, and see if you can repeat
> > the behaviour.
>
> You'll always have hard time repeating that under strace or gdb, since a
> debugger uses SIGTRAP for i
On Sun, 21 Nov 2004, Davide Libenzi wrote:
>
> So it seems it did not work even before, the gdb-SIGTRAP stepping. In
> 2.6.8 I get a straight segfault just for running it.
Ok, that at least means it's not a regression, although it may be that the
altered behaviour is enough to make some progr
On Sun, 21 Nov 2004, Davide Libenzi wrote:
>
> You know you're sick, don't you? Making traps inc's to get you in the
> correct opcode to move function in edx->fnp, is indeed fruit of a sick
> mind :=)
I prefer "creative" over "sick". It's so much less judgemental.
I thought it was a fun way
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Now, try to "strace" it, or debug it with gdb, and see if you can repeat
> the behaviour.
You'll always have hard time repeating that under strace or gdb, since a
debugger uses SIGTRAP for it's own purpose and does not pass it to the
program.
Andreas
The following change to dlls/mscms/profile.c
revision 1.6
date: 2004/11/21 15:48:18; author: julliard; state: Exp; lines: +135 -3
Implement and test GetColorProfileElementTag,
GetCountColorProfileElements and IsColorProfileTagPresent. Stub
GetStandardColorSpaceProfile{A,W}.
breaks Fr
On Sun, 21 Nov 2004, Linus Torvalds wrote:
> On Mon, 22 Nov 2004, Andreas Schwab wrote:
> >
> > Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
> > > Now, try to "strace" it, or debug it with gdb, and see if you can repeat
> > > the behaviour.
> >
> > You'll always have hard time repeating that
Linus Torvalds <[EMAIL PROTECTED]> writes:
> IMHO, this is a nice cleanup, and it also means that I can actually debug
> my "program from hell":
Does it also work when trying to single step over it? I guess all bets
are off then.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE
On Fri, Nov 19, 2004 at 01:53:38PM -0800, Linus Torvalds wrote:
>
> On Fri, 19 Nov 2004, Daniel Jacobowitz wrote:
> >
> > I'm getting the feeling that the question of whether to step into
> > signal handlers is orthogonal to single-stepping; maybe it should be a
> > separate ptrace operation.
>
Hello,
i'm looking for a lightweight way to read the windows regitry. I don't
know windows, so i don't know how it's done. The goal in simply to check
the windows network configuration of a machine from a live-cd, to use
the same parameters on the running live-cd. Do i need wine api and dlls
to do
On Sun, 21 Nov 2004, Linus Torvalds wrote:
>
> I'm by no means 100% sure that we should encourage the kind of programming
> "skills" I showed with that example program, so in that sense this may not
> be worth worrying about. That said, I do hate the notion of having
> programs that are basic
On Sun, 21 Nov 2004, Davide Libenzi wrote:
>
> I'd agree with Linus here. A signal handler is part of the application, so
> it should be single stepped in the same way other application code does.
> My original patch simply reenabled the flag before returning to userspace,
> and this had the
On Sun, 21 Nov 2004, Linus Torvalds wrote:
> Ok, how about this patch?
>
> It does basically two things:
>
> - it makes the x86 version of ptrace be a lot more careful about the TF
>bit in eflags, and in particular it never touches it _unless_ the
>tracer has explicitly asked for it (
Shachar Shemesh wrote:
I think the source of the problem is a small misunderstanding about
what LPK.DLL does on windows. It's not where the reordering algorithm
is. That's in uniscribe. What's there is how this reordering algorithm
is used for ExtTextOut, DrawText, EditControl and so on. As such
mammique wrote:
Hello,
i'm looking for a lightweight way to read the windows regitry. I don't
know windows, so i don't know how it's done. The goal in simply to check
the windows network configuration of a machine from a live-cd, to use
the same parameters on the running live-cd. Do i need wine api
Robert Shearman wrote:
Shachar Shemesh wrote:
I think the source of the problem is a small misunderstanding about
what LPK.DLL does on windows. It's not where the reordering algorithm
is. That's in uniscribe. What's there is how this reordering
algorithm is used for ExtTextOut, DrawText, EditCon
On Mon, 22 Nov 2004, Andreas Schwab wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > IMHO, this is a nice cleanup, and it also means that I can actually debug
> > my "program from hell":
>
> Does it also work when trying to single step over it? I guess all bets
> are off then.
If y
On Sun, 21 Nov 2004 15:01:58 -0800, Dan Kegel wrote:
> For the record, I checked, and Red Hat 9's lsb-1.3 package
> simply made ld-lsb.so.1 a symlink to ld-linux.so.2,
I'm pretty sure all distros do that. I've never heard of any LSB compliant
distro using a custom linker to override upstream choic
Jesse Allen a écrit :
On Fri, Nov 19, 2004 at 01:53:38PM -0800, Linus Torvalds wrote:
On Fri, 19 Nov 2004, Daniel Jacobowitz wrote:
I'm getting the feeling that the question of whether to step into
signal handlers is orthogonal to single-stepping; maybe it should be a
separate ptrace operation.
I r
On Mon, 2004-11-22 at 13:10 -0800, Linus Torvalds wrote:
> I actually broke down and am downloading the latest source tree of wine,
> let's see if I can find the place you do this.
The Wine source tree is organised in the same way Windows is, which is
bizarre and unintuitive but we don't really ha
On Mon, 22 Nov 2004 20:01:03 +, Ann and Jason Edmeades wrote:
> Was there a problem with this one - Its really holding me up with progress,
> so I need to ensure I resolve any issues asap. Apologies if this is still in
> your list of patches to work through as I heard you have just moved
If th
On Sun, Nov 21, 2004 at 10:23:41PM -0800, Linus Torvalds wrote:
>
> Ok, how about this patch?
>
> It does basically two things:
>
> - it makes the x86 version of ptrace be a lot more careful about the TF
>bit in eflags, and in particular it never touches it _unless_ the
>tracer has ex
On Mon, Nov 22, 2004 at 04:15:21PM -0700, Jesse Allen wrote:
>
> For the wine app in question, it does make a difference. However, there is
> a new problem. The program gets stuck at the loading screen at 100% CPU.
> It's making a call to select, timing out, and then tries select again,
> repe
On Thursday 18 November 2004 01:29, Brian Gunlogson wrote:
> >
> > But, as Jason is currently doing a lot of work on splitting/moving code
> > to wined3d, we'll have to wait to commit it (and i should help him, when
> > i'll have time).
>
> Is this a tedious task or does it require knowledge of the
Le lun 22/11/2004 à 17:54, Mike Hearn a écrit :
> On Mon, 22 Nov 2004 20:01:03 +, Ann and Jason Edmeades wrote:
> > Was there a problem with this one - Its really holding me up with progress,
> > so I need to ensure I resolve any issues asap. Apologies if this is still in
> > your list of patch
Le ven 19/11/2004 à 15:42, Vincent Béron a écrit :
> Le ven 19/11/2004 à 15:07, Alexandre Julliard a écrit :
> > Mike Hearn <[EMAIL PROTECTED]> writes:
> >
> > > We don't have to be over-general about it, just dynamically loading the
> > > ones that cause problems would be fine (or using syscalls
Dmitry Timoshkov wrote:
>
> If you have a small test case or a snippet of the +relay log showing
> the problem I'll have a look.
>
http://migusoft.ru/misc/trace.bz2
with added ERR()s, see attachment
I cut the tail of log just before the first err:listbox. Note that
there are two listboxes on the fo
On Mon, Nov 22, 2004 at 09:39:32PM -0500, Vincent Béron wrote:
> Now, the obvious question is how can we prevent that in the future?
> Specify a glibc version-release (we'll get users rpm --force'ing it, a
> future glibc update can (or not) break it, etc.)? Let a Wine compiled
> with epoll support
Please do not apply this patch
On Thursday 11 November 2004 11:38 pm, Kevin Koltzau wrote:
> This is a bit of a bad hack, but very bad things happen when a stock brush is
> deleted
>
> Changelog
> Prevent deletion of stock brushes when system colors change
>
CreateBrushIndirect under Wine currently returns stock brushes if the brush
requested
matches the color. In gdi/brush.c the following comment is made:
/* If a solid brush is created in a color matching one of the
* stock brushes, native returns the stock object (GDI heap
* optimisation). Some
Vincent Béron wrote:
So all this boils down to is that RH shipped a glibc update which broke
backwards compatibility, with the same version number (glibc-2.3.2). A
Wine compiled on the newer version takes advantage of epoll support
being present, but will refuse to run on the older version.
Had onl
39 matches
Mail list logo
