Re: Assining .bat and .com files with the desktop
Am 11.08.2011 17:21, schrieb Nowres Rafid: > I propose to associate .bat and .com files with wine's cmd in GNOME, > KDE and others > > Did you mean .bat and .cmd? This. are the both endings for commandline (batch) scripts
Re: Assining .bat and .com files with the desktop
On Thu, Aug 11, 2011 at 6:18 PM, Vincent Povirk wrote: > I'm not sure DOSBox is able to competently open some random executable > file. One would have to make a config file that sets up a drive > mapping, runs the file, and quits. If Wine can do these things (and > maybe also properly handle cases where the COM executable expects to > be run on a windows machine or, say, a dos machine with win3.1 > installed), it seems like a fine choice to me. > > There's a non-zero chance that wine start /unix will actually start > cmd and make a terminal for BAT files. It makes one for console > executables. If it doesn't, there's a possibility that start.exe will > do that on Windows, in which case that is a Wine bug that we should > fix. You should test that before making a new thing. > > There was some talk on #mono (or #monodev) to the effect that the > arbitration mechanism for different kinds of files is called mime > types, and a DOS exe, x86/x64 PE exe, and CLR exe are all different > and should have different mime types. > On Windows, double-clicking a BAT file causes it to open in a terminal window which automatically closes after the file is finished running, whereas using "start" cause the terminal window to stay open even after the file is finished running. On Wine using "start" wrongly closes the Window automatically, but since that's what we want for a double-clicked BAT file, "wineconsole" has the same behaviour and can be used instead. Unfortunately wineconsole doesn't like *nix paths, so it can't be used from a .desktop file directly...
Re: wined3d: Only update the sampler map when needed
On Tuesday 26 July 2011 23:13:53 Henri Verbeet wrote: > > +device->fixed_function_usage_map = 0xff; > This looks questionable, it will cause unused textures to be loaded. I'll try to cover this with my draw overhead test, but I have to get rid of its use of a pixel shader first. Performance concerns aside, I don't really like loading textures depending on the shader or ffp settings. Currently its not an issue because we preload all used textures every draw, but if we want to change that one day we'll have to keep track of the ffp and shader states to figure out which textures to preload. If we ignore the shader/ffp setup when deciding which textures to preload we keep the states independent. signature.asc Description: This is a digitally signed message part.
Re: [1/3] gdi32: Initial Gamma setting tests
Am 10.08.2011 23:24, schrieb Nikolay Sivov: > On 8/11/2011 00:58, André Hentschel wrote: >> --- >> dlls/gdi32/tests/dc.c | 40 >> 1 files changed, 40 insertions(+), 0 deletions(-) thx for the hints, i just sent try2 which should be much cleaner. -- Best Regards, André Hentschel
Re: Assining .bat and .com files with the desktop
Am 11.08.2011 18:18, schrieb Vincent Povirk: > I'm not sure DOSBox is able to competently open some random executable > file. One would have to make a config file that sets up a drive > mapping, runs the file, and quits. If Wine can do these things (and > maybe also properly handle cases where the COM executable expects to > be run on a windows machine or, say, a dos machine with win3.1 > installed), it seems like a fine choice to me. Wine can. See winevdm/winevdm.c:start_dosbox. I'm currently working on fixing issues on both sides. Am 11.08.2011 17:57, schrieb Damjan Jovanovic: > While I am at it, EXE files are not clearly Wine's either - they could > be real-mode DOS executables, or .NET code intended for Mono on *nix. > At some point, Wine/Mono/DOSBox and related projects need to have a > talk about some kind of arbitration mechanism. Am 11.08.2011 18:18, schrieb Vincent Povirk: > There was some talk on #mono (or #monodev) to the effect that the > arbitration mechanism for different kinds of files is called mime > types, and a DOS exe, x86/x64 PE exe, and CLR exe are all different > and should have different mime types. Talks are good, but did one project already do something for that, wo we can build upon it? -- Best Regards, André Hentschel
Re: Assining .bat and .com files with the desktop
Damjan, I dont believe it is necessary to have separate desktop files for different commands. Just append whatever you need in a new section. I believe chromium does that to differentiate some --flags. On Thu, Aug 11, 2011 at 6:57 PM, Damjan Jovanovic wrote: > On Thu, Aug 11, 2011 at 5:21 PM, Nowres Rafid wrote: >> I propose to associate .bat and .com files with wine's cmd in GNOME, KDE and >> others >> >> >> > > AFAIK COM files are ancient self-contained real-mode DOS code, with no > ability to load DLLs. Shouldn't they rather be loaded by DOSBox, which > we delegate DOS applications to on the AMD64 architecture anyway? > > BAT files should associate with Wine, but on Windows double-clicking > them runs them in a terminal window (when last I checked). Thus we'd > have to create a new wine-cmd.desktop which associates with BAT files. > I'll look into it. > > While I am at it, EXE files are not clearly Wine's either - they could > be real-mode DOS executables, or .NET code intended for Mono on *nix. > At some point, Wine/Mono/DOSBox and related projects need to have a > talk about some kind of arbitration mechanism. > > Damjan Jovanovic > > >
Re: Assining .bat and .com files with the desktop
I'm not sure DOSBox is able to competently open some random executable file. One would have to make a config file that sets up a drive mapping, runs the file, and quits. If Wine can do these things (and maybe also properly handle cases where the COM executable expects to be run on a windows machine or, say, a dos machine with win3.1 installed), it seems like a fine choice to me. There's a non-zero chance that wine start /unix will actually start cmd and make a terminal for BAT files. It makes one for console executables. If it doesn't, there's a possibility that start.exe will do that on Windows, in which case that is a Wine bug that we should fix. You should test that before making a new thing. There was some talk on #mono (or #monodev) to the effect that the arbitration mechanism for different kinds of files is called mime types, and a DOS exe, x86/x64 PE exe, and CLR exe are all different and should have different mime types.
Re: Assining .bat and .com files with the desktop
On Thu, Aug 11, 2011 at 5:21 PM, Nowres Rafid wrote: > I propose to associate .bat and .com files with wine's cmd in GNOME, KDE and > others > > > AFAIK COM files are ancient self-contained real-mode DOS code, with no ability to load DLLs. Shouldn't they rather be loaded by DOSBox, which we delegate DOS applications to on the AMD64 architecture anyway? BAT files should associate with Wine, but on Windows double-clicking them runs them in a terminal window (when last I checked). Thus we'd have to create a new wine-cmd.desktop which associates with BAT files. I'll look into it. While I am at it, EXE files are not clearly Wine's either - they could be real-mode DOS executables, or .NET code intended for Mono on *nix. At some point, Wine/Mono/DOSBox and related projects need to have a talk about some kind of arbitration mechanism. Damjan Jovanovic
Assining .bat and .com files with the desktop
I propose to associate .bat and .com files with wine's cmd in GNOME, KDE and others
Re: gsoc mentor summit
On Wednesday 10 August 2011 21:00:24 Owen Rudge wrote: > Any further thoughts on this from any of the other mentors? It looks > like the latest date to officially confirm things is the 30th September, > but we probably want to figure things out before then to sort out > travel, etc. I guess if nobody shouts out loud we'll just add ourselves to the participants list. That's how Roderick and I handled it 2 years ago... signature.asc Description: This is a digitally signed message part.
Re: d3dx9: CloneMesh test and improvements
On Thu, Aug 11, 2011 at 3:01 PM, Matteo Bruni wrote: > 2011/8/11 Michael Mc Donnell : >> >> + dst_ptr[0] = src->x < 0.0f ? (SHORT)ceilf(src->x * SHRT_MAX + >> 0.5f) :(SHORT)floorf(src->x * SHRT_MAX + 0.5f); > > You can use roundf() instead. Actually, notice that maybe what you > actually need for correct rounding is rintf() (which essentially > matches what D3DXFloat32To16Array does). You should probably test this > (even on your own, not necessarily adding those to the testsuite, I'd > say). Ok I'll look into that. I also noticed that I had a bug in the UBYTE4 conversion. I'll modify the tests to catch those cases. > Still on the conversion: going on with this "strategy" is going to > require a ton of code to handle every src->dst format combination. You > may look into doing that in two steps: first converting src to float4, > then float4 into dst. I haven't looked into it, so there may be some > detail making this impractical, but still it's worth a try, I guess. That's a good idea. I had started doing the other conversions, but noticed that it was a lot of code. I'll try your idea. Thanks!
Re: cmd: an issue with cd .. command
I corrected the code as suggested
and added some test cases
On Thu, 2011-08-11 at 14:03 +0200, Frédéric Delanoy wrote:
> On Thu, Aug 11, 2011 at 05:19, Nowres Rafid wrote:
> > Hello,
> >
> > the command "cd .. " doesn't work when there is extra spaces at the end.
> >
> > I propose this patch and ask for your confirmation about it.
> >
> > best regards.
>
>}
>else {
> +
> +/* Remove any space at the end of command
> +This was because "cd .. " wasn't working */
> + {
> +WCHAR *ptr = command + strlenW(command) - 1;
> +
> +while(*ptr == ' ')
> +*ptr-- = 0;
> + }
>
> You shouldn't modify the "command" parameter. This one ought to be
> constant, even if it's not currently marked so.
> It's better to change the "string" string.
>
> Also you should add testcases to cmd's test suite, possibly as a
> preliminary patch of a series, but it can also be together with the
> patch. That's up to you.
>
> Also for single patches, you don't need "[1/1]"... use git
> format-patch "-k" option, or edit the subject before submission.
>
> Frédéric
>From c75bd914878a2a2e4cfbb6caaa8925b9798c2ab9 Mon Sep 17 00:00:00 2001
From: Nowres Rafid
Date: Thu, 11 Aug 2011 13:51:38 +
Subject: cmd: fixing an issue with extra whitespaces after cd parameter
---
programs/cmd/builtins.c |8 ++-
programs/cmd/tests/test_builtins.cmd | 39 ++
2 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/programs/cmd/builtins.c b/programs/cmd/builtins.c
index 09c166f..1de1987 100644
--- a/programs/cmd/builtins.c
+++ b/programs/cmd/builtins.c
@@ -2101,15 +2101,21 @@ void WCMD_setshow_default (WCHAR *command) {
WCMD_output (cwd);
}
else {
+pos = string;
/* Remove any double quotes, which may be in the
middle, eg. cd "C:\Program Files"\Microsoft is ok */
-pos = string;
while (*command) {
if (*command != '"') *pos++ = *command;
command++;
}
*pos = 0x00;
+/* Remove any whitespace at the end of command
+This was because "cd .. " wasn't working */
+pos--;
+while ( *pos == ' ' || *pos == '\t' )
+*pos-- = 0x00;
+
/* Search for appropriate directory */
WINE_TRACE("Looking for directory '%s'\n", wine_dbgstr_w(string));
hff = FindFirstFileW(string, &fd);
diff --git a/programs/cmd/tests/test_builtins.cmd b/programs/cmd/tests/test_builtins.cmd
index a83e568..b152787 100644
--- a/programs/cmd/tests/test_builtins.cmd
+++ b/programs/cmd/tests/test_builtins.cmd
@@ -36,6 +36,45 @@ echo :word
echo word@space@
echo word@space@@space@
+
+echo Testing 'cd' --
+mkdir test
+cd
+cd test
+cd
+cd ..
+cd
+cd test
+cd
+cd ..
+cd
+cd test
+cd
+cd ..
+cd test
+cd ..
+cd .
+cd .
+cd test >nul
+cd .. >nul
+cd testii
+mkdir test2
+cd test2
+mkdir test21
+cd test21
+cd ..\..
+cd test2
+mkdir test22
+cd test22
+cd ..\test21
+cd ..
+rd test21
+rd test22
+cd ..
+rd test
+rd test2
+
+
echo Testing redirection operators --
mkdir foobar & cd foobar
echo ...stdout redirection
--
1.7.4.1
Re: cmd: an issue with cd .. command
2011/8/11 Nowres Rafid :
> here we change the "command"
>
> if (CompareStringW(LOCALE_USER_DEFAULT,
> NORM_IGNORECASE | SORT_STRINGSORT,
> command, 2, parmD, -1) == 2) {
> command += 2;
> while (*command && *command==' ') command++;
> }
>
> that's why I decided to change it too.
What I mean by constant is that the "WCHAR* command" contents isn't modified.
Here the "command" formal parameter is just a copy of caller's WCHAR
pointer, so you don't affect the caller by doing pointer arithmetic on
it (although using a local pointer would be clearer/better style), and
the actual contents isn't altered.
Frédéric
NB: You should leave wine-devel as Cc:
Re: cmd: an issue with cd .. command
2011/8/11 Nowres Rafid : > where is the code that eliminates extra spaces after normal directories > name? > (because "cd dir " works) Don't know. You'll have to find yourself, possibly by running with cmd debug channel and/or debugger Frédéric
Re: d3dx9: CloneMesh test and improvements
2011/8/11 Michael Mc Donnell : > > +dst_ptr[0] = src->x < 0.0f ? (SHORT)ceilf(src->x * SHRT_MAX + > 0.5f) :(SHORT)floorf(src->x * SHRT_MAX + 0.5f); You can use roundf() instead. Actually, notice that maybe what you actually need for correct rounding is rintf() (which essentially matches what D3DXFloat32To16Array does). You should probably test this (even on your own, not necessarily adding those to the testsuite, I'd say). Still on the conversion: going on with this "strategy" is going to require a ton of code to handle every src->dst format combination. You may look into doing that in two steps: first converting src to float4, then float4 into dst. I haven't looked into it, so there may be some detail making this impractical, but still it's worth a try, I guess.
Re: cmd: an issue with cd .. command
On Thu, Aug 11, 2011 at 05:19, Nowres Rafid wrote:
> Hello,
>
> the command "cd .. " doesn't work when there is extra spaces at the end.
>
> I propose this patch and ask for your confirmation about it.
>
> best regards.
}
else {
+
+/* Remove any space at the end of command
+This was because "cd .. " wasn't working */
+ {
+WCHAR *ptr = command + strlenW(command) - 1;
+
+while(*ptr == ' ')
+*ptr-- = 0;
+ }
You shouldn't modify the "command" parameter. This one ought to be
constant, even if it's not currently marked so.
It's better to change the "string" string.
Also you should add testcases to cmd's test suite, possibly as a
preliminary patch of a series, but it can also be together with the
patch. That's up to you.
Also for single patches, you don't need "[1/1]"... use git
format-patch "-k" option, or edit the subject before submission.
Frédéric
Re: cmd: an issue with cd .. command
You need to write tests for as many cases you can think of. eg cd ., cd .., some invalid directories and so on. Im not familiar with the cmd code but this feels like a bit of a hack. Jerome On Thu, Aug 11, 2011 at 6:19 AM, Nowres Rafid wrote: > Hello, > > the command "cd .. " doesn't work when there is extra spaces at the end. > > I propose this patch and ask for your confirmation about it. > > best regards. > > >
