wine-devel February 2002

wine-devel@winehq.org

142 participants
296 discussions

Re: Notepad2. Command line processing
by lawson_whitney＠juno.com 20 Feb '02

20 Feb '02

On Fri, 15 Feb 2002, Andriy Palamarchuk wrote: > I *think* this patch does not depend on my previous > patch. > > Changelog: > - implemented parsing of file name, passed in command > line, loading new file on startup. This fixes bug 407 > Did you notice in testing this patch that notepad can not save a file? Never mind bug 407, that is the Real Bug that renders notepad unusable. :-). I guess this is not an urgent bug, I can use joe, jed, vi (elvis, vim) or emacs if I need to change a file. Lawson Illigitimati non carborundum.

4 3

Re: License change vote results
by Roger Fujii 20 Feb '02

20 Feb '02

Alexandre Julliard <julliard(a)winehq.com> wrote: > The obvious result of this vote is that my previous conclusion was > wrong: there is clearly widespread support in the community for a > copyleft-style license. With 2 out of 3 contributors in favor of the > switch, and less than 15% opposed to it, it's clear that we are going > to proceed with the change. As a curiosity, what % of the voters are affiliated with codeweavers? I realize that they are a significant contributer, but as you are using the word "community", it's fair to ask a) how big that number is in total b) if there are large components in that number, they should be at least quantified. -r

8 7

MIDL replacement?
by Phillip Schmitz 20 Feb '02

20 Feb '02

Some time ago there was talk of using an (msrpc/com) idl compiler and idl files to replace some of the complexity of the current COM implementation details (I imagine the main advantage would be that winelib programs might be able to use COM stuff without having to generate stubs etc using MIDL). Rather than starting from scratch people recommended finding an existing (corba) idl compiler and hacking that. Has anyone taken up the challenge? I had a look at the freedce idl compiler but I can't get it to compile. Not that I want to invite another round of "my license is better than your license" but should this be distributed independently of wine so as to avoid license problems or what could one base it on if distributed with wine (if wine was rewritten to depend on its availability this would make things tricky... ) Also, while on the topic of MIDL it seems that the emitted code contains marshaling hints/info in special strings - does wine currently understand these? (undocumented of course but not that messy - people writing their own custom DCOM-over-other-transports stuff managed to work them out quite quickly - I'm sure working with people from Microsoft Research helped though :) Would it need to be a drop-in replacement for MIDL? I suppose not but I'm not sure how much easier that would be (I know com-idl is a moving target with COM+ and new attributes etc but plain COM should be sufficient for most). Anyway - this is the result of a few days research and may all be in vain - those with more experience with COM and its implementation in wine should (if required) shoot me down now before I continue wasting my time. Phillip Trainee wine-devel lurker who marvels at the endurance of people using/implementing COM in C. PS I don't know if it is worthwhile starting a separate effort to make a "free" MIDL replacement regardless - what do people writing windows code with mingw etc do if they want to use COM?

2 1

cd programs && make install
by lawson_whitney＠juno.com 20 Feb '02

20 Feb '02

Good day! Maybe this is a local misconfiguration (only I doubt it) or maybe I am going about it wrong,...maybe I deleted winetest.pm myself and can't remember... cd `dirname winetest/__install__` && make install make[1]: Entering directory `/oof/Wine-20020122/programs/winetest' [ -d /usr/local/bin ] || mkdir -p /usr/local/bin /usr/bin/install -c winetest.so /usr/local/bin/winetest.so cd /usr/local/bin && rm -f winetest && ln -s wine winetest [ -d /usr/local/lib ] || mkdir -p /usr/local/lib /usr/bin/install -c -m 644 wine.pm /usr/local/lib/wine.pm /usr/bin/install: wine.pm: No such file or directory make[1]: *** [install] Error 1 make[1]: Leaving directory `/oof/Wine-20020122/programs/winetest' make: *** [winetest/__install__] Error 2 Lawson "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

2 1

RMS, Univerial Themes, Slashdot, and Wine
by Tim R. 20 Feb '02

20 Feb '02

Hi, This post, http://mail.gnome.org/archives/foundation-list/2002-February/msg00015.html to some GNOME mailing list got /.ed recently. Quoting from the post: >It might also be useful to organize a specific joint project, >something that would improve the coherence of a GNU/Linux system >which uses parts of both GNOME and KDE. The idea that occurred to me >was to work on unifying theme definitions, so that a user can define >a theme just once and have it work with both GNOME and KDE. Perhaps >others will have a better suggestion. I would love to see something like this happen. However, IMHO, I think something like this should be more than just KDE and GNOME. I would like to see something like that as a more or less Linux (and BSD, etc), or X11 standard. It seems to me that Wine could benifit from something like this. Basicly, Wine is just a Unix/X11 toolkit that happens to have the same API as MS Windows and includes a binary loader right? Or am I completely off base here? Anyway, GNOME programs tend to look and feel like GNOME programs, KDE programs tend to look and feel like KDE programs, and Wine programs tend to look and feel like Windows programs. So could something like this work for Wine? Could Wine programs inherit their look and feel from some kind of universal theme? That would surely help the Windows programs integrate into the X desktop. So I guess I'm asking, would this work for Wine, and if so, is anyone interested in doing it? If the first answer is yes but the second is no, could anyone provide me with some pointers for getting involved with doing some a project myself? (Both the work on Wine, and on GNOME/Gtk/KDE/Qt/etc.) Also some of the replies to RMS's post suggested this was an itch none of the GNOME people felt like scratching, because none of them used KDE programs. I thought perhaps the Wine people would feel more like scratching this itch, because most of you probably use Wine programs along side of atleast either KDE or GNOME applications, if not both. Sorry if this has been a bit off topic, or if I don't really know what I'm talking about. --Tim Ringenbach

1 0

Bye
by Gerard Patel 20 Feb '02

20 Feb '02

Ring down the curtains, the farce is over ;-) I will unsubscribe from wine lists in a few days. If anyone of the contributors has a problem with the few lines of code I wrote for Wine, they should not hesitate to send me a mail in my personal inbox, I'll try to understand what I was trying to do and if I succeed I'll explain :-) And if among the seven who voted against the changes there are enough people aventurous (I did not participate to the 'vote'), I'd be interested to hear from them and discuss a contribution to a new project under a x11 like license. As wine-license seems to be a continuation of the gpl/bsd flamewar :-//, I'd prefer to talk about a x11 project elsewhere... Thanks to all on this list who helped me. Good luck to the Wine guys for their 1.0 version. Gerard PS : And ah, well, as a parting note for Alexandre Julliard : there is a problem with your patch made on Revision 1.22 / (download) - [select for diffs] , Fri Sep 14 00:24:40 2001 UTC (5 months ago) by julliard Branch: MAIN Changes since 1.21: +8 -13 lines Diff to previous 1.21 Make sure that HWND comparisons are always done with full 32-bit handles. You included this (hardly related) change in dlls/x11drv/window.c, line 524: while (prev && !(GetWindowLongW( prev, GWL_STYLE ) & WS_VISIBLE)) prev = GetWindow( prev, GW_HWNDPREV ); This is triggering a regression in one of my test apps, webferret (www.webferret.com). The option window has its tabs covering each other. I can work around with this patch : --- winpos.c.orig Tue Dec 18 02:27:43 2001 +++ winpos.c Thu Jan 10 18:08:16 2002 @@ -880,7 +880,7 @@ if (get_whole_window(wndPtr)) /* don't do anything if X window not created yet */ { Display *display = thread_display(); - + int zorder = !(winpos->flags & SWP_NOZORDER); if (!(winpos->flags & SWP_SHOWWINDOW) && (winpos->flags & SWP_HIDEWINDOW)) { /* clear the update region */ @@ -895,10 +895,11 @@ TRACE( "unmapping zero size win %x\n", winpos->hwnd ); TSXUnmapWindow( display, get_whole_window(wndPtr) ); } + else if (winpos->flags & SWP_SHOWWINDOW) zorder = TRUE; wine_tsx11_lock(); if (bChangePos) - X11DRV_sync_whole_window_position( display, wndPtr, !(winpos->flags & SWP_NOZORDER) ); + X11DRV_sync_whole_window_position( display, wndPtr, zorder); else { struct x11drv_win_data *data = wndPtr->pDriverData;ü as far as I can understand your code and what the app is doing, your new code updates the ordering of the X window but there is a case missing when child windows are shown using for instance ShowWindow. But of course you'll have a better patch :-)

4 3

RE: License change vote results
by Patrik Stridvall 19 Feb '02

19 Feb '02

> Here is the summary of the votes I received in answer to the request > to switch to a copyleft-style license: > > Agree Disagree Indifferent > > All votes: 76 (70%) 15 (14%) 17 (16%) > > Contributors: 39 (66%) 7 (12%) 13 (22%) > > Contrib. weighted: 59 (64%) 13 (14%) 20 (22%) > > The first line counts all the votes I received. The second line counts > the votes of all people/companies who contributed some code to the > project. The last line counts all contributors again but with each > being given 1, 2, or 3 votes depending on the importance of his > contributions (this evaluation is obviously a bit subjective, but I > think the overall trend is clear). Intresting to note is that contributors that disagree are on average ranked higher (almost 2) but the contributors that agree are ranked lower (about 1.5). This means that people that has more effort to protect are less willing to do so. Very intresting. The only reasonably conclusion for this that I can think of is that people with more to protect have thought more on the drawbacks on copyleft licenses (especially the LGPL) than people with less to protect. > The obvious result of this vote is that my previous conclusion was > wrong: there is clearly widespread support in the community for a > copyleft-style license. For some copyleft-style license perhaps. I'm not entirely against copyleft-style licenses either even if I voted disagree. However don't be so sure that all that voted for it really wants a license like the LGPL that prevent (at least according to your interpretation) using for example proprietary libraries to implement some functionalility. Or for that matter prevents Transgaming to add copy protection that they can't release openly because of a NDA. Calling proprietary libraries is something that I have been trying to explain is not just something "evil" companies out to earn a profit do, but also quite reasonably people just trying to help themselves or some friends to run applications under Wine. Is it really morally or ethically right to prevent that? I also asked how that is compatible with freedom 3 of the Free Software defintion: "The freedom to improve the program, and release your improvements to the public, so that the whole community benefits." > With 2 out of 3 contributors in favor of the > switch, and less than 15% opposed to it, it's clear that we are going > to proceed with the change. > > We now have to decide the implementation details, like the exact > license used, whether to require copyright assignments, etc. I think the first thing me need to do is to properly discuss what we want to accieve with the license and even more importantly what we think is acceptable to sacrifice. Then we must vote on what is important to prevent and what is important to avoid preventing. Especially we must vote on for example whether preventing Transgamings business model is reasonable and similar specific cases. After we have done that we can see if any existing license fits something that the majority agrees on or whether it is appropriete design a license of our own that does. I'm not at all sure that the LGPL is a good alternative at least not without properly clarify what paragraph 2d means as well as making certain that the majority of contributors really wants a license that means whatever paragraph 2d means. Another thing. It is not nessary to have the whole of wine under the same license. For example the header files (wine/include/*.h) might be appropriate to have under the current license or even under public domain to facillitate sharing with other projects. > My > suggestion is that we create a separate mailing list to discuss that, > to avoid drowning wine-devel under yet another license flame war. Agreed. I have subscribed to it and are ready to continue the debate there.

3 2

languages for wine tests
by Andriy Palamarchuk 19 Feb '02

19 Feb '02

Are we going to use other languages than Perl and C for tests creation? I created a small shell test script to test other shell scripts, which are part of Wine (namely regapi scripts). It is easy to rewrite the test script in Perl. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com

2 1

RE: License change vote results
by Patrik Stridvall 19 Feb '02

19 Feb '02

> > For some copyleft-style license perhaps. I'm not entirely against > > copyleft-style licenses either even if I voted disagree. > > > However don't be so sure that all that voted for it really wants > > a license like the LGPL that prevent (at least according to your > > interpretation) using for example proprietary libraries to > > implement some functionalility. > > This is a spurious argument. You tell us that you voted that you > disagree, then ask us to not assume that those who voted in > favor agree > with the LGPL -- but provide no evidence to the contrary? The evidence is that the question didn't ask the whether the voters agreed with the LGPL it asked whether they thought copyleft was good. No bait and switch tactics thank you very much. Copyleft doesn't imply that everything it uses or in the case of GPL even what uses it should be copyleft only whatever is derived from it. A proprietary library that is called from a copylefted application is obviously not derived from it. Yet the LGPL under some interpretations prevent this. So the LGPL goes further than the definition of copyleft so the question whether supporters of copyleft support the LGPL is quite valid. > In any case, the precise license chosen is an issue yet to be > hashed out; > and it seems the wine-license mailing list is the place to do that. True. But I don't think all intrested have signed up yet. I will continue cross-posting a while yet. > > Or for that matter prevents Transgaming to add copy > protection that they > > can't release openly because of a NDA. > > I'm afraid Transgaming gets no sympathy from me if a future > Wine license > prevents them from working on copy protection functionality. > The DMCA is > fundamentally broken; technological mechanisms to prevent copying are > fundamentally broken because there can be no protection for fair use > rights; and any company that uses such copy protection > mechanisms should > be thoroughly boycotted. While I don't condemn TransGaming > for trying to > support copy-protection mechanisms in Wine -- corporations are by > definition amoral -- The DMCA might be (and is IMHO) fundamently broken but NDA:s are not. The copy protection that Transgaming has implemented is just an exemple of things that might come under a NDA. I can imagine 3D accelerators and a lot of other things that might fall under NDA:s. Note that some NDA might only be temporary before a product is released. Surely it would be nice to have Wine working on the release day. > I also won't shed any tears if this particular > business model falls by the wayside. No business model can exists that requires NDA:s if disclosure of source is mandated. If it could be hidden in a external library everthing would be OK, but alas the LGPL doesn't allow that under Alexandre's interpretation.

2 1

Re:GetStdHandle Problem
by Ignasi Villagrasa 19 Feb '02

19 Feb '02

Here is the .spec I'm using: name mcwine type win32 mode cuiexe init main I compile it using winebuild -fPIC -o mcwine.c -spec mcwine.spec It generates a mcwine.c file, that I include in my makefile. I add several wine libraries and create the executable without problems. When trying to execute, I get the following message: wine client error:(nil): sendmsg: Descriptor de fichero err¾neo (In spanish, error in file handle) If I run the program using gdb, I see the following: (gdb) r Starting program: /usr/client/mcc_gnu/cmpm/cmpmgnu /B100 /Oaaaa-1.ovl Breakpoint 1, McConsole::Inicializar (this=0x80aa528) at /usr/comun/src/mc_vis32.cpp:429 429 conhanout = GetStdHandle(STD_OUTPUT_HANDLE); 1: conhanin = 0 (gdb) n 430 conhanin = GetStdHandle(STD_INPUT_HANDLE); 1: conhanin = 0 (gdb) n 431 FlushConsoleInputBuffer(conhanin); 1: conhanin = 0 (gdb) n wine client error:(nil): sendmsg: Descriptor de fichero err¾neo Program exited with code 01. (gdb) So I know the problem comes from GetStdHandle, but I don't know why, because the program links properly, and I suppose GetStdHandle, a basic Win32 function, should work. Any hint ? Perhaps the libraries I'm linking ? Compiler/linker options ? Thanks in advance, Ignasi Villagrasa.

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2002