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

Re: d3d8 CVS doesn't compile

by Lionel Ulmer

> That seems really overkill. It's OK to define some symbols ourselves > when they have well-known values, but I don't think shipping the full > headers is really necessary; and I don't see how it would solve issues > like the above anyway. Well, the more 'recent' extensions we will use, the more problems we will have. So, to fix all these 'Wine CVS does not build' issues, we can either : 1) test ALL extensions we plan to use in the configure script and disable on an one-per-one basis. Which is a pain to maintain and not really in-line with what OpenGL provides (as extension should be checked at run-time and not at compile time to have one binary work everywhere). 2) do some 'partial' re-implementation of OpenGL headers in the Wine source tree (which is what is done in the dlls/d3d8/d3dcore_gl.h file) 3) ship ourselves the most up-to-date version of the OpenGL headers (actually, we could only ship glext.h but due to bugs in some vendors' gl.h and glx.h files, it's a bit problematic) which would mean removal of all the #ifdef / #endif in the code and all the re-definition of the constants in the d3dcore_gl.h file. What I prefer in the third solution is its 'simplicity'... I.e. maybe shipping glext.h ourselves is overkill, but at least we will develop against a known target instead of having to each time copy / paste the needed extensions in our own header files one by one. Anyway, it's more Raphael's problem than mine so I will let him continue the discussion if he wishes to :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

April 28, 2004

Re: [Darwine] compiling wine on Darwin/MacOS X 4/10

by emmanuel maillard

Hi, This patch will replace the previous one. It fix the stack corruption problem, so exceptions are correctly handle. Changelog : Add darwin/ppc support in THREAD_InitStack emmanuel Le 16 avr. 04, à 10:13, Pierre d'Herbemont a écrit : > Emmanuel, > > I know that I did this hack, but it is not really a good one. Since it > corrupts the stack (you get a stack frame error at every signal > caught). > So this issue would need to be a bit more investigated. But it is > required for now, without it you can't launch an App. > > Pierre > > PS: its good to see that someone takes time to send those patches and > work ;) So thanks for that. > > On 15 avr. 04, at 23:36, emmanuel maillard wrote: > >> Hi, >> >> an other patch for darwin/ppc >> >> changelog >> Add darwin/ppc support in THREAD_InitStack >> >> emmanuel >> >> <kernel_thread.diff> >

April 28, 2004

Re: d3d8 CVS doesn't compile

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: >> I could only find glCompressedTexImage2DARB in my glext.h >> (SGI OpenGL 1.2.1). Any clues? > > Alexandre, > > Would you accept a patch to provide our own OpenGL headers in the Wine > source tree ? From what I know, their licensing is pretty relaxed (I can > check though) and it would prevent all the myriads of compiling problems / > #ifdef magic we have with GL code in Wine. That seems really overkill. It's OK to define some symbols ourselves when they have well-known values, but I don't think shipping the full headers is really necessary; and I don't see how it would solve issues like the above anyway. -- Alexandre Julliard julliard(a)winehq.org

April 28, 2004

Re: [D3D8] Many Improvements

by Raphael

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 27 April 2004 22:33, Duane Clark wrote: > This commit to CVS doesn't compile for me: > http://www.winehq.org/hypermail/wine-cvs/2004/04/0346.html > > The part the doesn't compile is the replacement of > glCompressedTexImage2DARB() > > - glCompressedTexImage2DARB(gl_target, > - ... > + glCompressedTexImage2D(gl_target, > + ... > > The old name compiled fine for me; changing it back fixes the compile. > This is on RH7.3. Yes, you have an old (too old?) GL header. I have just sent a patch to fix it Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAj+l2p7NA3AmQTU4RApdTAJ9n8EWRAa0nsxAOhJodHV9XO3V2BwCfc7+N EO0xGqH7Ws1Vs1LY/lljnpE= =Dg30 -----END PGP SIGNATURE-----

April 28, 2004

Re: RFH: winetest testing

by Shachar Shemesh

Kevin Koltzau wrote: >If the service is flagged as interactive, everything acts normally > > Except you can take control over the process, thus escalating priveleges. MS's reply? "It's an application bug. Don't use interactive services". With such a reply, you would really expect them not to ship any interactive services themselves, wouldn't you? Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

April 28, 2004

Re: RFH: winetest testing

by Shachar Shemesh

Kevin Koltzau wrote: >GINA runs on a completely dedicated, secure windows station, there are 2 such >window stations, the one displayed at login (which is also the one shown when you >hit ctrl-alt-del), the other is used by the screen saver >the only windows that can be displayed on these are generated by the Messenger >service, which simply displays a popup window on the current window station that >is attached to user input > > At a demo in Black Hat Windows 2001, in Las Vegas, a guy from the rootkit project was demoing their stuff. Amazing stuff. One of the things he was demoing was fresh out of the oven. A kernel-mode rootkit launching a user-mode process. They were taking another process, and copying it's process information for their newly created process. He was running cmd, IIRC. The thing is, he was demoing how he was telneting (to a fake IP), and issued a command to run CMD, and nothing happened. And the guy says "oh well, I said it was experimental". Then, a couple of minutes later, the guy presses CTRL+ALT+DEL for an unrelated reason, and guess what? There is his CMD Window, functional and all. They were cloning the information of the wrong Win32 process. Not entirely relevant, and obviously once your'e in kernel mode, you can do anything. Still, that's where my info comes from. Sorry about the distraction. Just thought you may enjoy the story. Shachar p.s. http://www.rootkit.com, in case anyone is interested. -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

April 28, 2004

Re: RFH: winetest testing

by Kevin Koltzau

On Wednesday 28 April 2004 07:59 am, Shachar Shemesh wrote: > First of all, we are talking about "non-interactive serivces" only. Yes > Actually, I think the user WILL see them if she presses "ctrl-alt-del". > The GINA login window is one such window opened by a service, as well as > that thing that pops up only when you press ctrl+alt+del. GINA runs on a completely dedicated, secure windows station, there are 2 such window stations, the one displayed at login (which is also the one shown when you hit ctrl-alt-del), the other is used by the screen saver the only windows that can be displayed on these are generated by the Messenger service, which simply displays a popup window on the current window station that is attached to user input

April 28, 2004

Re: exec-shield patch take 6

by Mike Hearn

On Wed, 28 Apr 2004 20:13:34 +0900, Mike McCormack wrote: > * figure out how to find the base address of the preloader at link time > so it's not hardcoded in the source. If it was dynamic we could simply walk the _DYNAMIC list, but as it's static I think /proc/self/maps is the only way. Of course, that isn't portable either :) > The main problem is getting Alexandre to review it, and figure out what > other things he wants addressed before it can be included. Until that > happens, I'm going to maintain and periodically improve the patch so > that others can use/test it. Cool. I don't have time to work on this anymore anyway. > Well, we can't get it right unless we know the location of the PE that's > going to be run, so the idea is that Wine will always load a simple > winelib exe that calls CreateProcess first. CreateProcess passes the > unix path of the PE image in WINEPEEXEPATH. Argh, more init complexity. This is going to get confusing fast :) thanks -mike

April 28, 2004

Re: RFH: winetest testing

by Kevin Koltzau

On Wednesday 28 April 2004 06:25 am, Francois Gouget wrote: > I don't think that it is correct to say that services cannot cerate > windows. From what I remember from the time I wrote a service and how I > read the information at the URLs you provided, what happens is that a > service can create windows but the user won't see them, and the user > won't be able to send input of click on them. But as long as the process > does not expect the user to do anything with the windows it puts up we > should be fine. > > Note that some tests need to be able to create windows. See for instance > user32_test.exe. If services cannot create Windows at all (i.e. if > CreateWindow fails for services), then many important tests are likely > not to work at all, thus greatly reducing the usefulness of such a > service process! > > (based on the trend I suspect we'll get more and more window related tests) Services can create windows, but when the service is not flagged as interactive its windows don't act completely normally, AFAIK. >From what I remember in my past work with services (which has been a while so I may be forgetting something here), windows created from a non-interactive service dont show up in the system window list (as seen by apps like spy++), and they cannot be visible (that is, the windows are created hidden, and a call to ShowWindow will always fail) If the service is flagged as interactive, everything acts normally

April 28, 2004

Re: RFH: winetest testing

by Shachar Shemesh

Francois Gouget wrote: >On Tue, 27 Apr 2004, Kevin Koltzau wrote: >[...] > > >>Under NT, services run under a dedicated window station separate from the interactive >>window station. It is not possible for them to create windows, as there is no display or >>user input associated with this windows station, they can however have a console >> >> > > > First of all, we are talking about "non-interactive serivces" only. >I don't think that it is correct to say that services cannot cerate >windows. From what I remember from the time I wrote a service and how I >read the information at the URLs you provided, what happens is that a >service can create windows but the user won't see them, and the user >won't be able to send input of click on them. > Actually, I think the user WILL see them if she presses "ctrl-alt-del". The GINA login window is one such window opened by a service, as well as that thing that pops up only when you press ctrl+alt+del. I hope this helps. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

April 28, 2004