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. 29, 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. 29, 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. 29, 2004

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. 29, 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. 29, 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

Re: W->A cleanup of DirectDrawEnumerateEx part 1

by James Hawkins

I guess this is one of the w->a cases that shouldnt be fixed if this is the case. On Sat, 28 Aug 2004 18:30:50 +0200, Lionel Ulmer <lionel.ulmer(a)free.fr> wrote: > On Sat, Aug 28, 2004 at 12:17:27PM -0400, James Hawkins wrote: > > Changelog > > * change szDriver and szDescription from char to WCHAR in > > DDDEVICEIDENTIFIER and DDDEVICEIDENTIFIER2. > > Well, this seems completely wrong to me. Why Unicodify an API that has no > Unicode equivalent in Microsoft code ? > > If I look at the platform SDK, this structure is defined with a 'char', so I > wonder why you would choose to deviate from the standard ? > > Lionel > > -- > Lionel Ulmer - http://www.bbrox.org/ > > -- James Hawkins

Aug. 28, 2004

Re: W->A cleanup of DirectDrawEnumerateEx part 4

by Lionel Ulmer

On Sat, Aug 28, 2004 at 12:20:24PM -0400, James Hawkins wrote: > Changelog > * cleanup cross calls in DirectDrawEnumerateEx To continue with my other mail, you should have sent all this in one big patch as (from what I can see) it cannot work if you do not apply all 4 parts in one go. Anyway, the 'problem' in Wine is that it uses the DDDEVICEIDENTIFIER2 structure to hold driver information. But, as this information is also exported via API calls like the 'GetDeviceIdentifier' method from the DDraw COM object, you cannot just Unicodify it, you need to let it in ASCII (as there are no, AFAIK, Unicode versions of any of the DirectX < 8 APIs). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 28, 2004

Re: W->A cleanup of DirectDrawEnumerateEx part 1

by Lionel Ulmer

On Sat, Aug 28, 2004 at 12:17:27PM -0400, James Hawkins wrote: > Changelog > * change szDriver and szDescription from char to WCHAR in > DDDEVICEIDENTIFIER and DDDEVICEIDENTIFIER2. Well, this seems completely wrong to me. Why Unicodify an API that has no Unicode equivalent in Microsoft code ? If I look at the platform SDK, this structure is defined with a 'char', so I wonder why you would choose to deviate from the standard ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 28, 2004

RE: patch: shell32.dll - SHELL_ArgifyW expands env-vars

by Jens Collin

Is there anything wrong with this patch? I can't see my changes taken place in CVS. Let me know and I'll fix 'em. /J -----Original Message----- From: wine-patches-admin(a)winehq.org [mailto:wine-patches-admin(a)winehq.org] On Behalf Of Jens Collin Sent: den 8 augusti 2004 17:55 To: wine-patches(a)winehq.org Subject: patch: shell32.dll - SHELL_ArgifyW expands env-vars changelog: * lookup of envoronment-vars in SHELL_ArgifyW in shell32.dll added. (Such as %SystemRoot%).

Aug. 28, 2004

Richedit control

by Mike McCormack

Hi All, I'm going to play with the richedit control to try get it to draw RTF documents with formatting. My plan is to write a program that can display but not edit, then let somebody else add the editting functionality afterwards :) Once I can get the attached program to work, the plan is to change the code in text-writer.c to add the formatting information to the richedit control via standard richedit messages. If anybody is already working on it, or wants to have a go, let me know. Mike #include <stdio.h> #include <windows.h> #include <winuser.h> #include <richedit.h> void fill_richedit( HWND hwnd ) { PARAFORMAT pf; CHARFORMAT cf; SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "this is a test\n"); // add text on the right memset( &pf, 0, sizeof pf ); pf.cbSize = sizeof pf; pf.dwMask = PFM_ALIGNMENT; pf.wAlignment = PFA_RIGHT; SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "right\n"); // add text in the center memset( &pf, 0, sizeof pf ); pf.cbSize = sizeof pf; pf.dwMask = PFM_ALIGNMENT; pf.wAlignment = PFA_CENTER; SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "centre\n"); // add text on the left memset( &pf, 0, sizeof pf ); pf.cbSize = sizeof pf; pf.dwMask = PFM_ALIGNMENT; pf.wAlignment = PFA_LEFT; SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "left\n"); // add bold text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_BOLD; cf.dwEffects = CFE_BOLD; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "bold "); // add italic text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_ITALIC | CFM_BOLD; cf.dwEffects = CFE_ITALIC; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "italic "); // add underlined text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_ITALIC | CFM_BOLD | CFM_UNDERLINE; cf.dwEffects = CFE_UNDERLINE; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "underline "); // add strikeout text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_ITALIC | CFM_BOLD | CFM_UNDERLINE | CFM_STRIKEOUT; cf.dwEffects = CFE_STRIKEOUT; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "strikeout"); // add normal text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_BOLD | CFM_ITALIC | CFM_UNDERLINE | CFM_STRIKEOUT; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) " normal\n"); // add red text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_COLOR; cf.crTextColor = RGB(255,0,0); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "red "); // add green text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_COLOR; cf.crTextColor = RGB(0,255,0); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "green "); // add blue text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_COLOR; cf.crTextColor = RGB(0,0,255); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "blue\n"); // try some fonts memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_FACE | CFM_SIZE; cf.yHeight = 300; strcpy(cf.szFaceName, "Tahoma"); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "tahoma "); // try some fonts memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_FACE; strcpy(cf.szFaceName, "Helvetica"); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "Helvetica "); // try some fonts memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_FACE; strcpy(cf.szFaceName, "Courier"); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "Courier "); } LRESULT WINAPI ParentWindowProc (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { RECT r; HWND hwndRichedit = (HWND) GetWindowLong( hWnd, 0 ); char *cls; //cls = RICHEDIT_CLASS; //cls = "RICHEDIT10A"; cls = "RICHEDIT"; switch(msg) { case WM_CREATE: GetClientRect( hWnd, &r ); hwndRichedit = CreateWindow( cls, "", WS_CHILD | WS_VISIBLE | ES_MULTILINE | ES_SUNKEN, 0, 30, r.right-r.left, r.bottom - r.top - 30, hWnd, NULL, NULL, NULL ); fill_richedit( hwndRichedit ); SetWindowLong( hWnd, 0, (LONG) hwndRichedit ); break; case WM_CLOSE: DestroyWindow(hWnd); break; case WM_LBUTTONDOWN: InvalidateRect( hWnd, NULL, TRUE ); break; case WM_DESTROY: PostQuitMessage( 0 ); break; } return DefWindowProc(hWnd,msg,wParam,lParam); } /*********************************************************************** * * WinMain */ int PASCAL WinMain (HINSTANCE hInstance, HINSTANCE prev, LPSTR cmdline, int show) { WNDCLASS cls; char className[] = "parentclass"; /* To make sure className >= 0x10000 */ char winName[] = "Richedit control"; HWND hWnd; MSG msg; LoadLibrary("riched32"); cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; cls.lpfnWndProc = ParentWindowProc; cls.cbClsExtra = 0; cls.cbWndExtra = 4; cls.hInstance = 0; cls.hIcon = LoadIcon (0, IDI_APPLICATION); cls.hCursor = LoadCursor (0, IDC_ARROW); cls.hbrBackground = GetStockObject (WHITE_BRUSH); cls.lpszMenuName = 0; cls.lpszClassName = className; if (!RegisterClass (&cls)) return FALSE; /* Setup windows */ hWnd = CreateWindow (className, winName, WS_OVERLAPPEDWINDOW , CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0, NULL, hInstance, 0); ShowWindow (hWnd, show); UpdateWindow (hWnd); /* now enter mesage loop */ while( 0 != GetMessage( &msg, 0, 0, 0 ) ) { TranslateMessage( &msg ); DispatchMessage( &msg ); } return 0; }

Aug. 28, 2004