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

Re: tips needed for implementing the common control ICC_STANDARD_CLASSES

by James Hawkins

Here is the output of the program and the backtrace. On Sun, 29 Aug 2004 10:55:02 +0100, Robert Shearman <rob(a)codeweavers.com> wrote: > James Hawkins wrote: > > >>This is all just speculation, but maybe it's possible that Kazaa uses a > >>non-standard control in it's code? > >> > >> > If it works on Windows 2000, for example, (or using comctl32.dll v5.81 > instead of v6) then this is not the cause. > > >On Sat, 28 Aug 2004 22:17:24 -0400, > >michael(a)cherryblossom.homelinux.com > ><michael(a)cherryblossom.homelinux.com> wrote: > > > > > >>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. > >> > >> > It doesn't use common controls to implement its peer-to-peer concepts. > > >>>On Fri, 27 Aug 2004 12:48:03 -0400, James Hawkins <truiken(a)gmail.com> wrote: > >>> > >>> > >>>>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. > >>>> > Could you send me the backtrace and/or try the patch in this message: > http://www.winehq.org/hypermail/wine-patches/2004/08/0520.html > > >>>> 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. > >>>> > Assuming that the program works on operating systems older than XP, this > message is not the cause of your problems. > > >>>> 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. > >>>> > >>>> > To implement ICC_STANDARD_CLASSES would mean copying a bunch of code > from user32 (or being really clever and somehow reusing it) and then > implementing the few new messages, which usually involve being able to > use image lists and using themes. > > Rob > > -- James Hawkins

Aug. 29, 2004

Re: CommonUnimpStub looping

by Mike Hearn

On Sun, 29 Aug 2004 13:26:37 +0100, Robert Shearman wrote: > Use the attached patch and run with warn+module. > > Rob There's no need, I debugged this in January. The problem is that the IE installer contains its own copy of advapi32 but it doesn't actually implement all the functions that ours does. In particular some are exported but just forward to the CommonUnimpStub function which is a bit like our code which throws an exception. Our GDI32 implementation uses one of the registry APIs that is implemented by our advapi32 implementation, but when IE is loaded the advapi32 inside the installer package takes precendence with the result that the GDI is linked to stub code. So things blow up. The solution is to force advapi32 to builtin so the older native version is never loaded. thanks -mike

Aug. 29, 2004

Re: CommonUnimpStub looping

by Mike Hearn

On Sun, 29 Aug 2004 13:55:49 +0200, Stefan Leichter wrote: > trying to install ie6 on current wine gives me an endless loop with function > calls to CommonUnimpStub(). Try export WINEDLLOVERRIDES="advapi32=builtin" You may need others. You can refer to the source of my IE6 installer script to see how to solve some similar problems. Unfortunately the only way to fix this one so it works out of the box is to force advapi32 to always load builtin, and never native. I'm not sure what Alexandres policy on modifying the default DLL overrides in the source is. Last time I submitted a patch to change the internal table it was rejected.

Aug. 29, 2004

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

by Huw D M Davies

On Sat, Aug 28, 2004 at 05:59:39PM -0400, Nyef wrote: > 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. You're right, an MSFT stdole32 might work fine - I guess we should at least try it. So for fun I've attached the program we used to generate CrossOver's stdole32.tlb (Actually you need to take the generated file and wrap it up in a resource only dll, but that's a detail). Since it was designed to be compiled with MSVC, it uses the L"" construct for olestrings - you can hack around this by compiling with -fshort-wchar for now. Huw.

Aug. 29, 2004

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

by Con Kolivas

Ove Kaaven wrote: > søn, 29.08.2004 kl. 04.13 skrev Michael Chang: > >>>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? > > > A book I have described how it works... > > The Windows scheduler is in its most basic form remarkably similar to > the scheduling policy known in Linux as SCHED_RR, with a few > "enhancements". For example, the thread owning the foreground window > gets a priority boost relative to other threads in the system. There's > also some stuff in there to help deal with the priority-inversion > problem known to real-time programmers, I think. (When a low priority > thread can keep blocking the execution of a high priority thread by > holding a lock the high priority thread needs, with the result that > medium priority threads get to run but the high priority thread does > not, it's called priority inversion, if I understand right.) > > Also note that Windows allows a Win32 process to boost its own priority > all the way to what they call "real time". Only root can do this under > Linux. I'm not sure if you need administrator privileges to do this > under Windows (probably not), but since every Windows user runs as > administrator anyway, it's probably not unlikely that many applications > expect this ability anyway. > > Internally, Windows assigns each thread a priority, determined by > process priority class, thread priority class (all programmatically > set), and some other factors such as whether it's running in the > foreground (owns the foreground window) or not. Threads with the same > scheduling priority are scheduled round-robin. Threads with higher > priority preempt anything with lower priority, so that lower priority > threads will not get to run as long as a higher priority thread is > runnable. It is of course recommended and assumed that applications use > high priority only for threads that won't use much CPU, since if they > do, execution of that thread will block all threads with lower priority > than itself. > > The book described no kind of dynamic scheduling based on how much CPU > time a thread is spending, only the aforementioned "is in foreground" > thing. Does imply that a Win32 app running an infinite loop could run > fine in the background, but would hang the system if brought to the > foreground, I think (assuming Windows doesn't see that it has hung, > which it probably checks by seeing if it responds to messages). Thanks. That's useful to know. To be honest, knowing how linux manipulates priorities dynamically and that more of the OS is threaded at different layers from windows, it is a miracle than any of the high performance gaming might run smoothly. >>>and how wine treats that scheduling (which I also don't). > > > I don't see how that's relevant. Wine doesn't schedule threads, the > Linux kernel does. Audio runs as a separate thread outside of wine potentially through who knows how many layers as a combination of both process and kernel context so that's already complicating the issue by having a separate thread. X does the same again. So what the win32 game is doing under wine when it asks for audio or graphics to be done will be handled completely differently to windows. How blocking is done between the graphics and audio calls, when you have a highly cpu bound task (the game) as well is definitely complex and not just the kernel that is responsible here. Add to that the fact that wine itself runs a few threads and as I said before, it's a miracle it runs smoothly at all. Cheers, Con

Aug. 29, 2004

CommonUnimpStub looping

by Stefan Leichter

Hello, trying to install ie6 on current wine gives me an endless loop with function calls to CommonUnimpStub(). I started with .wine and dirve_c created by wine and installed dcom98, vc c++ runtime, vb 5 + 6 Runtime What i found so far is that it happens when the iebatch.exe gets started. The call the DllMain of the gdi32.dll never returns. In the traces i can see: 0016:Call PE DLL (proc=0x4080e5a4,module=0x40800000 L"gdi32.dll",reason=PROCESS_ATTACH,res=0x1) but a line like 0016:Ret PE DLL (proc=0x409b15a4,module=0x409a0000 L"gdi32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 is not inside the log file. Any tips to get around this problem ? Bye Stefan

Aug. 29, 2004

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

by Mike Hearn

On Sun, 29 Aug 2004 09:51:30 +0200, Ove Kaaven wrote: > A book I have described how it works... Hi Ove, I remember TransGaming had some problems with kernel 2.6 scheduling: did you guys ever get to the bottom of it? What are you recommending your users do if not? thanks -mike

Aug. 29, 2004

Re: W->A cleanup of DirectDrawEnumerateEx part 4

by Mike Hearn

On Sun, 29 Aug 2004 02:52:12 +0900, Mike McCormack wrote: > Rule of Thumb: > * After each patch is applied, the CVS should build and work. I'd just like to elaborate on this point : CVS should build and work but the feature or whatever it is you're working on doesn't necessarily have to be complete. That's why I posted binary relocatability in two parts, after the first part Wine will still work just fine, but the feature isn't complete. Only after all the parts are applied will the feature become active. But, it made sense to split it into two parts, as that way the changes are easier to review. Knowing where and how to split patches is a bit of a black art but comes with practice. Following Mikes rule of thumb can help a lot. thanks -mike

Aug. 29, 2004

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

by Ove Kaaven

søn, 29.08.2004 kl. 11.43 skrev Robert Shearman: > Ove Kaaven wrote: > > >søn, 29.08.2004 kl. 04.13 skrev Michael Chang: > > > > > >Also note that Windows allows a Win32 process to boost its own priority > >all the way to what they call "real time". Only root can do this under > >Linux. I'm not sure if you need administrator privileges to do this > >under Windows (probably not), but since every Windows user runs as > >administrator anyway, it's probably not unlikely that many applications > >expect this ability anyway. > > > As decribed here: > http://www.winntmag.com/Articles/Index.cfm?IssueID=22&ArticleID=302 > There are 31 priority levels and only users with Administrator > privileges can set processes to the highest priorities of 16-31. OK, so you need administrator to set a realtime priority, but you are still able to set a high priority on yourself without being an administrator under Windows. This is not possible under Linux, where a non-root process can only reduce, not elevate, its own priority. > I doubt there are programs that require these high priorities, although > we could find potential targets by printing a message for programs that > try and set their priority to a high level. For what it's worth, at TransGaming we know for a fact that some games (maybe it was Battlefield 1942) does; they elevate the priority of one of their most critical threads, and seem to use interesting mechanisms to regulate how much time this high-priority thread use relative to the other threads. In any case it does help the game's smoothness to experimentally elevate this thread's priority under Linux, but this is not really a solution because of permissions.

Aug. 29, 2004

Re: Debug Channels trashed

by Mike Hearn

On Sat, 28 Aug 2004 19:30:58 +0200, Uwe Bonnes wrote: > It seems the location of the debug channels is picked up from the ebx > register %ebx is supposed to point to the ELF global offset table, iirc. If it's been reset somewhere then it could cause this sort of crash when accessing global vars in an external library as I imagine debug channels are. The offending line is printing the *return* value of the function so I really suspect this is similar to a problem reported earlier this year (?) where some win32 code wasn't performing register saves correctly. I bet this is the same problem. > 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. Try wrapping the window proc callout with some code that saves %ebx on the stack. There is an example in another part of the code but I can't remember what! :( If you compile the relevant DLL with optimization off you may be able to get away with this for testing the theory: __asm__("push %ebx") // make the call to the wndproc here __asm__("pop %ebx") // now test the debug channel and carry on The reason it works if you comment out the debug channel code is that %ebx is reset by gcc generated code on entry to an ELF exported function. thanks -mike

Aug. 29, 2004