August 2005 - Wine-Devel - list.winehq.org

Bugzilla - old rubbish bugs...
by Ann & Jason Edmeades Aug. 25, 2005

Aug. 25, 2005

I asked this a while ago and noone was too upset, but I am going to try to spend some time slowly closing off some of the bugs which do not have enough info in them to be reproduced, and have not had a response to a request to see if the problem persists for a long time (e.g. 6 months). I wont close anything which is reproducible (I'll try if I can) and I believe if something is wrongfully closed it can always be reopened? If anyone else has a spare moment, feel free to help! At the moment there is >1300 available bugs, but looking at lots of them in detail I doubt there's 500 which are worth keeping! (I was bored and looking for some things to fix and it's like a needle in the haystack looking in bugzilla at the moment). Jason

2 1

Loading resources from wine dlls
by Michael Jung Aug. 25, 2005

Aug. 25, 2005

Hello, I would like to add a 'My Documents' icon to shell32. This icon has a resource ID of 235 in WinXP's shell32. Apparently one can't load resources from wine's own dlls, though. If you call PrivateExtractIcons with 'c:\windows\system32\shell32.dll' as the file name parameter, you'll get a 'WARN: File %s not found or path too long'. I guess that's because there is no such file in wine's fake windows environment. There is a hack (which is even declared as a hack in the comment) in the initialization code of the 'Shell Icon Cache' (starting from line 372 in 'dlls/shell32/iconcache.c'). It loads the first 38 icons from shell32 at initialization time, and later returns them from the cache without having to access the file (which would'nt work). This seems to be a principal problem (Loading resources from wine dlls, if they are accessed by the filename they have on a windows system). Are there any plans on how to fix this? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

3 2

Throwing in an idea (probably it was discussed before though)
by John Smith Aug. 24, 2005

Aug. 24, 2005

As a Win developer, I want to make a suggestion (sorry if it was already discussed - or if similar mechanism already exists): What if some simple way will be provided for Win developers to say which options they prefer for WINE to use for their application? While it may seem to somewhat contradict to the 'big bright future' of the WINE (with all the apps running flawlessly under WINE), it would hopefully allow for immediate increase of out-of-the-box supported applications. For example, it could be a resource string of special format (for example, "__WINE_CONFIG_HINT: "Managed" = "N""), and multiple hints should be allowed. This hint should override system-wide settings but in turn should be overridden by per-app settings in wine config file/registry. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

8 13

Re: secur32: Getting some real functionality into the NTLM provider, try 2
by Juan Lang Aug. 24, 2005

Aug. 24, 2005

Hi Kai, In ntlm.c, + /* convert the program name to Unicode */ (snip) + /* and back to the CP_UNIXCP */ This round-tripping is unnecessary when the text is already ASCII. ASCII values are just as valid in UTF8 as they are in CP1252 or whatever. Basically, don't bother converting anything you can type. + if(pAuthData == NULL) In this if statement, you duplicate the business of converting the user name and domain name to CP_UNIXCP in both branches. You should instead store a pointer to the user name and domain name, and convert them in one common branch after the if statement. + SEC_CHAR *client_argv[] = + { + program, + client_protocol, + client_user_arg, + client_domain_arg, + NULL + }; You must declare variables at the beginning of the block, not in the middle. Not all C compilers allow this. + if(pszPackage != NULL) + { + int package_sizeW = MultiByteToWideChar(CP_ACP, 0, pszPackage, -1, + NULL, 0); Since you don't use pszPackage in ntlm_AcquireCredentialsHandleW, why bother converting it? Just pass NULL. + if(identity->Flags == SEC_WINNT_AUTH_IDENTITY_ANSI) (snip) + else + { + memcpy(pAuthDataW, identity, sizeof(SEC_WINNT_AUTH_IDENTITY_W)); + } This looks funny. Why not just set pAuthDataW to identity in this case? That way you avoid the memcpy. Something like this: PSEC_WINNT_AUTH_IDENTITY_W pAuthDataW; if (identity->Flags == SEC_WINNT_AUTH_IDENTITY_ANSI) { /* convert it like you do */ } else pAuthDataW = (PSEC_WINNT_AUTH_IDENTITY_W)identity; /* call ntlm_AcquireCredentialsHandleW */ if (pAuthDataW != identity) HeapFree(GetProcessHeap(), 0, pAuthDataW); + if((ret = encodeBase64(helper->password, + helper->pwlen-2, buffer+3, + max_len-3, &buffer_len)) != SEC_E_OK) + { + HeapFree(GetProcessHeap(), 0, buffer); + HeapFree(GetProcessHeap(), 0, bin); + return ret; + } You ought to zero the memory of the password and free it, regardless of whether encodeBase64 succeeds or fails. (Really you ought to call SecureZeroMemory, but wine hasn't implemented that.. oh well.) In tests/ntlm.c: + //lstrcpyA(identity->Password, pass ? pass :""); No C++ style comments, please. More generally, on the tests, I like them because they should nearly always succeed in Windows. But they're not very likely to succeed in Wine, are they? You handle not having an ntlm_auth fairly gracefully, I think, and also handle not being able to create an inbound context, which you say may not work without some magic setup. But this won't generally work out of the box if ntlm_auth works and an inbound context can be created, can it? The tests will try to authenticate with whatever domain name is in the registry, or default to WORKGROUP if that's empty, and your UNIX username, and no password. That's not very likely to succeed. So, it would be nice to have these tests somewhere for people to check that this code indeed works.. but I'm not sure they can go into the regression test suite. Unless I'm mistaken. Thanks, --Juan ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

1 0

Delphi 5 debugger is working!
by Vitaliy Margolen Aug. 24, 2005

Aug. 24, 2005

As of todays CVS Delphi 5 debugger is fixed. Well, ok, there are still some bugs. One is a minor bug (Module view reports all modules as a project executable name), but all exports are there. You can even try to disassemble them. But here is where the major problems start. Debugger segfaults on that. This is because NtQueryVirtualMemory and NtProtectVirtualMemory currently don't work on other processes. I have modified those functions to return STATUS_SUCCESS instead. This allows to access ntdll, kernel32 and possibly any other modules that have the same base address for application and debugger. You might need prelink installed to relocate ntdll and kernel32 to 0x7bxxxxxx addresses. This makes their base addresses the same for all wine apps. Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others is not that simple. Basically there are no way to do it from other processes. Ok, NtQueryVirtualMemory could be implemented some-what easily using NtReadVirtualMemory and possibly one more server call. But for others I see only three ways to implement them: 1. Adding worker thread to each process. This way we can ask it to perform requested operation for us. But, there is a catch - this will complicate lots of things. Besides, messing with processes is not a good thing(tm). It will brake some apps, that don't expect to see more then one thread. Or if we'll try to hide a worker thread, it will make things even worse. 2. Using signal(s). Unfortunately this is not as simple to do ether. From what I been told, this will require non trivial synchronization, that still doesn't guarantee deadlocks. 3. Infamous wine kernel module. Some how I don't think that kernel guys will go for this type of functionality. Even for debugging proposes, it still poses considerable security risk allowing one process manipulate other process' memory. So it will have to be a wine only module, which means we'll have to maintain in against all supported kernel versions and require kernel development environment. Any other solutions that I have forgotten/haven't even thought of? -- Best regards, Vitaliy

5 6

Re: Software patents
by gslink Aug. 24, 2005

Aug. 24, 2005

The whole business of software patents is very likely to explode at any time. There are several software patents on cds and dvds which are so vague that it is impossible to tell exactly what is going on. The licenses to use these patents allow the company issuing the patent to control cd content and to examine it. The first time one of these companies tries to use the license to access DOD classified information there will be a resolution. The easiest way to resolve this business with Borland is to contact Borland. They may also have an interest in Wine. If they have no objection to what Wine wants to do then there is no one else to complain. They might even help Wine. Borland probably doesn't even realize that Wine exists although some of the people in Borland are probably very familiar with it. I think you will find this to be true of all big software companies such as IBM and Microsoft.

8 10

solution for including itss.h in hhctrl.ocx
by James Hawkins Aug. 24, 2005

Aug. 24, 2005

Hey Alexandre, I need to be able to include itss.h from dlls/itss in order to read CHM files. Mike offered the solution that I add -I($SRCDIR)../itss to hhctrl's Makefile.in. The next problem comes when I run make depend. make depend looks for itss.h but can't find it because it hasn't been built yet. Mike then suggested adding ../dlls/itss/itss.idl to IDL_SRCS in include/Makefile.in. That works fine up until make install which gives these two errors: /usr/bin/install: cannot create regular file `/usr/include/wine/windows/../dlls/itss/itss.idl': No such file or directory /usr/bin/install: cannot create regular file `/usr/include/wine/windows/../dlls/itss/itss.h': No such file or directory Do you have any suggestions on how to access itss.h from hhctrl.ocx? -- James Hawkins

2 1

Re: commctrl: dialog theming
by Evil Aug. 24, 2005

Aug. 24, 2005

I'm no longer able to run programs that require the native comctl32 and commctrl DLLs, since updating to today's CVS. Could it be related to these theme patches? It seems that now, if you override comctl32 for any app (or globally), even WineCfg itself will error out with the error. err:thunk:_loadthunk (commctrl.dll, Cctl1632_ThunkData16, comctl32.dll): Unable to load 'commctrl.dll', error 2 err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"c:\\windows\\system32\\winecfg.exe" failed, status c0000142 The native commctrl.dll and comctl32.dll both exist in my windows/system directory - the same versions that always worked before. Overriding commctrl doesn't have any effect on this error. -J Frank Richter wrote: >This patch assumes the listbox patch was applied before. > >Frank Richter <frank.richter(a)gmail.com> >Add theming support for dialogs (to support tab page background). > >

5 9

wine error with 'wine client error:d: write: Bad file descriptor'
by Oliver Mössinger Aug. 24, 2005

Aug. 24, 2005

Hi wine-devel, i have a windows program whitch generates the attached 'wine.txt' wine output. Followed is a part of the output: >>> Threads: process tid prio (all id:s are in hex) 00000042 (D) C:\MGC\LeoSpec\LS2005a_82\bin\win32\leonardo.exe 00000017 0 0000000d 0 <== 0000000e 00000016 0 00000013 0 00000012 0 00000011 0 00000010 0 0000000f 0 WineDbg terminated on pid 0x42 wine client error:d: write: Bad file descriptor <<< The program works with windows! Can someone help me to run the program? thanks Oliver Mössinger

1 0

Re: secur32: Getting real functionality into the NTLM provider
by Alexandre Julliard Aug. 24, 2005

Aug. 24, 2005

Kai Blin <blin(a)gmx.net> writes: > + unsigned char buffer[SECUR32_MAX_BUF_LEN+6000]; > + BYTE bin[SECUR32_MAX_BUF_LEN]; You shouldn't allocate fixed size buffers on the stack, especially not huge ones like that. You should compute the necessary size and allocate a properly sized buffer from the heap. > + SEC_CHAR client_user_arg[512]; > + SEC_CHAR client_domain_arg[512]; > + SEC_CHAR passwd[512] = {0}; Same here, there's nothing that guarantees the buffers are the right size; using snprintf may avoid overflows but it doesn't make the code behave correctly. > +SECURITY_STATUS fork_helperA(PNegoHelperA *new_helper, const char *prog, > + char * const argv[], char* passwd) > +{ You should have a single fork helper that takes Unicode, you can't pass ASCII chars to the Unix app anyway, you have to use CP_UNIXCP. And more generally, you should do everything in Unicode. > + if( ( pipe(pipe_in) < 0 ) || ( pipe(pipe_out) < 0 ) ) > + { > + return SEC_E_INTERNAL_ERROR; > + } > + > + helper->helper_pid = fork(); > + > + helper->password = passwd; > + > + if(helper->helper_pid == -1) > + { > + return SEC_E_INTERNAL_ERROR; > + } You are leaking file descriptors in the error cases. > + if(helper->helper_pid == 0) > + { > + /* We're in the child now */ > + close(0); > + close(1); > + > + dup2(pipe_out[0], 0); > + close(pipe_out[0]); > + close(pipe_out[1]); > + > + dup2(pipe_in[1], 1); > + close(pipe_in[0]); > + close(pipe_in[1]); > + > + execvp(prog, argv); > + > + /* Whoops, we shouldn't get here. Big badaboom.*/ > + return SEC_E_INTERNAL_ERROR; You shouldn't return from the child, you should pass the error back to the parent and then exit(). > + { > + helper->pipe_in = fdopen(pipe_in[0], "r"); > + close(pipe_in[1]); > + helper->pipe_out = fdopen(pipe_out[1], "w"); > + close(pipe_out[0]); > + } You should avoid using stdio. -- Alexandre Julliard julliard(a)winehq.org

2 2