--- Dmitry Timoshkov [EMAIL PROTECTED] a écrit : Duane Clark
[EMAIL PROTECTED] wrote:
In an attempt to revive this thread (since it broke printing for me
too), it appears that if a NULL pointer is passed to:
RtlCreateUnicodeStringFromAsciiz(pNameW,pName);
then it returns an
On Wed, Feb 05, 2003 at 11:44:22PM +0100, Uwe Bonnes wrote:
Hallo,
since about last week, wine compilation stops in d3d8:
device.o: In function `DrawPrimitiveI':
/home/bon/tmp/wine/compile/wine/dlls/d3d8/device.c:535: undefined reference to
`glMultiTexCoord3f'
Dan == Dan Kegel [EMAIL PROTECTED] writes:
Dan How about we hold it as a satellite conference to LinuxTag,
Dan Karlsruhe, Germany, 10-13 July 2003? LinuxTag is a very big, very
Dan cool event. See
Dan http://www.linuxtag.org/2003/en/conferences/cfp.html - Dan
Another event is
fixme:win:GetProcessWindowStation (void): stub
You can ignore lines that refer to window stations I think, it's a part
of the NT window security system.
fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x77a7abc8,pFormat = ^0x77a7ac1a,...):
semi-stub
I'd guess this is the more crucial one.
So,
On Thu, 6 Feb 2003 09:52:42 +0100
Uwe Bonnes [EMAIL PROTECTED] wrote:
Dan == Dan Kegel [EMAIL PROTECTED] writes:
Dan How about we hold it as a satellite conference to LinuxTag,
Dan Karlsruhe, Germany, 10-13 July 2003? LinuxTag is a very big,
very Dan cool event. See
Dan
Keith Matthews wrote:
Dan How about we hold it as a satellite conference to LinuxTag,
Dan Karlsruhe, Germany, 10-13 July 2003? LinuxTag is a very big,
very Dan cool event. See
Dan http://www.linuxtag.org/2003/en/conferences/cfp.html - Dan
Another event is Linux Kongress. In the
On Thu, Feb 06, 2003 at 10:49:17AM +0100, Martin Wilck wrote:
On Mon, 2003-02-03, I wrote:
Why is that relevant to Wine? 99% of the Wine code uses DOS/Windows
functions like WriteFile() anyway. All we need to do is make sure that
these functions handle the Unix fd's properly (and they
I've already sent this to Dimi, but... the demo
http://msdn.microsoft.com/downloads/samples/internet/commctrl/vlistvw/default.asp
doesn't work very well with Wine at the moment.
It demonstrates the LVS_OWNERDATA variant of a listview.
I built it with msvc6. The default view looks ok, but if you
Lionel == Lionel Ulmer [EMAIL PROTECTED] writes:
Lionel On Wed, Feb 05, 2003 at 11:44:22PM +0100, Uwe Bonnes wrote:
Hallo,
since about last week, wine compilation stops in d3d8: device.o: In
function `DrawPrimitiveI':
Just a side issue: On my system (PIII 1GHz), one pair of dup()/close()
calls takes about 1us. Not all too much, but it may matter in
IO-intensive applications.
Of course I am not arguing in favor of sacrificing stability for a tiny
bit of performance. Just another small pro for my patch :-)
LinuxTag is my favorite so far, fwiw, as
1) it looks fairly well organized and interesting in its own right
Yes, this is of course both good and bad.
Good because it is as you said intresting,
bad because we might lose the Wine focus.
This is that IMHO happend at LinuxKongress in Erlangen
Sylvain Petreolle [EMAIL PROTECTED] wrote:
In an attempt to revive this thread (since it broke printing for me
too), it appears that if a NULL pointer is passed to:
RtlCreateUnicodeStringFromAsciiz(pNameW,pName);
then it returns an empty string in pNameW.buffer, rather than
Martin Wilck [EMAIL PROTECTED] wrote:
Why is that relevant to Wine? 99% of the Wine code uses DOS/Windows
functions like WriteFile() anyway. All we need to do is make sure that
these functions handle the Unix fd's properly (and they will if they
don't call close()).
What's up, people?
[EMAIL PROTECTED] wrote:
diff -ur clean/wine/objects/palette.c wine/objects/palette.c
--- clean/wine/objects/palette.c Wed Jan 29 15:31:13 2003
+++ wine/objects/palette.cFri Jan 31 12:47:21 2003
@@ -674,6 +674,7 @@
}
if (!(dc = DC_GetDCPtr( hdc ))) return 0;
prev =
Are you really saying that this function is tranforming every NULL
string pointer
to another one returning \0 ? This is nonsense.
That's correct behaviour. We need to make checks for NULL
everywhere
when appropriate before RtlCreateUnicodeStringFromAsciiz calls to
avoid
this kind of
On Thu, 6 Feb 2003 [EMAIL PROTECTED] wrote:
-TRACE(got %s %s %s %s\n, drive, directory,
- filename, extension);
+char tmpPath[MAX_PATH];
+TRACE(got %s %s %s %s\n,
+ drive ? drive : ,
+ directory ? directory : ,
+ filename ? filename : ,
+
Dan Kegel [EMAIL PROTECTED] wrote:
That looks like a horrible kludge. Before we settle on
something like this, we should probably consult the
people on the unicode mailing list to see what they
suggest.
This is not what I suggest. Please read my complete mail. I wrote:
I did a test on w2k
Hi Martin,
OK, what happens if one thread closes an FD in the middle of another
thread's read operation (that might take multiple accesses to an FD)? I
think that's unlikely, but that seems to me to be what the dup/close
business is all about.
It might be that the previous dup/close code
Greetings,
I'm hoping we are nearing a solution, with so many people involved =)
http://bugs.winehq.com/show_bug.cgi?id=1234 has been updated with logfiles
and my small info.
http://bugs.winehq.com/show_bug.cgi?id=1254 has been created with
my info and logfiles.
What other log files do you
Dmitry Timoshkov [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
RtlUpperChar does not take the locale into account. It always convertes
just
'a' .. 'z' and nothing else.
Is this the right direction or did I miss something?
No, that's not right. We really need to convert to unicode
Hi,
I'm porting a software using winelib and found a (at least I think so)
serious bug with the edit control: When you put a lot of text in an
edit control and then begins to backspace them, the app simply seg faults.
I'm using wine-20030115 but also tried wine-20021031, and both have
this
Felipe W Damasio wrote:
Hi,
I'm porting a software using winelib and found a (at least I think
so) serious bug with the edit control: When you put a lot of text in
an edit control and then begins to backspace them, the app simply seg
faults.
I'm using wine-20030115 but also
[EMAIL PROTECTED] wrote:
RtlUpperChar does not take the locale into account. It always convertes
just 'a' .. 'z' and nothing else.
Is this the right direction or did I miss something?
No, that's not right. We really need to convert to unicode first, then
upper case unicode character and
Geoff Thorpe wrote:
Nonetheless, it is pretty essential that wine's problem get resolved
before these incompatible versions start making it into mainstream
distributions - glibc and linux distribution people leaving wine behind
would not help anyone.
Agreed.
Do we have a definitive
* Dan Kegel ([EMAIL PROTECTED]) wrote:
Not many people are running the new glibc+kernel combination.
It's been hard to do until recently.
I think the key thing for the moment is to get a few developers
set up with it (either via Red Hat 8.1 beta, or via Gentoo (more work,
but much more
Do we have a definitive explanation of just how bad the current
wine/pthread incompatibilities are, and/or where current efforts are at?
I'd not known there were any efforts to get wine working with nptl
(hence my perhaps exaggerated alarm) until the link to Ingo's kernel
patch was posted
[EMAIL PROTECTED] wrote:
ChangeLog:
Fix module entry deallocation in MODULE_DecRefCount.
Description:
Also decrement the reference count on any other libraries with
exactly the same short name since two module entries are being
allocated when we load the library. Maybe
Geoff Thorpe wrote:
Perhaps compiling a UML 2.5.*-based kernel and making a small LFS-style
root filesystem downloadable would be a good idea?
Yes, that would probably help.
It would have to include the latest glibc, etc
(see
Do we have a definitive explanation of just how bad the current
wine/pthread incompatibilities are, and/or where current efforts are at?
I'd not known there were any efforts to get wine working with nptl
(hence my perhaps exaggerated alarm) until the link to Ingo's kernel
patch was posted (aug2002
By the way, it looks like that page has some typos.
The German page looks more correct, and is still mostly
English (go figure):
http://www.linuxtag.org/2003/de/conferences/cfp.html
Well, wherever the summit is hold, I will try to be there this time ... if
we start to agree on a date soon
And we do not need the glibc developers, the ball is in our park ;)
Presuming we knock the ball out of the park, do we have any
hope for backwards compatibility (in other words, can
we build a flavor of Wine that will work both on glibc 2.3
and glibc 2.2?)
Jer
Dan Kegel wrote:
However, it's not clear to me that's required
for developing winethreads-over-pthreads. People
could probably get started on that with their
current Linux, even though it's not 100% posix-compliant,
and has odd quirks like using a special management thread, etc.
Exactly.
Eric Pouech wrote:
among the things we have to take care of:
- signals: signal, in current implementation, is sent to a thread. in
nptl, it's sent to the process. So, lots of thread control has to be
rewritten
- in the same type of issues, getpid() now returns the same pid for all
David Fraser wrote:
Dan Kegel wrote:
However, it's not clear to me that's required
for developing winethreads-over-pthreads. People
could probably get started on that with their
current Linux, even though it's not 100% posix-compliant,
and has odd quirks like using a special management thread,
Following up on myself:
Eric Pouech wrote:
among the things we have to take care of:
- signals: signal, in current implementation, is sent to a thread. in
nptl, it's sent to the process. So, lots of thread control has to be
rewritten
- in the same type of issues, getpid() now
Michael Stefaniuc wrote:
| export LD_ASSUME_KERNEL=2.2.5
Ok, i've checked Phoebe2 with kernel 2.4.20-2.33 and the
LD_ASSUME_KERNEL workaround and wine seems to work just fine. This
should give us some time to move to pthreads.
That's fantastic! I feel much less worried now.
- Dan
On Wed, Feb 05, 2003 at 11:05:08PM +0100, Michael Stefaniuc wrote:
On Wed, Feb 05, 2003 at 01:47:46PM -0800, Francois Gouget wrote:
On Wed, 5 Feb 2003, Michael Stefaniuc wrote:
i hate to reply to myself but here is Ingo's answer:
| could you try:
|
| export
Ulrich Weigand wrote:
Eric Pouech wrote:
among the things we have to take care of:
- signals: signal, in current implementation, is sent to a thread. in
nptl, it's sent to the process. So, lots of thread control has to be
rewritten
- in the same type of issues, getpid() now returns the same
However, at least in the Linux / glibc 2.3.x case, there's a new gettid
call that returns a 'thread ID' that used to be the pid, and a new tkill
system call that can be used to send a signal to one TID, just like the
old Linux kill would send a signal to a specific thread. I think using
those
Geoff Thorpe [EMAIL PROTECTED] writes:
Do we have a definitive explanation of just how bad the current
wine/pthread incompatibilities are, and/or where current efforts are at?
I'd not known there were any efforts to get wine working with nptl
(hence my perhaps exaggerated alarm) until the
Hi,
Tony Lambregts wrote:
Please start a bug for this in Bugzilla
http://bugs.winehq.org
Done.
It got assigned to [EMAIL PROTECTED], though.
Is there someone who could work on this so I can assign this bug to him
directly?
It seems a critical bug and I'm afraid that leaving assigned
On Thu, 2003-02-06 at 15:10, Alexandre Julliard wrote:
Geoff Thorpe [EMAIL PROTECTED] writes:
Do we have a definitive explanation of just how bad the current
wine/pthread incompatibilities are, and/or where current efforts are at?
I'd not known there were any efforts to get wine working
Eric Pouech wrote:
Ulrich Weigand wrote:
LDT sharing should not be a problem (there were bugs in kernels 2.0.x
w.r.t. that issue, but those are long since fixed). The core problem
with the LDT was that the LinuxThreads implementation used to allocate
entries with modify_ldt, and Wine
On Thu, Feb 06, 2003 at 03:31:52PM -0600, Chris Tooley wrote:
On Thu, 2003-02-06 at 15:10, Alexandre Julliard wrote:
Geoff Thorpe [EMAIL PROTECTED] writes:
Do we have a definitive explanation of just how bad the current
wine/pthread incompatibilities are, and/or where current efforts
Felipe W Damasio wrote:
Hi,
Tony Lambregts wrote:
Please start a bug for this in Bugzilla
http://bugs.winehq.org
Done.
It got assigned to [EMAIL PROTECTED], though.
Is there someone who could work on this so I can assign this bug
to him directly?
It seems a
On Thu, 6 Feb 2003, Michael Stefaniuc wrote:
[...]
Ok, i've checked Phoebe2 with kernel 2.4.20-2.33 and the
LD_ASSUME_KERNEL workaround and wine seems to work just fine. This
should give us some time to move to pthreads.
Well, I'm more pessimistic. Unfortunately LD_ASSUME_KERNEL is not a
Michael Stefaniuc wrote:
I realize that this discussion is targeted at a real solution to the
problem, however some of us are already in the situation and are too
dumb to know how to deal with it. On the RedHat Phoebe (Beta versions
already exhibit this problem) it was said that using
the fix doesn't seem the right one... could you post a -debugmsg
+file,+module of what really happens here
The places I've seen it happen are in parts of a large and complicated program -
I'll see if I can find a simple test case that repros the problem and post a
trace here.
But I can give
[EMAIL PROTECTED] wrote:
I did a test on w2k trying to convert all chars between 0 and 255.
The result was:
Just 'a' .. 'z' are converted to 'A' .. 'Z', all other characters remain
unchanged.
I switched the machine between 'EN' (English) and 'DE' (German) and no
difference.
My test
Martin Wilck [EMAIL PROTECTED] writes:
Am Fre, 2003-01-31 um 22.37 schrieb Alexandre Julliard:
I think it's cleaner to return a dup of the fd instead of relying on
the fact that the fd is cached internally. This may not always be the
case, and it's better to risk an fd leak than to risk
Dan Kegel wrote:
I've already sent this to Dimi, but... the demo
http://msdn.microsoft.com/downloads/samples/internet/commctrl/vlistvw/default.asp
doesn't work very well with Wine at the moment.
It demonstrates the LVS_OWNERDATA variant of a listview.
I built it with msvc6. The default view
51 matches
Mail list logo
