Re: New winetricks 20090902: new verbs vc2005trial, python26
Dan Kegel wrote: > vc2005trial is the 180 day Team Server edition of Visual C++ 2005. > The winetricks verb for this is a bit odd - it prompts you for > your password so it can mount the volume before installation. > If you have a better idea, please let me know. You can use fuseiso/fusermount to mount/umount iso images. Vitaliy.
Re: New winetricks 20090902: new verbs vc2005trial, python26
On Wed, Sep 2, 2009 at 9:36 PM, Dan Kegel wrote: > Another week, another winetricks. > > The only interesting changes are new verbs vc2005trial and python26. I lied -- there's one more interesting change. More verbs with prerequisites are now smart, and won't waste time installing already-installed prerequisites. (The vc2005trial verb had three prerequisites, and it was driving me nuts while testing.)
New winetricks 20090902: new verbs vc2005trial, python26
Another week, another winetricks. The only interesting changes are new verbs vc2005trial and python26. These are only of interest to developers. vc2005trial is the 180 day Team Server edition of Visual C++ 2005. The winetricks verb for this is a bit odd - it prompts you for your password so it can mount the volume before installation. If you have a better idea, please let me know. I haven't done a KDE version of the prompt; patches welcome. I also haven't implemented -q for this; it's hard to figure out, even with hints (see the comments). If anyone wants to tackle it, be my guest, I'd love to have unattended install working. The python26 verb includes pywin32, since that was needed by the script I was trying to run (the gyp self-test). Most people will just use Linux python, but when you're running a win32-specific python script, the windows python interpreter comes in pretty handy. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Thanks to Austin English for various patches and assistance.
Re: Asynchronus serial port
On Wed, Sep 2, 2009 at 7:31 PM, Fenixk19 wrote:
> Hello! I've already post the
> bug(http://bugs.winehq.org/show_bug.cgi?id=19713) on this subject, but i
> need more help. So I've decided to write here.
> There is a problem in wine. When I use asynchronous serial port read,
> data never comes. Event, caused by select comes. But operation status
> stays pending, and i can't do anything to this serial port anymore. In
> windows it never get pending, and port can be accessed just after data
> arrival. Seems to be wineserver problem, but i don't know, where to look
> at. What code respond for asynchronous serial port in wineserver?
> Alexander.
> P.S. Test program attached.
>
>
>
>
Hi,
Alexandre would be the guy to talk to about wineserver-related things.
Sadly he's off on a long weekend. Does the attached patch help solve
the problem?
Mike.
diff --git a/dlls/ntdll/serial.c b/dlls/ntdll/serial.c
index dfb00e1..2a448ed 100644
--- a/dlls/ntdll/serial.c
+++ b/dlls/ntdll/serial.c
@@ -851,6 +851,7 @@ typedef struct async_commio
{
HANDLE hDevice;
DWORD* events;
+IO_STATUS_BLOCK*iosb;
HANDLE hEvent;
DWORD evtmask;
DWORD mstat;
@@ -985,12 +986,14 @@ static DWORD CALLBACK wait_for_event(LPVOID arg)
}
if (needs_close) close( fd );
}
+if (commio->iosb)
+commio->iosb->u.Status = *commio->events ? STATUS_SUCCESS : STATUS_CANCELLED;
if (commio->hEvent) NtSetEvent(commio->hEvent, NULL);
RtlFreeHeap(GetProcessHeap(), 0, commio);
return 0;
}
-static NTSTATUS wait_on(HANDLE hDevice, int fd, HANDLE hEvent, DWORD* events)
+static NTSTATUS wait_on(HANDLE hDevice, int fd, HANDLE hEvent, PIO_STATUS_BLOCK piosb, DWORD* events)
{
async_commio* commio;
NTSTATUSstatus;
@@ -1003,6 +1006,7 @@ static NTSTATUS wait_on(HANDLE hDevice, int fd, HANDLE hEvent, DWORD* events)
commio->hDevice = hDevice;
commio->events = events;
+commio->iosb= piosb;
commio->hEvent = hEvent;
get_wait_mask(commio->hDevice, &commio->evtmask);
@@ -1301,7 +1305,7 @@ static inline NTSTATUS io_control(HANDLE hDevice,
case IOCTL_SERIAL_WAIT_ON_MASK:
if (lpOutBuffer && nOutBufferSize == sizeof(DWORD))
{
-if (!(status = wait_on(hDevice, fd, hEvent, lpOutBuffer)))
+if (!(status = wait_on(hDevice, fd, hEvent, piosb, lpOutBuffer)))
sz = sizeof(DWORD);
}
else
Re: Wine t-shirts?
Hi there, The T-shirt is finally on sale. We waited to have the Valgrind T-shirt ready to release both at the same time, as I guess many Wine lovers may also be Valgrind lovers. Direct link: http://www.freewear.org/?page=show_item&id=FW0030 If we have resources we'll try to upgrade our Wine catalog soon with other style of designs, stay tunned. Cheers, Ismael On Tue, Aug 4, 2009 at 11:45 PM, Ismael Barros² wrote: > Hi there, > > Sorry for the huge delay, our artist has been quite busy. We finally > got the last design iteration: > > http://www.freewear.org/images/release_candidates/Wine_final.png > > The only difference between versions A and B is in the eyes. Let us > know which one you like better, and any kind of comment or suggestion > is welcomed. After the design is approved, in one week we make have > the T-shirt available in the store. > > Cheers, > Ismael >
Asynchronus serial port
Hello! I've already post the
bug(http://bugs.winehq.org/show_bug.cgi?id=19713) on this subject, but i
need more help. So I've decided to write here.
There is a problem in wine. When I use asynchronous serial port read,
data never comes. Event, caused by select comes. But operation status
stays pending, and i can't do anything to this serial port anymore. In
windows it never get pending, and port can be accessed just after data
arrival. Seems to be wineserver problem, but i don't know, where to look
at. What code respond for asynchronous serial port in wineserver?
Alexander.
P.S. Test program attached.
#include
#include
int main()
{
HANDLE hSerial = CreateFile(".\\COM1", GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
DCB dcbSerialParams = {0};
dcbSerialParams.DCBlength=sizeof(dcbSerialParams);
dcbSerialParams.BaudRate=CBR_9600;
dcbSerialParams.ByteSize=8;
dcbSerialParams.StopBits=ONESTOPBIT;
dcbSerialParams.Parity=NOPARITY;
dcbSerialParams.fBinary = 1;
dcbSerialParams.fDtrControl = DTR_CONTROL_DISABLE;
dcbSerialParams.fRtsControl = RTS_CONTROL_DISABLE;
SetCommState(hSerial, &dcbSerialParams);
COMMTIMEOUTS timeouts={0};
timeouts.ReadIntervalTimeout=250;
timeouts.ReadTotalTimeoutConstant=250;
timeouts.ReadTotalTimeoutMultiplier=250;
timeouts.WriteTotalTimeoutMultiplier = timeouts.WriteTotalTimeoutConstant = 250;
SetCommTimeouts(hSerial, &timeouts);
SetupComm(hSerial, 1024, 1024);
PurgeComm(hSerial, PURGE_TXCLEAR | PURGE_RXCLEAR | PURGE_TXABORT | PURGE_RXABORT);
SetCommMask(hSerial, EV_RXCHAR);
int iters = 0;
DWORD dwResult = 0;
DWORD dwReadResult = 0;
DWORD dwOvRes = 0;
DWORD bOvResult = 0;
char buffer[2048];
DWORD dwRead = 0;
DWORD evtMask, dwError;
DWORD dwTest;
OVERLAPPED ovOverlapped;
ovOverlapped.Offset = ovOverlapped.OffsetHigh = 0;
ovOverlapped.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
BOOL bRes = WaitCommEvent(hSerial, &evtMask, &ovOverlapped);
if(!bRes)
{
dwError=GetLastError();
if (dwError == ERROR_IO_PENDING)
{
printf("dwError = ERROR_IO_PENDING\n");
printf("*** All preparations is done. Now we are gonna wait for event.\n");
dwResult = WaitForSingleObject(ovOverlapped.hEvent, INFINITE);
do
{
bOvResult = GetOverlappedResult(hSerial, &ovOverlapped, &dwOvRes, FALSE);
dwError=GetLastError();
printf("ovOverlapped.Internal = %lu\n", ovOverlapped.Internal);
printf("dwError = %d\n", dwError);
printf("bOvResult = %d\n", bOvResult);
if (bOvResult) break;
if(ovOverlapped.Internal==259)
printf("*** ovOverlapped.Internal==259. That means, that event is in progress. It is a bug. Because in windows it will never reach this point. It seems that data get stuck somewhere, but event is sent. If we try to read data, we'll get nothing.\n");
Sleep(500);
} while (dwError == ERROR_IO_INCOMPLETE);
if (bOvResult)
{
printf("*** All is done good. It means, that we are in Windows, or Wine is fixed(hope so).\n");
printf("OK.\n");
if (evtMask & EV_RXCHAR)
{
printf("EV_RXCHAR.\n");
}
} else
{
printf("BAD.\n");
}
}
}
return 0;
}
Re: [1/3] riched20: Implement handling of WM_KEYDOWN VK_RETURN in a dialog mode.
On Wed, Sep 2, 2009 at 1:34 PM, Sergey Khodych wrote: > >> 1. editor->hWnd may be NULL for windowless richedit controls, but you >> code doesn't seem to take that into consideration. >> 2. The style flags that you get from GetWindowLongW should probably >> come from the cached values in editor->styleFlags. > > The main reason why GetWindowLongW is used there is that editor->styleFlags > actually isn't window style and doesn't contain ES_WANTRETURN. What's the > proper way to get actually window style in this case? > editor->styleFlags should cache any window styles that are needed on window creation, but it seems ES_WANTRETURN was missed because it wasn't used and there was not ITextHost property to associate it with. This can be handled where the extended styles are obtained as shown in the following diff. I tested and made sure the ES_WANTRETURN style does get cached by native richedit by trying to change it with SetWindowLong, so this is necessary. diff --git a/dlls/riched20/txthost.c b/dlls/riched20/txthost.c index ddf3d76..d3a7330 100644 --- a/dlls/riched20/txthost.c +++ b/dlls/riched20/txthost.c @@ -58,6 +58,7 @@ ITextHost *ME_CreateTextHost(HWND hwnd, BOOL bEmulateVersion10) texthost->bEmulateVersion10 = bEmulateVersion10; editor = ME_MakeEditor((ITextHost*)texthost, bEmulateVersion10); +editor->styleFlags |= GetWindowLongW(hwnd, GWL_STYLE) & ES_WANTRETURN; editor->exStyleFlags = GetWindowLongW(hwnd, GWL_EXSTYLE); editor->hWnd = hwnd; /* FIXME: Remove editor's dependence on hWnd */ SetWindowLongPtrW(hwnd, 0, (LONG_PTR)editor);
Re: [1/3] riched20: Implement handling of WM_KEYDOWN VK_RETURN in a dialog mode.
1. editor->hWnd may be NULL for windowless richedit controls, but you code doesn't seem to take that into consideration. 2. The style flags that you get from GetWindowLongW should probably come from the cached values in editor->styleFlags. The main reason why GetWindowLongW is used there is that editor->styleFlags actually isn't window style and doesn't contain ES_WANTRETURN. What's the proper way to get actually window style in this case?
Re: [PATCH 5/5] wined3d: Print a warning when an ARB program exceeds the native resource limits.
Am Wednesday 02 September 2009 15:07:42 schrieb Henri Verbeet: > > That said, I haven't seen a GL implementation yet that successfully > > compiles and SW-emulates a program that exceeds the limits. > > It isn't necessarily a problem when this happens, it's more meant as a > diagnostic while debugging. Well, its most likely going to bring performance down to unplayable levels, but using it just as diagnostics is fine with me
Re: gdiplus/tests: Fix test on Win7
Eh never mind, I'll do it. On Wed, Sep 2, 2009 at 9:22 AM, Vincent Povirk wrote: > - gdiplusStartupInput.GdiplusVersion = 2; > + gdiplusStartupInput.GdiplusVersion = 42; > > Could you please test the intermediate versions to determine what's > supported? You could use a loop to determine the highest supported > version (making sure the return is UnsupportedGdiplusVersion if it's > not Ok) followed by a test that the highest supported version is > between 1 and some constant. > > In fact, knowing the supported version would be helpful in any case, > and it would be nice to have a trace() printing it. > > On Wed, Sep 2, 2009 at 5:16 AM, Ge van Geldorp wrote: >> Changelog: >> gdiplus/tests: Fix test on Win7 >> >> --- >> dlls/gdiplus/tests/pen.c | 5 +++-- >> 1 files changed, 3 insertions(+), 2 deletions(-) >> >> >> >> >> >> >> > > > > -- > Vincent Povirk > -- Vincent Povirk
Re: gdiplus/tests: Fix test on Win7
-gdiplusStartupInput.GdiplusVersion = 2; +gdiplusStartupInput.GdiplusVersion = 42; Could you please test the intermediate versions to determine what's supported? You could use a loop to determine the highest supported version (making sure the return is UnsupportedGdiplusVersion if it's not Ok) followed by a test that the highest supported version is between 1 and some constant. In fact, knowing the supported version would be helpful in any case, and it would be nice to have a trace() printing it. On Wed, Sep 2, 2009 at 5:16 AM, Ge van Geldorp wrote: > Changelog: > gdiplus/tests: Fix test on Win7 > > --- > dlls/gdiplus/tests/pen.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > > > > > > -- Vincent Povirk
Re: [PATCH 5/5] wined3d: Print a warning when an ARB program exceeds the native resource limits.
2009/9/2 Stefan Dösinger :
> Am Wednesday 02 September 2009 09:27:58 schrieb Henri Verbeet:
>> + GL_EXTCALL(glGetProgramivARB(GL_FRAGMENT_PROGRAM_ARB,
>> GL_PROGRAM_UNDER_NATIVE_LIMITS_ARB, &native)); +
>> checkGLcall("glGetProgramivARB()");
>> + if (!native) WARN("Program exceeds native resource limits.\n");
>> + }
> shouldn't that be a FIXME? The most likely reasons for this are either that we
> advertise incorrect caps, or our privately added code breaks the limits, or
> that the driver is broken. In the first two cases we can do something, and in
> the other case we might want to report the issue to the driver devs
>
> That said, I haven't seen a GL implementation yet that successfully compiles
> and SW-emulates a program that exceeds the limits.
>
It isn't necessarily a problem when this happens, it's more meant as a
diagnostic while debugging.
Re: [PATCH 5/5] wined3d: Print a warning when an ARB program exceeds the native resource limits.
Am Wednesday 02 September 2009 09:27:58 schrieb Henri Verbeet:
> +GL_EXTCALL(glGetProgramivARB(GL_FRAGMENT_PROGRAM_ARB,
> GL_PROGRAM_UNDER_NATIVE_LIMITS_ARB, &native)); +
> checkGLcall("glGetProgramivARB()");
> +if (!native) WARN("Program exceeds native resource limits.\n");
> +}
shouldn't that be a FIXME? The most likely reasons for this are either that we
advertise incorrect caps, or our privately added code breaks the limits, or
that the driver is broken. In the first two cases we can do something, and in
the other case we might want to report the issue to the driver devs
That said, I haven't seen a GL implementation yet that successfully compiles
and SW-emulates a program that exceeds the limits.
Re: [PATCH 1/3] jscript: Added to_primitive on hosting objects test.
Jacek Caban writes: > --- > dlls/jscript/tests/run.c | 32 > 1 files changed, 28 insertions(+), 4 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M jscript.dll -T ../../.. -p jscript_test.exe.so run.c && touch run.ok run.c:216: Test failed: V_VT(pvarRes) = 63784 make[2]: *** [run.ok] Error 1 -- Alexandre Julliard julli...@winehq.org
Re: Mirror Space
2009/9/2 David Gerard : > 2009/9/2 Scott Ritchie : > >> I don't think it's worth bothering to set that up, as my medium term >> plan is to migrate users to a real Launchpad PPA for Ubuntu 9.10. In >> 9.10, it'll actually be much easier to add PPAs (and their unique key), >> so I can cut the instructions on the download page dramatically. >> Launchpad has that sophisticated mirroring infrastructure already. > > > Oh yes,that's the obvious answer :-) I assume you'll still be putting > Debian builds on wine.budgetdedicated.com? (Or can Debian feed from an > Ubuntu PPA as well?) Scott's not doing the Debian packages any more; that's my job (with Maurilio providing the space for the repository and archives). I'd welcome a Debian package apt mirror, but I don't think Debian likes PPA.
Re: Mirror Space
2009/9/2 Scott Ritchie : > I don't think it's worth bothering to set that up, as my medium term > plan is to migrate users to a real Launchpad PPA for Ubuntu 9.10. In > 9.10, it'll actually be much easier to add PPAs (and their unique key), > so I can cut the instructions on the download page dramatically. > Launchpad has that sophisticated mirroring infrastructure already. Oh yes,that's the obvious answer :-) I assume you'll still be putting Debian builds on wine.budgetdedicated.com? (Or can Debian feed from an Ubuntu PPA as well?) - d.
