August 2004 - Wine-Devel - list.winehq.org

Re: tips needed for implementing the common control ICC_STANDARD_CLASSES

by michael＠cherryblossom.homelinux.com

On Fri, Aug 27, 2004 at 12:53:36PM -0400, James Hawkins wrote: > I'm reading through msdn some more and they say ICC_STANDARD_CLASSES should > > "Load one of the intrinsic User32 control classes. The user controls > include button, edit, static, listbox, combobox, and scrollbar." > > If I'm remembering, those controls are already implemented in > wine/controls. Maybe ICC_STANDARD_CLASSES just loads one/several of > these controls for the user. I'm really not sure though, and I'm sure This is all just speculation, but maybe it's possible that Kazaa uses a non-standard control in it's code? That wouldn't surprise me, especially when one considers the complex peer-to-peer concepts behind how it works. > someone on wine-devel knows a lot more about this than me. ditto, probably. > On Fri, 27 Aug 2004 12:48:03 -0400, James Hawkins <truiken(a)gmail.com> wrote: > > Hi, > > > > I've had a lot of people ask me about how well kazaa lite runs in > > wine, so I will be working on getting it to work. The install file is > > called klitekpp243e.exe, and the setup works great. (NOTE: im trying > > to get the app to work without having to use any native dlls) After By without native dlls, are you referring to without all standard windows dlls, (meaning you can use the dlls supplied with kazaa lite) or without all dlls, period, end of story? The former should be easier, right? > > the installation of klite, a program called KLConfigWizard.exe is run. > > It's a dialog box with some text initially, then when you click the > > next button, the user encounters a fatal error and we're sent to the > > debugger. The error is: > > > > fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 > > > > The unknown class is one of the two control classes left to be > > implemented in commctrl: ICC_STANDARD_CLASSES. I would like to > > implement this class, but I have no idea where to start. I've > > searched msdn for ICC_STANDARD_CLASSES, but it only turned up a link > > to the INITCOMMONCONTROLSEX structure. If anyone has any ideas or > > hints that they can give me, I would really appreciate it. Thanks for > > your time. > > > > -- > > James Hawkins > > > > > -- > James Hawkins >

Aug. 28, 2004

Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by Michael Chang

On Sat, Aug 28, 2004 at 01:54:19AM +1000, Con Kolivas wrote: > Mike Hearn wrote: > >>>Well, apparently we don't use sched_yield, so the problem must > >>>>lie somewhere else. Maybe Con can help us out here? Alexandre says he > >> > >>Interesting. Probably the most valuable information is that it seems > >>to work fine if we artificially limit the threads to exactly the same > >>timeslice _or_ we put them at such a low priority that they are forced > >>to be guaranteed to round robin one task at a time. This is the way > >>2.4 used to work which is why with the new 2.6 schedulers which do far > >>more out-of-order rescheduling some applications have a problem; > >>particularly under load. I suspect it's actually the latter issue. > >>Locking between threads should prevent that being a problem, though. > >>You already mentioned that you dont use sched_yield() and I couldn't > >>even begin to look at the wine code myself so perhaps you know > >>something more. > > > > > >Hi Con, > > > >One thought that occurred to me, and this is just a random theory, is > >that maybe the issue is not with the Wine code but the Win32 code run on > >top of it. Do you know how 2.6 scheduling compares with 2.4 and Windows > >(NT) scheduling? Could it be that some apps are written to expect > >Windows-style scheduling and fail to work if they don't get it? > > I argued with myself about the logic in this for ages. The best I could > come up with is - I don't know :| I'd need to know about windows > scheduling (which I don't) Obviously, if Win apps have been written to expect this, there's documentation somewhere... if someone has free time, maybe look for it? IIRC, there are some things about priority scheduling, and that apps take complete control of the CPU for a set period of time based on that priority (something like Very High, High, Normal, Low, Very Low or something in the eyes of a consumer) -- which leads to the behaviour that CPU intensive apps which have high priority slow down the PC and take up loads of CPU time, and poorly written apps that have high priority can loop forever, and crash/freeze the PC because other apps don't get CPU time, nor does the interrupter (Ctrl-Alt-Del and it's Task Manager (which IIRC worked better in 9x by taking over and halting all processes but itself, but had more features and became an app like everything else in later versions)). Unfortunately, this is all speculation, because I am a 9x user with some experience with XP machines, not a Windows Developer. > and how wine treats that scheduling (which I also don't). Can someone explain where this is written, or why it isn't? > > Cheers, > Con Just a curious onlooker, --Michael Chang

Aug. 28, 2004

Re: working together on stdole.tlb and a end to dcom9x

by Nyef

On Sat, Aug 28, 2004 at 11:06:46PM +0200, Filip Navara wrote: > Mike Hearn wrote: > > >It basically involves implementing the ICreateTypeLib interfaces in our > >OLE dlls. Nyef did some great work on this but for stdole32.tlb we need > >the other version, I think. > > > > > Can you elaborate more please? Looking at dlls/oleaut32/typelib2.c I see > that the ICreateTypeLib2 interface is implemented. The ICreateTypeLib2 interface is used to create the new-style MSFT typelibs. The older ICreateTypeLib interface is used for the old-style typelibs. While the newer interface also implements the older one, when you ask for the old interface with CreateTypeLib() you get a completely different implementation. I don't see why it necessarily follows that stdole32 wouldn't work as an MSFT typelib, but the implementation of ICreateTypeInfo2 is badly incomplete in places, and I would trust it to completely mess up any semi-complex type library you attempt to create with it. Specifically, any type library that involves functions or variables. > Regards, > Filip --Alastair Bridgewater

Aug. 28, 2004

Re: working together on stdole.tlb and a end to dcom9x

by Filip Navara

Mike Hearn wrote: >It basically involves implementing the ICreateTypeLib interfaces in our >OLE dlls. Nyef did some great work on this but for stdole32.tlb we need >the other version, I think. > > Can you elaborate more please? Looking at dlls/oleaut32/typelib2.c I see that the ICreateTypeLib2 interface is implemented. Regards, Filip

Aug. 28, 2004

cleanup w->a cross calls in printdrv

by James Hawkins

I want to send this through wine-devel first to see if there are any problems with it. In gdi_private.h I had to change the parameters that pStartDoc accepted from DOCINFOA to DOCINFOW. I know I shouldn't change public api headers, but this one is private so the change seems acceptable. If it's not let me know. Another problem that might popup is the way the DOCINFOW struct is filled in the StartDocA function: len = MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, NULL, 0 ); docName = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) ); MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, docName, len ); docW.lpszDocName = docName; <--- is this assignment a problem? if(docName) HeapFree( GetProcessHeap(), 0, (LPWSTR)docName ); The reason why I had to make a docName variable is because docW.lpszDocName is a LPCWSTR so there were warnings when i had docW.lpszDocName directly in the call to MultiByteToWideChar. Changelog * cleanup w->a cross calls in StartDoc -- James Hawkins

Aug. 28, 2004

Re: Other W->A crosscalls

by Francois Gouget

On Wed, 25 Aug 2004, Rolf Kalbermatter wrote: [...] > I see many "xxxAW calls xxxA function" mainly in the shell related DLLs. This > is of course not something you can really get rid of, so the script should > be able to exclude those cases. I couldn't test as I don't have smatch, but I think that simply adding this line in the right place should do the trick. $func_in = "No function" if ($func_in =~ /AW$/); See the attached script. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

Aug. 28, 2004

Re: wine/ windows/painting.c dlls/user/painting.c

by Rein Klazes

On Wed, 25 Aug 2004 19:46:11 -0500, you wrote: > Log message: > GetUpdateRgn should clip the returned region to the client area. > Changed GetUpdateRect and ExcludeUpdateRgn to call GetUpdateRgn. > Moved these 3 functions to dlls/user/painting.c. This has the effect that a program that like agent does this: case WM_PAINT: if( GetUpdateRect(hWnd, ...) { hdc = BeginPaint(hWnd,...); } causes a lot of: err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 0x1002c! Is it not possible to restrict the update region to the client area in the first place? Rein. -- Rein Klazes rklazes(a)xs4all.nl

Aug. 28, 2004

Re: W->A cleanup of DirectDrawEnumerateEx part 4

by Mike McCormack

You should post one patch not four that depend upon each other. Rule of Thumb: * After each patch is applied, the CVS should build and work. Mike James Hawkins wrote: > Changelog > * cleanup cross calls in DirectDrawEnumerateEx >

Aug. 28, 2004

Re: W->A cleanup of DirectDrawEnumerateEx part 1

by Mike Hearn

On Sat, 28 Aug 2004 13:30:40 -0400, James Hawkins wrote: > I guess this is one of the w->a cases that shouldnt be fixed if this > is the case. Pretty much anything which involves changing public structures (ie declared in the headers in include/) is probably wrong, as not all the Windows APIs are unicode. You can always check to see if the definition is on MSDN if you aren't sure when something is public or not. thanks -mike

Aug. 28, 2004

Debug Channels trashed

by Uwe Bonnes

Hallo, I am trying to run the WebPACK_42wp30_full_installer.exe : http://direct.xilinx.com/direct/webpack/42wp3/\ : WebPACK_42wp30_full_installer.exe (a 110 MByte Download). Running it crashes quite early, while testing the debug channels: err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TrueType" err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TT" wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405ac2f0,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0xc0685566 in 32-bit code (0x40710c60). In 32 bit mode. 0x40710c60 WINPROC_CallWndProc [/home/wine/wine/dlls/user/../../windows/winproc.c:232] in user32: testb $0x8,0x0(%eax) 232 if (TRACE_ON(relay)) 232 if (TRACE_ON(relay)) Wine-dbg>Backtrace: =>1 0x40710c60 WINPROC_CallWndProc+0x70(wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:232] in user32 (0x4067fb7c) 2 0x4071578d CallWindowProcA+0xed(func=0x4078656c, hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:3123] in user32 (0x4067fba0) 3 0x406eb083 DefDlgProcA+0x63(hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/defdlg.c:451] in user32 (0x4067fbd0) 4 0x40710437 WINPROC_wrapper+0x17 in user32 (0x4067fbf4) 5 0x40710c4c WINPROC_CallWndProc+0x5c(wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:230] in user32 (0x4067fc30) 6 0x4071578d CallWindowProcA+0xed(func=0x406eb020, hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:3123] in user32 (0x4067fc54) 7 0x40725b8f call_window_proc+0x11f(lparam=0x0, unicode=0x0, same_thread=0x1) [/home/wine/wine/dlls/user/message.c:1461] in user32 (0x4067fcb8) 8 0x4072839e SendMessageTimeoutA+0x1be(hwnd=0x10022, msg=0x110, wparam=0x1002c, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x4067fd3c) [/home/wine/wine/dlls/user/message.c:1968] in user32 (0x4067fd18) 9 0x40728425 SendMessageA+0x35(hwnd=0x10022, msg=0x110, wparam=0x1002c, lparam=0x0) [/home/wine/wine/dlls/user/message.c:2012] in user32 (0x4067fd44) 10 0x406efc5c DIALOG_CreateIndirect+0x107c(dlgProc=0x4012df, param=0x0, unicode=0x0, modal=0x1) [/home/wine/wine/dlls/user/../../windows/dialog.c:672] in user32 (0x4067fe54) 11 0x406f04be DialogBoxParamA+0x4e(hInst=0x400000, name=0x12c, owner=0x0, dlgProc=0x4012df, param=0x0) [/home/wine/wine/dlls/user/../../windows/dialog.c:821] in user32 (0x4067fe78) 12 0x0040184d (0x004137a2) It seems the location of the debug channels is picked up from the ebx register Wine-dbg>disass 0x40710c52 0x40710c52 WINPROC_CallWndProc [../windows/winproc.c:231] in user32: call 0x40707c70 WIN_RestoreWndsLock [/home/wine/wine/dlls/user/../../windows/user.c:183] in user32 0x40710c57 WINPROC_CallWndProc [../windows/winproc.c:232] in user32: movl 0x190(%ebx),%eax 0x40710c5d WINPROC_CallWndProc [../windows/winproc.c:232] in user32: addl $24,%esp 0x40710c60 WINPROC_CallWndProc [../windows/winproc.c:232] in user32: testb $0x8,0x0(%eax) I wonder what can trash the testing of the debug channels. I ran with +heap to look for heap corruption, but couldn't find something. Uncommenting the offending code > if (TRACE_ON(relay)) > DPRINTF( "%04lx:Ret window proc %p (hwnd=%p,msg=%s,wp=%08x,lp=%08lx) retval=%08lx\n", > GetCurrentThreadId(), proc, hwnd, SPY_GetMsgName(msg, hwnd), wParam, lParam, retvalue ); makes the application proceed. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 28, 2004