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

Re: RegOverridePredefKey stub

by Robert Shearman

Jens Nestler wrote: > /****************************************************************************** > + * RegOverridePredefKey [ADVAPI32.@] > + * > + * Maps a predefined registry key to the specified registry key. > + * > + * PARAMS > + * hKey [I] A handle to one of the following predefined keys: > + * HKEY_CLASSES_ROOT > + * HKEY_CURRENT_CONFIG > + * HKEY_CURRENT_USER > + * HKEY_LOCAL_MACHINE > + * HKEY_PERFORMANCE_DATA > + * HKEY_USERS > + * hNewHKey [I] A handle to an open registry key. This handle is returned by the RegCreateKeyEx or RegOpenKeyEx function. > + * It cannot be one of the predefined keys. The function maps hKey to refer to the hNewHKey key. > + * This affects only the calling process. > + * If hNewHKey is NULL, the function restores the default mapping of the predefined key. > + * > + * RETURNS > + * Success: ERROR_SUCCESS > + * Failure: the return value is a nonzero error code defined in Winerror.h > + * > + * NOTES > + * The RegOverridePredefKey function is intended for software installation programs. > + * It allows them to remap a predefined key, load a DLL component that will be installed on the system, > + * call an entry point in the DLL, and examine the changes to the registry that the component attempted to make. > + * The installation program can then write those changes to the locations intended by the DLL, > + * or make changes to the data before writing it We appreciate your patch, but you're not allowed to copy information from MSDN into the Wine source like this. -- Rob Shearman

Jan. 27, 2008

Re: RegOverridePredefKey stub

by Peter Oberndorfer

On Sonntag 27 Januar 2008, Jens Nestler wrote: > Hello all, > > I'm a Windows software developer and I'm trying to execute an application > under the wine environment. > Now I have a problem introduced with wine 0.9.49. > > I use the function RegOverridePredefKey from the advapi32.dll. > In wine 0.9.49 a stub entry for this function was created, but the > implementation is missing. > To hold my code running, I need any implememtation for this function. > Please apply the attached patch for a stub implementation. > > Thank you > Jens > The documentation for the function was copied from MSDN. So this patch can not be accepted. If you don't write the documentation yourself submit the patch without documentation. It might be useful for the future to add the function prototype to winreg.h. style problem: Indention of the new code looks different than the surrounding code. Greetings Peter

Jan. 27, 2008

Re: Vacation

by Detlef Riekenberg

On Sa, 2008-01-26 at 10:17 +0100, Alexandre Julliard wrote: > I'm off skiing for a week... Have fun and be careful with your legs. -- By by ... Detlef

Jan. 27, 2008

Re: your winhttp work

by Hans Leidekker

On Sunday 27 January 2008 15:11:23 Hans Leidekker wrote: Try this one, I forgot to diff one required file in the previous version. Also, run configure after applying. -Hans

Jan. 27, 2008

Re: your winhttp work

by Hans Leidekker

On Sunday 27 January 2008 06:42:45 EA Durbin wrote: [ I decided to CC wine-devel since you're the second person to ask ] > You had completed some work on winhttp and provided a snapshot in bug 9200. > Has this been sent to wine-patches yet? I was going to tinker with it a bit > to see if I could get an app working and wondered if you had anything more > up to date or if this had been merged into git yet? If you've already got > a solution I don't want to reinvent the wheel. Here's a rediffed version of my unfinished winhttp patch. I wrote it primarily to explore the option of implementing winhttp on top of wininet. Basically we are faced with a choice between this option, which requires a Wine-only extension to wininet to implement winhttp style callbacks, and duplicating wininet code. I think layering can be done in a relatively clean way by making wininet handle the superset of wininet and winhttp callbacks and adding callback filtering as required by winhttp. Old wininet behavior can then be obtained by an implicit filter on the wininet subset of callbacks. If time permits I'll write a comprehensive test suite for winhttp which should help us make an informed decision. -Hans

Jan. 27, 2008

RegOverridePredefKey stub

by Jens Nestler

Hello all, I'm a Windows software developer and I'm trying to execute an application under the wine environment. Now I have a problem introduced with wine 0.9.49. I use the function RegOverridePredefKey from the advapi32.dll. In wine 0.9.49 a stub entry for this function was created, but the implementation is missing. To hold my code running, I need any implememtation for this function. Please apply the attached patch for a stub implementation. Thank you Jens

Jan. 27, 2008

Re: Wine Test Shell - timeouts during test runs too short?

by Stefan Dösinger

Am Sonntag, 27. Januar 2008 13:49:36 schrieb Reece Dunn: > On 27/01/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > Am Sonntag, 27. Januar 2008 12:18:12 schrieb Reece Dunn: > > > Hi, > > > > > > When running the Wine Test Shell to run the tests as part of > > > http://test.winehq.org/, there are several timeouts in different > > > places. > > > > > > These may be valid timeouts, but on my Vista test machine ddraw:d3d > > > and msi:install generate the timeout message box part way through the > > > test run, even though they continue and complete. Those tests are just > > > slow. > > > > If you don't have a 3D accelerator(e.g. running in a VM), the ddraw d3d > > and visual tests will attempt to use the RGB software rendering device, > > which *is* slow. Running the visual test takes a few minutes instead of a > > few secounds. > > These are running on a decent spec Vista machine that is not running > through VM. > > I don't know if 3D acceleration is on; it looks like it is off (the > colour gradiant sweep tests take a while to flick through). This is > strange though, because it is the default configuration for the Vista > machine and games like Oblivion and Command and Conquer 3 play fine > (but those are using D3D, not DDraw). The ddraw "d3d" and "visual" tests use d3d - earliear d3d versions(d3d <= 7) are a subset of ddraw.dll . It could be that your driver doesn't like something about the way the test initializes d3d, so the test falls back to the software renderer.

Jan. 27, 2008

Re: Wine Test Shell - timeouts during test runs too short?

by Reece Dunn

On 27/01/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am Sonntag, 27. Januar 2008 12:18:12 schrieb Reece Dunn: > > Hi, > > > > When running the Wine Test Shell to run the tests as part of > > http://test.winehq.org/, there are several timeouts in different > > places. > > > > These may be valid timeouts, but on my Vista test machine ddraw:d3d > > and msi:install generate the timeout message box part way through the > > test run, even though they continue and complete. Those tests are just > > slow. > If you don't have a 3D accelerator(e.g. running in a VM), the ddraw d3d and > visual tests will attempt to use the RGB software rendering device, which > *is* slow. Running the visual test takes a few minutes instead of a few > secounds. These are running on a decent spec Vista machine that is not running through VM. I don't know if 3D acceleration is on; it looks like it is off (the colour gradiant sweep tests take a while to flick through). This is strange though, because it is the default configuration for the Vista machine and games like Oblivion and Command and Conquer 3 play fine (but those are using D3D, not DDraw). Do you know how to turn 3D acceleration on in Vista? That said, Wine Test Shell should accept this as a valid test run and not timeout. - Reece

Jan. 27, 2008

Re: Wine Test Shell - timeouts during test runs too short?

by Stefan Dösinger

Am Sonntag, 27. Januar 2008 12:18:12 schrieb Reece Dunn: > Hi, > > When running the Wine Test Shell to run the tests as part of > http://test.winehq.org/, there are several timeouts in different > places. > > These may be valid timeouts, but on my Vista test machine ddraw:d3d > and msi:install generate the timeout message box part way through the > test run, even though they continue and complete. Those tests are just > slow. If you don't have a 3D accelerator(e.g. running in a VM), the ddraw d3d and visual tests will attempt to use the RGB software rendering device, which *is* slow. Running the visual test takes a few minutes instead of a few secounds. I've considered using the Reference rasterizer, which is even slower, as a fallback for the d3d9 tests, however, running the d3d9 visual tests in the refrast in qemu takes approximately 5 hours, so I dropped the idea. Furthermore the d3d9 refrast has to be installed separately.

Jan. 27, 2008

Re: d3dx8: Implement D3DXCreateTextureFromFile

by Chris Robinson

On Sunday 27 January 2008 12:39:18 am Luis C. Busquets Pérez wrote: > +{ > + FIXME("(void): stub\n"); > + return D3D_OK; > +} You probably shouldn't return okay if you're not implementing the function. It's normal to return D3DERR_NOTIMPLEMENTED (or whatever it is). At the very least you don't want to leave the output parameters untouched.

Jan. 27, 2008