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 ICU
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
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. I
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 to
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
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
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
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
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
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 sure
why
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 internal
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
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 else,
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 requiring the
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
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 as
On Sun, 2004-11-21 at 17:40 -0500, Vincent Bron 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. Right
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
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
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,
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 inventing
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
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
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 give great
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 not
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 could edit
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
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 in the
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
29 matches
Mail list logo
