April 2003 - Wine-Devel - list.winehq.org

CVS Character set (was: lostwages/templates/en documentation.template)

by Joerg Mayer

I'm noticing that during the last few weeks several mails have been sent to the cvs list that use 8-bit characters but do not specifiy an encoding in the mail header. Would it be possible to either add one (depends on whether cvs does recognize the encoding type) or remove those extra characters? On Tue, Apr 22, 2003 at 01:28:01PM -0500, Jeremy Newman wrote: > Log message: > ChangeLog > Â Â Â Dimitrie O. Paun <dpaun(a)rogers.com> > Â Â Â Remove references to no longer existing document. > > Patch: http://cvs.winehq.com/patch.py?id=7945 Thanks Jörg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

April 23, 2003

Re: System Shock 2 Working (Almost)

by Lionel Ulmer

> The problem is the 2D overlay stuff - the HUD, inventory, etc. are all > missing which makes it unplayable. I saw on some other forum that it > had been added to either wine or winex... anyone have any ideas? This is a known problem on WineHQ. The support for this is planned but nothing has acually been done yet (it's something very annoying to do :-) ). If I find time in the next weeks to rework on D3D, I may finally add this (it's THE one feature that is missing to make a lot of old games work properly). > Another problem is that ss2 no longer seems to work with the newer wine > builds (20030327 at least) it just displays a message that says video > card not supported. Ah ? I will have to test it on my box for regressions then :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

April 23, 2003

RE: FoxPro & Wine :)

by Patrik Stridvall

> On Wed, 23 Apr 2003, Patrik Stridvall wrote: > > > While, I suppose, you can have a license the regulates this to, even > > if the LGPL doesn't, the problem is the doctrine of first sale means > > anybody that it can be distributed to can resell (or give) that copy > > to anybody that can't be distributed directly to. > > And that is in no contradiction with the (L)GPL, as it does not > restrict to whom we can redistribute, but rather under what > conditions a derived work can be distributed. But that is exactly what I said above. Should I interpret it as you agree? But please note that the last step meantioned above is not distribution, it is sale (or gift) on an invidual copy allowed by first sale. And as I said earlier, it makes the conditions for redistribution is rather meaningless, since anybody regardless or willingless or abillity to follow the redistribution conditional can indirectly for all intent and purposed have distributed to anybody your work, while seperately distributing anything that uses, modififies, adapts etc your work for his purposes on the end users computer. The situation for the Microsoft Visual FoxPro (MVFP) runtime is almost identical since you analagous to above can for all intent and purpose have it distributed seperately. Summary: Microsoft released the MVFP runtime for all intent an purpose for free since they thought that charging for it would be bad for their purposes. Some people release some work under the LGPL because they thought charging for it would be bad for their purposes... Nobody can both have the cake and eat it. Microsoft can't, I can't, you can't... And futher more, again, Copyright law is designed that way on purpose, not by accident.

April 23, 2003

Re: odd message: Hmm have I answered my own question

by Robert Lunnon

On Wednesday 23 April 2003 15:41, Robert Lunnon wrote: > I am debugging a shareware game my kids often play called little fighter 2 > (It deadlocks after creating the third thread) But before I get to the > deadloack I noticed I get the following two messages from wine, > > > err:module:BUILTIN_LoadModule loaded .so but dll wineaudioio.drv still not > found > err:module:BUILTIN_LoadModule loaded .so but dll joystick.drv still not > found > > from what I can see wine is loading the two shared libraries ok and > __wine_dll_register gets properly called EG > > Breakpoint 2, __wine_dll_register (header=0xdcb82480, filename=0xdcb721f6 > "wineaudioio.drv") at loader.c:327 > > Yet find_dll_descr( dllname ) in builtin.c fails to find the name ?? > > > Any hints would be appreciated Seems there is a dll register function for 32 bit and 16 bit dlls and for some reason wine is trying to load a 16 bit dll rather than a 32 bit one. Since these dlls don't exist for 16 bits it fails. New question then, does this mean that the application I am running is a 16 bit one or does it mean something else ?

April 23, 2003

odd message

by Robert Lunnon

I am debugging a shareware game my kids often play called little fighter 2 (It deadlocks after creating the third thread) But before I get to the deadloack I noticed I get the following two messages from wine, err:module:BUILTIN_LoadModule loaded .so but dll wineaudioio.drv still not found err:module:BUILTIN_LoadModule loaded .so but dll joystick.drv still not found from what I can see wine is loading the two shared libraries ok and __wine_dll_register gets properly called EG Breakpoint 2, __wine_dll_register (header=0xdcb82480, filename=0xdcb721f6 "wineaudioio.drv") at loader.c:327 Yet find_dll_descr( dllname ) in builtin.c fails to find the name ?? Any hints would be appreciated

April 23, 2003

Re: oleaut32 patch

by Gregory M. Turner

On Tuesday 22 April 2003 10:39 am, Ove Kaaven wrote: > tir, 22.04.2003 kl. 06.02 skrev Alexandre Julliard: > > Ove Kaaven <ovek(a)arcticnet.no> writes: > > > The oaidl_p.c is almost unmodified MIDL output generated from Wine's > > > oaidl.idl (I only had to add an #undef __WINE__ at the top to get all > > > the Winelib definitions, perhaps this isn't needed under Wine anymore), > > > so it shouldn't be hard to maintain, and Alexandre once said MIDL > > > output is acceptable as a stopgap solution. I don't know if proper > > > InstallShield repaint support calls for stopgaps, though. > > > > One problem is that this code causes hundreds of warnings, and I don't > > think that's acceptable (it also fails to link but that could be fixed > > by adding a few stubs). Couldn't those be fixed by tweaking our headers a bit? I seem to recall being able to imagine ironing those out... well, I guess I need to reapply this patch and go over it to give a meaningful opinion. > Hmm, the stub functions in usrmarshal.c was enough for me when I tried. > What stubs are missing? I forget, again, but I experienced this too against cvs as of a couple of days ago. > And yeah, I know it causes a lot of warnings, but I thought that it > might be a reasonable tradeoff since it won't stay there forever. > > > We could fix the warnings manually but that > > will cause obvious maintenance problems. How far are we from being > > able to generate that with widl? > > Not all that close I'm afraid. I think it might be easiest to make widl > emit stubless (rpcrt4-interpreted bytecode) marshallers than the > old-fashioned inline marshallers Indeed, it probably would... I gravitate to the depreciated /Oi versions because I imagine they will provide a nice guideline as to how to implement the stubless versions... but I get the impression you have delved into this more deeply than I, Ove, so I'm happy to defer to your judgement (not that I'm the gatekeeper here anyhow ;) ) Will try to take a look this weekend and see if I have any coherent thoughts on the subject ;) > (hardcoded function tables, which look > like a nightmare to generate) > but wine's dlls/rpcrt4/ndr_stubless.c is > still just a stub... > so the bytecode interpreter would have to be > implemented also (but of course that has to be done eventually anyway, > stubless proxies are better according to MS, so many apps will use > them). It'll probably take a few weeks for me at least, since the stuff > I do have works, and thus its priority is lower... but I can try if > you're willing to wait a bit. -- gmt "Democracy is the theory that holds that the common people know what they want, and deserve to get it good and hard." HL Mencken

April 23, 2003

Re: Wintab32 dll devlopment

by Mike McCormack

Hi Robert, Aric did the work on this for Crossover Office, and as usual it will be merged in to the WineHQ CVS within the next couple of weeks. He can probably send you what he's done before then. Mike Robert North wrote: > I have just posted a status update on my wintab32 development > to the following wine bug. > > http://bugs.winehq.com/show_bug.cgi?id=1160 > > And following on from that update there are a number of questions I need > answered to guide my further development: > > 1. Cross over office and tablets. > I heard somewhere that Crossover office had a tablet implementation. > Does anyone know about this, and who to contact to find out more? > If they've got an implementation of wintab, I wonder if it's worth > continuing the development. > > 2. When to post patches > I could start producing patches quite soon. > For instance, I could post patches when the WTInfo function is working. > Or, I could wait till the whole system is working fully with at least > one app? > > 3. Size of the patches. > Is it better to break patches into small (valid compile, but > non-functioning) chunks, or to release large functioning patches? > > 4. Config files > Wintab will need some config data. > I assume the best place to put this is in the ~/.wine/config file, > within a registry key named "wintab"? > > 5. Development notes. > I have some notes on the design that other developers will probably find > useful. > Where in the wine project should they go? > There seems to be no place for rough notes. > > 6. x11drv integration. > Currently the code is implemented to connect to X11 in a similar way to > directX. No additional code is placed in the x11drv dll. > This X11 connection should be discarded. To this end I have a number of > functions that I'd like to place in x11drv dll. > The question is: > Should I put them into x11drv before releasing any patches, or maintain > the directX style connection in the initial wine patches? > > > 7. Cross-platform abilities > Is there any need to think about allowing alternatives to > XInput to plug into the wintab dll? > > Yeah, I know that's a lot of questions, > But I hope you guys can give me some guidance. > > Bye > -Rob. >

April 23, 2003

Re: rpc exception

by Gregory M. Turner

On Monday 21 April 2003 10:55 pm, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > needed. I don't think any other C compiler supports local functions > (even g++ doesn't AFAIK), so there won't be much hope of ever making > it work. gosh, that sucks. > Of course we could decide to stop supporting other compilers, > but I don't think everybody would be happy with that. me neither. I guess this is kind of crazy, since they still aren't portable, but my goal in writing that code was to violate only one rule: no nested functions. of course, when I eventually used __label__ and "auto" I think I broke even those rules, making it totally gcc specific. also, Perhaps you will all emit a collective groan (or simply pity me for my inability to learn from history), but given __LINE__, and the usual macro-mashing-together tricks, I see no reason to assume that there is insufficient expressive power to achieve the proper semantics... I suspect a failure of imagination on my part. I'd like to take another look at this with a mind to reimplement all flow-of-control using goto instead of loops and nested functions. I would hate to see wine scrap such a long-standing tradition as code portability just on account of some exception handling macros that are grossly inefficient wrappers anyhow... > > Also, not accepting code into Wine that depend on exception is one thing, > > but what about Winelib? We can have the exception code commented out if > > __WINESRC__ is defined, but at least lets get it in if it works, it will > > plug a big Winelib hole. > > Sure, we can make the macros available for Winelib. I hate to be the weak link in the chain here... But I'd at least like to take this to the drawing board once more before I throw in the towel. I have some time on Thursday, so I will get back to the list on Friday with either a patch or a white flag. -- gmt "Democracy is the theory that holds that the common people know what they want, and deserve to get it good and hard." HL Mencken

April 23, 2003

Re: Winelib CoolPlayer port

by Dimitrie O. Paun

On April 22, 2003 04:17 pm, Vincent Béron wrote: > Next is the actual Winelib stuff, which is very small. Just a few lines indeed! > The first part is an MFC header (thankfully, nothing else seems to be > needed from MFC). This is the: --- CoolPlayerCVS-20030421-2130-orig/afxres.h 1969-12-31 19:00:00.000000000 -0500 +++ CoolPlayerCVS-20030421-2130/afxres.h 2003-04-21 21:51:07.000000000 -0400 @@ -0,0 +1 @@ +#include "winres.h" right? > The second part is the only problematic thing. The current div > implementation works fine for binary compatibility on i386, but doesn't > work well for source level compatibility on the same platform. I would prefer if we fix this one in Wine, so we don't have to submit this part for inclusion in the CoolPlayer code. This would be _our_ benefit for the port, no? :) -- Dimi.

April 23, 2003

Re: Fix trackbar size

by Dimitrie O. Paun

On April 22, 2003 05:55 pm, Maxime Bellengé wrote: > + * Copyright 2003 Maxime Belleng�<maxime.bellenge(a)laposte.net> > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -231,13 +232,13 @@ > channel->top = lpRect.top + offsetedge; > channel->bottom = lpRect.bottom - offsetedge; > channel->left = lpRect.left + offsetthumb; > - if (dwStyle & (TBS_BOTH | TBS_LEFT)) channel->left += 8; > + if (dwStyle & (TBS_BOTH | TBS_LEFT)) channel->left += > (lpRect.right-lpRect.left-offsetthumb-cyChannel)/2; Unfortunately, the patch seems to be wrapped, and your name did not show up properly in the copyright notice. -- Dimi.

April 23, 2003