Hello,
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 WM_PAINT is sent to listbox when application draws
"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 be?
Just a shot
Marcus Meissner wrote:
Algorithmic changes (like using epoll ;) are bound to bring
way more speedups than silly compiler flags.
epoll reduces wineserver's CPU using when running iTunes from >90% to
less than 4%. Try finding a compiler flag that gives that kind of
improvement ;-)
Mike
On Sun, Nov 21, 2004 at 07:31:40PM -0500, Vincent Béron wrote:
> > Or we could just build some download pages for winehq, and just host the
> > files
> > on sf.net, like that we could make them more user friendly. Or we could make
> > some pages and put them on winehq.sf.net, so that packagers cou
Le dim 21/11/2004 à 18:59, Ivan Leo Puoti a écrit :
> >You're forgetting K6 and K6-2 users with i586. Also, RH never provided
> >i586 packages (except for kernel and glibc), so it'd be foreign to the
> >distro to offer only that.
>
> The why not just 386 and 686, that will fit all.
> And you could
Sunday, November 21, 2004, 2:38:31 PM, you wrote:
> Le sam 20/11/2004 à 13:58, Mike Hearn a écrit :
> [snip]
>> There have been discussions about this on fedora-devel, I think the
>> conclusion was that you don't need to do this. Basically compiling for
>> i586 using athlon scheduling should giv
Vincent Béron wrote:
Le dim 21/11/2004 à 17:19, Dimitrie O. Paun a écrit :
On Sun, Nov 21, 2004 at 04:38:31PM -0500, Vincent Béron wrote:
I never claimed there's a big speed advantage between the 3 builds. But
since I (for myself) prepare the athlon one, and at least the i386 one
for everyb
Dan Kegel wrote:
Bzzt. In the real world, the distro vendor would have noticed
this during LSB certification, and since the shared library
loader for LSB 1.3 is /lib/ld-lsb.so.1 rather than /lib/ld-linux.so.2,
the vendor can easily force libc to be linuxthreads based even
if the default libc is NP
On Sun, Nov 21, 2004 at 05:52:03PM -0500, Vincent Béron wrote:
> Another way to tackle it would be with the distro version not only in
> the filename but in the release name also (20041019 Fedora Core 2, then
> underneath it the list of corresponding packages).
>
> Other ideas?
Rather then invent
>You're forgetting K6 and K6-2 users with i586. Also, RH never provided
>i586 packages (except for kernel and glibc), so it'd be foreign to the
>distro to offer only that.
The why not just 386 and 686, that will fit all.
And you could not build devel and srps packages, or build them but hide them,
Le dim 21/11/2004 à 18:40, Ivan Leo Puoti a écrit :
> > Could we show (our own pages) where users could choose distro, then
> > distro version, then actual package? Instead of pointing them to a few
> > screenful of files directly...
>
> We already partially have this, if you go to http://www.wine
> Could we show (our own pages) where users could choose distro, then
> distro version, then actual package? Instead of pointing them to a few
> screenful of files directly...
We already partially have this, if you go to http://www.winehq.com/download and
click on Red Hat you get this page
http://
On Sun, 2004-11-21 at 17:40 -0500, Vincent BÃron wrote:
> That'd be great, but which lib versions do you plan to link to (Alsa,
> OpenSSL, etc.)? How far back do you want to be compatible with?
Good question. Until lots of users stop complaining that it doesn't work
on their systems, I guess. Righ
Le dim 21/11/2004 à 17:19, Dimitrie O. Paun a écrit :
> On Sun, Nov 21, 2004 at 04:38:31PM -0500, Vincent Béron wrote:
> > I never claimed there's a big speed advantage between the 3 builds. But
> > since I (for myself) prepare the athlon one, and at least the i386 one
> > for everybody else, I may
Mike Hearn wrote:
I'm not aware of e.g. an LSB-1.3 application that doesn't run properly
on any system that supports LSB-1.3. Are you?
I'm not aware of any LSB applications at all, actually. But let's take
RealPlayer for example. Let's pretend that Real had made it an LSB app.
Would that have save
Le dim 21/11/2004 à 17:37, Mike Hearn a écrit :
> On Sun, 2004-11-21 at 16:38 -0500, Vincent Béron wrote:
> > > Yes while we're on the subject the FC2 RPMs are compiled with libICU
> > > giving GDI32 a dependency on libstdc++ 5, whereas FC3 apparently only
> > > installs libstdc++ 6 by default requ
On Sun, Nov 21, 2004 at 05:19:42PM -0500, Dimitrie O. Paun wrote:
> On Sun, Nov 21, 2004 at 04:38:31PM -0500, Vincent Béron wrote:
> > I never claimed there's a big speed advantage between the 3 builds. But
> > since I (for myself) prepare the athlon one, and at least the i386 one
> > for everybody
On Sun, 2004-11-21 at 16:38 -0500, Vincent BÃron wrote:
> > Yes while we're on the subject the FC2 RPMs are compiled with libICU
> > giving GDI32 a dependency on libstdc++ 5, whereas FC3 apparently only
> > installs libstdc++ 6 by default requiring the user to install
> > compat-libstdc++ (assuming
On Sun, Nov 21, 2004 at 04:38:31PM -0500, Vincent Béron wrote:
> I never claimed there's a big speed advantage between the 3 builds. But
> since I (for myself) prepare the athlon one, and at least the i386 one
> for everybody else, I may as well prepare the i686 one.
I think this is a problem: we
Le sam 20/11/2004 à 13:58, Mike Hearn a écrit :
[snip]
> There have been discussions about this on fedora-devel, I think the
> conclusion was that you don't need to do this. Basically compiling for
> i586 using athlon scheduling should give great results on all processors
> even P4 due to the inter
Le sam 20/11/2004 à 14:59, Mike Hearn a écrit :
[snip]
> > I hate that solution. I've been bitten by overly strict dependencies
> > before. If you require libstdc++5, mark as depending on it. Same goes
> > for libc versions.
>
> Makes sense. RPM should have picked it up automatically, I'm not su
Jonathan Wilson wrote:
> Basicly, the idea is that mingw-runtime would become the "definitive" set
> of msvcrt.dll headers out there and that ReactOS, MingW and WINE would
> start using it for any case where you are talking to msvcrt.dll from the
> public side.
I don't know what other people's
> Correct. When a commonly-needed package becomes "stable",
> a snapshot of its interface specification is taken, and added
> to the LSB. LSB applications can then rely on that
> interface being available. That might sound like a no-op,
> but the painstaking attention to detail involved in naili
Stefan Leichter <[EMAIL PROTECTED]> writes:
> The main summary shows that the tests winspool.drv:info
> fails sometimes on the platform win2k, but in the summary
> of win2k (2000 differences) the line winspool.drv:info is
> not listed.
Yep, the display logic is quite simple and broken, although
t
Jeremy White wrote:
... a while back, I asked the
LSB if they'd consider adding Wine to the app-battery (standard tests
required for LSB certification).
They were actually quite open to the notion; Alexandre was working
with someone technical on the challenges involved.
Candidly, I dropped the ball
Mike Hearn wrote:
> [The LSB] really doesn't deal with anything useful at all that isn't already
> stable and on every Linux system anyway.
Correct. When a commonly-needed package becomes "stable",
a snapshot of its interface specification is taken, and added
to the LSB. LSB applications can then
I would like to know if my implementation of GetLayout is clean.
I did not found any information about GetLayout16, I would like to know
if it is correct too.
Thanks
Rémi
diff -u dlls/gdi/dc.c dlls/gdi/dc.c
--- dlls/gdi/dc.c 2004-11-21 18:34:03.0 +0100
+++ dlls/gdi/dc.c 2004-11-21 19:00:3
Hi All,
I've written a regression test that shows what the undocumented flag
0x1000 passed by shlwapi.StrIsIntlEqualW/A to CompareStringW/A does.
I discovered the different by writing a short program that compared
the output of CompareString with and without the flag for all unicode
charac
LSB 3, on the other hand, is going to add Gnome support, so they're
at least thinking about the desktop now.
(Your other objections - FreeType, fontconfig, libjpeg, OpenSSL, etc -
could be packaged along with an LSB implementation of Wine, so they're
not really an issue.)
Forgive the slight shift t
On Sat, 20 Nov 2004 17:09:18 -0800, Dan Kegel wrote:
> LSB 2.0 doesn't deal with sound, scanning, or printing (beyond lpr, anyway?),
It really doesn't deal with anything useful at all that isn't already
stable and on every Linux system anyway.
> so an LSB 2.0 version of Wine would probably have t
On Sunday 21 November 2004 03:23, Tom wrote:
> I cant find WinZip 10 ... I thought they may of had a beta out
> that is why I ask about it. I guess Hans ment WinZip 9 SR1 in
> this post.
>
> http://www.winehq.org/hypermail/wine-devel/2004/11/0412.html
Yes I should have written 9, not 10, sorry.
Hello,
i noticed something wrong in the summary of 200411201000.
The main summary shows that the tests winspool.drv:info fails sometimes on the
platform win2k, but in the summary of win2k (2000 differences) the line
winspool.drv:info is not listed.
Bye Stefan
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> >We don't really have to write it from scratch, porting an existing code
> >would suffice, but a difference between unicode char width (16 vs. 32 bit)
> >makes it impossible to use any system unicode APIs.
> >
> Lost you there. We are currently using
33 matches
Mail list logo