May 2001 - Wine-Devel - list.winehq.org

some unimplemented COM stuff

by Malte.Starostik＠t-online.de

Hello, I have started implementing a small winelib-program that shall eventually add ActiveX support to the Konqueror web browser. For testing I'm using the Shockwave Flash OCX and experienced some problems due to unimplemented functions and features in winelib. First thing is typelib registration, which doesn't work yet as the debug output tells. Okay, did that manually. Then, for setting the control's properties, I tried the easy way via IDispatch::Invoke(), which calls ITypeInfo::Invoke() and that's only a stub :( I worked around this via evil assembler hacks to call the interface's members as given by the vtable offsets in the FUNCDESC using stdcall convention - unfortunately g++ doesn't support specifying a calling convention for method pointers like HRESULT (IDispatch::*setProp)(BSTR). After getting this to work, I hit the next problem: unimplemented urlmon.RegisterBindStatusCallback and when I use a native urlmon.dll it tries to call shlwapi.154, with native shlwapi it still doesn't work somehow, but that's a different story. Anyway, what I'd basically need to get this to work properly is - typelib registration - IDispatch::Invoke() - RegisterBindStatusCallback() and probably asyncronous bind contexts - probably a "real" URL Moniker, not just CreateURLMoniker() using a File Moniker What I'd like to know is if anyone is already working on any of these and if so what's the status and how I could help getting these implemented. if no one started yet, I'd still like to give it a try. Thanks, -Malte PS: the attached patch fixes urlmon.h not being C++-safe. -- Wars don't determine who's right, only who's left.

May 28, 2001

a tool: simple C++ interface definition -> ICOM_ macro converter.

by TAKESHIMA Hidenori

This program may help creating ICOM_ macro. (but this code doesn't have portability, so some modification may be required.) for example, if give the following codes to stdin, we gets ICOM_ macros for IPersist. class IUnknown { public: HRESULT QueryInterface( REFIID riid, LPVOID *ppvObj) ; ULONG AddRef() ; ULONG Release() ; }; export interface IPersist : public IUnknown { virtual HRESULT STDMETHODCALLTYPE GetClassID( CLSID *pClassID ); };

May 28, 2001

Wrc patch

by kenon＠go2.pl

Hi, This patch is an answer for "Call for volunteers". I hope it fixes : "wrc fails on preprocessed files" #115: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=115 Maciek Changelog * tools/wrc/ppy.y Maciek Kaliszewski <kenon(a)go2.pl> Added better GCC-style #line directive handling. --

May 28, 2001

Enabling backing store

by David Hagood

Has any thought been given to enabling backing store on Wine's windows? As it stands now, when you obscure a Wine window, it forces the Windows app to redraw the screen. Many times this is not needed. Perhaps a configuration option to allow certain apps to have backing store on would be useful. I know that up until a few months ago, it was possible to go into wnd.c and change the default from NotUseful to WhenMapped and things seemed to work well. However, the structure of the X driver has changed, and a simple patch is no longer possible.

May 27, 2001

Re: X Error with latest Wine and Notes

by Ian Pilcher

David.Goodenough(a)dga.co.uk wrote: > > I have noticed that with the latest Wine (May drop) I have started to get X > Errors. This typically happens as a dialog is being dismissed. > > The latest of these errors read:-- > > X Error of failed request: BadWindow (invalid Window parameter) > Major opcode of failed request: 12 (X_ConfigureWindow) > Resource if in failed request: 0x1c24350 > Serial number of failed request: 9920 > Current serial number in output stream: 9922 > > I get the feeling, although I can not prove it, that this may be timing > related, as it tends to happen when I am a bit quick completing the dialog. > The other odd thing that happens when this occurs is that a second copy of > the window, not the detail face of the window, just the window and its > frame controls, is drawn slightly down and right of the original window, > then it blows and Notes hangs. > > I had not noticed this behaviour before switching to the May drop. There > are no other console messages that are out of the ordinary set that I have > been reporting for a while. > > Is this a known problem? David - I have also seen this problem, but I have no idea what causes it. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 27, 2001

Re: Q: anybody using Exceed on NT4 as X server for wine?

by Stefan Leichter

Heiko Nardmann wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Is there anybody out there who uses Exceed on NT4 as the X server to display > wine applications (like winemine from examples) which have been started on > Linux? > > If yes are did you try 20010510 snapshot (or CVS) to run your applications? > > If yes could you provide me with your configuration files? I am still not > able to start winemine since snapshot 20010418 (20010326 works fine). > Hello, i am able to run programs on a remote computer using Exceed for NT4. I tried FREECELL and regw32.exe (www.heise.de) I have started the programs from an xterm, maybe this is not what you like to do. With the attached xstart file i am also able to run freecell directly. But if i remove /usr/bin/X11/xtern from the xstart file the program terminates after some minutes. Bye Stefan [Xstart] Start Method=4 Program Type=0 User Id=sle Password= Command=export DISPLAY=sle2:0 ; /usr/bin/X11/xterm -ls -e wine -- 'D:\FREECELL\FREECELL.EXE' 2>&1 | tee /wine_app/tmp/freecell.log Info Prompt=0 Description=Freecell(a)sle3 Host=sle3 Connect Timeout=1 Close Timeout=50 Response Timeout=4 Prompt Timeout=2 Show Progress=1 Log Reply=0 UserId Prompt=login:|Username: Password Prompt=password:

May 26, 2001

Re: AFM files no longer required

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > Here's a thought. How about creating a data subdirectory for the Post- > Script driver (i.e. dlls/wineps/data). The data could then be put in > separate files in that directory without confusing things. (The data > isn't interdependent from a build point of view, just from a main- > tenance point of view.) > > I don't know the Makefile magic necessary to do this, but if someone > could step forward with that piece, I suspect it would address both of > our concerns. > > What do you think? That's certainly a viable solution yes. If you send me a patch implementing the separate files I'll do the Makefile magic. -- Alexandre Julliard julliard(a)winehq.com

May 25, 2001

Re: AFM files no longer required

by Ian Pilcher

Here's a thought. How about creating a data subdirectory for the Post- Script driver (i.e. dlls/wineps/data). The data could then be put in separate files in that directory without confusing things. (The data isn't interdependent from a build point of view, just from a main- tenance point of view.) I don't know the Makefile magic necessary to do this, but if someone could step forward with that piece, I suspect it would address both of our concerns. What do you think? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 25, 2001

Re: AFM files no longer required

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > I actually gave quite a bit of thought to the large file issue before > submitting it, and I would agree with you if there were any functional > code in the file. Because it's entirely data, and it's heavily > interdependent, I really think that one file is better. I disagree. If the data is so interdependent that you cannot split the file, you are doing something wrong IMO. And in fact splitting it will help enforce a clean data structure, which is a major advantage. > From a build point of view, gcc has no problem at all with the file. In > fact it compiles much faster than many of Wine's functional files. I know some older versions of gcc had problems with large data structures, using exponential memory to compile them or something like that. > If a > target compiler (does Wine build with anything other than gcc?) does have > a problem with it, I will yield to necessity. Until that happens, how- > ever, I believe that the practical benefit of maintainability outweighs > stylistic concerns. (After all, it's not like anyone will ever need to > read all the way through the file to understand it, as is the case with > functional code.) You may not need to read every single line, but you still need to go through it if you want to understand the structure (this is how I noticed it was too large...). So please consider splitting it. -- Alexandre Julliard julliard(a)winehq.com

May 25, 2001

Re: AFM files no longer required

by Ian Pilcher

Forgot to cc wine-devel. Alexandre Julliard wrote: > > You should really split it into separate files, a 40,000 lines file is > a bit too much. Also all this data must be constant and in a read-only > section, it's eating 400k of data space right now. I actually gave quite a bit of thought to the large file issue before submitting it, and I would agree with you if there were any functional code in the file. Because it's entirely data, and it's heavily interdependent, I really think that one file is better. (As the person most likely be tweaking the data in the near future, I can tell you that having a single file to edit, albeit a long one, will be heck of a lot easier than having 39 separate files, and isn't that really the point?) >From a build point of view, gcc has no problem at all with the file. In fact it compiles much faster than many of Wine's functional files. If a target compiler (does Wine build with anything other than gcc?) does have a problem with it, I will yield to necessity. Until that happens, how- ever, I believe that the practical benefit of maintainability outweighs stylistic concerns. (After all, it's not like anyone will ever need to read all the way through the file to understand it, as is the case with functional code.) I would like to make the data constant, but that would require major surgery to afm.c, which is more than I can take on at this point. Keep in mind that the same amount of memory is being used currently; it's just dynamically allocated as the AFM files are read in. > > I'm guessing that you have a script to generate all this; could you > please consider submitting it? This way other people can make changes > too. > I have attached the two programs I use to generate agl.c. I have always intended to submit them, but didn't know where in the source tree to put them. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 25, 2001