- Wine-Devel - list.winehq.org

regression: msvc4.0 install dies sooner now
by Dan Kegel Dec. 9, 2002

Dec. 9, 2002

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 Dec. 9, 2002

Dec. 9, 2002

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 Dec. 9, 2002

Dec. 9, 2002

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 Dec. 9, 2002

Dec. 9, 2002

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(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

RE: wpp
by Patrik Stridvall Dec. 9, 2002

Dec. 9, 2002

> 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 Dec. 9, 2002

Dec. 9, 2002

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 Dec. 9, 2002

Dec. 9, 2002

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 Dec. 9, 2002

Dec. 9, 2002

> 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

Re: Janitorial Projects -- conformance tests --recruiting volunteers
by David Miller Dec. 9, 2002

Dec. 9, 2002

As someone only attempting to learn C I am looking for some other way to contribute something to wine. I have WinXP home on my laptop, so I could do WinXP tests if you can give me more information on what needs to be done. Dave

1 0

RE: wpp
by Patrik Stridvall Dec. 9, 2002

Dec. 9, 2002

> On December 8, 2002 03:27 pm, Patrik Stridvall wrote: > > It is faster. Mucher faster. Using cpp/gcc -E needs to > > fork a new process for example. > > What?!? You got to be kiddin', right? If you can measure > any difference in build time between the forking gcc -E > and using wpp I'll give you a dollar in small change. I personally have only tried piping every file parsed by winapi_check through "gcc -E" and it is was unbearably slow, so I removed the code. The parsing it itself can't possibly taken that extra time. So I'm pretty sure that I can measure it, yes. However, the big question is not if it is measuarable but rather if it is worth the cost or not. So, yes, I agree that we need to discuss the question. > On Linux process creating is extremely fast, and we do > fork 1000s of processes while building wine, this sort > of argument is just silly. Well, it is not really the "fork" in it self that is the problem it is the overhead of loading and initializing gcc and that sort of things. > By the same rationale I suggest having a complete copy > of gcc, ld, nm, and whatever tools we use while building > wine. It is not primarily a question of having a complete copy of whatever. It is a question of having whatever accessable as functions in a library to avoid a lot of unnessary overhead. It would be very nice it something made a GNU C compiler library to support among other things only running the preprocessor. > So no, if speed is the only argument, I say we get rid > of it: it's not worth maintaining a fraction of all that > additional code. 1. Depending on "gcc -E" will make it harder to port wrc to Windows. 2. It might be less flexible (not sure though). > > And then of course using "gcc -E" would possibly cause > > a GPL violatation. Not that it would matter very much > > if wrc and friend were GPL:ed. > > WTF are you talking about?!? How did you figure this one > out? Really, this is simply false, you can fork GPL > programs all you want, and cause no GPL violation. 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. This is of course absurd and would IMHO opinion nether fly in a court of law but still.... Sure wrc and friend are under a GPL compatible license (LGPL), so it wouldn't be a direct violation. However Wine has a policy that we do not link with GPL:ed libraries regardless in order to avoid possible problems for companies working with Wine so no we really can't make wrc depend of "gcc -E".

3 2