On Thu, 25 Apr 2002 21:09:38 +0200 (CEST), you wrote:
Patch: BUGS in my recently submitted patch series
This applies over my complete patch series -
I will send clean patches tomorrow.
The fixes in server/file.c and server/serial.c relate to Rein Klazes'
problem. Rein: please tell me
Hallo,
is there anybody beside me willing to care for a booth at Linuxtag June 6-9
in Karlsruhe? Please give feedback so I can apply for a booth.
Beside our normal program winex and crossover might be good objects to
demonstrate.
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut
Alexandre,
-static int FILE_GetUnixHandleType( HANDLE handle, DWORD access, enum
fd_type *type, int *flags )
+static int FILE_GetUnixHandleType( HANDLE handle, DWORD access, enum
fd_type *type, int *flags_ptr )
{
-int ret, fd = -1;
+int ret, flags, fd = -1;
-ret =
--- Eric Pouech [EMAIL PROTECTED] wrote:
And I think, that for the last type of programs a
cooperation between the
Wine-Devels and the Mono-Devels is very
advantageous. So, existing this
cooperations?
not to my knowledge.
moreover, it has to be seen the exact difference
between MS
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Alexandre, could you look at bug 572:
http://bugs.codeweavers.com/show_bug.cgi?id=572
It is possible that this bug is caused by your
patch.
Quite possible, but I'm afraid the trace is not
Helle friends
Still fighting with my serial printers.. :)
I upgrade my wine sources today with CVS and more advantages are in this new code (i'm
very happy) but
with one printer i receive the messages:
trace:file:fd is not overlapped
i comment the lines
//if ( ! (flags
If there is a socket for which event notification has been
requested by the application with WSAEventSelect(),
the behaviour is as follows:
- When data arrives, FD_READ is signalled _ONCE_.
- FD_READ is only delivered again if the app explicitly
reenables it with WSAEventSelect/WSAAsyncSelect
X server crashes???
Now thats the first time I hear about this one. Do you use XFree 4.1.0 (or
4.2.0) with the latest nvidia drivers? I'm using Trillian but with
codeweavers's crosssover plugin and it works damn well, no crashes here...
Hetz
On Friday 26 April 2002 00:50, Michael Cardenas
I just have downloaded the source of wine v. 20020411, I launched ./tools/wineinstall
as a normal user and I was told to enter the root password, the install crashed.
Here is a sample of stdout:
Wine build complete.
---
Performing 'make install' as root to install binaries, enter root password
Hi, my name is Paul.
I have had a similar problem compiling various software, after a long
battle I discovered that I had too little RAM on my machine.
48 mb on a 233PR IBM machine.
I have now increased that memory to 96 mb, the problem has disapeared.
If you could furnish a short list of the
I've been running into some problems with byte swapping in ole related code - it
looks like the relevant stuff is in storage32.c - I've modified
StorageUtl_{Read,Write}Word and DWord to byteswap on bigendian platforms, and
that seems to help, but I'm also running into problems with the wchar
Hi Martin,
Hmmm. MSDN says that FD_READ is only re-enabled on recv, recvfrom,
WSARecv and WSARecvFrom. Maybe you should verify that ReadFile doesn't
re-enable FD_READ on a windows platform or two?
ReadFile in asynchronous mode already reports completion of reads to the
wineserver... why not
On Fri, 26 Apr 2002, Marcelo Welter wrote:
I upgrade my wine sources today with CVS and more advantages are in this new code
(i'm very happy) but
with one printer i receive the messages:
trace:file:fd is not overlapped
Allright, another bug of mine :(
I wasn't aware that FILE_ReadFileEx
Hi Mike,
Hmmm. MSDN says that FD_READ is only re-enabled on recv, recvfrom,
WSARecv and WSARecvFrom. Maybe you should verify that ReadFile doesn't
re-enable FD_READ on a windows platform or two?
You're absolutely right. Unfortunately this will take some time.
The problem is that FD_READ has
XFree86 Version 4.1.0.1 / X Window System
(protocol Version 11, revision 0, vendor release 6510)
Release Date: 21 December 2001
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version
before
I still have problems with FD_CLOSE signalling.
AFAICS FD_CLOSE must be signalled when either of the three
following conditions hold:
1 Network error (Linux signals POLLERR)
2 Graceful close by the peer (Linux signals POLLHUP)
3 shutdown (SD_SEND) by the peer (Linux signals POLLIN with 0 bytes
On Fri, 26 Apr 2002, Yannick Fillatrau wrote:
I just have downloaded the source of wine v. 20020411, I launched
./tools/wineinstall as a normal user and I was told to enter the root password, the
install crashed.
Here is a sample of stdout:
Wine build complete.
---
Performing 'make
Martin Wilck [EMAIL PROTECTED] writes:
-static int FILE_GetUnixHandleType( HANDLE handle, DWORD access, enum
fd_type *type, int *flags )
+static int FILE_GetUnixHandleType( HANDLE handle, DWORD access, enum
fd_type *type, int *flags_ptr )
{
-int ret, fd = -1;
+int ret, flags, fd
Just a small patch to the server sock.c - it tries to implement exactly
the strategies that I described in my previous FD_CLOSE posting.
Seems to work pretty well with my test cases. It makes a difference
to my previous implementation only in rare cases, but I am sure it will be
better at
A patch for the winsock 2 unit test posted yesterday.
It now has an overlapped client. If you look at the code,
it does pretty nasty things to wine, and still works :-)
BUGS: probably doesn't compile under Windows, I'm using some
gcc extensions. You just get too used to them ...
If somebody
On 26 Apr 2002, Alexandre Julliard wrote:
My concern with that approach is that functions using
FILE_GetUnixHandle wouldn't handle the shutdown flags correctly. The
alternative would be to retire FILE_GetUnixHandle, or maybe move the
shutdown flags handling into wine_server_handle_to_fd.
Martin Wilck [EMAIL PROTECTED] writes:
The SO_OPENTYPE socket option used to be represented by a static variable.
This is wrong, it is a per-thread setting (clearly stated in MSDN).
Since this option is now used to determine whether sockets created with the
socket() function should have the
Hello, just noticed that my name in WWN121 was posted
as Speeddymon, I forgot that I had set it to that so
many many years ago... This is my real name and this
is what I will be posting under from now on... :)
__
Do You Yahoo!?
Yahoo! Games - play
from /etc/X11/XF86Config-4:
Section Device
Identifier Device1
Driver vesa
EndSection
WHAT??? why do you use the vesa driver and not nvidia's own driver?
Here's the same section on my Geforce 2 with nvidia binary only drivers
Section Device
# no known
On Fri, 26 Apr 2002, Speeddymon wrote:
If we submit a patch, and it is accepted (and
commited) it would be nice to know if any of my
patches will be in the next snapshot...
If it is committed to CVS, it will be in the next Wine snapshot. This is
automatic and systematic.
The only thing that
Hello, just had an update for WWN 121... Near the
bottom it says that Alexandre rejected a patch for the
Dustin -
I'll make the change and get it into 121. Sorry about
that, I summarized that thread about halfway into it.
-brian.
Speeddymon [EMAIL PROTECTED] writes:
Hello, just had an update for WWN 121... Near the
bottom it says that Alexandre rejected a patch for the
ldconfig problem (the one i submitted) that puts
$libdir/wine into ld.so.conf because users need to set
$WINEDLLPATH... the corrections are this:
Hi!
I have run into a warning, when compiling with gcc 3.1 (I dont know if it is
reported or not with 2.x gccs).
And I think the warning is right.
I dont think that the initializer of nil is right. It initializes an zero (0)
character length WCHAR array to a one character lenght array.
Or I
28 matches
Mail list logo
