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

Re: CoGetClassObject and multiple servers requested

by Marcus Meissner

On Tue, May 28, 2002 at 09:16:45AM -0700, Medland, Bill wrote: > (I guess this is for Marcus) > > I thought I had heard something about Local Server COM being in place now > but when I went to try it with our product I saw no attempt to do it (error > message about CLSCTX_LOCAL_SERVER registered but not supported). > > So I looked at CoGetClassObject and I see that the Remote_CoGetClassObject > (which I presume is attempting to do the LOCAL_SERVER) is only called if a > local server is requested and an inproc server or handler is not. > > Is there a good reason why the Remote_CoGetClassObject is not called on > failure to detect a registered inproc server or handler (which the existing > structure of the function supported)? No, there is no good reason. I was just guessing here. Feel free to adapt the logic. Ciao, Marcus

May 28, 2002

Re: Why start a COM local server twice?

by Marcus Meissner

On Tue, May 28, 2002 at 11:25:52AM -0700, Medland, Bill wrote: > Is this an oversight or a deliberate policy? > > Remote_CoGetClassObject creates the local server process and hands over to > create_marshalled_proxy > If create_marshalled_proxy can't immediately find the pipe then it will > create the process again. > > Is it safe to drop the first one? How about the second? It looks to me as > if Remote_CoGetClassObject is the only place that calls > create_marshalled_proxy so I presume we can remove either. Yes. I have tested following patch with dw4 install. Ciao, Marcus License: LGPL Changelog: Dropped superflous Remote_CoGetClassObject() (entirely contained in create_marshalled_proxy()). Index: compobj.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/compobj.c,v retrieving revision 1.55 diff -u -r1.55 compobj.c --- compobj.c 9 Mar 2002 23:39:09 -0000 1.55 +++ compobj.c 28 May 2002 21:40:28 -0000 @@ -1293,42 +1293,6 @@ return hr; } -static HRESULT WINAPI Remote_CoGetClassObject( - REFCLSID rclsid, DWORD dwClsContext, COSERVERINFO *pServerInfo, - REFIID iid, LPVOID *ppv -) { - HKEY key; - char buf[200]; - HRESULT hres = E_UNEXPECTED; - char xclsid[80]; - WCHAR dllName[MAX_PATH+1]; - DWORD dllNameLen = sizeof(dllName); - STARTUPINFOW sinfo; - PROCESS_INFORMATION pinfo; - - WINE_StringFromCLSID((LPCLSID)rclsid,xclsid); - - sprintf(buf,"CLSID\\%s\\LocalServer32",xclsid); - hres = RegOpenKeyExA(HKEY_CLASSES_ROOT, buf, 0, KEY_READ, &key); - - if (hres != ERROR_SUCCESS) - return REGDB_E_CLASSNOTREG; - - memset(dllName,0,sizeof(dllName)); - hres= RegQueryValueExW(key,NULL,NULL,NULL,(LPBYTE)dllName,&dllNameLen); - if (hres) - return REGDB_E_CLASSNOTREG; /* FIXME: check retval */ - RegCloseKey(key); - - TRACE("found LocalServer32 exe %s\n", debugstr_w(dllName)); - - memset(&sinfo,0,sizeof(sinfo)); - sinfo.cb = sizeof(sinfo); - if (!CreateProcessW(NULL,dllName,NULL,NULL,FALSE,0,NULL,NULL,&sinfo,&pinfo)) - return E_FAIL; - return create_marshalled_proxy(rclsid,iid,ppv); -} - /*********************************************************************** * CoGetClassObject [COMPOBJ.7] * CoGetClassObject [OLE32.16] @@ -1389,7 +1353,9 @@ if (((CLSCTX_LOCAL_SERVER) & dwClsContext) && !((CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER) & dwClsContext)) - return Remote_CoGetClassObject(rclsid,dwClsContext,pServerInfo,iid,ppv); + return create_marshalled_proxy(rclsid,iid,ppv); + + /* remote servers not supported yet */ if ( ((CLSCTX_REMOTE_SERVER) & dwClsContext)

May 28, 2002

Re: AppDB: A call for moderation ;-P

by Andriy Palamarchuk

On Sat, May 25, 2002 at 02:48:31PM -0700, Dustin Navea wrote: > After looking at the appdb, and seeing all these > seemingly random posts for help and the replies, i.e. > using winex over wine for games... I decided to call > for some moderation and cleanup on the AppDB. > > I think that the appdb needs several things done to it > to make it more functional and "user-friendly": > > 1) It needs moderators! I need a little time to compile a list of application owners (as always :-( ). They will do moderation for their applications. Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 28, 2002

Bug 717 - Was Re: [Bug 717] Changed - StarCraft Icons not created by wineshelllink

by Dustin Navea

--- wine-bugs(a)winehq.com wrote: > http://bugs.winehq.com/show_bug.cgi?id=717 > > *** shadow/717 Sun May 26 12:09:57 2002 > --- shadow/717.tmp.5845 Sun May 26 20:43:23 2002 > *************** > *** 149,151 **** > --- 149,158 ---- > > ------- Additional Comments From > Speeddymon(a)yahoo.com 2002-05-26 12:09 ------- > Changing CC's > + > + ------- Additional Comments From apa3a(a)yahoo.com > 2002-05-26 20:43 ------- > + Advise to discuss this issue on wine-devel. Not > everybody reviews Bugzilla logs. > + > + One more approach - if a target of a shell link > does not exist create a dummy > + target with some "UNKNOWN" icon, which will be > replaced later. I like this > + approach more. > \ No newline at end of file Here it is. Well, after looking at the code, I found out that it does create a key in RunOnce to create the icon after reboot, but the icon never gets created, I didn't do much investigation into why, but I do believe that the initialization of wine doesn't read RunOnce and so therefore the icons never get created. Also, after some more investigation, I found out that StarCraft.exe and StarEdit.exe don't get created until after the Windows Start Menu links get copied, so what needs to be done is either implement the runonce reading in wine init, or create an initscript that reads it and creates the icons with wineshelllink upon reboot, OR we can force icon extraction to be delayed somehow until after all other files have been extracted... I personally like the 2nd idea best, as it is 1) the easiest and 2) actually goes with the trace message of "Deferring Icon Creation to Reboot"... Actually, The 2nd idea could even go into the initscript that is posted in bugzilla already, its under one of the early bugs, the one about being able to double click the exe and it runs... -Dustin __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 28, 2002

Why start a COM local server twice?

by Medland, Bill

Is this an oversight or a deliberate policy? Remote_CoGetClassObject creates the local server process and hands over to create_marshalled_proxy If create_marshalled_proxy can't immediately find the pipe then it will create the process again. Is it safe to drop the first one? How about the second? It looks to me as if Remote_CoGetClassObject is the only place that calls create_marshalled_proxy so I presume we can remove either. Bill

May 28, 2002

Re: shlwapi shreg tests failed

by Sylvain Petreolle

> Ok, I've put my test results at > > http://www.astro.gla.ac.uk/users/paulm/wine/test-out > and my config file at > http://www.astro.gla.ac.uk/users/paulm/wine/conf > > For me, all the tests pass for wine working as > winme. Could you compare my > conf with yours, and see if there's anything > radically different? (its > mostly just stock) My files: config http://us.f1.yahoofs.com/users/7076b56a/bc/logs/config?bcc4888AUC.yWOZc test_winme http://us.f1.yahoofs.com/users/7076b56a/bc/logs/test_out_winme?bcc4888AvQpQ… Note that test with win31,win95 and win98 fail exactly the same as in test_winme. > > Also, if it is possible, it would be useful if you > could try running the > tests with wine running as win98 (for example). > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

May 28, 2002

Re: Lower bugs changing note

by Andriy Palamarchuk

--- Dustin Navea <speeddymon(a)yahoo.com> wrote: > The changes on the lower numbered bugs are done by > me, > trying to get some of these old bugs out of he list > of > ones to be worked on, if they have been fixed..... I noticed :-) Dustin, thank you for the great work you do. It was long overdue to clean these old issues. I have some comments - sometimes you mark as resolved and ask to reopen if the bug still exists bugs with very nice reports. I think this is good approach when you can't check whether the problem still exists or for some obscure applications, but many of the bug reports you closed are short, nice and consious. I think better approaches with these sort of bug reports is: a) try to reproduce yourself - the best approach. Your confirmation in the bug comments is very important for developer who may try to fix the issue. b) if research looks complex - a half a way to solving a bug, you can add comment, smth like "Needs to be confirmed". In both cases bug can be assigned to the component owner. c) ask to confirm without resolving the bug All these approaches insure that bug report won't be forgotten and this can happen if the bugs are just marked as "resolved". Could you try to go through the old bugs you marked as resolved? I already started to do this. I'll leave my comments in the bugs I reviewed. Thanks, Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 28, 2002

CoGetClassObject and multiple servers requested

by Medland, Bill

(I guess this is for Marcus) I thought I had heard something about Local Server COM being in place now but when I went to try it with our product I saw no attempt to do it (error message about CLSCTX_LOCAL_SERVER registered but not supported). So I looked at CoGetClassObject and I see that the Remote_CoGetClassObject (which I presume is attempting to do the LOCAL_SERVER) is only called if a local server is requested and an inproc server or handler is not. Is there a good reason why the Remote_CoGetClassObject is not called on failure to detect a registered inproc server or handler (which the existing structure of the function supported)? Bill

May 28, 2002

Keyboard layout detection not working??

by Shachar Shemesh

Hi all, I am using Debian SID with KDE. In KDE, I defined two keyboard layouts (US and IL). I tried to add Israeli keyboard detection using the attached patch (layout.diff). When trying to test that patch, however, I perform the following task: I type in the command as suggested in the docs (wine --debugmsg +key,+keyboard >& key.log). Attached are two run attempts. key.log is with the US keyboard selected, key2.log is with the Hebrew keyboard selected. Comparing the two outputs, several things become evident: 1. The Israeli keyboard is not detected. It fails to match even the non-Hebrew characters (such as the '/' instead of lower case 'q'). It's as if WINE did not notice that a non-English keymap was installed. On the other hand, there are some differences between the two runs. What's going on? 2. The dvorak keyboard has 0 mismatches???? I noticed that the code has some different virtual mapping of the keyboard. I am not aware that dvorak keyboards generate a different scan code mapping. Am I missing something here? 3. There does not appear to be any code that detects layout changes in X11, and sends the apropriate WM_INPUTLANGCHANGE message. I understood that implementing an event trigered by X layout change is a difficult matter, but it is highly necessary for my BiDi support (many programs, including Office, know the current direction, and have visual representation when it changes. Not implementing this message may prove to be problematic in that respect). I currently don't have the capacity to go after this particular problem, but if it remains unsolved by the time it becomes crucial to me, I will. If anyone has any leads on solving this problem, please let me know. I have entered bug #735 on this issue. Many thanks for your input, Shachar Index: dlls/x11drv/keyboard.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/keyboard.c,v retrieving revision 1.1 diff -u -r1.1 keyboard.c --- dlls/x11drv/keyboard.c 30 Apr 2002 21:16:39 -0000 1.1 +++ dlls/x11drv/keyboard.c 28 May 2002 13:20:04 -0000 @@ -531,6 +531,15 @@ "zZ","xX","cC","vV","bB","nN","mM","öÖ","çÇ",".:" }; +/*** Israeli keyboard layout */ +static const char main_key_IL[MAIN_LEN][4] = +{ + "`~","1!","2@","3#","4$","5%","6^","7&","8*","9(","0)","-_","=+", + "/Q","'W","÷E","øR","àT","èY","åU","ïI","íO","ôP","[{","]}", + "ùA","ãS","âD","ëF","òG","éH","çJ","ìK","êL","ó:",",\"","\\|", + "æZ","ñX","áC","äV","ðB","îN","öM","ú<","õ>",".?" +}; + /*** VNC keyboard layout */ static const WORD main_key_scan_vnc[MAIN_LEN] = { @@ -600,6 +609,7 @@ {"Latin American keyboard layout", 28591, &main_key_LA, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Lithuanian (Baltic) keyboard layout", 28603, &main_key_LT_B, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Turkish keyboard layout", 28599, &main_key_TK, &main_key_scan_qwerty, &main_key_vkey_qwerty}, + {"Israeli keyboard layout", 28598, &main_key_IL, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"VNC keyboard layout", 28591, &main_key_vnc, &main_key_scan_vnc, &main_key_vkey_vnc}, {NULL, 0, NULL, NULL, NULL} /* sentinel */

May 28, 2002

Re: Improvement for GetTimeZoneInformation

by Huw D M Davies

On Mon, May 27, 2002 at 11:12:07PM -0400, Vincent Béron wrote: > I need some help to finish this implementation. I don't have access to > an english version of Windows NT4 or 2K or XP, so I couldn't finish the > array of the timezones. COuld somebody help me a bit on this one? I'm > planning on actually writing the equivalence in Unix timezones, so you > only need to give me the names of the Windows timezones. I have a small > program to help you if you need it. > > Changelog: > - Improves the implementation of GetTimeZoneInformation. Missing some > Windows timezone names. In Windows there's a whole load of TimeZone information under \HLKM\Software\Microsoft\Windows\CurrentVersion\Time Zones I expect we should read the data from there rather than hardcode it; all we'd need to add would be a lookup table of Unix TZ names. Huw.

May 28, 2002