wine-devel

wine-devel@winehq.org

6 participants
84465 discussions

Question about STRICT
by Vincent Béron 09 Dec '02

09 Dec '02

I was compiling the tests on MSVC (hence my patch), and the gdi32test wouldn't compile with the Wine headers (but would with MSVC's). The problem can be traced back to the absence of STRICT in windef.h. With the closure of bug #90 (compilation with -DSTRICT), I think it would make sense to define it in a header (windef.h seems logical), with an ifdef NO_STRICT provision (see the attached proposed patch). This would allow to remove all -DSTRICT on compilation command lines. I await your comments on it. Vincent --- wine-20021206-1700/include/windef.h 2002-10-23 20:47:38.000000000 -0400 +++ wine-20021206-1700/include/windef.h 2002-12-07 16:34:02.000000000 -0500 @@ -28,6 +28,12 @@ #ifndef WINVER #define WINVER 0x0500 #endif + +#ifndef NO_STRICT +#ifndef STRICT +#define STRICT +#endif /* STRICT */ +#endif /* NO_STRICT */ #include "winnt.h"

2 1

Fw: Loading Autorun.inf on CD's
by Dustin Navea 09 Dec '02

09 Dec '02

----- Original Message ----- From: "Sylvain Petreolle" <spetreolle(a)yahoo.fr> To: "Tony Lambregts" <tony_lambregts(a)telusplanet.net>; "Dustin Navea" <speeddymon(a)sbcglobal.net> Cc: "Sylvain Petreolle" <spetreolle(a)yahoo.fr>; "Wine Developers" <wine-devel(a)winehq.com> Sent: Sunday, December 08, 2002 5:11 AM Subject: Re: Loading Autorun.inf on CD's > If you want act in this way, I have something for you. > This could help Paul Jones, who is searching how to "launch" *.msi > installers. interesting > The better way we can handle this is a program who tries to open every > document we give to it. A freeware utility exists in cygwin world and > is called cygstart, using the existing registry. If we give it a .doc, > it looks in HKCR and starts Worpad/Winword. > That is a definite must.. > If we tweak the registry of a .inf (winedefault.reg), we can ask it to > launch a tiny program that will open the .inf and run the program > specified. Sounds like it could work, but what about inf installer files (ie TweakUI's inf, or driver inf files) how would they be handled? > > I have not seen this work either and definitely not with an .inf. Yes > > it > > would be cool and if you want to start a bug concerning it feel free. > > I > > am not that worried about it though. The way I see it is that most of > > > > this is not realy a wine problem but rather with setting up autorun > > so > > that it is able to understand what to do with an .inf file. I suppose > > > > another way to look at it might be that wcmd could/should be able to > > handle something like "wcmd autorun.inf". > > -Dustin

2 2

regression: msvc4.0 install dies sooner now
by Dan Kegel 09 Dec '02

09 Dec '02

I found an unopened copy of msvc++ 4.0 at a garage sale last year for $5, couldn't resist. Today I finally tried to install it under Wine. wine-20020605-2 (rh8): installer started; when I clicked on 'Install Visual C++', it put up a 'Installing... please wait' dialog, then failed with a 'Can't read version info from C:\windows\kernel386.drv' message (more or less), then hung. wine-20021125 (from source): installer started; when I clicked on 'Install Visual C++', it hung. Looks like a regression to me. Logs of --debugmsg +relay are up at http://www.kegel.com/msvc4setup-wine20020605.log.bz2 http://www.kegel.com/msvc4setup-wine20021125.log.bz2 The latter file is 28MB uncompressed, 512KB compressed. I'm now building the intermediate releases of wine to see if I can narrow down when the regression occurred. - Dan

4 6

Re: Fix my broken WM_MOUSEHOVER patch
by Dimitrie O. Paun 09 Dec '02

09 Dec '02

On December 9, 2002 11:26 am, Mike Hearn wrote: > Patch is relative to wine root, made with cvs diff, is this right? Yes, and no (it's not in the right format). Please read: http://www.winehq.org/development/#patches http://www.winehq.com/hypermail/wine-devel/2002/09/0127.html -- Dimi.

3 2

Problem with DOSFS_OpenDevice
by Gustavo Junior Alves 09 Dec '02

09 Dec '02

Hi All, I having problems with raw printing. I receive this message from trace: device open lpt1 not supported (yet) Looking the code, I do not found any support for parallel ports neither on server or dos_fs. I missed something or DOSFS_OpenDevice does not support parallel printers? Thanks for the help. Gustavo Junior Alves alves(a)coslinux.com.br

2 1

Re: wine/dlls/winsock socket.c
by Martin Wilck 09 Dec '02

09 Dec '02

Am Sam, 2002-12-07 um 00.19 schrieb Alexandre Julliard: > Christoph Frick <frick(a)SC-Networks.de> > Force (WS_)SO_REUSEADDR before binding to a socket; Sorry, this is definitely wrong. Windows, just as Unix, returns WSAEADDRINUSE if SO_REUSEADDR isn't set (just tried it on W2k). There must be some special circumstances involved in those games the patch is supposed to fix. Perhaps they assume a certain Winsock implementation or Windows version. I'd like to know what remote addresses exactly the apps call bind() for, and in what order. Perhaps there are subtle differences in the way EADDRINUSE and SO_REUSEADDR are handled. > ignore (WS_)SO_DONTROUTE; Network games in Grand Prix Legends and Nascar 2002 > are possible now. Footnote (i) in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/wi… says that this is - in principle - legal: "A service provider may silently ignore this option on WSPSetSockOpt and return a constant value for WSPGetSockOpt, or it may accept a value for WSPSetSockOpt and return the corresponding value in WSPGetSockOpt without using the value in any way." However the patch implements the first behavior (ignore) whereas the Windows TCP/IP transport behaves as the second (later calls to getsockopt() refelect the SO_DONTROUTE settings, which seems to have no further effect). > Patch: http://cvs.winehq.com/patch.py?id=6523 Alexandre, please back this patch out for now, at least the SO_REUSEADDR part which is plain wrong. Please don't get me wrong: These issues need to be fixed, but please, not by applying hackish patches for special applications such as this one. Christoph: sorry I missed out on your previous mails to wine-devel. Next time, say something about sockets in the subject line and chances are I won't miss them again. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

RE: wpp
by Patrik Stridvall 09 Dec '02

09 Dec '02

> On December 8, 2002 06:01 pm, Patrik Stridvall wrote: > > It would be very nice it something made a GNU C compiler > > library to support among other things only running > > the preprocessor. > > Um, you mean like "cpp"? The debian packagers have even split > it out from > the gcc package for convenience, the package description explains; > > --------- > [snip] > The GNU C preprocessor is a macro processor that is used > automatically by > the GNU C compiler to transform programs before actual compilation. > > This package has been separated from gcc for the benefit of those who > require the preprocessor but not the compiler. > [snip] > --------- > > so clearly it can be done, and this is presumably for the > reasons Dimitrie > mentioned - preprocessing can be a useful (and much faster) subset to > separate out from the compilation process. Note that I said LIBRARY. Still running cpp is presumably more lightweight that running "gcc -E". > But as for the GPL argument against using the GNU C > (pre)compiler from a > run-time (ie. "forking/exec of 'gcc -E' is like linking to a > GPL lib"), I > find that rather hard to believe - especially as invoking > "gcc -E" can be > framed in very user-supplied terms. Eg. if the user is able to (in > theory) configure the program to exec() any precompilation > programs (and > command-line options) they want, then who is going to sue > *who* when the > default value for that setting just happens to be "gcc -E" when the > program installs? Exactly, as I said, it would never fly in court. However that doesn't mean that the FSF doesn't claim it never the less: http://www.fsf.org/licenses/gpl-faq.html#GPLInProprietarySystem > Richard Stallman will sue Redhat? Or will > the FSF begin > a crackdown against adolescent nerds who illegally point > GPL-incompatible > configuration files to GPL-licensed precompilers ...? I really don't > think this should be a cause for concern. No, I don't think it would be a cause for concern either. Still, as I said, that is what they claim. Obviously they are not stupid so it would be very unlikely that they would press the issue. They seem to prefer to use FUD to accieve their goals instead.

2 1

Winedbg and gcc 3.2
by Alberto Massari 09 Dec '02

09 Dec '02

Hi everybody, a few weeks ago I changed my build machine from a RedHat 7.2 + gcc 2.9x to a Mandrake 9.0 + gcc 3.2, and I noticed that I was unable to debug the Wine libraries (I got messages like "No debug information in ELF '/usr/local/lib/wine/xxxx.dll.so'), while gdb worked just fine. So today I digged a little bit and I found that winedbg supports the "stabs" debug format, and looks for the ".stabs" segment in the binary. The copy of gcc 3.2 I have (gcc-3.2-1mdk) doesn't produce this segment unless I replace the -g option with -gstabs. My questions at this point are: - is this behavior typical of every gcc 3.2? or it's only Mandrake that does it? - is somebody going to change the "configure" script to detect such a situation and specify "-gstabs" instead of "-g"? (I would volunteer myself, but I am not expert in this field... I just hacked my copy to make it work in my tree) - or should winedbg be improved to understand more debug formats, so that it can handle whatever informations the "-g" option spits out? Thanks, Alberto P.S. Please don't flame me if I said something naive....

2 2

GDI RestoreDC()
by Mike Hearn 09 Dec '02

09 Dec '02

Hi all, I think I've traced the problem with the Adobe SVG plugin not reliably rendering: This is from a good run (when I use an svg file I know will render OK): 080746b8:Call kernel32.LOCAL_Free(0000019f,00001aca) ret=40948f6b 080746b8:Ret kernel32.LOCAL_Free() retval=00000000 ret=40948f6b trace:gdi:GDI_FreeObject (0x1aca): leave 1 080746b8:Ret gdi32.DeleteObject() retval=00000001 ret=5300a17c 080746b8:Call gdi32.BitBlt(000008a8,00000000,00000000,0000008c,0000008c,00000ba0,00000000,00000000,00cc0020) ret=5300a1ae As you can see, it appears to perform the BitBlt call correctly, those parameters look correct. Here is the same section from a bad run: 080746b8:Call kernel32.LOCAL_Free(0000019f,00001ac2) ret=40948f6b 080746b8:Ret kernel32.LOCAL_Free() retval=00000000 ret=40948f6b trace:gdi:GDI_FreeObject (0x1ac2): leave 1 080746b8:Ret gdi32.DeleteObject() retval=00000001 ret=5301b3df 080746b8:Call gdi32.RestoreDC(000008a8,ffffffff) ret=53018c68 It doesn't call BitBlt at all, not now, not later, not at all. Instead, it calls RestoreDC for no apparently good reason. That last argument looks highly suspicious, in that MSDN says it's an int which when positive identifies a state and when negative identifies a "step", ie -1 would restore the last state from the stack. I can't figure out what ffffffff would be as an int though :( Would it be negative or positive? Either way, is this an intelligent sort of value for the parameter to have? The MSDN docs are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcon… I can't figure out why it would suddenly call RestoreDC and then seemingly go off on a tangent (the traces match up until that point), rather than do a BitBlt like it's supposed to. The SVG files vary only in that the "good" one has some interactivity (but it's not triggered at startup). Does anybody have any ideas? I'm fresh out for today. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 2

RE: wpp
by Patrik Stridvall 09 Dec '02

09 Dec '02

> In other words, preprocessing is like 10% of compilation, so > it can't be unbearably slow. Something else is wrong. Perhaps. It was quite a few years ago I did it. I just remember abandoning the idea of using "gcc -E" for preprocessing in winapi_check because of horrible a speed slowdown. > > The FSF claims that you forking and calling a GPL:ed executable > > is the same as linking with a GPL:ed library and calling > > functions in that library. > > Do you have a reference to this? Never heard of something like > this before. It was dicussed extensively during the great licensing war. http://www.fsf.org/licenses/gpl-faq.html#GPLInProprietarySystem The main part is this I think: < The difference between this and "incorporating" the GPL-covered software < is partly a matter of substance and partly form. The substantive part is < this: if the two programs are combined so that they become effectively < two parts of one program, then you can't treat them as two separate programs. < So the GPL has to cover the whole thing. In the case of wrc it is pretty clear that "gcc -E" will one of the parts of the whole program and thus wrc must be under the GPL (or compatible with it). While, as I said earlier, this is a not a direct problem for a LGPL application, we have as I said I policy not to "link" with GPL:ed applications.

1 0

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