Re: D3D9: Rework the converted vertex declaration management
On 16/04/07, Stefan Dösinger [EMAIL PROTECTED] wrote:
I have hope that this fixes the converted decl issues finally(appart of
sorting the array, which will be another patch)
+convertedDecls = HeapAlloc(GetProcessHeap(), 0,
sizeof(IDirect3DVertexDeclaration9 *) * (This-numConvertedDecls + 1));
+if(!convertedDecls) {
+/* This will destroy it */
+IDirect3DVertexDeclaration9_Release(pDecl);
+return NULL;
+}
+
+memcpy(convertedDecls, This-convertedDecls,
sizeof(IDirect3DVertexDeclaration9 *) * (This-numConvertedDecls));
+HeapFree(GetProcessHeap(), 0, This-convertedDecls);
Growing the array by a single element each time looks a bit expensive.
Also note that you could use HeapReAlloc there.
Re: FAQ moved to Wiki
On Sun, 2007-04-15 at 21:33 -0400, Dimi Paun wrote: On Sun, 2007-04-15 at 15:52 -0700, Scott Ritchie wrote: I've pasted the content from the FAQ onto the wiki here: http://wiki.winehq.org/FAQ I really don't think this is a good idea: * it's going to be less usable on the Wiki AFAIK Howso? Most people read our documentation (especially when they have a question to ask) by doing a websearch and poking around on our website. Bundling the FAQ with Wine doesn't add too much to this. * it's going to be fairly hard to edit since it is so big It's going to be a LOT easier to edit on the wiki then in that horrid monstrous SGML file. * it changes so seldom that it may as well stay on the main site It changes so seldom that about half of the entries are obsolete and might even make users more confused after reading than before. * we'll lose the other formats (.txt and .pdf) I think it needs more discussion before we do such a transition. If people agree to remove it, I can remove it from the docs/ package. I brought this up on the list last month (I think), and no one objected so I just went ahead and did it (after being lazy for a month). Anyway, we can talk about it now. I'm gonna go ahead and edit the wiki page (and include the new questions) in the meantime. Thanks, Scott Ritchie
Re: FAQ moved to Wiki
On Mon, Apr 16, 2007 at 12:00:50AM -0700, Scott Ritchie wrote: On Sun, 2007-04-15 at 21:33 -0400, Dimi Paun wrote: On Sun, 2007-04-15 at 15:52 -0700, Scott Ritchie wrote: I've pasted the content from the FAQ onto the wiki here: http://wiki.winehq.org/FAQ Hi Scott, Wiki is really a good idea. In the past I've been an opposer of Wiki engines, but nowadays I'm convinced of its usability. It should be also worhty to make nightly/monthly Wiki dumps to Wine versioning system to be able to distribute the documentation offline, for Wine users without net access. As modern Wiki engines support PDF and TXT page dumps, the only discussion IMO is how to automate wiki dumps to PDF/TXT/HTML and how to sync regularly with GIT/CVS repository. Sync should be also made before each Wine release. Thanks Vit Hrachovy
Re: KDevelop configure error or winebug
marcel busse a écrit : hi i can't debug with winedbg. it steps until end cause of no line debug info. at the start of the debugging process there is a fixme - it says something about dwarf-2 information. My config: i started a hello world with kdevelop and took as c++ compiler wineg++. that's all. __ Yahoo! Clever - Der einfachste Weg, Fragen zu stellen und Wissenswertes mit Anderen zu teilen. www.yahoo.de/clever please file a proper bug report in bugzilla tia -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: crypt32: Constify some variables (4 of 5) (Resend)
Andrew Talbot wrote: typedef BOOL (WINAPI *CryptDecodeObjectFunc)(DWORD, LPCSTR, const BYTE *, DWORD, DWORD, void *, DWORD *); typedef BOOL (WINAPI *CryptDecodeObjectExFunc)(DWORD, LPCSTR, const BYTE *, - DWORD, DWORD, PCRYPT_DECODE_PARA, void *, DWORD *); + DWORD, DWORD, const CRYPT_DECODE_PARA *, void *, DWORD *); This declaration needs to match that of CryptDecodeObjectEx in wincrypt.h. -- Rob Shearman
Re: D3D9: Rework the converted vertex declaration management
Growing the array by a single element each time looks a bit expensive. Also note that you could use HeapReAlloc there. Well, there won't be much growing operation since the number of possible FVF code combinations is limited and I expect all the fvf codes to be used somewhen in the first frame, thus don't cause a performance penality later. I want to send another patch which makes the array sorted today, and with that growing by more than one element or using HeapReAlloc won't buy us much since we have to iterate over the whole existing array anyway(to search for the place, and shift the bigger elements). pgphD0j8uBk4n.pgp Description: PGP signature
Re: Random X errors caused by recent cursor patch?
On Sat, Apr 14, 2007 at 05:19:31AM -0700, Dan Kegel wrote: On 4/3/07, Huw Davies [EMAIL PROTECTED] wrote: X Error of failed request: BadPixmap (invalid Pixmap parameter) Major opcode of failed request: 54 (X_FreePixmap) Resource id in failed request: 0x2a0006a Could you see if this helps? It looks like XRenderFreePicture actually destroys the underlying pixmap, so we ended up freeing it twice. Hi Huw, when are you going to submit that fix? People keep tripping over it; see http://bugs.winehq.org/show_bug.cgi?id=7959 and http://bugs.winehq.org/show_bug.cgi?id=8041 Unfortunately that patch isn't the correct fix - looking at the XServer code it's clear that the Pixmap is correctly ref counted, so we do indeed need to call XFreePixmap. I think the XError is due to a race between the thread display and the gdi display connections, but I haven't yet understood the issue well enough to write a correct patch. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: winealsa: implement opening and closing of device, and return caps.
Maarten Lankhorst [EMAIL PROTECTED] writes: +/* Note: this thread can be TerminateThread'd, when not in critical section + * Hence I use alloca here, and a critical section to protect when it is not + * desired to be TerminateThread'd, assume when the critical section is taken + * we won't ever get it back and we're signalled to terminate + */ +static DWORD WINAPI callback_thread(LPVOID lParam) You can't use TerminateThread for normal termination, it should only be used for fatal erros when cleaning up properly is not possible. Also please don't use alloca. -- Alexandre Julliard [EMAIL PROTECTED]
Re: secur32: invert error handling conditions in order to decrease indentation in secur32/wrapper.c.
On Monday 16 April 2007 13:20, Yuval Fledel wrote: Please reply-to-all next time. I've found your reply on the archive. Sure, sorry about that. I'm working on schannel at the moment. schannel is not a regular SSP, and the functions in wrapper.c can't load native. I've implemented the proper loading code in my local tree and I'm sending it in obvious pieces. no-op cleanups is the first step. Ok, fair enough. If you are going to work on this, feel free to clean up. I could implement schannel as a normal SSP and use the current code. However, if I can do something closer to what native does, I'd better do it. Sure. I guess Juan Lang will be interested in this (I've CCed him), as he's been working on this for quite some time now. Not that loading native schannel is a piece of cake. It does require faking lsass (done), and implementing lots of functions everywhere (userenv, crypt32, ntdll, rsaenh: I'll send after a cleanup and writing tests). The current stage is that native schannel loads and initializes, but builtin rsaenh does not supply everything it needs, so it can't complete the ssl handshake. Native rsaenh requires unimplemented stuff in ntdll. Interesting. I'll keep an eye out for those patches. Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgp19VOUc6uaj.pgp Description: PGP signature
gdi32 : Questions about SetDIBColorTable and GetDIBColorTable
Hi,
I am looking deeper inside gdi32 in order to continue helping wine after my
first try on WidenPath.
Something looks strange to me in SetDIBColorTable and GetDIBColorTable.
GetDIBColorTable is structured like this :
if (dc-funcs-pGetDIBColorTable)
result = dc-funcs-pGetDIBColorTable;
else
{
result = local implementation;
}
return result;
This looks normal. If dc-funcs-pGetDIBColorTable is available, wine uses it,
else it uses a local implementation.
In both cases, the return value is the result of the chosen operation.
But I have more difficulties with SetDIBColorTable :
result = local implementation;
if (dc-funcs-pGetDIBColorTable)
dc-funcs-pGetDIBColorTable;
return result;
Whatever happen next, the local implementation is used. Then if
pGetDIBColorTable is available, it is used too. I see here a second call for
the same thing, even if the local implementation succeed. Moreover, the result
of dc-funcs-pGetDIBColorTable is not used as a return value.
Is there a mistake here, or is there something I do not understand ?
GetDIBColorTable uses the local implementation only if dc-funcs is not
available. That is not the case for SetDIBColorTable, which runs first the
local implementation.
What is the right policy to apply here ?
I believe the call order of pSetDIBColorTable and the fact its return value is
not used are errors. Am i wrong? If someone can confirm I am not, I will
provide a patch in the next days.
Thank you for your help and time,
Laurent Vromman
Re: FAQ moved to Wiki
On Mon, 2007-04-16 at 00:00 -0700, Scott Ritchie wrote: I brought this up on the list last month (I think), and no one objected so I just went ahead and did it (after being lazy for a month). Anyway, we can talk about it now. I'm gonna go ahead and edit the wiki page (and include the new questions) in the meantime. Well, you maybe right. Let's see how well the new FAQ works on the wiki, and then decide which one to keep. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
re: Which component should I use to create this bug ?
lauren wrote: When Navigation is installed, the file DAO350.dll is copied to the Common Files directory and is regsrved. When running Navigation after that, it displays an error message about not finding DAO350.dll. Copying the file to windows/system32 allows Navigation to find the file and use it, but it should be able to find it in Common Files too. Which component should I choose ? If installing native dcom fixes it, use wine-ole. (e.g. winetricks dcom98) If in doubt, use wine-misc. (Native MSI doesn't seem to work right now, so don't try that... see http://bugs.winehq.org/show_bug.cgi?id=5809 ) Navigation is a Visual Basic program, using VB methods to load dlls. Be sure to give the app's home page. If you had mentioned it in this message, I would have tried it out myself... - Dan
re: Which component should I use to create this bug ?
The application homepage is http://francois.fouchet.free.fr/ There is now an entry in AppDB for it. I will try winetricks when home. Thank you for your help. Laurent On Mon, 16 Apr 2007 08:20:47 -0700, Dan Kegel [EMAIL PROTECTED] wrote: lauren wrote: When Navigation is installed, the file DAO350.dll is copied to the Common Files directory and is regsrved. When running Navigation after that, it displays an error message about not finding DAO350.dll. Copying the file to windows/system32 allows Navigation to find the file and use it, but it should be able to find it in Common Files too. Which component should I choose ? If installing native dcom fixes it, use wine-ole. (e.g. winetricks dcom98) If in doubt, use wine-misc. (Native MSI doesn't seem to work right now, so don't try that... see http://bugs.winehq.org/show_bug.cgi?id=5809 ) Navigation is a Visual Basic program, using VB methods to load dlls. Be sure to give the app's home page. If you had mentioned it in this message, I would have tried it out myself... - Dan
Re: gdi32 : Questions about SetDIBColorTable and GetDIBColorTable
Laurent Vromman [EMAIL PROTECTED] writes: Whatever happen next, the local implementation is used. Then if pGetDIBColorTable is available, it is used too. I see here a second call for the same thing, even if the local implementation succeed. Moreover, the result of dc-funcs-pGetDIBColorTable is not used as a return value. Is there a mistake here, or is there something I do not understand ? GetDIBColorTable uses the local implementation only if dc-funcs is not available. That is not the case for SetDIBColorTable, which runs first the local implementation. What is the right policy to apply here ? Both are correct. gdi32 always stores the color table, so it has to be updated upon SetDIBColorTable no matter what the driver does; while GetDIBColorTable doesn't need to access it if the driver has a better way of doing it. This way the driver can either: 1. not implement anything, get and set are handled by gdi32; 2. let gdi32 maintain the local copy but still do something when the color table is changed; 3. implemented both set and get to override gdi32 completely. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Random X errors caused by recent cursor patch?
On 4/16/07, Huw Davies [EMAIL PROTECTED] wrote: On Sat, Apr 14, 2007 at 05:19:31AM -0700, Dan Kegel wrote: On 4/3/07, Huw Davies [EMAIL PROTECTED] wrote: X Error of failed request: BadPixmap (invalid Pixmap parameter) Major opcode of failed request: 54 (X_FreePixmap) Resource id in failed request: 0x2a0006a Could you see if this helps? It looks like XRenderFreePicture actually destroys the underlying pixmap, so we ended up freeing it twice. Hi Huw, when are you going to submit that fix? People keep tripping over it; see http://bugs.winehq.org/show_bug.cgi?id=7959 and http://bugs.winehq.org/show_bug.cgi?id=8041 Unfortunately that patch isn't the correct fix - looking at the XServer code it's clear that the Pixmap is correctly ref counted, so we do indeed need to call XFreePixmap. I think the XError is due to a race between the thread display and the gdi display connections, but I haven't yet understood the issue well enough to write a correct patch. Huw. -- Huw Davies [EMAIL PROTECTED] BTW, I was able to frequently reproduce the bug while running the user32 message test.
Re: crypt32: Constify some variables (4 of 5) (Resend)
Robert Shearman wrote: Andrew Talbot wrote: typedef BOOL (WINAPI *CryptDecodeObjectFunc)(DWORD, LPCSTR, const BYTE *, DWORD, DWORD, void *, DWORD *); typedef BOOL (WINAPI *CryptDecodeObjectExFunc)(DWORD, LPCSTR, const BYTE *, - DWORD, DWORD, PCRYPT_DECODE_PARA, void *, DWORD *); + DWORD, DWORD, const CRYPT_DECODE_PARA *, void *, DWORD *); This declaration needs to match that of CryptDecodeObjectEx in wincrypt.h. Hi Rob, I am just curious to know why. This was my reasoning: CryptDecodeObjectEx - which I haven't touched - calls a selected local function via this local function pointer. If the local function doesn't alter the data to which a parameter points, is it not safe to constify the local version of the parameter? If there were an API function like so: WINAPI INT StrpCmpA(LPSTR pszStrA, LPSTR pszStrB); it would be OK to implement it with a helper function whose prototype was something like: static inline int strcmp(const char *s1, const char *s2); as long as the promises of s1 and s2 were kept. The only bit of memory-altering that I believe the PCRYPT_DECODE_PARA pointer is associated with is this: 250 if (pDecodePara pDecodePara-pfnAlloc) 251 *(BYTE **)pvStructInfo = pDecodePara-pfnAlloc(bytesNeeded); but I don't think that this would preclude constifying the local parameter, since it's only calling a function that allocates memory for a disconnected structure. -- Andy.
Better support for IL-2 Sturmovik
Hello, I subscribed to this list, because I want to help in developing wine so that (my current favorite) simulation works better. Egoistic hah :) ? - a good motivation though ... The first thing I want to go for is the networking support, which does not work at all. So I started off with the Developers Guide, but I noticed while debugging, that I could use some instant guidance - some person available via ICQ, any other IM or even TeamSpeak who can give quick hints. Maybe here somebody might also be interested in providing better support for this game and even wants to cooperate with me in the development. I am trying to track down the problem which causes the game Sturmovik not to be able to connect to a server. As I didn't find any other link to a person So if any of you are often online in any IM and want to provide help, I would appreciate it. Thanks in advence Briareos
Re: Better support for IL-2 Sturmovik
On 16/04/07, Briareos [EMAIL PROTECTED] wrote: So if any of you are often online in any IM and want to provide help, I would appreciate it. A lot of people are on IRC, #winehackers on freenode.
Re: Better support for IL-2 Sturmovik
Am Montag 16 April 2007 19:44 schrieb Briareos: Hello, I subscribed to this list, because I want to help in developing wine so that (my current favorite) simulation works better. Egoistic hah :) ? - a good motivation though ... I am trying to track down the problem which causes the game Sturmovik not to be able to connect to a server. As I didn't find any other link to a person Does that application maybe use directplay? pgprv7AEuKDMe.pgp Description: PGP signature
Re: advapi32: Added test and fix for GetFileSecurity
On 4/16/07, Nigel Nia-Chiang Liang [EMAIL PROTECTED] wrote: Hi, Added a simple test case and fix for GetFileSecurity with NULL pSecurityDescriptor parameter as suggested by James Hawkins. SetLastError(NO_ERROR); + result = pGetFileSecurityA( directory,OWNER_SECURITY_INFORMATION,buffer,0x40,outSize); Please don't change the whitespace. The SetLastError call is a part of that test block, so there's no need for an empty line. +result = pGetFileSecurityA( directory,OWNER_SECURITY_INFORMATION,NULL,0x40,outSize); +ok(result, GetFileSecurityA should not fail for NULL pSecurityDescriptor parameter\n); What is the value of outSize in this case? You need to set it to some value before the call and check if it's changed after the call. -- James Hawkins
Re: Which component should I use to create this bug ?
I tested my theory about the path, it turns out I was wrong, adding common files doesn't change anything. On 4/16/07, Laurent Vromman [EMAIL PROTECTED] wrote: The application homepage is http://francois.fouchet.free.fr/ There is now an entry in AppDB for it. I will try winetricks when home. Thank you for your help. Laurent On Mon, 16 Apr 2007 08:20:47 -0700, Dan Kegel [EMAIL PROTECTED] wrote: lauren wrote: When Navigation is installed, the file DAO350.dll is copied to the Common Files directory and is regsrved. When running Navigation after that, it displays an error message about not finding DAO350.dll. Copying the file to windows/system32 allows Navigation to find the file and use it, but it should be able to find it in Common Files too. Which component should I choose ? If installing native dcom fixes it, use wine-ole. (e.g. winetricks dcom98) If in doubt, use wine-misc. (Native MSI doesn't seem to work right now, so don't try that... see http://bugs.winehq.org/show_bug.cgi?id=5809 ) Navigation is a Visual Basic program, using VB methods to load dlls. Be sure to give the app's home page. If you had mentioned it in this message, I would have tried it out myself... - Dan -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
Re: Which component should I use to create this bug ?
Looking at a +file trace, it appears that the program doesn't give a path, or specifically looks for the file in the Navigation directory. If it doesn't give a path, it is a wine issue, and you should file a bug, if it specifically looks for the file in the Navigation directory, then it is a Navigation issue, and you should request the developer(s) to move the install of DAO350.dll to the navigation directory. I checked on a windows install, and the DAO350.dll is located in Common Files by default. I tried playing around with different methods to get wine to look in common files with no luck, so I'm thinking it's a wine issue. Anyone else care to look? Tom On 4/16/07, Tom Spear [EMAIL PROTECTED] wrote: I tested my theory about the path, it turns out I was wrong, adding common files doesn't change anything. On 4/16/07, Laurent Vromman [EMAIL PROTECTED] wrote: The application homepage is http://francois.fouchet.free.fr/ There is now an entry in AppDB for it. I will try winetricks when home. Thank you for your help. Laurent On Mon, 16 Apr 2007 08:20:47 -0700, Dan Kegel [EMAIL PROTECTED] wrote: lauren wrote: When Navigation is installed, the file DAO350.dll is copied to the Common Files directory and is regsrved. When running Navigation after that, it displays an error message about not finding DAO350.dll. Copying the file to windows/system32 allows Navigation to find the file and use it, but it should be able to find it in Common Files too. Which component should I choose ? If installing native dcom fixes it, use wine-ole. (e.g. winetricks dcom98) If in doubt, use wine-misc. (Native MSI doesn't seem to work right now, so don't try that... see http://bugs.winehq.org/show_bug.cgi?id=5809 ) Navigation is a Visual Basic program, using VB methods to load dlls. Be sure to give the app's home page. If you had mentioned it in this message, I would have tried it out myself... - Dan -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
Re: Better support for IL-2 Sturmovik
Am Montag, 16. April 2007 20:10 schrieben Sie: Am Montag 16 April 2007 19:44 schrieb Briareos: Hello, I subscribed to this list, because I want to help in developing wine so that (my current favorite) simulation works better. Egoistic hah :) ? - a good motivation though ... I am trying to track down the problem which causes the game Sturmovik not to be able to connect to a server. As I didn't find any other link to a person Does that application maybe use directplay? Does not seem so. I tried: WINEDEBUG=+loaddll and grepped the output with dplay, play, direct. Also I tried WINEDEBUG=+loaddll which does not give additional output. The strange thing about the networking problem is, that there is no network traffic generated (checked with wireshark).
Re: [04/10] wined3d: Ignore SetTextureStageState on unsupported texture stages
Am Montag 16 April 2007 21:19 schrieb H. Verbeet: Tests indicate that Windows doesn't actually check the bounds on this call. However, since our memory layout is almost certainly different from Windows' an application might very well get away with a little bit of memory corruption on Windows and not on Wine. It seems to me that the best way to deal with this is to simply print a WARN and return WINED3D_OK. Changelog: - Ignore SetTextureStageState on unsupported texture stages Wouldn't it be better to check against MAX_TEXTURES instead of the gl limit? Or do changes get lost on windows too? GetTextureStageState may tell the difference pgpJHDls74Tv1.pgp Description: PGP signature
Re: [04/10] wined3d: Ignore SetTextureStageState on unsupported texture stages
On 16/04/07, Stefan Dösinger [EMAIL PROTECTED] wrote:
Wouldn't it be better to check against MAX_TEXTURES instead of the gl limit?
True, use the attached patch instead.
---
dlls/wined3d/device.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index d4f8ddd..d19d773 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -3774,6 +3774,11 @@ static HRESULT WINAPI
IWineD3DDeviceImpl_SetTextureStageState(IWineD3DDevice *if
TRACE((%p) : Stage=%d, Type=%s(%d), Value=%d\n, This, Stage,
debug_d3dtexturestate(Type), Type, Value);
+if (Stage = MAX_TEXTURES) {
+WARN(Attempting to set stage %u which is higher than the max stage
%u, ignoring\n, Stage, MAX_TEXTURES - 1);
+return WINED3D_OK;
+}
+
This-updateStateBlock-changed.textureState[Stage][Type] = TRUE;
This-updateStateBlock-set.textureState[Stage][Type] = TRUE;
This-updateStateBlock-textureState[Stage][Type] = Value;
Request for small bit of mentoring
I found a small bug in the uninstaller program, and would like to write the fix myself. I have a working copy in my local tree, but it duplicates code. Basically I found that uninstaller does not scan the uninstall registry entry of HKEY_CURRENT_USER. I took lines 196-197 and duplicated that, changing HKEY_LOCAL_MACHINE to HKEY_CURRENT_USER, and then did the same for lines 210-228. I would like to get down to a smaller linecount, but I would like to do the patch myself, so I would appreciate some assistance in figuring out how. Could someone email me privately to help? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
Re: RegDeleteTree
Stefan Leichter wrote: ChangeLog -- added implementation of RegDeleteTreeA/W --- ../wine-git/dlls/advapi32/advapi32.spec 2006-10-03 10:52:50.0 +0200 +++ dlls/advapi32/advapi32.spec 2007-04-13 22:14:25.0 +0200 @@ -473,6 +473,8 @@ @ stdcall RegCreateKeyW(long wstr ptr) @ stdcall RegDeleteKeyA(long str) @ stdcall RegDeleteKeyW(long wstr) +@ stdcall RegDeleteTreeA(long str) +@ stdcall RegDeleteTreeW(long wstr) @ stdcall RegDeleteValueA(long str) @ stdcall RegDeleteValueW(long wstr) @ stdcall RegDisablePredefinedCache() --- ../wine-git/dlls/advapi32/registry.c2007-04-09 18:15:02.0 +0200 Hi Stefan, Isn't there supposed to be a corresponding entry to winreg.h ? Cheers, Paul.
Re: Better support for IL-2 Sturmovik
On Monday 16 April 2007 21:10, Briareos wrote: The strange thing about the networking problem is, that there is no network traffic generated (checked with wireshark). Can you run it on windows and get me a network trace of the traffic it generates there? As far as I am aware, our winsock implementation has a couple of bugs, but most are pretty minor and obscure. If IL-2 used directplay on the other hand, that'd explain why it's not working. I'll be able to tell from the network trace. Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpQPHQzvXRAf.pgp Description: PGP signature
FW: locales, unicode and ansi with msvcrt (bug 8022)
(Meant to copy wine-devel as well, in case anyone else had any comments)
Subject: RE: locales, unicode and ansi with msvcrt (bug 8022)
My current plan, unless you have strong objections, is to make the
wprintf
msvcrt routines use WideCharToMultiByte on the string into the GetACP
codepage before being written out, and add file tests for this into the
msvcrt testsuite
You shouldn't really guess, you need to investigate how the things are
supposed
to work in Windows. IMO you are going wrong route by looking how msvcrt
works
instead of looking how cmd.exe does. Did you try to run native cmd.exe in
WIne
and see how it handles cp conversions, or under logger.exe in Windows?
Firstly, leave cmd.exe out of the equation. This has nothing to do with it
at all. Just to emphasize, I am looking at the part of the bug where xcopy
was writing out characters padded with gaps (nulls) which is caused by it
simply calling msvcrt's wprintf.
I can recreate the problem with a simple, one line console application run
through wine (not cmd.exe nor wineconsole):
void main() { wprintf(Ltest with wprintf); }
[program was compiled VC6 : cl /MD test.c ]
wine test a.a
od -x a.a
000 0074 0065 0073 0074 0020 0077 0069 0074
020 0068 0020 0077 0070 0072 0069 006e 0074
040 0066
export WINEDLLOVERRIDES=msvcrt=n
wine test a.a
od -x a.a
000 6574 7473 7720 7469 2068 7077 6972 746e
020 0066
Shows wine internal msvcrt differs from windows msvcrt and incorrectly
outputs Unicode
I'm also guessing relay and snoop cant see internal dll calls, so that
might
explain the lack of calls. Perhaps something like wcstombs would be the
key
to this
Even if internal dll calls are not logged, wcstombs does an external call
to do
its job.
What makes you say that? It potentially doesn't need to, given the internal
caching it does in process_attach, it could do it all in memory. However...
WINEDEBUG=+all,+relay,+snoop wine test 2a.a
a.a (removing Set/GetLastError and Tls call) shows:
0009:CALL msvcrt.wprintf(00403010) ret=0040100d
0009:Call ntdll.RtlAllocateHeap(0041,,1000) ret=77c2c3c9
0009:trace:heap:RtlAllocateHeap (0x41,0002,1000): returning
0x412168
0009:Ret ntdll.RtlAllocateHeap() retval=00412168 ret=77c2c3c9
0009:Call kernel32.WriteFile(0008,0033f9c8,0011,0033f9ac,)
ret=77c30218
0009:trace:file:WriteFile 0x8 0x33f9c8 17 0x33f9ac (nil)
0009:trace:ntdll:NtWriteFile
(0x8,(nil),(nil),(nil),0x33f8b8,0x33f9c8,0x0011,(nil),(nil))!
0009: get_handle_fd( handle=0x8, access=0002, cached=1 )
0009: get_handle_fd() = 0 { type=1, flags=0 }
0009:Ret kernel32.WriteFile() retval=0001 ret=77c30218
0009:RET msvcrt.wprintf() retval=0011 ret=0040100d
Note the writefile call - it passed 0x11 bytes (number of bytes in the
narrow string)
Logger shows no calls from msvcrt during that time, but I don't trust it.
Running test program under windbg and trying to follow it through it does
appear wctomb is called (it does NOT result in WideCharToMultiByte, possibly
due to the characters or locale I am using?) but it does it on a character
by character basis (I believe during the formatting). This would be the
equivalent on wine to calling pf_vsnprintf with out.unicode set to false.
(I don't know why it doesn't come up on snoop - maybe it's a near call (no
fixups?).
So its back to a necessity to ensure for text streams we only output
multibyte (not wide).
I can see 2 ways of doing it:
1. Change MSVCRT_vfwprintf and add a conversion widechartomultibyte for a
text stream (if (MSVCRT_fdesc[fd].wxflag WX_TEXT) ...)
Advantages: Changes self contained, easy
Disadvantages: Formatting into Unicode buffer, then need to allocate space
for answer, convert, print, free
2. Change MSVCRT_vfwprintf to use a new internal function which is identical
to MSVCRT_vsnwprintf but sets out-Unicode = FALSE and out.buf.A as
destination string.
Advantages: Fastest way (conversion is WC-MB as the formatting is
processed)
Disadvantage: Needs new internal function
My preference is (2), and I have coded and tested it to confirm it does
solve both the file i/o tests (included in patch) and the console output
tests (performed by hand)
Comments?
Jason
0002-MSVCRT-f-printfw-should-output-Multibyte-not-unicode-to-text-streams.patch
Description: Binary data
Re: Request for small bit of mentoring
On 4/16/07, Briareos [EMAIL PROTECTED] wrote: Am Montag, 16. April 2007 22:35 schrieb Tom Spear: I found a small bug in the uninstaller program, and would like to write the fix myself. I have a working copy in my local tree, but it duplicates code. Basically I found that uninstaller does not scan the uninstall registry entry of HKEY_CURRENT_USER. I took lines 196-197 and duplicated that, changing HKEY_LOCAL_MACHINE to HKEY_CURRENT_USER, and then did the same for lines 210-228. I would like to get down to a smaller linecount, but I would like to do the patch myself, so I would appreciate some assistance in figuring out how. Could someone email me privately to help? Are you by chance talking about Steam? No im talking about the wine uninstaller program. From the command line, type uninstaller. It's located in wine/programs/uninstaller.. It's wine's version of the Add/Remove Programs control panel applet. By the way, in case anyone wants to review it to offer comment, the patch is attached. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email uninstaller.patch Description: Binary data
wine 0.9.35 Something strange happened with the fonts ?
Well, I don't quite know what happened there with the fonts, however my fonts are now back working by deleting the contents of the fonts folder c:\windows\fonts\ and simply copying in verdana.ttf + bold+italics etc into this folder. The reason I had to copy verdana was because the application 'anno domini' copies a font called broadway into \windows\fonts\ then another application 'Virtual Mechanics Webengine' then uses the broadway font for it's license dialogue box, presumably because that's the only font present in c:\windows\fonts\ unless verdana is in /windows/font/ directory then it uses that which looks an awful lot more legible than the broadway font. So it seems to be working now, however I have a question. When you run notepad.exe and look at the fonts available, with an empty windows\fonts\ directory notepad lists about 51 fonts, all of which are truetype except 1. So why are these fonts not in \windows\fonts\ where applications such as webengine can find them ? And how does fontforge figure in this equation, I assume it generates the 51 fonts then wine passes those fonts in some way. However won't that cause a problem for applications that expect to find fonts present in \windows\fonts ? Regards Nick
Re: wine 0.9.30-35 Something strange happened with the fonts ?
Nick Law wrote: Well, I don't quite know what happened there with the fonts, however my fonts are now back working by deleting the contents of the fonts folder c:\windows\fonts\ and simply copying in verdana.ttf + bold+italics etc into this folder. The reason I had to copy verdana was because the application 'anno domini' copies a font called broadway into \windows\fonts\ then another application 'Virtual Mechanics Webengine' then uses the broadway font for it's license dialogue box, presumably because that's the only font present in c:\windows\fonts\ unless verdana is in /windows/font/ directory then it uses that which looks an awful lot more legible than the broadway font. So it seems to be working now, however I have a question. When you run notepad.exe and look at the fonts available, with an empty windows\fonts\ directory notepad lists about 51 fonts, all of which are truetype except 1. So why are these fonts not in \windows\fonts\ where applications such as webengine can find them ? And how does fontforge figure in this equation, I assume it generates the 51 fonts then wine passes those fonts in some way. However won't that cause a problem for applications that expect to find fonts present in \windows\fonts ? Regards Nick I tied it down to a specific font sserief.fon 18,576 bytes (generated with fontforge ?) This being present in \windows\fonts causes the license help dialogues text to be blank in the webengine application.. while in notepad MS sans serif text is also blank. Another, much larger sserief.fon file (about 62Kbytes) was present in X11/truetype (which may have come from a windows system ?) was used instead which worked just fine in both notepad webengine. So could fontforge be producing a bad sserief.fon file or .fon files that wine has trouble displaying ?. I checked back to 0.9.30 and the md5 of the sserief.fon file is the same as the file in 0.9.35. so the fon file hasn't changed so is it something in wine changed between version 0.9.30 35 ? Is it the case these .fon files should not be in /windows/fonts
locales, unicode and ansi with msvcrt (bug 8022)
I've tried the test with winelib and got:
$ winegcc test.c
$ ./a.out nya
$ od -x nya
000 3f3f 3f3f 3f3f 3f3f 0066
011
This output differs from previous. I tried this under several locales, the
results are the same.
When I applied the patch, EXE version (I used mingw32 instead of VC 6), works
OK, but no changes with winelib. Buggy winegcc???
Next test.
Here I use localized strings.
#include windows.h
void main() {
/* Это тест (this is a test in Russian) */
WCHAR russtr[]={0x044d, 0x0442, 0x043e,
0x0020, 0x0442, 0x0435,
0x0441, 0x0442, 0x};
wprintf(Ltest with wprintf);
wprintf(russtr);
}
Result of mingw32-gcc version:
000 6574 7473 7720 7469 2068 7077 6972 746e
020 fd66 eef2 f220 f1e5 00f2
031
The localized string has been written in cp1251.
The results are the same wine cmd a.exe and wine /k a.exe.
winconsole --backend=user does not work.
The same test under windows (mingw32 version): Only test with wprintf has
been printed.
No localized string. Mystic? Wine works, but windows does not???
Under simple wine cmd /k ... windows programs and wine produce the same
output (now). Under wineconsole embedded cmd commands like 'help' still does
not work. Windows The Native Ones - works OK. I suspect we output them in the
wrong way.
Thus, the bug where xcopy was writing out characters padded with gaps is
fixed,
but invalid codepage bug is still present. pf_vsnprintf is buggy??? (yes, it
sounds blasphemic, but it is the one thing I can imagine).
Thanks a lot!
--
Kirill
Services, net start, and control panel
While pondering native msiexec's navel, I looked around for ways to start, stop, and list services on Wine. Didn't see any; there probably ought to be a net.exe command that implements start and stop verbs, and a little control panel, too. I bet it wouldn't be too hard to implement them. For the curious, here are a couple service-related demo apps that might be of interest: http://www.codeproject.com/system/xyntservice.asp is a handy little demo service, and http://www.codeproject.com/system/AMFSServiceManager.asp is a handy little control-panel-like service manager gui (doesn't work because EnumServiceStatus isn't implemented). - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
