wine-devel October 2004

wine-devel@winehq.org

115 participants
272 discussions

Re: WSCEnumProtocols, was _SHExpandEnvironmentStrings() should return input string if no % found to expand?
by Rolf Kalbermatter 25 Oct '04

25 Oct '04

James Hawkins wrote: >> No, it will work. The cast probably there because the original author >> didn't want to write two functions. Instead he added a bool to the >> internal function that specifies whether the buffer is unicode or >> not. The cast is then needed to keep the compiler happy. > >The fact that the structures have a string in them is one issue that >you're ignoring. You can't make a cast from a unicode to an ansi >string just by casting. You have to call RtlMultiByteToWideChar to >convert it. This isn't a problem here since the helper function which is called has as last parameter a boolean telling it if the structure should be interpreted as the ANSI or Unicode version. While this may look asthetically wrong it is technically correct as long as the strings are embedded as pointers instead of inlined. There is a string inlined in the structure but it is at the end of the structure only so even there it is not necessarily a problem although the internal helper function needs to take extra care to get it right and in that it might be a better idea to just implement the Unicode version and convert for the ANSI one. >The major problem that you're ignoring is that you're >casting from one kind of struct to another, and they aren't the same. >The cast wont work. You would have to individually pull out the >relevant fields into a new PROTOCOL_INFO struct like I said in the >last post. If by original author I'm assuming you're talking about >the author of the spec file. In which case, there was only one >function in the spec file to begin with, because all functions only >have one in the spec file originally until someone stubs out that >function and finds out that it needs and A and a W...which is why I >didn't want my patch committed. This would be indeed the real problem if it was the case, but (from my SDK headers): int WSPAPI WSCEnumProtocols(IN LPINT lpiProtocols, OUT LPWSAPROTOCOL_INFOW lpProtocolBuffer, IN OUT LPDWORD lpdwBufferLength, OUT LPINT lpErrno); int WSAAPI WSAEnumProtocolsA(IN LPINT lpiProtocols, OUT LPWSAPROTOCOL_INFOA lpProtocolBuffer, IN OUT LPDWORD lpdwBufferLength); There is no ANSI version defined for the WSC function. This means either of two things: It is on all versions of Windows Unicode or it is very much like many Shell functions really ANSI on non NT systems while NT systems implement it as Unicode. Seeing that MSDN claims this to be supported on even Win95 I tend to believe the second one but only tests will show. The fact that modern SDK headers don't contain any indication of ANSI support means nothing as Microsoft has removed support for developing Win9x application from many SDK headers and MSDN. The problem seems to me rather that even the WSAEnumProtocols function casts the WSAPROTOCOL_INFOA/W structure pointer into PROTOCOL_INFOA and since they have indeed a completely different layout we are basically causing big trouble. I doubt that WSAEnumProtocols ever did work properly unless MS has at some point changed the second parameter of the function. Once this has been fixed, the implementation as suggested by Hans should actually work fine. Rolf Kalbermatter

1 0

Re: Fully Revised Wine User Guide Introduction
by Francois Gouget 25 Oct '04

25 Oct '04

On Mon, 25 Oct 2004, Francois Gouget wrote: > On Fri, 22 Oct 2004, Scott Ritchie wrote: > [...] >> Unlike my previous patch, this one should be properly formatted, > > It still had very long lines. So here's a line-wrapped version of the patch: > > Changelog: > > * documentation/introduction.sgml > > Scott Ritchie <scott(a)open-vote.org> > Revised Wine User Guide Introduction Sorry for this. I was without Internet access for a while and our emails crossed. Hmmm, I wonder... does this double the chances of the patch getting accepted?<g> -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

1 0

d3drs_multisampleantialias: check for it?
by Devils Cry 24 Oct '04

24 Oct '04

Hi again... :/ ^^ So im now moving for the multisampleantialias call... ive found the gl_multisample_arb function to be matching, so far, so good. Now while googling for it i only found code examples which check whether multisampling is supported before it is activated. My question: do i need this? I found no other call in the d3d8lib which asks for its extension the way i found it (http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=46). Theres also another problem: the multisampling has to be turned off after its done, turned on again if something is drawn and after this turned off again (at least i understood it that way...). Is it enough to simply turn it on? And if not, how should i do this??? Thx in advance Nikolas

2 1

Re: _SHExpandEnvironmentStrings() should return input string if no % found to expand?
by Hans Leidekker 24 Oct '04

24 Oct '04

On Sunday 24 October 2004 01:35, James Hawkins wrote: > The reason why I said to ignore this patch is because there has to be > both an A and a W version of it. I'm pretty sure that this cast: No, I believe this is an exception. I assume that the spec file is correct in that there are no A and W versions of this function in shell32, it's just WSCEnumProtocols(). > (PROTOCOL_INFOA *)buffer > from a LPWSAPROTOCOL_INFOW structure isn't going to work. No, it will work. The cast probably there because the original author didn't want to write two functions. Instead he added a bool to the internal function that specifies whether the buffer is unicode or not. The cast is then needed to keep the compiler happy. > WSAPROTOCOL_INFO and PROTOCOL_INFO don't even have the same fields: No, but WSCEnumProtocols() wants WSAPROTOCOL_INFOW structures, just like WSAEnumProtocolsW(). Quote from MSDN: int WSCEnumProtocols( LPINT lpiProtocols, LPWSAPROTOCOL_INFOW lpProtocolBuffer, LPDWORD lpdwBufferLength, LPINT lpErrno ); -Hans

2 1

Re: Patch : dlls/ntdll, dlls/kernel, dlls/user
by Dmitry Timoshkov 24 Oct '04

24 Oct '04

"Peter Quiring" <pquiring(a)hotmail.com> wrote: > I've added some stub's for 39 functions that I've come accross > while using Wine. I often try to use native DLLs as much as > possible but can't always unless these 39 stubs are added. > I've also attached a txt file listing the functions I've added. That's usually considered a bad idea to add stubs to .spec files if there is no real need for that. And that's really the case, since: 1. there is no real difference between a missing API and a stubbed in the .spec file one 2. using native dlls "as much as possible" is not encouraged in Wine at all, and especially for Wine *development* 3. you can't use native versions of ntdll, kernel32 and user32 in any case 4. Adding stubs for NT/win2k/win2k3 only APIs will make the things much worse for some apps, because they could start think that they are running under those platforms by checking presence of that APIs -- Dmitry.

1 0

OpenGL Extension Viewer
by Devils Cry 24 Oct '04

24 Oct '04

Hi there everybody! While browsing the web i found a little tool which i expect to be quite helpfull: the opengl extension viewer. Though its written for windows, it runs perfectly on wine and allows people working on d3d and so on to have a quick overview of the functions. With kind regards Nikolas

2 2

DLL search order
by Kenneth Porter 24 Oct '04

24 Oct '04

I know this has to be a FAQ, but I'm not finding it. I want to test a custom version of kernel32.dll without bothering other wine users on the box. What do I need to do to make an app search the local directory for it instead of using the one in /usr/lib/wine?

2 1

Re: Bug in recent shellpath.c change, with fix?
by Juan Lang 24 Oct '04

24 Oct '04

This certainly is a bug. Your patch fixes it, but I think it might be better (there's an unnecessary copy left, and I wonder whether _SHExpandEnvironmentStrings should be called at all). I'll submit what I think is a better patch shortly. Thanks, --Juan --- Dan Kegel <dank(a)kegel.com> wrote: > Hey, I think I found a bug in your recent patch. > Could you have a look and maybe approve my > patch or submit the real fix? > The app I was tryiing to install was Google Desktop > Search, > which is a free download from > http://desktop.google.com > > Thanks, > Dan > > -------- Original Message -------- > Subject: _SHExpandEnvironmentStrings() should return > input string if no % found to expand? __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

1 0

bug 2170: can't install Office '97
by Dan Kegel 24 Oct '04

24 Oct '04

http://bugs.winehq.org/show_bug.cgi?id=2170 This bug is marked 'closed', but it's still happening for me with today's CVS. Anyone know what's up with this? Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 2

RE: The wine user guide: an idea
by Scott Ritchie 24 Oct '04

24 Oct '04

Thanks for you comment. I've taken up the task of rewriting alot of the User Guide at the moment, and revising the Using Wine section may be the most important next step after the rewrite of the Intro. > What I would like is a section with common use cases of wine and > step-by-step instructions for each of them. It shouldn't be long - it > should be mostly links to other parts of the user guide. I think of > something like that... Not a bad idea, I'll certainly keep it in mind as I go through the other chapters. -Scott Ritchie

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
28
Older →

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 October 2004