Re: BitTorrent
FYI, There are native Linux bittorrent clients, including the one you're trying to use. On Sat, 2005-03-26 at 02:15 +, Andrew Neil Ramage wrote: > Following up from the last message, when I tried to move beyond the > stage described, I get the following: > > next > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 > EIP:1e04e00f ESP:406ee804 EBP:406ee860 EFLAGS:00210246( - 00 > -RIZP1) > EAX: EBX:0002 ECX: EDX:a93c6858 > ESI:406ee860 EDI:a93c6858 > Stack dump: > 0x406ee804: 4131a118 0002 1e04dd4c > 0x406ee814: 406ee860 406ee868 1e09ca68 406ee860 > 0x406ee824: 41300a64 1e04de36 406ee860 > 0x406ee834: 406ee868 0029 0002 1e0bcd75 > 0x406ee844: 0029 1e09ca68 412b35e8 > 0x406ee854: 1e04dbec 406ee860 406ee868 1e0bcd76 > Backtrace: > =>1 0x1e04e00f PyCFunction_Call in python22 (0x406ee860) >2 0x1e04db8f PyCFunction_Call in python22 (0x1e0bcd76) >3 0x6164 (0x297a) >4 0x (0x) > 0x1e04e00f PyCFunction_Call+0xc2f in python22: repne scasb %es:(%edi) > Wine-dbg>First chance exception: page fault on read access to 0xa93c6858 > in 32-bit code (0x1e04e00f). > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 > EIP:1e04e00f ESP:406ee804 EBP:406ee860 EFLAGS:00210246( - 00 > -RIZP1) > EAX: EBX:0002 ECX: EDX:a93c6858 > ESI:406ee860 EDI:a93c6858 > Stack dump: > 0x406ee804: 4131a118 0002 1e04dd4c > 0x406ee814: 406ee860 406ee868 1e09ca68 406ee860 > 0x406ee824: 41300a64 1e04de36 406ee860 > 0x406ee834: 406ee868 0029 0002 1e0bcd75 > 0x406ee844: 0029 1e09ca68 412b35e8 > 0x406ee854: 1e04dbec 406ee860 406ee868 1e0bcd76 > Backtrace: > =>1 0x1e04e00f PyCFunction_Call in python22 (0x406ee860) >2 0x1e04db8f PyCFunction_Call in python22 (0x1e0bcd76) >3 0x6164 (0x297a) >4 0x (0x) > 0x1e04e00f PyCFunction_Call+0xc2f in python22: repne scasb %es:(%edi) > Wine-dbg> > > > Andrew > > "Someone set a bad example > makes surrender seem alright; > The act of a noble warrior > who's lost the will to fight > > And now you're trembling on a rocky ledge > Staring out into a heartless sea > Facing life on a razor's edge > Nothing's what you thought it would be." > > --- > > Rush, The Pass (Presto, 1989) > >
BitTorrent
Following up from the last message, when I tried to move beyond the stage described, I get the following: next Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:1e04e00f ESP:406ee804 EBP:406ee860 EFLAGS:00210246( - 00 -RIZP1) EAX: EBX:0002 ECX: EDX:a93c6858 ESI:406ee860 EDI:a93c6858 Stack dump: 0x406ee804: 4131a118 0002 1e04dd4c 0x406ee814: 406ee860 406ee868 1e09ca68 406ee860 0x406ee824: 41300a64 1e04de36 406ee860 0x406ee834: 406ee868 0029 0002 1e0bcd75 0x406ee844: 0029 1e09ca68 412b35e8 0x406ee854: 1e04dbec 406ee860 406ee868 1e0bcd76 Backtrace: =>1 0x1e04e00f PyCFunction_Call in python22 (0x406ee860) 2 0x1e04db8f PyCFunction_Call in python22 (0x1e0bcd76) 3 0x6164 (0x297a) 4 0x (0x) 0x1e04e00f PyCFunction_Call+0xc2f in python22: repne scasb %es:(%edi) Wine-dbg>First chance exception: page fault on read access to 0xa93c6858 in 32-bit code (0x1e04e00f). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:1e04e00f ESP:406ee804 EBP:406ee860 EFLAGS:00210246( - 00 -RIZP1) EAX: EBX:0002 ECX: EDX:a93c6858 ESI:406ee860 EDI:a93c6858 Stack dump: 0x406ee804: 4131a118 0002 1e04dd4c 0x406ee814: 406ee860 406ee868 1e09ca68 406ee860 0x406ee824: 41300a64 1e04de36 406ee860 0x406ee834: 406ee868 0029 0002 1e0bcd75 0x406ee844: 0029 1e09ca68 412b35e8 0x406ee854: 1e04dbec 406ee860 406ee868 1e0bcd76 Backtrace: =>1 0x1e04e00f PyCFunction_Call in python22 (0x406ee860) 2 0x1e04db8f PyCFunction_Call in python22 (0x1e0bcd76) 3 0x6164 (0x297a) 4 0x (0x) 0x1e04e00f PyCFunction_Call+0xc2f in python22: repne scasb %es:(%edi) Wine-dbg> Andrew "Someone set a bad example makes surrender seem alright; The act of a noble warrior who's lost the will to fight And now you're trembling on a rocky ledge Staring out into a heartless sea Facing life on a razor's edge Nothing's what you thought it would be." --- Rush, The Pass (Presto, 1989)
BitTorrent
I tried downloading the BitTorrent client from [url] and executin -- Andrew "Someone set a bad example makes surrender seem alright; The act of a noble warrior who's lost the will to fight And now you're trembling on a rocky ledge Staring out into a heartless sea Facing life on a razor's edge Nothing's what you thought it would be." --- Rush, The Pass (Presto, 1989) [EMAIL PROTECTED] andrew]$ wine $C/"Program Files"/BitTorrent/btdownloadgui.exe fixme:msvcrt:MSVCRT_signal (1 0x1):stub fixme:msvcrt:MSVCRT_signal (1 0x):stub fixme:msvcrt:MSVCRT_signal (2 0x1):stub fixme:msvcrt:MSVCRT_signal (2 0x):stub fixme:msvcrt:MSVCRT_signal (3 0x1):stub fixme:msvcrt:MSVCRT_signal (3 0x):stub fixme:msvcrt:MSVCRT_signal (4 0x1):stub fixme:msvcrt:MSVCRT_signal (4 0x):stub fixme:msvcrt:MSVCRT_signal (5 0x1):stub fixme:msvcrt:MSVCRT_signal (5 0x):stub fixme:msvcrt:MSVCRT_signal (6 0x1):stub fixme:msvcrt:MSVCRT_signal (6 0x):stub fixme:msvcrt:MSVCRT_signal (7 0x1):stub fixme:msvcrt:MSVCRT_signal (7 0x):stub fixme:msvcrt:MSVCRT_signal (8 0x1):stub fixme:msvcrt:MSVCRT_signal (8 0x):stub fixme:msvcrt:MSVCRT_signal (9 0x1):stub fixme:msvcrt:MSVCRT_signal (9 0x):stub fixme:msvcrt:MSVCRT_signal (10 0x1):stub fixme:msvcrt:MSVCRT_signal (10 0x):stub fixme:msvcrt:MSVCRT_signal (11 0x1):stub fixme:msvcrt:MSVCRT_signal (11 0x):stub fixme:msvcrt:MSVCRT_signal (12 0x1):stub fixme:msvcrt:MSVCRT_signal (12 0x):stub fixme:msvcrt:MSVCRT_signal (13 0x1):stub fixme:msvcrt:MSVCRT_signal (13 0x):stub fixme:msvcrt:MSVCRT_signal (14 0x1):stub fixme:msvcrt:MSVCRT_signal (14 0x):stub fixme:msvcrt:MSVCRT_signal (15 0x1):stub fixme:msvcrt:MSVCRT_signal (15 0x):stub fixme:msvcrt:MSVCRT_signal (16 0x1):stub fixme:msvcrt:MSVCRT_signal (16 0x):stub fixme:msvcrt:MSVCRT_signal (17 0x1):stub fixme:msvcrt:MSVCRT_signal (17 0x):stub fixme:msvcrt:MSVCRT_signal (18 0x1):stub fixme:msvcrt:MSVCRT_signal (18 0x):stub fixme:msvcrt:MSVCRT_signal (19 0x1):stub fixme:msvcrt:MSVCRT_signal (19 0x):stub fixme:msvcrt:MSVCRT_signal (20 0x1):stub fixme:msvcrt:MSVCRT_signal (20 0x):stub fixme:msvcrt:MSVCRT_signal (21 0x1):stub fixme:msvcrt:MSVCRT_signal (21 0x):stub fixme:msvcrt:MSVCRT_signal (22 0x1):stub fixme:msvcrt:MSVCRT_signal (22 0x):stub fixme:msvcrt:_XcptFilter (-1073741819,0x406de3c4)semi-stub wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0xa93c6858 in 32-bit code (0x1e04e00f). In 32 bit mode. Second try [EMAIL PROTECTED] andrew]$ WINEDEBUG=all [EMAIL PROTECTED] andrew]$ winedbg $C/"Program Files"/BitTorrent/btdownloadgui.exe WineDbg starting on pid 0xa In 32 bit mode. 0x405045d2 start_process+0x102 in kernel32: jmp 0x405045c1 start_process+0xf1 in kernel32 Wine-dbg>next fixme:msvcrt:MSVCRT_signal (1 0x1):stub fixme:msvcrt:MSVCRT_signal (1 0x):stub fixme:msvcrt:MSVCRT_signal (2 0x1):stub fixme:msvcrt:MSVCRT_signal (2 0x):stub fixme:msvcrt:MSVCRT_signal (3 0x1):stub fixme:msvcrt:MSVCRT_signal (3 0x):stub fixme:msvcrt:MSVCRT_signal (4 0x1):stub fixme:msvcrt:MSVCRT_signal (4 0x):stub fixme:msvcrt:MSVCRT_signal (5 0x1):stub fixme:msvcrt:MSVCRT_signal (5 0x):stub fixme:msvcrt:MSVCRT_signal (6 0x1):stub fixme:msvcrt:MSVCRT_signal (6 0x):stub fixme:msvcrt:MSVCRT_signal (7 0x1):stub fixme:msvcrt:MSVCRT_signal (7 0x):stub fixme:msvcrt:MSVCRT_signal (8 0x1):stub fixme:msvcrt:MSVCRT_signal (8 0x):stub fixme:msvcrt:MSVCRT_signal (9 0x1):stub fixme:msvcrt:MSVCRT_signal (9 0x):stub fixme:msvcrt:MSVCRT_signal (10 0x1):stub fixme:msvcrt:MSVCRT_signal (10 0x):stub fixme:msvcrt:MSVCRT_signal (11 0x1):stub fixme:msvcrt:MSVCRT_signal (11 0x):stub fixme:msvcrt:MSVCRT_signal (12 0x1):stub fixme:msvcrt:MSVCRT_signal (12 0x):stub fixme:msvcrt:MSVCRT_signal (13 0x1):stub fixme:msvcrt:MSVCRT_signal (13 0x):stub fixme:msvcrt:MSVCRT_signal (14 0x1):stub fixme:msvcrt:MSVCRT_signal (14 0x):stub fixme:msvcrt:MSVCRT_signal (15 0x1):stub fixme:msvcrt:MSVCRT_signal (15 0x):stub fixme:msvcrt:MSVCRT_signal (16 0x1):stub fixme:msvcrt:MSVCRT_signal (16 0x):stub fixme:msvcrt:MSVCRT_signal (17 0x1):stub fixme:msvcrt:MSVCRT_signal (17 0x):stub fixme:msvcrt:MSVCRT_signal (18 0x1):stub fixme:msvcrt:MSVCRT_signal (18 0x):stub fixme:msvcrt:MSVCRT_signal (19 0x1):stub fixme:msvcrt:MSVCRT_signal (19 0x):stub fixme:msvcrt:MSVCRT_signal (20 0x1):stub fixme:msvcrt:MSVCRT_signal (20 0x):stub fixme:msvcrt:MSVCRT_signal (21 0x1):stub fixme:msvcrt:MSVCRT_signal (21 0x):stub fixme:msvcrt:MSVCRT_signal (22 0x1):stub fixme:msvcrt:MSVCRT_signal (22 0x):stub First chance exception: page fault on read access to 0xa93c6858 in 32-bit code (0x1e04e00f).
Re: saving winrash
Robert Shearman wrote: Chris Morgan wrote: I have already sent links to documents on MSDN that state how to make a service run on an interactive desktop. As some of the tests are a little distracting graphically, we should probably do the dialog as you suggest. I guess this is really up to the people running the test machines. If the source to winrash was in the Wine tree I would already have fixed it by now. The source has been available on Sourceforge since the project started. Patches welcome :-) Ah, ok. I've never seen a link to the project. Here's a patch that should fix the creating of a service so that it appears on an interactive window station. Ohhh! This is interesting! Does this mean the service will have a desktop to interact with? regards, Jakob
Re: redirecting text to standard out
Thanks for that idea, I was able to capture some output from Dragon Nat. Speaking using that idea. trace:text:DrawTextExW L"New-Paragraph ", -1, [(17,2)-(729,18)] 0824 trace:text:DrawTextExW Params: iTabLength=0, iLeftMargin=0, iRightMargin=0 trace:text:DrawTextExW L"this text was dictated into NaturallySpeaking for ", -1, [(17,2)-(729,18)] 0824 there's almost certainly a better way to do this but at least that gives me a rudementary way of grabbing dictated text in a Linux process. I could probably pipe it through grep to filter out the actual text from the rest. Unless anyone has a better idea Peter On Fri, 25 Mar 2005 22:01:07 +0100, Hans Leidekker <[EMAIL PROTECTED]> wrote: On Friday 25 March 2005 16:14, Raphael Clifford wrote: I am running a windows app under wine that prints text to the screen. This can be copied and pasted into wine's notepad. Is there any way to get wine to simply output all text written by the app to standard out? I remember I did something like this to extract the word list from a Dutch dictionary program: WINEDEBUG="trace+text" wine 2>&1 Because my program can't display all words at once and because I didn't want to click the mouse button a hundred thousand times I wrote a little program to do it. I used xwininfo and xev to find the window id and coordinates of the down arrow on the scroll bar for the word list. The program would then send X button press and release events to this window in a loop. -Hans -- Opera 7 mail on Linux
Hotel full again?
I tried to book a double room 28th April -> 1st May (sharing with tridge), and it seems the hotel is all full again :-( There seems to be quite a contingent of Samba folk intending to come along (from a poll on the samba team list), and given the number of 'maybe' and 'probably' replies, I suspect I'm not the only one without a room... Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: redirecting text to standard out
On Friday 25 March 2005 16:14, Raphael Clifford wrote: > I am running a windows app under wine that prints text to the screen. > This can be copied and pasted into wine's notepad. Is there any way to > get wine to simply output all text written by the app to standard out? I remember I did something like this to extract the word list from a Dutch dictionary program: WINEDEBUG="trace+text" wine 2>&1 Because my program can't display all words at once and because I didn't want to click the mouse button a hundred thousand times I wrote a little program to do it. I used xwininfo and xev to find the window id and coordinates of the down arrow on the scroll bar for the word list. The program would then send X button press and release events to this window in a loop. -Hans
Re: DirectDraw YUV overlays
Lionel Ulmer wrote: I would suggest using the Xv extensions again if possible. Yes, and it will provide hardware-based scaling for free too... I wonder if GL exports any YUV-like texture formats on modern hardware. Not really. :( There's an apple-specific extension for it. On the other hand, YUV->RGB conversion should be really easy to write as a fragment program (either NV_texture_shader, ARB_fragment_shader [GLSL], ARB_fragment_program, NV_fragment_program) on any gf3-era card or later, which I'm guessing is why not many implementors are rushing to standardise YUV textures. --Adam
Re: Regression in winealsa (message only?)
On Thu, 2005-03-24 at 21:26, Jeremy White wrote: > Hmm. That's my patch, but it bumps into one from Robert Reif. > > Robert, is plug:hw:N the correct device naming convention for > PCM opens? I've always done plughw:N. It appears as though > the snd_hctl_open of plug:hw:0 is failing. > > I can't tell because of the lack of Alsa documentation which > is supposed to be right; if we're supposed to do plughw:0 > instead of plug:hw:0, I'll have to fudge that code for the > volume control stuff. > > Paul, you can test this for yourself by adding a > > [ALSA] > "PlaybackDevice"="plughw" This doesn't make a difference. > > to your config (or just try "hw" if that fails too). The error message disappears but a new is there: fixme:wave:ALSA_WaveInit - > > and seeing if everything still works (if the error below > goes away but a new one pops up, then I have work to do :-/). > > Cheers, > > Jeremy > It doesn't seem to affect the sound though. Running current CVS with a +wave gives: trace:wave:ALSA_WaveInit using waveout device "plug:hw:0" trace:wave:ALSA_WaveInit dev=0 id=Intel ICH name=Intel 82801DB-ICH4 subdev=0 subdev_name=subdevice #0 subdev_avail=0 subdev_num=1 stream=PLAYBACK subclass=GENERIC MIX trace:wave:ALSA_TraceParameters FLAGS: sampleres=false overrng=true pause=true resume=true syncstart=true batch=true block=true double=true halfd=true joint=true trace:wave:ALSA_TraceParameters access=(null) trace:wave:ALSA_TraceParameters format=(null) trace:wave:ALSA_TraceParameters channels_min=1, channels_min_max=1 trace:wave:ALSA_TraceParameters buffer_size_min=1, buffer_size_min_max=4294967294 trace:wave:ALSA_TraceParameters rate_min=4000 rate_max=4294967295 trace:wave:ALSA_TraceParameters buffer_time_min=1 buffer_time_max=4294967295 trace:wave:ALSA_TraceParameters periods_min=0 periods_max=4294967295 trace:wave:ALSA_TraceParameters period_size_min=0, period_size_min_max=4294967295 trace:wave:ALSA_TraceParameters period_time_min=83 period_time_max=2048000 trace:wave:ALSA_TraceParameters tick_time=1000 trace:wave:ALSA_WaveInit Configured with dwFmts=000f dwSupport=0060 ALSA lib control.c:654:(snd_ctl_open_noupdate) Invalid CTL plug:hw:0 trace:wave:ALSA_WaveInit using waveout device "plug:hw:1" trace:wave:ALSA_WaveInit using wavein device "plug:hw:0" trace:wave:ALSA_WaveInit dev=0 id=Intel ICH name=Intel 82801DB-ICH4 subdev=0 subdev_name=subdevice #0 subdev_avail=0 subdev_num=1 stream=CAPTURE subclass=GENERIC MIX trace:wave:ALSA_TraceParameters FLAGS: sampleres=false overrng=true pause=true resume=true syncstart=true batch=true block=true double=true halfd=true joint=true trace:wave:ALSA_TraceParameters access=(null) trace:wave:ALSA_TraceParameters format=(null) trace:wave:ALSA_TraceParameters channels_min=1, channels_min_max=1 trace:wave:ALSA_TraceParameters buffer_size_min=1, buffer_size_min_max=4294967294 trace:wave:ALSA_TraceParameters rate_min=4000 rate_max=4294967295 trace:wave:ALSA_TraceParameters buffer_time_min=1 buffer_time_max=4294967295 trace:wave:ALSA_TraceParameters periods_min=0 periods_max=4294967295 trace:wave:ALSA_TraceParameters period_size_min=0, period_size_min_max=4294967295 trace:wave:ALSA_TraceParameters period_time_min=166 period_time_max=2048000 trace:wave:ALSA_TraceParameters tick_time=1000 trace:wave:ALSA_WaveInit Configured with dwFmts=000f trace:wave:ALSA_WaveInit using wavein device "plug:hw:1" trace:wave:ALSA_widMessage (0, DRVM_INIT, , , ); trace:wave:ALSA_widMessage (0, WIDM_GETNUMDEVS, , , ); trace:wave:ALSA_wodMessage (0, DRVM_INIT, , , ); trace:wave:ALSA_wodMessage (0, WODM_GETNUMDEVS, , , ); The message is already present after a clean tools/wineinstall and: regsvr32 ir50_32.dll (needed for AVI). Cheers, Paul.
Re: saving winrash
Chris Morgan wrote: I have already sent links to documents on MSDN that state how to make a service run on an interactive desktop. As some of the tests are a little distracting graphically, we should probably do the dialog as you suggest. I guess this is really up to the people running the test machines. If the source to winrash was in the Wine tree I would already have fixed it by now. The source has been available on Sourceforge since the project started. Patches welcome :-) Ah, ok. I've never seen a link to the project. Here's a patch that should fix the creating of a service so that it appears on an interactive window station. Rob --- winrash.c~ 2005-03-25 03:09:39.0 -0600 +++ winrash.c 2005-03-25 03:11:12.285319362 -0600 @@ -1431,7 +1431,7 @@ "Winrash", // pointer to name of service to start "Winrash", // pointer to display name STANDARD_RIGHTS_REQUIRED, // type of access to service -SERVICE_WIN32_OWN_PROCESS, // type of service +SERVICE_WIN32_OWN_PROCESS | SERVICE_INTERACTIVE_PROCESS, // type of service SERVICE_AUTO_START, // when to start service SERVICE_ERROR_NORMAL, // severity if service fails to start argv[2],// pointer to name of binary file
Re: updown: proper handling for GWL_STYLE
Dimitrie O. Paun wrote:
ChangeLog
Proper handling for GWL_STYLE.
Minor cleanups.
case WM_ENABLE:
- if (dwStyle & WS_DISABLED) UPDOWN_CancelMode (infoPtr);
+ if (infoPtr->dwStyle & WS_DISABLED) UPDOWN_CancelMode (infoPtr);
InvalidateRect (infoPtr->Self, NULL, FALSE);
break;
You need to update infoPtr->dwStyle here. EnableWindow(FALSE) does not
generate a WM_STYLECHANGED message.
+case WM_STYLECHANGED:
+if (wParam == GWL_STYLE) {
+infoPtr->dwStyle = ((LPSTYLESTRUCT)lParam)->styleNew;
+ InvalidateRect (infoPtr->Self, NULL, FALSE);
+}
+break;
+
Rob
Re: winetest: code reorder
"Ferenc Wagner" <[EMAIL PROTECTED]> wrote: > The point is: the method of operation (GUI, console, quiet) > should be taken into account already when displaying the > error message about desktop visibility. It matters when you > drive winetest from another program. I strongly believe > that the intended functionality of the moved lines is > totally preserved by this patch. If it's not the case, then > I made a mistake and would be happy if you pointed it out. > I just don't understand your concerns... Your patch implies that running on a not visible desktop is a legitimate mode running winetest, but it is not, no matter which mode (GUI, console, quiet) is requested on the command line. I hope that running winetest on a not visible desktop is forbidden once and for all. -- Dmitry.
Re: winetest: code reorder
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > "Ferenc Wagner" <[EMAIL PROTECTED]> wrote: > >> The -s option (submit file, do not run tests) makes sense >> anyway. But my main reason is that it drove me mad by not >> obeying the -c option (no GUI) in some test runs. And I >> don't think it hurts or contradicts your aims. > > I'd prefer to deprecate running winetest in any other mode > except of on a visible desktop in order to avoid > confusion. There are no two different modes. It's doing tests on a visible desktop only. > Again, there is no point in running it in 2 different > modes if all you just want to do is to send the test > results you've got by running winetest in interactive mode > 2 minutes ago. This feature was explicitly requested to get around proxies and such. The point is: the method of operation (GUI, console, quiet) should be taken into account already when displaying the error message about desktop visibility. It matters when you drive winetest from another program. I strongly believe that the intended functionality of the moved lines is totally preserved by this patch. If it's not the case, then I made a mistake and would be happy if you pointed it out. I just don't understand your concerns... -- Feri.
Re: ipaddress: uniform naming
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > I figured I might as well be consistent. The problem with LowerLimit > is the capital at the beginning, I don't remember where I got the (bad) > idea to name it like that. We don't use such naming anywhere, and I really > think I did a mistake when I went for it. Maybe lowerLimit is a more > acceptable solution? But do you really think it's worth having an exception > to the rule for a little 'n'? I don't think there's any point in trying to impose such silly rules on ourselves, and I really don't see what's wrong with starting with a capital letter. That's also the way Windows does it in most places where it doesn't have the Hungarian crap. Of course I think using all lowercase would be a lot more readable, but if you are going to use uppercase "LowerLimit" is much better than "lowerLimit". -- Alexandre Julliard [EMAIL PROTECTED]
Re: LOSTWAGES: updates
On Fri, Mar 25, 2005 at 09:48:48PM +0900, Mike McCormack wrote: > + Remove HeapAlloc casts Please make this a , all entries there are at that level. -- Dimi.
Re: ipaddress: uniform naming (take 2)
On Fri, Mar 25, 2005 at 12:05:20PM +, Mike Hearn wrote: > Blah, consistency with past mistakes rather than fixing them is how Win32 > ended up being such a steaming pile in the first place. If you want to do > a mass search/replace why not un-hungarianize the whole file? Because out of 24 controls, only a few (maybe 2 or 3) don't use a consistent notation. And honestly, while I don't much care for the hungarian notation, I don't think it's that bad anymore to warrant such a huge renaming. And besides, the stuff that I'm renaming is code that I wrote, and so I'm sure I'm not upsetting anyone :). -- Dimi.
Re: winetest: code reorder
"Ferenc Wagner" <[EMAIL PROTECTED]> wrote: > The -s option (submit file, do not run tests) makes sense > anyway. But my main reason is that it drove me mad by not > obeying the -c option (no GUI) in some test runs. And I > don't think it hurts or contradicts your aims. I'd prefer to deprecate running winetest in any other mode except of on a visible desktop in order to avoid confusion. Again, there is no point in running it in 2 different modes if all you just want to do is to send the test results you've got by running winetest in interactive mode 2 minutes ago. -- Dmitry.
redirecting text to standard out
Hi, I am running a windows app under wine that prints text to the screen. This can be copied and pasted into wine's notepad. Is there any way to get wine to simply output all text written by the app to standard out? This would save me a lot of hassle :) I don't mind if it outputs far too much (text from buttons etc) as I am planning on filtering the information in any case. It has been suggested to me to edit TextOut (or ExtTextOut) in dlls/gdi somewhere and simply add a printf. I had a look but this is the first time I have ever looked at wine source and I am completely baffled. Any help is very much appreciated. Cheers, Raphael
Re: advapi32: Implement NtLoadKey
On Fri, 25 Mar 2005 17:08:25 +0900, Mike McCormack <[EMAIL PROTECTED]> wrote:
>
> James Hawkins wrote:
>
> > +/* mount a key directly under HKLM or HKU */
> > +static void mount_key(struct key *key, const WCHAR *subkey, obj_handle_t
> > handle)
> > +{
>
> > +if (!(f = fdopen(fd, "r")))
> > +return;
> > +
> > +/* create the key */
> > +newkey = create_key(key, subkey, NULL, KEY_DIRTY, 0, &created);
> > +if (!newkey)
> > +return;
> > +
> > +/* load the key */
> > +load_keys(newkey, f, -1);
> > +}
>
> I think you leak the FILE * returned from fdopen here. Additionally, if
> dup() or fdopen() fails, no error code will be set, so the code will
> fail silently.
>
> In NtLoadKey(), you should close the file handle "hive" that you open.
>
> Can't you achieve the same effect using the original load_registry
> request, rather than creating a new request? If not, you can also
> remove the load_registry request from protocol.def as I think it's no
> longer used.
Oops this is the wrong (previous) patch. I'll send in the new one.
--
James Hawkins
Re: winetest: code reorder
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > "Ferenc Wagner" <[EMAIL PROTECTED]> wrote: > >> ChangeLog: Check desktop visibility after processing command >>line arguments. > > Why do you need it? There is no point to proceed if the > tests can not run in an appropriate environment. The -s option (submit file, do not run tests) makes sense anyway. But my main reason is that it drove me mad by not obeying the -c option (no GUI) in some test runs. And I don't think it hurts or contradicts your aims. -- Feri.
Re: Support for IDvdInfo2::GetDiscID
Tim Hentenaar wrote: On Sat, 19 Jun 2004 14:42:27 +0100 James Courtier-Dutton <[EMAIL PROTECTED]> wrote: The Windows api method uses the function call IDvdInfo2::GetDiscID http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/htm/idvdinfo2getdiscid.asp This returns a unique 64bit ID for a DVD. Has anyone found out what exactly it does to create this 64bit ID. It would be nice to get linux DVD players to be able to use the same method. If no-one else has figured it out yet, I might try my hand at reverse engineering it just for the hell of it. :P Tim Did you make any progress on this?
Re: winetest: code reorder
"Ferenc Wagner" <[EMAIL PROTECTED]> wrote: > ChangeLog: Check desktop visibility after processing command >line arguments. Why do you need it? There is no point to proceed if the tests can not run in an appropriate environment. -- Dmitry.
Re: [WINEALSA] multiple sound card support patch review needed
On Fri, 25 Mar 2005 11:02:46 +0100, Ferenc Wagner wrote: > I doubt it. First, ALSA have notion of the default device, > which Wine should respect. Indeed, in fact I patched winealsa in the past to use the "default" device instead of talking to the plughw device directly precisely so it was compatible with dmix.
RE: I think I know how uxtheme works...
In copyright law it's the result that matter, not the process. To be protected by copyright law, it must be in tangible form. Looking at disassembled code is permitted by copyright law so it's only a problem if the person doing it lacks self-discipline and uses the disassembled code in a way that violates copyright law. That said, I don't believe there is a need for reverse engineering methods for implementing the majority of ReactOS and WINE. Our goal is to run Windows software on ReactOS and other free operating systems. We have some smart people on these projects. If the Windows software vendors could figure out how to use the interfaces using the public available documentation, then we can certainly implement the interfaces from that same information. If there is an interface that isn't documented, then certainly most Windows software won't use it and there is no need to implement the interface at all. Casper References: >From http://www.nus.edu.sg/intro/slides/02_1_Wilson%20Wong.ppt What is protectable? Functionality? - not protected - must be an "expression...of a set of instructions" - Autodesk Inc v Dyason (Aust): copying function of AutoCAD lock but not code (no infringement) Program Structure? - (cf: plot elements in literary/dramatic works capable of protection) - eg. structural arrangements of modules and subroutines - yes if expression of idea, & no if ideas or functions: difficult line to draw - yes if organisation, sequence, arrangement or compilation - not protectable: elements of software which are: * ideas; * dictated by efficiency or external factors (eg h/w) specs, compatibility reqms, industry standards; or * public domain - not if similarity is due only to similar subject matter * analogy: drawing of a hand * eg any 2 word processors will have some structural similarities > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike McCormack > Sent: 25. marts 2005 10:39 > To: Jonathan Wilson > Cc: wine-devel@winehq.org; [EMAIL PROTECTED] > Subject: Re: I think I know how uxtheme works... > > > Jonathan Wilson wrote: > > What I am doing here is clean-room reverse engineering. > > There's no reason that we need to expose ourselves to any legal risk at > all. It may be your opinion that reading assembly code and describing > it is legal and safe, but I don't agree and I'm sure others who work on > Wine don't either. > > The original IBM BIOS was clean room reverse engineered because there > was not enough documentation available for it. We have MSDN, which is > not 100% complete, but is good enough for most purposes. Other things > can be deduced from test programs. Information that cannot be deduced > by a test program is irrelevant. > > Reverse engineering does not help Wine. Casual observers will assume > that Wine is the result of reverse engineering by disassembly, which is > incorrect and harmful. > > Mike
Re: ipaddress: uniform naming
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > I don't much like hungarian notation. I used to hate it. > Not so much anymore, but that's besides the point. > > Back in the day when I introduced these names they seemed > like a good idea. I was wrong, mea culpa. They are not > particulary good (why capitalize structure members?), > and they don't mix well with the rest of the naming > convention in the other controls. > > They irk me every time I see them, so I'd like to change > them to something saner. I can live with hwndSelf since that's pretty much used everywhere, but do you really need to add Hungarian line noise to the other variables? Exactly how is "nLowerLimit" saner than "LowerLimit"? -- Alexandre Julliard [EMAIL PROTECTED]
Re: saving winrash
Ivan Leo Puoti <[EMAIL PROTECTED]> writes: > Recently winetest is leaving a testdir directory behind > it, so cleanup needs to be done better. This testdir comes from dlls/shell32/tests/shlfolder.c; RemoveDirectoryA in line 78 can fail somehow. Also, the return in line 147 doesn't do the necessary cleanup after CreateFileFolders() in line 144. Having no Windows is really a drag when fixing conformance tests... Btw I'm adding a tag entry dialog to winetest. But not sure if it can delete itself any way... -- Feri.
Re: [WINEALSA] multiple sound card support patch review needed
Paul van Schayck <[EMAIL PROTECTED]> writes: > On Tue, 22 Mar 2005 09:52:13 -0500, Robert Reif <[EMAIL PROTECTED]> wrote: > >> What happens when you have two or more identical cards. >> Should we also look for dmix in the device name? > > I think we should always look for hw:n I doubt it. First, ALSA have notion of the default device, which Wine should respect. On the other hand, using the hw:n device relies on a hardware mixer for sharing the sound card, which some widespread integrated cards don't have. So a lot of users would prefer using plughw:n (or another dmixed device) instead. The ALSA default can be set in ~/.asoundrc or by environmental variables, which is very convenient. Wine shouldn't behave differently unless explicitly configured so. > Doesn't ALSA have some kind of function to discover all devices? Probably not at the moment (except for /proc/asound/cards etc.) It was discussed on the ALSA devel list recently, but I don't remember the conclusions. -- Feri.
Re: I think I know how uxtheme works...
Jonathan Wilson wrote: What I am doing here is clean-room reverse engineering. There's no reason that we need to expose ourselves to any legal risk at all. It may be your opinion that reading assembly code and describing it is legal and safe, but I don't agree and I'm sure others who work on Wine don't either. The original IBM BIOS was clean room reverse engineered because there was not enough documentation available for it. We have MSDN, which is not 100% complete, but is good enough for most purposes. Other things can be deduced from test programs. Information that cannot be deduced by a test program is irrelevant. Reverse engineering does not help Wine. Casual observers will assume that Wine is the result of reverse engineering by disassembly, which is incorrect and harmful. Mike
Re: advapi32: Implement NtLoadKey
James Hawkins wrote:
+/* mount a key directly under HKLM or HKU */
+static void mount_key(struct key *key, const WCHAR *subkey, obj_handle_t
handle)
+{
+if (!(f = fdopen(fd, "r")))
+return;
+
+/* create the key */
+newkey = create_key(key, subkey, NULL, KEY_DIRTY, 0, &created);
+if (!newkey)
+return;
+
+/* load the key */
+load_keys(newkey, f, -1);
+}
I think you leak the FILE * returned from fdopen here. Additionally, if
dup() or fdopen() fails, no error code will be set, so the code will
fail silently.
In NtLoadKey(), you should close the file handle "hive" that you open.
Can't you achieve the same effect using the original load_registry
request, rather than creating a new request? If not, you can also
remove the load_registry request from protocol.def as I think it's no
longer used.
Mike
