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

Re: Re-implement MSVCRT *printf

by Aneurin Price

Mike McCormack wrote: > > 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 Could you elaborate on this point? I'm not sure to what exactly it is you're referring. > * not abusing the preprocessor in printf.h, > * not writing C code in the header in printf.h Actually I don't really know why I even called it that, since it was never really a header, just by analogy with scanf.h I suppose :-), but see below... > * preventing code duplication by implementing the A functions using the > W functions The attached patch addresses these points, does it look any better? I haven't tested it too rigorously yet, since I wanted some feedback without first spending ages checking it extensively, but it seems to be fine - just have to make sure I haven't forgotten some corner cases. > * writing some regression tests to show your code is correct I still don't really know what I might test here. Maybe try examples of cases where the current code does not act like Windows; there are also some cases where neither acts like windows (but they seem to have the same problems). The problem is I probably wouldn't think of cases where my code causes regressions (otherwise it wouldn't do so:-)), and this isn't really something in which you can enumerate all the different combinations of options (at least without infinite time and patience). Thanks for your comments, Aneurin Price

Oct. 27, 2004

Re: rsaenh

by Juan Lang

Looks good to me, Michael, though I'd suggest using /dev/random rather than /dev/urandom: the blocking behavior of the former shouldn't be a problem for Wine (since this DLL makes no timing guarantees anyway). Since this replaces rsabase.dll, you could add a patch to wine.inf that registers this rather than that. Otherwise forward away to wine-patches and see what happens :) --Juan --- Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > Hello, > > this is an updated version of my rsaenh.dll patch from yesterday with > Juan's > suggestions implemented: > > 1.) Changed destruct_... function names to destroy_... . > 2.) Removed the multiple-of-four behaviour for handles. > 3.) Got rid of the splitting of handle management functions into one > table > locking function and one function, which actually does the real work. > 4.) MD4, MD5 and SHA hashes as well as random number generation will > work now > even if rsaenh was compiled with libssl-dev headers available, but no > libcrypto.so at run-time. > 5.) Compilation fixes for the case that OpenSSL was configured to > support only > a subset of the functions imported by rsaenh.dll. > 6.) Uses /dev/urandom instead of OpenSSL's RAND_bytes function. (Do we > have to > check for the availability of /dev/urandom in the configure script?) > > If you want to try the patch note the following: > - After you have applied the patch you have to run autoheader and > autoconf. > Then cd dlls ; make_dlls ; cd .. ; configure. > - After you have compiled and installed wine, you have to unregister > rsabase > and register rsaenh (regsvr32 /U rsabase ; regsvr32 rsaenh). rsaenh.dll > is > meant to replace rsabase.dll sometime (Windows XP also has rsaenh.dll > only). > > Greetings, > Michael _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com

Oct. 27, 2004

rsaenh

by Michael Jung

Hello, this is an updated version of my rsaenh.dll patch from yesterday with Juan's suggestions implemented: 1.) Changed destruct_... function names to destroy_... . 2.) Removed the multiple-of-four behaviour for handles. 3.) Got rid of the splitting of handle management functions into one table locking function and one function, which actually does the real work. 4.) MD4, MD5 and SHA hashes as well as random number generation will work now even if rsaenh was compiled with libssl-dev headers available, but no libcrypto.so at run-time. 5.) Compilation fixes for the case that OpenSSL was configured to support only a subset of the functions imported by rsaenh.dll. 6.) Uses /dev/urandom instead of OpenSSL's RAND_bytes function. (Do we have to check for the availability of /dev/urandom in the configure script?) If you want to try the patch note the following: - After you have applied the patch you have to run autoheader and autoconf. Then cd dlls ; make_dlls ; cd .. ; configure. - After you have compiled and installed wine, you have to unregister rsabase and register rsaenh (regsvr32 /U rsabase ; regsvr32 rsaenh). rsaenh.dll is meant to replace rsabase.dll sometime (Windows XP also has rsaenh.dll only). Greetings, Michael

Oct. 27, 2004

Re: Listview notify_dispinfoT Messageformat

by Robert Shearman

Thorsten Kani wrote: > Hello, > Testing showed that the current implementation of notify_dispinfoT > doesnt work with W2K. (or at least not with SP4 (: ) > The attached patch corrects that our Listview doesnt display anything > on native. > > Following assumption proved to be wrong for the Message LVN_GETDISPINFOW: > /* > With testing on Windows 2000 it looks like the notify format > has nothing to do with this message. It ALWAYS seems to be > in ansi format. */ > > This time, only LVN_*ETDISPINFOW is patched, anything else is untouched. > -Anybody please tell me if you see problems with this Fix since i dont > want to break things.- I have seen exactly the same problem with the IShellView implementation in native shell32. I have attached the patch I did at the time. I didn't submit it, because I soon got into a tangled mess where the function name was wrong and the isW parameter completely unnecessary and a whole bunch of functions calling it were also wrong. To summarise: *all* common control notifications should be sent in the same format (ANSI/Unicode) as their parent (except if overriden by the CCS_SETUNICODEFORMAT message). It should not be based on the message sent to the control. Rob Index: listview.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/listview.c,v retrieving revision 1.394 diff -u -p -r1.394 listview.c --- listview.c 2 Sep 2004 23:00:53 -0000 1.394 +++ listview.c 27 Oct 2004 20:16:51 -0000 @@ -818,10 +818,6 @@ static int get_ansi_notification(INT uni } /* - With testing on Windows 2000 it looks like the notify format - has nothing to do with this message. It ALWAYS seems to be - in ansi format. - infoPtr : listview struct notificationCode : *Unicode* notification code pdi : dispinfo structure (can be unicode or ansi) @@ -830,14 +826,10 @@ static int get_ansi_notification(INT uni static BOOL notify_dispinfoT(LISTVIEW_INFO *infoPtr, INT notificationCode, LPNMLVDISPINFOW pdi, BOOL isW) { BOOL bResult = FALSE; - BOOL convertToAnsi = FALSE; INT cchTempBufMax = 0, savCchTextMax = 0; LPWSTR pszTempBuf = NULL, savPszText = NULL; - if ((pdi->item.mask & LVIF_TEXT) && is_textT(pdi->item.pszText, isW)) - convertToAnsi = isW; - - if (convertToAnsi) + if ((pdi->item.mask & LVIF_TEXT) && (infoPtr->notifyFormat == NFR_ANSI)) { if (notificationCode != LVN_GETDISPINFOW) { @@ -861,15 +853,16 @@ static BOOL notify_dispinfoT(LISTVIEW_IN savPszText = pdi->item.pszText; pdi->item.pszText = pszTempBuf; pdi->item.cchTextMax = cchTempBufMax; + + notificationCode = get_ansi_notification(notificationCode); } TRACE(" pdi->item=%s\n", debuglvitem_t(&pdi->item, infoPtr->notifyFormat != NFR_ANSI)); - bResult = notify_hdr(infoPtr, get_ansi_notification(notificationCode), - (LPNMHDR)pdi); + bResult = notify_hdr(infoPtr, notificationCode, &pdi->hdr); - if (convertToAnsi) + if ((pdi->item.mask & LVIF_TEXT) && (infoPtr->notifyFormat == NFR_ANSI)) { MultiByteToWideChar(CP_ACP, 0, (LPSTR) pdi->item.pszText, -1, savPszText, savCchTextMax);

Oct. 27, 2004

Re: Gradient Color for Caption Bar

by Mike McCormack

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

Oct. 27, 2004

Listview notify_dispinfoT Messageformat

by Thorsten Kani

Hello, Testing showed that the current implementation of notify_dispinfoT doesnt work with W2K. (or at least not with SP4 (: ) The attached patch corrects that our Listview doesnt display anything on native. Following assumption proved to be wrong for the Message LVN_GETDISPINFOW: /* With testing on Windows 2000 it looks like the notify format has nothing to do with this message. It ALWAYS seems to be in ansi format. */ This time, only LVN_*ETDISPINFOW is patched, anything else is untouched. -Anybody please tell me if you see problems with this Fix since i dont want to break things.- Tho

Oct. 27, 2004

Re: rsaenh

by Juan Lang

--- Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > > 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. > I would rather keep this, since it isn't really a performance problem. > Perhaps > sometime somebody else will use the code with "real" handles. No, this won't be the case. By real handle I mean one which is sharable between processes, is refcounted by the wineserver, etc. That isn't the case with the Crypto API handles. So no, it doesn't cause a performance problem, but it is confusing. > This handle > managing code is actually another example where I would love to have a > library, which would be linked statically by multiple dlls. I agree that one should be available. Robert Shearman posted a patch to add handle tables to ntdll: http://www.winehq.org/hypermail/wine-patches/2004/10/0339.html It isn't committed yet, but it might be a usable replacement. It depends how much you need the features it doesn't provide. > When I wrote the code I thought a double call to EnterCriticalSection on > the same mutex might deadlock. I later found out that I doesn't, but > thought that it might be faster to avoid multiple calls to > EnterCriticalSection, since those call wineserver. It doesn't appear as though critical sections involve the wine server. Take a look at ntdll/critsection.c and RtlEnterCriticalSection. > > 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. > Are you saying that we should consider the case where we actually have a > libcrypto.so at runtime, but which only exports a subset of the > functions rsaenh was compiled with? No, in this case I'm pointing out that most of the hash functions don't require OpenSSL at all (MD4, MD5, and SHA1), so why should they be prevented from working if it isn't available? Right now the check is done at the entry to the function, so all will fail if libcrypto.so isn't there. In my above example I move the check to the function that depends on libcrypto.so. > Now, this would mean we are considering the case, where we only have a > subset of the libssl-dev headers at compile time, right? Right, or that the OpenSSL you compiled against had some of the algorithms disabled. The check as you have it will prevent MD2 from working if DES wasn't available at compile time, and vice-versa. There's no guarantee how OpenSSL was configured. A similar comment, that is also open to debate, is the implementation of gen_rand_impl. I know, rsabase already does it this way.. but it might be better to try to use /dev/random instead of RAND_bytes, since that will work on many platforms whether or not OpenSSL is available. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

Oct. 27, 2004

Re: Re-implement MSVCRT *printf

by Mike Hearn

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? >

Oct. 27, 2004

Re: Gradient Color for Caption Bar

by Shachar Shemesh

Mike McCormack wrote: > 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? How many colors are typically drawn across a single bar? If this number is significantly less than the number of vertical lines, you can precalculate the width of each color bar, and draw a series of boxes. > Mike Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Oct. 27, 2004

Re: Gradient Color for Caption Bar

by Dmitry Timoshkov

"William Poetra Yoga H" <williampoetra(a)yahoo.com> wrote: > Well, I can't find GdiGradientFill by searching at MSDN. I found some links > through Google, though. Is it a deprecated, old API? If that's the case, I > think we'd better link to msimg32. GdiGradientFill is the gdi32 entry point to which msimg32's GradientFill is forwarded. "Deprecated" is the Microsoft term which they usually use to force developers to go the way Microsoft wants and has nothing to do with reality and especially with Wine development. -- Dmitry.

Oct. 27, 2004