December 2005 - Wine-Devel - list.winehq.org

re: [commdlg] Fix ChooseColor / pr4125

by Dan Kegel

On 12/26/05, Alexandre Julliard <julliard(a)winehq.org> wrote: > Dan Kegel <dank(a)kegel.com> writes: > > Signed-off-by: dank(a)kegel.com > > Fix for http://bugs.winehq.org/show_bug.cgi?id=4125 > > This lets the color picker respond properly to keystrokes > > This fix was made with only the most superficial understanding of the > > code, but it seems reasonable. > > It doesn't apply, looks like white space is mangled. Sorry - mail clients are getting less and less friendly to me and plain text. Please grab it from http://kegel.com/wine/pr4125.patch instead. Thanks! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 28, 2005

Re: a more native host environment

by Vitaliy Margolen

Wednesday, December 28, 2005, 12:22:07 PM, Justin Lesarge wrote: > I'd like to see wine produce real PE dll files that > use unix system calls as a back end. For example, a > real kernel32.dll in PE format that maps at the same > addresses as the windows XP version, and so on. That's not the way it works. kernel32.dll doesn't call kernel directly. It's calling ntdll.dll instead. And why would you need same addresses? > PE executables could be seamlessly loaded with an ibcs > extension and properly linked against wine's real PE > system dlls. Hm well you can't just load one dll. You have to setup whole environment for Wine to work, start wineserver. > Adapting wine to that sort of architecture would make > it as native as real windows, and the bulk of wine's > sources wouldn't need to be edited. May I ask why do you need suck a huge complication to Wine project? If you just need Wine's dlls compiled as native - look on download page. Unless I'm missing the point of this exercise. Vitaliy

Dec. 28, 2005

a more native host environment

by Justin Lesarge

I'd like to see wine produce real PE dll files that use unix system calls as a back end. For example, a real kernel32.dll in PE format that maps at the same addresses as the windows XP version, and so on. PE executables could be seamlessly loaded with an ibcs extension and properly linked against wine's real PE system dlls. Adapting wine to that sort of architecture would make it as native as real windows, and the bulk of wine's sources wouldn't need to be edited.

Dec. 28, 2005

Invisible fonts - unimplemented SPI_GETFONTSMOOTHINGTYPE

by Peter Åstrand

I'm trying to get the application "Nya Multigram" (http://www.softogram.se/multigramkunskapsbanken.html) running in Wine. It works somewhat, but the initial screen (which should look like http://www.softogram.se/grafik/multigramkunskapsbanken/mgkbscreenshot4.jpg) doesn't have any text. The buttons are rendered very slowly, and this error message appears: fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) A screenshot is available at http://www.cendio.com/~peter/multigram.png. A partial log when running with WINEDEBUG=+font,+nativefont,+wc_font is included below. Any ideas on how to solve this? trace:font:GetTextMetricsW text metrics: Weight = 700 FirstChar = 32 AveCharWidth = 16 Italic = 0 LastChar = 64258 MaxCharWidth = 16 UnderLined = 0 DefaultChar = 0 Overhang = 0 StruckOut = 0 BreakChar = 32 CharSet = 0 PitchAndFamily = 36 -------------------- InternalLeading = 4 Ascent = 24 Descent = 6 Height = 30 fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) trace:font:WineEngCreateFontInstance L"System", h=16, it=0, weight=400, PandF=22, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance returning cached gdiFont(0x7fe9b888) for hFont 0x7c trace:font:X11DRV_SelectFont hdc=0x1154, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:WineEngCreateFontInstance L"System", h=16, it=0, weight=400, PandF=22, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance returning cached gdiFont(0x7fe9b888) for hFont 0x7c trace:font:X11DRV_SelectFont hdc=0x2284, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:X11DRV_SelectFont hdc=0x2284, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:X11DRV_SelectFont hdc=0x2284, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:X11DRV_SelectFont hdc=0x2284, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:WineEngCreateFontInstance L"Arial", h=31, it=0, weight=700, PandF=00, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance returning cached gdiFont(0x7b7abd70) for hFont 0xec8 trace:font:X11DRV_SelectFont hdc=0x2218, hfont=0xec8 trace:font:X11DRV_SelectFont gdiFont = 0x7b7abd70 trace:font:X11DRV_SelectFont hdc=0x1154, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:WineEngCreateFontInstance L"Arial", h=31, it=0, weight=700, PandF=00, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance returning cached gdiFont(0x7b7abd70) for hFont 0xec8 trace:font:X11DRV_SelectFont hdc=0x1154, hfont=0xec8 trace:font:X11DRV_SelectFont gdiFont = 0x7b7abd70 -- Peter Åstrand ThinLinc Chief Developer Cendio www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

Dec. 28, 2005

Re: SPARC assembly won't compile, problems with NT headers

by Alexandre Julliard

Troy Rollo <wine(a)troy.rollo.name> writes: > On the other hand it seems this field ends up with the wrong value under x86 > anyway, since the calculation is "_end - .L__wine_spec_rva_base". > ".L__wine_spec_rva_base" is in ".data", which in kernel32.dll.so on my system > is section 21 at 0xb6940 - well after ".text". which is section 9 at 0x15000. > > According to MS, SizeOfImage should be "Size of the image, in bytes, including > all headers." Right now it is much less than that even on the x86 platforms. It's relative to the start of the NT header, and it gets relocated at load time when we map the NT header to its proper place, at the start of the .text section. -- Alexandre Julliard julliard(a)winehq.org

Dec. 28, 2005

Re: New trying to debug missing menubar

by Joseph Garvin

So I've worked on this some more but I'm still stuck =) The +menu log shows a couple CreateMenu calls that I can immediately dismiss -- they're for the system menu (the one you get when you click the upper left box in the title bar). Using +win, there's a call to CreateWindowEx that passes a value for hMenu, but the name of this window is "listbox" and the app does have a listbox, and the listbox doesn't have it's own menu, so I'm assuming as per the MSDN docs this hMenu is actually a child window identifier (MSDN says that can be the case for certain window styles, and it looks like dlls/user/win.c does check for this, see here: http://tinyurl.com/qp1q) Question: What's the "correct" behavior for CreateWindowEx to take if no hMenu is passed in english? I'm not sure what logic the code snippet below is following. There's another call to CreateWindowEx that appears to be making the main window, that has no hMenu value passed to it. I planted a bunch of TRACE's in dlls/user/win.c and found that it's getting to the following section of CreateWindowEx: (Around line 1046 or so, should be 10 or so lines off because of stuff I've added) LPCSTR menuName = (LPCSTR)GetClassLongPtrA( hwnd, GCLP_MENUNAME ); if (menuName) { if (!cs->hInstance || HIWORD(cs->hInstance)) { TRACE("We get right here\n"); cs->hMenu = LoadMenuA(cs->hInstance,menuName); } else { cs->hMenu = HMENU_32(LoadMenu16(HINSTANCE_16(cs->hInstance),menuName)); } if (cs->hMenu) { MENU_SetMenu( hwnd, cs->hMenu ); } } In this section menuName is the same as the class name passed to CreateWindowEx. I don't know if that should cause problems. I haven't started looking at what GetClassLongPtrA does yet. LoadMenuA must end up returning null, because it never ends up getting to the SetMenu call. Through judicious trace planting, I've deduced this string of calling: LoadMenuA - > FindResourceA -> FindResourceExA -> findresourceA -> LdrFindResource_U -> find_entry -> RtlImageDirectoryEntryToData And then a check this check returns true: (Around line 2037 :P) if (!(addr = nt->OptionalHeader.DataDirectory[dir].VirtualAddress)) return NULL; At that point I stopped because I've now delved into the realm of deep black magic, and I suspect the bug must be somewhere earlier in the chain (probably in CreateWindowEx). Thoughts? Ideas? :P

Dec. 27, 2005

Re: SPARC assembly won't compile, problems with NT headers

by Troy Rollo

On Fri, 23 Dec 2005 19:18, Alexandre Julliard wrote: > Troy Rollo <wine(a)troy.rollo.name> writes: > > This will work if (and only if) the value of SizeOfImage is unimportant > > for Winelib executables. Of course in that case there is probably some > > merit in setting it to zero anyway since at least that would make it > > obvious that it has no meaningful value if somebody reads it later. > > Some apps do read it. It doesn't have to be exact, but it has to make > sense (like being beyond the last section, things like that), so > setting it to zero won't work. That's what I thought, which is why I suggested modifying the output file after the link step. The problem occurs at assembly time rather than link time. The assembler has no knowledge of what segment _end is in, and so assumes it is in a segment that is different from the segment of *every* other symbol. It cannot produce relocation records performing operations on symbols that are in different segment, presumably due to a limitation in the object file format (I have not investigated this too closely since I have assumed that if the file format could handle it then the GNU assembler, at least, would have implemented it, as it has for x86). On the other hand it seems this field ends up with the wrong value under x86 anyway, since the calculation is "_end - .L__wine_spec_rva_base". ".L__wine_spec_rva_base" is in ".data", which in kernel32.dll.so on my system is section 21 at 0xb6940 - well after ".text". which is section 9 at 0x15000. According to MS, SizeOfImage should be "Size of the image, in bytes, including all headers." Right now it is much less than that even on the x86 platforms. -- Troy Rollo - wine(a)troy.rollo.name

Dec. 27, 2005

Re: URLMON: Removed not used code.

by Jacek Caban

Troy Rollo wrote: >Merely removing unused code does not give you any copyright in the file. On >related matters, neither does fixing trivial bugs - there must be some >substantial additional expression introduced to a file in order to give rise >to a copyright claim. "Substantial" in this case means having expressive >substance rather than referring to the size of the change. > >Most of the code you have removed has been intentionally left in because the >implementation is still incomplete, but the routines you have removed are >there for whoever eventually completes the implementation to build on. > >I am also not sure why you think the INTERNET_SCHEME_FILE case is unused. > > Please, look at the code and changelog before witting such things. I just didn't add copyright in patches I have sent previously (and now I sent a part of changes I have in my tree and they included copyright header). INTERNET_SCHEME_FILE is not used because I've implemented it in a correct way. I really don't care much if I am in the copyright header or not. Jacek

Dec. 27, 2005

Re: URLMON: Removed not used code.

by Troy Rollo

On Wed, 28 Dec 2005 03:45, Jacek Caban wrote: > @@ -3,6 +3,7 @@ > * > * Copyright 1999 Ulrich Czekalla for Corel Corporation > * Copyright 2002 Huw D M Davies for CodeWeavers > + * Copyright 2005 Jacek Caban for CodeWeavers > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public Merely removing unused code does not give you any copyright in the file. On related matters, neither does fixing trivial bugs - there must be some substantial additional expression introduced to a file in order to give rise to a copyright claim. "Substantial" in this case means having expressive substance rather than referring to the size of the change. Most of the code you have removed has been intentionally left in because the implementation is still incomplete, but the routines you have removed are there for whoever eventually completes the implementation to build on. I am also not sure why you think the INTERNET_SCHEME_FILE case is unused. -- Troy Rollo - wine(a)troy.rollo.name

Dec. 27, 2005

Re: exception.o - Undefined reference to NtCurrentTeb in CVS?

by Evil

Robert Shearman wrote: > > Are you compiling with -O2? If not, then that is the reason why the > error is occuring for you, but not others (but still needs to be fixed). > You hit the nail on the head, Robert. I removed -O2 from my flags while troubleshooting a problem with a different project (ffmpeg, I think), right before I went on vacation. Without it, the inline optimizations weren't occurring - just as you reckoned. I put it back and it does now compile without any issues. But, as you said, there should probably be a backup function for non-optimized builds. Thanks again for your time! Jesse

Dec. 27, 2005