Re: [PATCH] Replace builtin WineFile Execute Dialog with standard RunFile Dialog - try2
damnit. sorry about that, that's what I get for trying to amend. Here is the correct patch, try 3 On Tue, Dec 29, 2009 at 12:34 PM, Steven Edwards wrote: > I don't know why this didn't get through, resending from gmail. > > This time incorporating (most of) the feedback from Dmitry Timoshkov > and Paul Vriens and attempting to better match the coding style of the > rest of the file which is inconsistent as hell. > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo From f9a2429f5b1049309623042e8519ee438cd40ce3 Mon Sep 17 00:00:00 2001 From: Steven Edwards Date: Mon, 28 Dec 2009 11:44:20 -0500 Subject: [PATCH] Replace builtin WineFile Execute Dialog with standard RunFile Dialog --- programs/winefile/Cs.rc | 17 +- programs/winefile/Da.rc | 17 +- programs/winefile/De.rc | 17 +- programs/winefile/En.rc | 17 +- programs/winefile/Es.rc | 17 +- programs/winefile/Fr.rc | 17 +- programs/winefile/Hu.rc | 16 + programs/winefile/It.rc | 17 +- programs/winefile/Ja.rc | 17 +- programs/winefile/Ko.rc | 17 +- programs/winefile/Lt.rc | 17 +- programs/winefile/Nl.rc | 17 +- programs/winefile/No.rc | 17 +- programs/winefile/Pl.rc | 17 +- programs/winefile/Pt.rc | 22 + programs/winefile/Ru.rc | 16 + programs/winefile/Si.rc | 17 +- programs/winefile/Sv.rc | 17 +- programs/winefile/Tr.rc | 17 +- programs/winefile/Zh.rc | 33 +-- programs/winefile/resource.h |3 +- programs/winefile/winefile.c | 50 +++--- 22 files changed, 36 insertions(+), 376 deletions(-) diff --git a/programs/winefile/Cs.rc b/programs/winefile/Cs.rc index ad71863..80ddc1b 100644 --- a/programs/winefile/Cs.rc +++ b/programs/winefile/Cs.rc @@ -45,7 +45,7 @@ IDM_WINEFILE MENU FIXED IMPURE MENUITEM "&Komprese...",119 MENUITEM "&Dekomprese...", 120 MENUITEM SEPARATOR -MENUITEM "&Spustit...", ID_EXECUTE +MENUITEM "&Spustit...", ID_RUN MENUITEM "&Tisknout...",102 MENUITEM "Asociovat...",103 MENUITEM SEPARATOR @@ -150,21 +150,6 @@ IDM_WINEFILE MENU FIXED IMPURE } } - -IDD_EXECUTE DIALOG FIXED IMPURE 15, 13, 210, 63 -STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU -CAPTION "Spustit" -FONT 8, "MS Shell Dlg" -{ -CONTROL "", 101, "Static", SS_SIMPLE|SS_NOPREFIX, 3, 6, 162, 10 -CONTROL "&Pøíkaz:", -1, "Static", SS_LEFTNOWORDWRAP|WS_GROUP, 3, 18, 60, 10 -EDITTEXT201, 3, 29, 134, 12, ES_AUTOHSCROLL -CONTROL "Jako &Symbol", 214, "Button", BS_AUTOCHECKBOX|WS_TABSTOP,3, 45, 71, 12 -DEFPUSHBUTTON "OK", 1, 158, 6, 47, 14 -PUSHBUTTON "Zrušit", 2, 158, 23, 47, 14 -PUSHBUTTON "&Pomoc", 254, 158, 43, 47, 14 -} - IDD_SELECT_DESTINATION DIALOG FIXED IMPURE 15, 13, 210, 63 STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU CAPTION "Zvolte cíl" diff --git a/programs/winefile/Da.rc b/programs/winefile/Da.rc index ffc7415..385333c 100644 --- a/programs/winefile/Da.rc +++ b/programs/winefile/Da.rc @@ -39,7 +39,7 @@ IDM_WINEFILE MENU FIXED IMPURE MENUITEM "K&omprimer...",119 MENUITEM "De&komprimer...", 120 MENUITEM SEPARATOR -MENUITEM "Kø&r...", ID_EXECUTE +MENUITEM "Kø&r...", ID_RUN MENUITEM "&Udskriv...", 102 MENUITEM "Associer...", 103 MENUITEM SEPARATOR @@ -144,21 +144,6 @@ IDM_WINEFILE MENU FIXED IMPURE } } - -IDD_EXECUTE DIALOG FIXED IMPURE 15, 13, 210, 63 -STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU -CAPTION "Kør" -FONT 8, "MS Shell Dlg" -{ -CONTROL "", 101, "Static", SS_SIMPLE|SS_NOPREFIX, 3, 6, 162, 10 -CONTROL "&Kommando:", -1, "Static", SS_LEFTNOWORDWRAP|WS_GROUP, 3, 18, 60, 10 -EDITTEXT201, 3, 29, 134, 12, ES_AUTOHSCROLL -CONTROL "&Som symbol", 214, "Button", BS_AUTOCHECKBOX|WS_TABSTOP,3, 45, 71, 12 -DEFPUSHBUTTON "OK", 1, 158, 6, 47, 14 -PUSHBUTTON "Annuller", 2, 158, 23, 47, 14 -PUSHBUTTON "&Hjælp", 254, 158, 43, 47, 14 -} - IDD_SELECT_DESTINATION DIALOG FIXED IMPURE 15, 13, 210, 63 STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU CAP
Re: dlls/user32/combo.c: Fix an issue where pressing 's' in a combobox shows the dropdown isntead of finding an entry starting with 's'.
I had already sent a second patch without the C++-style comment. But regardless, if you say other parts of the code are also wrong, then I will leave this to someone closer to the project, who knows better what is it that should be done here. 2009/12/29 Dmitry Timoshkov > "David Quintana (gigaherz)" wrote: > > Issue was caused by VK_F4 having the same exact code as a lowercase 's'. >> So the code, which treated WM_CHAR and WM_KEYDOWN as the same, executed >> the wrong piece of code which was meant to be ONLY for WM_KEYDOWN. >> > > Thanks for spotting this bug. Anyway the fix is not correct. Virtual key > codes should be tested only in the WM_KEYDOWN handler, WM_CHAR handler > should test for character codes. Also, as Nikolay asked please don't use > C++ comments in Wine code. > > -- > Dmitry. >
Re: CPPCheck Dec 29
On 30/12/09 03:55, chris ahrendt wrote: I just ran CPP check this evening and got the following : rpcrt4/rpc_transport.c 490 (error) Uninitialized variable smb_floor 761 (error) Uninitialized variable pipe_floor 885 (error) Uninitialized variable tcp_floor If you look at the code : static size_t rpcrt4_ncacn_np_get_top_of_tower(unsigned char *tower_data, const char *networkaddr, const char *endpoint) { twr_empty_floor_t *smb_floor; twr_empty_floor_t *nb_floor; size_t size; size_t networkaddr_size; size_t endpoint_size; TRACE("(%p, %s, %s)\n", tower_data, networkaddr, endpoint); networkaddr_size = networkaddr ? strlen(networkaddr) + 1 : 1; endpoint_size = endpoint ? strlen(endpoint) + 1 : 1; size = sizeof(*smb_floor) + endpoint_size + sizeof(*nb_floor) + networkaddr_size; if (!tower_data) return size; It is correct in that these three are not initialised and could point to anything on the local stack. Additionally if you look above you can get potentially a bogus return.. Additionally for tcp_floor: static size_t rpcrt4_ip_tcp_get_top_of_tower(unsigned char *tower_data, const char *networkaddr, unsigned char tcp_protid, const char *endpoint) { twr_tcp_floor_t *tcp_floor; twr_ipv4_floor_t *ipv4_floor; struct addrinfo *ai; struct addrinfo hints; int ret; size_t size = sizeof(*tcp_floor) + sizeof(*ipv4_floor); TRACE("(%p, %s, %s)\n", tower_data, networkaddr, endpoint); if (!tower_data) return size; Same problem here as well Chris Looks like a CPPCheck bug, sizeof is a unary operator and not a function, those variables never get dereferenced. The ()s in those expressions are actually unneeded as sizeof only needs them for type names and not variables. Alasdair
CPPCheck Dec 29
I just ran CPP check this evening and got the following : rpcrt4/rpc_transport.c 490 (error) Uninitialized variable smb_floor 761 (error) Uninitialized variable pipe_floor 885 (error) Uninitialized variable tcp_floor If you look at the code : static size_t rpcrt4_ncacn_np_get_top_of_tower(unsigned char *tower_data, const char *networkaddr, const char *endpoint) { twr_empty_floor_t *smb_floor; twr_empty_floor_t *nb_floor; size_t size; size_t networkaddr_size; size_t endpoint_size; TRACE("(%p, %s, %s)\n", tower_data, networkaddr, endpoint); networkaddr_size = networkaddr ? strlen(networkaddr) + 1 : 1; endpoint_size = endpoint ? strlen(endpoint) + 1 : 1; size = sizeof(*smb_floor) + endpoint_size + sizeof(*nb_floor) + networkaddr_size; if (!tower_data) return size; It is correct in that these three are not initialised and could point to anything on the local stack. Additionally if you look above you can get potentially a bogus return.. Additionally for tcp_floor: static size_t rpcrt4_ip_tcp_get_top_of_tower(unsigned char *tower_data, const char *networkaddr, unsigned char tcp_protid, const char *endpoint) { twr_tcp_floor_t *tcp_floor; twr_ipv4_floor_t *ipv4_floor; struct addrinfo *ai; struct addrinfo hints; int ret; size_t size = sizeof(*tcp_floor) + sizeof(*ipv4_floor); TRACE("(%p, %s, %s)\n", tower_data, networkaddr, endpoint); if (!tower_data) return size; Same problem here as well Chris
Re: Removing WPARAM/LPARAM Casts
Michael Stefaniuc wrote: > On 12/28/2009 03:06 AM, James Mckenzie wrote: >> I've noticed that Michael Stefuic (sp?) has removed quite a few >> WPARAM/LPARAM casts when calling SendMessage() and was >> wondering/inquiring if he was going do this to riched20/tests/editor.c >> since I noticed he put in a change for riched20. >> >> Michael are you going to do so, or are you going to leave this to >> others? > All but one change in the riched20 patch where for > riched20/tests/editor.c. Michael: Thank you. I've been working on the EM_FORMATRANGE patch and would like to make changes in the tests to see what happens and if the tests remain valid for Wine and Windows. James McKenzie
Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
2009/12/29 Henri Verbeet : > 2009/12/29 Matteo Bruni : >> I added the fake parser for two reasons: because I have to initialize >> an asm_parser structure anyway in the create__parser functions >> (and I prefer to use parser_fake for the unimplemented shader versions >> instead of parser_vs_3) and I want to avoid having some tests for the >> other shader versions pass "by chance" inside the todo_wine (this is >> accomplished by the asmparser_end_fake function... probably this can >> be seen as a hack). >> Agreed on the structure fields. >> > Can't you just let the parser fail when it encounters an unsupported > shader version? That's more or less what happens anyway, but I don't > think you have to wait until after parsing all the instructions for > that. > Yep, you are right. I believe previously I had found no way to halt the parser early, so I simply let it go until the end and I needed the fake backend to cope with that. Seems like the YYABORT macro does just what I need...
Linux Gaming: Are We There Yet?
Excelent review from the guys in AnandTech of the current status of gaming in Linux, they have tested Wine vs CrossOver Games vs Cedega vs Windows 7 and the results are quite good. http://www.anandtech.com/linux/showdoc.aspx?i=3700 -- Jaime Rave Torres Ingeniero de Sistemas Miembro de la Fundación de Software Libre de Colombia http://www.fslcol.org/ http://sobrelibertad.blogspot.com/ 3003160361
Re: dbghelp: Make sure the ClientPointers flag is set correctly
2009/12/29 Jason Green : > Using "stg show" from stgit 0.14.2. Looks like that function is mostly just > a passthrough to "git show". git-format-patch seems nicer since it gives > the number of line items changed, etc., although there's probably an option > in "git show" somewhere that will do that as well...? Not sure if "git show" can do that, but format-patch is much nicer for creating patch series. You can also then use send-email to send those patches.
Re: dbghelp: Make sure the ClientPointers flag is set correctly
On Dec 29, 2009, at 2:37 PM, Henri Verbeet wrote: > 2009/12/29 Jason Green : >> commit 317da09400946ca9f97361a47a227595c5bedfe3 >> Author: Eric van Beurden >> Date: Tue Dec 29 12:35:03 2009 -0500 >> >>Make sure the ClientPointers flag isn't set incorrectly > > Mostly out of curiosity, how did you generate this patch? That looks > like the kind of output git log gives, not git format-patch. Using "stg show" from stgit 0.14.2. Looks like that function is mostly just a passthrough to "git show". git-format-patch seems nicer since it gives the number of line items changed, etc., although there's probably an option in "git show" somewhere that will do that as well...?
Re: dbghelp: Make sure the ClientPointers flag is set correctly
2009/12/29 Jason Green : > commit 317da09400946ca9f97361a47a227595c5bedfe3 > Author: Eric van Beurden > Date: Tue Dec 29 12:35:03 2009 -0500 > > Make sure the ClientPointers flag isn't set incorrectly Mostly out of curiosity, how did you generate this patch? That looks like the kind of output git log gives, not git format-patch.
Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
On 12/29/2009 04:54 PM, Matteo Bruni wrote: 2009/12/29 Alexandre Julliard: Matteo Bruni writes: + +%option reentrant bison-bridge These won't work on old flex versions, and will get you in trouble with the flex police (aka Michael Stefaniuc ;-) All that because the Wine maintainer puts a lot of emphasis on portability ... Alexandre, now you have another person on your side against RHEL 5 and old flex versions :) I have just submitted a patch for configure.ac to require a newer flex version to build Wine. People on RHEL5 can just rebuild a SRPM from Fedora (those from F7 to F10 are just a "rpmbuild --rebuild"). Now the Wine maintainer needs to just accept that patch ;) bye michael
Re: Guide for creating new AppInstall tests
On Tue, Dec 29, 2009 at 9:12 AM, Sam S. wrote: > Hi Austin, > > thank you for your reply. I'll give it another try. > > Btw, I do realise that some questions of the step-by-step list I gave > at the end are already (at least partially) answered in various places > - this was intended more as an outline of how a step-by-step guide > useful to users with no prior experience could be added to the wiki > page. > Your answeres already made the process much clearer to me... > > One thing though: > >>> - on Windows: how to properly test-run/debug the new script >> >> By running it a few times and making sure nothing fails ;-). > > So you need to run > > ..\tools\autohotkey\autohotkey.exe testname.ahk > > and then check > > C:\appinstall\testname-result.txt > > correct? Right. Or you can install AutoHotKey and just double click testname.ahk. >>> - on Windows: how to get all those checksums >> >> There's not an easy way on windows, without installing cygwin. This is >> explained in the wiki. > > It explains it for Linux, I was hoping there would be a way to get the > checksums of the files generated on Windows, without copying them to > Linux first... Well, too bad... If windows supported proper scripting and bundling sha1sum.exe, it would be easier ;-). >> If someone would volunteer to help with the documentation >> (by proofing it, making sure I didn't leave steps out, etc.), it would >> help greatly. > > If I manage to get it working now, maybe I can help with the > documantation (by providing a user's perspective)... > In any case, having a step-by-step howto of the actual process (as > outlined in my first email) would already be a great improvement > compared to having to collect the various bits of information from all > over... Feel free to e-mail me for help in writing a test (off list). > One more thing: There should probably be a link to the AppInstall wiki > page at http://www.winehq.org/contributing and maybe other places... > (right now, it seems to be linked to only from the archived WWN > article, which makes it not so easy to discover for users...) Good idea. -- -Austin
Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
2009/12/29 Matteo Bruni : > I added the fake parser for two reasons: because I have to initialize > an asm_parser structure anyway in the create__parser functions > (and I prefer to use parser_fake for the unimplemented shader versions > instead of parser_vs_3) and I want to avoid having some tests for the > other shader versions pass "by chance" inside the todo_wine (this is > accomplished by the asmparser_end_fake function... probably this can > be seen as a hack). > Agreed on the structure fields. > Can't you just let the parser fail when it encounters an unsupported shader version? That's more or less what happens anyway, but I don't think you have to wait until after parsing all the instructions for that.
Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
2009/12/29 Alexandre Julliard : > Matteo Bruni writes: > >> + >> +%option reentrant bison-bridge > > These won't work on old flex versions, and will get you in trouble with > the flex police (aka Michael Stefaniuc ;-) > Alexandre, now you have another person on your side against RHEL 5 and old flex versions :) Joking aside, that's not a big issue as wpp is not reentrant anyway and I'm using the mutex to allow a single call at a time to D3DXAssembleShader. Just a question: as now I have to keep the parser context in a global structure defined in asmshader.y, how should I give access to it from asmshader.l? Do you prefer to give visibility to the global struct from asmshader.l or to create a getter (like a struct asm_parser *asm_get_context(void) function)?
Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
2009/12/29 Henri Verbeet : > 2009/12/28 Matteo Bruni : >> > Why do you need the fake parser? Can't you just not support those > shader versions yet? There's also (in general) not much of a point in > adding structure fields that aren't used yet. > I added the fake parser for two reasons: because I have to initialize an asm_parser structure anyway in the create__parser functions (and I prefer to use parser_fake for the unimplemented shader versions instead of parser_vs_3) and I want to avoid having some tests for the other shader versions pass "by chance" inside the todo_wine (this is accomplished by the asmparser_end_fake function... probably this can be seen as a hack). Agreed on the structure fields. >> +/* This file needs the original d3d9 definitions. The bwriter ones >> + * aren't useable because they are wine-internal things. We're writing >> + * d3d8/9 shaders here, so we need the d3d9 definitions (which are >> + * equal to the d3d8 ones) >> + */ > This doesn't seem to match what the code actually does. That #include is only used from the next patch. I'll move the include and the comment in the right place (maybe rephrasing it somewhat). > >> +/* Debug utility routines. Some are not reentrant, check asmutils.c */ > Same as above. Yep, that's not true anymore, courtesy of wine_dbg_sprintf. > As for splitting things up, I think it's ok to e.g. add the > pre-processor first, and just return E_NOTIMPL from assemble_shader(). > You mean a patch which adds only the first half of the D3DXAssembleShader implementation (returning just after the preprocessing)? That seems reasonable. Btw, ok for your other points also.
Re: Guide for creating new AppInstall tests
Hi Austin, thank you for your reply. I'll give it another try. Btw, I do realise that some questions of the step-by-step list I gave at the end are already (at least partially) answered in various places - this was intended more as an outline of how a step-by-step guide useful to users with no prior experience could be added to the wiki page. Your answeres already made the process much clearer to me... One thing though: >> - on Windows: how to properly test-run/debug the new script > > By running it a few times and making sure nothing fails ;-). So you need to run ..\tools\autohotkey\autohotkey.exe testname.ahk and then check C:\appinstall\testname-result.txt correct? >> - on Windows: how to get all those checksums > > There's not an easy way on windows, without installing cygwin. This is > explained in the wiki. It explains it for Linux, I was hoping there would be a way to get the checksums of the files generated on Windows, without copying them to Linux first... Well, too bad... > If someone would volunteer to help with the documentation > (by proofing it, making sure I didn't leave steps out, etc.), it would > help greatly. If I manage to get it working now, maybe I can help with the documantation (by providing a user's perspective)... In any case, having a step-by-step howto of the actual process (as outlined in my first email) would already be a great improvement compared to having to collect the various bits of information from all over... One more thing: There should probably be a link to the AppInstall wiki page at http://www.winehq.org/contributing and maybe other places... (right now, it seems to be linked to only from the archived WWN article, which makes it not so easy to discover for users...)
Re: Building and packaging Wine Gecko
On 12/29/09 2:07 PM, André Hentschel wrote: Jacek Caban schrieb: On 12/28/09 8:34 AM, Ove Kaaven wrote: OK, I've almost got a wine-gecko package built 100% from source, but there's a problem: the gcc version in Debian's mingw32, namely gcc 4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5 something, compiles it correctly, but I can't reasonably build-depend on it, as that version is not even in the current stable.) (Note that this 4.2.1-sjlj might not suffer from that gcc bug 9381 mentioned on the wiki, as the testcases for it doesn't seem to crash. Or aren't they supposed to crash?) It does suffer from this bug, these tests are probably not enough to show it. I also seem to recall the gcc 4.4-based mingw32 compiler, available in unstable, also refusing to compile those sources at all, due to numerous problems with the headers, such as inconsistently declared calling conventions for methods and stuff. I'm not sure what to do about this. Any ideas about something I can do to make it build with gcc 4.2 or 4.4? The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current Git version uses GCC 4.4 SVN version (waiting for the first official GCC release). All older compilers are not enough unless you'd patch them (but that doesn't sound reasonable). Jacek Hi Jacek, gcc 3.4.5 or 3.4.6(as mentioned in the wiki)? It was a typo, it's 3.4.6 (although 3.4.5 would also work). Thanks, Jacek
Re: Building and packaging Wine Gecko
On 12/29/09 5:45 AM, Austin English wrote: On Mon, Dec 28, 2009 at 6:53 PM, Jacek Caban wrote: On 12/29/09 1:44 AM, Ove Kaaven wrote: gcc 4.4.2 is already released, and Debian unstable is using it as the default compiler. And like I mentioned, they even have a mingw32 cross compiler of it. Would it then be a good idea to build wine-gecko git instead of wine-gecko 1.0.0? Should that work? That won't work, but I think it's better to spend time on working on the next release. When is the next 'release' of wine-gecko planned? E.g., when will wine-gecko git become wine-gecko 1.1? It's not yet planned. Jacek
Re: Building and packaging Wine Gecko
Jacek Caban schrieb: > On 12/28/09 8:34 AM, Ove Kaaven wrote: >> OK, I've almost got a wine-gecko package built 100% from source, but >> there's a problem: the gcc version in Debian's mingw32, namely gcc >> 4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the >> resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5 >> something, compiles it correctly, but I can't reasonably build-depend on >> it, as that version is not even in the current stable.) >> >> (Note that this 4.2.1-sjlj might not suffer from that gcc bug 9381 >> mentioned on the wiki, as the testcases for it doesn't seem to crash. Or >> aren't they supposed to crash?) >> > > It does suffer from this bug, these tests are probably not enough to > show it. > >> I also seem to recall the gcc 4.4-based mingw32 compiler, available in >> unstable, also refusing to compile those sources at all, due to numerous >> problems with the headers, such as inconsistently declared calling >> conventions for methods and stuff. >> >> I'm not sure what to do about this. Any ideas about something I can do >> to make it build with gcc 4.2 or 4.4? >> > > The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current > Git version uses GCC 4.4 SVN version (waiting for the first official GCC > release). All older compilers are not enough unless you'd patch them > (but that doesn't sound reasonable). > > > Jacek > > Hi Jacek, gcc 3.4.5 or 3.4.6(as mentioned in the wiki)? -- Best Regards, André Hentschel
Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
Matteo Bruni writes: > + > +%option reentrant bison-bridge These won't work on old flex versions, and will get you in trouble with the flex police (aka Michael Stefaniuc ;-) -- Alexandre Julliard julli...@winehq.org
Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
2009/12/28 Matteo Bruni : > Why do you need the fake parser? Can't you just not support those shader versions yet? There's also (in general) not much of a point in adding structure fields that aren't used yet. > +/* This file needs the original d3d9 definitions. The bwriter ones > + * aren't useable because they are wine-internal things. We're writing > + * d3d8/9 shaders here, so we need the d3d9 definitions (which are > + * equal to the d3d8 ones) > + */ This doesn't seem to match what the code actually does. > +/* Debug utility routines. Some are not reentrant, check asmutils.c */ Same as above. > +const char *debug_print_dstreg(const struct shader_reg *reg, shader_type st) > { > +return wine_dbg_sprintf("%s", get_regname(reg, st)); > +} > + > +const char *debug_print_srcreg(const struct shader_reg *reg, shader_type st) > { > +switch(reg->srcmod) { > +case BWRITERSPSM_NONE: > +return wine_dbg_sprintf("%s", get_regname(reg, st)); > +} > +return "Unknown modifier"; > +} "return get_regname(reg, st);" should work at least as well. > +/* Mutex used to guarantee a single invocation > + of the D3DXAssembleShader function (or its variants) at a time. > + This is needed as wpp isn't thread-safe */ > +extern CRITICAL_SECTION wpp_mutex; It's probably easier to just statically initialize the critical section in shader.c. As for splitting things up, I think it's ok to e.g. add the pre-processor first, and just return E_NOTIMPL from assemble_shader().