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

Re: some rasapi32 stubs

by Marcus Meissner

On Tue, Jul 10, 2001 at 10:10:17PM +1000, Mike McCormack wrote: > > ChangeLog: > * dlls/rasapi32/rasapi.c, dlls/rasapi32/rasapi32.spec > Stub some rasapi functions. If you know arguments are strings you can use 'str' instead of 'ptr' in the .spec file, and relay debugging will print strings ;) Also you can use the return value of debugstr_a(a) for string output. Ciao, Marcus

July 10, 2001

Joysiick under Wine

by David Hagood

I've seen a couple of messages about getting USB joysticks working under Wine, but do regular (i.e. gameport) sticks work? I've confirmed that my stick is being read by Linux, and that it is reporting events correctly. Now, how do I get Wine to pass them along? I've confirmed: 1) that I have read/write permissions to /dev/js0 2) that Wine tries to read /dev/js0 3) that Wine indeed does read from /dev/js0, but that 4) Wine shortly thereafter closes /dev/js0, never to read it again. Do I need to have the X Window system joystick driver loaded? Or do I need to add something to the system.ini or .wine/config files. This is a Windowless install, under RH6.1, with 2.4.6, and a CVS pull of Wine from a few days ago. I'm trying to get HalfLife running under Wine. I have the GL working, I have sound working, but I am one of those strange fellows that likes to move with a stick, and look with a mouse. Are there any Windows/Wine tools that I can run to try to troubleshoot this?

July 10, 2001

Re: PATCH: internetgetconnectionstate

by Gerard Patel

At 11:37 PM 09/07/2001 +0200, you (Marcus Meissner) wrote: >Hi, > >QuickTimePlayer 5 is using InternetGetConnectedState to check whether to >download its 'homepage'. > >Just say we are connected, and on a LAN. > >Ciao, Marcus > >Changelog: > Have InternetGetConnectedState always return 'LAN connection'. Theoretically this could cause trouble when used with a computer having no connection to the Internet, as an app could think it can connect, try to do it, fail and terminate or display annoying messages. It's not really a strong objection, as most decent computers are connected to the Internet these days, but maybe a config option could be better ? Just a thought. Gerard

July 10, 2001

Re: wv{sn,ns}printf[AW]

by Alexandre Julliard

Peter Hunnisett <hunnise(a)yahoo.com> writes: > 2) Can wvnsprintf be moved from user32 into shlwapi? This would cause > user32 to have to import shlwapi (because wsprintfA and friends use it > in their implementation) and I don't know if that's legal because user32 > seems to only import gdi32 and kernel32. If not, what's the solution? > Reimplement everything in user32 to not use wvnsprintf and move the > implementation over or just keep the existing situation and rename > wvnsprintf to wvnsprintf and forward the shlwapi calls to user32? user32 cannot import shlwapi, since this would create a circular dependency. Since the functions are needed both in user32 and shlwapi, they have to be implemented in user32 and forwarded from shlwapi to user32 (the alternative is to have two complete wsprintf implementations, which is a bit of a pain). I guess you could also rename the user32 ones, but this is not strictly necessary (and the current name has the advantage of following the C library naming of vsnprintf). -- Alexandre Julliard julliard(a)winehq.com

July 9, 2001

wv{sn,ns}printf[AW]

by Peter Hunnisett

Hi, it appears that we have a bit of a hack in the wine code. Presently we export wvsnprintf[AW] from user32. - These two functions do not appear to be in the real user32.dll and the comments in the code seem to back it up. - Windows does have wvnsprintf[AW] (note the transposed "sn") exported from shlwapi.dll So my questions are: 1) Was the user32 a bit of a hack because those routines just weren't noticed or was it because of something from before shlwapi? 2) Can wvnsprintf be moved from user32 into shlwapi? This would cause user32 to have to import shlwapi (because wsprintfA and friends use it in their implementation) and I don't know if that's legal because user32 seems to only import gdi32 and kernel32. If not, what's the solution? Reimplement everything in user32 to not use wvnsprintf and move the implementation over or just keep the existing situation and rename wvnsprintf to wvnsprintf and forward the shlwapi calls to user32? Thanks, Peter hunnise(a)yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

July 9, 2001

Re: Are these the ordinal names?

by Alexandre Julliard

Peter Hunnisett <hunnise(a)yahoo.com> writes: > Howdy, > I have a couple of questions about the following error messages > > err:win32:fixup_imports No implementation for > SHLWAPI.dll.281(wvnsprintfA) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > err:win32:fixup_imports No implementation for > SHLWAPI.dll.282(wvnsprintfW) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > err:win32:fixup_imports No implementation for > SHLWAPI.dll.240(StrRetToStrW) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > > 1) Do these messages mean that 281 is named wvnsprintfA and so on? If > so, why does the SHLWAPI.240 name not seem to jive with the existing > implementation? If a name is specified, the ordinal is only a hint, so it's OK for it to be different. What this means is that in some version of shlwapi StrRetToStrW is at ordinal 240, but it can be at other ordinals in other versions since it is looked up by name. In our builtin version, ordinal 240 is something else (which is fine), and StrRetToStrW is not implemented at all (which is the cause of your problem). You can either implement it, or use the native shlwapi. -- Alexandre Julliard julliard(a)winehq.com

July 8, 2001

Re: sharing windows between processes

by Alexandre Julliard

"Bill Medland" <medbi01(a)accpac.com> writes: > Some time ago I raised the issue of the fact that windows handles cannot be > shared between processes on the same server and was told that it was a > known significant issue. > > Is anyone doing anything about it? Sure, that's the main reason behind all the recent window management and messaging changes. So yes, it is being worked on. -- Alexandre Julliard julliard(a)winehq.com

July 8, 2001

Re: Mouse events

by Alexandre Julliard

Duane Clark <dclark(a)akamail.com> writes: > I assume some problem led to its removal. I regularly try out Myst (the > 32 bit version) as a test, running locally on a 700MHz Athlon, so this > can't be blamed on a slow ethernet connection or slow machine. When > dragging the slide controls in the "planetarium", they used to follow > the mouse just fine. With this patch, if you grab the control, move the > mouse and release it, the control does not keep up with the mouse but > just moves at a moderately slow pace until it reaches the point where > the mouse was released (a few seconds to travel from one end to the > other). At that point everything returns to normal. The new hardware event handling does not yet attempt to merge mouse motion events, so this is probably the reason for the problem. This should be fixed soon. -- Alexandre Julliard julliard(a)winehq.com

July 8, 2001

Re: printing docu

by Duane Clark

Andreas Mohr wrote: > Hi all, > > while trying to configure Wine for printing in order to be able to use > Windows Acrobat Reader instead of Linux acroread which is crashing on certain > PDF files, I remembered that the printing docu is everything but perfect. > > Updated printing docu a bit. > > ... > - <sect3> > <title>Spooling</title> > <para> > Spooling is rather primitive. The [spooler] section of > @@ -82,13 +82,14 @@ > example the following lines > </para> > <screen> > -"LPT1:" = "foo.ps" "LPT2:" = "|lpr" > +"LPT1:" = "foo.ps" > +"LPT2:" = "|lpr" > </screen> > <para> > map <systemitem>LPT1:</systemitem> to file <filename>foo.ps</filename> > and <systemitem>LPT2:</systemitem> to the <command>lpr</command> > - command. If a job is sent to an unlisted port then a file is created > - with that port's name e.g. for <systemitem>LPT3:</systemitem> a file > + command. If a job is sent to an unlisted port, then a file is created > + with that port's name; e.g. for <systemitem>LPT3:</systemitem> a file > called <systemitem>LPT3:</systemitem> would be created. > </para> > <para> While it used to work that way, for me at least, the part about - a job that is sent to an unlisted port will create a file with the port's name - stopped working a few months ago. And I just tested it a few minutes ago and it still does not work (for me). I don't know where the data goes, but it does not appear to be written to a file anywhere. Actually, I think that is probably a good thing. In most cases, the print dialog should have a "Print to file" button. And if there is no way to specify a file name, then the ~/.wine/config entry "FILE:" = "foo.ps" will control where it is written, and in this case it will in fact be correctly written to the indicated file name. Duane

July 8, 2001

Half-Life/CS under WINE

by David Bronaugh

Just as a follow-up to my previous email.. if you want a quick response from me, email me off the list - I'm getting the digest, as I don't want to massively clutter up my inbox. David Bronaugh

July 8, 2001