Hi Kai,
> I'm just looking into implementing Kerberos and Negotiate for SSPI. It
> seems like I'll need an ASN.1 parser for both of those. I know you have
> a partial implementation of an ASN.1 DER parser in crypt32, but I think
> it would be kind of silly to keep two seperate copies. Think it wou
Hi Juan,
I'm just looking into implementing Kerberos and Negotiate for SSPI. It seems
like I'll need an ASN.1 parser for both of those. I know you have a partial
implementation of an ASN.1 DER parser in crypt32, but I think it would be
kind of silly to keep two seperate copies. Think it would m
Hello!
On Fri, 2006-11-17 at 10:20 +0100, Hans Leidekker wrote:
> On Friday 17 November 2006 09:01, Pavel Roskin wrote:
>
> > trace:file:CreateFileW L".\\Cdrom0" GENERIC_READ GENERIC_WRITE
> > FILE_SHARE_READ FILE_SHARE_WR
>
> On NT based systems drive letters are aliases for device names
>
On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
No, you're adding code all over the place that looks up this setting -
this will have to be changed later. It's the exact same thing I did with
shader mode, so just trying to shortcut to the end result...
My plan is to remove the checks for
> There's nothing wrong with bringing this up on wine-devel. Adam has
> taken the time to track down the possible bug culprit, and he's
> sharing it with the developers. If, on the other hand, he had just
> said, "app xyz doesn't work, don't know why" the the response would be
> correct. Not e
That's still missing runtime check for GL_ARB_DEPTH_TEXTURE extension. I
don't like "developers only" and "registry key" - feature should be
complete or not in the tree.
> The trouble with the current setup is that we can't use different
formats based on what extensions
are present.
Then the
H. Verbeet wrote:
On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
H. Verbeet wrote:
> On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
>> This flag needs to be per adapter - should be added to device.c
like the
>> shader mode.
>>
> Well, the registry setting is global. I'm not sure
On 11/17/06, Aaron Slunt <[EMAIL PROTECTED]> wrote:
Adam Connell wrote:
> Greetings,
>
> While investigating why a game (Kasparov's Chessmate) didn't work,
> I think I found a bug in the implementation of imagehlp.dll in the
> the MapAndLoad function located in dlls/imagehlp/access.c lines
> 165-
On Fr, 2006-11-17 at 17:31 +0100, Stefan Dösinger wrote:
> Just stumbled uppon some interesting thing about openal and DirectSound 3D on
> vista: http://www.openal.org/openal_vista.html
>
> It sounds like openal will be the old way to get hw accelerated 3d sound on
> vista, and creative is writ
Aaron Slunt wrote:
Adam Connell wrote:
Greetings,
While investigating why a game (Kasparov's Chessmate) didn't work,
I think I found a bug in the implementation of imagehlp.dll in the
the MapAndLoad function located in dlls/imagehlp/access.c lines
165-167. The function looks like it tries to op
Adam Connell wrote:
Greetings,
While investigating why a game (Kasparov's Chessmate) didn't work,
I think I found a bug in the implementation of imagehlp.dll in the
the MapAndLoad function located in dlls/imagehlp/access.c lines
165-167. The function looks like it tries to open an uninitialized
Greetings,
While investigating why a game (Kasparov's Chessmate) didn't work,
I think I found a bug in the implementation of imagehlp.dll in the
the MapAndLoad function located in dlls/imagehlp/access.c lines
165-167. The function looks like it tries to open an uninitialized
string szFileName inst
After doing the suggested tactis it still failed but with fewer errors:
Here is the output
"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"English_United States.1252"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"C"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"English_United States.1252"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"
Hello,
On 16/11/06, Renu Rajput <[EMAIL PROTECTED]> wrote:
I am facing a performance issue in CRichEditCtrl under Wine. My
application reads data from a *.dat file and displays it in the
CRichEdit editor. When I try to open large data files, it takes a lot
of time(around 4-5 minutes) to open the
Hello,
When rastering on display (winex11) some pen options set in GDI(PS_JOIN_xxx,
PS_ENDCAP_xxx) are taken into account, but they are ignored in wineps when
generating a postscript for printing as it seems.
Is there any workaround or i'm wrong and these styles are supported ? Thanks a
lot
Hi,
Just stumbled uppon some interesting thing about openal and DirectSound 3D on
vista: http://www.openal.org/openal_vista.html
It sounds like openal will be the old way to get hw accelerated 3d sound on
vista, and creative is writing a dsound -> openal wrapper. Maybe it gets a
proper license
On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
H. Verbeet wrote:
> On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
>> This flag needs to be per adapter - should be added to device.c like the
>> shader mode.
>>
> Well, the registry setting is global. I'm not sure if it really makes
>
On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
Ivan Gyurdiev wrote:
> This flag needs to be per adapter - should be added to device.c like
> the shader mode.
I meant the device structure.
Yeah, I got that.
Also, the mode selection should include configuration and support
detection - I t
H. Verbeet wrote:
On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
This flag needs to be per adapter - should be added to device.c like the
shader mode.
Well, the registry setting is global. I'm not sure if it really makes
sense to use different offscreen rendering modes for different
dev
On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
Was GL_ARB_DEPTH_TEXTURE detection added to wine recently?
I don't have the latest copy. If not, needs to be added to take
advantage of the formats you're adding.
No, but it's a pretty old extension. The trouble with the current
setup is that
Ivan Gyurdiev wrote:
This flag needs to be per adapter - should be added to device.c like
the shader mode.
I meant the device structure.
Also, the mode selection should include configuration and support
detection - I think you're missing the support detection. Imho there
should be a select_of
On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
This flag needs to be per adapter - should be added to device.c like the
shader mode.
Well, the registry setting is global. I'm not sure if it really makes
sense to use different offscreen rendering modes for different
devices.
H. Verbeet wrote:
Two things to note here:
- We use GL_DEPTH_COMPONENT24_ARB as internal format for 16-bit
depth textures. This is needed because GL_DEPTH_COMPONENT16_ARB
doesn't work with FBOs.
- We don't properly support combined depth and stencil buffer
formats yet. To support this properly
This flag needs to be per adapter - should be added to device.c like the
shader mode.
On Friday 17 November 2006 09:01, Pavel Roskin wrote:
> trace:file:CreateFileW L".\\Cdrom0" GENERIC_READ GENERIC_WRITE
> FILE_SHARE_READ FILE_SHARE_WR
On NT based systems drive letters are aliases for device names
in what is called the NT object manager namespace. It looks like
DVDDecrypter
Marcus Meissner schrieb:
> On Wed, Nov 15, 2006 at 06:09:40PM +, L. Rahyen wrote:
>>> So for fixing some _broken_ applications this patch unconditionally
>>> disables nx protection for every application running under wine. Seems like
>>> a bad tradeoff imo. (Though I don't know how widespread t
On Friday 17 November 2006 09:14, Hans Leidekker wrote:
> This is from a box running Windows Server 2003 Enterprise Edition,
> Service Pack 1:
Thanks.
Kai
--
Kai Blin,
WorldForge developerhttp://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin/
--
Will code for
On Friday 17 November 2006 00:21, Kai Blin wrote:
> for Samba, as my Win2k box always sets that bit. The Samba team wants me to
> check if this also happens in Win2k3, too. I don't have that version of
> Windows flying around, but maybe someone in here has and would like to run
> the attached e
Hello!
I've tried to figure out why some programs working with CD and DVD
drives work only if the emulated version is set to Windows NT 4, but not
Windows 2000 or XP.
I used DVDDecrypter 3.5.4.0 with the current Wine from git.
DVDDecrypter is configured to use SPTI, which is the default. Fixing
Hello,
On 16/11/06, Renu Rajput <[EMAIL PROTECTED]> wrote:
I am facing a performance issue in CRichEditCtrl under Wine. My
application reads data from a *.dat file and displays it in the
CRichEdit editor. When I try to open large data files, it takes a lot
of time(around 4-5 minutes) to open the
30 matches
Mail list logo
