Austin English austinenglish@gmail.com writes:
This dll is not a core part of windows (at least, not yet), but I think it should be considered for inclusion in Wine. A bit of explanation is necessary:
xlive.dll comes from Games for Windows (1,2), whose installer depends on .Net 3.5 (can be skipped with the /nodotnet parameter). Native fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). As it currently stands, users can't play any 'Game for Windows' that doesn't have a Windows license.
That's not a good enough reason, particularly considering how ugly the resulting code is. And it seems unlikely that this is ever going to move beyond the nasty hack stage, given the lack of documentation.
On Tue, Nov 2, 2010 at 12:34 PM, Alexandre Julliard julliard@winehq.org wrote:
Austin English austinenglish@gmail.com writes:
This dll is not a core part of windows (at least, not yet), but I think it should be considered for inclusion in Wine. A bit of explanation is necessary:
xlive.dll comes from Games for Windows (1,2), whose installer depends on .Net 3.5 (can be skipped with the /nodotnet parameter). Native fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). As it currently stands, users can't play any 'Game for Windows' that doesn't have a Windows license.
That's not a good enough reason, particularly considering how ugly the resulting code is. And it seems unlikely that this is ever going to move beyond the nasty hack stage, given the lack of documentation.
Fair enough. You never know until you try and have the code in hand.
For those interested, I've put an initial fork at http://github.com/austin987/wine/ . If you've got any games that need xlive, please test against it and report any bugs to me directly or at http://bugs.winehq.org/show_bug.cgi?id=23532. I plan to expand the tests next, to try and get some documentation, so that it can possibly be implemented in the future in a clean way (by someone else, if need be).
Am 02.11.2010 20:46, schrieb Austin English:
On Tue, Nov 2, 2010 at 12:34 PM, Alexandre Julliard julliard@winehq.org wrote:
Austin English austinenglish@gmail.com writes:
This dll is not a core part of windows (at least, not yet), but I think it should be considered for inclusion in Wine. A bit of explanation is necessary:
xlive.dll comes from Games for Windows (1,2), whose installer depends on .Net 3.5 (can be skipped with the /nodotnet parameter). Native fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). As it currently stands, users can't play any 'Game for Windows' that doesn't have a Windows license.
That's not a good enough reason, particularly considering how ugly the resulting code is. And it seems unlikely that this is ever going to move beyond the nasty hack stage, given the lack of documentation.
Fair enough. You never know until you try and have the code in hand.
For those interested, I've put an initial fork at http://github.com/austin987/wine/ . If you've got any games that need xlive, please test against it and report any bugs to me directly or at http://bugs.winehq.org/show_bug.cgi?id=23532. I plan to expand the tests next, to try and get some documentation, so that it can possibly be implemented in the future in a clean way (by someone else, if need be).
@All: There are already some Projects which reimplement non-windows dlls like e.g. cuda. I totally see the reason to not integrate them into Wine, but maybe we could start a small Project hosting all that stuff at _one_ point and not spread over the www. Maybe my upcoming CE dlls will also fall into that catagory... Then we also could pack the .dll.so's up into one nsis installer, where you can select which subproject you want to install. (Maybe 32-bit and 64-bit? And possibly in some other way also for ARM?) Your opinions?
On 11/02/2010 01:34 PM, André Hentschel wrote:
Am 02.11.2010 20:46, schrieb Austin English:
On Tue, Nov 2, 2010 at 12:34 PM, Alexandre Julliard julliard@winehq.org wrote:
Austin English austinenglish@gmail.com writes:
This dll is not a core part of windows (at least, not yet), but I think it should be considered for inclusion in Wine. A bit of explanation is necessary:
xlive.dll comes from Games for Windows (1,2), whose installer depends on .Net 3.5 (can be skipped with the /nodotnet parameter). Native fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). As it currently stands, users can't play any 'Game for Windows' that doesn't have a Windows license.
That's not a good enough reason, particularly considering how ugly the resulting code is. And it seems unlikely that this is ever going to move beyond the nasty hack stage, given the lack of documentation.
Fair enough. You never know until you try and have the code in hand.
For those interested, I've put an initial fork at http://github.com/austin987/wine/ . If you've got any games that need xlive, please test against it and report any bugs to me directly or at http://bugs.winehq.org/show_bug.cgi?id=23532. I plan to expand the tests next, to try and get some documentation, so that it can possibly be implemented in the future in a clean way (by someone else, if need be).
@All: There are already some Projects which reimplement non-windows dlls like e.g. cuda. I totally see the reason to not integrate them into Wine, but maybe we could start a small Project hosting all that stuff at _one_ point and not spread over the www. Maybe my upcoming CE dlls will also fall into that catagory... Then we also could pack the .dll.so's up into one nsis installer, where you can select which subproject you want to install. (Maybe 32-bit and 64-bit? And possibly in some other way also for ARM?) Your opinions?
From a usability perspective we're not going to be doing much good
unless this happens near-automatically with a typical Wine installation. That means either including them in Wine directly or including hooks to download them when needed (this could also be done in the packaging layer)
-Scott Ritchie
Am 03.11.2010 um 06:00 schrieb Scott Ritchie:
From a usability perspective we're not going to be doing much good unless this happens near-automatically with a typical Wine installation. That means either including them in Wine directly or including hooks to download them when needed (this could also be done in the packaging layer)
Another thing I wondered about: Can those DLLs be compiled outside the main wine tree? It'd seem nicer to me to have a project with just the DLL as opposed to a clone of the entire wine tree.
As for the server parts of xlive, I guess to get them working with a builtin DLL we'd have to build our own server infrastructure. Even then it would be an entirely different set of users and data than what you get on Windows.
-
Alexandre Julliard -
André Hentschel -
Austin English -
Scott Ritchie -
Stefan Dösinger