Re: Screenshots
Here's a few game-esque contributions from myself: www.enderboi.com/winepics/ (sure sure, two of them are pretty redundant thanks to Native linux ports... but what the hell :) - Ender On Thu, 21 Nov 2002, Tony Lambregts wrote: Date: Thu, 21 Nov 2002 23:37:50 -0700 From: Tony Lambregts [EMAIL PROTECTED] To: Brian Vincent [EMAIL PROTECTED] Cc: Wine devel [EMAIL PROTECTED] Subject: Re: Screenshots Brian Vincent wrote: I've been meaning to put something together for a few days here.. shots to Brian isn't the best way to go about it as nobody knows who has sent what. Have you actually got any yet Brian? First, take a look at: http://www.theshell.com/~vinn/ss [snip] The following would be nice to see: any game This Game has only two minor bugs that keep it from being Platinum The first is that it needs to be run from its own directory (is that really a bug?) and the other is there is a screen for parents which is not accessable. Yes I (just) filed a bug report about it. http://bugs.winehq.com/show_bug.cgi?id=1162 I don't know if this is really sexy but I like the results. http://www.telusplanet.net/public/lambregt/LeapAheadPreschool.png All my other games have more serious bugs but I thought this one might qualify for Gold especially if The keyboard thing was cleared up. If you are interested these are a list of other games and their problems. Other games: Riven - Major screen corruption, Menu doesn't work. Myst - Hell I havent played it for so long I don't realy know whats wrong with it SimCity - Intro screen does not play, formatting of numbers wrong and lockup if you save while exiting (yes the linux verion works fine.) Other Kids games Curious George - medium screen coruption some sound problems An American Tail - sound locks up after movies (PITA} Operation - Major screen corruption. Carmen Sandiego Junior Detective - Won't start (just bought it) Some of these have bug reports but I guess I still have some bug reporting to do... -- Tony Lambregts
Re: wine/tools wineinstall
On Thu, Nov 21, 2002 at 01:19:42PM -0600, Dustin Navea wrote: I'm not totally sure that this should be done as my wine install comes with opengl disabled due to relying on libpthread for thread safety. If we remove the --enable-opengl from wineinstall FLC's will not know how to enable it... As far as I understood, OpenGL is enabled by default now whatever the thread safeness of your GL library... So it's no use to have an option specifically enabling it. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: winewrapper
Am Fre, 2002-11-22 um 00.41 schrieb Dimitrie O. Paun: If Wine was a mature, stable project, I'd agree with you. But it's not. The ability to make a small change in Wine, go back to the Winelib app, and test it, is invaluable. I would have simply given up debugging PuTTY f I had to go through a wine install for every little test and experiment I was making. For me it was quite ok to do a make install only in the dll subdirs where I had modified something. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Screenshots
Hi, On Thu, Nov 21, 2002 at 11:37:50PM -0700, Tony Lambregts wrote: [snip] Other games: Riven - Major screen corruption, Menu doesn't work. Myst - Hell I havent played it for so long I don't realy know whats wrong with it The last time i checked it (4-5 month ago) it worked just fine. I'll check it again. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg14509/pgp0.pgp Description: PGP signature
Re: winewrapper
On Fri, Nov 22, 2002 at 09:45:01AM +0100, Martin Wilck wrote: Am Fre, 2002-11-22 um 00.41 schrieb Dimitrie O. Paun: If Wine was a mature, stable project, I'd agree with you. But it's not. The ability to make a small change in Wine, go back to the Winelib app, and test it, is invaluable. I would have simply given up debugging PuTTY f I had to go through a wine install for every little test and experiment I was making. For me it was quite ok to do a make install only in the dll subdirs where I had modified something. aolme too/aol In the dlls subdirs i also normaly type make install instead of make. Ok, it's a word more to type but it was easier for me to using it in the natural way aka installing wine, then to figure it out how to run it directly from the sources. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg14510/pgp0.pgp Description: PGP signature
Re: wine and asyncronous file i/o
Hi Mike! What sort of file handle is the program trying to read from? Is it a serial port, a socket, a pipe or a standard file? -debugmsg +file,+comm,+server,+winsock should generate a good enough trace. Mike It's a standard file. I think, there's missing the error code in the OVERLAPPED structure on end of file. This is used to distinguish the end of the file in the library. I will take a look at this today evening. -- Martin Fuchs [EMAIL PROTECTED]
Interesting control samples
Hi, I just found http://www.codejock.com/, they seems to provide a Toolkit to enhance any app (giving Microsoft's new UI look), the most interesting for Wine is that you can download 40 basic samples of different controls. Few notes : - A quick test shows that Wine can't launch any exe. - No source code is included I thought it may be a good test case ... Here is the list of samples included in XTSetupSamples_1931.exe : AccelDemo.exe BrowseDialog.exe BrowseEdit.exe Button.exe CaptionBar.exe CheckListBox.exe ColorPicker.exe CommonControls.exe CoolMenu.exe DockingDemo.exe EditListBox.exe FlatCombo.exe FlatHeader.exe FlatTabCtrl.exe FlatTabView.exe GUI_Explorer.exe GUI_Outlook.exe GUI_VisualStudio.exe GUI_WinZip.exe HexEdit.exe HyperLink.exe ListCtrl.exe MaskEdit.exe MDITabWindows.exe MultiFrameDocking.exe OutlookBar.exe Pager.exe PrintPreview.exe SearchOptions.exe SplitterWindow.exe StatusBar.exe TabbedView.exe TabCtrlBar.exe TabCtrl.exe TipOfTheDay.exe TipWindow.exe TrayIconDemo.exe TrayIconDlg.exe TreeCtrl.exe WindowPos.exe Mehmet
Re: wine and asyncronous file i/o
Hi Martin,
I've attached the interesting section of the resulting trace file.
Maybe you see, what's going on.
The programs reads a file with 21517 bytes length.
After fetching five blocks of 4096 bytes correctly, it reads the remaining
1037 bytes. But it does not stop! It reads this last file block continuously.
EOF conditions are nasty. Seems we got it wrong... Please try the
following patch (it should solve your problem). However I guess it needs
regression testing because it changes overlapped ReadFile() semantics
drastically. If this condition turns out to be right, we may actually be
able to get rid of the special treatment of sockets in
FILE_AsyncReadService().
Martin
Index: files/file.c
===
RCS file: /home/wine/wine/files/file.c,v
retrieving revision 1.170
diff -u -r1.170 file.c
--- files/file.c21 Nov 2002 03:45:03 - 1.170
+++ files/file.c22 Nov 2002 11:00:47 -
@@ -1697,6 +1697,11 @@
r = FILE_GetNtStatus ();
goto async_end;
}
+else if ( result == 0 )
+{
+r = STATUS_END_OF_FILE;
+goto async_end;
+}
lpOverlapped-InternalHigh += result;
TRACE(read %d more bytes %ld/%d so
far\n,result,lpOverlapped-InternalHigh,fileio-count);
--
Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Screenshots
Brian Vincent wrote: First, take a look at: http://www.theshell.com/~vinn/ss Quite a few folks have sent stuff in. Now, after looking at so many screenshots and trying to evaluate them for content I've realized a few things.. 1) We're absolutely going to have to insist on 800x600 resolution. Thanks for all the ones so far, but really the only usable ones are the 800x600. (There are exceptions, such as Mike's Quicktime one that can be resized nicely.) 2) Screenshots of an application doing something are the way to go. For instance, the one Mike just sent me showing Adobe's SVG plug-in in IE is WAY cool. Unfortunately it's not usable because of the resolution. Even a pull-down menu being pulled down is enough. 3) Cluttered desktops suck. You don't need to have 3 terminal windows, Mozilla, and everything else in the background. For the most part I think the screenshots have followed that rule closely. Is there a reason I get a 403 error (Forbidden: You don't have permission to access /~vinn/ss/Rick_Romero/PegasusMail1.png on this server.) on all of Rick_Romero's submissions? Are they secret? Can I make a suggestion as well that complicated desktop background pictures are unhelpful ... they make the file a lot bigger without contributing anything. That said,for apps which you can run to occupy all available screen space this is not a problem. David
Debugging mouse messages
Hi, After setting up my dual crossover/winehq (last tarball release) installation, I tried doing some traces on IE with the adobe svg plugin. I can't figure out why I am getting this: trace:msg:MSG_peek_message got type 5 msg 113 hwnd 0 wp 8 lp 41380d58 trace:cursor:X11DRV_GetCursorPos pointer at (661,442) trace:msg:MSG_peek_message got type 5 msg 2a1 hwnd 10042 wp 0 lp 0 trace:msg:GetKeyState key (0x12) - 0 trace:msg:WINPROC_CallProc32ATo32W func 0x413e9024 (hwnd=00010039,msg=WM_USER+000b,wp=,lp=) over and over again when the mouse is not moving. It appears that IE (the constant polling for the cursor position occurs when showing a 404 screen too) has different mouse behaviour to other apps, for instance in WebFerret the X11DRIV_GetCursorPos function is only called when the mouse actually moves. In IE, it's called seemingly on a timer (i'd guess every .25 or .5 seconds) even when the cursor is over a toolbar (though not the address bar oddly). I'm also confused by the reference to WINPROC_CallProc32ATo32W, is this normal? Google says it's used as part of 32bit-16bit thunking, but there is no 16bit code here as far as I'm aware. Any ideas? thanks -mike -- Mike Hearn [EMAIL PROTECTED] QinetiQ
Re: Debugging mouse messages
I can't figure out why I am getting this: trace:msg:MSG_peek_message got type 5 msg 113 hwnd 0 wp 8 lp 41380d58 trace:cursor:X11DRV_GetCursorPos pointer at (661,442) trace:msg:MSG_peek_message got type 5 msg 2a1 hwnd 10042 wp 0 lp 0 trace:msg:GetKeyState key (0x12) - 0 trace:msg:WINPROC_CallProc32ATo32W func 0x413e9024 (hwnd=00010039,msg=WM_USER+000b,wp=,lp=) over and over again when the mouse is not moving. It appears that IE (the constant polling for the cursor position occurs when showing a 404 screen too) has different mouse behaviour to other apps, for instance in WebFerret the X11DRIV_GetCursorPos function is only called when the mouse actually moves. In IE, it's called seemingly on a timer (i'd guess every .25 or .5 seconds) even when the cursor is over a toolbar (though not the address bar oddly). If you look with Spy++ in Windows do you get the same? If not it's not IE itself but the combined behaviour of IE and Wine, each one retriggering somehow the other because of a different message behaviour. I also had to change my app as wine handled and sent some messages differently (different order of messages, different count...) which got me into a recursion that didn't happen on Windows. Of course I should have fixed wine. But as I'm not a message guru (and no one could help me) I had to change my app. bye Fabi
Re: Debugging mouse messages
Yes, I looked using Spy++ in Windows and it gets the WM_MOUSEHOVER messages, the log looks like this: 00010 00080288 P WM_MOUSEHOVER wParam: lParam:00C20034 point:(64, 350) 00011 00080288 P message:0x0118 [Unknown] wParam:FFFA lParam:BF87ACAB point:(64, 350) I don't really know how to read Spy++ traces, is the second message an undocumented one or something? Does Spy++ work under Wine? I'd guess probably not, but being able to restrict messages traces to particular windows (or sub windows) is really useful. thanks -mike On Fri, 2002-11-22 at 12:22, Fabian Cenedese wrote: I can't figure out why I am getting this: trace:msg:MSG_peek_message got type 5 msg 113 hwnd 0 wp 8 lp 41380d58 trace:cursor:X11DRV_GetCursorPos pointer at (661,442) trace:msg:MSG_peek_message got type 5 msg 2a1 hwnd 10042 wp 0 lp 0 trace:msg:GetKeyState key (0x12) - 0 trace:msg:WINPROC_CallProc32ATo32W func 0x413e9024 (hwnd=00010039,msg=WM_USER+000b,wp=,lp=) over and over again when the mouse is not moving. It appears that IE (the constant polling for the cursor position occurs when showing a 404 screen too) has different mouse behaviour to other apps, for instance in WebFerret the X11DRIV_GetCursorPos function is only called when the mouse actually moves. In IE, it's called seemingly on a timer (i'd guess every .25 or .5 seconds) even when the cursor is over a toolbar (though not the address bar oddly). If you look with Spy++ in Windows do you get the same? If not it's not IE itself but the combined behaviour of IE and Wine, each one retriggering somehow the other because of a different message behaviour. I also had to change my app as wine handled and sent some messages differently (different order of messages, different count...) which got me into a recursion that didn't happen on Windows. Of course I should have fixed wine. But as I'm not a message guru (and no one could help me) I had to change my app. bye Fabi -- Mike Hearn [EMAIL PROTECTED] QinetiQ
Re: Rosetta, wine, sound bug?
From: Sylvain Petreolle [EMAIL PROTECTED]
bash-2.05a$ wine -debugmsg +winmm,+wave,+dsound Rosetta.exe
trace:winmm:WINMM_LibMain 0x4163 0x1 (nil)
trace:winmm:WINMM_CreateIData Created IData (0x403f0ef8)
trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N);
trace:winmm:MMDRV_Install Got 32 bit func 'auxMessage'
trace:winmm:MMDRV_Install Got 32 bit func 'mixMessage'
trace:winmm:MMDRV_Install Got 32 bit func 'midMessage'
trace:winmm:MMDRV_Install Got 32 bit func 'modMessage'
trace:winmm:MMDRV_Install Got 32 bit func 'widMessage'
trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage'
trace:winmm:MMDRV_GetDescription32 Can't find file wineoss.drv
^^^
Shouldn't happen.
trace:winmm:MMDRV_Install wineoss.drv = No description
I get similar errors with MMDRV_GetDescription32. I assumed they
were happening because the actual file wineoss.drv does not exist.
Further, I assumed that MMDRV_GetDescription32 tries to get the
description from locating the relevant record in the actual file.
Please note that I have not had a chance to verify any of this.
I have just recently taken an interest in wine's sound libraries,
and would be glad to help out where I can.
-- Jeff S
_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
Menu selection algorithm
Hi list, Sorry if this is slightly off topic. I am having some trouble with a sample program I keep changing to death. This program is written in VC on Windows 2000, and being run on Wine as well. I added a Hebrew menu over an already existing English(US) one. My regional settings say that my global settings are Hebrew, as are my local settings. The two menus both have the same ID, and only the language is different between them. When VC's resource editor displays the menus, it displays one with (English U.S) appended, and the Hebrew one without any extension (implying it thinks this is the default one). So, what's the problem - you ask? While my view of what should happen is obviously consistant with that of Wine's - i.e. - the locale should select which menu to use, Windows displays the English locale ONLY. The only way I could make it display the Hebrew one was by changing the language on the English one to something else (French). Wine behaves as expected. running: wine TestApp Yields an english menu, while LANG=he_IL wine TestApp yields a Hebrew one. I wouldn't worry so much, except that since we define a bug in Wine as any inconsistancy with Windows, this is a bug. I'm mostly trying to understand why Windows won't do what it's supposed to do, however. I'm using RegisterClass to register a class with the menu identifier passed using MAKEINTRESOURCE, and then just calling CreateWindow to create the window. Anyone has any ideas or suggestions, or just an opinion whether that should worry us at all? Shachar
Re: Debugging mouse messages
Well, I'm feeling rather pleased with myself, I found one of the bugs :) line 970 of windows/input.c is this: PostMessageA(TrackingList[i].tme.hwndTrack, WM_MOUSEHOVER, 0, 0); when it should actually be PostMessageA(TrackingList[i].tme.hwndTrack, WM_MOUSEHOVER, 0, (pos.y 8) + (pos.x)); That doesn't supply the keyboard state correctly of course, which should be in wParam, but i don't know if I'll be able to fix it all, especially as ASV seems to have suddenly got a lot more choosy about when it'll render things. On Fri, 2002-11-22 at 14:09, Mike Hearn wrote: Yes, I looked using Spy++ in Windows and it gets the WM_MOUSEHOVER messages, the log looks like this: 00010 00080288 P WM_MOUSEHOVER wParam: lParam:00C20034 point:(64, 350) 00011 00080288 P message:0x0118 [Unknown] wParam:FFFA lParam:BF87ACAB point:(64, 350) I don't really know how to read Spy++ traces, is the second message an undocumented one or something? Does Spy++ work under Wine? I'd guess probably not, but being able to restrict messages traces to particular windows (or sub windows) is really useful. thanks -mike On Fri, 2002-11-22 at 12:22, Fabian Cenedese wrote: I can't figure out why I am getting this: trace:msg:MSG_peek_message got type 5 msg 113 hwnd 0 wp 8 lp 41380d58 trace:cursor:X11DRV_GetCursorPos pointer at (661,442) trace:msg:MSG_peek_message got type 5 msg 2a1 hwnd 10042 wp 0 lp 0 trace:msg:GetKeyState key (0x12) - 0 trace:msg:WINPROC_CallProc32ATo32W func 0x413e9024 (hwnd=00010039,msg=WM_USER+000b,wp=,lp=) over and over again when the mouse is not moving. It appears that IE (the constant polling for the cursor position occurs when showing a 404 screen too) has different mouse behaviour to other apps, for instance in WebFerret the X11DRIV_GetCursorPos function is only called when the mouse actually moves. In IE, it's called seemingly on a timer (i'd guess every .25 or .5 seconds) even when the cursor is over a toolbar (though not the address bar oddly). If you look with Spy++ in Windows do you get the same? If not it's not IE itself but the combined behaviour of IE and Wine, each one retriggering somehow the other because of a different message behaviour. I also had to change my app as wine handled and sent some messages differently (different order of messages, different count...) which got me into a recursion that didn't happen on Windows. Of course I should have fixed wine. But as I'm not a message guru (and no one could help me) I had to change my app. bye Fabi -- Mike Hearn [EMAIL PROTECTED] QinetiQ
Re: wm_mousehover bug fix.....
- Original Message - From: Mike Hearn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 22, 2002 9:32 AM Subject: wm_mousehover bug fix. Sorry to kind of spam, it was much easier to fix it than I thought it would be. Hacking wine isn't so hard after all.. Never is.. ;) input.c line 970 should be: PostMessageA(TrackingList[i].tme.hwndTrack, WM_MOUSEHOVER, get_key_state() , (pos.y 8) + (pos.x)); I didn't think it was worth sending to wine-patches as it's just a 1 line fix and I didn't do it against wine cvs, but the last tarball release. That solves all my mouse handling issues with the ASV, so I'm a happy person once more. If somebody could apply that patch that'd be fab. usually 1-liners are easier to get committed to CVS than big patches, and Alexandre will commit patches against the latest tarball instead of the latest CVS, as not everyone has the kind of time/connection to be able to get the latest CVS. At one point, I had to do the same, submit patches from the latest tarball... Go ahead and send it to wine-patches, and see what people say. -Dustin
Re: winspool.drv again
The winspool.drv issue is a lot more serious than the in-tree execution. This one screws things up badly for the PuTTY build system. Should we modify winebuild to try to link with winspool.drv, and if that fails with winspool.dll when -lwinspool is given? (or the other way around, I don't know) The right approach would be to implement import libraries. This is already on my TODO list, I'll bump the priority a bit... Thanks Alexandre. I tried to do this a while back but was having problems understanding something in the makefiles for my make implib rule. A fix for the import libs would be great because I have this same problem when building certain dlls under mingw and keeping the mingw win32api package and wine in sync is a big waste of time for me. C:\mingw\bin\..\lib\gcc-lib\mingw32\3.2\..\..\..\..\mingw32\bin\ld.exe: cannot f ind -lwinspool.drv C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 make: *** [comdlg32.dll] Error 1
Re: RFC: console curses
Dimitrie O. Paun a écrit : On November 21, 2002 04:44 pm, Eric Pouech wrote: this won't support the case where the app creates it own console after it has started Duh! Forgot about that one. This is getting funny :) What about this one: When we create a console, we start a process (say wconsole, since the wineconsole is taken :)) that starts the console of our choice, and then communicates back to us, somehow, the stdin, stdout, and stderr handles. as I wrote, the issue is not about creating the console (that's doable), it's about keeping it open while all apps attached to this console are running and in all the cases it creates a huge amount of code/work to be created (and I not even sure that's doable in a 100% bullet proof fashion) A+
Re: Rosetta, wine, sound bug?
[EMAIL PROTECTED] a écrit : Alright, I did the new debugmsg and I also tried a few more things: I installed a directx based game and the sound worked fine for it. I tried to adjust the volume on the program itself and that didn't work. I tried changing directories and such, that also didn't work. Here is the output from the : are you sure you run it with -debugmsg +winmm,+wave,+dsound ?? nor audio not dsound show up in the trace as they should A+
Re: Rosetta, wine, sound bug?
Jeff Smith a écrit :
From: Sylvain Petreolle [EMAIL PROTECTED]
bash-2.05a$ wine -debugmsg +winmm,+wave,+dsound Rosetta.exe
trace:winmm:WINMM_LibMain 0x4163 0x1 (nil)
trace:winmm:WINMM_CreateIData Created IData (0x403f0ef8)
trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N);
trace:winmm:MMDRV_Install Got 32 bit func 'auxMessage'
trace:winmm:MMDRV_Install Got 32 bit func 'mixMessage'
trace:winmm:MMDRV_Install Got 32 bit func 'midMessage'
trace:winmm:MMDRV_Install Got 32 bit func 'modMessage'
trace:winmm:MMDRV_Install Got 32 bit func 'widMessage'
trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage'
trace:winmm:MMDRV_GetDescription32 Can't find file wineoss.drv
^^^
Shouldn't happen.
trace:winmm:MMDRV_Install wineoss.drv = No description
I get similar errors with MMDRV_GetDescription32. I assumed they
were happening because the actual file wineoss.drv does not exist.
Further, I assumed that MMDRV_GetDescription32 tries to get the
description from locating the relevant record in the actual file.
that's correct. this part of the code if just for debugging purpose (and
be can simply ignore the trace...)
A+
Re: winspool.drv again
On November 22, 2002 01:12 pm, Eric Pouech wrote: be aware anyway that in some cases we have both foo.dll and foo.drv (checkout msacm...) so import libs are the way That's what Alexandre was saying too :) I've fund a way to work around it for PuTTY, but we need to fix this as -lwinspool is very common, and most build systems are hard to hack to change them to winspool.drv, if you want to share your build system between Wine, and Windows... -- Dimi.
Re: RFC: console curses
On November 22, 2002 01:24 pm, Eric Pouech wrote: and in all the cases it creates a huge amount of code/work to be created (and I not even sure that's doable in a 100% bullet proof fashion) I see the problems now, thanks for the explanation. In that case, I would say between to equal methods, pick the one that leaves the door open for such future work, if anyone is inclined to do it. -- Dimi.
Re: wm_mousehover bug fix.....
On 22 Nov 2002, Mike Hearn wrote: Sorry to kind of spam, it was much easier to fix it than I thought it would be. Hacking wine isn't so hard after all.. input.c line 970 should be: PostMessageA(TrackingList[i].tme.hwndTrack, WM_MOUSEHOVER, get_key_state() , (pos.y 8) + (pos.x)); That doesn't make much sense, is the X and Y coordinates really always less than 256? Brings back memories of the the CGA days... Perhaps you meant (pos.y 16). But if so, you should probably use the MAKELONG or MAKELPARAM macro here.
Re: RFC: console curses
I see the problems now, thanks for the explanation. In that case, I would say between to equal methods, pick the one that leaves the door open for such future work, if anyone is inclined to do it. that's also what I had in mind... it's time now to go back to write actually what has been discussed in the RFC A+
Re: wine and asyncronous file i/o
Hi Martin, What sort of file handle is the program trying to read from? Is it a serial port, a socket, a pipe or a standard file? -debugmsg +file,+comm,+server,+winsock should generate a good enough trace. Mike Martin Fuchs wrote: Hi! I've got an application, which uses an asynchron file stream library. I uses ReadFileEx() and alertable wait with SleepEx(). This doesn't work right with wine. It seems to get caught in an endless loop. Wine and wineserver together use 100 % cpu power. Does anyone already know, what's going wrong here? I had a quick look at the implementation in wine, but couldn't find any hint about missing functionality or some thing like this. Which debug switches wold be usefull to trace this?
Re: wine and asyncronous file i/o
Thanks, Martin! EOF conditions are nasty. Seems we got it wrong... Please try the following patch (it should solve your problem). However I guess it needs regression testing because it changes overlapped ReadFile() semantics drastically. If this condition turns out to be right, we may actually be able to get rid of the special treatment of sockets in FILE_AsyncReadService(). Yes, the file read routine seems to work now. However the application doesn't run completely yet. But that's another problem, I think... -- Martin Fuchs [EMAIL PROTECTED]
Re: wm_mousehover bug fix.....
Ove Kaaven ovehk-at-ping.uio.no |Wine Mailing Lists| wrote: On 22 Nov 2002, Mike Hearn wrote: Sorry to kind of spam, it was much easier to fix it than I thought it would be. Hacking wine isn't so hard after all.. input.c line 970 should be: PostMessageA(TrackingList[i].tme.hwndTrack, WM_MOUSEHOVER, get_key_state() , (pos.y 8) + (pos.x)); More to the point, the windows headers say that for WM_MOUSEHOVER,the low 16bits contain X the high 16bits contain Y. As this stands, you have low 8 bits for X, and 24 high bits for Y. That doesn't make much sense, is the X and Y coordinates really always less than 256? Brings back memories of the the CGA days... Perhaps you meant (pos.y 16). But if so, you should probably use the MAKELONG or MAKELPARAM macro here. Sounds about right (To a windows progammer)
wintab.dll: Copyright trademark issues.
As I mentioned in an e-mail a couple of days back, I'm about to start implemening a version of wintab.dll. First I want to ask about legal issues: 1. trademark issues. wintab is a trademark. Does this impact on the ability to implement wintab.dll 2. API header files. Please look at the licence for the API files, avaialable at the following URL: http://www.pointing.com/Wintab/WTKIT126.ZIP Does this allow our use of the headers, in Wine? Does it allow the use of fragments of the headers in Wine? This is not too much of an issue, as I understand it's OK to re-write compatible headers In your own words. 3. I am in the UK, how does this affect the copyright/trademark issues above? Ok, some background about wintab: wintab.dll is an open industry standard API developed by a group of tablet manufacturers, and seems to be currently maintained by the company LCS/Telegraphics. Web page for wintab: http://www.pointing.com/WINTAB.HTM LCS/Telegraphics home: http://www.pointing.com/LCS.HTM I also found this organiation that LCS belongs to interesting: http://www.interop.org/ Many thanks -Rob.
Re: wine/ windows/winproc.c windows/winpos.c windo ...
On Friday 22 November 2002 03:22 pm, Alexandre Julliard wrote:
ChangeSet ID: 6371
1.154 1.155 +76 -93 wine/controls/menu.c
gcc 3.2 isn't happy with this:
make[2]: Entering directory `/var/src/wine/dlls/user'
gcc -c -I. -I. -I../../include -I../../include -march=athlon -O1 -pipe -mmmx -m3dnow
-gstabs -g3 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_USER32_
-D_WINABLE_ -D_REENTRANT -o ../../controls/menu.o ../../controls/menu.c
../../controls/menu.c: In function `MENU_GetBitmapItemSize':
../../controls/menu.c:722: pointers are not permitted as case values
../../controls/menu.c:729: pointers are not permitted as case values
../../controls/menu.c:730: pointers are not permitted as case values
../../controls/menu.c:731: pointers are not permitted as case values
../../controls/menu.c:732: pointers are not permitted as case values
../../controls/menu.c:733: pointers are not permitted as case values
../../controls/menu.c:737: pointers are not permitted as case values
../../controls/menu.c:738: pointers are not permitted as case values
../../controls/menu.c:739: pointers are not permitted as case values
../../controls/menu.c:740: pointers are not permitted as case values
../../controls/menu.c:741: pointers are not permitted as case values
../../controls/menu.c: In function `MENU_DrawBitmapItem':
../../controls/menu.c:778: pointers are not permitted as case values
../../controls/menu.c:793: pointers are not permitted as case values
../../controls/menu.c:796: pointers are not permitted as case values
../../controls/menu.c:799: pointers are not permitted as case values
../../controls/menu.c:802: pointers are not permitted as case values
../../controls/menu.c:805: pointers are not permitted as case values
../../controls/menu.c:808: pointers are not permitted as case values
../../controls/menu.c:809: pointers are not permitted as case values
../../controls/menu.c:810: pointers are not permitted as case values
../../controls/menu.c:811: pointers are not permitted as case values
../../controls/menu.c:812: pointers are not permitted as case values
make[2]: *** [../../controls/menu.o] Error 1
make[2]: Leaving directory `/var/src/wine/dlls/user'
make[1]: *** [user] Error 2
make[1]: Leaving directory `/var/src/wine/dlls'
make: *** [dlls] Error 2
These are DECLARE_HANDLE'ed values. This seems to fix it:
Index: controls/menu.c
===
RCS file: /home/wine/wine/controls/menu.c,v
retrieving revision 1.155
diff -u -r1.155 menu.c
--- controls/menu.c 22 Nov 2002 21:22:16 - 1.155
+++ controls/menu.c 22 Nov 2002 22:13:40 -
@@ -719,26 +719,26 @@
{
switch(LOWORD(id))
{
-case HBMMENU_SYSTEM:
+case (WORD)HBMMENU_SYSTEM:
if (data)
{
bmp = (HBITMAP)data;
break;
}
/* fall through */
-case HBMMENU_MBAR_RESTORE:
-case HBMMENU_MBAR_MINIMIZE:
-case HBMMENU_MBAR_MINIMIZE_D:
-case HBMMENU_MBAR_CLOSE:
-case HBMMENU_MBAR_CLOSE_D:
+case (WORD)HBMMENU_MBAR_RESTORE:
+case (WORD)HBMMENU_MBAR_MINIMIZE:
+case (WORD)HBMMENU_MBAR_MINIMIZE_D:
+case (WORD)HBMMENU_MBAR_CLOSE:
+case (WORD)HBMMENU_MBAR_CLOSE_D:
size-cx = GetSystemMetrics( SM_CXSIZE );
size-cy = GetSystemMetrics( SM_CYSIZE );
return;
-case HBMMENU_CALLBACK:
-case HBMMENU_POPUP_CLOSE:
-case HBMMENU_POPUP_RESTORE:
-case HBMMENU_POPUP_MAXIMIZE:
-case HBMMENU_POPUP_MINIMIZE:
+case (WORD)HBMMENU_CALLBACK:
+case (WORD)HBMMENU_POPUP_CLOSE:
+case (WORD)HBMMENU_POPUP_RESTORE:
+case (WORD)HBMMENU_POPUP_MAXIMIZE:
+case (WORD)HBMMENU_POPUP_MINIMIZE:
default:
FIXME(Magic 0x%08x not implemented\n, id);
return;
@@ -775,7 +775,7 @@
switch(LOWORD(lpitem-text))
{
-case HBMMENU_SYSTEM:
+case (WORD)HBMMENU_SYSTEM:
if (lpitem-dwItemData)
{
bmp = (HBITMAP)lpitem-dwItemData;
@@ -790,26 +790,26 @@
bm.bmWidth -= bmp_xoffset;
}
goto got_bitmap;
-case HBMMENU_MBAR_RESTORE:
+case (WORD)HBMMENU_MBAR_RESTORE:
flags = DFCS_CAPTIONRESTORE;
break;
-case HBMMENU_MBAR_MINIMIZE:
+case (WORD)HBMMENU_MBAR_MINIMIZE:
flags = DFCS_CAPTIONMIN;
break;
-case HBMMENU_MBAR_MINIMIZE_D:
+case (WORD)HBMMENU_MBAR_MINIMIZE_D:
flags = DFCS_CAPTIONMIN | DFCS_INACTIVE;
break;
-case HBMMENU_MBAR_CLOSE:
+case (WORD)HBMMENU_MBAR_CLOSE:
flags = DFCS_CAPTIONCLOSE;
break;
-case HBMMENU_MBAR_CLOSE_D:
+case (WORD)HBMMENU_MBAR_CLOSE_D:
flags = DFCS_CAPTIONCLOSE |
Winelib Applications
Folks, A new page has appeared in the Wine constellation g. It is still a work in progress, but I hope to release version 0.1 in the next few days, once I have a change to add what I've done on PuTTY, and Visual-MinGW. Check it out: http://www.dssd.ca/wine/Winelib-Apps.html Comments, suggestions, flames -- all welcome! -- Dimi.
RE: wintab.dll: Copyright trademark issues.
As I mentioned in an e-mail a couple of days back, I'm about to start implemening a version of wintab.dll. First I want to ask about legal issues: 1. trademark issues. wintab is a trademark. Does this impact on the ability to implement wintab.dll No, I can't see how. Everything we will reasonable do with the name are either unrelated to trademarks or are used in reference to what is protected by the trademark. 2. API header files. Please look at the licence for the API files, avaialable at the following URL: http://www.pointing.com/Wintab/WTKIT126.ZIP Does this allow our use of the headers, in Wine? Does it allow the use of fragments of the headers in Wine? From the headers: The text and information contained in this file may be freely used, copied, or distributed without compensation or licensing restrictions. So the headers are basicly public domain. Specifically it is compatible with the X11 license and the LGPL so no problem. We could include the files as they are without any modification at all as far as copyright is concerned. Presumably we might need some compiler related fixes though. This is not too much of an issue, as I understand it's OK to re-write compatible headers In your own words. True. 3. I am in the UK, how does this affect the copyright/trademark issues above? It is not likely to matter very much almost regardless of there you are in the world, copyright and trademark laws are usually not that different. UK is pretty normal AFAIK. Ok, some background about wintab: wintab.dll is an open industry standard API developed by a group of tablet manufacturers, and seems to be currently maintained by the company LCS/Telegraphics. Web page for wintab: http://www.pointing.com/WINTAB.HTM LCS/Telegraphics home: http://www.pointing.com/LCS.HTM OK. Seem to contain documentation and other things nessary or useful for implementing. I can see two issues though. 1. It is not an offical Microsoft DLL so should it be part of Wine or not? IMHO yes, it seems to be widely used. However Alexandre decides. 2. How do you expect to implement this presumably very complicted DLL? Does Linux have some special libraries for supporting tablets?
where is the code that converts VARIANTS?
Can anyone tell me where the code is that converts a VARIANT from VT_DECIMAL to VT_BSTR? Bill
Re: where is the code that converts VARIANTS?
On Fri, 22 Nov 2002, Medland, Bill wrote: Can anyone tell me where the code is that converts a VARIANT from VT_DECIMAL to VT_BSTR? You mean VarBstrFromDec? It probably should have been in dlls/oleaut32/variant.c, if it had been implemented. (You could just have grep-ed the source for VariantChangeType or whatever API you're using, though.)
Re: Wine Boehm garbage collector
Le jeu 21/11/2002 à 21:22, Alexandre Julliard a écrit : François-Denis Gonthier [EMAIL PROTECTED] writes: Apparently, the problem lies in Boehm GC, but before mailing Hans Boehm about this (he can probably provide limited support only), I'd like to hear about the people that knows about the internals of Wine. It seems that seg fault is deliberate, it's trying to determine the end of the addressable space. So if you continue execution the signal should get handled; maybe this is what breaks, or maybe it's something else later on. It's somewhere else: Program received signal SIGSEGV, Segmentation fault. 0x405a54ab in GC_mark_from (mark_stack_top=0x80871b8, mark_stack=0x80870a8, mark_stack_limit=0x808f0a8) at mark.c:647 647 deferred = *limit; (gdb) bt #0 0x405a54ab in GC_mark_from (mark_stack_top=0x80871b8, mark_stack=0x80870a8, mark_stack_limit=0x808f0a8) at mark.c:647 #1 0x405a51a0 in GC_mark_some ( cold_gc_frame=0x40822cf8 ´\005\\@\034-\202@h7[@(ÕY@´\005\\@L-\202@@ÙY@(ÕY@h7[@L-\202@+ÙY@¯ÓZ@) at mark.c:374 #2 0x4059dc46 in GC_stopped_mark (stop_func=0x4059d528 GC_never_stop_func) at alloc.c:500 #3 0x4059d940 in GC_try_to_collect_inner ( stop_func=0x4059d528 GC_never_stop_func) at alloc.c:353 #4 0x405a7868 in GC_init_inner () at misc.c:703 #5 0x405a3b6d in GC_generic_malloc_inner (lb=100, k=1) at malloc.c:123 #6 0x405a3c9f in GC_generic_malloc (lb=100, k=1) at malloc.c:190 #7 0x405a3f51 in GC_malloc (lb=100) at malloc.c:295 #8 0x4021512b in WinMain () at boehm_crash.c:5 #9 0x402150a5 in __wine_exe_main () at boehm_crash.exe.spec.c:109 #10 0x400b1f5c in start_process () at ../../scheduler/process.c:564 #11 0x400b5ed5 in call_on_thread_stack (func=0x400b1d24) at ../../scheduler/sysdeps.c:112 I can't seem to find anything else for now, such as why limits gets too high. Vincent
Re: dosconf move
György 'Nog' Jeney [EMAIL PROTECTED] writes: Is there any reason why this patch has not been applied? This is essentially the same as my dosconf try 3 patch but for your convinience I made a new diff against the current cvs. It's really ugly to export the DOSCONF structure as part of the DOS module interface. I think it's better to wait until that stuff can be moved without having to export it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Menu selection algorithm
Shachar Shemesh [EMAIL PROTECTED] wrote: So, what's the problem - you ask? While my view of what should happen is obviously consistant with that of Wine's - i.e. - the locale should select which menu to use, Windows displays the English locale ONLY. The only way I could make it display the Hebrew one was by changing the language on the English one to something else (French). I revived my old test for FindResource and now I see what are you talking about. LoadStringA/W and FindResourceA/W under Win2000 do search for language resource in the following order: 1. Neutral language with neutral sublanguage 2. LANG_ENGLISH, SUBLANG_DEFAULT 3. LANG_ENGLISH, SUBLANG_NEUTRAL 4. Current locale lang id 5. Current locale lang id with neutral sublanguage 6. Return first in the list But that means that the whole our internationalization will not work, if we will go that way. But the question I have is: had I made an error when I did the test under Win95OSR2 or MS has changed algorithm since then? -- Dmitry.
Re: Wine Boehm garbage collector
Thank you for all that information. I consider that any progress, even the smallest one, is welcomed on that issue. If needed, I'll forward that information to a group that is more experience with Boehm's GC (GNU GJC comes to my mind). - Original Message - From: Vincent Béron [EMAIL PROTECTED] To: François-Denis Gonthier [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, November 22, 2002 8:56 PM Subject: Re: Wine Boehm garbage collector Le jeu 21/11/2002 à 21:22, Alexandre Julliard a écrit : François-Denis Gonthier [EMAIL PROTECTED] writes: Apparently, the problem lies in Boehm GC, but before mailing Hans Boehm about this (he can probably provide limited support only), I'd like to hear about the people that knows about the internals of Wine. It seems that seg fault is deliberate, it's trying to determine the end of the addressable space. So if you continue execution the signal should get handled; maybe this is what breaks, or maybe it's something else later on. It's somewhere else: Program received signal SIGSEGV, Segmentation fault. 0x405a54ab in GC_mark_from (mark_stack_top=0x80871b8, mark_stack=0x80870a8, mark_stack_limit=0x808f0a8) at mark.c:647 647 deferred = *limit; (gdb) bt #0 0x405a54ab in GC_mark_from (mark_stack_top=0x80871b8, mark_stack=0x80870a8, mark_stack_limit=0x808f0a8) at mark.c:647 #1 0x405a51a0 in GC_mark_some ( cold_gc_frame=0x40822cf8 ´\005\\@\034-\202@h7[@(ÕY@´\005\\@L-\202@@ÙY@(ÕY@h7[@L-\202@+ÙY@¯ÓZ@) at mark.c:374 #2 0x4059dc46 in GC_stopped_mark (stop_func=0x4059d528 GC_never_stop_func) at alloc.c:500 #3 0x4059d940 in GC_try_to_collect_inner ( stop_func=0x4059d528 GC_never_stop_func) at alloc.c:353 #4 0x405a7868 in GC_init_inner () at misc.c:703 #5 0x405a3b6d in GC_generic_malloc_inner (lb=100, k=1) at malloc.c:123 #6 0x405a3c9f in GC_generic_malloc (lb=100, k=1) at malloc.c:190 #7 0x405a3f51 in GC_malloc (lb=100) at malloc.c:295 #8 0x4021512b in WinMain () at boehm_crash.c:5 #9 0x402150a5 in __wine_exe_main () at boehm_crash.exe.spec.c:109 #10 0x400b1f5c in start_process () at ../../scheduler/process.c:564 #11 0x400b5ed5 in call_on_thread_stack (func=0x400b1d24) at ../../scheduler/sysdeps.c:112 I can't seem to find anything else for now, such as why limits gets too high. Vincent
Page fault with isspace(*p)
I am rewriting the regsvr stuff in dlls/comcat to make it practical to
extend to ole32 and all the other COM DLLs. I have a nice simple function
to skip whitespace and return the next character:
static int getc_skipws(char const **p)
{
while (isspace(*p))
++*p;
return **p;
}
This gets called with **p == '['. I get a page fault in the
implementation of isspace(), where the macro is testing 0x20 against the
value for '[' in the __ctype_b array. What gives?
Re: dosconf move
György 'Nog' Jeney [EMAIL PROTECTED] writes: Is there any reason why this patch has not been applied? This is essentially the same as my dosconf try 3 patch but for your convinience I made a new diff against the current cvs. It's really ugly to export the DOSCONF structure as part of the DOS module interface. I think it's better to wait until that stuff can be moved without having to export it. This uglyness doesnt haveto stay around for to long as this patch was to split up my patches a bit for my int21 move for which I have posted a patch already. Is there any reason why THAT one has not been applied? BTW Im very sorry for sending 3 e-mails but my squirelmail/internet connection just doesnt work well. I have to push the stop button on my browser to stop sending the mail over and over again. This time I got the timeing wrong as I was having a Voip conversation at the same time.
