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

Re: Print warning when drives of type cdrom do not contain a device field

by Mike Hearn

On Wed, 2004-01-21 at 23:18, Alexandre Julliard wrote: > We obviously can't print warnings on the console for every config > parameter that might be wrong. That's a job for winecheck. OK. Is there a reason this isn't autodetected anyway, or is that coming up in Erics rewrite?

Jan. 21, 2004

Re: Print warning when drives of type cdrom do not contain a device field

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > OK, so I forgot the changelog entry. Apart from that, any reason this > patch bounced? We obviously can't print warnings on the console for every config parameter that might be wrong. That's a job for winecheck. -- Alexandre Julliard julliard(a)winehq.com

Jan. 21, 2004

Re: Print warning when drives of type cdrom do not contain a device field

by Mike Hearn

OK, so I forgot the changelog entry. Apart from that, any reason this patch bounced? On Tue, 13 Jan 2004 19:11:17 +0000, Mike Hearn wrote: > I wasted half and hour tracing through the cdrom subsystem to find out why > halflife wasn't playing any music, only to find it was a config file > problem. Maybe this message can stop other people from making the same > mistake. > > Index: files/drive.c > =================================================================== > RCS file: /home/wine/wine/files/drive.c,v > retrieving revision 1.104 > diff -u -r1.104 drive.c > --- files/drive.c 25 Nov 2003 01:51:07 -0000 1.104 > +++ files/drive.c 13 Jan 2004 19:01:13 -0000 > @@ -338,7 +338,9 @@ > close(cd_fd); > } > } > - } > + } else if (drive->type == DRIVE_CDROM) { > + MESSAGE("\n* You have a CD-ROM drive defined in your configuration, but it is missing the Device key.\n* Playing CD audio and direct access will not work.\n\n"); > + } > > /* Get the FailReadOnly flag */ > RtlInitUnicodeString( &nameW, FailReadOnlyW );

Jan. 21, 2004

Re: wine cvs notes and proposed keyboard detection fix.

by Shane Shields

On Wednesday 21 January 2004 9:03 am, you wrote: > > I have done that and piped the output to a logfile. Attached is an > > abbreviated version with just the icelandic and turkish detection > > included. It seems to be mismatching on detecting the third keysym where > > the key is defined in /etc/X11/xkb/symbols/tr this could be a clue :) > > 15 mismatches per layout is too much. Isn't it? I dont know, is it? :) I would have thought that for a turkish keyboard (or any language and the appropriate definition for that matter) should have no mismatches. It is even stranger that a different layout gets a higher score and gets chosen instead. Eg. For a Turkish keyboard. trace:keyboard:X11DRV_KEYBOARD_DetectLayout Attempting to match against "Icelandic keyboard layout" trace:keyboard:X11DRV_KEYBOARD_DetectLayout matches=39, mismatches=9, seq=36, score=42 trace:keyboard:X11DRV_KEYBOARD_DetectLayout Attempting to match against "Turkish keyboard layout" trace:keyboard:X11DRV_KEYBOARD_DetectLayout matches=33, mismatches=15, seq=33, score=6 Thats what I would like to fix if noone wants to. I just need to make sure I understand the code properly. As you know I supplied a patch that produced the correct result whereas you said. "The patch is wrong, since it cures just a symptom not the problem itself. There are two problems with current x11drv keyboard code: 1. Very likely that Turkish keyboard layout there is incorrect. 2. As stated before the keyboard code should be fixed to take into account the real keyboard layout while building the keyc2vkey map, not the hardcoded one." I have verified that (No. 1) the Turkish keyboard layout is correct so I am now trying to work on No. 2. > > > TRACE_(key)("mismatch for keysym 0x%04lX, keycode %d, > > > > in function X11DRV_KEYBOARD_DetectLayout where it should be > > > > TRACE_(key)("mismatch for keysym 0x%08lX, keycode %d, > > 0x%04lX doesn't mean a truncation to 4 characters in format. I just checked my books and I confused C's printf and C++'s stream formatting. I should sleep more and get more CCCCC's :). > > > > ckey[i] = keysym & 0xFF; > > This piece of code gets executed only if XKB is disabled or couldn't > translate keysym to a character. And according to the piped output it is not going there either so I am at a loss for the moment. What I have been doing so far is compiling cvs as an rpm and installing it that way. Is it possible to compile and test without actually installing wine? And when a change is made to just compile and link the relevent section? At the moment whenever I want to test something it is a two hour compile and install just to check a two minute change. I also want to be able to step through the code too. -- Shane Shields Registered LFS Compiler: 7582 To drink the WINE of success you must first seek the sayings of source Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.

Jan. 21, 2004

Re: revised dsound mmap mapping patch

by Alexandre Julliard

Robert Reif <reif(a)earthlink.net> writes: > Moves dsound mmap mapping info into dsound objects. This is causing a test failure for me: dsound.c:340: Test failed: SetFormat failed: 0x8878000a -- Alexandre Julliard julliard(a)winehq.com

Jan. 21, 2004

Re: WINMM problem with Half-Life

by Mike McCormack

Mike McCormack wrote: > > Eric Pouech wrote: > >>> Any ideas? >> >> >> as an ugly hack, does setting the dwEventCount in the WINE_MCIAVI >> struct as volatile help ? (private_mciavi.h). > > > No, that didn't help, the one below does: Well, it sort of does... but with that patch, sometimes westuck in the critical section. I guess the question is why does dwEventCount count further than expected? Mike

Jan. 21, 2004

Re: RFC on our new initiative

by Jeremy Newman

On Wed, 2004-01-21 at 10:55, Gregory M. Turner wrote: > Looks great to me; although there are not any discussions yet (or are there?) > in the "forums" area to demonstrate the quality of the forum interface, if > it's something along the lines of phpBB, then it's perfect. It's hard to compete with a package that has had years of devel like phpBB, but I will be expanding the forums as time goes on. I'm currently working on a moderation system for it. Right now, as they stand, the forums I am using here are only slightly better than the WineHQ version. I did add prev/next links when more than 50 posts are displayed. And I added the goofy profile icons everyone seems to like so much. > As for wine vs Crossover -- I presume that "plain old wine" users are welcome > to participate? If so, then there really isn't a problem. As long as they are talking about usage under CrossOver. We really don't want to confuse our customers. > One layout nit: the images on the top don't line up right in Konqy 3.1.5. I recently updated the site to W3C HTML 4 compliance, but in doing so it broke how it displays in Konq. Ugh. Why bother being compliant if it breaks on some browsers out there. -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

Jan. 21, 2004

Re: RFC on our new initiative

by Gregory M. Turner

On Tuesday 20 January 2004 08:05 am, Jeremy Newman wrote: > From the desk of Jeremy White (who is at LinuxWorld ATM). > > Hey folks, > > We've just launched a major new initiative, the > CodeWeavers CrossOver Compatibility Center. > > You can check it out at > http://www.codeweavers.com/site/compatibility/ > but I think it's fair to describe it as the appdb > on steroids. Looks great to me; although there are not any discussions yet (or are there?) in the "forums" area to demonstrate the quality of the forum interface, if it's something along the lines of phpBB, then it's perfect. In my mind, the appdb is great, but better, threaded, discussion areas were needed for people to really get serious about it. As for wine vs Crossover -- I presume that "plain old wine" users are welcome to participate? If so, then there really isn't a problem. One layout nit: the images on the top don't line up right in Konqy 3.1.5. Looks pretty interesting, I hope it catches on. -- gmt "In accordance with the GPL, the source for pogo is available upon request, for a nominal fee to cover media and shipping costs.* "* = The source code will be provided to you as a series of large, neon-lit marquee letters shipped individually in wooden packing crates. Currently, the world's supply of neon gas limits our ability to ship large quantities of source code. The current expected wait time is 32 years, plus or minus 6 months, depending upon the condition of labor relations in countries with substantial noble gas exports. "For more information, please inject crystal meth directly into your eyeballs, and light yourself on fire while listening to the following song: "xmms http://www.ibiblio.org/propaganda/pogo/easteregg.mp3" -- the pogo README, presumably written by Bowie J. Poag

Jan. 21, 2004

Stack limit error in newest release (not in olders)

by Anssi Hannula

When I run mircstats.exe, I get the following error: err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. This didn't happen on older releases. What does this error message mean? The newest release also segfaulted, before I turned overcommit on. -- Anssi

Jan. 21, 2004

Re: [ddraw] asynchronous screen updates

by Piotr Pawłow

On Wednesday 21 January 2004 12:53, Mike Hearn wrote: > Metacity is normally a good barometer of whether we got WM stuff correct. > What errors do you see exactly? Are we created unmanaged windows here, or > are they managed but with screwed up NETWM attributes? Metacity displays two messages: #v+ Window manager warning: Window 0x3200004 (Warlords B) sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense. Window manager warning: Window 0x3400009 () sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense. #v- With metacity the game starts, main screen appears for one second, then disappears and the screen remains black. The game is running, I can hear sounds when I move the mouse, I can push buttons and exit the game, but I don't see anything. I can't switch windows with alt-tab. There is no music. KWin does not say anything when I start the game. Main screen appears and does not disappear. Music plays. I can start and play the game, switching windows with alt-tab works, but when I switch to another window I can't go back. KWin says: #v+ kwin: Raising: No support kwin: Raising: Refusing #v- The game halts and music stops when I switch to another window, then when I switch back music starts playing again, but the window does not show up. I created 3 logs with --debugmsg +x11drv: http://pp.siedziba.pl/tmp/wb/wb+x11drv-metacity.log - start the game and exit http://pp.siedziba.pl/tmp/wb/wb+x11drv-kwin.log - as above, with kwin http://pp.siedziba.pl/tmp/wb/wb+x11drv-kwin-switching_windows.log - start the game and switch windows 2 times I don't understand much from these logs, but maybe you or someone else can spot a problem. One thing I noticed, is that with metacity the game does not draw anything, which is indicated by the lack of "fixme:ddraw:Main_DirectDraw_WaitForVerticalBlank" messages. I rerun the test with +bitblt to make sure. I guess the game thinks its window is inactive. -- Piotr Pawłow mailto:pp(a)siedziba.pl

Jan. 21, 2004

Re: control/numeric pad/alt keys

by Vik

Sorry Please ignore my last message. It was a problem on my side, which had nothing to do with wine. Cheers Vik > Just noticed that control + whatever keycombination stopped working in > head. Numeric Pad and Alt key combinations seems to be dead as well. > > Wondering if it's just me with my jp106 keyboard, or if anybody else has > the same problem... -- ------------ Vikram Kumar vik(a)zone81.com "Let the dogs bark, Sancho, it's a sign we're going in the right direction." -- Don Quixote

Jan. 21, 2004

control/numeric pad/alt keys

by Vik

Hi, Just noticed that control + whatever keycombination stopped working in head. Numeric Pad and Alt key combinations seems to be dead as well. Wondering if it's just me with my jp106 keyboard, or if anybody else has the same problem... Cheers Vik Here's the trace of --debugmsg +key notepad.exe when I pressed "ctrl + o". Instead of opening the file open dialog, it just outputs 'o' in the notepad window. trace:key:X11DRV_KeyEvent type 2, window 3400006, state 0x0004, keycode 0x0020 trace:key:X11DRV_KeyEvent state = 4 nbyte = 1, status 0x4 trace:key:X11DRV_KeyEvent KeyPress : keysym=6F (o), # of chars=1 / 0x0f / '^O' trace:key:EVENT_event_to_vkey e->keycode = 20 trace:key:X11DRV_KeyEvent keycode 0x20 converted to vkey 0x4f trace:key:X11DRV_KeyEvent bScan = 0x18. trace:key:queue_kbd_event wParam=004f, lParam=00180001, InputKeyState=81 trace:key:TranslateMessage (WM_KEYDOWN, 004F, 00180001) trace:key:TranslateMessage Translating key VK_O (004f), scancode 18 trace:key:X11DRV_ToUnicodeEx (004F, 0018) : faked state = 0x0000 trace:key:EVENT_event_to_vkey e->keycode = 20 trace:key:X11DRV_ToUnicodeEx type 2, window 3400006, state 0x0000, keycode 0x0020 trace:key:X11DRV_ToUnicodeEx Translating char 0x6f to unicode trace:key:X11DRV_ToUnicodeEx ToUnicode about to return 1 with char 6f trace:key:TranslateMessage 1 -> PostMessageW(0x10022,WM_CHAR,006f,00180001) trace:key:TranslateMessage (WM_CHAR, 006F, 00180001) trace:key:X11DRV_KeyEvent type 3, window 3400006, state 0x0004, keycode 0x0020 trace:key:X11DRV_KeyEvent state = 4 nbyte = 0, status 0x1 trace:key:X11DRV_KeyEvent KeyRelease : keysym=0 (No Name), # of chars=0 / 0x00 / '' trace:key:EVENT_event_to_vkey e->keycode = 20 trace:key:X11DRV_KeyEvent keycode 0x20 converted to vkey 0x4f trace:key:X11DRV_KeyEvent bScan = 0x18. trace:key:queue_kbd_event wParam=004f, lParam=c0180001, InputKeyState=1 trace:key:TranslateMessage (WM_KEYUP, 004F, C0180001) trace:key:X11DRV_KeyEvent type 3, window 3400006, state 0x0004, keycode 0x0042 trace:key:X11DRV_KeyEvent state = 4 nbyte = 0, status 0x1 trace:key:X11DRV_KeyEvent KeyRelease : keysym=0 (No Name), # of chars=0 / 0x00 / '' trace:key:EVENT_event_to_vkey e->keycode = 42 trace:key:X11DRV_KeyEvent keycode 0x42 converted to vkey 0x11 trace:key:X11DRV_KeyEvent bScan = 0x1d. trace:key:queue_kbd_event wParam=0011, lParam=c01d0001, InputKeyState=0 trace:key:TranslateMessage (WM_KEYUP, 0011, C01D0001) -- ------------ Vikram Kumar vik(a)zone81.com "Let the dogs bark, Sancho, it's a sign we're going in the right direction." -- Don Quixote

Jan. 21, 2004

Re: [ddraw] asynchronous screen updates

by Mike Hearn

On Wed, 21 Jan 2004 06:36:09 +0100, Piotr Pawlow wrote: > windows managers (kwin > cannot raise the window, metacity complains that the window attributes do not > make sense). Metacity is normally a good barometer of whether we got WM stuff correct. What errors do you see exactly? Are we created unmanaged windows here, or are they managed but with screwed up NETWM attributes?

Jan. 21, 2004

Re: charset related compilation errors in authors.c

by Hans Leidekker

On Wednesday 21 January 2004 03:12, jds wrote: > The variable value is: > [root(a)toshiba root]# echo $LANG > en_US.UTF-8 If you can't update Wine to latest cvs or wait 'till the next release you can do: EXPORT LANG=C; make to get around the problem. -Hans

Jan. 21, 2004

Re: RFC on our new initiative

by Rein Klazes

On Wed, 21 Jan 2004 09:36:02 +0000, you wrote: > > Output attached, a graph produced with gnumeric is on > > http://home.wanadoo.nl/~wijn/wine/cvs.png > > Hmm, there doesn't seem to be any particular trend upwards, does there, > except perhaps a slight one towards the end. 1998 was a busy year, I > wonder what was going on then. > Looking through the email list, you may as well forget the first data point (October 1998). CVS did then send several messages for the same commit, I did include a "sort|uniq" in the script to prevent doubles, but these have slightly different send date/time's. November and later should be OK At the time Corel was actively involved in Wine development, that might account for the activity that you observe. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Jan. 21, 2004

Re: RFC on our new initiative

by Mike Hearn

> Output attached, a graph produced with gnumeric is on > http://home.wanadoo.nl/~wijn/wine/cvs.png Hmm, there doesn't seem to be any particular trend upwards, does there, except perhaps a slight one towards the end. 1998 was a busy year, I wonder what was going on then.

Jan. 21, 2004

Re: RFC on our new initiative

by Rein Klazes

On Tue, 20 Jan 2004 20:24:54 +0000, you wrote: > > and where we've come to from there, and I think it's doable. > > I think it's particularly doable if Desktop Linux continues to > > accelerate and we get a bunch more help to make it happen... > > Ah yes, exponentially scalable growth. Let's hope so. Graphs of cvs > commits/patch sizes would be neat. I might stick that on my (long) todo > list :) A quick awk script on my cvs in box produced monthly number of cvs commits. That includes the commits to winehq. Output attached, a graph produced with gnumeric is on http://home.wanadoo.nl/~wijn/wine/cvs.png Rein. -- Rein Klazes rklazes(a)xs4all.nl

Jan. 21, 2004

UXTHEME regression [was Re: install problems IE with fresh winehq wine-20031212-1fc1winehq.i686.rpm]

by Mike Hearn

On Wed, 2004-01-21 at 06:57, jds wrote: > 0x40fc2453 (UXTHEME.DLL.GetThemeSysString+0x4e3 in UXTHEME.DLL): incl 0x0(%esi) > Wine-dbg>quit A large UXTHEME update was committed in the last few days. It appears this causes the IE installer to crash. I'm currently bogged down with exams, it'll go on my list of regressions to track down and nail, but may take a few days or weeks, depending on how things go here. For now I'd suggest using 20031212, CVS is highly unstable and iesetup regresses all the time at the moment. I've copied this one to wine-devel as well so Kevin can see the crash. thanks -mike

Jan. 21, 2004

Re: Variant tests

by Sylvain Petreolle

Jon, > Sylvain, can you apply the attached patch and send me the full output of > running the 2 tests? I can't duplicate the failures you are seeing with any > oleaut32 version here, but testing with a really really old version lead to > some changes that may help. These failures were given by the current oleaut32 CVS. (not by a real Windows box!) Now with this patch applied (updating CVS), I get : - no failure for vartest - 24 failures for vartype. (logs attached) ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "You believe it's the year 1984, when in fact, its closer to 2184"1984 / Matrix _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 21, 2004

Re: RFC on our new initiative

by Boaz Harrosh

Steven Edwards wrote: >.....depends on what happens at Wineconf..... > > > >PS. The goal 95% of all Windows apps on crossover is nice but I am >afraid I am seeing more and more .Nyet apps out in the real world. For >this to happen anytime soon we have to get on the ball with Mono and Windows.Forms. > > Jeremy Did any one contact Xaim to see if they can send any MONO people to wineconf? Is there any vision on how these 2 integrate? I haven't even touched MONO yet (& .NET for that mater), but from the look of it they better use wine for some areas of .NET. Like .Forms. And certainly Wine Loader should have an hook ready for sending .NET code the MONO way. Free Life Boaz

Jan. 21, 2004

Re: wine cvs notes and proposed keyboard detection fix.

by Dmitry Timoshkov

"Shane Shields" <locutusenterprises(a)softhome.net> wrote: > > X11 team tends to remove more than 2 characters per keysym. See > > /etc/X11/xkb/symbols/tr. Turkish keyboard layout in Wine has more > > than 2 for some of them. Just do 'setxkbmap tr' and run Wine with > > +key,keyboard,+x11drv and look for mismatches. > > I have done that and piped the output to a logfile. Attached is an abbreviated > version with just the icelandic and turkish detection included. It seems to > be mismatching on detecting the third keysym where the key is defined > in /etc/X11/xkb/symbols/tr this could be a clue :) 15 mismatches per layout is too much. Isn't it? > TRACE_(key)("mismatch for keysym 0x%04lX, keycode %d, > > in function X11DRV_KEYBOARD_DetectLayout where it should be > > TRACE_(key)("mismatch for keysym 0x%08lX, keycode %d, 0x%04lX doesn't mean a truncation to 4 characters in format. > or my version of X11 is returning a larger value than it should. I suspect > this because of the large amount of calls to the function > KEYBOARD_MapDeadKeysym. Maybe the X11 guys have changed a short to a long > somewhere in my version of X11 (cvs 2003-11-24) or my gcc (3.2.2) has defined > them differently. If that is the case then the line > > ckey[i] = keysym & 0xFF; This piece of code gets executed only if XKB is disabled or couldn't translate keysym to a character. -- Dmitry.

Jan. 21, 2004

[ddraw] asynchronous screen updates

by Piotr Pawlow

If DGA is not available, Wine falls back to creating offscreen primary surface and blitting all changes to the screen. It knows which part of the surface might have changed by watching unlock calls. However, as Jukka Heinonen pointed out in his message posted on 17.10.2001, the update logic in asynchronous mode (when SYNC_UPDATE is not defined, which is the default) is broken: "(...)if more than one lock/unlock pair happens between update thread blits, display might not be updated correctly". Synchronous mode on the other hand, causes applications, which constantly lock and unlock big areas just to change a few pixels, run very slow. As this bug prevents me from playing "Warlords: Battlecry", I decided to do something about it. Here are my changes: - User_add_dirty_rect is now an asynchronous equivalent of User_copy_to_screen. It adds the rectangle to the list of dirty rectangles and signal the update thread that there is some work to do. - update thread calls User_get_dirty_rect to iterate over the list of dirty rectangles - current "naïve" algoritm keeps only one rectangle which is a union of all dirty rectangles, so it tends to redraw too much, but better algoritms may be implemented - removed now unused lastlockrect variable, and the code which updates it I attached the patch for your reviews, comments, suggestions. The game is almost playable now, there are remaining issues with DirectMusic (must be run with NODIRECTMUSIC switch or crashes) and windows managers (kwin cannot raise the window, metacity complains that the window attributes do not make sense). -- Piotr Pawlow mailto:pp(a)siedziba.pl

Jan. 21, 2004

Re: GetCommandLine issue with Dungeon Keeper

by Duane Clark

Frank Schruefer wrote: > ( > REPOST, again: I was told that my massages need long time to appear because > I'm not subscribed as frank.schruefer(a)t-online.de, ok, but my postings as > wine(a)man-made.de (which I'm subscribed as) never come through. > Maybe that is because mozilla only allows configuration for one outgoing > mailserver which is the t-online one? > Anything I could do about the situation? > ) Oops, I should have answered the last question. A simple fix would be to also subscribe the address frank.schruefer(a).... Since I assume you just don't want postings sent there, once you subscribe, go to your subscription settings web page: http://www.winehq.org/mailman/options/wine-devel/frank.schruefer ... (it should be listed in the welcome email you receive) and turn on "Disable mail delivery". There is no problem subscribing multiple email addresses.

Jan. 21, 2004

Re: GetCommandLine issue with Dungeon Keeper

by Duane Clark

Frank Schruefer wrote: > ( > REPOST, again: I was told that my massages need long time to appear because > I'm not subscribed as frank.schruefer(a)t-online.de, ok, but my postings as > wine(a)man-made.de (which I'm subscribed as) never come through. > Maybe that is because mozilla only allows configuration for one outgoing > mailserver which is the t-online one? > Anything I could do about the situation? > ) I never saw any postings as wine(a)man-made.de in the moderation queue. So something else must be wrong. The outgoing smtp server should make no difference. Maybe Jeremy can check his logs to see if anything is there (I don't have access to those). The lists have recently implemented spam blocking (yea!), so hopefully you were not classified as a spammer ;) A bit off topic... with any reasonably current Mozilla you can have different outgoing servers for different accounts. In the outgoing server settings, click the "Advanced" button to configure them. In the individual accounts, in server settings, click the Advanced button to select the desired outgoing server for that account.

Jan. 21, 2004

Re: Variant tests

by Dmitry Timoshkov

"Jon Griffiths" <jon_p_griffiths(a)yahoo.com> wrote: > Dmitry, this should fix the test failing on your Win2K box also. If > it doesn't please let me know. A failure I reported is fixed now. Thanks! -- Dmitry.

Jan. 21, 2004