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
Hi,
So far I have pretty much completed the d3dx9_24 dll. However, while writing the
spec files I faced a few problems which I'd like to have solved befor submitting
the patch:
1. With the d3dx9_31 dll, microsoft removed three functions from the SDK. I'm curious
what to do with them. Should I stub them at the first or last dll they're used in? Also,
How should I handle the forwarding thing then? I'm importing d3dx9_36 in each dll,
but need to import the dll containing the three functions, too (I'm just asking to make
sure there won't be any collisions or conflicts or something).
By the way, the three functions are D3DXCpuOptimizations, GetTargetDescByName
and GetTargetDescByVersion.
2. Another problem is, that many functions changed in there argument list from one version
to the next one.
For example http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c…
Says, that D3DXCreateFont changed the type of the D3DXFONT_DESC member Height
from UINT to INT. I think (but don't know, so I ask) that this could lead to a misbehavior in
some programs, as a UINT has a significant difference in the bit structure to INT. Also,
the Angle parameter in D3DXSHRotateZ was changed from const FLOAT to FLOAT, which
COULD also lead to problems.
3. Also, the MSDN seems to lack the info about D3DXGetTargetDescByName and
D3DXGetTargetDescByVersion. I'd be really gradeful if someone who has an old
version of the DXSDK installed could take a look into the headers and tell me the
argument list.
4. And just to make sure, I attached the d3dx9_24 specfile. Everything but the argument
types should be okay I think, but please tell me if you find any other problems with it,
like typos in function names or something about the forwarding. Also, the two
D3DXGetTargetDescByName/Version functions don't have argument lists yet
as I couldn't find resources about them.
That's it at the moment, I'll reply later to this topic if there appear new problems.
Thanks for any answers, best regards
Tony
Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl.
http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…
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.
The others (such as kernel32:debugger) may be the same - especially
when you get mixed results from different runs.
Because of this, the timeout length should be increased (I would say
at least doubled, to allow the long-running tests to run through).
Another thing... I find it breaks the idea of an automated test run to
have to watch it to OK the timeout messages. I know that UAC and the
shfileop tests bring up interactive dialogs, but these are from within
Windows itself, and will be dealt with by the timeout/test killer part
of the Wine Test Shell.
This would help make it easier for people to run the tests more often.
- Reece
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.
> Find attached some data on d3dx8, d3dx9_xx and d3dx10_xx implementations:
> dll files by d3dx extension:
> d3dx8 1 dll files
> d3dx9_xx 13 dll files
> d3dx10_xx 4 dll files
> [...]
>
Nice work, how did you get the data?
Did you run Dependency Walker on each dll or is there a more practical way?
I'm creating stub dlls at the moment and need to get the parameters for each function
on MSDN which is very time consuming and am looking for a faster way.
However, to add a little more data, my list of the differences between the d3dx9 dlls:
from d3dx9_24 to d3dx9_25:
+ D3DXUVAtlasCreate
+ D3DXUVAtlasPack
+ D3DXUVAtlasPartition
from d3dx9_25 to d3dx9_26:
+ D3DXComputeIMTFromPerTexelSignal
+ D3DXComputeIMTFromPerVertexSignal
+ D3DXComputeIMTFromSignal
+ D3DXComputeIMTFromTexture
from d3dx9_26 to d3dx9_27:
(no changes)
from d3dx9_27 to d3dx9_28:
+ D3DXPreprocessShader
+ D3DXPreprocessShaderFromFileA
+ D3DXPreprocessShaderFromFileW
+ D3DXPreprocessShaderFromResourceA
+ D3DXPreprocessShaderFromResourceW
from d3dx9_28 to d3dx9_30:
(no changes)
from d3dx9_30 to d3dx9_31:
- D3DXCpuOptimizations
- D3DXGetTargetDescByName
- D3DXGetTargetDescByVersion
from d3dx9_31 to d3dx9_32:
+ D3DXSHMultiply2
+ D3DXSHMultiply3
+ D3DXSHMultiply4
+ D3DXSHMultiply5
+ D3DXSHMultiply6
from d3dx9_32 to d3dx9_35:
(no changes)
from d3dx9_35 to d3dx9_36:
+ D3DXCreateFragmentLinkerEx
+ D3DXGetShaderConstantTableEx
They of course match to your reported number of function, great job.
PS: My d3dx9_24 patch is on its way, just need to prove that everything is correct
Find attached some data on d3dx8, d3dx9_xx and d3dx10_xx implementations:
dll files by d3dx extension:
d3dx8 1 dll files
d3dx9_xx 13 dll files
d3dx10_xx 4 dll files
Functions included in each d3dx:
DLL Number of functions
d3dx8 153
d3dx9_24 320
d3dx9_25 323
d3dx9_26 327
d3dx9_27 327
d3dx9_28 332
d3dx9_29 332
d3dx9_30 332
d3dx9_31 329
d3dx9_32 334
d3dx9_33 334
d3dx9_34 334
d3dx9_35 334
d3dx9_36 336
d3dx10_33 177
d3dx10_34 177
d3dx10_35 180
d3dx10_36 180
Total functions for all d3dx implementations: 5162 functions.
Total functions for all d3dx implementations taking into account
repetitions: 425 functions
From these 425 functions:
Functions specific to d3dx8: 15
Functions specific to d3dx9: 165
Functions specific to d3dx10: 71
Functions shared between d3dx8 and d3dx9: 65
Functions shared between d3dx9 and d3dx10: 35
Functions shared between the three implementations: 74
On the other hand, considering individual dlls,
17 functions are only mentioned in one dll
3 functions are mentioned in 2 dlls
68 functions are mentioned in 4 dlls
2 functions are mentioned in 7 dlls
10 functions are mentioned in 9 dlls
5 functions are mentioned in 11 dlls
3 functions are mentioned in 12 dlls
149 functions are mentioned in 13 dlls
65 functions are mentioned in 14 dlls
29 functions are mentioned in 17 dlls
74 functions are mentioned in 18 dlls
The patch that I have just submitted ("gdiplus: fix the bezier arc
path test (on all platforms).") is a simple fix for the failing test
in graphicspath.c. The failure highlights gdiplus behaviour that is
not directly obvious:
If you have a bezier arc:
static path_test_t arc_path[] = {
{600.0, 450.0, PathPointTypeStart, 0, 0}, /*0*/
{600.0, 643.3, PathPointTypeBezier, 0, 0}, /*1*/
{488.1, 800.0, PathPointTypeBezier, 0, 0}, /*2*/
};
the gdiplus code will make the last entry PathPointTypeBezier |
PathPointTypeCloseSubpath.
For the nature of the existing test, I believe the fix is correct (it
is testing the basic arc path functionality). However, there should be
another test to document the above behaviour.
- Reece
Am Freitag, 25. Januar 2008 19:41:52 schrieb Victor:
> This is a DX8 implementation of D3DXGetFVFVertexSize (i.e. D3DFVF_XYZW is
> commented out).I must note that I've encountered a bug in original/natvie
> D3DXGetFVFVertexSize - it returned wrong vertex size(one float less than
> needed(?)) when it was used with D3DFVF_XYZB4.It was more than a year ago,
> and I'm not sure if this bug still exists in native D3DX.
> Anyway this bug isn't reproduced here.
A few comments:
Regarding the possible bug in d3dx8 I recommend to add a test for this, like
you're testing other flags already in dlls/d3dx8/tests/math.c . This will
shed more light on the issue. If you do not have a Windows box to test on I
can run the test for you. If the bug still exists Wine should clone it as
well. (I don't think this function belongs to math.c by the way, probably
create a new file called vertex.c or fvf.c or something like that)
Your code contains some C++ comments ("//"), please do not use them as Wine is
plain C code. I think you can just remove the D3DFVF_XYZW block if this
enumeration doesn't exist in d3d8.
Also please watch out with the whitespaces: The code is mixing tabs and
spaces. Preferably stick to the style that is used in the rest of the file.
