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

Re: RFH: winetest testing

by Kevin Koltzau

On Wednesday 28 April 2004 07:38 am, Jakob Eriksson wrote: > What about "Allow service to interact with desktop" I have seen > somewhere in Windows? You run the service under the local system account and pass SERVICE_INTERACTIVE_PROCESS for service type when calling CreateService

April 28, 2004

Re: RFH: winetest testing

by Jakob Eriksson

On Wed, Apr 28, 2004 at 12:25:31PM +0200, 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 > > 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. What about "Allow service to interact with desktop" I have seen somewhere in Windows? -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News

April 28, 2004

Re: exec-shield patch take 6

by Mike McCormack

Mike Hearn wrote: > Go Mike! Good to see this work finally turn into a patch against CVS Well, there's a few things that probably need to be done before it can be applied: * consider turning it back into a standalone program rather than a shared object loader ... for portability, there may be platforms for which that don't work with that approach, and because Alexandre doesn't like the way that we need to change directories * figure out how to find the base address of the preloader at link time so it's not hardcoded in the source. * fix the case when a symbol we're searching for isn't present in the loaded image (in wld_find_symbol() ) so it doesn't crash. * allocate the buffer to store ld-linux.so.2's ELF header dynamically using calloc() * don't hardcode the name of ld-linux.so.2 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. > 0x1000000? Are you sure you didn't drop a zero somewhere? That's only > 16mb.... we probably want something like 0x40000000 which reserves a gig > of address space. Some very large game installers can in fact get close > to this level, and as it's just non-backed address space we're reserving > (for a shor time) there's no real reason to be stingy. 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. Once the location of the PE image is known, the preload reserves exactly the right amount of memory for that image. > You know, I wonder if we couldn't make this simpler ... well, shorter, > by assuming the stack is already set up and the main binary is mapped > correctly, then being careful not to disturb the linker entry stack just > reserve the areas we need with a few mmap syscalls, map in the real > dynamic linker and do a jump. In effect, rather than repeat the work the > kernel already did for everything but the real dynamic linker, insert a > small shim between them. > > Thoughts? That's exactly the way it works :) Mike

April 28, 2004

Re: RFH: winetest testing

by Francois Gouget

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 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) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

April 28, 2004

Re: exec-shield patch take 6

by Mike Hearn

Go Mike! Good to see this work finally turn into a patch against CVS :) On Wed, 2004-04-28 at 19:02 +0900, Mike McCormack wrote: > Description: > > This patch allows platforms using exec-shield patch against the Linux > kernel (eg. Fedora Core) to run Wine without disabling exec-shield. It also fixes the prelink case, right? :) > + vars.pe_size = 0x01000000; 0x1000000? Are you sure you didn't drop a zero somewhere? That's only 16mb.... we probably want something like 0x40000000 which reserves a gig of address space. Some very large game installers can in fact get close to this level, and as it's just non-backed address space we're reserving (for a shor time) there's no real reason to be stingy. > +/* > + * The _start function is the entry and exit point of this program > + * > + * It calls wld_start, passing a pointer to the args it receives > + * then jumps to the address wld_start returns after removing the > + * first argv[] value, and decrementing argc > + */ > +void _start(void); > +__asm ( > + ".align 4\n" > + "\t.global _start\n" > + "\t.type _start,@function\n" > +"_start:\n" > + "\tcall wld_start\n" > + "\tpush %eax\n" > + "\txor %eax,%eax\n" > + "\txor %ebx,%ebx\n" > + "\txor %ecx,%ecx\n" > + "\txor %edx,%edx\n" > + "\tret\n" > +); You know, I wonder if we couldn't make this simpler ... well, shorter, by assuming the stack is already set up and the main binary is mapped correctly, then being careful not to disturb the linker entry stack just reserve the areas we need with a few mmap syscalls, map in the real dynamic linker and do a jump. In effect, rather than repeat the work the kernel already did for everything but the real dynamic linker, insert a small shim between them. Thoughts? thanks -mike

April 28, 2004

Re[2]: Ukrainian translation

by Ylia K

-----Original Message----- From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> To: "Ylia K" <k_ilya(a)ukr.net> Date: Mon, 26 Apr 2004 23:52:14 +0900 Subject: Re: Ukrainian translation > "Ylia K" <k_ilya(a)ukr.net> wrote: > > > * dlls/kernel/nls/ukr.nls, dlls/comctl32/rsrc.rc, dlls/commdlg/rsrc.rc, dlls/user/resources/user32.rc, dlls/shell32/shres.rc, > > dlls/comctl32/comctl_Uk.rc, dlls/commdlg/cdlg_Uk.rc, dlls/shell32/shell32_Uk.rc, dlls/user/resources/user32_Uk.rc : > > > > Ilya Korniyko <k_ilya(a)ukr.net> > > > > Ukrainian translation: full translation of comclt32, commdlg, shel32, user dlls, fixes in ukr.nls > > You shouldn't touch ukr.nls since it has been auto generated. > > -- > Dmitry. > > > Ok, I'll make another patch ---------------- Best Regards, Ilya Korniyko

April 28, 2004

Re[2]: Add stub function HWND GetConsoleWindow()

by Ylia K

-----Original Message----- From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> To: "Ylia K" <k_ilya(a)ukr.net> Date: Mon, 26 Apr 2004 23:50:35 +0900 Subject: Re: Add stub function HWND GetConsoleWindow() > "Ylia K" <k_ilya(a)ukr.net> wrote: > > > * dlls/kernel/kernel32.spec, dlls/kernel/console.c, include/wincon.h > > Ilya Korniyko <k_ilya(a)ukr.net> > > Add stub function HWND GetConsoleWindow() > > > > It is for excelent file manager FAR Manager (www.rarlab.com) > > FAR Manager doesn't run without this patch. > > With patch it runs - good on winXP, very bad on winME. > > I'm wondering how your patch works at all, the call should smash > the stack since it misses WINAPI modifier. > > -- > Dmitry. > > > Yes I missed it :( But it works for me somehow! Though this function is already added in latest release, without my patch (only to .spec & .c , not ot wincon.h) ---------------- Best Regards, Ilya Korniyko

April 28, 2004

Re: d3d8 CVS doesn't compile

by Lionel Ulmer

> 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. After, we need to decide if we put them in include/GL/XXX.h and 'ship' them with Winelib or if we put them in include/wine/XXX.h so as to use them only to build Wine but Winelib users will use the standard OpenGL library. Both have problems though (mostly due to the calling convention problems). Lionel -- Lionel Ulmer - http://www.bbrox.org/

April 28, 2004

Re: SetFocus

by Alexandre Julliard

Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > Hmmm. It didn't work for me when I tried under win2k. I'll investigate it > further. I added a small test in dlls/user/tests/win.c if it helps. -- Alexandre Julliard julliard(a)winehq.org

April 28, 2004

Re: SetFocus

by Ulrich Czekalla

Hmmm. It didn't work for me when I tried under win2k. I'll investigate it further. /Ulrich On Tue, Apr 27, 2004 at 08:52:35PM -0700, Alexandre Julliard wrote: > Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > > > ChangeLog: > > Ulrich Czekalla <ulrich(a)codeweavers.com> > > Trying to set focus to an invisible window should fail > > I don't think that's correct, setting focus to an invisible window > seems to work fine on Windows. > > -- > Alexandre Julliard > julliard(a)winehq.org >

April 28, 2004