Hi guys, in the last two releases of wine (september's and october's)
System Shock 2 gets an Unhandled exception on quit, and doesn't save any
of it's settings/keybindings. It worked in june and july's, the
backtrace is attached... if there's anything else I can do to help
anyone who would like to
Peter Hartshorn <[EMAIL PROTECTED]> writes:
> Is there a mechanism for one wine process (thread?) to send a
> message to another process (thread?) and receive a response, ie
> a pointer?
No, there is no way to do that at the moment, and it's fairly tricky
to do correctly. This is why VirtualAlloc
Having disabled the curses support,
I see that the library is located by configure for future loading.
Shouldnt these test be conditional ?
dnl Get the soname for libraries that we load dynamically
>Uhh, I've seen several other windows programs that did not rely on the
>NULL feature, perhaps because it is documented poorly. These programs do
>gethostname() and then gethostbyname(). We will probably need a check in
>the gethostbyname path to catch those programs as well.
Correct, NULL and ge
On Fri, 31 Oct 2003 09:50:48 -0800, you wrote:
>
> hi Rein,
>
> >On my system everything works as expected: I get a list of all ip
> >addresses. That is with valid /etc/hostname and /etc/hosts entries.
>
> That's the trouble. Not every *nux box has the correct results - some do
> (like yours) -
hi Rein,
>On my system everything works as expected: I get a list of all ip
>addresses. That is with valid /etc/hostname and /etc/hosts entries.
That's the trouble. Not every *nux box has the correct results - some do
(like yours) - in fact I'd say many do not. We have done many Linux and
Lindow
Hi Rein,
>When I implemented the case that name == NULL ( another call for help, I
>wasn't aware of your bug report, sorry), the only reference I could find
>was this:
>
>| If null is provided in the name parameter, the returned string is the
same
>| as the string returned by a successful gethost
On Thu, 30 Oct 2003 10:59:40 -0800, you wrote:
>
> Hi Mike,
>
> bug 1541 is still *not* fixed correctly. See when passing in NULL in windows
> to gethostbyname, it is guarenteed to return a list of local IP addresses
> mapped on the box. However, with WINE, passing NULL causes gethostname to be
Mike Hearn wrote:
On Fri, 2003-10-31 at 00:51, Dan Kegel wrote:
getifaddrs() is indeed the right beast, though who knows, maybe you'll
have to filter out 127.0.0.1. Hitch is, Linux doesn't provide it.
I think it does as of the latest glibc, at least it's marked as "done"
on their TODO list.
Hey
On October 31, 2003 02:41 am, Gregory M. Turner wrote:
> BTW, note that transports like http, tcp, etc, could allow wine to do DCOM
> without resolving the "priveleged ports" issue (at least for fixed
> endpoints) of course, our wire protocol is way off and will need fixing
> before that's poss
On October 31, 2003 05:38 am, Adam Gundy wrote:
> that looks unlikely at the moment :-(
Darn. Even if we have to provide a switch (like --wine)
to valgrind? That would be so much better than a different
binary. What's the problem, BTW?
--
Dimi.
On October 31, 2003 05:32 am, Mike Hearn wrote:
> I think it does as of the latest glibc, at least it's marked as "done"
> on their TODO list.
So we can stick Dan's implementation in libs/port, and do a
configure check for it...
--
Dimi.
On Thu, 30 Oct 2003 10:59:40 -0800, you wrote:
>
> Hi Mike,
>
> bug 1541 is still *not* fixed correctly. See when passing in NULL in windows
> to gethostbyname, it is guarenteed to return a list of local IP addresses
> mapped on the box. However, with WINE, passing NULL causes gethostname to be
At 23:26 29/10/2003 -0500, Dimitrie O. Paun wrote:
>On October 29, 2003 08:44 am, Adam Gundy wrote:
>> A new tarball of valgrind modified to work with WINE is available from the
>> valgrind home page:
>>
>> http://developer.kde.org/~sewardj/
>> http://developer.kde.org/~sewardj/valgrind-2003101
On Fri, 2003-10-31 at 00:51, Dan Kegel wrote:
> getifaddrs() is indeed the right beast, though who knows, maybe you'll
> have to filter out 127.0.0.1. Hitch is, Linux doesn't provide it.
I think it does as of the latest glibc, at least it's marked as "done"
on their TODO list.
thanks -mike
Has there been any work on VirtualAllocEx for allocating memory
to other processes?
I would like to get this going to allow me to run mta:vc and blow
away other people in gta vice city (I believe that is a noble
cause).
To get me started I have a question.
Is there a mechanism for one wine proc
> "Orlando" == Orlando Feitosa <[EMAIL PROTECTED]> writes:
Orlando> Hello Friends, I'm trying to use an application that access the
Orlando> serial Port COM1 (which has a printer connected)
Orlando> when application tries to communicate with the port I receive
Orlando> the fol
On Thursday 30 October 2003 04:16 pm, Mike Hearn wrote:
> ncalrpc?
The preferred transport for local-to-self RPC/DCOM communications. In NT it's
implemented on top of "NT Ports" (see Undocumented NT), the advantge being
that this is fast. This RPC transport (but not the NT ports themselves) is
18 matches
Mail list logo
