- Wine-Devel - list.winehq.org

Fwd:Novell client
by Ivan Leo Puoti Aug. 4, 2004

Aug. 4, 2004

new ad request.

1 0

Re: Wine and locales
by Dmitry Timoshkov Aug. 4, 2004

Aug. 4, 2004

"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > In an attempt to get away from a possibly confusing subject line, and to > converge on an agreed behavior, here is an attempt to clear the desired > locale behavior Wine should have. Dmitry (and anyone else), please > comment on this table where you think there are errors in it, and say > what should be there. > > In the "Unix setting", I'm always assuming that LC_ALL overrides > whatever is written in that column, and that LANG is used if neither > LC_ALL nor the column are set. I said it many times already, and I'll repeat once more: Windows has only one active locale which defines all the things you mentioned in the table except language of the interface which let's set aside to not confuse each other. There is no need to try to find appropriate mappings for LC_TYPE or anything else you find in the output of the 'locale' command. But still (almost) any locale setting you want to modify in the win32 environment on a per user basis can be done either by running Control Panel/Regional Options, or modifying the registry or win.ini directly. By default all locale data are set according to the global system locale. Any attempt to have more than one active locale simultaneously will lead to confusion and nothing else, be it unix environment or win32. -- Dmitry.

5 40

Re: winedos: dos debugger support
by markus.amsler＠oribi.org Aug. 4, 2004

Aug. 4, 2004

Quoting Andreas Mohr <andi(a)rhlx01.fht-esslingen.de>: > What does this patch do? Does it do what I believe it does?? :-) > (finally provide useful debugging for DOS programs launched by Wine?) Yeahp. For Debugging .com files you also have to apply the EXEC fix patch [1]. For line editing support, apply BUFFERED INPUT patch [5]. Tested Debuggers (for more see [2]): - Microsoft's debug.exe - ddeb.exe (my favorite) [3] - debug.com (with source) [4] Markus [1] http://www.winehq.org/hypermail/wine-patches/2004/08/0044.html [2] http://www.programmersheaven.com/zone5/cat188/ [3] http://www.programmersheaven.com/zone5/cat188/26391.htm [4] http://www.programmersheaven.com/zone5/cat188/2025.htm [5] http://www.winehq.org/hypermail/wine-patches/2004/08/0043.html

1 0

Re: ListView fixes for Diamond (Try 2)
by Robert Shearman Aug. 4, 2004

Aug. 4, 2004

Filip Navara wrote: > Changelog: > - Don't update infoPtr->dwStyle in LISTVIEW_WindowProc. It's already > handled in LISTVIEW_StyleChanged and LISTVIEW_Create processing. > - Ignore WS_VSCROLL/WS_HSCROLL flags in infoPtr->dwStyle because it's > not always up-to-date. > - Fix TOOLBAR_DrawMasked to correctly use image list mask. > > - Filip > >------------------------------------------------------------------------ > >Changelog: >- Don't update infoPtr->dwStyle in LISTVIEW_WindowProc. It's already > handled in LISTVIEW_StyleChanged and LISTVIEW_Create processing. >- Ignore WS_VSCROLL/WS_HSCROLL flags in infoPtr->dwStyle because it's > not always up-to-date. >- Fix TOOLBAR_DrawMasked to correctly use image list mask. > >--- comctl32/listview.c Sat Jul 31 22:07:42 2004 >+++ comctl32/listview.c Wed Aug 4 00:19:30 2004 > > ... >--- comctl32/toolbar.c Sat Jul 31 22:07:14 2004 >+++ comctl32/toolbar.c Wed Aug 4 00:19:34 2004 >@@ -658,8 +658,7 @@ > > /* Create src image */ > hdcImage = CreateCompatibleDC(hdc); >- hbmImage = CreateBitmap(cx, cy, GetDeviceCaps(hdc,PLANES), >- GetDeviceCaps(hdc,BITSPIXEL), NULL); >+ hbmImage = CreateCompatibleBitmap(hdc, cx, cy); > SelectObject(hdcImage, hbmImage); > ImageList_DrawEx(himl, index, hdcImage, 0, 0, cx, cy, > RGB(0xff, 0xff, 0xff), RGB(0,0,0), ILD_NORMAL); >@@ -670,8 +669,8 @@ > SelectObject(hdcMask, hbmMask); > > /* Remove the background and all white pixels */ >- SetBkColor(hdcImage, ImageList_GetBkColor(himl)); >- BitBlt(hdcMask, 0, 0, cx, cy, hdcImage, 0, 0, SRCCOPY); >+ ImageList_DrawEx(himl, index, hdcMask, 0, 0, cx, cy, >+ RGB(0xff, 0xff, 0xff), RGB(0,0,0), ILD_MASK); > SetBkColor(hdcImage, RGB(0xff, 0xff, 0xff)); > BitBlt(hdcMask, 0, 0, cx, cy, hdcImage, 0, 0, NOTSRCERASE); > > > Filip, please put this in a separate patch. Rob

1 0

Re: WININET: take account of dwHeaderLength in HttpSendRequest
by Dmitry Timoshkov Aug. 3, 2004

Aug. 3, 2004

"Mike McCormack" <mike(a)codeweavers.com> wrote: > Does this look better? Strange I didn't get a compiler warning from that... > + if( dwHeaderLength == -1L ) > + len = strlenW(lpszHeaders); > + else > + len = dwHeaderLength; Well, it's better, but really needs a test to verify whether only -1 or any negative value is treated as a hidden strlen. -- Dmitry.

1 0

Re: WININET: take account of dwHeaderLength in HttpSendRequest
by Dmitry Timoshkov Aug. 3, 2004

Aug. 3, 2004

"Mike McCormack" <mike(a)codeweavers.com> wrote: > ChangeLog: > * take account of dwHeaderLength in HttpSendRequest > - len = strlenW(lpszHeaders)+3; > - szCookedHeaders = HeapAlloc( GetProcessHeap(), 0, sizeof(WCHAR)*len ); > - strcpyW( szCookedHeaders, lpszHeaders ); > + if( dwHeaderLength < 0 ) > + len = strlenW(lpszHeaders); > + else > + len = dwHeaderLength; (dwHeaderLength < 0) is an always true condition, since dwHeaderLength is DWORD, i.e. unsigned long. -- Dmitry.

1 0

wine metacity and ctrl-alt-del binding - ctrl sticks
by Grant Williamson Aug. 3, 2004

Aug. 3, 2004

Curious if there is a patch somewhere for this. Running rhel3, gnome-2.2 with metacity. 1) Start notepad, type a few characters 2) hit the keyboard combination ctrl-alt-del ... "gnome-session-kill --save" is started. 3) Cancel this option. 4) Now try typing in Notepad, i.e. hit the keys "s" or "f", its just like ctrl-s or ctrl-f have been held in. 5) Hitting ctrl once cancels this. Anyone have a patch, to stop this happening?

2 1

Re: cleanup a->w cross calls in advapi32/crypt.c
by Mike McCormack Aug. 3, 2004

Aug. 3, 2004

James Hawkins wrote: > + PWSTR keyname; > > - keyname = CRYPT_Alloc(strlen(KEYSTR) + strlen(pProvName) +1); > + keyname = CRYPT_Alloc((strlenW(KEYSTR) + strlenW(pProvName) + 1) * sizeof(WCHAR)); > if (keyname) > { > - strcpy(keyname, KEYSTR); > - strcpy(keyname + strlen(KEYSTR), pProvName); > + strcpyW(keyname, KEYSTR); > + strcpyW(keyname + strlenW(KEYSTR) * sizeof(WCHAR), pProvName); > } else > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > return keyname; > } This doesn't look right.... when using pointer arithmetic, you do so in increments of the pointer's type (eg. WCHAR). The following two lines are the same, and are both wrong: strcpyW(keyname + strlenW(KEYSTR) * sizeof(WCHAR), pProvName); strcpyW(&keyname[strlenW(KEYSTR) * sizeof(WCHAR)], pProvName); The right version would be: strcpyW(&keyname[strlenW(KEYSTR)], pProvName); but how about just using: strcatW( keyname, pProvname ); Mike

4 4

Re: cleanup a->w cross calls in advapi32/crypt.c
by Jeroen Janssen Aug. 2, 2004

Aug. 2, 2004

James Hawkins wrote: > I'm wasn't exactly sure on this one so it would be great if you could > help me on this one. When using pointer arithmetic, do the operations > such as --, ++... increment or decrement by the size of the pointer > type? Yes, if you have a char (1byte) pointer and you ++, you'll get one byte further. If you have a short (2byte) you'll get two bytes further in memory. If you have a long (4byte) pointer, you'll get 4 bytes further in memory if you ++. It is simular to dealing with arrays (looking at the memory layout) If you have an array of structs and need to get to the next struct in the array then you will need to look sizeof(struct) further in memory to find the next item in the array. --- Jeroen

1 0

Dynamic memory management in CryptAcquireContext
by Michael Jung Aug. 2, 2004

Aug. 2, 2004

Alexandre, I've noticed that you applied a modified version of my patch, which tries to fix a potential double free of the "temp" variable in dlls/advapi32/crypt.c's CryptAcquireContextA function. However, I think that the modified version does not fix the problem. Here is a code snippet from the current cvs versionc of crypt.c: CRYPT_Free(temp); ... if (pProv->pFuncs->pCPAcquireContext(&pProv->hPrivate, (CHAR*)pszContainer, dwFlags, pProv->pVTable)) { ... return TRUE; } /* FALLTHROUGH TO ERROR IF FALSE - CSP internal error! */ error: ... CRYPT_Free(temp); ... return FALSE; If the CSP's CPAcquireContext function fails, which is quite common (e.g. because the user specified key container does not exist), the "temp" variable is still free'd twice. I'm aware that my original patch was pretty ugly, due to a lot of redundancy, but I think this is due to fact that the CryptAcquireContext function seems not to be very well structured. I've submitted a patch two weeks ago, which basically was a reimplementation of CryptAcquireContext, but which was not committed (http://www.winehq.org/hypermail/wine-patches/2004/07/0213.html) Rob Shearman commented on this patch and felt that it is overkill to add both a helper function and a new struct type. Is this the reason the patch was not applied? I would be glad to rework the patch, if you give me some hints about what you did not like. However, I would prefer to wait until James Hawkins got his a->w cross call cleanup patch committed, in order not to break his work. Greetings, Michael -- Michael Jung, MSc Be liberal in what you accept, Integrated Circuits and Systems Lab and conservative in what you send. University of Technology, Darmstadt -- Jonathan Postel, Internet Pioneer phone: +49(6151)16-6692 / email: mjung(a)iss.tu-darmstadt.de

2 1