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

Re: Add time zone to TZ_Info

by Roger

I agree that PDT should say "Pacific Daylight Time" but whoever wrote this section refered to both ..DT and ..ST as "Standard Time" for some good reason.I assumed so I followed convention. It came up in an app I was running as a fixme since we switched to std time today and is used by TIME_GetTZAsStr(). If it appears beneficial, I'll be happy to change all the ..DT references to "Daylight Time" and resubmit. Duane Clark on Sunday, October 31, 2004 2:34 PM wrote: > Roger Olson wrote: > > RCS file: /home/wine/wine/dlls/ntdll/time.c,v > > retrieving revision 1.51 > > diff -u -u -r1.51 time.c > > --- dlls/ntdll/time.c 22 Oct 2004 19:54:17 -0000 1.51 > > +++ dlls/ntdll/time.c 31 Oct 2004 21:18:46 -0000 > > @@ -105,6 +105,9 @@ > > {"AKDT", > > {'A','l','a','s','k','a','n',' ','S','t','a','n','d','a','r','d',' ','T', > > 'i','m','e','\0'}, 480, 1}, > > + {"PST", > > + {'P','a','c','i','f','i','c',' ','S','t','a','n','d','a','r','d',' ','T', > > + 'i','m','e','\0'}, 480, 0}, > > {"PDT", > > {'P','a','c','i','f','i','c',' ','S','t','a','n','d','a','r','d',' ','T', > > 'i','m','e','\0'}, 420, 1}, > > Hmm... I don't know if anything actually uses the names, but I doubt > these are right. PDT would normally be referred to as Pacific Daylight > Time. Any chance of getting you to add some tests for these? > >

Oct. 31, 2004

Re: Add time zone to TZ_Info

by Duane Clark

Roger Olson wrote: > RCS file: /home/wine/wine/dlls/ntdll/time.c,v > retrieving revision 1.51 > diff -u -u -r1.51 time.c > --- dlls/ntdll/time.c 22 Oct 2004 19:54:17 -0000 1.51 > +++ dlls/ntdll/time.c 31 Oct 2004 21:18:46 -0000 > @@ -105,6 +105,9 @@ > {"AKDT", > {'A','l','a','s','k','a','n',' ','S','t','a','n','d','a','r','d',' ','T', > 'i','m','e','\0'}, 480, 1}, > + {"PST", > + {'P','a','c','i','f','i','c',' ','S','t','a','n','d','a','r','d',' ','T', > + 'i','m','e','\0'}, 480, 0}, > {"PDT", > {'P','a','c','i','f','i','c',' ','S','t','a','n','d','a','r','d',' ','T', > 'i','m','e','\0'}, 420, 1}, Hmm... I don't know if anything actually uses the names, but I doubt these are right. PDT would normally be referred to as Pacific Daylight Time. Any chance of getting you to add some tests for these?

Oct. 31, 2004

Re: signaling unix threads

by Markus Amsler

Jukka Heinonen wrote: >Yep. If using Linux 2.6 kernel and recent pthread library, >threads share the same pid and they must be signalled using >tkill and not kill. > Yes, you're right. I already wondered why dosvm worked before, it was because I used a 2.4 kernel. >The only place which knows how to >correctly signal threads is send_thread_signal function in >server/ptrace.c. So, the easy way to fix signalling is >to use Windows thread identifier for identifying dosvm thread >instead of pids (which don't work anyway) and add to wineserver >a handler that just calls send_thread_signal, which I guess >is what you have been doing, anyway. > > No, I did it much more uglier, that's why I asked the list. Thanks. Alexandre Julliard wrote: >Jukka Heinonen <jhei(a)iki.fi> writes: > > > >>Now, I have tried this approach and it seems to work. I have >>some prototype implementation lying around but I was thinking >>about doing something more complicated at the time, >>like using SIGUSR2 handler for doing Win32 remote operations >>discussed earlier on wine-devel, because signal handler >>is probably running in the correct context for doing >>this kind of things but I guess locking issues are going to >>be pretty complicated so it is probably better to just fix >>dosvm issues with a simple mechanism and not worry about >>anything else. >> >> > >It would certainly be nice if we could convince dosvm to stop using >SIGUSR2, there are lots of other things that could make better use of >it. I don't really have a good solution to offer though (except maybe >getting rid of dosvm altogether ;-) > > What about using a win32 compatible way to signal dosvm thread (I know in win32 there are no signals, but perhaps there's a undocu/hackish way). So one day winedos could compile/run on ReactOS/Windows. I also attached the patch which solves my signalling issues with kernel 2.6.8 and libc 2.3.2. I'm pretty unsure about the wineserver stuff, so comments are welcome. Markus ? thread_kill.diff Index: dlls/winedos/dosvm.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/dosvm.c,v retrieving revision 1.59 diff -u -r1.59 dosvm.c --- dlls/winedos/dosvm.c 4 Aug 2004 19:08:19 -0000 1.59 +++ dlls/winedos/dosvm.c 31 Oct 2004 19:00:30 -0000 @@ -51,6 +51,7 @@ #include "thread.h" #include "dosexe.h" #include "dosvm.h" +#include "wine/server.h" #include "wine/debug.h" #include "excpt.h" @@ -58,6 +59,8 @@ WINE_DECLARE_DEBUG_CHANNEL(module); WINE_DECLARE_DEBUG_CHANNEL(relay); +extern HANDLE dosvm_thread, loop_thread; + WORD DOSVM_psp = 0; WORD DOSVM_retval = 0; @@ -278,11 +281,22 @@ else pending_event = event; if (!old_pending && DOSVM_HasPendingEvents()) { + BOOL success; TRACE("new event queued, signalling (time=%ld)\n", GetTickCount()); /* Alert VM86 thread about the new event. */ - kill(dosvm_pid,SIGUSR2); - + SERVER_START_REQ( send_thread_signal ) + { + req->handle = dosvm_thread; + req->signal = SIGUSR2; + wine_server_call( req ); + success = reply->success; + } + SERVER_END_REQ; + + if (!success) + ERR ("Couldn't alert vm86 thread!\n"); + /* Wake up DOSVM_Wait so that it can serve pending events. */ SetEvent(event_notifier); } else { Index: dlls/winedos/module.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/module.c,v retrieving revision 1.45 diff -u -r1.45 module.c --- dlls/winedos/module.c 18 Oct 2004 21:19:57 -0000 1.45 +++ dlls/winedos/module.c 31 Oct 2004 19:00:31 -0000 @@ -103,9 +103,9 @@ /* global variables */ pid_t dosvm_pid; +HANDLE dosvm_thread, loop_thread; static WORD init_cs,init_ip,init_ss,init_sp; -static HANDLE dosvm_thread, loop_thread; static DWORD dosvm_tid, loop_tid; static void MZ_Launch( LPCSTR cmdtail, int length ); Index: include/wine/server_protocol.h =================================================================== RCS file: /home/wine/wine/include/wine/server_protocol.h,v retrieving revision 1.111 diff -u -r1.111 server_protocol.h --- include/wine/server_protocol.h 18 Aug 2004 00:04:58 -0000 1.111 +++ include/wine/server_protocol.h 31 Oct 2004 19:00:35 -0000 @@ -3095,6 +3095,20 @@ #define SET_GLOBAL_TASKMAN_WINDOW 0x04 + +struct send_thread_signal_request +{ + struct request_header __header; + obj_handle_t handle; + int signal; +}; +struct send_thread_signal_reply +{ + struct reply_header __header; + int success; +}; + + enum request { REQ_new_process, @@ -3274,6 +3288,7 @@ REQ_set_clipboard_info, REQ_open_token, REQ_set_global_windows, + REQ_send_thread_signal, REQ_NB_REQUESTS }; @@ -3458,6 +3473,7 @@ struct set_clipboard_info_request set_clipboard_info_request; struct open_token_request open_token_request; struct set_global_windows_request set_global_windows_request; + struct send_thread_signal_request send_thread_signal_request; }; union generic_reply { @@ -3640,8 +3656,9 @@ struct set_clipboard_info_reply set_clipboard_info_reply; struct open_token_reply open_token_reply; struct set_global_windows_reply set_global_windows_reply; + struct send_thread_signal_reply send_thread_signal_reply; }; -#define SERVER_PROTOCOL_VERSION 149 +#define SERVER_PROTOCOL_VERSION 151 #endif /* __WINE_WINE_SERVER_PROTOCOL_H */ Index: server/protocol.def =================================================================== RCS file: /home/wine/wine/server/protocol.def,v retrieving revision 1.110 diff -u -r1.110 protocol.def --- server/protocol.def 18 Aug 2004 00:04:58 -0000 1.110 +++ server/protocol.def 31 Oct 2004 19:00:39 -0000 @@ -2166,3 +2166,12 @@ #define SET_GLOBAL_SHELL_WINDOWS 0x01 /* set both main shell and listview windows */ #define SET_GLOBAL_PROGMAN_WINDOW 0x02 #define SET_GLOBAL_TASKMAN_WINDOW 0x04 + + +/* send a Unix signal to a specific thread */ +(a)REQ(send_thread_signal) + obj_handle_t handle; /* thread handle */ + int signal; /* the unix signal */ +(a)REPLY + int success; /* wether signaling succeeded */ +(a)END Index: server/request.h =================================================================== RCS file: /home/wine/wine/server/request.h,v retrieving revision 1.102 diff -u -r1.102 request.h --- server/request.h 20 Jul 2004 22:17:39 -0000 1.102 +++ server/request.h 31 Oct 2004 19:00:40 -0000 @@ -280,6 +280,7 @@ DECL_HANDLER(set_clipboard_info); DECL_HANDLER(open_token); DECL_HANDLER(set_global_windows); +DECL_HANDLER(send_thread_signal); #ifdef WANT_REQUEST_HANDLERS @@ -463,6 +464,7 @@ (req_handler)req_set_clipboard_info, (req_handler)req_open_token, (req_handler)req_set_global_windows, + (req_handler)req_send_thread_signal, }; #endif /* WANT_REQUEST_HANDLERS */ Index: server/thread.c =================================================================== RCS file: /home/wine/wine/server/thread.c,v retrieving revision 1.103 diff -u -r1.103 thread.c --- server/thread.c 27 Oct 2003 22:10:22 -0000 1.103 +++ server/thread.c 31 Oct 2004 19:00:41 -0000 @@ -1022,3 +1022,15 @@ release_object( thread ); } } + +/* send a Unix signal to a specific thread */ +DECL_HANDLER(send_thread_signal) +{ + struct thread *thread; + + if ((thread = get_thread_from_handle( req->handle, THREAD_SUSPEND_RESUME ))) + { + reply->success = send_thread_signal( thread, req->signal ); + release_object( thread ); + } +} Index: server/trace.c =================================================================== RCS file: /home/wine/wine/server/trace.c,v retrieving revision 1.214 diff -u -r1.214 trace.c --- server/trace.c 22 Sep 2004 02:46:38 -0000 1.214 +++ server/trace.c 31 Oct 2004 19:00:45 -0000 @@ -2548,6 +2548,17 @@ fprintf( stderr, " old_taskman_window=%p", req->old_taskman_window ); } +static void dump_send_thread_signal_request( const struct send_thread_signal_request *req ) +{ + fprintf( stderr, " handle=%p,", req->handle ); + fprintf( stderr, " signal=%d", req->signal ); +} + +static void dump_send_thread_signal_reply( const struct send_thread_signal_reply *req ) +{ + fprintf( stderr, " success=%d", req->success ); +} + static const dump_func req_dumpers[REQ_NB_REQUESTS] = { (dump_func)dump_new_process_request, (dump_func)dump_get_new_process_info_request, @@ -2726,6 +2737,7 @@ (dump_func)dump_set_clipboard_info_request, (dump_func)dump_open_token_request, (dump_func)dump_set_global_windows_request, + (dump_func)dump_send_thread_signal_request, }; static const dump_func reply_dumpers[REQ_NB_REQUESTS] = { @@ -2906,6 +2918,7 @@ (dump_func)dump_set_clipboard_info_reply, (dump_func)dump_open_token_reply, (dump_func)dump_set_global_windows_reply, + (dump_func)dump_send_thread_signal_reply, }; static const char * const req_names[REQ_NB_REQUESTS] = { @@ -3086,6 +3099,7 @@ "set_clipboard_info", "open_token", "set_global_windows", + "send_thread_signal", }; /* ### make_requests end ### */

Oct. 31, 2004

Re: Countering arguments against Wine

by Brian Vincent

On Sun, 31 Oct 2004 01:26:21 -0800, Jim White <jim(a)pagesmiths.com> wrote: > Thank you indeed Dan! If I encounter Mike Hearn yet again with his > "Darwine is Pointless" arguments I can sed 's/Wine/Darwine/ s/Linux/Mac > OS X/' in reply to him. Huh? I just went back through the archives and couldn't find any reference like that. Do you have a link to the thread or was it a private email? The closest I saw was this exchange where you wrote: "This is the more general project that has emerged from my initial idea for Darwine, namely X86/Linux binary compatibility for OS X. " Mike replied: "Hmm, what is that useful for? Nearly all software for Linux is open source and can be ported or sometimes simply recompiled for any given platform." That wasn't speaking about Wine. -Brian

Oct. 31, 2004

Re: Default System Colors

by William Poetra Yoga H

--- Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > The colors of your gnome/kde desktop don't map that nicely to windows > colors. Because of this the end-result won't allways be very nice. In the > future we might want something like this. The best way to add something like > this is to finish our uxtheme dll and add support for theming to all > controls. Then WineLook=win95 (or winxp) will give you the "classic" colors > and lets say "uxtheme" will give everything the look and feel of lets say > gtk/qt. (this is how windows xp does its theming too) > > Roderick > Please reply below the original post. Yeah, agreed. Your idea is good, and we just have to wait for uxtheme.dll to finish. But in the meantime is it ok for us to change the default colors? Because the Win95 colors are just too... dull. And my "gradient colors for caption bar" patch will make WINE's windows look nice if Win2K/XP colors are applied... _IF_ my gradient-colors-patch will ever get accepted, because until now it's not been applied yet... (but that's for another thread :-P) __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

Oct. 31, 2004

Re: Default System Colors

by William Poetra Yoga H

--- Stefan D�singer <stefandoesinger(a)gmx.at> wrote: > How about using the color setting from the X11 environment? Wine could read > it > on startup and convert it to registry keys. > Yes, we could do that, but I don't think it's a good idea. Windows programs are meant to be run on Windows, and people coming from Windows (I used to do Windows a few years back) expect the colors to match the ones on Windows, regardless of the colors of the current desktop environment. We could make it an option instead, and make the Win2K colors the default. But my patch hasn't been merged :'( Don't know why... __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

Oct. 31, 2004

Re: Default System Colors

by Stefan Dösinger

> So now, should we change the default system colors for WINE, from win95 to > winxp (classic)? I really think it looks a lot better with the new colors, > as the win95 colors are too dull (MS certainly must have done a lot of > research into this). How about using the color setting from the X11 environment? Wine could read it on startup and convert it to registry keys.

Oct. 31, 2004

Re: Listview notify_dispinfoT Messageformat

by Dimitrie O. Paun

On Sun, Oct 31, 2004 at 10:50:33AM +0000, Robert Shearman wrote: > Yes, that is correct. It would be a lot better to use a boolean flag > rather than storing the actual format code so that: > if (infoPtr->notifyFormat == NFR_UNICODE) > becomes: > if (infoPtr->bUnicode) Maybe a bit simpler yes, but surely not a lot :) Anyway, this flag is tested for NFR_* only _once_ in a 10000 line file, so I actually think that sticking to the standard is a better option here. > The old code does indeed send the correct notifications. Maybe there was > a bug in the function somewhere that prompted Aric to make his change. > However, the code could be a lot simpler by doing conversions from A to > W on incoming messages and then only doing W to A conversions for the > notifications, rather than the matrix of 4 cases you described above. Oh, come on, it was just a few more lines of code. In fact, I was happy with the code as it standed (that's no surprise, as I wrote it :)). I think we should just revert to it, and accept changes only with supporting tests. At the time that Aric submitted the patch, I was rather unhappy with it, but he claimed he performed extensive tests that proved that behaviour. He should have submitted them as part of the test suite. -- Dimi.

Oct. 31, 2004

Re: Listview notify_dispinfoT Messageformat

by Robert Shearman

Dimitrie O. Paun wrote: >On Wed, Oct 27, 2004 at 09:28:33PM +0100, Robert Shearman wrote: > > >>To summarise: *all* common control notifications should be sent in the >>same format (ANSI/Unicode) as their parent (except if overriden by the >>CCS_SETUNICODEFORMAT message). It should not be based on the message >>sent to the control. >> >> > >Just to be 100% clear: > -- what do you mean by "in the same format as their parent"? > The format is retrieved using the WM_NOTIFYFORMAT message, but can be overridden by CCM_SETUNICODEFORMAT. > From your patch, it seems that: > 1. In WM_CREATE, we have to query the notify format as such: > > infoPtr->hwndNotify = lpcs->hwndParent; > infoPtr->notifyFormat = SendMessageW(infoPtr->hwndNotify, WM_NOTIFYFORMAT, > (WPARAM)infoPtr->hwndSelf, (LPARAM)NF_QUERY); > > Yes, that is correct. It would be a lot better to use a boolean flag rather than storing the actual format code so that: if (infoPtr->notifyFormat == NFR_UNICODE) becomes: if (infoPtr->bUnicode) > 2. Handle WM_NOTIFYFORMAT, by querying the parent again: > > infoPtr->notifyFormat = SendMessageW(hwndFrom, WM_NOTIFYFORMAT, (WPARAM)infoPtr->hwndSelf, NF_QUERY); > Yes. It should also handle the NF_QUERY case in the WM_NOTIFYFORMAT handler so that child windows, like the header control, will get a sane value. > 3. When sending notifications, convert to ASCII iff infoPtr->notifyFormat == NFR_ANSI > > > If so, this is what we had before Aric did this change: > http://cvs.winehq.org/cvsweb/wine/dlls/comctl32/listview.c.diff?r1=1.330&r2… > What was wrong with the code before? It tried to send the notification > in the format specified by infoPtr->notifyFormat. The dependance on > the the type of message that was sent to the control is just to do > the conversion when we have to. That is: > > fmt-of-msg-sent-to-ctrl infoPtr->notifyFormat conversion-required > !isW (ASCII) NFR_ANSI no > isW (Unicode) NFR_ANSI yes > !isW (ASCII) NFR_UNICODE yes > isW (Unicode) NFR_UNICODE no > > The old code looked as isW only to determine if any conversion was required > (which I think you have to), but the format of the actual notification was > strictly determined by infoPtr->notifyFormat: > > if (infoPtr->notifyFormat == NFR_ANSI) > realNotifCode = get_ansi_notification(notificationCode); > else > realNotifCode = notificationCode; > bResult = notify_hdr(infoPtr, realNotifCode, (LPNMHDR)pdi); > > So, what was wrong with the original code? > > The old code does indeed send the correct notifications. Maybe there was a bug in the function somewhere that prompted Aric to make his change. However, the code could be a lot simpler by doing conversions from A to W on incoming messages and then only doing W to A conversions for the notifications, rather than the matrix of 4 cases you described above. > -- CCS_SETUNICODEFORMAT message: this is a flag, not a message, no? If so, what is > its semantics? If set, we have to ignore infoPtr->notifyFormat, and always send > notifications in Unicode format? > > That was a mistake. I meant CCM_SETUNICODEFORMAT. (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl…) >It's important to figure this one once and for all, so that we can fix all the >controls properly. > > Rob

Oct. 31, 2004

Re: Countering arguments against Wine

by Jim White

Holly Bostick wrote: > Dan Kegel wrote: > >> I've run into people several times who dislike the >> fact that I advocate or even work on the Wine project, >> ... >> Dan >> > > Dan, first of all, thanks for writing that dowm. Thank you indeed Dan! If I encounter Mike Hearn yet again with his "Darwine is Pointless" arguments I can sed 's/Wine/Darwine/ s/Linux/Mac OS X/' in reply to him. Jim White

Oct. 31, 2004