November 2002 - Wine-Devel - list.winehq.org

Re: wglCreateLayerContext?

by Lionel Ulmer

> This OpenGL method is currently a stub, looking at the MSDN > documentation I can't see why this is the case given the fairly complete > GL implementation Wine has. Is it that we cannot handle layering > properly in X or something? Well, the case 'iLayerPlane == 0' would be easy as it's the main plane.. But do tell me how you plan to do OpenGL underlay and overlay planes using GLX ? Maybe there is a GLX extension to that effect, but I am not aware of it. Moreover, do you actually have an application using this ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Nov. 28, 2002

Re: [RFC] Winelib enhancements (Linking)

by Dimitrie O. Paun

On November 28, 2002 01:35 pm, Alexandre Julliard wrote: > Yes, I think we want a wrapper like dllwrap to do all that. I'm not > sure a script would be enough, we may want a full-fledged C program. > The idea would be that you do something like: > > winewrap *.o *.res -o foo -lwhatever Excellent, exactly what I had in mind too. And you are right, it will take care of the running business as well. I'll add to the pages. -- Dimi.

Nov. 28, 2002

Re: [RFC] Winelib enhancements (wrc)

by Dimitrie O. Paun

On November 28, 2002 01:35 pm, Alexandre Julliard wrote: > I don't think that's necessary. Using .o files has a number of > problems, and it's really cleaner to use .res IMO. It's also more > along the lines of how Windows does it, and allows you to keep using > windres if you want, instead of being forced to switch to wrc. I did not mean to say that we should chance the way wrc works. Just enhance it to support a "direct to .o" compilation mode. As for "more along the lines of how Windows does it" is an academic issue: all OSS projects coding for Win32 use windres, and they compile directly to .o. Keep in mind that windres can be used just like wrc (.rc -> .res), but nobody uses it like that. The problem with that of course is that the makefiles have the resource.o file in all sorts of variables, etc. You can go and get rid of it from there manually for the initial porting effort, but it's actually not trivial to come up with solution that's acceptable to the app maintainer. Keep in mind that due to these thing working only on Windows, most of the apps don't have (and don't need) a configure script. Tweaking build processes is nasty, nasty business. Even the nice and clean ones are hard to understand, let alone the fact that most are ... weak. :) For a big project, you're in for a lot of pain. Most people will no go through with it if they know they don't have a chance of integrating their changes upstream. Or maybe that's just me... -- Dimi.

Nov. 28, 2002

Re: [RFC] Winelib enhancements (Compiler)

by Dimitrie O. Paun

On November 28, 2002 01:35 pm, Alexandre Julliard wrote: > > -CC=gcc > > +CC=wcc > > > > Q: Alexandre, would you accept such a utility in the tree? > > I don't know, I don't think you can write a one-size-fits-all script, > different apps will require different options, and then it will get > even more confusing IMO if you have two different ways of doing it > depending on your options. Maybe we should simply have a script > example in the documentation that people can adapt and ship with their > app if the makefile really makes it hard to set options. Sorry, maybe I was unclear. This wrapper will probably be a small C program that understands gcc's options. It needs to do the following: -- add the include dirs first -- add -fshort-wchar -- add -D__int8=char -D__int16=short -D__int32=int "-D__int64=long long" -- remove cygwin options not recognized by the Linux gcc If you think about them, it kindda makes sense, as under a Windowish environment these options are _implied_ in the invocation of gcc, just like -I /usr/include is implied when you invoke gcc under Linux. So to be honest, I don't see why it would be confusing, and second, why we can not have a one-size-fits-all wrapper. As I said, this is more a porting tool, to help you with the initial port. If the app has a configure script, you would want to instrument it to generate the correct flags for the compiler, and use gcc directly. But this is time consuming, and you have to worry about so many things at the beginning, I find it so much easier to have something working, and tweak only one thing at a time. -- Dimi.

Nov. 28, 2002

Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)

by Christian Costa

Ove Kaaven wrote: >On Thu, 28 Nov 2002, Christian Costa wrote: > >>Does ICOM_USE_INTERFACE_ATTRIBUTE prevent g++ to add the 8 bytes offset? >> > >Yeah. > >> From which g++ version this can be used? >> > >Not sure, but I'm pretty sure it's been supported in Debian's 2.95.4 stuff >(which grabbed lots of stuff from cvs, I think). So I'd guess that it >probably works in 3.0. > > > Thanks! It works fine with the version 2.96 I use.

Nov. 28, 2002

Re: [RFC] Winelib enhancements

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > However, these tweaks are really annoying in the initial > stages of the port, and would be so nice if we had a nice > compiler wrapper (call it wcc) that would do that behind > the scenes, so that the only modification to the makefile > would be: > > -CC=gcc > +CC=wcc > > Q: Alexandre, would you accept such a utility in the tree? I don't know, I don't think you can write a one-size-fits-all script, different apps will require different options, and then it will get even more confusing IMO if you have two different ways of doing it depending on your options. Maybe we should simply have a script example in the documentation that people can adapt and ship with their app if the makefile really makes it hard to set options. > -RC=windres > +RC=wrc > > This would mean moving the resources out of the .spec.c > file, and exporting the resources variable so we can link > it into the .spec.c file. > > Q: Alexandre, is this acceptable? Does it warrant discussion? I don't think that's necessary. Using .o files has a number of problems, and it's really cleaner to use .res IMO. It's also more along the lines of how Windows does it, and allows you to keep using windres if you want, instead of being forced to switch to wrc. > 2. Our linking process is quite different from the "standard" > one which uses gcc/ld to do the linking. We generate > intermediate files (.spec.c files), and use different flags. > Again, the solution for this (to at least help initial > porting efforts) would be a wrapper script that does this, > that can be used instead of ld. And so the question comes > back again, to haunt us: is this needed/wanted/acceptable? Yes, I think we want a wrapper like dllwrap to do all that. I'm not sure a script would be enough, we may want a full-fledged C program. The idea would be that you do something like: winewrap *.o *.res -o foo -lwhatever and it builds the .spec.c, compiles it, links everything into foo.exe.so, and builds a foo executable (which may be a wrapper script or a real ELF binary). This also (mostly) solves the "Running" issues: you still have a .exe.so file, but you don't really need to worry about it. You simply run "foo" and everything works. -- Alexandre Julliard julliard(a)winehq.com

Nov. 28, 2002

Re: How to debug wineserver

by Martin Wilck

Am Don, 2002-11-28 um 17.16 schrieb Tony Lambregts: > >is there any way we can debug the wineserver? > I am not sure this is the right answer since I am not a wine guru. > However when you start wineserver you can start it with debug levels > i.e., "wineserver -d1". Setting d0 turns winserver debugging off. Starting wine with "-debugmsg trace+server" works quite well. Furthermore, wineserver is a true Unix program. You can run in through gdb. I often run wine normally, then start gdb and simply attach to the running wineserver process. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Nov. 28, 2002

Re: Modifying registers

by Tony Lambregts

Fabian Cenedese wrote: > >> > Generally, is there a way to modify registers? Must be obvious but >> I'm blind. >> >> set $eip = 0x42424242 >> >> Dito for the other registers. > > > Thanks, worked fine. Should this be added to the docs? Even knowing now > what to look for I couldn't find it. I guess this was taken from gdb's > interface. > Are there other 'unofficial' :) features in winedbg? > > I will add this as part of the Advanced Debuging Techniques section of the Developers Guide. (working on it.) -- Tony Lambregts

Nov. 28, 2002

Chronic crash on Photoshop

by Robert North

Can someone look at the bug I raised about Photoshop crashing wine, (and potentially the whole of X11 and Linux) http://bugs.winehq.com/show_bug.cgi?id=1165 It's probably the most extreme bug I've seen on Linux ever. I wasn't sure if this was the appropriate place to post this request, so feel free to correct me. Cheers -Rob.

Nov. 28, 2002

Re: How to debug wineserver

by Tony Lambregts

Rajesh Akkineni wrote: >hi, >is there any way we can debug the wineserver? >thanks >Rajesh > > > > I am not sure this is the right answer since I am not a wine guru. However when you start wineserver you can start it with debug levels i.e., "wineserver -d1". Setting d0 turns winserver debugging off. I'm not sure what you are asking this for. -- Tony Lambregts

Nov. 28, 2002