On April 4, 2003 12:26 am, Sylvain Petreolle wrote:
> Apart RedHat, which system needs "alias wine='wine --with-ntpl'" to
> work properly ?
This is a configure option, not a wine option.
--
Dimi.
Since this patch, I get some applications that run into an infinite
loop. (example : winword). I don't use --with-nptl, should I ?
RH8.0 glibc 2.3.2 gcc 3.2
Max
On Fri, 2003-04-04 at 05:07, Alexandre Julliard wrote:
> "Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
>
> > Alexandre,
> >
> > I've
Maybe a little bit off topic but I think it is interesting.
I am working on kernel32 LanguageGroups functions (patch soon) and they
need some registry entries to work. As the registry keys are language
dependent, it could be great if they could be set at install time
according to the will of the u
Ok then.
Which systems need this option ?
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> a écrit :
> On April 4, 2003 12:26 am, Sylvain Petreolle wrote:
> > Apart RedHat, which system needs "alias wine='wine --with-ntpl'" to
> > work properly ?
>
> This is a configure option, not a wine option.
=
Apart RedHat, which system needs "alias wine='wine --with-ntpl'" to
work properly ?
> Yes, it's supposed to work. You have to use --with-nptl for now, I'm
> hoping to make it switchable at run time later; but apart from that
> it's mostly ready.
=
Sylvain Petreolle (spetreolle at users dot s
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Yes, it does, thanks! (I know, what are our alternatives?)
Well, I'm wondering if we shouldn't enforce that using winsock implies
using msvcrt, the mixed case winsock+Unix glibc is very fragile (and
actually it's already broken at least for gethost
On April 3, 2003 11:06 pm, Alexandre Julliard wrote:
> Well, I'm wondering if we shouldn't enforce that using winsock implies
> using msvcrt, the mixed case winsock+Unix glibc is very fragile (and
> actually it's already broken at least for gethostname).
Mind you that I compile PuTTY with msvcrt.
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> On April 3, 2003 10:07 pm, Alexandre Julliard wrote:
> > Yes, it's supposed to work. You have to use --with-nptl for now, I'm
> > hoping to make it switchable at run time later; but apart from that
> > it's mostly ready.
>
> Cool. Can't we detect a
On startup, PuTTY remains in an infinite loop. A run with --debugmsg +all
reveals the following repeating sequence:
[...]
000b: get_message( flags=1, get_win=(nil), get_first=, get_last= )
000b: get_message() = 0 { type=5, win=0x10048, msg=0118, wparam=,
lparam=40f806f
On April 3, 2003 10:20 pm, Alexandre Julliard wrote:
> Does this help? (this stuff is starting to be really ugly...)
Yes, it does, thanks! (I know, what are our alternatives?)
--
Dimi.
On April 3, 2003 10:07 pm, Alexandre Julliard wrote:
> Yes, it's supposed to work. You have to use --with-nptl for now, I'm
> hoping to make it switchable at run time later; but apart from that
> it's mostly ready.
Cool. Can't we detect at configure time that we need NPTL?
--
Dimi.
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> I get this when trying to compile putty:
>
> winegcc-mno-cygwin -Wall -O2 -D_WINDOWS -DDEBUG -DWIN32S_COMPAT -DNO_SECURITY
> -D_NO_OLDNAMES -DNO_MULTIMON -I. -c winnet.c
> In file included from /usr/local/include/wine/windows/windows.h:62,
>
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Alexandre,
>
> I've noticed you've checked in already some NTPL patches.
> Does this mean that Wine is ready for RH9? Can I go ahead
> and upgrade my system?
Yes, it's supposed to work. You have to use --with-nptl for now, I'm
hoping to make it sw
I get this when trying to compile putty:
winegcc-mno-cygwin -Wall -O2 -D_WINDOWS -DDEBUG -DWIN32S_COMPAT -DNO_SECURITY
-D_NO_OLDNAMES -DNO_MULTIMON -I. -c winnet.c
In file included from /usr/local/include/wine/windows/windows.h:62,
from /usr/local/include/wine/windows/winsock
Alexandre,
I've noticed you've checked in already some NTPL patches.
Does this mean that Wine is ready for RH9? Can I go ahead
and upgrade my system?
--
Dimi.
Mike Hearn <[EMAIL PROTECTED]> writes:
> Install time is an extra step that would increase packaging
> complexity.
We will need a way to create the initial registry anyway,
'regedit winedefault.reg' is clearly not enough, we need to do the dll
registration etc. So it can be added there.
> Wine s
> I don't think we want to have 'magic' registry entries that are
> computed dynamically, at least not inside the normal branches. There
> are dynamic branches like HKEY_DYN_DATA where we will need that, but I
> think the rest should use the normal update mechanisms. For things
> like plugging in a
Apart from the duplication of the signal mechanism, it also introduces
races, since we depend on the client to do part of the suspend
code. It means the server state will not necessarily match the actual
state of the client thread, which could cause trouble. I'm still not
convinced we want that in
Rod Taylor wrote:
By default it seems to return EINVAL.
Line 953
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/sound/pcm/dsp.c?annotate=1.62
so something like this should do.
A+
--
Eric Pouech
Index: dlls/winmm/wineoss/audio.c
=
> > killing a local thread could work the same way - it doesn't at the
> moment, but if you are
> > killing a thread your code is badly broken anyway.
>
> Many Windows apps do that.
why would we want to be broken ??
=
Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597
Adam Gundy <[EMAIL PROTECTED]> writes:
> OK.. I've just tried doing this but I don't appear to be able to redirect
> functions declared as "-register" (longjmp, setjmp, setjmp3 and __CxxFrameHandler).
This is a bug in winebuild, it should be fixed now.
--
Alexandre Julliard
[EMAIL PROTECTED]
Mike Hearn <[EMAIL PROTECTED]> writes:
> The wineserver seems the most logical choice, but I'm not sure if there
> are any special rules regarding it, nor whether Alexandre would accept
> stuff like interface probing into the server, it might be considered
> bloat. Care to comment Alexandre? Which
Adam Gundy <[EMAIL PROTECTED]> writes:
> the whole problem is that the wineserver wants to have unique PIDs for each thread
> so that
> it can send signals to them, and attach to them for debugging. my patch for the
> wineserver
> means that the wineserver doesn't want to send signals for 'norma
At 08:08 03/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <[EMAIL PROTECTED]> writes:
>
>> Solaris isn't an issue here - valgrind only works on linux/x86.
>
>Of course Solaris is an issue, unless you somehow make your patch take
>effect only when running under valgrind.
currently the patched
Adam Gundy <[EMAIL PROTECTED]> writes:
> Solaris isn't an issue here - valgrind only works on linux/x86.
Of course Solaris is an issue, unless you somehow make your patch take
effect only when running under valgrind.
> >Well, sending a signal to a thread from another process is standard
> >Linux
Thanks, downloaded it.
I will wait to recompile it since I removed the file to have a fresh
copy and cvs.sf.net seems to be down atm (some maintenance perhaps ?)
> a (small) part of the valgrind patch has been committed to CVS - I
> have just updated
> the patch on sourceforge to remove this bit. N
At 16:53 03/04/03 +0200, Sylvain Petreolle wrote:
>With your new patch applied to a cvs version of valgrind,
>valgrind fails to compile. I get :
>
>make[1]: Entre dans le répertoire `/home/valgrind/coregrind'
>source='vg_to_ucode.c' object='vg_to_ucode.o' libtool=no \
>depfile='.deps/vg_to_ucode.Po
At 14:50 02/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <[EMAIL PROTECTED]> writes:
>
>> * dlls/Makefile.in: Rebuild the msvcrt directory twice, once for
>> msvcrt.dll.so and once for the debug msvcrtd.dll.so.
>
>You can't do that, the Makefile.in is generated automatically
OK, more questions :)
> Clearly c) because that will work properly even when doing
> hotplugging of pcmcia cards and doing interactive dialup
> to an isp. Might want to cache it for 10 seconds or something,
> and you might need to worry about what happens when programs
> are reading the reg entri
At 16:47 03/04/03 +0200, Sylvain Petreolle wrote:
>You included the following suppression within wine.supp into your
>valgrind patch,
>did you do debug or must a bug be open on bugzuilla ?
>
># The CTLCOLOR message handler doesn't fill in pResult - BUG!
>{
> CWnd::ReflectChildNotify/CWnd::OnChil
With your new patch applied to a cvs version of valgrind,
valgrind fails to compile. I get :
make[1]: Entre dans le répertoire `/home/valgrind/coregrind'
source='vg_to_ucode.c' object='vg_to_ucode.o' libtool=no \
depfile='.deps/vg_to_ucode.Po' tmpdepfile='.deps/vg_to_ucode.TPo' \
depmode=gcc3 /bin
You included the following suppression within wine.supp into your
valgrind patch,
did you do debug or must a bug be open on bugzuilla ?
# The CTLCOLOR message handler doesn't fill in pResult - BUG!
{
CWnd::ReflectChildNotify/CWnd::OnChildNotify(Cond)
Memcheck:Cond
fun:CWnd::ReflectChildN
On April 3, 2003 08:45 am, Adam Gundy wrote:
> another couple of days trying to build one of our libraries (of about 40)
> convinced me that it wasn't going to be worth the effort.
Unfortunately, winegcc is missing suppport for -shared, so it's not yet
useful for building DLLs. I hope to fix that
At 06:57 03/04/03 -0500, Dimitrie O. Paun wrote:
>On April 3, 2003 05:45 am, Adam Gundy wrote:
>> I've never got very far with winelib - as soon as any code involving OLE
>> gets involved, things won't compile. In fact, getting stuff without OLE to
>> compile is frequently painful and slow :-(
>
>I
>From prior discussion it seems like it should use CreateProcess but I was not really
>sure. I was
going to attempt to fix some other unix and wineisms in shelllink.c and shellexec.c
but I need a
good test app or regression test for these functions. I guess I could try and write a
test for
it...
On April 3, 2003 08:32 am, Steven Edwards wrote:
> I can test/use
> comctl32 under Win2k but having a test suite rather the just a few apps
> would be nice. If you dont plan on doing any maybe myself and some of the
> ReactOS developers can write some as we are working on getting shell32 and
> comc
On April 2, 2003 02:39 pm, Steven Edwards wrote:
> shell32 shelllink.c uses fork on line 748 and waitpid on line 789
That one looks like it wants to use CreateProcess(), no?
--
Dimi.
On April 3, 2003 05:45 am, Adam Gundy wrote:
> I've never got very far with winelib - as soon as any code involving OLE
> gets involved, things won't compile. In fact, getting stuff without OLE to
> compile is frequently painful and slow :-(
I suggest you look into winegcc if you want to use winel
On Wed, 2003-04-02 at 20:53, Kevin DeKorte wrote:
> I saw one of those
>
> > XIO: fatal IO error 2 (Success) on X server ":0.0"
> > after 5251 requests (5243 known processed) with 0 events remaining.
>
> Errors this morning on a RedHat 8.0 (glibc 2.3.2). I killed wine and
> wineserver. B
At 20:34 02/04/03 +0200, Eric Pouech wrote:
>>the reason msvcrtd is there is that you need to use it for valgrind to do
>>any checking of the heap - an instrumented malloc (see the changes to ntdll/heap.c)
>>is required to tell valgrind that freshly allocated blocks are uninitialized,
>>and the fre
At 09:27 02/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <[EMAIL PROTECTED]> writes:
>
>> which part of the signal stuff won't work? all that has happened is that the
>> "kill( , SIGUSR1 )" has moved from the wineserver to the client (for 'local'
>> threads). I thought that the NPTL stuff sti
oops... didnt see your name :)
--- Vitaliy Margolen <[EMAIL PROTECTED]> a écrit :
> Thanks for the replay, but I'm already between steps 6.1.11 - debug
> it and
> 6.1.12 - Fix it. ;-)
>
> Thursday, April 3, 2003, 12:00:00 AM, you wrote:
>
> > Please use the wine-users list and read
> > http://w
42 matches
Mail list logo
