April 2002 - Wine-Devel - list.winehq.org

Re: Installing MS Office gives error in installer

by Speeddymon

Well, I did use crossover office last night and everything turned out beautifully. Hell when I used that it also helped me (indirectly) to find the icon for loki's port of unreal tournament, so i now have that in my kde menu. what i was saying before though was that the windows link files (.lnk extension) weren't being put into the kde menu, i believe it is a bug/problem in 20020411 wine mainly due to that fact that that wine wouldn't install the icons but crossover office wine would...who knows, all is well now on my computer though. thanks for the help guys. --- Hetz Ben Hamo <hetz(a)kde.org> wrote: > On Monday 22 April 2002 23:48, Speeddymon wrote: > > no, in the installer its the .lnk files (windows > link > > files) that aren't being copied from the cd (or > being > > converted to .desktop files) or something at any > rate > > tho, they never showed up in my kde menu or on my > > desktop... so theres probably a problem in wine > > somewhere. I will try crossover office tonight to > see > > if it installs the files or not... and post back > > tomorrow > > Check it on your .kde directory - they should be > there. I'm running crossover > office and they're appearing quite well. > > Thanks, > Hetz __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/

April 23, 2002

New Winsock2 patch series - now tested

by Martin Wilck

Hi, I will now start to submit a new series of patches for Winsock2-related issues. Most of it is for overlapped IO, but there are some other issues, too. I have done a fair bit of testing with 16 and 32 bit network-oriented Windows apps, and found no regressions (well some apps wouldn't install or run with either the CVS version or my patched version of wine). Among the tested apps are - Opera (v5.12, 32bit, and 3.62, 16bit) - FreeAgent (news reader, 16bit) - Solstice Internet Mail (16bit) - Hamster local news server (32bit, interesting because it's using ReadFile()/WriteFile() for overlapped socket IO) - My evil overlapped testing server/client app I spotted a number of bugs with the "big" patch I sent to wine-devel last Friday. These are fixed in the version I'll submit now. The patch is now split into parts again (one bug fix for an earlier patch of mine that is already in CVS, and 7 "real" parts). Most of the testing has of course been done with the full patch set applied. I have tried to separate logically independent units, but I cannot swear that all is fine if only part of them is applied, and the later patches do fix some important problems. The main reason for splitting the stuff up is to make it easier for people to review. I honestly think that these patches are now ready for being applied to CVS and tested in the field. Here is the overall patch summary (for detailed explanantions see the patches thenmselves): - Correct handling of deferred WSAAccept() operations, - Change register_async() and the queue_async() method to allow more flexibility, needed for sockets, - Server support for overlapped IO on sockets, - Fix problem with FD_CLOSE never being delivered in some situations, - Wait for POLLIN if FD_CLOSE event notification is requested to catch grateful close or shutdown by the peer (empty recv(), no POLLHUP), - Implement overlapped WSARecvFrom()/WSASendTo() and WSAGetOverlappedResult(), - Change shutdown() to account for pending overlapped requests, - Change ReadFile() semantics for overlapped reads on sockets (return even if buffer is not yet full), - Improve error reporting for asynchronous requests (files and sockets) - Account for the SO_OPENTYPE socket option on a per-thread basis. I plan to look into the regression-testing code and also supply a few tests for the new socket functionality. Cheers (and please test this stuff with your apps!), Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 23, 2002

Re: toolbar.c problem

by Duane Clark

Rick Romero wrote: > I hope it's not a coincidence, but unfortunately I don't know how you > got to the point you did to fix it :) Wasn't easy for someone with as little wine experience as me, that's for sure :-) Basically, fpga_editor actually had two different toolbars. The main one did not work, but some sub-windows had a toolbar that did work. So I traced the application in both cases, and compared what was different. The difference was as I mentioned in the posting you linked to, regarding the call of ReleaseCapture(). I could tell from the return addresses in the traces that ReleaseCapture() was being called directly by the application in the broken case, immediately before TOOLBAR_LButtonUp(), but by wine in the working case. From that point, it was a matter duplicating the procedure in a more controlled environment. I had just recently figured how to use ControlSpy (for some listview bugs), and that turned out to be an ideal testbed for this too.

April 23, 2002

internet explorer regression

by Michael Cardenas

I just picked up the latest cvs and some time in the last 3 weeks someone put in a patch that causes IE5 to crash when typing in an address in the address bar. I used office 2k pro to test. Also, windows media player can't install downloaded codecs, and it can in crossover office, but I'm not sure if that's a regression or an old bug. It complains about security settings. -- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi

April 23, 2002

Re: toolbar.c problem

by Rick Romero

On Tue, 2002-04-23 at 10:51, Duane Clark wrote: > Rick Romero wrote: > > > > Forgive the intrusion, but I've been watching your thread, because it > > sounds quite like bug # 434. > > http://bugs.codeweavers.com/long_list.cgi?buglist=434 > > My own feeling is that this probably is not related, because my patch > was pretty specific to mouse up events within the toolbar. The > WM_LBUTTONUP message that you refer to in this bug is sent from many > different routines, depending on where the mouse is in the app. > Also, this bug appears to be a problem of a missing mouse capture > release. In my case, the cursor was being released just fine. It was > just that the expected action was never invoked. >From what I understand some applications (MS VC++ apps) will make some of those calls directly. It appears that my app (MS Visual FoxPro) does this.. So I would assume that VFP itself is sending a LBUTTONUP call whether it's run from Wine or Win9x or Win2k. THEREFORE (caps to indicate massive assumption coming:) the problem is the action isn't invoked.. I support that assumption with my funky 'slowness' test (that nobody else can replicate - how appropriate). The action IS taken when the system is ungodly slow. <shrug> > > > > > I believe it was your toolbar.c patch that initially fixed the toolbar > > issues, but out of curiosity, before the patch, were you able to check > > if it was a regression? (Maybe back to 6/20/01?) I found your comments( > > http://www.winehq.com/hypermail/wine-devel/2002/03/0109.html ), but I > > didn't see any comments indicating a regression test. > > My memory of events that far back is vague, but my recollection is that > the toolbar problem with my two apps (fpga_editor and Designer) has been > there since I started using wine, about May 2000. There were indeed a > number of other regressions triggered by the June 2001 changes, so I do > remember that date fairly well ;) Yes, for that bug, it appears to be something with the wineserver. Maybe it's also releated to the server serialization issues another user posted. > > I think what you described is happening in other areas (see the bug), > > with other apps, but for your app, it only manifested in the toolbars. > > Possible, but I suspect just a coincidence. The TOOLBAR_LButtonUp() > routine should only be called very specifically when the mouse is in the > toolbar. It certainly is possible that there is a very similar problem > in another routine, though. I hope it's not a coincidence, but unfortunately I don't know how you got to the point you did to fix it :) Rick

April 23, 2002

Re:unit test (C) with WINAPIV function

by Eric Pouech

> ok ((wsprintfW (buf, fmt -1) == 10), "wsPrintfW length failure"); shouldn't it be wsprintfW (buf, fmt, -1) == 10 instead ? ^ | A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

April 23, 2002

Re: unit test (C) with WINAPIV function

by Francois Gouget

On Tue, 23 Apr 2002, Medland, Bill wrote: > Any chance of some help with this? > > Yesterday i submitted a unit test for wsprintfA. I didn't include wsprintfW > because I couldn't get it to work right. I still can't. I think it's > something to do with the calling convention (since wsprintf uses cdecl, not > stdcall). Here's the test code itself; > > static BOOL wsprintfWTest (void) > { > WCHAR buf[25]; > static const WCHAR fmt[] = {'%','0','1','0','l','d','\0'}; > WCHAR target[] = {'-','0','0','0','0','0','0','0','0','1'}; > > printf ("%p %p\n", buf, fmt); > ok ((wsprintfW (buf, fmt, -1) == 10), "wsPrintfW length failure"); ^ Would adding the above comma fix the problem? > ok ((lstrcmpW (buf, target) == 0), > "wsprintfW zero padded negative value failure\n"); > > return TRUE; > } [...] > Am I missing something obvious? Yes and no :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

April 23, 2002

Re: unit test (C) with WINAPIV function

by Huw D M Davies

On Tue, Apr 23, 2002 at 09:18:45AM -0700, Medland, Bill wrote: > Any chance of some help with this? > static BOOL wsprintfWTest (void) > { > WCHAR buf[25]; > static const WCHAR fmt[] = {'%','0','1','0','l','d','\0'}; > WCHAR target[] = {'-','0','0','0','0','0','0','0','0','1'}; target's not '\0' terminated. > printf ("%p %p\n", buf, fmt); > ok ((wsprintfW (buf, fmt -1) == 10), "wsPrintfW length failure"); missing a ',' between fmt and -1. > ok ((lstrcmpW (buf, target) == 0), > "wsprintfW zero padded negative value failure\n"); > > return TRUE; > } Huw.

April 23, 2002

RE: unit test (C) with WINAPIV function - sorry

by Medland, Bill

> -----Original Message----- > From: Medland, Bill [mailto:Bill.Medland(a)accpac.com] SNIP > ok ((wsprintfW (buf, fmt -1) == 10), "wsPrintfW length failure"); DUH! > Am I missing something obvious? Yes Bill

April 23, 2002

unit test (C) with WINAPIV function

by Medland, Bill

Any chance of some help with this? Yesterday i submitted a unit test for wsprintfA. I didn't include wsprintfW because I couldn't get it to work right. I still can't. I think it's something to do with the calling convention (since wsprintf uses cdecl, not stdcall). Here's the test code itself; static BOOL wsprintfWTest (void) { WCHAR buf[25]; static const WCHAR fmt[] = {'%','0','1','0','l','d','\0'}; WCHAR target[] = {'-','0','0','0','0','0','0','0','0','1'}; printf ("%p %p\n", buf, fmt); ok ((wsprintfW (buf, fmt -1) == 10), "wsPrintfW length failure"); ok ((lstrcmpW (buf, target) == 0), "wsprintfW zero padded negative value failure\n"); return TRUE; } but if I print the addresses of buf and fmt from within wsprintfW I get the same values for buf but for fmt I get a smaller pointer (0x401ecac instead of 0x401ecae) (and I can't figure out how to get at it in gdb to see exactly what is going on). Am I missing something obvious? Bill

April 23, 2002