Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
Eventually we have to implement bi-di support there without relying on any
external libraries.
BiDi is a $&!(@*#)$ complicated algorithm (excuse my language). Why on
earth should we insist on writing it ourselves?
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> >Eventually we have to implement bi-di support there without relying on any
> >external libraries.
> >
> >
> BiDi is a $&!(@*#)$ complicated algorithm (excuse my language). Why on
> earth should we insist on writing it ourselves?
We don't really h
On Sat, Nov 20, 2004 at 02:49:15PM -0700, Jesse Allen wrote:
> the interesting part in a seperate file:
> ftp://resnet.dnip.net/
>
I took another look at the section I found. It doesn't describe much, but it
shows "000c: *signal* signal=5" for example, which are probably SIGTRAP's.
I decided to
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
Hmm. Would separating the BiDi code (which is the reason ICU is linked
with GDI) into a separate DLL (they way it is on Windows 2000) help?
We have wine_unicode.dll for that and many things are already separated
there, li
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
Hmm. Would separating the BiDi code (which is the reason ICU is linked
with GDI) into a separate DLL (they way it is on Windows 2000) help?
We have wine_unicode.dll
...
Eventually we have to implement bi-di support there
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> Hmm. Would separating the BiDi code (which is the reason ICU is linked
> with GDI) into a separate DLL (they way it is on Windows 2000) help?
We have wine_unicode.dll for that and many things are already separated
there, like unicode, case map, coll
Mike Hearn wrote:
can't we package Wine as an LSB package?
No, that's really not possible/sensible.
I suspect Wine depends on nothing that isn't in the LSB.
I suspect it depends on a lot, for instance FreeType, OpenSSL, CUPS,
fontconfig, libasound/arts/jack, SANE, libjpeg etc etc.
LSB 2.0 doesn't d
Tom wrote:
Tom wrote:
The 4.72.7325.0 is ok i think. In my tests it runs with IE5, IE6,
Winzip 9.0 and the hhupd.exe itself.
Can you give the Winzip 10 install a try?
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
Tom wrote:
The 4.72.7325.0 is ok i think. In my tests it runs with IE5, IE6,
Winzip 9.0 and the hhupd.exe itself.
Can you give the Winzip 10 install a try?
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:
> Do you think I should add an explicit dependancy on the redhat-release
> (or fedora-release) package, so people don't install them on the wrong
> distribution?
Yes, it would be a good idea considering how many packages you build.
> It's a mess, but Wine does some things so close to glibc that
> i
> I count 24 packages
Well, I've got only one RPM that works on Mandrake 9.2, 10.0 and 10.1, and it
runs on 9.1 too if you upgrade your glibc packages, so having fewer packages is
porbably also possible for RH.
Ivan.
Libero ADSL: nav
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.
Hi,
--- Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> Hmm. Would separating the BiDi code (which is the reason ICU is
> linked
> with GDI) into a separate DLL (they way it is on Windows 2000) help?
> It's something I want to do anyways because:
Having it as a DLL would be nice because then I cou
On Sat, 2004-11-20 at 21:33 +0200, Shachar Shemesh wrote:
> No, that's not what optimizing does. The instruction set of all CPUs
> since 386 is virtually identical, and since 486 is almost completely
> identical. HOWEVER, different internal CPU structure means that the CPUs
> progressively appro
Andreas Mohr wrote:
Hi,
On Sat, Nov 20, 2004 at 04:40:09PM +0100, Sven Paschukat wrote:
#define WINE_FILEDESCRIPTION_STR "Wine htmlhelp OCX"
#define WINE_FILENAME_STR "hhctrl.ocx"
#define WINE_FILEVERSION 4,72,7325,0
#define WINE_FILEVERSION_STR "4.72.7325.0"
#define WINE_PRODUCTVERSION 4,72,7325,0
Mike Hearn wrote:
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 chip designs, or somesuch.
I think an i
Hi,
On Sat, Nov 20, 2004 at 04:40:09PM +0100, Sven Paschukat wrote:
> #define WINE_FILEDESCRIPTION_STR "Wine htmlhelp OCX"
> #define WINE_FILENAME_STR "hhctrl.ocx"
> #define WINE_FILEVERSION 4,72,7325,0
> #define WINE_FILEVERSION_STR "4.72.7325.0"
> #define WINE_PRODUCTVERSION 4,72,7325,0
> #defin
On Sat, 20 Nov 2004 10:34:17 -0500, Vincent Béron wrote:
> That's partly because for myself I like (for no other reason than "I
> can") to have a build optimized for my architecture, which is athlon.
> Building it means uploading it is only a few more minutes. Then, knowing
> that a lot of other pe
On Fri, 19 Nov 2004 22:17:40 -0800, Dan Kegel wrote:
> I wonder, though: the fact that somebody downloaded the wrong
> package means there are probably too many different versions
> at sourceforge to download. I count 24 packages! (OK, a few of
> them are srpms.)
That's typical for open source
"Tom" <[EMAIL PROTECTED]> wrote:
> So should we remove the DirectX product name from the DirectX .rc files or
> just leave it as is ?
I think it's up to DirectX maintainers, although I personally would prefer
to use "Wine" as the product name everywhere without exceptions. After all
that's a rea
Sven Paschukat wrote:
Tom schrieb:
Here is version 1.1a (4.72.7325) but we could go with 1.21 the version
that shipped with win 2K (4.73.8412) and IE 5.5 onward will still
update. and (4.74.8875) is version 1.32 btw...
Any preference?
I have had to append the WINE_FILEVERSION und WINE_PRODUCTVE
On Sun, 21 Nov 2004 00:27:46 +0800, Dmitry Timoshkov <[EMAIL PROTECTED]>
wrote:
"Tom" [EMAIL PROTECTED] wrote:
I changed the format to reflect the other version.rc files
+#define WINE_PRODUCTNAME_STR "winsock"
You don't need to invent a product name, it's already defined in
include/wine/wine_com
"Tom" [EMAIL PROTECTED] wrote:
> I changed the format to reflect the other version.rc files
> +#define WINE_PRODUCTNAME_STR "winsock"
You don't need to invent a product name, it's already defined in
include/wine/wine_common_ver.rc. The product name is Wine.
--
Dmitry.
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 really don't see why. If a controlling process is asking for
single-steppi
> I'm getting the feeling that the question of whether to step into
> signal handlers is orthogonal to single-stepping;
No, it's not. You only ever step into a handler when you ask to.
That's already the interface.
> Platforms which don't implement PTRACE_SINGLESTEP would probably
> appreciate
On Fri, Nov 19, 2004 at 09:41:44PM +0100, Eric Pouech wrote:
> >Btw, does wine ever _use_ PTRACE_SINGLESTEP for any of the things it does?
> >
> >If it does, then that woulc certainly explain why my "fix" made no
> >difference: my fix _only_ handles the case where the ptracer never
> >actually as
On Fri, 19 Nov 2004, Eric Pouech wrote:
>
> wine mixes both approches, we have (to control what's generated inside the
> various exception) to ptrace from our NT-kernel-like process (the ptracer) to
> get the context of the exception. Restart from the ptracer is done with
> PTRACE_SINGLESTEP.
On 2004-11-19 11:18 AM, Jonathan Wilson wrote:
In light of e.g.
http://reactos.com:8080/archives/public/ros-dev/2004-November/000658.html
I would like to suggest the following header ideas.
Currently MingW has:
1.A set of headers that contain a copy of part of the platform SDK
I'm sure you alread
Tom schrieb:
Here is version 1.1a (4.72.7325) but we could go with 1.21 the version
that shipped with win 2K (4.73.8412) and IE 5.5 onward will still
update. and (4.74.8875) is version 1.32 btw...
Any preference?
I have had to append the WINE_FILEVERSION und WINE_PRODUCTVERSION with a
",0" to a
Le sam 20/11/2004 à 01:17, Dan Kegel a écrit :
[snip]
> Or better yet, ask people to download the right package.
> I just downloaded
> http://prdownloads.sourceforge.net/wine/wine-20041019-1rh9winehq.i686.rpm
> and it worked fine on RH9.
That (wrong package installed) is probably the cause of some
Le sam 20/11/2004 à 08:45, Shachar Shemesh a écrit :
> Vincent Béron wrote:
>
> >Le ven 19/11/2004 à 09:02, Mike Hearn a écrit :
> >
> >
> >>1) The RH9 RPMs are apparently being compiled with epoll support linked
> >>in. This is causing user pain. We should really be using dlsym here,
> >>
Hans Leidekker wrote:
On Thursday 18 November 2004 22:45, Sven Paschukat wrote:
What about Tom's suggestion setting a more realistic -lower- version in
builtin hhctrl.ocx? Version number 10.0 is good for applications needing
hhelp functionality, but not for them with installers.
Yes, that may w
Vincent Béron wrote:
Le ven 19/11/2004 à 09:02, Mike Hearn a écrit :
1) The RH9 RPMs are apparently being compiled with epoll support linked
in. This is causing user pain. We should really be using dlsym here,
why are we not again?
If you're talking about this thread
(http://www.linux
On Saturday 20 November 2004 00:53, [EMAIL PROTECTED] wrote:
> I am attempting to install the href="http://televantage.activelogic.com";>TeleVantage Client
> into wine. I have compiled Wine-20041019 from source.
>
> Upon running the installer, I get way too many errors:
[many MSI errors]
I j
34 matches
Mail list logo
