cmd: an issue with cd .. command
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.
>From f4b4581273704ccf6e67f7595f1c3e4243ed7559 Mon Sep 17 00:00:00 2001
From: Nowres Rafid
Date: Thu, 11 Aug 2011 03:11:26 +
Subject: [1/1]cmd: trim whitespace at the end of cd command
---
programs/cmd/builtins.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/programs/cmd/builtins.c b/programs/cmd/builtins.c
index 09c166f..03b5445 100644
--- a/programs/cmd/builtins.c
+++ b/programs/cmd/builtins.c
@@ -2101,6 +2101,17 @@ void WCMD_setshow_default (WCHAR *command) {
WCMD_output (cwd);
}
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;
+ }
+
+
/* Remove any double quotes, which may be in the
middle, eg. cd "C:\Program Files"\Microsoft is ok */
pos = string;
--
1.7.4.1
Re: wined3d: Fix does not clip transformed vertices in z-direction
On 10 August 2011 17:35, Антон Ярцев wrote: > In some d3d9 2d-games, some sprites does not draws, or draws like thin line > because game use transformation for primitives, and z-coordinate(detected ~ > -700...+700 range) of vertices might be not in view volume as occurs. I'm pretty sure I've mentioned this before, but this clearly needs tests before you can even start thinking about a fix. As it is, the patch is simply wrong, it causes several test failures.
Re: [1/3] gdi32: Initial Gamma setting tests
On 8/11/2011 00:58, André Hentschel wrote:
---
dlls/gdi32/tests/dc.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/dlls/gdi32/tests/dc.c b/dlls/gdi32/tests/dc.c
index 5017583..f8ceccd 100644
--- a/dlls/gdi32/tests/dc.c
+++ b/dlls/gdi32/tests/dc.c
@@ -24,6 +24,7 @@
#include
#include
+#include "ddraw.h"
#include "wine/test.h"
#include "winbase.h"
#include "wingdi.h"
@@ -599,6 +600,44 @@ static void test_desktop_colorres(void)
ReleaseDC(NULL, hdc);
}
+static void test_gamma(void)
+{
+BOOL ret;
+HDC hdc = GetDC(NULL);
+DDGAMMARAMP oldramp;
I think it's better to use plain buffer for that to match prototype.
+
+ret = GetDeviceGammaRamp(hdc,&oldramp);
+
+if (ret)
+{
To avoid extra indentation level maybe just exit earlier..
+DDGAMMARAMP ramp;
+ZeroMemory(&ramp, sizeof(ramp));
+
+/* ramps are zero for every color */
+ret = SetDeviceGammaRamp(hdc,&ramp);
+todo_wine ok(!ret, "SetDeviceGammaRamp succeeded\n");
+
+/* set a ramp part at the end of every color to non-zero */
+ramp.red[255] = 1;
+ramp.green[255] = 1;
+ramp.blue[255] = 1;
+ret = SetDeviceGammaRamp(hdc,&ramp);
+todo_wine ok(!ret, "SetDeviceGammaRamp succeeded\n");
+
+/* set a ramp part in the middle of one color to non-zero */
+ramp.blue[127] = 1;
+ret = SetDeviceGammaRamp(hdc,&ramp);
+todo_wine ok(!ret, "SetDeviceGammaRamp succeeded\n");
+
This needs more tests, is it possible you can't have any zeros at all?
+/* cleanup: set old ramp */
+ret = SetDeviceGammaRamp(hdc,&oldramp);
+ok(ret || broken(!ret), "SetDeviceGammaRamp failed\n");
What a broken case is about?
+else win_skip("GetDeviceGammaRamp failed, skipping tests\n");
When it fails on native by the way?
+
+ReleaseDC(NULL, hdc);
+}
+
START_TEST(dc)
{
test_savedc();
@@ -609,4 +648,5 @@ START_TEST(dc)
test_DeleteDC();
test_boundsrect_invalid();
test_desktop_colorres();
+test_gamma();
}
re: Current state of USBD.SYS
> Louis wrote >> Our patches should already be available (Google for "Muse Research open >> source"; I can't recall the server it's on at the moment, but it should >> be >> in the "1.8" subdirectory). > > I think it's > ftp://ftp.museresearch.com/rpms/1.8/ > and in particular > ftp://anonymous+museresearch@ftp.museresearch.com/rpms/1.8/wine-1.1.7-muse16.fc8.src.rpm > - Dan > > p.s. > http://www.museresearch.com/support/receptor-faq.php > says > Q. If Receptor uses GPLed code, where can I download the source? > A. You can download all relevant Source Code here: > http://www.museresearch.com/support/receptor.php?r=src > but there's nothing there; the right url seems to be > http://www.muse.reprisesoftware.com/receptor.php?r=src > which points to the files. > Louis, maybe you could get the FAQ updated... > That'd be the one. IT has been moving files around, so I am not sure how permanent that particular Reprise Software link will be, but I'll make sure that they get the FAQ updated once they are finished. The direct ftp link will be your best bet. Louis
re: Current state of USBD.SYS
Louis wrote > Our patches should already be available (Google for "Muse Research open > source"; I can't recall the server it's on at the moment, but it should be > in the "1.8" subdirectory). I think it's ftp://ftp.museresearch.com/rpms/1.8/ and in particular ftp://anonymous+museresearch@ftp.museresearch.com/rpms/1.8/wine-1.1.7-muse16.fc8.src.rpm - Dan p.s. http://www.museresearch.com/support/receptor-faq.php says Q. If Receptor uses GPLed code, where can I download the source? A. You can download all relevant Source Code here: http://www.museresearch.com/support/receptor.php?r=src but there's nothing there; the right url seems to be http://www.muse.reprisesoftware.com/receptor.php?r=src which points to the files. Louis, maybe you could get the FAQ updated...
Re: gsoc mentor summit
On 27/07/2011 16:04, Stefan Dösinger wrote: Yes. I'd be interested as well, that's why I started this thread. I've been there already in 2009, so if anyone else wants to go I'd be happy to yield. 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. -- Owen Rudge http://www.owenrudge.net/
Re: Current state of USBD.SYS
> Yes, Wine added support for udev (because hal is now obsolute on most > Linux distributions), but AFAIK the plans were not to remove hal due > to backward compatibility. > No major changes to usbd.sys were made. Wine still doesn't detect USB > devices or load drivers or anything like that. OK, I guess I'll have to find a way to adapt our old patches for that then. >> Also what I'd like to find out is if there is maybe a cutting-edge >> usbd.sys module that hasn't made it into the development WINE branch. > > I have plans to write more usbd.sys stuff but nothing as of yet. Are > you planning to release your custom patches at some stage? Our patches should already be available (Google for "Muse Research open source"; I can't recall the server it's on at the moment, but it should be in the "1.8" subdirectory). I'm not sure how general-purpose the code is (I didn't write it). Louis
Re: Current state of USBD.SYS
On Wed, Aug 10, 2011 at 1:15 AM, wrote: > Hi, > I'm in the process of migrating custom patches made to WINE 1.1.7 to > WINE 1.3.24. Among those is USBD.SYS, which we use to run a Windows > driver for a specific USB device which has no equivalent Linux driver. > I was wondering what to expect from 1.3.24 as far as USB device > discovery and Windows driver support goes. For example, our older > patched version ties into Linux HAL to find devices, but there doesn't > *appear* to be the same functionality in this newer stock version. Does > anyone know what the goal of usbd.sys is in WINE 1.3.24? Yes, Wine added support for udev (because hal is now obsolute on most Linux distributions), but AFAIK the plans were not to remove hal due to backward compatibility. No major changes to usbd.sys were made. Wine still doesn't detect USB devices or load drivers or anything like that. > Also what I'd like to find out is if there is maybe a cutting-edge > usbd.sys module that hasn't made it into the development WINE branch. I have plans to write more usbd.sys stuff but nothing as of yet. Are you planning to release your custom patches at some stage? > Anyway, thanks for your time and any help is greatly appreciated, as always. > > -Louis Damjan
[PATCH] winealsa.drv: Fix AudioRenderClient write pointer calculation
Hi, The buffering code in winealsa & wineoss is still very complex and I've had a hard time following it. Because of the complexity, it's potentially error-prone. Here's an error: Consider this sequence of calls: BufferSize 100 GetBuffer(80) Release(80) pcm_write(50) => offs = 50, held = 30 (80-50) GetBuffer(30) (max 70) =>LOCKED_WRAPPED (because pos 80 + 30 is > 100) Release(30) => wrap_buffer 20 at end & 10 at beginning => offs = 50, held = 60 (note offs+held > 100) GetBuffer(10) (max 40) =>LOCKED_NORMAL (fits into primary) Release(10) =>computes buffer = offs+held = 50+60 = 110 > 100! =>illegal memory access An easy fix would be to correct buffer = This->local_buffer + +(This->lcl_offs_frames + This->held_frames) * This->fmt->nBlockAlign; into (offs+held %buffer_size) However are we sure that's all? I'd love to see the code as understandable as winecoreaudio (although I know there need be more state variables to handle the two buffers). Precisely because winecoreaudio is more readable I was able to fix the Get/ReleaseBuffer ordering issue, while ALSA and OSS are still waiting (waiting too for another patch to have GetCurrentPadding simply return held_frames on top of it). IOW, the winecoreaudio driver is the best of the three, receiving fixes written easily, while ALSA and OSS are lagging behind because it's tedious to patch them correctly. Regards, Jörg Höhle
