October 2004 - Wine-devel - list.winehq.org

Writing tests
by Walt Ogburn 28 Oct '04

28 Oct '04

Hi folks, I have a question about dependencies when writing tests. Some tests use LoadLibraryA and GetProcessAddress to get access to Windows / Wine APIs, and other tests just include the appropriate header files and link to the DLLs. One example of the first type is dlls/oleaut32/olefont.c: ================ <snip> ============================================== static HMODULE hOleaut32; static HRESULT (WINAPI *pOleCreateFontIndirect)(LPFONTDESC,REFIID,LPVOID*); START_TEST(olefont) { LPVOID pvObj = NULL; HRESULT hres; IFont* font = NULL; hOleaut32 = LoadLibraryA("oleaut32.dll"); pOleCreateFontIndirect = (void*)GetProcAddress(hOleaut32, "OleCreateFontIndirect"); if (!pOleCreateFontIndirect) return; ===================================================================== What is the reason for this difference? Which example should new tests follow? My guess is that LoadLibraryA and GetProcAddress are used if the headers, DLLs, and APIs might not be present on some Windows machines, so that the tests don't fail. If that's correct, is there a list somewhere of which ones are safe and which ones should be handled like in the olefont test? Thanks, Walter

2 1

Re: change default colors to winxp colors; add COLOR_MENUHILIGHT and COLOR_MENUBAR
by William Poetra Yoga H 28 Oct '04

28 Oct '04

--- William Poetra Yoga H <williampoetra(a)yahoo.com> wrote: > Use default colors for Windows XP's Windows Classic style, Windows Standard > color scheme. > > Added new indexes for DefSysColors: COLOR_MENUHILIGHT and COLOR_MENUBAR > My patch was not merged... :( Um... any problems with the patch? Please comment. Thanks :) __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

1 0

Re: Gradient Color for Caption Bar
by Mike McCormack 28 Oct '04

28 Oct '04

William Poetra Yoga H wrote: > Use GdiGradientFill (not GradientFill) to implement gradient caption bar (for now). GradientFill is pretty slow, as it files the rectangle line by line. I'm not sure how much this is going to slow down a normal application. It used to draw pixel by pixel, and that was a very noticable slowdown... line by line is much faster than that, but it still may cause a slowdown in some circumstances. Anybody have any ideas about how to speed up GradientFill? Mike

3 2

rsaenh and /dev/urandom
by Michael Jung 28 Oct '04

28 Oct '04

Hello, some more thoughts on the security of using /dev/urandom. This is from MSDN (CryptGenRandom): > With Microsoft CSPs, CryptGenRandom uses the same random number generator > used by other security components. This allows numerous processes to > contribute to a system-wide seed. CryptoAPI stores an intermediate random > seed with every user. To form the seed for the random number generator, a > calling application supplies bits it might have—for instance, mouse or > keyboard timing input—that are then added to both the stored seed and > various system data and user data such as the process ID and thread ID, the > system clock, the system time, the system counter, memory status, free disk > clusters, the hashed user environment block. This result is SHA-1 hashed, > and the output is used to seed an RC4 stream, which is then used as the > random stream and used to update the stored seed. This is from the linux kernel sources (2.6.8.1 drivers/char/random.c): > When random bytes are desired, they are obtained by taking the SHA > hash of the contents of the "entropy pool". The SHA hash avoids > exposing the internal state of the entropy pool. It is believed to > be computationally infeasible to derive any useful information > about the input of SHA from its output. Even if it is possible to > analyze SHA in some clever way, as long as the amount of data > returned from the generator is less than the inherent entropy in > the pool, the output data is totally unpredictable. For this > reason, the routine decreases its internal estimate of how many > bits of "true randomness" are contained in the entropy pool as it > outputs random numbers. > > If this estimate goes to zero, the routine can still generate > random numbers; however, an attacker may (at least in theory) be > able to infer the future output of the generator from prior > outputs. This requires successful cryptanalysis of SHA, which is > not believed to be feasible, but there is a remote possibility. > Nonetheless, these numbers should be useful for the vast majority > of purposes. Condensed, I read this as follows: - Microsoft uses an entropy source to seed a pseudo-random generator. If the seed is known, then the pseudo-random numbers are predictable. - /dev/urandom is also seeded with an entropy source. However, whenever the kernel collects new entropy, this also affects /dev/urandom. As I understand it, this basically means the following: In the worst case (kernel doesn't collect new entropy), we are as good as Microsoft. In all other cases /dev/urandom is better. Given this and the fact that OpenSSL also seems to apply /dev/urandom, I think rsaenh should also do it this way. Greetings, Michael

1 0

Re: Re-implement MSVCRT *printf
by Mike McCormack 28 Oct '04

28 Oct '04

Aneurin Price wrote: > Comments, anyone? Looks like you've put quite a bit of effort into that. I think it's a worthwhile effort, however, please consider: * using a style more consistent with the rest of the Wine codebase * not abusing the preprocessor in printf.h, * not writing C code in the header in printf.h * preventing code duplication by implementing the A functions using the W functions * writing some regression tests to show your code is correct thanks, Mike

4 3

Windows XP Setup
by Jacobus Erasmus 28 Oct '04

28 Oct '04

Just a quick question, How much effort would it take to get setup.exe on windows XP CD to run from begining to end. (And in the process install the DLL's fonts etc.) The second question is if somebody is willing to take on this task and how much would it cost me. Regards jacobus(a)kewlconcepts.co.za

1 0

Re: shell32: SHFileOperation improvements
by Mike McCormack 28 Oct '04

28 Oct '04

Rolf, Thanks for cleaning up SHFileOperation. Can you please try restructuring your code further to get rid of the excessive number of branching points in that function? Last time I counted, SHFileOperation had more than 60 if/while/for/case statements in the one +500 line function... that makes it hard to read. If you were to make use of helper functions more often, you'd improve your code's readability, eliminate the need for 2-space indent, the pointless /* end-if */ comments, reduce the excessive number of local variables and reduce side effects, thus making it easier for other people to understand and fix the code. Try make small functions that fit in ~50 lines. If a function gets over 50 lines, cut it up into two new functions. Mike Rolf Kalbermatter wrote: > + if (b_Multi || IsAttribFile(FromAttr)) > + continue; > + if (IsAttribDir(FromAttr)) > + { > + /* in w98/w2k/wXp endless recursive move until it aborts due to filename getting to > + long, we don't do this stupidity but return the according error anyhow here */ > + retCode = ERROR_FILENAME_EXCED_RANGE; > + break; > + } > } > - } > + if (( b_SameRoot_MOVE && (b_Multi) && !(b_MultiFrom) && IsAttribFile(FromAttr) && IsAttribDir(ToAttr)) > + || (!(b_MultiFrom) && IsAttribFile(FromAttr) && IsAttribFile(ToAttr)) > + || ( (b_Multi) && IsAttribDir(FromAttr) && IsAttribDir(ToAttr)) > + || (!b_SameRoot_MOVE && IsAttribDir(FromAttr) && IsAttribFile(ToAttr)) > + ) > + { > + ToAttr = SHRenameOnCollision(&nFileOp, pToFile + 1, pFromFile + 1); > + } /* endif */ > + } /* endif */ > + if (!(b_MultiFrom) && (!FlagRenameOnCollision(&nFileOp) || b_SameRoot_MOVE) && > + ((SFSC_IDENTIICAL | SFSC_SOURCE_CONTAINS_TARGET) & f_SameDrive)) > + { > + if (!FlagRenameOnCollision(&nFileOp) && (IsAttribFile(FromAttr))) > + { > + /* target is the same as source */ > + retCode = 0x71; > + } > + break; > + } /* endif */ > + > + /* Analyzing for moving SourceName to TargetName */ > + if ((b_MultiFrom || !b_Multi) && ((IsAttribFile(FromAttr) && IsAttribDir(ToAttr)) || > + (!b_MultiTo && IsAttribDir(ToAttr)) || > + (!b_MultiTo && IsAttribDir(FromAttr) && b_MultiFrom && !b_SameRoot_MOVE))) > + { > + SHFileStrCpyCatW(pTempTo, NULL, pFromFile); > + /* without FOF_MULTIDESTFILES shlfileop would create dir's recursively */ > + nFileOp.fFlags |= FOF_MULTIDESTFILES; > + retCode = SHFileOperationW(&nFileOp); > + continue; > + } > + /* What can we do with one pair and FO_MOVE/FO_COPY ? */ > + /* w98se, nt40 does create recursive dirs, W2K not! wMe ist not tested */ > + if (IsAttribDir(ToPathAttr) || !b_SameRoot_MOVE) > + { > + if (!b_MultiFrom) > + { > + if (IsAttribFile(FromAttr)) > + { > + if (b_SameRoot_MOVE && > + /* windows-bug, MOVE for File also with pToTailSlash, COPY not for this */ > + (!(IsAttribFile(ToAttr)) || (!(FlagAskOverwrite(&nFileOp)) && FlagNotOverwrite(&nFileOp))) && > + (IsAttribDir(ToPathAttr) || b_ToMask)) > + { > + /* With the same drive, we can move for FO_MOVE, dir to dir is solved later */ > + retCode = SHNotifyMoveFileW(nFileOp.pFrom, nFileOp.pTo); > + continue; > + } /* endif */ > + if (IsAttribDir(ToPathAttr) && !pToTailSlash && !IsAttribDir(ToAttr)) > + { > + if (!(FOI_NeverOverwrite & nFileOp.fAnyOperationsAborted)) > + { > + if (!FlagNotOverwrite(&nFileOp)) > + { > + ToAttr = INVALID_FILE_ATTRIBUTES; > + } > + if (IsAttribFile(ToAttr) && FlagNotOverwrite(&nFileOp)) > + { > + if (FlagAskOverwrite(&nFileOp)) > + { > + /* FIXME: we must change the dialog in the future to allow 3-4 cases, > + * 'Yes','No','Yes for all','Never ?' */ > + if ((INVALID_FILE_ATTRIBUTES != ToAttr) && !SHELL_ConfirmDialogW(ASK_OVERWRITE_FILE, pTempTo)) > + { > + retCode = 0x10008; > + nFileOp.fAnyOperationsAborted |= TRUE; > + break; > + } > + ToAttr = INVALID_FILE_ATTRIBUTES; > + } /* endif */ > + } /* endif */ > + } /* endif */ > + if (INVALID_FILE_ATTRIBUTES == ToAttr) > + { > + if (SHNotifyCopyFileW(pTempFrom, pTempTo, FlagRenameOnCollision(&nFileOp))) > + { > + /* the retcode for this case is unknown */ > + retCode = 0x10009; > + } > + if ((FO_COPY != FuncSwitch) && !retCode) > + { > + nFileOp.wFunc = ((level + 1) << FO_LevelShift) + FO_DELETE; > + retCode = SHFileOperationW(&nFileOp); > + } > + continue; > + } > + } > + } > + if (IsAttribDir(FromAttr)) > + { > + if (INVALID_FILE_ATTRIBUTES == ToAttr) > + { > + SetIfPointer(pToTailSlash, '\0'); > + ToAttr = SHRenameOnCollision(&nFileOp, pToFile + 1, pFromFile + 1); > + if (INVALID_FILE_ATTRIBUTES != ToAttr) > + { > + /* w2k returns ERROR_ALREADY_EXISTS, if it found the target with mask */ > +#if 1 > + retCode = ERROR_ALREADY_EXISTS; > +#else > + retCode = ERROR_INVALID_NAME; > +#endif > + nFileOp.fAnyOperationsAborted |= TRUE; > + break; > + } > + lpFileName = &pToFile[lstrlenW(pToFile)]; > + if (pToTailSlash) > + { > + pToTailSlash = lpFileName; > + lpFileName++; > + } > + ((DWORD*)lpFileName)[0] = '\0'; > + retCode = SHNotifyCreateDirectoryW(pTempTo, NULL); > + > + if (retCode) > + { > + retCode = (ERROR_PATH_NOT_FOUND | 0x10000); /* nt40,w98se,w2k,wxp */ > + break; > + } > + ToAttr = GetFileAttributesW(pTempTo); > + SetIfPointer(pToTailSlash,'\\'); > + nFileOp.fFlags &= ~FOF_RENAMEONCOLLISION; > + } > + if (IsAttribDir(ToAttr)) > + { > + /* both are existing dirs, we (FO_)MOVE/COPY the content */ > + pToFile = SHFileStrCpyCatW(pTempFrom, NULL, wWildcardFile); > + nFileOp.fFlags &= ~FOF_MULTIDESTFILES; > + retCode = SHFileOperationW(&nFileOp); > + if ((FO_COPY != FuncSwitch) && !retCode) > + { > + ((DWORD*)pToFile)[0] = '\0'; > + nFileOp.wFunc = ((level + 1) << FO_LevelShift) + FO_DELETE; > + retCode = SHFileOperationW(&nFileOp); > + } > + continue; > + } > + } /* endif IsAttribDir(from) */ > + } /* endif !b_MultiFrom */ > + } > + if (!b_SameRoot_MOVE) > + { > + nFileOp.fAnyOperationsAborted |= TRUE; > + } /* endif */ > + retCode = ERROR_CANCELLED; > + } /* end-while */

1 0

Re: rsaenh
by Juan Lang 27 Oct '04

27 Oct '04

Hi Michael, that was quick! Okay, more feedback: 1. English note: destruct_handle_table really should be destroy_handle_table. I know, "destructor" came into common use, but the verb is to destroy. Same with destruct_key, destruct_hash, etc. 2. A CSP isn't allocating a "real" handle, it's sort of a pseudohandle, so the multiple-of-four business isn't necessary. When I was testing SSPs, I found some of them return 0 as a valid handle value. So I think using the index directly would be fine. 3. Do you really need to separate all the functions into an impl version and a non-impl version? It looks as though the non-impl version does the locking, while the impl assumes the table is locked. It seems you could at least document this, and it also doesn't seem necessary in every case, if at all--EnterCriticalSection won't deadlock if a thread that's already entered it calls it again. 4. Some of the OpenSSL checks don't seem valid. In init_hash_impl, for example, you fail if libcrypto isn't available, even if it isn't necessary for the hash. Please fail only if you really need an OpenSSL func. E.g., if (!pMD2_Init) { SetLastError()... } seems better to me. 5. This may be open to debate, but as far as a "more elegant way": perhaps you should protect each typedef with the header file that defines it, e.g. in HASH_CONTEXT, rather than: #ifdef HAVE_OPENSSL MD2_CTX md2; #endif you could use: #ifdef HAVE_OPENSSL_MD2_H MD2_CTX md2; #endif This way you could support the algorithms you were compiled with, even if they aren't the entire set. Sorry I didn't mention these last time.. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

2 2

Re: Re-implement MSVCRT *printf
by Mike Hearn 27 Oct '04

27 Oct '04

I'm not sure if this is just Mozilla acting up but the patch doesn't seem to be fully indented. Is this just UA wierdness? Aneurin Price wrote: > Comments, anyone? >

1 0

Re: Gradient Color for Caption Bar
by Dmitry Timoshkov 27 Oct '04

27 Oct '04

"William Poetra Yoga H" <williampoetra(a)yahoo.com> wrote: > This patch is for filling the caption bar (a.k.a. title bar) with gradient > colors, like in Win98/WinME/Win2K/WinXP. > > I've modified nonclient.c too heavily (work on other parts of it), so this > patch may generate offsets or things like that. Please comment on wine-devel. > Thanks. > -IMPORTS = gdi32 advapi32 kernel32 ntdll > +IMPORTS = msimg32 gdi32 advapi32 kernel32 ntdll Use gdi32.GdiGradientFill instead of msimg32.GradientFill, the latter one is forwarded to gdi32 anyway. -- Dmitry.

3 3