- Wine-Devel - list.winehq.org

SHGetFileInfo - fix LargeIcon & add rel. path
by Vitaliy Margolen March 15, 2003

March 15, 2003

According to MSDN: pszPath - [in] Pointer to a buffer that contains the path and file name. Both absolute and _RELATIVE_ paths are valid. Plus fix for getting Large Icon properly. SHGetFileInfo was always returning small icon. Looking at what I found, I think this should be yet one more sanity check project that does following: if (aConst == 0) Find all where (* & aConst) For more details see patch. FIY: SHGFI_LARGEICON = $00000000 Vitaliy Margolen changelog: - make SHGetFileInfo handle relative paths - fix requests for large icons Index: shell32_main.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shell32_main.c,v retrieving revision 1.112 diff -u -r1.112 shell32_main.c --- shell32_main.c 14 Jan 2003 23:43:42 -0000 1.112 +++ shell32_main.c 15 Mar 2003 21:44:50 -0000 @@ -209,7 +209,7 @@ SHFILEINFOA *psfi, UINT sizeofpsfi, UINT flags ) { - char szLocation[MAX_PATH]; + char szLocation[MAX_PATH], szFullPath[MAX_PATH]; int iIndex; DWORD ret = TRUE, dwAttributes = 0; IShellFolder * psfParent = NULL; @@ -229,6 +229,16 @@ psfi->szTypeName[0] = '\0'; psfi->iIcon = 0; + if (!(flags & SHGFI_PIDL)){ + // SHGitFileInfo should work with absolute and relative paths */ + if (PathIsRelativeA(path)){ + GetCurrentDirectoryA(MAX_PATH, szLocation); + PathCombineA(szFullPath, szLocation, path); + } else { + lstrcpynA(szFullPath, path, MAX_PATH); + } + } + if (flags & SHGFI_EXETYPE) { BOOL status = FALSE; HANDLE hfile; @@ -240,12 +250,12 @@ if (flags != SHGFI_EXETYPE) return 0; - status = GetBinaryTypeA (path, &BinaryType); + status = GetBinaryTypeA (szFullPath, &BinaryType); if (!status) return 0; if ((BinaryType == SCS_DOS_BINARY) || (BinaryType == SCS_PIF_BINARY)) return 0x4d5a; - hfile = CreateFileA( path, GENERIC_READ, FILE_SHARE_READ, + hfile = CreateFileA( szFullPath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0 ); if ( hfile == INVALID_HANDLE_VALUE ) return 0; @@ -294,7 +304,7 @@ if (flags & SHGFI_PIDL) { pidl = ILClone((LPCITEMIDLIST)path); } else if (!(flags & SHGFI_USEFILEATTRIBUTES)) { - hr = SHILCreateFromPathA(path, &pidl, &dwAttributes); + hr = SHILCreateFromPathA(szFullPath, &pidl, &dwAttributes); } if ((flags & SHGFI_PIDL) || !(flags & SHGFI_USEFILEATTRIBUTES)) @@ -324,7 +334,7 @@ { if (flags & SHGFI_USEFILEATTRIBUTES) { - strcpy (psfi->szDisplayName, PathFindFileNameA(path)); + strcpy (psfi->szDisplayName, PathFindFileNameA(szFullPath)); } else { @@ -346,7 +356,7 @@ else { char sTemp[64]; - strcpy(sTemp,PathFindExtensionA(path)); + strcpy(sTemp,PathFindExtensionA(szFullPath)); if (!( HCR_MapTypeToValueA(sTemp, sTemp, 64, TRUE) && HCR_MapTypeToValueA(sTemp, psfi->szTypeName, 80, FALSE ))) { @@ -397,7 +407,7 @@ char * szExt; DWORD dwNr=0; - lstrcpynA(sTemp, path, MAX_PATH); + lstrcpynA(sTemp, szFullPath, MAX_PATH); if (dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) psfi->iIcon = 2; @@ -409,7 +419,7 @@ && HCR_GetDefaultIconA(sTemp, sTemp, MAX_PATH, &dwNr)) { if (!strcmp("%1",sTemp)) /* icon is in the file */ - strcpy(sTemp, path); + strcpy(sTemp, szFullPath); if (flags & SHGFI_SYSICONINDEX) { @@ -419,10 +429,10 @@ else { IconNotYetLoaded=FALSE; - PrivateExtractIconsA(sTemp,dwNr,(flags&SHGFI_LARGEICON) ? - GetSystemMetrics(SM_CXICON) : GetSystemMetrics(SM_CXSMICON), - (flags&SHGFI_LARGEICON) ? GetSystemMetrics(SM_CYICON) : - GetSystemMetrics(SM_CYSMICON), &psfi->hIcon,0,1,0); + PrivateExtractIconsA(sTemp,dwNr,(flags & SHGFI_SMALLICON) ? + GetSystemMetrics(SM_CXSMICON) : GetSystemMetrics(SM_CXICON), + (flags & SHGFI_SMALLICON) ? GetSystemMetrics(SM_CYSMICON) : + GetSystemMetrics(SM_CYICON), &psfi->hIcon,0,1,0); psfi->iIcon = dwNr; } } @@ -430,7 +440,7 @@ } else { - if (!(PidlToSicIndex(psfParent, pidlLast, (flags & SHGFI_LARGEICON), + if (!(PidlToSicIndex(psfParent, pidlLast, !(flags & SHGFI_SMALLICON), (flags & SHGFI_OPENICON)? GIL_OPENICON : 0, &(psfi->iIcon)))) { ret = FALSE; @@ -438,13 +448,13 @@ } if (ret) { - ret = (DWORD) ((flags & SHGFI_LARGEICON) ? ShellBigIconList : ShellSmallIconList); + ret = (DWORD) ((flags & SHGFI_SMALLICON) ? ShellSmallIconList : ShellBigIconList); } } /* icon handle */ if (SUCCEEDED(hr) && (flags & SHGFI_ICON) && IconNotYetLoaded) - psfi->hIcon = ImageList_GetIcon((flags & SHGFI_LARGEICON) ? ShellBigIconList:ShellSmallIconList, psfi->iIcon, ILD_NORMAL); + psfi->hIcon = ImageList_GetIcon((flags & SHGFI_SMALLICON) ? ShellSmallIconList:ShellBigIconList, psfi->iIcon, ILD_NORMAL); if (flags & (SHGFI_UNKNOWN1 | SHGFI_UNKNOWN2 | SHGFI_UNKNOWN3)) FIXME("unknown attribute!\n");

1 0

Re: Fix for ArrangeCtrlPositions in commdlg
by Maxime Bellengé March 15, 2003

March 15, 2003

Is there any problem with this patch ? It has not been applied and I didn't see any comments on wine-devel. The current cvs implementation is broken I think. If you try to open a file with WinHex or WinZip you can see the problems. If there is any problem with it, please tell me in order for me to fix it a+ On Wed, 2003-03-12 at 23:54, Maxime Bellengé wrote: > This patch replaces my previous patches. > It fixes the computation of the file dialog box size and the component > placement. > > Now WinHex open dialog box looks fine as well as VirtualDub, Winzip. > > The new algorithm is partially based on information found at > http://www.bridgespublishing.com/articles/issues/0201/Custom_Open_dialogs__… > > ChangeLog: > - Fix how the size of the dialog is computed and the child component > placed. -- Maxime Bellengé <maxime.bellenge(a)laposte.net>

2 1

Re: Oleauto Header
by Alexandre Julliard March 15, 2003

March 15, 2003

Jon <jon_p_griffiths(a)yahoo.com> writes: > +dlls/oleaut32/variant.c > Correct the prototype of VarCyFromI1() Actually I'd argue that using signed char is correct here, and that the other I1 functions should be fixed to use signed chars too. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: (Mis)using threads
by Mikko Rauhala March 15, 2003

March 15, 2003

(Sorry for thread breakage, I'm not actually subscribed but commenting based on the archive.) On Thu Mar 13 2003, 02:11:50 CST Ove Kaaven wrote: > Yes, they all support what I'm saying: a non-root process cannot > increase its scheduling priority (in the common meaning of "priority", > not the inversed sense that renice and setpriority use, of course, if > that wasn't obvious). Actually, at least Linux has some capability support, and if the Wine process would by some means be set up to receive CAP_SYS_NICE, it could manipulate priorities at will. Unfortunately, I don't think eg. the capability filesystem support is at place currently, so this might take some tweaking. (I'm not sure if eg. a suid root wrapper that would just exec wine with normal user priviledges and give it CAP_SYS_NICE would work.) This solution also is obviously limited to systems supporting CAP_SYS_NICE. Another alternative would be to make a suitably authorized (root or CAP_SYS_NICE) priority switching server, which could respond to spesifically authorized priority switch requests. A bit of a kludge, yes. Of course, any solution that gives user processes access to setpriority() is potentially dangerous, but at least the dangers would be limited, unlike with running Wine as root. -- Mikko Rauhala - mjr(a)iki.fi - <URL:http://www.iki.fi/mjr/> Transhumanist - WTA member - <URL:http://www.transhumanism.org/> Singularitarian - SIAI supporter - <URL:http://www.singinst.org/>

1 0

DPRINTF->TRACE Final (Exceptions - not changed)
by Tony Lambregts March 15, 2003

March 15, 2003

This completes the first stage of DPRINTF->TRACE. There are still a lot of files that use DPRINTF. The following is a list of the files I where I did not replace DPRINTF with TRACE along with a breif explanation. I would appreciate any comments on this or any of the patches that I submitted over the last day. windows/dce.c................ dump function. windows/winproc.............. dump function. scheduler/process.c.......... relay function. scheduler/tread.c............ relay function. relay32/relay386.c........... relay function. relay32/snoop.c.............. snoop function. programs/wineconsole ........ uses WINE_DPRINTF. msdos/vxd.c.................. dump function. misc/version.c............... should this be a FIXME? memory/global.c.............. dump function. memory/instr.c............... dump function. memory/local.c............... dump function. loader/pe_image.c............ dump function. loader/ne/module.c........... dump function. if1632/relay.c............... relay function. if1632/snoop.c............... snoop function. graphics/x11drv/opengl.c .... dump function. files/smb.c.................. dump functions (patch submitted) review. dlls/wineclipsrv.c........... define macros. dlls/winsock/socket.c........ dump function. dlls/winedos/dosvm.c......... relay function. dlls/winaspi/winaspi16.c .... dump function. dlls/winaspi/winaspi32.c..... dump function. dlls/user/hook.c............. relay function. dlls/opengl32/wgl.c.......... dump function (review). dlls/ole32/compobj.c......... dunp function. dlls/ole32/compositemoniker.c review (no /n to complete). dlls/ole32/storage.c......... dump function. dlls/ntdll/heap.c............ dump function. dlls/ntdll/virtual.c......... dump function. dlls/msvcrt/cppexcept.c...... dump function. dlls/kernel/thunk.c.......... thunk. dlls/kernel/wowthunk.c....... thunk. dlls/dsound/buffer.c......... this should be a fixme/message review. dlls/dsound/dsound_main.c.... dump function needs review. dlls/dsound/primary.c........ this should be a fixme/message review. dlls/dinput/device.c......... dump function dlls/ddraw/d3dcommon.c....... dump functions dlls/ddraw/d3dexecutebuffer.c patch submitted, dump function review. dlls/ddraw/d3dlight.c........ dump function dlls/ddraw/d3dmaterial.c..... dump functions dlls/ddraw/d3dhelper.c....... dump functions dlls/d3d8/device.c........... perhaps this should be a FIXME dlls/d3d8/shader.c........... frankly I don't want to touch it.<g> controls/menu.c.............. ditto. -- Tony Lambregts

3 3

Re: Fwd: failure delivery
by Eric Pouech March 15, 2003

March 15, 2003

Jon Griffiths wrote: >>>any reason why not use DllMain instead of patching winebuild ? >> >>If you mean the DllMain of msvcrt, there is no way for the it to >>know >>what type of app is calling it AFAICS. Only the generated main >>knows, >>and should inform msvcrt when it starts. Also the handling of >>main() >>is different for natively build apps linked with msvcrt: they >>should >>eventually have a different loop than ExitProcess(main()) >> >>Some of these settings can be overriden and should be handled by >>the >>.exe file. Wildcard expansion and the user math errors come to >>mind. but in most of the cases, this is a linker issue (overriding in user's compilation units symbols which come from libraries - in this case the C runtime libraries) perhaps a better way would be to add another layer: - instead of calling directly the user defined main function, then call another one, which would perform the next initialization steps (main vs. wmain calling, _matherr overriding, command line expansion...) A+ -- Eric Pouech

1 0

Re: DPRINTF->TRACE Final (Exceptions - not changed)
by Jon Griffiths March 15, 2003

March 15, 2003

Hi, > but i can't without use of DPRINTF ... > but if you have a better solution ? I suggest creating functions to print your types into a string, and then dump the created string. Then, if no trace is defined, make those functions macros that compile to nothing. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com

1 0

Re: winebuild initialisation
by Eric Pouech March 15, 2003

March 15, 2003

Jon wrote: > Hi, > > This patch adds initialisation code to apps that import msvcrt. This should be > expanded at some point to do the right things for dlls that do the same, but > at present, this only affects Winelib users who build their own dlls. > > Apps that don't import msvcrt won't see any changes. any reason why not use DllMain instead of patching winebuild ? -- Eric Pouech

2 1

Re: ntdll Rtl Strings
by Jon Griffiths March 15, 2003

March 15, 2003

Hi, >For base 0 it accepts: {whitespace} [+|-] [0[x|o|b]] {digits} >For bases 2, 8, 10 and 16 it accepts: {whitespace} [+|-] {digits} I'll resend with this difference added, for what its worth. > So: Feel free to reformat the comments of "my" functions, > but do not remove information. Far be it from me to impinge on "your" functions. I understand that documenting our implementation well is important, which is why I sent the patches in the first place, to produce better quality documentation in developer-useful formats (see documentation patches 1-4). Since we obviously share the same goals here, can I suggest you generate the documentation for functions you consider "yours", and reformat them as appropriate. Then we can work together to reach both our goals, without needing to resort to 'yours-and-mine' mentality. And Wine and Winelib developers will benefit as a result. Cheers, Jon (in humourously amused mode) ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com

1 0

Re: wine/ server/trace.c server/thread.h server/th ...
by Rein Klazes March 15, 2003

March 15, 2003

On Tue, 4 Mar 2003 16:18:44 -0600, you wrote: > ChangeSet ID: 7374 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/03/04 16:18:44 > > Modified files: > server : trace.c thread.h thread.c ptrace.c process.c > context_sparc.c context_powerpc.c > context_i386.c > scheduler : process.c client.c > include/wine : server_protocol.h > dlls/ntdll : signal_sparc.c signal_powerpc.c signal_i386.c > > Log message: > Use SIGUSR1 instead of SIGSTOP to suspend threads. This patch causes a regression running thebat! mail client. Running with --debugmsg +seh gives: | trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x41f32ea1 | trace:seh:EXC_RtlRaiseException info[0]=00000001 | trace:seh:EXC_RtlRaiseException info[1]=00000000 | trace:seh:EXC_CallHandler calling handler at 0x43fcf5 code=c0000005 flags=0 | trace:seh:EXC_RtlUnwind code=c0000005 flags=2 | trace:seh:EXC_RtlRaiseException code=c0000028 flags=1 addr=(nil) | err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. One thread stays alive, but the half-constructed main window is frozen. If I run with --debugmsg +relay there is no crash and the program manages to display the main windows after 20 miutes. Starting form winedbg doesn't seem to work, a first chance exception occurs soon after startup (long before the one above) and: | Wine-dbg>wine client error:b: read: Bad address | wine client error:b: sendmsg: Bad file descriptor I don't know how to proceed from here. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 2