Another fortnight, another winetricks.
Main changes are Solaris portability improvements,
more verbs support silent install,
and three new verbs:
directplay will be handy for those couple dozen networked games that
use that API.
dotnet30 probably isn't ready for prime time, but it's
Kai Blin wrote:
Sorry about that - looks like I hadn't in fact updated my git tree quite
properly. Also, I left out a header file I think. Try this patch instead.
There's no copyright statement or license indicated on the new header file. I
assume that's going to be LGPL v2
On Wednesday 28 November 2007 00:09:26 Gavriel State wrote:
> Hi Kai,
>
> Sorry about that - looks like I hadn't in fact updated my git tree quite
> properly. Also, I left out a header file I think. Try this patch instead.
There's no copyright statement or license indicated on the new header file
On Wednesday 21 November 2007 05:42:18 Gavriel State wrote:
> Enclosed here is a patch to today's WineHQ git tree with our dpnet
> implementation in the hopes that someone finds it useful. Beyond
> ensuring that it compiles and links, it has not been tested at all with
> WineHQ.
That's funny, it
On Wednesday 21 November 2007 05:42:18 Gavriel State wrote:
Hi Gav,
> On #winehackers the other day, kblin asked about whether TransGaming had
> a Direct Play implementation. The answer is that we have something that
> was worked on for a while but never completed. We have had some partial
> su
On Wednesday 07 March 2007 10:52, Alessandro Pignotti wrote:
> + /* I think we have to add a player to the total number of players only if
> it's not a player created for system
> + purpose like the name server. This way it seems we get a correct
> player number */
> + if( ~dwFlags & DPL
On Tuesday 06 March 2007 23:25, Alessandro Pignotti wrote:
> Hi everyone,
> this patch fixes the behaviour of dplayx that was not adding new player to
> its counter.
I don't see a patch. Did you attach it?
Kai
--
Kai Blin,
WorldForge developerhttp://www.worldforge.org/
Wine developer
--- Frank Richter <[EMAIL PROTECTED]> wrote:
> On 03.03.2007 13:56, Joris Huizer wrote:
> >
> > if( i == 0 )
> > - memcpy( &lpSpData->dwReserved1,
> returnBuffer,
> > sizeof(lpSpData->dwReserved1) );
> > + sscanf(returnBuffer, "%x",
> &lpSpData->dwReserved1);
> >
> >
> >
> > C
On 03.03.2007 13:56, Joris Huizer wrote:
>
> if( i == 0 )
> - memcpy( &lpSpData->dwReserved1, returnBuffer,
> sizeof(lpSpData->dwReserved1) );
> + sscanf(returnBuffer, "%x", &lpSpData->dwReserved1);
>
>
>
> Couldnt you use:
> strcpy(lpSpData->dwReserved1,returnBuffer);
Reading
if( i == 0 )
- memcpy( &lpSpData->dwReserved1, returnBuffer,
sizeof(lpSpData->dwReserved1) );
+ sscanf(returnBuffer, "%x", &lpSpData->dwReserved1);
Couldnt you use:
strcpy(lpSpData->dwReserved1,returnBuffer);
Sorry for only replying now; Your solution is equivalent, e
On Friday 02 March 2007 22:54, Alessandro Pignotti wrote:
> Hi,
> This is the first of several patches that will make builtin dplayx
> compatible with native dpwsockx, so we can kill the native override of
> dplayx
This patch adds two compile-time warnings about implicitly declaring sscanf.
Please
On Di, 2007-02-27 at 13:15 +0100, Alessandro Pignotti wrote:
> +dlls/dplayx/tests/Makefile
That is will not work since today, as the format changed.
The correct entry is created by "tools/make_makefiles"
I updated the wiki, that
autogenerated code should not be included in a Patch
--
By b
On 27/02/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> +BOOL FAR PASCAL EnumConnectionsCallback(LPCGUID lpguidSP, LPVOID
lpConnection,
> + DWORD dwConnectionSize, LPCDPNAME lpName, DWORD dwFlags,
> + LPVOID lpContext)
> +{
This doesn't look like a proper type of callb ack for
IDirectPlayX_
"Alessandro Pignotti" <[EMAIL PROTECTED]> wrote:
+BOOL FAR PASCAL EnumConnectionsCallback(LPCGUID lpguidSP, LPVOID lpConnection,
+ DWORD dwConnectionSize, LPCDPNAME lpName, DWORD dwFlags,
+ LPVOID lpContext)
+{
This doesn't look like a proper type of callb ack for
IDirectPlayX_EnumConnectio
On Saturday 24 February 2007 22:10, Alessandro Pignotti wrote:
> Thanks for the suggestions, this version of the patch uses IsEqualGUID and
> eliminates C++ style comments and insert a proper copyright notice in the
> added file
You might want to use #include "wine/test.h" instead of #include
, a
On 24/02/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Use
todo_wine ok(memcmp(&sessionDesc.guidInstance,&zeroGuid,16),"Session guid not
initialized");
Afaik the proper way is to use IsEqualGUID() rather than memcmp().
Alessandro Pignotti wrote:
On Saturday 24 February 2007 19:31, Stefan Dösinger wrote:
todo_wine ok(memcmp(&sessionDesc.guidInstance,&zeroGuid,16),"Session guid
not initialized");
For tests which are known to fail
This version of the patch follows Stefan's advice.
-
Am Samstag 24 Februar 2007 17:25 schrieb Alessandro Pignotti:
> Hi everyone,
> the directx sdk says that directplay has to initialize sesison guid in
> SESSIONDESC2 struct that is passed by the application with the Open call.
> This patch adresses that issue and includes proper conf
On Saturday 10 February 2007 19:39, Alessandro Pignotti wrote:
> I'm working to implement a service provider compatible with the protocol
> used by directplay over TCP/IP.
> Currently i've implemented the lobby code and tested it against
> simpleconnect.exe and chatconnect.
On Monday 29 January 2007 14:26, Kai Blin wrote:
> On Sunday 28 January 2007 20:38, Tomas Carnecky wrote:
> > > From Microsoft DirectX SDK Documentation it seems that directplay
> > > should initialize the instance guid on session creation, this trivial
> > > patch do
On Sunday 28 January 2007 20:38, Tomas Carnecky wrote:
> > From Microsoft DirectX SDK Documentation it seems that directplay should
> > initialize the instance guid on session creation, this trivial patch does
> > that.
>
> Two questions:
>
> 1. Does windows do this,
Alessandro Pignotti wrote:
> Hi,
> this is my first patch i hope it's well formatted
formating is good.
> From Microsoft DirectX SDK Documentation it seems that directplay should
> initialize the instance guid on session creation, this trivial patch does
> that.
Two
Am Dienstag 23 Januar 2007 14:08 schrieb Alessandro Pignotti:
> Hi everyone,
> i'm taking a look at wine's directplay implementation. From the the wiki
> i've seen that there are efforts to understand the directplay protocol. But
> it seems to be be quite a difficult
On 1/23/07, Alessandro Pignotti <[EMAIL PROTECTED]> wrote:
Hi everyone,
i'm taking a look at wine's directplay implementation. From the the wiki i've
seen that there are efforts to understand the directplay protocol. But it
seems to be be quite a difficult task. Would no
Hi everyone,
i'm taking a look at wine's directplay implementation. From the the wiki i've
seen that there are efforts to understand the directplay protocol. But it
seems to be be quite a difficult task. Would not be a better idea to
implement a wine directplay service provid
kets.
> > Start a game that uses DirectPlay for networking and start a network
> > game.
> >
> > Start the game on another box and connect to the game. Now, in the game
> > lobby, use the chat to say something from both games. Then, change a
> > setting or two and st
On Sunday 26 November 2006 22:39, Kai Blin wrote:
> Here's what I would like you to do (if you want to help out):
>
> Fire up a network sniffer that dumps to libpcap format. Grab TCP and UDP
> packets.
> Start a game that uses DirectPlay for networking and start a network game
On Monday 27 November 2006 08:39, Kai Blin wrote:
> On a side note, broadcasting for servers seems to fail (i.e. never
> produces a packet). This seems to be a winsock problem, too.
I don't have a Windows box with multiple NICs set up anywhere, but it seems
like either our winsock implementation
On Monday 27 November 2006 00:08, Alexander Nicolaysen Sørnes wrote:
>
> Most DirectPlay games (using Wine and native dlls) hang instead of
> terminating the connection properly (bug 5534); does this matter when
> making the log?
So far I've been testing this usig native, but
On 11/27/06, Alexander Nicolaysen Sørnes <[EMAIL PROTECTED]> wrote:
Most DirectPlay games (using Wine and native dlls) hang instead of terminating
the connection properly (bug 5534); does this matter when making the log?
I think Kai intended for people to make the packet log from a W
Søndag 26 november 2006 22:39, skrev Kai Blin:
> Hi folks,
>
> As you might know, I'm currently toying with figuring out the MS DirectPlay
> protocol. I've been making some progress with my wireshark dissector over
> the weekend, and would be interested in some add
Hi folks,
As you might know, I'm currently toying with figuring out the MS DirectPlay
protocol. I've been making some progress with my wireshark dissector over the
weekend, and would be interested in some additional games to get more
different data on some of this stuff.
Here'
Adam Luchjenbroers skrev:
What Windows version would you be interested in?
At this point, I should probably mention that while I have a great interest in
seeing DirectPlay working, I have relatively little time to work on it. I'm
doing my investigations here and there, and if n
>
> What Windows version would you be interested in?
At this point, I should probably mention that while I have a great interest in
seeing DirectPlay working, I have relatively little time to work on it. I'm
doing my investigations here and there, and if no-one picks up on this I&#
Adam Luchjenbroers skrev:
On Mon, 24 Apr 2006 11:47, Francois Gouget wrote:
On Fri, 21 Apr 2006, Adam Luchjenbroers wrote:
[...]
With the way DirectPlay works, we could provide our own provider and a
compatible provider if we so wanted (at least, to the extent of my
knowledge
On Mon, 24 Apr 2006 11:47, Francois Gouget wrote:
> On Fri, 21 Apr 2006, Adam Luchjenbroers wrote:
> [...]
>
> > With the way DirectPlay works, we could provide our own provider and a
> > compatible provider if we so wanted (at least, to the extent of my
> > knowledge
On Fri, 21 Apr 2006, Adam Luchjenbroers wrote:
[...]
With the way DirectPlay works, we could provide our own provider and a
compatible provider if we so wanted (at least, to the extent of my
knowledge).
IMHO we should saves ourselves some work and only do the compatible
provider since it will
On Thu, 20 Apr 2006 13:46, Francois Gouget wrote:
> It seems like this would prevent you from connecting to games hosted by
> commercial companies (e.g. Microsoft) as these are unlikely to install
> the Wine DirectPlay library.
>
> Or is DirectPlay never used in this way? Even so I
On Mon, 17 Apr 2006, Stefan Dösinger wrote:
[...]
Always wanted to see that implemented, but there's the issue of the
DirectPlay protocol itself, which AFAIK is undocumented.
For the start, we don't have to be compatible with the Microsoft protocol. If
we can get a Wine-Wine prot
On Mon, 17 Apr 2006 06:56, H. Verbeet wrote:
> > Or do we have a solution for that?
>
> Ethereal? :-)
True. but how does that sit with respect to reverse engineering? Any potential
legal issues?
--
"Liberty means responsibility. That is why most men dread it." - George
Bernard Shaw
Am Montag, 17. April 2006 16:18 schrieb Adam Luchjenbroers:
> On Sat, 15 Apr 2006 20:03, Alexander N. Sørnes wrote:
> > This is a proposal for a Google Summer of Code Project.
> >
> > Improve Wine's DirectPlay implementation so that it can at least run a
> > sim
On 17/04/06, Adam Luchjenbroers <[EMAIL PROTECTED]> wrote:
> Or do we have a solution for that?
Ethereal? :-)
On Sat, 15 Apr 2006 20:03, Alexander N. Sørnes wrote:
> This is a proposal for a Google Summer of Code Project.
>
> Improve Wine's DirectPlay implementation so that it can at least run a
> simple demo app, and ideally end up enabling network play for a free
> game demo.
>
Alex wrote:
> This is a proposal for a Google Summer of Code Project.
>
> Improve Wine's DirectPlay implementation so that it can at least run a
> simple demo app, and ideally end up enabling network play for a free
> game demo.
> A list of such demos is available here
&
On 4/15/06, "Alexander N. Sørnes" <[EMAIL PROTECTED]> wrote:
> This is a proposal for a Google Summer of Code Project.
>
> Improve Wine's DirectPlay implementation so that it can at least run a
> simple demo app, and ideally end up enabling network play for a f
This is a proposal for a Google Summer of Code Project.
Improve Wine's DirectPlay implementation so that it can at least run a
simple demo app, and ideally end up enabling network play for a free
game demo.
A list of such demos is available here
http://wiki.winehq.org/DirectPlay
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
On Friday 23 April 2004 13:21, Mike Hearn wrote:
> On Thu, 22 Apr 2004 17:49:43 -0500, Ryan Underwood wrote:
> > I have seen some mentions of work on DirectPlay. Who is currently
> > working on this, and what are the imple
On Thu, 22 Apr 2004 17:49:43 -0500, Ryan Underwood wrote:
> I have seen some mentions of work on DirectPlay. Who is currently
> working on this, and what are the implementation plans?
AFAIK nobody. I haven't seen any DirectPlay patches for ages. Not many
games use it.
> I am mai
I have seen some mentions of work on DirectPlay. Who is currently
working on this, and what are the implementation plans?
I am mainly curious if it is planned to be network compatible with
the same programs running on Windows. There could be some drawback to
this, because the old versions of
49 matches
Mail list logo
