Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
2009/12/28 Matteo Bruni matteo.myst...@gmail.com:
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().
Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
Matteo Bruni matteo.myst...@gmail.com 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: 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: 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 Cabanja...@codeweavers.com 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
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: 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: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
2009/12/29 Henri Verbeet hverb...@gmail.com: 2009/12/28 Matteo Bruni matteo.myst...@gmail.com: 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: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
2009/12/29 Alexandre Julliard julli...@winehq.org: Matteo Bruni matteo.myst...@gmail.com 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 Matteo Bruni matteo.myst...@gmail.com: 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: Guide for creating new AppInstall tests
On Tue, Dec 29, 2009 at 9:12 AM, Sam S. sml...@gmail.com 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.
On 12/29/2009 04:54 PM, Matteo Bruni wrote: 2009/12/29 Alexandre Julliardjulli...@winehq.org: Matteo Brunimatteo.myst...@gmail.com 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: dbghelp: Make sure the ClientPointers flag is set correctly
2009/12/29 Jason Green jav...@gmail.com: commit 317da09400946ca9f97361a47a227595c5bedfe3 Author: Eric van Beurden eri...@transgaming.com 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: 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 jav...@gmail.com: commit 317da09400946ca9f97361a47a227595c5bedfe3 Author: Eric van Beurden eri...@transgaming.com 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 jav...@gmail.com: 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.
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: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
2009/12/29 Henri Verbeet hverb...@gmail.com: 2009/12/29 Matteo Bruni matteo.myst...@gmail.com: 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...
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
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: 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
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 dmi...@codeweavers.com David Quintana (gigaherz) gigah...@gmail.com 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: [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 winehac...@gmail.com 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 sedwa...@bordeauxgroup.com
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 Komprimer...,119
MENUITEM Dekomprimer..., 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
CAPTION Vælg destination
diff --git
