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

Re: Windows screensaver.

by gleb＠nbase.co.il

On Sun, Dec 23, 2001 at 03:24:41PM -0500, David Elliott wrote: > Hope that helps you to figure it out! Yes! Your answer is very helpful. Thank you and others who answered me in private. -- Gleb.

Dec. 24, 2001

DOS stuff pretty much broken [Re: wine/ dlls/kernel/kernel_main.c dlls/kernel/wp ...]

by Andreas Mohr

On Tue, Dec 04, 2001 at 02:54:50PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 1007495689308334133587778 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine2. 01/12/04 14:54:50 > > Modified files: > dlls/kernel : kernel_main.c wprocs.spec > dlls/ntdll : Makefile.in ntdll.spec > dlls/winedos : Makefile.in dosvm.c int09.c module.c > winedos.spec > graphics : dispdib.c > include : callback.h miscemu.h > miscemu : main.c > msdos : Makefile.in dosmem.c dpmi.c int20.c int21.c > int2f.c interrupts.c ioports.c > Added files: > dlls/winedos : devices.c dosaspi.c dosexe.h int10.c int16.c > int17.c int19.c int20.c int21.c int29.c int31.c > int33.c ioports.c vga.c vga.h xms.c > Removed files: > include : dosexe.h vga.h > msdos : devices.c dosaspi.c int10.c int16.c int17.c > int19.c int29.c int33.c vga.c xms.c > > Log message: > Moved most of the real-mode stuff to dlls/winedos. > > Patch: http://cvs.winehq.com/patch.py?id=1007495689308334133587778 This one probably breaks a whole heap of older Win3.x apps. When I started the Win98 setup.exe for fun, it choked on int 0x21 "list of lists" (DOS_LOLSeg not initialized). Trouble is that we initialize DOS variables in case of DOS programs *only*. This is rather fatal IMHO, especially in the case of List Of Lists, which is a pretty important structure with lots of information that some Win 3.x programs might rely on. Thus DOS stuff should be reorganized somehow. Any suggestions ? IMHO probably winedos should get loaded as soon as DOS3Call() gets called even once. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 24, 2001

Re: fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

by Laurent Pinchart

Sorry for all of those who were looking forward for MB_TASKMODAL support, but I fixed my problem without having to implement that. The problem came from SetWindowPos(a)dlls/x11drv/winpos.c which didn't react properly to the SWP_NOACTIVATE flag. I attached a patch to this e-mail, comments are welcome. Laurent Pinchart

Dec. 24, 2001

Re: Wine Tasklist

by Francois Gouget

On Sun, 23 Dec 2001, Robert Baruch wrote: > Hi Francois, > > What about a list of general, unclassified things that need to be fixed, > basically keeping track of all the FIXME stuff? Such as (just for example, > of course :) setting virtual memory protections on executable images when > loaded. Yes, I guess we could have a third list containing fully-diagnosed bugs. The virtual memory protection issues could go there as well as maybe other items picked-up from wine-dev. The task could even point straight to the wine-dev discussion when appropriate to reduce the amount of work necessary to enter the bug. But we must be careful not to have too many task lists. One of the ideas is to focus attention on a relatively limited set of issues and if we just have a ton of tasklists that just cover all the bugs in bugzilla then they are not very useful. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Dec. 24, 2001

[Shrinker] Another landmine

by Robert Baruch

More stepping through the code, comparing Windbg to gdb, and I found another landmine. Shrinker gets the address of the NTDLL procedure LdrAccessResource, and looks for this code: FF74XXXX push [esp+X] E8XXXXXXXX call .... Instead, it finds an unimplemented procedure in Wine. So now I will look at LdrAccessResource (and friends) to see what's involved in implementing it, whatever it is. --Rob

Dec. 24, 2001

Re: fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

by Laurent Pinchart

I found a way to store some information in the window extra memory, and I now disable all the root windows of the current thread, but the message box still pops up for a second and then disappears. What could I try next ? Laurent Pinchart

Dec. 24, 2001

Re: Wine Tasklist

by Robert Baruch

Hi Francois, What about a list of general, unclassified things that need to be fixed, basically keeping track of all the FIXME stuff? Such as (just for example, of course :) setting virtual memory protections on executable images when loaded. --Rob

Dec. 24, 2001

Re: fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

by Laurent Pinchart

> This has been discussed before, most recently on wine-users, I > think... Are you running in managed mode? Then try this patch: > http://www.winehq.com/hypermail/wine-patches/2001/11/0126.html > > (Hey, Alexandre, is there a reason you haven't applied that yet, anyway?) I applied the patch succesfuly, but it doesn't help, either in managed or non-managed mode. The message box still pops up for a second and then disappears. I was wondering why message boxes are allowed to be APPLMODAL, TASKMODAL and SYSTEMMODAL, while other dialog boxes aren't. I feel it would have been simpler and cleaner to implement TASK/SYSTEM/APPL modality in windows/dialog.c instead of windows/msgbox.c, as dialog.c already disables the root ancestor of the dialog parent. I still haven't found out how to increase the extra memory of the MSGBOX class. Any info will be appreciated. Laurent Pinchart

Dec. 24, 2001

Wine Tasklist

by Francois Gouget

Hi, I would like to establish two Wine tasklists in Wine's bugzilla. * the first list would contain the items listed in my previous 'Call for Volunteers' emails. This would make it easier to keep track of these tasks. * the second list would contain more complex and general items like 'DCOM support'. For the first list, refer to my previous 'Call for Volunteers' emails. I think I will start it from there and we can update it after that. For the second list, I included a first draft below. I would like your comments on it, especially with regard to the status of some of these items, and suggestions if you see missing items. I know we already have a 'Wine 1.0' and 'Wine 1.x' tasklists'. There may be some overlap but I think the intent is different. * My intent with these two new tasklists is to advertise what we want to do to potential contributors. So the idea is to then add a page to the WineHQ web site that would list all the ways one can contribute to Wine: maintaining an application entry in the Application Database, helping users on the mailing lists, buying Wine based applications, and of course contributing code. And for this last item, these lists would provide a good starting point, both for developpers with little time and for developpers who want to invest themselves more heavily in Wine. * Then unlike the 1.0 and 1.x tasklists, these new lists would not be tied to a specific Wine release or date. I hope to produce a draft of this web page in the coming days. In the meantime let me know if I missed things in the list below. For each item I tried to indicate the rationale behind the task, and point to the corresponding bugzilla report if there is one. Wine tasklist ------------- * Make the registry loadable on demand - when working from a Windows partition the registry is big. - this causes wineserver to allocate a lot of memory - this has a big impact on startup times - a 'database' based registry may be more robust * Rasterizer - to paint into a DIB we have to copy the IB contents into an X bitmap, call X functions to modify the bitmap, often only to have to copy the result back to the DIB when the application tries to read it. Imagine it for eash SetPixel operation! - a rasterizer would be able to perform these operations directly on the DIB and thus provide better performance, at least in some situations. - it would also provide better color accuracy: the X server often only supports a few bit depths so that if the application works on a 24bpp DIB but the X server is in 16bpp mode, 3bits are lost per color component. * Cross process messages - used by many applications - needed for DDE (bug 95) - Alexandre, you worked on this recently, right? Is this working now? - See bug 93 * Out of proc COM - Needed for Installshield 6 - Would probably help with at least some functionality of a host of other applications * DCOM support - same as out of proc COM but network transparent - should be interoperable with Microsoft's implementation so that, in a company setting, processes running in Wine can connect to servers running on whatever Windows server are present. * Better multi-user support - how to get per-user registry files - how much per-user setup is really necessary? (create a '.wine' directory, create per user registry files, who does that, ...) - is it possible to share a single read-only 'c:\' drive? What do we need to get parity with an NT environment? - is it possible to share a read-only 'system.reg' file? - what is the impact of a 'load on demand' registry? Could we share a single registry server? - what would be necessary to share a single - there are many options that need to be investigated and documented... * UNC path handling - for drives '\\.\e:', devices - for network paths - there's been a patch related to this recently but I believe it does not cover all cases - integrate with Samba to handle network UNC paths - provide a way to mount/unmount drives at runtime, especially network drives. One should be able to disable this in the config file (for security reasons). - Support for 'persistent' mounts... will require modifying the way w specify which drives are mounted where. - provide an applet to mount/unmount drives while Wine is running. * Native Alsa support - Alsa is the future of sound in Linux: should be integrated in 2.5 - Could it offer capabilities that OSS does not offer? - Other platforms may not support Alsa any time soon so we must keep OSS too - Anti-rational: Alsa includes an OSS compatibilty mode that seems to work pretty well - see bug 324 * aRts support - On an OSS system when the aRts daemon is running Wine cannot access the sound device - aRts makes it possible to send the sound other the network. This kind of functionality is great for a thin-client environments: setup a server and have the sound sent to each terminal ("You've got mail" ;-). Supporting aRts in Wine would let it integrate perfectly in such an environment. - this could either be native support, or making Wine compatible with artsdsp. The current problem may be related to the -Bsymbolic link option. - see bug 325 * ESounD support - Same thing as for aRts - see bug 326 - Making Wine compatible with artsdsp may also make it compatible with esddsp (and vice versa). * Write a regedit replacement - used by some installers to create registry keys - we can limit the functionality to just that although since Wine has a registry we should probably provide a tool to browse/edit it. - will be more important once we have a database based registry for the load on demand functionality * Write a regsvr32 replacement - used by some installers * Fix the desktop mode - If a process running in desktop mode start another, the new process creates a new desktop - the background is black - one cannot start a specific application in desktop mode. You have to modify the config file. * Compile with STRICT on - better type safety - reveales all the 16/32bits hacks - see bug 90 * Dll separation - to allow us to swap native dlls in and out with less problems - to make the dlls more independent of each other and make it easier to treat them as independent projects - see bug 96 * HEAP_strdup* removal - Alexandre said some day that they will go away - Part of the dll separation? * Move the winsock16 code to wsock32 - winsock16 is more related to wsock32 than to ws2_32 - ws2_32 is the new API. This would leave us with a clean 32bit implementation of the new API that is not encumbered with 16bit hacks. * Check .spec file completeness - we need complete spec file to know where we stand - determine what's new in WinMe, Win2000, WinXP - check that the ordinals/absence of ordinals is correct - I have scripts that can be used as a starting point * Winedbg expression handling - when modifying the contents of a variable there can be mixups where the debugger modifies its own memory instead of that of the debugged process. * Winedbg g++ 3.0 support - The debugging format and the ABI changed in g++ 3.0 and winedbg does not support the new ABI. - This prevents debugging of C++ Winelib applications - This is especially troublesome for MFC Winelib applications - Eric, you worked on this recently, do you know if this is a thing of the past or is it possible that there are still problems (I did not test recently) * Better memory allocator - some memory allocation/release patterns cause the current allocator to be relatively inefficient - see threads on wine-dev (Ove/Gav hit this problem) * Winelib richedit support - one of the things needed by MFC - the API seems at least partly supported, but the headers are very incomplete - see bug 330 * Visual C++ project support - make it possible to generate a Winelib project from a Visual C++ project - this should be done by extending winemaker - see bug 61 * Specify how to compile and package the MFC - many applications use the MFC. To make Winelib useful it is necessary to make it easier to compile the MFC and MFC-based applications - winemaker has some support for the MFC. But it makes suppositions about how the MFC were compiled (library names, etc.). So it is necessary to document how to get something that works well - see bug 110 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

Dec. 24, 2001

Re: fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

by Ove Kaaven

On Mon, 24 Dec 2001, Laurent Pinchart wrote: > The installer displays at some point a task modal message box, but for some > reason the box disapears almost instantly, and I'm stuck with a focused > installshield screen on which I can't do anything as the task modal msgbox is > invisible and unfocused. This has been discussed before, most recently on wine-users, I think... Are you running in managed mode? Then try this patch: http://www.winehq.com/hypermail/wine-patches/2001/11/0126.html (Hey, Alexandre, is there a reason you haven't applied that yet, anyway?)

Dec. 24, 2001

Re: License debate conclusion

by James Tabor

Dan Kegel wrote: > > Roger Fujii wrote: > > I'm sad. The LGPL seems like the clearest hope we have of protecting > Wine against companies that want to take it and never contribute code > back. Its protection might not be airtight -- but it would clearly > communicate the spirit. And my impresson was that the majority of > Wine developers agree. > > > - Dan Hum????????? Like the ODIN Project! James

Dec. 23, 2001

Re: License debate conclusion

by Dan Kegel

James wrote: > > Dan Kegel wrote: > > I'm sad. The LGPL seems like the clearest hope we have of protecting > > Wine against companies that want to take it and never contribute code > > back. Its protection might not be airtight -- but it would clearly > > communicate the spirit. And my impresson was that the majority of > > Wine developers agree. > > Like the ODIN Project! Good point. The ODIN project's license is at http://odin.netlabs.org/License.phtml There was some talk of sharing code between Wine and Odin in 1999; see http://www.winehq.com/News/1999-50.html#0 We might want to update http://www.winehq.com/others.html to reflect the current status and license of the Odin project. I'm not quite sure whether the Odin license is compatible with the LGPL. It looks fairly GPL compatible, but I didn't look hard. - Dan

Dec. 23, 2001

Re: Windows screensaver.

by David Elliott

On 2001.12.23 11:10 Gleb Natapov wrote: > Hello all, > > Perhaps this was asked before, but I didn't find the answer. > Is it possible to run windows screensaver in linux using wine? > If not, how hard it will be to write support for this? > Well, there are a few issues: 1. Loading wine takes forever on my box (although this will be fixed in about a week when I get a dual-athlon setup). Not an ideal solution to the speed problem in my mind.. but works for me. 2. You can already run most screensavers using: wine using wine /path/to/screensaver.scr /s An .scr file is essentially just an .exe that has been renamed. The /s switch tells the screensaver to actually run as a screensaver. Without it it will open up the configuration properties for the screensaver. 3. You'll notice that when you run the screensaver like this that it will appear on top of all other windows and when you move the mouse it will go away. That is, the screensaver itself takes care of putting itself above all other windows and will dismiss itself when it gets an event such as mouse move or button press or whatever. XScreenSaver doesn't work this way. You'll notice that most of the commandlines in your .xscreensaver file have the -root option. That means draw in the root window which if you run that by itself (i.e. outside of xscreensaver) you'll notice that it will in fact draw to the root window (i.e. your desktop background). Also, moving the mouse around does nothing... the program simply draws stuff on the screen and absolutely does not handle dismissing itself like a win screensaver. XScreenSaver creates a virtual root window on top of everything which it then runs the screensaver program in. That way the screensaver program still thinks it is just drawing in the root window, but in reality it is drawing on top of everything. XScreensaver also takes care of dismissing the screensaver when you move the mouse. I believe it does this by sending it a signal of some sort, although I am not entirely sure. You really ought to read its documentation to get all the specifics on this. However, you /can/ add a line that runs wine to run the screensaver in your .xscreensaver file. In fact, I just tried this. If you run in demo mode you get the expected behavior, it won't go away until you click a button. If you set it as your screensaver and do a normal blank (i.e. not lock) then it'll go away when you move the mouse. However, if you do a lock screen it'll clear the screen to black when you move the mouse, ask you for your password (which for some reason it didn't accept the first time, but maybe I just typed it wrong). Anyway, once you type a valid password you are still looking at the screensaver until you move the mouse again. So basically it already does mostly work. One way to decrease the startup time would be to start the wineserver in persistent mode before hand. Then the first time you load the screensaver (or some other windows app) it'll take a while, this is because the first client to connect has to set some stuff up. However, after that the wineserver is running and ready to go so it doesn't take very long for the screensaver to start up. (I just checked this, and that is what happens). One thing you could maybe try to do to decrease this is make a very lightweight wine configuration in a different directory. You can use the WINEPREFIX environment variable to do this. With a bit of configuration you could have a wineserver running permanently listening on a socket in $WINEPREFIX instead of in the usual ~/.wine directory. Also that way when you run windows apps it doesn't affect your other wineserver. As far as fixing the behavior goes, I have a few ideas. Wine supports a "Desktop" mode where a desktop window is created and all wine drawing is done to that window. You could maybe change wine a bit to allow wine to draw into an already created desktop window (e.g. draw into the root window). That might make things behave a slight bit better. In fact, doing that alone might fix everything. And I also think that doing that should be simple (and maybe there is already a way to do this). Hope that helps you to figure it out! -Dave

Dec. 23, 2001

Re: License debate conclusion

by Francois Gouget

On Sun, 23 Dec 2001, James A Sutherland wrote: [...] > > I'm sad. The LGPL seems like the clearest hope we have of protecting > > Wine against companies that want to take it and never contribute code > > back. > > Whether or not Wine *needs* "protection" from this is another question. If I > have a super improved version of Wine and don't distribute it, no harm is > done to anyone. IMO, the "danger" of someone creating a proprietary Wine is a > strawman - there's already a set of proprietary Win32 implementations out > there from some outfit in Redmond, and it hasn't killed Wine development > AFAICS :-) Well, this outfit probably does not use any code from Wine. But I am pretty sure that if this line of products were taken out of the streets tomorrow for good so that it were impossible to buy any computer with this product or to buy the product itself in stores, well if that unlikely event were to take place I am sure that we would see a lot of companies (both users and vendors) very eager to contribute to Wine to ensure that there is still a platform to run their legacy applications on ;-) I am sure that we would see Wine and Winelib make big progress, at least for couple of years... So in that way they are harming the development of Wine :-) Ok it's a bit far fetched, but still, their is some truth in the above if you think about it. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Dec. 23, 2001

Re: fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

by Dan Kegel

Laurent Pinchart wrote: > > When trying to install The Longest Journey (an adventure game), I ran into a > problem with modal message boxes. > > The installer displays at some point a task modal message box, but for some > reason the box disapears almost instantly, and I'm stuck with a focused > installshield screen on which I can't do anything as the task modal msgbox is > invisible and unfocused. That sounds like a problem I have with the history window of Microsoft Sourcesafe with a Wine build from CVS from about two months ago (I haven't updated since then). Looking forward to trying your upcoming fix. - Dan

Dec. 23, 2001

[Fwd: Re: License debate conclusion]

by lee

> I think it's clear that Wine cares, and should be careful not to alienate > companies like Codeweaver and Transgaming. One way to deal with Transgaming > might be to start a campaign to get people to buy Transgaming subscriptions, > or perhaps try to rummage up enough of a one-time payment to get Transgaming > to contribute their current changes back. I suspect that there's some > such arrangement they'd be happy with. I tried to do just that and got rejected ( error after submitting and didn't want to try 'again' until they contact me ) by the online payment system for some odd reason....I wonder how many others have experineced this ( I checked my input twice and had all *'s filled out )........granted it could be isolated in that I made some minor goof on form..-we'll see. just a fyi in case it wasnt' me.. lee -===

Dec. 23, 2001

Re: License debate conclusion

by dfd

> I think it's clear that Wine cares, and should be careful not to alienate > companies like Codeweaver and Transgaming. One way to deal with Transgaming > might be to start a campaign to get people to buy Transgaming subscriptions, > or perhaps try to rummage up enough of a one-time payment to get Transgaming > to contribute their current changes back. I suspect that there's some > such arrangement they'd be happy with. I tried to do just that and got rejected by the online payment system for some odd reason....I wonder how many others have experineced this and thus........ just a fyi lee -===

Dec. 23, 2001

Re: License debate conclusion

by Dan Kegel

James A Sutherland wrote: > > > before this is concluded, I will add one thing just for the sake > > > of archival (in case this comes up again). If ALL of wine were strictly > > > LGPLed, basically, *all* propriatary extensions could no longer be > > > included. Why? Because the output of winebuild will be LGPLed, thus > > > no propriatary programs could use its output in creating a shared > > > library. winebuild is like bison in this case, and the output of > > > bison has a special exemption so that you can use it in something > > > other than *GPLed programs. > > > > Agreed, programs that generate code should specify what license the > > generated code is under. > > "Agreed"? My view is that compilers (or any "program that generates code") > should have *NO* say whatsoever in licensing of the output. Or do you want to > see VC++ prohibiting the development of software competing with MS offerings? Because generated code could be considered a derived work of the compiler, programs that generate code need to expressly disclaim rights to the generated code to avoid restricting the use of that code. If the compiler vendor fails to expressly spell out the licensing of the generated code, users of the compiler are left in an unclear legal position. - Dan

Dec. 23, 2001

Re: License debate conclusion

by Daniel Sabo

On Sun, 23 Dec 2001 09:10:45 -0800, James A Sutherland wrote: > On Sunday 23 December 2001 4:09 pm, Dan Kegel wrote: >> Roger Fujii wrote: >> > Alexandre Julliard <julliard(a)winehq.com> wrote: [snip.] > "Agreed"? My view is that compilers (or any "program that generates > code") should have *NO* say whatsoever in licensing of the output. Or do > you want to see VC++ prohibiting the development of software competing > with MS offerings? [snip] In fact, the VC++ license says that you may not use it to develop software not intended for the Microsoft Windows platform.

Dec. 23, 2001

CVS server

by Dimitrie O. Paun

It looks like we're running an old version of CVS on the server, as it complains it does not understand #cvs up -C is it possible to upgrade it? That would be a good idea irrespective of the -C problem, as the new versions fixed quite a few (nasty) bugs. -- Dimi.

Dec. 23, 2001

Re: License debate conclusion

by James A Sutherland

On Sunday 23 December 2001 4:09 pm, Dan Kegel wrote: > Roger Fujii wrote: > > Alexandre Julliard <julliard(a)winehq.com> wrote: > > > My conclusion is that there clearly isn't enough support in the > > > developers community to justify changing the license. So I'm not going > > > to proceed with any change, either now or in the foreseeable future. > > > > hurrah. > > I'm sad. The LGPL seems like the clearest hope we have of protecting > Wine against companies that want to take it and never contribute code > back. Whether or not Wine *needs* "protection" from this is another question. If I have a super improved version of Wine and don't distribute it, no harm is done to anyone. IMO, the "danger" of someone creating a proprietary Wine is a strawman - there's already a set of proprietary Win32 implementations out there from some outfit in Redmond, and it hasn't killed Wine development AFAICS :-) > Its protection might not be airtight -- but it would clearly > communicate the spirit. And my impresson was that the majority of > Wine developers agree. > > > before this is concluded, I will add one thing just for the sake > > of archival (in case this comes up again). If ALL of wine were strictly > > LGPLed, basically, *all* propriatary extensions could no longer be > > included. Why? Because the output of winebuild will be LGPLed, thus > > no propriatary programs could use its output in creating a shared > > library. winebuild is like bison in this case, and the output of > > bison has a special exemption so that you can use it in something > > other than *GPLed programs. > > Agreed, programs that generate code should specify what license the > generated code is under. "Agreed"? My view is that compilers (or any "program that generates code") should have *NO* say whatsoever in licensing of the output. Or do you want to see VC++ prohibiting the development of software competing with MS offerings? > > This inadvertant problem is precisely why *GPLed stuff has to be > > scrutinized carefully if you care about commercial relationships (most > > *GPL projects don't care) and is why commerical interests are wary of > > projects with a *GPL license. > > I think it's clear that Wine cares, and should be careful not to alienate > companies like Codeweaver and Transgaming. One way to deal with > Transgaming might be to start a campaign to get people to buy Transgaming > subscriptions, or perhaps try to rummage up enough of a one-time payment to > get Transgaming to contribute their current changes back. I suspect that > there's some such arrangement they'd be happy with. IMO, the current license is working just fine. Wine is getting developed and used by plenty of people: as was pointed out earlier, using a more restrictive license would have harmed Wine, rather than helping. (I'm reminded of the proverb about the monkey with a jar of sweets here: in situations like this, if you force an "all or nothing" choice on people, they will choose the latter...) James.

Dec. 23, 2001

Windows screensaver.

by gleb＠nbase.co.il

Hello all, Perhaps this was asked before, but I didn't find the answer. Is it possible to run windows screensaver in linux using wine? If not, how hard it will be to write support for this? Thanks, -- Gleb.

Dec. 23, 2001

Re: License debate conclusion

by Dan Kegel

Roger Fujii wrote: > > Alexandre Julliard <julliard(a)winehq.com> wrote: > > > > My conclusion is that there clearly isn't enough support in the > > developers community to justify changing the license. So I'm not going > > to proceed with any change, either now or in the foreseeable future. > > hurrah. I'm sad. The LGPL seems like the clearest hope we have of protecting Wine against companies that want to take it and never contribute code back. Its protection might not be airtight -- but it would clearly communicate the spirit. And my impresson was that the majority of Wine developers agree. > before this is concluded, I will add one thing just for the sake > of archival (in case this comes up again). If ALL of wine were strictly > LGPLed, basically, *all* propriatary extensions could no longer be > included. Why? Because the output of winebuild will be LGPLed, thus > no propriatary programs could use its output in creating a shared > library. winebuild is like bison in this case, and the output of > bison has a special exemption so that you can use it in something > other than *GPLed programs. Agreed, programs that generate code should specify what license the generated code is under. > This inadvertant problem is precisely why *GPLed stuff has to be scrutinized > carefully if you care about commercial relationships (most *GPL projects don't > care) and is why commerical interests are wary of projects with a *GPL license. I think it's clear that Wine cares, and should be careful not to alienate companies like Codeweaver and Transgaming. One way to deal with Transgaming might be to start a campaign to get people to buy Transgaming subscriptions, or perhaps try to rummage up enough of a one-time payment to get Transgaming to contribute their current changes back. I suspect that there's some such arrangement they'd be happy with. - Dan

Dec. 23, 2001

Re: fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

by Laurent Pinchart

> That sounds like a problem I have with the history window > of Microsoft Sourcesafe with a Wine build from CVS from about > two months ago (I haven't updated since then). > > Looking forward to trying your upcoming fix. There will be no upcoming fix until I get some help... I'm willing to write support for MB_TASKMODAL, but have no idea about how to do so. It seems that I need to EnumThreadWindows, get the state enable state of all windows, disable them, and restore their enable state when the dialog box is closed. If I'm right, my problem is how/where to store the enable state of all the thread windows. I've been thinking about the window extra data, but I haven't been able to find where the MSGBOX class is registered so that I can allocate more space for extra data (cbWndExtra). Any help will be appreciated. Laurent Pinchart

Dec. 23, 2001

Re: [PATCH] forward tab notification to the parent

by Andreas Mohr

On Sat, Dec 22, 2001 at 02:31:56PM +0000, Gerard Patel wrote: > The following patch : > ChangeSet ID: 1008622332606314052827656 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine2. 01/12/17 15:52:12 > > Modified files: > dlls/comctl32 : tab.c > > Pass on all unhandeled messages to the owner. > > leads to bad regressions with some apps. > > The attached patch has the same positive effect on hh.exe > but without the regressions. Confirmed: That patch had horrible effects on desk.cpl. Applying your patch fixed it. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 23, 2001