April 2007 - Wine-Devel - list.winehq.org

Re: wineshelllink: fall back to $HOME if $HOME/Desktop does not exist
by Jeff L April 21, 2007

April 21, 2007

Lei Zhang wrote: > Hi, > > As reported in bug 7373, some people do not have a Desktop directory > in their home directory. Wineshelllink should fall back to putting > .desktop files in the home directory if the Desktop directory does not > exist. Is there a reason why we should not just create a Desktop directory? Seems neater than cluttering up the home. Jeff

4 6

Re: Fix xcopy so output is either unicode (console) or oem (file)
by Dmitry Timoshkov April 21, 2007

April 21, 2007

"Ann & Jason Edmeades" <us(a)edmeades.me.uk> wrote: > +/* ========================================================================= > + * Output a formatted unicode string. Ideally this will go to the console > + * and hence required WriteConsoleW to output it, however if file i/o is > + * redirected, it needs to be WriteFile'd using OEM (not ANSI) format > + * ========================================================================= */ > +int XCOPY_wprintf(const wchar_t *format, ...) { The described above behaviour should be implemented either inside of wprintf implementation in msvcrt, or inside of the console driver of WriteConsoleW depending on the test results IMO. That's why I asked you to solve msvcrt and console output problems separately. Also please do not introduce wchar_t, use WCHAR instead. -- Dmitry.

1 0

Whats the approved technique to restier a dll in registry
by Jeff L April 21, 2007

April 21, 2007

There seems to be two ways to do this, add the entries to wine.inf or set the dll up as self registering. There are examples of both in wine and the discussion seems to favour self registering but people still seem to be adding registry entries to wine.inf. A bit of guidance would be appreciated. Jeff Latimer

1 0

[programs/uninstaller] fixed patch, but there is a problem somewhere else...
by Tom Spear April 20, 2007

April 20, 2007

With James' help, I managed to get the uninstaller patch done up right, however, I am running into a small problem. The way I had originally done the array at the top of FetchUninstallInformation was not correct, however it allowed for proper functionality. HKEY hkeyroot[numrootkeys]; hkeyroot[0] = HKEY_CURRENT_USER; hkeyroot[1] = HKEY_LOCAL_MACHINE; With that code, I can open the uninstaller, and see all of the uninstall entries. With the following, correct code: HKEY hkeyroot[] = { HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE }; When I open the uninstaller, the first uninstall entry is not shown (and from what I can tell in the additional traces that I put in, looks like it is not even being found). However, when I type something into the filter editbox, like the first letter of that entry that is missing, it appears. The same function is being called with the dialog first opens as is being called when the dialog refreshes. If I type into the filter field, and then select something and hit uninsall, and then cancel the uninstall, the window updates again, and the first entry disappears again. Like I said, the UNINSTALL calls UpdateList, the INITDIALOG calls UpdateList, and the FILTER calls UpdateList as well, however in UNINSTALL and INITDIALOG cases the first entry does not appear. I think the problem is somewhere else in wine, but I cannot confirm this right now without doing a trace+all, and I am leaving work for the weekend.. The patch and registry file I am using are attached if anyone wants to look into this while I am gone. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

1 0

Re: [resend]gdi32 : Completes WidenPath implementation
by Alexandre Julliard April 20, 2007

April 20, 2007

Laurent Vromman <laurent(a)vromman.org> writes: > elp = HeapAlloc( GetProcessHeap(), 0, size ); > - > + lp = HeapAlloc( GetProcessHeap(), 0, sizeof(LOGPEN)); > GetObjectW( dc->hPen, size, elp ); > + > + obj_type = GetObjectType(dc->hPen); > + if(obj_type == OBJ_PEN) { > + memcpy(lp, elp, sizeof(LOGPEN)); > + penStyle = lp->lopnStyle; > + } > + else if(obj_type == OBJ_EXTPEN) { > + penStyle = elp->elpPenStyle; > + } > + else { > + SetLastError(ERROR_CAN_NOT_COMPLETE); > + return FALSE; > + } There's no reason to make a copy of the structure, a typecast would work just as well. Also you are leaking memory here. -- Alexandre Julliard julliard(a)winehq.org

1 0

gethostbyname(my_name) and IL2-Sturmovik CONTINUED
by Briareos April 20, 2007

April 20, 2007

Hello list, I want to continue a discussion about a problem already reported by David Nolden in December 2005. It is about what gethostbyname should return if given the machines name and does not only affect IL-2 Sturmovik. Placing a quick cite of him here: [...] The Problem: gethostbyname(own_name) always returns 127.0.0.1. [...] The socket is then bound to the ip-adress 127.0.0.1, and to it's corresponding loopback-interface, so it's unusable. Any connection-request times out. [...] All the discussion back then happened (in wine-devel) between the 12.12.2005 and 14.12.2005. Subject: "gethostbyname(my_name) and IL2-Sturmovik" And a Patch: wine-patches: 17.01.2006 02:00:21 Subject: gethostbyname-patch Check also Bug #7929 (duplicated by #8075). My opinion is simple: To me it's logical that you get 127.0.0.1 when pinging your local hostname, but if windows does give the IP of your NIC then wine should do as well - as we want to reach compatibility. If, on the other hand, you say it's simply bad programming done by the app-developer if he tries to fetch the IP of the NIC that way, I'd say let's still comply to it, because its more likely than having a programmer expecting to get 127.0.0.1 when asking for "localhostname". Any comments welcome!

3 2

secur32: invert error handling conditions in order to decrease indentation in secur32/wrapper.c.
by Yuval Fledel April 20, 2007

April 20, 2007

> On Saturday 14 April 2007 00:56, Yuval Fledel wrote: > > - the patch is a no-op. > > While I like to do the same to functions I work on, is there any reason you > need to change this for wrapper.c? It hasn't been changed for quite a while > and seems feature complete. > > Kai Hi Kai, Please reply-to-all next time. I've found your reply on the archive. I'm working on schannel at the moment. schannel is not a regular SSP, and the functions in wrapper.c can't load native. I've implemented the proper loading code in my local tree and I'm sending it in obvious pieces. no-op cleanups is the first step. I could implement schannel as a normal SSP and use the current code. However, if I can do something closer to what native does, I'd better do it. Not that loading native schannel is a piece of cake. It does require faking lsass (done), and implementing lots of functions everywhere (userenv, crypt32, ntdll, rsaenh: I'll send after a cleanup and writing tests). The current stage is that native schannel loads and initializes, but builtin rsaenh does not supply everything it needs, so it can't complete the ssl handshake. Native rsaenh requires unimplemented stuff in ntdll. On Saturday 14 April 2007 00:56, Detlef wrote: > I suggest to modify only one Function per Patch > (max. two Functions, when they work together and the total Patch-size > is small). Will do. -- Yuval Fledel

3 3

Re: wine.inf: update registry key
by Dmitry Timoshkov April 20, 2007

April 20, 2007

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > Hi, this fixes bug #7953 -> http://bugs.winehq.org/show_bug.cgi?id=7953 > Vitaly said this one won't go as it might break another app, but i don't > get that , as the key in windows looks quite the same, No it doesn't in the default Windows setup, and the key was changed for a reason to make Picasa work some time ago: http://source.winehq.org/git/wine.git/?a=commitdiff;h=f03c86a27387cd1dc27c3… -- Dmitry.

2 2

Re: Move console input/output codepages to server
by Kirill K. Smirnov April 20, 2007

April 20, 2007

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > > @@ -141,12 +138,19 @@ HWND WINAPI GetConsoleWindow(VOID) > > */ > > UINT WINAPI GetConsoleCP(VOID) > > { > > - if (!console_input_codepage) > > + BOOL ret; > > + UINT codepage = GetOEMCP(); /* default value */ > > + > > + SERVER_START_REQ(get_console_input_info) > > { > > - console_input_codepage = GetOEMCP(); > > - TRACE("%u\n", console_input_codepage); > > + req->handle = 0; > > + ret = !wine_server_call_err( req ); > > + if (ret && reply->codepage) > > + codepage = reply->codepage; > > Did you test what happens when an app sets console code page to a pseudo > cp like CP_ACP (0)? Your code will force code page to be always equal to > what GetOEMCP returns in that case. IsValidCodePage will fail. App is not allowed to pass CP_ACP, CP_OEMCP and other pseudo codepages to these function. #include <windows.h> int main(void) { printf("%d\n", IsValidCodePage(CP_ACP)); printf("%d\n", IsValidCodePage(CP_OEMCP)); SetConsoleCP(CP_ACP); printf("%d\n", GetConsoleCP()); SetConsoleOutputCP(CP_ACP); printf("%d\n", GetConsoleOutputCP()); SetConsoleCP(CP_OEMCP); printf("%d\n", GetConsoleCP()); SetConsoleOutputCP(CP_OEMCP); printf("%d\n", GetConsoleOutputCP()); return 0; } Small test: This will write under both wine and windows: 0 0 866 866 866 866 If change codepage to cp1251 via chcp, output will be: 0 0 1251 1251 1251 1251 So my code is OK. -- Kirill

1 0

Re: iphlpapi: Only call res_init() once per process
by Kai Blin April 20, 2007

April 20, 2007

On Wednesday 18 April 2007 20:39, Hans Leidekker wrote: > +static int resolver_initialised; Shouldn't that be static int resolver_initilised = 0; here? I thought that in C, ints aren't initialized to 0 automatically. > +/* call res_init() just once because of a bug in Mac OSX 10.4 */ > +static void initialise_resolver( void ) > +{ > + if (!resolver_initialised) > + { > + res_init(); > + resolver_initialised = 1; > + } > +} Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

4 4