Re: ASN.1 parser
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 would > make sense to create our own asn dll? Or is there any method to find out > what functions msasn1.dll provides? Well, finding out the functions is easy enough: winedump can do that for you. The trouble is they're undocumented. Some very sparse information is available for at least one function [1] based on describing a vulnerability someone discovered in msasn1.dll. You could use that as a starting point for test cases for msasn1, and you could implement one based on those. I think you could get Kerberos and Negotiate working quicker just by copying code as needed. No non-MS application I'm aware of uses msasn1 directly, so Wine wouldn't gain much from a compatible version. Doing the "right" thing could be sort of a hassle for crypt32 too (not that so many apps use it right now.) The only thing is how much duplicated code offends you. I'm trying to prevent you from diving into a black hole, like I did with crypt32 when what I was really after was SSL ;) [1] http://www.phreedom.org/solar/exploits/msasn1-bitstring/ Sponsored Link Online degrees - find the right program to advance your career. Www.nextag.com
ASN.1 parser
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 make sense to create our own asn dll? Or is there any method to find out what functions msasn1.dll provides? Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpEiNMMS9lgO.pgp Description: PGP signature
Re: CD-ROM access via "\\\\.\\Cdrom0"
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 > in what is called the NT object manager namespace. It looks like > DVDDecrypter knows that. At least it knows that there are devices called CdromN. On the other hand, if the list of the devices can be obtained, it would make sense to only try the devices from that list instead of going from Cdrom0 to Cdrom63. I don't know why letters are used on WinNT. Most likely, the "Cdrom" names don't exist on WinNT. And the reason to use them on Win2k would be to support even the devices without a letter allocated for them. > I remember looking into this when writing tape support. There you also > need to manually create a symlink from .wine/dosdevices/tape0 to /dev/st0 > to make it work. You are totally right. My "proof of concept" patch turns out to be totally useless. It's sufficient to create a link from .wine/dosdevices/cdrom0 to the device (e.g. /dev/cdrom). I'm getting an "Unable to disable media change notification" warning, but it can be ignored. It should be easy to fix. > The issue also comes up with newer installers from MS > that use QueryDosDevice to find a real harddisk among the available > drives; they do so by looking for a specific substring in the object name. > Furthermore, the volume APIs also expose parts of the object namespace; > volume names are in fact symlinks to device names. OK, this confirms that the object namespace is an important feature. Search for "object namespace" shows that the issue is known to wine developers. > So Wine needs to emulate more of the object namespace, possibly by > extending the current concept of storing dos devices as symlinks > in the host filesystem. I.e. we could have a directory under .wine > that represents the root of the object namespace and use subdirectories > and symlinks to mimic the very filesystem like structure of the > object namespace. I actually think that complete Wine configuration should be in the registry. As soon as parts of Wine configuration can be changed using UNIX file operation, we have a problem of consistency. File managers won't check consistency for us. But I realize that this issue is arguable and that some people users to be in control. > We could then extend winecfg to detect Unix device files for cdrom, > floppy, tape etc, and create appropriate symlinks in there. Indeed, that would be the simplest short-term solution. No changes in Wine DLLs are actually needed. > BTW, Sysinternals' WinObj is a handy little tool that visualizes the > object namespace. Yes. And it's completely empty under Wine. By the way, I don't see Cdrom0 on WinXP. Maybe DVDDecrypter is right to scan through all numbers. -- Regards, Pavel Roskin
Re: [3/5] wined3d: Make the offscreen render mode a registry setting
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 both this and the shader code completely, and switch to a more driver like structure, where we simply load the correct backend at initialisation, and call stuff through there.
Re: Bug in MapAndLoad function
> 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 every developer reads wine-bugs, or checks the bugzilla. > Totally agreeing with you here. The mail from Adam Connell has much more to do with wine development then a load of other really off-topic mails that sometimes appear on wine-devel mailinglist.
Re: [2/5] wined3d: Fix depth buffer formats to use actual depth textures
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 setup should be fixed, rather than adding dependent code without extension checks. I might have mentioned before that statically initialized tables are evil Btw, good job, I am glad you're working on this does it make Battlefield 2 work?
Re: [3/5] wined3d: Make the offscreen render mode a registry setting
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 if it really makes > sense to use different offscreen rendering modes for different > devices. Sure it does - different cards have different capabilities [ but like I mentioned in the other mail, I think you're missing the "support" bit of "configuration + support" that should be used to choose offscreen mode ]. I think you're missing the point of the setting. It's something internal for developers. 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...
Re: Bug in MapAndLoad function
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-167. The function looks like it tries to open an uninitialized
> string szFileName instead of the passed file name "pszImageName".
>
> I think there has been a bug filed already (Bug 6099 Alien Shooter
> needs imagehlp.dll override) and I think this explains it.
>
> Wine version 0.9.25
>
> /***
> *MapAndLoad (IMAGEHLP.@)
> */
> BOOL WINAPI MapAndLoad(
> LPSTR pszImageName, LPSTR pszDllPath, PLOADED_IMAGE pLoadedImage,
> BOOL bDotDll, BOOL bReadOnly)
> {
> CHAR szFileName[MAX_PATH];
> HANDLE hFile = NULL;
> HANDLE hFileMapping = NULL;
> HMODULE hModule = NULL;
> PIMAGE_NT_HEADERS pNtHeader = NULL;
>
> TRACE("(%s, %s, %p, %d, %d)\n", pszImageName, pszDllPath,
> pLoadedImage,
> bDotDll, bReadOnly);
>
> /* PathCombine(&szFileName, pszDllPath, pszImageName); */
> /* PathRenameExtension(&szFileName, bDotDll?:"dll":"exe"); */
>
> /* FIXME: Check if the file already loaded (use
> IMAGEHLP_pFirstLoadedImage) */
> if(!(hFile = CreateFileA(
> szFileName, GENERIC_READ, 1, /* FIXME: FILE_SHARE_READ not defined
> */
> NULL, OPEN_EXISTING, 0, NULL)))
> {
> SetLastError(ERROR_FILE_NOT_FOUND);
> goto Error;
> }
>
> Cheers,
> Adam
>
>
>
>
Please file a bug in bugzilla regarding this. wine-devel is not the
place to file bug reports, much more can get done in bugzilla.
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 every developer reads wine-bugs, or checks the bugzilla.
--
James Hawkins
Re: OpenAL and DirectSound
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 writing a dsound -> openal wrapper. Maybe it gets a > proper license so we can include it in wine :-) > > Maybe we should write an openal thunk for wine? Many games use openal, and it > seems that on wine openal uses directsound. That might work more better and > faster if we had a openal.dll which directly called linux openal :-) > > Just dropping the suggestions :-) There was something a while ago... Google-Result for "wineopenal": http://www.winehq.com/pipermail/wine-devel/2006-June/048273.html -- By by ... Detlef
Re: Bug in MapAndLoad function
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 open an uninitialized
string szFileName instead of the passed file name "pszImageName".
I think there has been a bug filed already (Bug 6099 Alien Shooter
needs imagehlp.dll override) and I think this explains it.
Wine version 0.9.25
/***
*MapAndLoad (IMAGEHLP.@)
*/
BOOL WINAPI MapAndLoad(
LPSTR pszImageName, LPSTR pszDllPath, PLOADED_IMAGE pLoadedImage,
BOOL bDotDll, BOOL bReadOnly)
{
CHAR szFileName[MAX_PATH];
HANDLE hFile = NULL;
HANDLE hFileMapping = NULL;
HMODULE hModule = NULL;
PIMAGE_NT_HEADERS pNtHeader = NULL;
TRACE("(%s, %s, %p, %d, %d)\n", pszImageName, pszDllPath,
pLoadedImage,
bDotDll, bReadOnly);
/* PathCombine(&szFileName, pszDllPath, pszImageName); */
/* PathRenameExtension(&szFileName, bDotDll?:"dll":"exe"); */
/* FIXME: Check if the file already loaded (use
IMAGEHLP_pFirstLoadedImage) */
if(!(hFile = CreateFileA(
szFileName, GENERIC_READ, 1, /* FIXME: FILE_SHARE_READ not
defined */
NULL, OPEN_EXISTING, 0, NULL)))
{
SetLastError(ERROR_FILE_NOT_FOUND);
goto Error;
}
Cheers,
Adam
Please file a bug in bugzilla regarding this. wine-devel is not the
place to file bug reports, much more can get done in bugzilla.
http://bugs.winehq.org
Thank you.
And yes I saw a bug was already filed about it, I meant if you think it
might've been a different issue to file a separate report. But if you
think it's the same bug, then the best you can do is post about it in
bugzilla, since wine-devel is not a place to report bugs.
Thank you.
Re: Bug in MapAndLoad function
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
string szFileName instead of the passed file name "pszImageName".
I think there has been a bug filed already (Bug 6099 Alien Shooter
needs imagehlp.dll override) and I think this explains it.
Wine version 0.9.25
/***
* MapAndLoad (IMAGEHLP.@)
*/
BOOL WINAPI MapAndLoad(
LPSTR pszImageName, LPSTR pszDllPath, PLOADED_IMAGE pLoadedImage,
BOOL bDotDll, BOOL bReadOnly)
{
CHAR szFileName[MAX_PATH];
HANDLE hFile = NULL;
HANDLE hFileMapping = NULL;
HMODULE hModule = NULL;
PIMAGE_NT_HEADERS pNtHeader = NULL;
TRACE("(%s, %s, %p, %d, %d)\n", pszImageName, pszDllPath,
pLoadedImage,
bDotDll, bReadOnly);
/* PathCombine(&szFileName, pszDllPath, pszImageName); */
/* PathRenameExtension(&szFileName, bDotDll?:"dll":"exe"); */
/* FIXME: Check if the file already loaded (use
IMAGEHLP_pFirstLoadedImage) */
if(!(hFile = CreateFileA(
szFileName, GENERIC_READ, 1, /* FIXME: FILE_SHARE_READ not defined
*/
NULL, OPEN_EXISTING, 0, NULL)))
{
SetLastError(ERROR_FILE_NOT_FOUND);
goto Error;
}
Cheers,
Adam
Please file a bug in bugzilla regarding this. wine-devel is not the
place to file bug reports, much more can get done in bugzilla.
http://bugs.winehq.org
Thank you.
Bug in MapAndLoad function
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 instead of the passed file name "pszImageName".
I think there has been a bug filed already (Bug 6099 Alien Shooter
needs imagehlp.dll override) and I think this explains it.
Wine version 0.9.25
/***
* MapAndLoad (IMAGEHLP.@)
*/
BOOL WINAPI MapAndLoad(
LPSTR pszImageName, LPSTR pszDllPath, PLOADED_IMAGE pLoadedImage,
BOOL bDotDll, BOOL bReadOnly)
{
CHAR szFileName[MAX_PATH];
HANDLE hFile = NULL;
HANDLE hFileMapping = NULL;
HMODULE hModule = NULL;
PIMAGE_NT_HEADERS pNtHeader = NULL;
TRACE("(%s, %s, %p, %d, %d)\n", pszImageName, pszDllPath,
pLoadedImage,
bDotDll, bReadOnly);
/* PathCombine(&szFileName, pszDllPath, pszImageName); */
/* PathRenameExtension(&szFileName, bDotDll?:"dll":"exe"); */
/* FIXME: Check if the file already loaded (use
IMAGEHLP_pFirstLoadedImage) */
if(!(hFile = CreateFileA(
szFileName, GENERIC_READ, 1, /* FIXME: FILE_SHARE_READ not defined
*/
NULL, OPEN_EXISTING, 0, NULL)))
{
SetLastError(ERROR_FILE_NOT_FOUND);
goto Error;
}
Cheers,
Adam
Re: Debugging solidworks 2006
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"C"
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"C"
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"C"
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"C"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"English_United States.1252"
err:wgl:ConvertPixelFormatWGLtoGLX Can't find a matching FBCONFIG_ID for
VISUAL_ID 0x24!
err:wgl:X11DRV_ChoosePixelFormat Can't find a matching FBCONFIG_ID for
VISUAL_ID 0x24!
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:shdocvw:PersistStreamInit_InitNew (0x335d488)
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
fixme:shdocvw:navigate_url Unsupported arguments
fixme:ole:CoCreateInstance no instance created for interface
{08c0e040-62d1-11d1-9326-0060b067b86e} of class
{4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80004002
fixme:shdocvw:ClOleCommandTarget_QueryStatus (0x335d524)->((null) 1
0x33e520 (nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d524)->((null) 25 2 0x33e534
(nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d524)->((null) 26 2 0x33e534
(nil))
fixme:shdocvw:ClDispatch_Invoke (0x335d524)->(-709
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)->(-5512
{----} 2048 0002 0x33e448 0x33e494 (nil)
0x33e458)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)->(-5501
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)->(-5512
{----} 2048 0002 0x33e448 0x33e494 (nil)
0x33e458)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)->(-5502
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d524)->(-5513
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x3
Re: CRichEditCtrl: Performance issue
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 file. I checked the code and found that, in Wine, the richedit editor streams-in the data in a block of 4096 bytes. On Linux, the read request to the file is routed via Wine. For every block of 4096 bytes that are read, the system makes a back and forth call between the callback function in the application and Wine code(ME_StreamInFill() in dlls\riched20\editor.c), which causes the delay. 4096 bytes is the same that MS uses. In fact, we have other problem, it's the speed of insertion of large text chunks (especially without any formatting) to the editor storage from the RTF/plaintext reader. It should be optimized. And also, MS RichEdit, starting from version 3, displays the first page of large loaded text very quick, and you can work with it and see how vertical scrollbar thumb gets smaller and smaller and smaller while the text is read into editor storage in the background. We should add that, too. The size of the buffer does not really matter here... If anyone stumbled upon the similar issue, what should be the solution to this. Optimize internal text storage (many small mallocs and reallocs ;( ). Optimize text insertion code. Do formatting/layout tasks in the background. -- Ph.
Printing of line joins/ends in Wine
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
OpenAL and DirectSound
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 so we can include it in wine :-) Maybe we should write an openal thunk for wine? Many games use openal, and it seems that on wine openal uses directsound. That might work more better and faster if we had a openal.dll which directly called linux openal :-) Just dropping the suggestions :-) Stefan pgpMSGZjIMaoE.pgp Description: PGP signature
Re: [3/5] wined3d: Make the offscreen render mode a registry setting
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 > sense to use different offscreen rendering modes for different > devices. Sure it does - different cards have different capabilities [ but like I mentioned in the other mail, I think you're missing the "support" bit of "configuration + support" that should be used to choose offscreen mode ]. I think you're missing the point of the setting. It's something internal for developers.
Re: [3/5] wined3d: Make the offscreen render mode a registry setting
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 think you're missing the support detection. Imho there should be a select_offscreen_mode() function like the shader mode is done, selecting between fbo, pbuffer, and none. Well, it's an internal registry setting for developers, I don't think it's needed at this point.
Re: [3/5] wined3d: Make the offscreen render mode a registry setting
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 devices. Sure it does - different cards have different capabilities [ but like I mentioned in the other mail, I think you're missing the "support" bit of "configuration + support" that should be used to choose offscreen mode ].
Re: [2/5] wined3d: Fix depth buffer formats to use actual depth textures
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 we can't use different formats based on what extensions are present. I think GL_EXT_PACKED_DEPTH_STENCIL should be used for stencil/depth.. Yes, it should. However, that extension is a lot newer, and as mentioned above we can't currently return different formats based on what extensions are present.
Re: [3/5] wined3d: Make the offscreen render mode a registry setting
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_offscreen_mode() function like the shader mode is done, selecting between fbo, pbuffer, and none.
Re: [3/5] wined3d: Make the offscreen render mode a registry setting
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.
Re: [2/5] wined3d: Fix depth buffer formats to use actual depth textures
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 we need to be able to detect if the relevant extensions are available or not. 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. I think GL_EXT_PACKED_DEPTH_STENCIL should be used for stencil/depth..
Re: [3/5] wined3d: Make the offscreen render mode a registry setting
This flag needs to be per adapter - should be added to device.c like the shader mode.
Re: CD-ROM access via "\\\\.\\Cdrom0"
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 knows that. I remember looking into this when writing tape support. There you also need to manually create a symlink from .wine/dosdevices/tape0 to /dev/st0 to make it work. The issue also comes up with newer installers from MS that use QueryDosDevice to find a real harddisk among the available drives; they do so by looking for a specific substring in the object name. Furthermore, the volume APIs also expose parts of the object namespace; volume names are in fact symlinks to device names. So Wine needs to emulate more of the object namespace, possibly by extending the current concept of storing dos devices as symlinks in the host filesystem. I.e. we could have a directory under .wine that represents the root of the object namespace and use subdirectories and symlinks to mimic the very filesystem like structure of the object namespace. We could then extend winecfg to detect Unix device files for cdrom, floppy, tape etc, and create appropriate symlinks in there. BTW, Sysinternals' WinObj is a handy little tool that visualizes the object namespace. -Hans
Re: loader: Mark the stack as executable if possible.
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 these kind of >>> broken applications are. But there are definitly applications out there >>> which don't need this.) >> Most of Windows applications will not work. Especialy games. Yes there >> some >> applications that work but this is mostly small applications without complex >> GUI. Some example are Proxomitron (this is a proxy) and mdict (simple 9KB >> program with graphical interface). But most users use Wine for Games and for >> applications with complex GUI (complex GUI = complex application in most >> cases). Just try 10-20 popular games and 10-20 popular applications - most >> of >> them will crash without McCormack's patch or with noexec=on. Even if real >> problem is because of broken PE header this doesn't matter - we must emulate >> typical Windows behavior in such case (at least by default). > > This is incorrect, even with NX most applications will work. Only those with > broken PE headers like above will not. There are still those apps which allocate some memory( read-writeable only), extract/decrypt some code into that memory and then try to run it. These won't work either.
Re: Need some Win2k3 help
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 cotton. pgpZumpbr4xkO.pgp Description: PGP signature
Re: Need some Win2k3 help
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 exe for me and send me the output? This is from a box running Windows Server 2003 Enterprise Edition, Service Pack 1: ntlm.c:311:Running setupClient ntlm.c:608:No ISC flags set, NTLMSSP flags are 0xa2088207 ntlm.c:627:ISC_REQ_CONNECTION flag set, NTLMSSP flags are 0xa2088207 ntlm.c:646:ISC_REQ_EXTENDED_ERROR flag set, NTLMSSP flags are 0xa2088207 ntlm.c:665:ISC_REQ_MUTUAL_AUTH flag set, NTLMSSP flags are 0xa2088207 ntlm.c:684:ISC_REQ_USE_DCE_STYLE flag set, NTLMSSP flags are 0xa2088207 ntlm.c:703:ISC_REQ_DELEGATE flag set, NTLMSSP flags are 0xa2088207 ntlm.c:722:ISC_REQ_INTEGRITY flag set, NTLMSSP flags are 0xe2088297 ntlm.c:741:ISC_REQ_REPLAY_DETECT flag set, NTLMSSP flags are 0xe2088297 ntlm.c:760:ISC_REQ_SEQUENCE_DETECT flag set, NTLMSSP flags are 0xe2088297 ntlm.c:779:ISC_REQ_CONFIDENTIALITY flag set, NTLMSSP flags are 0xe20882b7 ntlm.c:311:Running setupClient ntlm.c:372:Running setupFakeServer ntlm.c:406:Running the client the first time. ntlm.c:534:Running communicate. ntlm.c:504:Running the fake server the first time ntlm.c:534:Running communicate. ntlm.c:865:Looping ntlm.c:406:Running the client the second time. ntlm.c:534:Running communicate. ntlm.c:504:Running the fake server the second time ntlm.c:534:Running communicate. ntlm.c:865:Looping ntlm.c:311:Running setupClient ntlm.c:372:Running setupFakeServer ntlm.c:406:Running the client the first time. ntlm.c:534:Running communicate. ntlm.c:504:Running the fake server the first time ntlm.c:534:Running communicate. ntlm.c:865:Looping ntlm.c:406:Running the client the second time. ntlm.c:534:Running communicate. ntlm.c:504:Running the fake server the second time ntlm.c:534:Running communicate. ntlm.c:865:Looping ntlm.c:311:Running setupClient ntlm.c:342:Running setupServer ntlm.c:406:Running the client the first time. ntlm.c:534:Running communicate. ntlm.c:482:Running the server the first time ntlm.c:534:Running communicate. ntlm.c:865:Looping ntlm.c:406:Running the client the second time. ntlm.c:534:Running communicate. ntlm.c:482:Running the server the second time ntlm.c:534:Running communicate. ntlm.c:865:Looping ntlm.c:311:Running setupClient ntlm.c:342:Running setupServer ntlm.c:406:Running the client the first time. ntlm.c:534:Running communicate. ntlm.c:482:Running the server the first time ntlm.c:534:Running communicate. ntlm.c:865:Looping ntlm.c:406:Running the client the second time. ntlm.c:534:Running communicate. ntlm.c:482:Running the server the second time ntlm.c:534:Running communicate. ntlm.c:865:Looping ntlm.c:311:Running setupClient ntlm.c:372:Running setupFakeServer ntlm.c:406:Running the client the first time. ntlm.c:534:Running communicate. ntlm.c:504:Running the fake server the first time ntlm.c:534:Running communicate. ntlm.c:977:Looping ntlm.c:406:Running the client the second time. ntlm.c:534:Running communicate. ntlm.c:504:Running the fake server the second time ntlm.c:534:Running communicate. ntlm.c:977:Looping ntlm.c:1068:Testing with more than one buffer. ntlm: 124 tests executed, 0 marked as todo, 0 failures.
CD-ROM access via "\\\\.\\Cdrom0"
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
ASPI would be a separate topic.
If NT4 is emulated, the program scans all drives by letters and then
opens drive H: (which is the DVD drive on my system). Here's an excerpt
from the log produced by
WINEDEBUG=+file,+cdrom,+ntdll,+kernel,+aspi wine DVDDecrypter.exe
trace:file:CreateFileW L".\\H:" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ
FILE_SHARE_WRITE
creation 3 attributes 0x0
trace:file:RtlDosPathNameToNtPathName_U (L".\\H:",0x7d6b75b0,(nil),(nil))
trace:file:RtlGetFullPathName_U (L".\\H:" 520 0x7d6b7314 (nil))
trace:ntdll:NtCreateFile handle=0x7d6b75b8 access=c000 name=L"\\??\\H:"
objattr=0040 roo
t=(nil) sec=(nil) io=0x7d6b75a8 alloc_size=(nil)
attr= sharing=0003 disp=1 options=0050 ea=(nil).0x
trace:file:get_dos_device L"H:" -> "/dev/scd0"
trace:file:CreateFileW returning 0x8c
And that's what the same command would produce with win2k emulation:
trace:file:CreateFileW L".\\Cdrom0" GENERIC_READ GENERIC_WRITE
FILE_SHARE_READ FILE_SHARE_WR
ITE creation 3 attributes 0x0
trace:file:RtlDosPathNameToNtPathName_U
(L".\\Cdrom0",0x7d6b25b0,(nil),(nil))
trace:file:RtlGetFullPathName_U (L".\\Cdrom0" 520 0x7d6b2314 (nil))
trace:ntdll:NtCreateFile handle=0x7d6b25b8 access=c000 name=L"\\??\\Cdrom0"
objattr=0040
root=(nil) sec=(nil) io=0x7d6b25a8 alloc_size=(nil)
attr= sharing=0003 disp=1 options=0050 ea=(nil).0x
warn:file:CreateFileW Unable to create file L".\\Cdrom0" (status c034)
trace:file:CreateFileW returning 0x
trace:file:CreateFileW L".\\Cdrom1" GENERIC_READ GENERIC_WRITE
FILE_SHARE_READ FILE_SHARE_WR
ITE creation 3 attributes 0x0
trace:file:RtlDosPathNameToNtPathName_U
(L".\\Cdrom1",0x7d6b25b0,(nil),(nil))
The program cycles like this to Cdrom63 and then gives up.
I think it would be great if Wine adds supported for opening CD-ROMs by
number. Better yet if it enumerated CD-ROMs an other drives
automatically.
I have make a proof-of-concept patch that allows DVDDecrypter to find
the CD-ROM drive under win2k emulation. I had to create a link
from .wine/dosdevices/cdrom0 to /dev/scd0 manually. This is not the
right fix, but it shows that it can be done.
diff --git a/dlls/ntdll/path.c b/dlls/ntdll/path.c
index e4af89a..2ca5883 100644
--- a/dlls/ntdll/path.c
+++ b/dlls/ntdll/path.c
@@ -316,6 +316,7 @@ DOS_PATHNAME_TYPE WINAPI RtlDetermineDos
ULONG WINAPI RtlIsDosDeviceName_U( PCWSTR dos_name )
{
static const WCHAR consoleW[] = {'\\','\\','.','\\','C','O','N',0};
+static const WCHAR cdromW[] = {'\\','\\','.','\\','C','D','R','O','M',0};
static const WCHAR auxW[3] = {'A','U','X'};
static const WCHAR comW[3] = {'C','O','M'};
static const WCHAR conW[3] = {'C','O','N'};
@@ -372,6 +373,12 @@ ULONG WINAPI RtlIsDosDeviceName_U( PCWST
if (strncmpiW( start, comW, 3 ) && strncmpiW( start, lptW, 3 )) break;
if (*end <= '0' || *end > '9') break;
return MAKELONG( 4 * sizeof(WCHAR), (start - dos_name) * sizeof(WCHAR)
);
+case 11:
+if (*(end - 1) <= '0' || *(end - 1) > '9') break;
+case 10:
+if (*end <= '0' || *end > '9') break;
+if (strncmpiW( start, cdromW, 9 )) break;
+return MAKELONG( (end - start + 1) * sizeof(WCHAR), (start - dos_name)
* sizeof(WCHAR) );
default: /* can't match anything */
break;
}
--
Regards,
Pavel Roskin
Re: CRichEditCtrl: Performance issue
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 file. I checked the code and found that, in Wine, the richedit editor streams-in the data in a block of 4096 bytes. On Linux, the read request to the file is routed via Wine. For every block of 4096 bytes that are read, the system makes a back and forth call between the callback function in the application and Wine code(ME_StreamInFill() in dlls\riched20\editor.c), which causes the delay. 4096 bytes is the same that MS uses. In fact, we have other problem, it's the speed of insertion of large text chunks (especially without any formatting) to the editor storage from the RTF/plaintext reader. It should be optimized. And also, MS RichEdit, starting from version 3, displays the first page of large loaded text very quick, and you can work with it and see how vertical scrollbar thumb gets smaller and smaller and smaller while the text is read into editor storage in the background. We should add that, too. The size of the buffer does not really matter here... If anyone stumbled upon the similar issue, what should be the solution to this. Optimize internal text storage (many small mallocs and reallocs ;( ). Optimize text insertion code. Do formatting/layout tasks in the background. -- Ph.
