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

Re: cleanup w->a cross calls in printdrv

by Huw D M Davies

On Sat, Aug 28, 2004 at 04:27:12PM -0400, James Hawkins wrote: > Index: dlls/gdi/gdi_private.h > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/gdi_private.h,v > retrieving revision 1.14 > diff -u -r1.14 gdi_private.h > --- dlls/gdi/gdi_private.h 6 Aug 2004 18:59:31 -0000 1.14 > +++ dlls/gdi/gdi_private.h 28 Aug 2004 19:55:41 -0000 > @@ -162,7 +162,7 @@ > INT (*pSetWindowExt)(PHYSDEV,INT,INT); > INT (*pSetWindowOrg)(PHYSDEV,INT,INT); > BOOL (*pSetWorldTransform)(PHYSDEV,const XFORM*); > - INT (*pStartDoc)(PHYSDEV,const DOCINFOA*); > + INT (*pStartDoc)(PHYSDEV,const DOCINFOW*); > INT (*pStartPage)(PHYSDEV); > BOOL (*pStretchBlt)(PHYSDEV,INT,INT,INT,INT,PHYSDEV,INT,INT,INT,INT,DWORD); > INT (*pStretchDIBits)(PHYSDEV,INT,INT,INT,INT,INT,INT,INT,INT,const void *, The fact that you're touching a .h file should probably tell you that you need to look at more than just one .c file > Index: dlls/gdi/printdrv.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/printdrv.c,v > retrieving revision 1.39 > diff -u -r1.39 printdrv.c > --- dlls/gdi/printdrv.c 4 May 2004 04:13:06 -0000 1.39 > +++ dlls/gdi/printdrv.c 28 Aug 2004 19:55:41 -0000 > @@ -70,13 +71,14 @@ > * > * Note: we now do it the other way, with the STARTDOC Escape calling StartDoc. > */ > -INT WINAPI StartDocA(HDC hdc, const DOCINFOA* doc) > +INT WINAPI StartDocW(HDC hdc, const DOCINFOW* doc) > { > INT ret = 0; > DC *dc = DC_GetDCPtr( hdc ); > > TRACE("DocName = '%s' Output = '%s' Datatype = '%s'\n", > - doc->lpszDocName, doc->lpszOutput, doc->lpszDatatype); > + debugstr_w(doc->lpszDocName), debugstr_w(doc->lpszOutput), > + debugstr_w(doc->lpszDatatype)); > > if(!dc) return SP_ERROR; And if you look further down StartDoc, you'll see: if (dc->funcs->pStartDoc) ret = dc->funcs->pStartDoc( dc->physDev, doc ); so the question is where is this function implemented? Well the dc->funcs array can either contain ptrs to internal gdi fns from the metafile and enhmetafile drivers, or it'll have ptrs to external dlls such as x11drv or wineps - see dlls/gdi/driver.c for the details. In the case of StartDoc a grep of the tree will show you that you need to update PSDRV_StartDoc. Unfortunately PSDRV_StartDoc is going to be rather messy to unicodify (this is probably why nobody has done this yet) since it uses calls to the 16 bit print spooling functions that are necessarily ansi. Huw.

Aug. 29, 2004

Wine's X11drv integration in Mac OS X

by Pierre d'Herbemont

Hi, We are currently porting Wine to Mac OS X. Currently Wine has a display driver for X11, and we would like to continue to use it for the Mac OS X port: to display the GUI interface, we don't need the Aqua UI elements since we prefer to use Windows theming system, and given the complexity and amount of work done in x11drv . But we also would like to be able to build something that behaves like a normal Carbon or Cocoa App, with a Dock Icon, and a Menu Bar, which would be managed by some Carbon code in Wine itself. I had a look to the X11CallCarbonAndCocoa [1] sample code, but the trouble is that the X11 window still belongs to X11.app, a mouse click in the Dock to get the App's Windows to the front doesn't work for the X11 Window, and the menu bar for this Window is still the X11.app's menu bar. So I'd like to know if there is a way for the Wine Carbon instance to own the X11 Windows Wine created. At least it would be a feature that we'd like to see :) Thanks, Pierre. PS: I am not subscribed to the x11-users so please CC me. I am also CC-ing the wine-devel and darwine-devel, sorry about that. [1] http://developer.apple.com/samplecode/X11CallCarbonAndCocoa/ X11CallCarbonAndCocoa.html

Aug. 29, 2004

Re: tips needed for implementing the common control ICC_STANDARD_CLASSES

by Robert Shearman

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

Aug. 29, 2004

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

by 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. 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. >>>and how wine treats that scheduling (which I also don't). >>> >>> Wine performs local procedure calls to a server to perform the equivalent of Windows syscalls. It does this over Unix domain sockets. Processes block while waiting for data from the server. Rob

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. 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). > > 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.

Aug. 29, 2004

Re: tips needed for implementing the common control ICC_STANDARD_CLASSES

by James Hawkins

Ok I'll try to get that in. Thanks for the tip Juan. On Sat, 28 Aug 2004 22:26:22 -0700 (PDT), Juan Lang <juan_lang(a)yahoo.com> wrote: > James wrote: > > 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. > > It doesn't look like you'd need to do anything special > for the ICC_STANDARD_CLASSES case. The standard > controls are all registered when user32 loads (see the > call to CLASS_RegisterBuiltinClasses in user32's > user_main.c). Comctl32 already imports user32, so > ICC_STANDARD_CLASSES ought to be able to be added to > the /* dummy initialization */ section of > InitCommonControlsEx. > > While you're at it, the comment appears to be > incorrect. It says ICC_LINK_CLASS is unimplemented, > but in fact it is in the case statement below. The > comment at the top of the file is similarly out of > date. > > At least, that's what I get by reading it. YMMV. Try > patching and seeing how kazaa lite does :) > > --Juan > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - Send 10MB messages! > http://promotions.yahoo.com/new_mail > -- James Hawkins

Aug. 29, 2004

Re: tips needed for implementing the common control ICC_STANDARD_CLASSES

by Juan Lang

James wrote: > 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. It doesn't look like you'd need to do anything special for the ICC_STANDARD_CLASSES case. The standard controls are all registered when user32 loads (see the call to CLASS_RegisterBuiltinClasses in user32's user_main.c). Comctl32 already imports user32, so ICC_STANDARD_CLASSES ought to be able to be added to the /* dummy initialization */ section of InitCommonControlsEx. While you're at it, the comment appears to be incorrect. It says ICC_LINK_CLASS is unimplemented, but in fact it is in the case statement below. The comment at the top of the file is similarly out of date. At least, that's what I get by reading it. YMMV. Try patching and seeing how kazaa lite does :) --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

Aug. 29, 2004

Re: tips needed for implementing the common control ICC_STANDARD_CLASSES

by James Hawkins

> This is all just speculation, but maybe it's possible that Kazaa uses a > non-standard control in it's code? You could be right about this, but I'm pretty sure it's ICC_STANDARD_CLASSES that's needed, because the error I get when I try to run wine is: fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 I looked through wine/include and in commctrl.h we have: ICC_STANDARD_CLASSES 0x00004000 and in dlls/comctrl32/commctrl.c we have: * FIXME * implement the following control classes: * ICC_LINK_CLASS * ICC_STANDARD_CLASSES in the docs of InitCommonControlsEx. > 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? Yea if kazaa gives us dlls to use...we'll use em. 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. > > > 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 > > > -- James Hawkins

Aug. 28, 2004

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

by Nyef

On Sun, Aug 29, 2004 at 04:42:04AM +0200, Filip Navara wrote: > > You're pretty much right. I tried to create *very* simple > HelloWorld-type type library with it and and it reported me bunch of > "stub!" messages and crashed. I also found a bug in implementation of > ITypeLib2_fnGetTypeInfoOfGuid (in fact both implementations, the one in > typelib.c and the second in typelib2.c). It should reference the typelib > it's called on. This ensures that later call > ITypeInfo_GetContainingTypeLib will not return bogus pointer if the > original caller already released the TypeLib. See the attached test. If > any COM hacker around can fix it, it would be nice. You're right to be suspicious, and there may actually be a bug with the reference counting in typelib2.c, but fnGetTypeInfoOfGuid should -not- directly AddRef() the containing typelib. Such an AddRef() rightfully belongs in with the implemetations of QueryInterface(), AddRef(), and Release() on ICreateTypeInfo2. It is supposed to be set up that the TypeInfo objects never deallocate themselves when they hit 0 references, but they do hold a reference to their containing typelib. The TypeLib objects never hold a reference to any of their typeinfos (so as not to cause a reference cycle), but they are set up to deallocate the typeinfo structures when the typelib hits 0 references. I'll give the typelib2.c code a look-over tomorrow with an eye towards verifying that reference counting is correct. > Regards, > Filip --Alastair Bridgewater

Aug. 28, 2004

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

by Filip Navara

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. > > Ok, I studied the code more and now I understand the the difference (SLTG vs. MSFT libraries). Thanks for explaining. >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 pretty much right. I tried to create *very* simple HelloWorld-type type library with it and and it reported me bunch of "stub!" messages and crashed. I also found a bug in implementation of ITypeLib2_fnGetTypeInfoOfGuid (in fact both implementations, the one in typelib.c and the second in typelib2.c). It should reference the typelib it's called on. This ensures that later call ITypeInfo_GetContainingTypeLib will not return bogus pointer if the original caller already released the TypeLib. See the attached test. If any COM hacker around can fix it, it would be nice. Regards, Filip #include <windows.h> #include <oaidl.h> #include <stdio.h> #define ok(x,y) if (!(x)) printf(y); else printf("ok\n") int main() { LPTYPELIB ptlibStdOle; LPTYPEINFO ptinfoIUnknown; HRESULT result; result = LoadTypeLib(OLESTR("stdole32.tlb"), &ptlibStdOle); ok(result == S_OK, "can't load stdole32.tlb"); /* continue only if stdole32.tlb is present. */ if (result == S_OK) { ok(ptlibStdOle->AddRef() == 2, "invalid reference count\n"); /* GetTypeInfoOfGuid adds refernece to typelib */ result = ptlibStdOle->GetTypeInfoOfGuid(IID_IUnknown, &ptinfoIUnknown); ok(result == S_OK, "can't get type info about IUnknown"); ok(ptlibStdOle->Release() == 2, "invalid reference count\n"); ok(ptinfoIUnknown->Release() == 0, "invalid reference count\n"); ok(ptlibStdOle->Release() == 0, "invalid reference count\n"); } }

Aug. 28, 2004