February 2008 - Wine-Devel - list.winehq.org

Re: slc: Initial stub DLL (try 2)

by Alistair Leslie-Hughes

> "Kornél Pál" <kornelpal(a)gmail.com> wrote in message > news:002901c87333$092364e0$5747ee55(a)kornelpal.hu... > slc.dll is part of Windows Vista, and seems to be responsible for > activation, key validation, maybe genuine validation and probably trial > time > limit. >I don't think that this is required by Wine unless the DLL has some >publically documented API. The public API for this dllcan be found in slpublic.h Best Regards Alistair Leslie-Hughes

Feb. 19, 2008

Re: slc: Initial stub DLL (try 2)

by Alistair Leslie-Hughes

"Robert Shearman" <rob(a)codeweavers.com> wrote in message news:47BB0C1F.7060803(a)codeweavers.com... > Alistair Leslie-Hughes wrote: >> slc: Initial stub dll > > I'm not sure we want to go down the path of implementing the functions > in this DLL. Furthermore, this file isn't present on an XP SP2 > installation. This dll is present for vista and Windows Server 2008. > > Can you give some information as to why this is needed and how the > application depends on this DLL? The standard Solitaire under Vista requires this dll, and uses function SLGetWindowsInformationDWORD (Stubbing this function was going to be my next patch). Best Regards Alistair Leslie-Hughes

Feb. 19, 2008

Re: slc: Initial stub DLL (try 2)

by Kornél Pál

slc.dll is part of Windows Vista, and seems to be responsible for activation, key validation, maybe genuine validation and probably trial time limit. I don't think that this is required by Wine unless the DLL has some publically documented API. Kornél ----- Original Message ----- From: "Robert Shearman" <rob(a)codeweavers.com> To: <leslie_alistair(a)hotmail.com> Cc: <wine-devel(a)winehq.org> Sent: Tuesday, February 19, 2008 6:04 PM Subject: Re: slc: Initial stub DLL (try 2) > Alistair Leslie-Hughes wrote: >> slc: Initial stub dll > > I'm not sure we want to go down the path of implementing the functions > in this DLL. Furthermore, this file isn't present on an XP SP2 > installation. > > Can you give some information as to why this is needed and how the > application depends on this DLL? > > -- > Rob Shearman > > >

Feb. 19, 2008

re: Do we need a forum?

by Dan Kegel

Steven Edwards wrote: > My thoughts, as well as > Tom's was that by creating a "blessed" location, all third parties as > well as vendors that develop Wine related products could say "if you > want to discuss using a vendor provided Wine product in a > non-supported manner all are advised to go here and share information" Yes, of course, it would be nice if there were One True Place to go, but the closest we're ever going to get is essentially the status quo, where the wine-users mailing list is the place of record for user support, the appdb is the place of record for looking for tips for a particular app, and all the other areas are secondary. We can improve slightly on this by linking to other popular wine forums as they pop up, emphasizing all the while that they are secondary. - Dan

Feb. 19, 2008

Re: slc: Initial stub DLL (try 2)

by Robert Shearman

Alistair Leslie-Hughes wrote: > slc: Initial stub dll I'm not sure we want to go down the path of implementing the functions in this DLL. Furthermore, this file isn't present on an XP SP2 installation. Can you give some information as to why this is needed and how the application depends on this DLL? -- Rob Shearman

Feb. 19, 2008

Re: ddraw: Assign to structs instead of using memcpy

by Stefan Dösinger

Am Sonntag, 17. Februar 2008 01:38:50 schrieb Andrew Talbot: > And I presume that if the underlying struct tags > are different between two similar types, then the compiler would warn of > type incompatibility if such an assignment were attempted. Not quite. You can have a DDSURFACEDESC2 *ddsd pointer, with ddsd->dwSize == sizeof(DDSURFACEDESC). Then you have in binary a DDSURFACEDESC *, not a DDSURFACEDESC2 *. The compiler won't see that, since the type is determined at runtime. (Don't blame me, Microsoft invented that)

Feb. 19, 2008

Re: Make.rules.in: Pass the --nounistd flag to flex since unistd.h is a header that might not be present on all systems.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > I disagree. The global make rules, among other things, should enforce > policies whether this be telling the C compiler to error on certain > non-portable constructs like declarations after statements or telling > flex not to output code that includes headers that might not be > present, like unistd.h. Yes, but policies about headers don't always apply globally. Some parts of the project, like the server, are Unix-only, and using unistd.h in those parts is perfectly legitimate. -- Alexandre Julliard julliard(a)winehq.org

Feb. 19, 2008

Re: Pass parms through to PdhLookupPerfIndexByNameW for checking

by Dmitry Timoshkov

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > + if (machine && !(machineW = pdh_strdup_aw( machine ))) return PDH_MEMORY_ALLOCATION_FAILURE; > > - if (machine) > - { > - FIXME("remote machine not supported\n"); > - return PDH_CSTATUS_NO_MACHINE; > - } > if (!(nameW = pdh_strdup_aw( name ))) > return PDH_MEMORY_ALLOCATION_FAILURE; > > ret = PdhLookupPerfIndexByNameW( NULL, nameW, index ); You forgot to actually pass machineW to PdhLookupPerfIndexByNameW. -- Dmitry.

Feb. 19, 2008

Re: Make.rules.in: Pass the --nounistd flag to flex since unistd.h is a header that might not be present on all systems.

by Robert Shearman

Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > >> The point is that all of the files need it. Only tools/widl/parser.l >> needs to include unistd.h and it already does so manually. >> > > Then you should put the option in all the files. That sort of thing > doesn't belong in the global make rules. I disagree. The global make rules, among other things, should enforce policies whether this be telling the C compiler to error on certain non-portable constructs like declarations after statements or telling flex not to output code that includes headers that might not be present, like unistd.h. However, I've sent a patch that turns the option on individually for each file so that you can choose which route to take. -- Rob Shearman

Feb. 19, 2008

Re: Make.rules.in: Pass the --nounistd flag to flex since unistd.h is a header that might not be present on all systems.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > The point is that all of the files need it. Only tools/widl/parser.l > needs to include unistd.h and it already does so manually. Then you should put the option in all the files. That sort of thing doesn't belong in the global make rules. -- Alexandre Julliard julliard(a)winehq.org

Feb. 19, 2008