wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

Re: Dialog painting
by Gerard Patel 18 Sep '01

18 Sep '01

At 12:35 AM 11/09/2001 +0300, you wrote: > >I took a closer look at this. I just ripped out the interesting parts >from Speak freely in order to find a simple program exhibiting the >problems. What I ended up with was a program which does nothing >interesting except to show a simple dialg using CreateDialog(). It >still doesn't work under Wine. The source is attached. I have looked at your source. With current Wine, expose X events are retrieved from the X server when Wine has nothing else to do. These events are setting the update region. CreateWindow does not set the update region in current Wine, even if the window is visible. This is the point that matters for your problem I think. hSplash = CreateDialog (hInstance, MAKEINTRESOURCE(IDD_SPLASH), NULL, Splash_DlgProc); SetForegroundWindow(hSplash); // here the update region is nil (Wine problem !) UpdateWindow(hSplash); // --> nothing is displayed. Sleep(5000); // events are retrieved from the X server queue. printf("Removing splash.\n"); DestroyWindow(hSplash); Your code does not display anything because no message is retrieved from the message queue. After the Sleep call, WM_PAINT messages are available, but as you don't retrieve them by calling PeekMessage or something like that, nothing is shown. I don't want to say that your app code is wrong, of course. There is a problem in Wine, but I don't know what to do about it. My first thought would be to scan the X queue and retrieve the expose events as was done before the great changes of this summer, but this may be somewhat difficult to do right. I prefer to waste my time searching for other problems, because I have no doubt that Alexandre Julliard is aware of this one and it's clear that he is not finished yet with X code reorganization. Gerard

2 1

RE: dlls/advapi32/crypt.c
by Patrik Stridvall 17 Sep '01

17 Sep '01

> Vladimir Vukicevic <vladimir(a)ximian.com> writes: > > > I think that the discussion of OpenSSL vs. libgcrypt isn't really > > necessary -- there's no reason why two implementations of CryptoAPI > > can't be done, one using the gcrypt backend, one using OpenSSL. > > Granted, this is a duplication of effort, but I think there > is enough > > interest that it shouldn't be too difficult to do both. > Also, it's easy > > enough to ship two different advapi32.so's, or even create an > > intermediate cryptoapi layer that supports plugins, so that > the option > > always remains with the distributor or user whether to go with a GPL > > implementation, a BSD implementation, or even a commercial > > implementation. > > As far as the main tree is concerned, everything has to be under the > Wine license (or compatible). It's not acceptable to depend on a > library that would impose extra conditions on the Wine/Winelib > user. The problem is what constitutes extra conditions is extremly vague. If you have a Winelib application that don't for example use say any crypto functions, you really can't be said either to use or to derive a new work from a completely unused and/or unnessary library. If you do use any crypto function, well, whether that imposes any extra conditions is an extremely difficult legal issue that really can't be answered without a real court case. It might depend on whether the use is optional but it might not. That is what I have been trying to point out in my recent messages. So just saying that "I don't want any libraries that imposed extra conditions on the Wine/Winelib user" is not really a very informative answer. What you mean is (I guess): 1. No use of libraries under the GPL or other viral licenses 2. No use of commersial libraries (end user and/or developer must pay for it) Or do you mean something else? Anyway see below. > And this is not solved by having a choice between two different > sets of extra conditions. Note that you always have the choice of NOT using crypto. If Wine didn't include a working crypto implementation that would be the only choice wouldn't it? As long as it doesn't effect the performance or maintainabillity of Wine in negative way more choices are always better than less IMHO.

1 0

Monkey Island 3 install
by Johan Gill 17 Sep '01

17 Sep '01

After some testing, I've found that the installation of Curse of Monkey Island works fine if winver=win98 is specified. What made the win95 install break was this: --- /opt/cvs-commit/wine/misc/version.c 2001/07/02 19:59:49 1.43 +++ /opt/cvs-commit/wine/misc/version.c 2001/07/27 23:57:38 1.44 @@ -75,7 +75,7 @@ }, /* WIN95 */ { - 0x07005F03, + 0x07000304, 0xC0000004, { sizeof(OSVERSIONINFOA), 4, 0, 0x40003B6, If that is a correct fix, the real problem is to be found somewhere else. /Johan Gill, johane(a)lysator.liu.se

1 0

RE: dlls/advapi32/crypt.c
by Patrik Stridvall 17 Sep '01

17 Sep '01

> On Sat, 2001-09-15 at 02:12, Patrik Stridvall wrote: > > In short. GPL:ed Winelib applications is not our concern > > and we shouldn't IMHO make it one beyond making sure > > that all linking to non GPL compatible libraries is optional. > > > > GPL:ed libraries is, as said above, a different story, that > > from a legal point of view is an unresolved issue. The "answer" > > of that question regardless of what it will be, will, be very > > important since it might, unless it is too vague, define the > > boundaries of copyright in a more definite way. > > I think that the discussion of OpenSSL vs. libgcrypt isn't really > necessary -- there's no reason why two implementations of CryptoAPI > can't be done, one using the gcrypt backend, one using OpenSSL. > Granted, this is a duplication of effort, but I think there is enough > interest that it shouldn't be too difficult to do both. > Also, it's easy > enough to ship two different advapi32.so's, or even create an > intermediate cryptoapi layer that supports plugins, so that the option > always remains with the distributor or user whether to go with a GPL > implementation, a BSD implementation, or even a commercial > implementation. It is not the effort that is the real problem. The problem is that since ADVAPI32 might use libgcrypt (that is GPL:ed library) it possible to for a non-GPL:ed Winelib application to indirectly via the ADVAPI to "link" to libgrypt. This would violate the GPL:ed in some meaning. Of course the authors of the Winelib application might be entirely unaware of this fact but it is still teoretical violation. This is, of course, in some meaning absurd, but ask yourself this: What meaning have the GPL for libraries if you can just wrap a intermediate library with a GPL compatible license (like Winelib:s ADVAPI "library") around it and circumvent the GPL? Of course a distinct possibility exists that a court of law will find that the GPL (as applied to libraries) is meaningless or at least meaningless in the case of Wine. But are you willing to be the defendent in a test case? Alexandre is not. Still IMHO even in the worst case what will likely happend is that. 1. Richard Stallman (or somebody else) sends a GPL violation notice. 2. Slashdot debate the case and possibly hang us out. :-) 3. We will discuss on the list what to do and possible remove the offending code. 4. If we do not the debate on Slashdot and elsewhere will continue 5. If we still persist the chances that we will be sued is still quite small since A) The cases of winning is close to zero B) There is little or no chance to profit even regardless of this. Of course there is moral aspect of this but ask yourself this: "Is it immoral to shatter somebodies unrealistic expectations?" In short there is no legal risk at all IMHO but Alexandre has said earlier that he doesn't want code using GPL:ed libraries if not to protect himself or the Wine project, so to protect possible users of Wine if not from legal issues so from bad PR. > There's also something to be said for following Microsoft's API for > crypto back-ends, so that proprietary back-ends (i.e. those > dealing with > hardware keys, etc.) could function within the wine cryptoapi > framework. > In this case, each individual provider (RSA, DSS, etc.) would then be > implemented either in terms of gcrypt, or OpenSSL, or libcrypt, or any > other. That is probably a good idea. But you can't use libgcrypt at least not without asking the libgcrypt authors if it is OK that Wine(lib) uses libgcrypt despite the fact that it makes it possible for non-GPL:ed Winelib applications to indirectly use libgcrypt. And you better ask Alexandre whether is OK with him to include the code under such circumstances.

1 0

RE: dlls/advapi32/crypt.c
by Patrik Stridvall 17 Sep '01

17 Sep '01

> Patrik Stridvall wrote: > > > > > On another note, however, I was re-reading the CryptoAPI > > > thread and I don't > > > think that Vladimir Vukicevic's questions were really > > > answered from September > > > 3rd. > > > > Can you be a little more specific? > > > > As far using GPL:ed libraries, that is a question that > > really can't be properly answered without a real court > > case. > > I think that Vladimir's suggestion that OpenSSL could be > used as an alternative back end did not recieve sufficient > attention. He wasn't sure that that was a good approach > given the fact that it would arguably cause difficulty for > people who wanted to run GPLed apps on top of Wine+OpenSSL. Well. If we only permit linking with libraries that have GPL compatible licenses, we will seriously limit our choices. Sure I, since GPL is a dominant license, fully agree that all linking to non-GPL:ed libraries should be optional. Of course the question of what is optional is vague too. See below. Also note that this is an entirely different issue than the issues concerning GPL:ed libraries. In the case above it is 100% clear that only the distributor of the GPL:ed application can have any legal liabillities for possible violation of the GPL. It is not out immediate concern. Beside since they, because of the GPL, must have the source code they can always disable things like crypto that might not have a 100% GPL compatible Winelib implementation. In short. GPL:ed Winelib applications is not our concern and we shouldn't IMHO make it one beyond making sure that all linking to non GPL compatible libraries is optional. GPL:ed libraries is, as said above, a different story, that from a legal point of view is an unresolved issue. The "answer" of that question regardless of what it will be, will, be very important since it might, unless it is too vague, define the boundaries of copyright in a more definite way. However, I'm a little afraid of that for the GPL to be truely meaningful, especially in the case of Wine, you will have define the boundaries of copyright a little to strict for my liking. > Since the number of GPLed Windows apps that do not have Linux > counterparts is vanishingly small, the OpenSSL option seems to > me more appropriate than using a libgcrypt back end. The > OpenSSL license does not have the viral properties that the > GPL has (it's an old-style BSD-type license, complete with the > advertising clause), and therefore we should be able to weak-link > Wine with libOpenSSL without any license contamination. Agreed. > Packagers > who distribute libOpenSSL with Wine would then be responsible > for meeting the OpenSSL license requirements for advertising > and attribution. Of course but that is not our immediate concern, the same would be if we link with any proprietary library. Any distributor of such libraries whether in conjuction with Wine(lib) or seperately must of course fullfull the licensing requirements of such libraries (including but not limited to pay any license fees). Actually in some meaning we already do, since proprietary implemenatations of both X Windows and OpenGL exists and Wine(lib) will happily dynamically link with them and use them if they exists. Wine(lib):s use of them obviously do not gives any license to distribute them, but that is not our concern. This of course raises they question if we mandatorily link to libraries, like X Windows or OpenGL, that both have GPL and non-GPL compatible implemtations: Do we optionally or mandatorily link to a non GPL compatible library? Does this matter from a legal perspetive as concerning whether a Winelib user violate the GPL or not? In addition does it matter whether the GPL compatible library is: 1. Complete 2. Close to complete 3. Has only basic functionallity 4. Unusably buggy 5. Unimplemented stubs 6. In the planing state 7. A theoretical construction In that case why?

2 1

DDE and postmessage
by eric pouech 16 Sep '01

16 Sep '01

(mainly for Alexandre) I've started looking at the inter-process DDE message management as of today, PostMessage doesn't use the packing strategy used by SendMessage (rightfully because of possible dangling pointer issue if pointers are used in message parameters) however, some DDE messages need to send additional information even when posting (copying all data), and DDE protocol requires posting messages (SendMessage is banned) do you have any plan to handle this ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

RE: dlls/advapi32/crypt.c
by Patrik Stridvall 16 Sep '01

16 Sep '01

> On another note, however, I was re-reading the CryptoAPI > thread and I don't > think that Vladimir Vukicevic's questions were really > answered from September > 3rd. Can you be a little more specific? As far using GPL:ed libraries, that is a question that really can't be properly answered without a real court case. Regardless of this if you want any code using a GPL:ed library in the CVS you need to convince Alexandre to change his mind. What other questions are unanswered?

5 4

min/max and types
by eric pouech 15 Sep '01

15 Sep '01

just for fun, I tried compiling Wine with Linux latest min/max macros definitions Index: include/windef.h =================================================================== RCS file: /usr/share/cvs/cvsroot/wine/wine/include/windef.h,v retrieving revision 1.58 diff -u -r1.58 windef.h --- include/windef.h 2001/07/30 18:57:18 1.58 +++ include/windef.h 2001/09/14 18:06:53 @@ -133,6 +133,27 @@ #define min(a,b) (((a) < (b)) ? (a) : (b)) #endif #endif /* NOMINMAX */ +#if defined(__WINE__) && defined(__GNUC__) +#undef max +#undef min +#define min(x,y) \ + ({ const typeof(x) _x = x; \ + const typeof(y) _y = y; \ + \ + (void) (&_x == &_y); \ + \ + _x < _y ? _x : _y; \ + }) + +#define max(x,y) \ + ({ const typeof(x) _x = x; \ + const typeof(y) _y = y; \ + \ + (void) (&_x == &_y); \ + \ + _x > _y ? _x : _y; \ + }) +#endif #ifndef _MAX_PATH /* FIXME: These are supposed to be in stdlib.h only */ here's the output (the list of types mismatches in min/max calls...) to whomever feels like fixing them (if needed) registry.c:386: warning: comparison of distinct pointer types lacks a cast registry.c:1246: warning: comparison of distinct pointer types lacks a cast trace.c:69: warning: comparison of distinct pointer types lacks a cast trace.c:147: warning: comparison of distinct pointer types lacks a cast reg.c:177: warning: comparison of distinct pointer types lacks a cast reg.c:195: warning: comparison of distinct pointer types lacks a cast reg.c:209: warning: comparison of distinct pointer types lacks a cast reg.c:224: warning: comparison of distinct pointer types lacks a cast reg.c:232: warning: comparison of distinct pointer types lacks a cast reg.c:306: warning: comparison of distinct pointer types lacks a cast reg.c:318: warning: comparison of distinct pointer types lacks a cast reg.c:328: warning: comparison of distinct pointer types lacks a cast reg.c:379: warning: comparison of distinct pointer types lacks a cast reg.c:416: warning: comparison of distinct pointer types lacks a cast reg.c:496: warning: comparison of distinct pointer types lacks a cast dos_fs.c:2201: warning: comparison of distinct pointer types lacks a cast dos_fs.c:2202: warning: comparison of distinct pointer types lacks a cast drive.c:926: warning: comparison of distinct pointer types lacks a cast file.c:1884: warning: comparison of distinct pointer types lacks a cast profile.c:120: warning: comparison of distinct pointer types lacks a cast module.c:1644: warning: comparison of distinct pointer types lacks a cast module.c:1645: warning: comparison of distinct pointer types lacks a cast heap.c:645: warning: comparison of distinct pointer types lacks a cast local.c:401: warning: comparison of distinct pointer types lacks a cast local.c:891: warning: comparison of distinct pointer types lacks a cast registry.c:507: warning: comparison of distinct pointer types lacks a cast version.c:477: warning: comparison of distinct pointer types lacks a cast int21.c:857: warning: comparison of distinct pointer types lacks a cast int21.c:861: warning: comparison of distinct pointer types lacks a cast ole2nls.c:435: warning: comparison of distinct pointer types lacks a cast process.c:1251: warning: comparison of distinct pointer types lacks a cast process.c:1276: warning: comparison of distinct pointer types lacks a cast process.c:1312: warning: comparison of distinct pointer types lacks a cast process.c:1345: warning: comparison of distinct pointer types lacks a cast console.c:170: warning: comparison of distinct pointer types lacks a cast console.c:429: warning: comparison of distinct pointer types lacks a cast console.c:982: warning: comparison of distinct pointer types lacks a cast console.c:984: warning: comparison of distinct pointer types lacks a cast console.c:1294: warning: comparison of distinct pointer types lacks a cast console.c:1345: warning: comparison of distinct pointer types lacks a cast registry.c:785: warning: comparison of distinct pointer types lacks a cast registry.c:1001: warning: comparison of distinct pointer types lacks a cast registry.c:1082: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:203: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:229: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:230: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:1702: warning: comparison of distinct pointer types lacks a cast dde/misc.c:1963: warning: comparison of distinct pointer types lacks a cast message.c:962: warning: comparison of distinct pointer types lacks a cast resource.c:320: warning: comparison of distinct pointer types lacks a cast resource.c:370: warning: comparison of distinct pointer types lacks a cast text.c:318: warning: comparison of distinct pointer types lacks a cast menu.c:847: warning: comparison of distinct pointer types lacks a cast menu.c:849: warning: comparison of distinct pointer types lacks a cast menu.c:917: warning: comparison of distinct pointer types lacks a cast menu.c:918: warning: comparison of distinct pointer types lacks a cast menu.c:931: warning: comparison of distinct pointer types lacks a cast cursoricon.c:519: warning: comparison of distinct pointer types lacks a cast timer.c:155: warning: comparison of distinct pointer types lacks a cast winpos.c:1811: warning: comparison of distinct pointer types lacks a cast winpos.c:1812: warning: comparison of distinct pointer types lacks a cast winproc.c:1755: warning: comparison of distinct pointer types lacks a cast winproc.c:1768: warning: comparison of distinct pointer types lacks a cast winproc.c:1901: warning: comparison of distinct pointer types lacks a cast winpos.c:1733: warning: comparison of distinct pointer types lacks a cast winpos.c:1734: warning: comparison of distinct pointer types lacks a cast winpos.c:1738: warning: comparison of distinct pointer types lacks a cast winpos.c:1739: warning: comparison of distinct pointer types lacks a cast winpos.c:1743: warning: comparison of distinct pointer types lacks a cast winpos.c:1744: warning: comparison of distinct pointer types lacks a cast winpos.c:1748: warning: comparison of distinct pointer types lacks a cast winpos.c:1749: warning: comparison of distinct pointer types lacks a cast winpos.c:1815: warning: comparison of distinct pointer types lacks a cast winpos.c:1816: warning: comparison of distinct pointer types lacks a cast winpos.c:1817: warning: comparison of distinct pointer types lacks a cast winpos.c:1818: warning: comparison of distinct pointer types lacks a cast xfont.c:3336: warning: comparison of distinct pointer types lacks a cast xfont.c:3339: warning: comparison of distinct pointer types lacks a cast lolvldrv.c:106: warning: comparison of distinct pointer types lacks a cast mmsystem.c:986: warning: comparison of distinct pointer types lacks a cast comboex.c:395: warning: comparison of distinct pointer types lacks a cast listview.c:723: warning: comparison of distinct pointer types lacks a cast listview.c:780: warning: comparison of distinct pointer types lacks a cast listview.c:3123: warning: comparison of distinct pointer types lacks a cast listview.c:7940: warning: comparison of distinct pointer types lacks a cast propsheet.c:145: warning: comparison of distinct pointer types lacks a cast propsheet.c:1998: warning: comparison of distinct pointer types lacks a cast rebar.c:1476: warning: comparison of distinct pointer types lacks a cast rebar.c:1490: warning: comparison of distinct pointer types lacks a cast tab.c:1080: warning: comparison of distinct pointer types lacks a cast toolbar.c:1086: warning: comparison of distinct pointer types lacks a cast treeview.c:1500: warning: comparison of distinct pointer types lacks a cast treeview.c:1594: warning: comparison of distinct pointer types lacks a cast treeview.c:2514: warning: comparison of distinct pointer types lacks a cast treeview.c:2516: warning: comparison of distinct pointer types lacks a cast treeview.c:4218: warning: comparison of distinct pointer types lacks a cast treeview.c:4351: warning: comparison of distinct pointer types lacks a cast treeview.c:4356: warning: comparison of distinct pointer types lacks a cast midi.c:117: warning: comparison of distinct pointer types lacks a cast audio.c:774: warning: comparison of distinct pointer types lacks a cast audio.c:1759: warning: comparison of distinct pointer types lacks a cast midi.c:618: warning: comparison of distinct pointer types lacks a cast midi.c:968: warning: comparison of distinct pointer types lacks a cast internet.c:489: warning: comparison of distinct pointer types lacks a cast -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 2

Winsock API
by Robert Lunnon 15 Sep '01

15 Sep '01

I have Converted WSAIOCTL to use SIOCGETIFCONF ioctl calls rather than parse /proc which is to linux-centric but I was asked by Francois Gouget to look at trying to make WsControl unix independent by implementing it using other windows APIs rather than by using unix calls directly. Unfortunately this API is a bit of a mess because WsControl can return the MAC Adress but WSAIoctl doesn't appear to implement that functionality. To get The MAC Address we then need to make an appropriate UNIX IOCTL call for which we need the interface name, which isn't available from WSAIoctl either. There are other ways in windows to getthe MAC address via an SNMP call but I'm not sure how that is implemented (Possibly with a call back to WSControl) I don't see then how WSControl can be implemented without the present hacks and duplicated code between WSAIoclt and WSControl helper functions. My proposal then would be... 1.) Separate out all the unix centric helper functions for WSControl and WSAIoctl into a common ancestor source file with no windows dependencies. This should remove the ugly socket hack in WSControl, both libraries still end up with private copies of the common helper functions but since they are all derived from the same common source file it will at least be encapsulated and easier to maintain. 2.) The doco for WSIoctl indicate the encoding for the Ioctl op-code allows for a "Standard" unix IOCTL to be passed to WSIoctl ostensibly for FIONREAD,FIONBIO et al, with predictable results. If I were to implement SIOCGETIFCONF in WsIoctl then this would allow a pass-through so I could get what I need from the host OS without disturbing current windows programs. Because windows doesn't define SIOCGETIFCONF whatever we choose for the value of the op-code might end up being used by Microsoft later, breaking Wine. (Possible but not very likely) Opinions ?

1 0

Information Request For Porting WINE
by Lucien LaCroix 15 Sep '01

15 Sep '01

I would like to find out if the development of WINE supports it being ported to Windows 16-Bit OS. Currently, I am developing a Windows Clone and would very much ike to work on Porting WINE to Win16. However, I am not 100% sure if the way WINE operates wether it would work. WINE will work if it is a complete re-written library system that merely interfaces with the host system. WINE won't work if it serves as a translater from host system system calls to the guest application. Any information on this plus a good compiler that is usefull for someone who knows a bit, but not everything, hopefully one with a good GUI. Thank-You. David Scherer, lacroixlucien(a)hotmail.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

2 1

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