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

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 15, 2001

Dec. 15, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > They might even have an implementation from scratch with no > Wine code at > > all. > > I can see no difference between for example their DLL and a > Microsoft DLL > > running under Wine, regardless of Wine being GPL or LGPL or > whatever. > > There is no difference whatsoever, as long as it is not based on Wine > code. We can't (and shouldn't) prevent anybody from reimplementing a > dll from scratch. My point exactly. > What we can (and should IMO) prevent is people using > our own code against us. Yes, but does the example below ... > > Then we have the middle case by have say the Crypto API that is > > a part of ADVAPI32. Does distributing a whole file replacement of > > dlls/advapi32/crypt.c represent a violation of GPL or LGPL? > > In that case why? The Crypto API is largely independent of the > > rest of ADVAPI32 it could as well be a separate DLL. ... really violate the LGPL IYO (In Your Opinion)? I really can't see why it is significant that Microsoft put the Crypto API in ADVAPI32.DLL instead of say a seperate DLL, say CRYPTO32.DLL. > > Any protection that (L)GPL provides is to a large part based on > > myth and legend. > > I think you are very mistaken here. The protection is based strictly > on copyright law, and if anything is certain it is that copyright law > is going to become even stronger in the coming years. There are certainly a lot of people that _wish_ to make copyright law stronger. However even more important is a copyright law that make logical sense. I think doctrine of derived work is one of the most serious mistakes in how copyright law today is formulated. The basic idea is a good one and I support it, but I really think it should have been formulated in term of combined works instead of derived works. That is, if you combine your work with somebody elses work and distribute it together you must have the permission all the authors of all parts the combined work consists of. But that is exactly what the doctrine of derived work says, you object, what is the difference? Well, the difference is subtle. Under a strict doctrine of combined work ONLY distribution of the combined work is prohibited not providing a work that can be combined with another work to form a combined work regardless of whether this was intended or not. Under such a doctrine, the (L)GPL doesn't make any sense (and thus have no power) if all if you only provide patches. Note that you only have to accept the (L)GPL if you distribute the (L)GPL:ed work and you don't. The fact that end user can combine your work and the (L)GPL:ed work, perhaps using a script you wrote, perhaps not, doesn't matter att all under a strict combined work doctrine since no distribution is taking place. The big question for the future is the doctrine of derived work really a strict doctrine of combined work? Note that 1. This is the only thing it AFAIK has been used for in actual court cases 2. This might be the only possible constitutional interpretation of copyright law, because otherwise somebody (A) can prevent somebody else (B) from "speaking" based on what some third party (C) can used the "speech" lawfully acquired from B together with some "speech" lawfully acquired from A. Especially since what C might do is most likely not even be illegal. > In addition our situation is even easier since the dll interfaces are > already defined for us; the difficulties you see are purely imaginary, > I don't think there would be any technical problem applying the LGPL > to Wine. Technical problems perhaps not, but does it help? Especially given how much it might hurt. > The GPL is another story, but we clearly don't want to go there if > Wine is to remain useful for running proprietary applications. Agreed. > > In addition hypocritical people at for example Slashdot also > > seems to wish to apply different standard at open source licenses > > and proprietary licenses. > > > > So company cries that their products shouldn't be hacked (having a > > part replace) should be ignored despite their insistance that a > > paragraf of their license has been violated, while any violations > > of the (L)GPL doing essentialy the same thing (replacing a part) > > should be strictly enforced. :-) > > If you don't understand the fundamental difference between the GPL and > a standard EULA, I'd suggest studying the issue a bit more. And > www.gnu.org is probably a better reference than Slashdot to learn > about this kind of things <g> Oh, I read both these sites and more. Sure there is a difference, as the current law is written, but the big question does it make sense that there is a difference? The fundamental issue is the same. 1. I am the author of some work 2. You would like to use my work in some way. 2. I'm prepared to make the work available to you under some conditions As a side note, because of copyright as some sort of public contract not all possible conditions are enforcabled. For example first sale doctrine says I can't control what happends to a specific copy of a work once I have sold it. But that doesn't change the fact the situations are basicly the same and I was not talking about law here rather about morality. I said hypocritical didn't I? > > True, but that doesn't worry me so much, since very few non games > > depend of DirectX and this allows us concentrate on what is really > > important getting commonly used productivity applications to run > > under Wine. > > In short, because you don't care about games Wine doesn't have to > support them. I strongly disagree with this sentiment; even though I > don't care much about games myself, I want Wine to be able to run them > just like other applications. And again, DirectX is just one example > of something that could happen with any other part of Wine. What I mean is that, we can't have everything. We don't have the resources to do everything. We have to make priorities and people playing games are people that are unlikely to provide a lots of new developers or other resources for the core Wine project as it is organized. Companies on the other hand wanting to run their productivity application are much more likely to provide resources developing Wine further especially after we reach the point there their normal applications run close to perfectly and they wish to make their more unusual application to run as well to be able to provide a say all Linux desktop. Therefore I'm happy to leave things like DirectX to companies like Transgaming for the time being since people that wants to play games are more likely to be happy with the way they can support Transgaming ie paying a monthly fee. > > That is true, but I still think we made the right choice. > > If we had made Wine LGPL we might have prevent Transgaming > > from entering the market and a change now might prevent others > > from doing so. > > I don't think so; they would certainly have had to make some > adjustments to the business model, but I think it is definitely > possible to build a business on an LGPL code base. Of course these > days building any kind of business is quite difficult, but I don't > think LGPL vs. X11 is going to be the difference that makes otherwise > successful businesses fail. Using your strict interpretion of the LPGL it will significantly increase the cost of entry to the market, thus requiring higher risk of entering the market, even with a basicly sound business model. > > I think it is very dangerous for us to reject the help we can get > > to increase the mind share of Wine and derivates as a whole, > > inspite of any inconviences for the core Wine project. > > > > Wine has not yet accieved the breakthrough on the desktop market > > that Linux did on the server market and until then we need all the > > allies we can yet, regardless of their actually "loyalties". > > Well, I strongly disagree. Wine is supposed to be a free > implementation of Windows; if making it successful requires making it > non-free, we might as well stop right now. "He who defend everything, defends nothing" Need I say more? > Anyway we are not going to convince each other. I take note that you > are opposed to the change, even if I admit I'm a bit surprised; it > seems last time we discussed licenses you were quite favorable to the > LGPL. Well, with age comes wisdom (or senility). :-) Seriously, we made that choice we made in hope that it would be a good one and I think it is to early to say that the choice was a bad one. Changing licenses out of panic is a bad idea. Let calm down and think this through properly.

4 3

Re: [RFC] Async I/O patch: server code + ReadFileEx()
by lawson_whitney＠juno.com Dec. 15, 2001

Dec. 15, 2001

On Sat, 15 Dec 2001, Mike McCormack wrote: > > Hi Lawson, > > another user head space error... i forgot to include async.h :-/ > > Here's the patch including async.h. > > Mike > > > >I did tools/make_requests, but where is async.h spoze to come from? > .. > make[1]: Entering directory `/oof/Wine-20011108/miscemu' make[1]: `miscemu.o' is up to date. make[1]: Leaving directory `/oof/Wine-20011108/miscemu' gcc -o wine miscemu/miscemu.o -L./dlls -lntdll -L./library -lwine -L./unicode -l wine_unicode -lncurses -lm -lutil -ldl ./dlls/libntdll.so: undefined reference to `FILE_GetTimeout' collect2: ld returned 1 exit status make: *** [wine] Error 1 [whit(a)giftie wine]$ This might be something stupid I have done, OTOH she had warts, and it might not be. I'll sort it out later. Lawson ________________________________________________________________ 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/.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 15, 2001

Dec. 15, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Umm. I feared that question would come. The "protection" > the LGPL (or GPL) > > that Marcus proposed is IMHO largely an illusion when it > comes to libraries. > > > > Sure we might use a strict interpretion as a weapon in a PR campaign > > against possible voilators but we don't have the resources to sue > > somebody and I very much doubt we would succed either. > > I think you greatly underestimate the power of such licenses. That is what remains to be seem. Many laws doesn't make logical sense anymore or becomes inconsistant in the new brave world and the attempts to adapt them often introduces new problems. The attempts of various courts the interpret the uninterpretable inconsistancies, without realizing it, futuremore adds to the confusion. Expect extreme uncertainty to be the keyword for the immediate future. > AFAIK > nobody in the world is currently shipping code (except maybe by > mistake) in violation of the GPL or LGPL, despite the fact that it has > never been taken to court. True, it does have some power because few wants to be named a bad boy, but that might mean less and less in the future. > And nobody in their right mind would base a > business on shipping illegal code; even if they believed they could > get a judge to agree with them, the risk is simply too great. Small changes in a particular DLL then there is no clear boundaries between their boundaries between their code and ours might be risky, true. However, in your example five companies offered one proprietary version each of five different half important DLLs. They might even have an implementation from scratch with no Wine code at all. I can see no difference between for example their DLL and a Microsoft DLL running under Wine, regardless of Wine being GPL or LGPL or whatever. Then we have the middle case by have say the Crypto API that is a part of ADVAPI32. Does distributing a whole file replacement of dlls/advapi32/crypt.c represent a violation of GPL or LGPL? In that case why? The Crypto API is largely independent of the rest of ADVAPI32 it could as well be a separate DLL. Any protection that (L)GPL provides is to a large part based on myth and legend. In addition hypocritical people at for example Slashdot also seems to wish to apply different standard at open source licenses and proprietary licenses. So company cries that their products shouldn't be hacked (having a part replace) should be ignored despite their insistance that a paragraf of their license has been violated, while any violations of the (L)GPL doing essentialy the same thing (replacing a part) should be strictly enforced. :-) Note that I'm not accusing you of being hypocritical, I just point out the we can't both have the cake and eat it. What if Microsoft licensed their code as is not allowed to run under an emulator or something similar? Of course myth and legend can be a powerful ally. Just look at all thing done, good or bad, in the name of Christianity, Democracy or whatever, regardless of whether what was done was was logically consistant with whatever else was done. However, my opposition to (L)GPL is not based primarily on that, but rather the alleged, and by you, it seems, supported, features of it. See below. > > > My concern is not so much about Transgaming, I trust that > Gav means to > > > do the right thing, > > > > Agreed and I think we should allow them considerable time > to consider > > their position as well no need to rush something. > > I'm not trying to rush anything, just opening a discussion. And as I > said this is not against Transgaming, any license change would not > modify the current situation at all anyway, since it obviously only > applies to future developments. Agreed. > > > even if I don't entirely agree with his methods. > > > > Well, money makes the world go round whether you like it or not. :-) > > I like it, in fact as you may know I make money with Wine too... I'd > be more than happy to see Gav or others make millions out of Wine, but > I don't want to let people hurt the project, even if doing that makes > them more money. Agreed. > > Now that Transgaming has done the hard work of getting > InstallShield to > > work and even been kind enough provide the source code > eventhough under > > a propritary license it can't be that difficult to look at it and > > provide an alternative implementation. > > The issue is absolutely not limited to this InstallShield stuff. In > fact my worry is much more about what we see happening in DirectX, > where all development on the free version has stopped. True, but that doesn't worry me so much, since very few non games depend of DirectX and this allows us concentrate on what is really important getting commonly used productivity applications to run under Wine. Once companies are being to migrate to Linux/Wine we will hopefully get an influx of new developers to fix less important problems. > > The work of companies that we don't trust is ignored and we work > > on as we always have. > > That's true if that work is kept completely proprietary. But the thing > that the Transgaming stuff should make us realize is that if that work > is released under a free but non open-source license, it competes with > Wine for user and developer mind share, and it hurts Wine no matter > how much we try to ignore it. That is a new situation that I believe > we didn't take into account when picking the current license. That is true, but I still think we made the right choice. If we had made Wine LGPL we might have prevent Transgaming from entering the market and a change now might prevent others from doing so. I think it is very dangerous for us to reject the help we can get to increase the mind share of Wine and derivates as a whole, inspite of any inconviences for the core Wine project. Wine has not yet accieved the breakthrough on the desktop market that Linux did on the server market and until then we need all the allies we can yet, regardless of their actually "loyalties". In short: We have to take the good with the bad.

5 4

Re: [RFC] Async I/O patch: server code + ReadFileEx()
by lawson_whitney＠juno.com Dec. 14, 2001

Dec. 14, 2001

On Fri, 14 Dec 2001, Mike McCormack wrote: > Hi Martin, > > This is a working patch that: > > * orders async operations > * moves all async timeouts and activation back to the server > * works for serial I/O > * should be extensible to other objects > > Tell me what you think. > > Mike > > > ChangeLog: > * move async activation into the server > * implement async queues > I did tools/make_requests, but where is async.h spoze to come from? make[1]: Entering directory `/oof/Wine-20011108/server' ../tools/makedep -I. -I. -I../include -I../include -C. async.c atom.c change.c console.c context_i386.c context_sparc.c debugger.c device.c event.c file.c hand le.c main.c mapping.c mutex.c named_pipe.c object.c pipe.c process.c ptrace.c qu eue.c registry.c request.c select.c semaphore.c serial.c snapshot.c sock.c threa d.c timer.c trace.c unicode.c user.c window.c -C. async.h: No such file or directory async.h was first included from async.c:21 make[1]: *** [depend] Error 1 make[1]: Leaving directory `/oof/Wine-20011108/server' make: *** [server/__depend__] Error 2 [whit(a)giftie wine]$ Probable user head space error. - Dennis A. Moore

1 0

Winelib source for IPropertySetStorage implementation
by Sanand Patel Dec. 14, 2001

Dec. 14, 2001

Hello, We have managed to compile and link winelib for a SPARC CPU, and Winelib runs in a fashion (can compile/link simple C++ application and execute a couple of WIN32 APIs). But I can't seem to find the implementation for IPropertySetStorage/IPropertyStorage. I see the defines in the header files (include/wine/obj_storage..) but I have scoured the winelib source tree for the implementation with no luck. Is this interface implmented? Thanks.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 13, 2001

Dec. 13, 2001

> It's been quite fascinating watching this discussion; it's > nice to see that > such issues are covered. It raises two issues for me: > 1. Where does Lindows fit into all this? Does anyone know > what's happening > there? No idea. > 2. Is the current wine license as loose as it appears to me? Probably. > My > understanding is that "the license" is the file "LICENSE" at > the root of the > cvs tree and basically allows anyone to do anything with it > provided they > keep the license in there (and respect copyright). Yes. > I keep > seeing quotes and > things that suggest wine is under GPL, LGPL, BSD etc.; I > presume that they > are simple ill-informed. It is under the modified BSD license, ie the BSD license without the advertisment clause, more often called the X11 license.

1 0

Re: Patch to memory/virtual.c
by Uwe Bonnes Dec. 13, 2001

Dec. 13, 2001

>>>>> "Robert" == Robert Baruch <autophile(a)starband.net> writes: Robert> Description: map_image now sets up the protections in the view Robert> of the memory-mapped executable image according to the Robert> protections for each section in the image. Before the patch, Robert> running an app under WinDbg on W2K/VMware showed a protection Robert> violation at a certain address, which Wine did not fault at that Robert> address. After the patch, the app faults in the same place in Robert> Wine as it does in W2K. I think the protection setting needs more care. With some shrinker file (targ2001.exe) I get ... trace:module:map_image mapping section .idata at 0x75b69000 off 34000 size c00 flags 40000040 ... trace:virtual:map_image Set protection for section .idata 40000040 to 41. trace:virtual:VIRTUAL_SetProt 0x75b69000-0x75b69fff c-r-- ... Unhandled exception: page fault on write access to 0x75b6903c in 32-bit code (0x40091c2f). In 32-bit mode. 0x40091c2f (PE_fixup_imports+0x2af [pe_image.c:330] in libntdll.so): movl %eax,0x0(%ecx) 333 if (!thunk_list->u1.Function) { Wine-dbg>Backtrace: =>0 0x40091c2f (PE_fixup_imports+0x2af(wm=0x40382b48) [pe_image.c:330] in libntdll.so) (ebp=405b5dc8) Giving VPROT_WRITE to .idata breaks when native oleaut32 is loaded: trace:module:MODULE_LoadLibraryExA Trying native dll 'D:\wine95\system\OLEAUT32.DLL' trace:module:PE_LoadImage loading D:\wine95\system\OLEAUT32.DLL trace:virtual:CreateFileMappingW (18,(nil),01000000,0000000000000000,(null)) trace:module:map_image mapped PE file at 0x65340000-0x653d2000 trace:module:map_image mapping section .text at 0x65341000 off 2000 size 82000 flags 60000020 ... trace:virtual:map_image Set protection for section .text 60000020 to 45. trace:virtual:VIRTUAL_SetProt 0x65341000-0x653c2fff c-r-x ... Unhandled exception: page fault on write access to 0x65341000 in 32-bit code (0x40091c2f). In 32-bit mode. 0x40091c2f (KERNEL32.DLL.__wine_call_from_16_thunk+0x61cf): movl %eax,0x0(%ecx) Wine-dbg>Backtrace: =>0 0x40091c2f (KERNEL32.DLL.__wine_call_from_16_thunk+0x61cf) (ebp=405b6cbc) 1 0x400924e2 (KERNEL32.DLL.__wine_call_from_16_thunk+0x6a82) (ebp=405b6d48) 2 0x40092632 (KERNEL32.DLL.__wine_call_from_16_thunk+0x6bd2) (ebp=405b6d70) ... Running with builtin oleaut32 and friends, I again get to the shrinker error box. Thanks for your efforts so long! Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 13, 2001

Dec. 13, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > In short: > > Should the Wine project wait until you release or should it not? > > That's certainly a question we have to think about, but I think there > is a deeper issue: should we continue to release under a license that > allows people to use our own code to hurt the project? Umm. I feared that question would come. The "protection" the LGPL (or GPL) that Marcus proposed is IMHO largely an illusion when it comes to libraries. Sure we might use a strict interpretion as a weapon in a PR campaign against possible voilators but we don't have the resources to sue somebody and I very much doubt we would succed either. If I was I judge I wouldn't want to touch the issue of what constituted "linking" with a ten foot pole. Beside since where was no real damages since Wine was already free I would probably look for an excuse to dismiss the case as early as possible. No, a license change is not the answer to our problems. > My concern is not so much about Transgaming, I trust that Gav means to > do the right thing, Agreed and I think we should allow them considerable time to consider their position as well no need to rush something. > even if I don't entirely agree with his methods. Well, money makes the world go round whether you like it or not. :-) > But I'm worried that if Transgaming succeeds, it will set a precedent > that others will follow, who may have no desire at all to do the right > thing for Wine. Succeed with what? Now that Transgaming has done the hard work of getting InstallShield to work and even been kind enough provide the source code eventhough under a propritary license it can't be that difficult to look at it and provide an alternative implementation. Note that Gav said: < To say that our work is preventing anyone from doing a free version of DCOM is < completely incorrect. To the contrary: we have already contributed < substantial amounts of this code to the public tree - thousands of < lines, in fact. That can only help anyone with a sudden and unexpected < interest in recreating our work. We could quite easily make InstallShield work ourselves now that they have don't all the tedious debugging and we know what needs to be done. Note copyright only protects expression not fact or ideas (or hard work for that matter). In light of this it might be advantagous for Transgaming to release their InstallShield code. But as I said lets no rush things. I'm prepared to give them the benifit of the doubt and wait for them to decide. However my (and presumable others) patience in not boundless. > What will happen if 5 different dlls are improved and > released by 5 different companies under 5 different non-free licenses? When we had to decide which of the companies we trusted to release their code in the not so far away future and which we don't trust. The work of companies that we don't trust is ignored and we work on as we always have.

2 1

Improved redraw performance when application loaded
by Dave Hawkes Dec. 13, 2001

Dec. 13, 2001

changelog: Reduced the time for a window with many child windows to be displayed. More info: A large application was taking up to 10 seconds to display its main window. This appears to be due to X individually exposing every child window (of which there are very many) of the main application window and then wine forcing a redraw on the parent of every child and then all the subchildren again (!) resulting in the accumulation of a huge redraw list. This patch will force a redraw only on the child and not the parent as X will eventually expose that anyway. After applying this patch the initial redraw dropped from around 10 seconds to about 2 seconds and I could not find any painting problems If anyone else is having slow application loading problems of this nature, then please try this patch. Dave Hawkes

1 0

Re: Uncleared WM_PAINT loop problem
by Gerard Patel Dec. 13, 2001

Dec. 13, 2001

At 02:13 PM 12/12/2001 -0500, you wrote: >I have a problem where an edit control get stuck in an infinite WM_PAINT >loop. > >BeginPaint never clears the paint count because of this code: > > if(((hrgnUpdate = wndPtr->hrgnUpdate) != 0) || (wndPtr->flags & >WIN_INTERNAL_PAINT)) > add_paint_count( hwnd, -1 ); > > >if wndPtr->hrgnUpdate is 0 then the paint count is never decremented here >and nowhere else attempts to decrement it and we land up in an infinite >paint loop. I'm not sure how we get to this point the a NULL update region >(which may be a bug anyway), but there should still be a method of breaking >out of this loop once we are there. > >I tried removing the test and always calling add_paint_count and this >appears to fix the problem. > With current Cvs code the infinite loop should have gone away... Alexandre Julliard has changed a strangeness of BeginPaint : when the update region is null, Wine used to paint the whole window. New code set an empty painting rectangle. However, if the empty update region comes from an earlier Wine bug, the new code replaces excessive repainting with no repainting at all. I have already an app that shows this problem. As I was saying in reply to Andi Mohr, better code can reveal better old bugs... Gerard

2 1

Improved redraw performance when application loaded
by Dave Hawkes Dec. 13, 2001

Dec. 13, 2001

changelog: Reduced the time for a window with many child windows to be displayed. More info: A large application was taking up to 10 seconds to display its main window. This appears to be due to X individually exposing every child window (of which there are very many) of the main application window and then wine forcing a redraw on the parent of every child and then all the subchildren again (!) resulting in the accumulation of a huge redraw list. This patch will force a redraw only on the child and not the parent as X will eventually expose that anyway. After applying this patch the initial redraw dropped from around 10 seconds to about 2 seconds and I could not find any painting problems If anyone else is having slow application loading problems of this nature, then please try this patch. Dave Hawkes

1 0

Great ! [Re: wine/ dlls/user/Makefile.in dlls/user/wnd16.c ...]
by Andreas Mohr Dec. 13, 2001

Dec. 13, 2001

On Wed, Dec 12, 2001 at 08:03:31PM -0500, Alexandre Julliard wrote: > Started rewrite of painting functions for multiple processes. Moved > BeginPaint to dlls/user. Fixed bug in paint count handling. Oh yeah. *Much* better now :-) OrCAD PSpice can actually be looked at now without vom****** :-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 1

Re: Installshield 6 (inter-proc) patches
by Igor Furlan Dec. 13, 2001

Dec. 13, 2001

On Thu, 13 December 2001, Alexandre Julliard wrote: it will set a precedent > that others will follow, who may have no desire at all to do the right > thing for Wine. What will happen if 5 different dlls are improved and > released by 5 different companies under 5 different non-free licenses? > Wasn't (L)GPL designed to ___prevent___ this kind of things to happen ? just my 0.02euro Igor

1 0

Re: Great ! [Re: wine/ dlls/user/Makefile.in dlls/user/wnd16.c ...]
by Gerard Patel Dec. 13, 2001

Dec. 13, 2001

At 02:08 PM 13/12/2001 +0100, you wrote: >On Wed, Dec 12, 2001 at 08:03:31PM -0500, Alexandre Julliard wrote: >> Started rewrite of painting functions for multiple processes. Moved >> BeginPaint to dlls/user. Fixed bug in paint count handling. >Oh yeah. >*Much* better now :-) > >OrCAD PSpice can actually be looked at now without vom****** :-) Well, at least one of my test apps is now completely broken, certainly a following of this patch (repainting problems). This does not mean that the patch is wrong of course - maybe 2 bugs were compensating each other before. Gerard

1 0

Re: OSS fixes
by Duane Clark Dec. 12, 2001

Dec. 12, 2001

Eric wrote: > could the people who had issues with the latest OSS patch(es) test > if this one fixes all their issues ? This patch causes both Riven and Myst to immediately freeze for me, and no sound at all. Without the patch, the sound in Myst works pretty good (occasional brief dropouts). In Riven without the patch, only the opening sequence has sound, and that has many large dropouts. I'm using ALSA drivers in Redhat. Duane

6 7

Uncleared WM_PAINT loop problem
by Dave Hawkes Dec. 12, 2001

Dec. 12, 2001

Hi, I have a problem where an edit control get stuck in an infinite WM_PAINT loop. BeginPaint never clears the paint count because of this code: if(((hrgnUpdate = wndPtr->hrgnUpdate) != 0) || (wndPtr->flags & WIN_INTERNAL_PAINT)) add_paint_count( hwnd, -1 ); if wndPtr->hrgnUpdate is 0 then the paint count is never decremented here and nowhere else attempts to decrement it and we land up in an infinite paint loop. I'm not sure how we get to this point the a NULL update region (which may be a bug anyway), but there should still be a method of breaking out of this loop once we are there. I tried removing the test and always calling add_paint_count and this appears to fix the problem. Before I submit this change, does anyone know the original reason for this test in the first place? Thanks Dave Hawkes

1 0

Re: [PATCH] BeginPaint
by eric pouech Dec. 12, 2001

Dec. 12, 2001

Gerard Patel wrote: > > ChangeLog: > > * windows/painting.c > Fix stupid use of unlocked window pointer wouldn't it be a good idea to zero out the wndPtr after releasing so that we could catch such errors ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Wine doesn't work
by Dmitry Petuhov Dec. 12, 2001

Dec. 12, 2001

Hello!!! I have subj in Wine 20011004 Linux Kernel 2.4.2, Xwindow 4.0.3 It sayes: X Error of failed request: XF86DGANoDirectVideoMode Major opcode of failed request: 138 (XFree86-DGA) Minor opcode of failed request: 22 (XDGAOpenFramebuffer) Serial number of failed request:181 Current serial number in output stream: 181 Why it is and how I may run it???

1 0

can not run IE and it's derived app
by wenhong xing Dec. 12, 2001

Dec. 12, 2001

dear sir/madam: i use wine with redhat linux 7.2 and enjoyed it very much. however, i encountered a problem that may need your help: i have project built with VC++ 6.0. it included CHtmlView/microsoft web browser control. it turned out that they could not be created when the program started. but i link MFC staticlly; at least the CHtmlView shouldn't cause trouble. please give me some advice. thanks wenhong __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com

1 0

problems with counter-strike under wine
by Matthew Winner Dec. 11, 2001

Dec. 11, 2001

info: newest versions of counter-strike and half-life for windows. wine version 200111008 GLX and NVdriver installed and working for nvidia card running hl.exe from .../half-life on c:\ of windows partition with wine --winver win98 hl.exe -- hl.exe --console using c:\\windows, c:\\windows\\system, c:\\windows\\temp, etc in .wine/config file halflife loads and runs flawlessly, but these errors occur when I try and start a game of counterstrike: fixme:winsock:_get_sock_fd handle 0 is not a socket (GLE 6) Warning: /halflife.wad not accessible from a configured DOS drive I also get one that looks like this: fixme:system:SystemParametersInfoA Unimplemented action: 3 (SPI_GETMOUSE) It will terminate on all three of these, apparently at random, but the most common is the one about halflife.wad. here's my config entry on the DOS drive in question: [Drive C] "Path" = "/mnt/win" "Type" = "hd" "Label" = "MS-DOS" "Filesystem" = "win95" "Device" = "/dev/hda1" It's a fat32 partition running windows 98 se and windows 2000. windows 98 is emulated in the conifg file. The last line "Device" I added, hoping this would help somehow. The mount point and /dev/hda1 are correct. I've tried running with --winver win98, this doesn't seem to help. any ideas? I noticed a few others on this post have had similar problems. It's pretty clear that Counter-Strike can and does work under WINE. Is this an ldconfig matter? what should I do? matt -- mwinner(a)altavista.com Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com

1 0

Wine, Office, and the antitrust settlement
by Dan Kegel Dec. 11, 2001

Dec. 11, 2001

I'm proposing that Wine be part of the settlement of the Microsoft antitrust trial. See http://www.kegel.com/remedy.html Comments welcome. I have a few questions for Wine developers, especially the good folks at Codeweavers and Transgaming: 1. How much would it cost to achieve full support for Office 2000 in Wine? 2. Is it true that Office uses undocumented Windows APIs? If so, how many? Are they a significant part of the challenge of supporting Office? Thanks, Dan Kegel dank(a)kegel.com

3 5

extracting shares from mtab
by Robert Lunnon Dec. 11, 2001

Dec. 11, 2001

Mon, 10 Dec 2001 00:06, you wrote: > Message: 6 > Date: Sat, 08 Dec 2001 18:38:57 -0500 > From: Gavriel State <gav(a)transgaming.com> > Organization: TransGaming Technologies Inc. > To: Alexandre Julliard <julliard(a)winehq.com> > CC: Dan Kegel <dank(a)kegel.com>, Eric Pouech <eric.pouech(a)voila.fr>, > Stefan.Leichter(a)camLine.com, wine-devel(a)winehq.com > Subject: Re: UNC patch & parsing fstab/mtab > > Alexandre Julliard wrote: > > > > Dan Kegel <dank(a)kegel.com> writes: > > > > > Just how terrible is parsing /etc/mtab? It doesn't look like > > > much code. I'd be happy to provide a nice OO wrapper object > > > for it if that would make you happier. It would then no > > > longer be an ugly hack. Would that satisfy you? Or are > > > you fundamentally opposed to it for some other reason than > > > code clarity? > > > > Code clarity is one thing (it should be probably using getmntent and > > friends), performance is another (parsing /etc/mtab on each CreateFile > > is *not* a good idea), but mainly I'm opposed to the concept of > > configuring everything by hand except magically getting smb shares > > through /etc/mtab, when they may not at all reflect what you want the > > Windows application to see. It doesn't fit in the current > > configuration philosophy. Now of course the config philosophy can be > > changed, but it must remain coherent. > > I don't doubt that we don't want to be parsing /etc/mtab on each > CreateFile, but I will put in a word for some modifications to the > configuration philosophy when it comes to drive letters. > > One of the problems we've come across recently is this: for games that > use copy protection, we need to have direct access to the device that > a CD-ROM drive uses. For the moment, this relys on the user to manually > configure their drive letters. From what we've seen, doing so is > beyond the ken of many of our users. > > As such, we've put together a scheme for parsing /etc/fstab on startup > (not mtab: the drive may not be mounted), and automatically adding > drive letters for each iso9660 filesystem listed. The patch (to the > WineX tree) is here: > > http://www.geocrawler.com/archives/3/9376/2001/11/0/7204310/ > > We're happy to contribute this in our next outward merge if people > think it's useful. > > -Gav Oh no not again Except for us poor people that dont use linux ! On Solaris fstab is vfstab, and mtab is mnttab, parsing these files is no good unless it is done in some portable way. (Not that smbfs even works on Solaris) I would think that persistent share selection should be saved in the registry and accessed through smbclient rather than smbfs, then smb shares would work for all OSs supporting Samba, not just those supporting smbfs. IMHO There are already too many linux centrix assumptions in wine, please, lets not add any more . Bob

3 2

Getting Started
by Oliver Sampson Dec. 11, 2001

Dec. 11, 2001

Howdy, I'm trying to get started with Wine development, and I figured the best way would be to CVS the code and install it. I CVSed the code, configured, did a 'make depend', 'make', and a 'make install'. When I try to run wine, I get a message that libntdll.so wasn't found. So I found it in /usr/lib/libntdll.so. is there something in the initial setup config that didn't work correctly? FWIW, I can rpm the wine-cvs-unstripped rpm just fine, and it works well. (The install process and the program.) Any ideas how to get this working from my cvs directory? Thanks, ==================================================== Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

5 15

Re: OSS fixes
by Gerard Patel Dec. 10, 2001

Dec. 10, 2001

At 09:23 PM 10/12/2001 +0100, you wrote: >could the people who had issues with the latest OSS patch(es) test >if this one fixes all their issues ? I have only one serious issue, and it's fixed by your patch. While you are at it, I noticed a few spelling errors : 'can be do better' at line 672 'unable read mixer' at line 1250 'unable set mixer' at line 1282 'we have the 0 the block by hand' at line 1394 'we can have at least a 4 longs to store.' at line 1401, Gerard

1 0

RE: Dialog autoradio buttons are initially not tabstops
by Medland, Bill Dec. 10, 2001

Dec. 10, 2001

No. It IS down in the button.c; I'll do it in a second. > -----Original Message----- > From: Medland, Bill [mailto:Bill.Medland(a)accpac.com] > Sent: Monday, December 10, 2001 1:57 PM > To: Wine patches (E-mail) > Subject: Dialog autoradio buttons are initially not tabstops > > > <<diff33.txt>> >

1 0