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

question about modal messageboxes.

by Ivan Leo Puoti

I looked at MSDN docs for MessageBox http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu… and found that MB_SYSTEMMODAL is identical to MB_APPLMODAL, the only difference is that the dialogue box is created with WS_EX_TOPMOST. In Wine the window style is loaded from user32_En.rc, and STYLE contains, amongst other things, DS_SYSMODAL. MSDN http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu… says that if this value is used the window will be created using the WS_EX_TOPMOST style. But what this means is that in Wine a messagebox is *always* created with this style, while, if MSDN is correct, this should only happen when MB_SYSTEMMODAL is passed to MessageBox. Am I getting something wrong or is this a bug? If yes, would creating 2 resources, one for MB_APPLMODAL and one for MB_SYSTEMMODAL be a good solution? Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

Oct. 29, 2004

Re: rsaenh

by Juan Lang

Michael wrote: > If I use /dev/random in my patch the unit tests take more than three > minutes without any user interaction. As to be expected, it runs faster > if I move the mouse around wildly to generate entropy => You're right, this seems unreasonable for 32 bytes of random data, especially in this context. Alexandre has the final word anyway, so submitting to wine-patches was a good idea. Again, sorry I didn't see all this up front, but I'd like to suggest the following improvement: If OpenSSL is available, go ahead and use RAND_bytes, but call RAND_add first with the input buffer. I don't have a good estimate for the number of bits of entropy to expect, since we don't know whether the caller will actually have provided a seed. Assuming it's unlikely, maybe RAND_add(pbBuffer, dwLen, dwLen / 16.0f)? And go ahead and fall back to /dev/urandom if OpenSSL isn't available. Thanks, --Juan __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

Oct. 29, 2004

We hit 5mb for 3 months running!

by Mike Hearn

Hey guys, Here's a great excuse for a party: wine-patches has had 5mb of traffic per month for the last three months now. Apart from a short dip over the summer, it looks like we've been consistently generating 5mb/month for most of the year! 2003 was mostly hovering around the 4mb level, and 2002 was mostly 1-2mb (apart from when Dimi had his listview hackfest and we got 6mb!) so we seem to be doing something right :) Let's see if we can keep it up and who knows, maybe 2005 will be averaging at 6mb/month! Expect me to be doing my bit in a few days (ADSL on Nov 1st now :) thanks -mike

Oct. 29, 2004

Re: Wine, openssl, kerberos, and "fixme:crypt:RSA_CPAcquireContext You have to install libcrypto.so..."

by Vincent Béron

Le ven 29/10/2004 à 01:56, Dan Kegel a écrit : > Maybe this is old hat, but: > > I ran into the message > fixme:crypt:RSA_CPAcquireContext You have to install libcrypto.so and development headers in order to use crypto API > while running an app. Looking at the code, > it's only issued if wine's configure can't find /usr/include/openssl/ssl.h. > But I have that file! Digging deeper, I saw that ssl.h > includes krb5.h, which isn't on the standard include path. > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82369 > explains the issue. It looks like configure.ac needs > to be modified as described in that bug report to check > for pkgconfig-openssl, and use it if present to guess > the cflags needed to use openssl: > > $ pkg-config openssl --cflags > -I/usr/kerberos/include > > A workaround seems to be to configure like this: > ./configure CFLAGS="-I /usr/kerberos/include " > This happily sets HAVE_OPENSSL_SSL_H in include/config.h. IIRC, that's only needed on RH9 (not on RH7.3, RH8, FC1, FC2, WBEL3), and is exactly what my rpm for it does. Also, CPPFLAGS is a better choice than CFLAGS (it's the preprocessor which needs that -I directive, not the compiler). Vincent

Oct. 29, 2004

Re: SHDOCVW: download the Mozilla Active X control on demand (take 2)

by Dimitrie O. Paun

On Fri, Oct 29, 2004 at 10:08:32AM +0200, Andreas Mohr wrote: > Hi, > > Well, the least we should do is have the URL point to WineHQ and then > use a forward page to his URL IMHO. > Hosting it on WineHQ would probably be the best way indeed. Nah, this is what our SourceForge page is for. -- Dimi.

Oct. 29, 2004

Re: USER32: add a short test for child windows (take 2)

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > ChangeLog: > * add a short test for child windows > START_TEST(win) > { > + test_child_window(); > + > pGetAncestor = (void *)GetProcAddress( GetModuleHandleA("user32.dll"), "GetAncestor" ); > pGetWindowInfo = (void *)GetProcAddress( GetModuleHandleA("user32.dll"), "GetWindowInfo" ); Please add your test at the end of existing tests. By placing the test before everything else you are at least skipping the tests performed in the hook procedure. -- Dmitry.

Oct. 29, 2004

Re: SHDOCVW: download the Mozilla Active X control on demand (take 2)

by Andreas Mohr

Hi, On Fri, Oct 29, 2004 at 01:52:27PM +0900, Mike McCormack wrote: > I think we should not put Adam's page in our registry by default, but > perhaps host the control on WineHQ somewhere and use the URL for that > instead, so as not to direct too much traffic to Adam's page... Well, the least we should do is have the URL point to WineHQ and then use a forward page to his URL IMHO. Hosting it on WineHQ would probably be the best way indeed. Andreas Mohr

Oct. 29, 2004

Re: signaling unix threads

by Jukka Heinonen

Markus Amsler wrote: > There's a fundamental bug in winedos/dosvm. c[1]. SIGUSR2 is sent to the > current process, but it should be sent to the dosvm thread. This causes > various ugly bugs. > I found no way signaling a unix thread, without modifing the wineserver. > I have implemented a thread_kill command in the wineserver, this solves > my problem, but i'm quite sure it won't get applied. > > I'm really not a wineserver/threading expert. Have I missed something? Yep. If using Linux 2.6 kernel and recent pthread library, threads share the same pid and they must be signalled using tkill and not kill. The only place which knows how to correctly signal threads is send_thread_signal function in server/ptrace.c. So, the easy way to fix signalling is to use Windows thread identifier for identifying dosvm thread instead of pids (which don't work anyway) and add to wineserver a handler that just calls send_thread_signal, which I guess is what you have been doing, anyway. Now, I have tried this approach and it seems to work. I have some prototype implementation lying around but I was thinking about doing something more complicated at the time, like using SIGUSR2 handler for doing Win32 remote operations discussed earlier on wine-devel, because signal handler is probably running in the correct context for doing this kind of things but I guess locking issues are going to be pretty complicated so it is probably better to just fix dosvm issues with a simple mechanism and not worry about anything else. So, feel free to submit a patch, if it is simple enough it should get accepted or at least you should get some suggestions how to change the patch in order for it to get accepted. -- Jukka Heinonen <http://www.iki.fi/jhei>

Oct. 29, 2004

Re: USER32: add a short test for child windows

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > ChangeLog: > * add a short test for child windows Could you please merge it with existing win.c tests? -- Dmitry.

Oct. 29, 2004

Re: Success Stories?

by Brian Vincent

On Thu, 28 Oct 2004 16:58:25 -0700 (PDT), M-Halo <masochisthalo(a)yahoo.com> wrote: > I'd be happy to start pulling something together! I > don't know how soon I can have something done, but I > can definately start brainstorming something in my > head, Google around for other stories, and find a way > to invite others to share theirs. Excellent! You can find quite a few resources out there. Perhaps check past issues of the Wine Weekly News and scan the first section usually labeled "News:". > Are you the web developer for the WineHQ site? (I'm a > web developer [client-side], but I'm not a user of > CVS.) :) Not really the web developer (that would be Jeremy Newman), more of a propaganda coordinator. As far as this goes, feel free to send me plain text or even something marked up and I'll add. Or, just send it to wine-patches @ winehq.org. > P.S. I know I can't be committed to this as the owner, > but I can definately do this as a short-term project > to get the ball-rolling. :) No problem. This is something that won't require much updating, so it's a nice contained project. -Brian

Oct. 29, 2004