cvs [update aborted]: request `update_template' not supported by server
by Shachar Shemesh 05 Aug '02
by Shachar Shemesh 05 Aug '02
05 Aug '02
When trying to perform CVS operations on the WINE build from Solaris, I
get the above mentioned error:
cvs [update aborted]: request `update_template' not supported by server
I am using cvs version 1.10.1
Anyone here knows what the problem is?
Shachar
1
0
Hi,
While hunting down a function to get the HWND associated to a DC (I found it
'WindowFromDC'), I looked at the GetDCEx code, and found this :
dce->DCXflags |= DCX_DCEBUSY;
(...)
if (!USER_Driver.pGetDC( hwnd, hdc, hrgnClip, flags )) hdc = 0;
In that case, shouldn't the DCEBUSY flag be 'unset' or something ? I did not
submit a patch because I did not know if unsetting would have been enough or
if DCE_ReleaseDC should have been called (and, yes, I know, the pGetDC
cannot ever return FALSE in the X11 driver, but well, if the error code
exists, we should write it properly :-) ).
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
1
0
Hi,
According to WRT [1], one of todays patches caused a regression error,
picked up by one of the wininet DLL tests. Only, none of the patches seem
to have touched wininet.
The problem is with the tests at dlls/wininet/tests/http.c lines 117 and
157. The test freezes for up to 4 minutes, then returns the failures.
As an act in desperation, I've tried reversing some of the patches (1-4,
6, and 7 from the WRT list) without success.
I'm also a little suspicious that this might be something to do with
Glasgow (or me :) I've been able to reproduce the problem on two other
(local) machines, but I've not tried on any remote machines. I've also
tried using earlier cvs versions (from a few days ago), but that build
fails the wininet tests too. It would be good if someone could confirm the
problem.
Sorry if this turns out to be a red herring ...
Paul.
PS It's quite late here, so I might not be able to reply until tomorrow.
[1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php
----
Paul Millar
3
8
I am also Cc:ing this patch to wine-devel because I think it shows that
there is an issue that deserves a bit of thought: Code formatting.
We certainly should not get anal rentative on this, but something like
int trn = 1234,i=0;
from files/smb.c where even a single line is inconsistent really
makes me wonder.
Also I am not aware of any coding style that asks for blanks around the
assignment but does not use a blank after the comma.
The patch below fixes at least the worst problems, by consistently using
a blank after a comma in variable declarations.
Gerald
ChangeLog:
Fix formatting of variable declarations.
Index: smb.c
===================================================================
RCS file: /home/wine/wine/files/smb.c,v
retrieving revision 1.8
diff -u -3 -p -r1.8 smb.c
--- smb.c 19 Jul 2002 03:17:19 -0000 1.8
+++ smb.c 4 Aug 2002 17:35:54 -0000
@@ -123,7 +123,7 @@ struct NB_Buffer
static int netbios_name(const char *p, unsigned char *buffer)
{
char ch;
- int i,len=0;
+ int i, len=0;
buffer[len++]=' ';
for(i=0; i<=MAX_HOST_NAME; i++)
@@ -146,7 +146,7 @@ static int netbios_name(const char *p, u
static DWORD NB_NameReq(LPCSTR host, unsigned char *buffer, int len)
{
- int trn = 1234,i=0;
+ int trn = 1234, i=0;
NBR_ADDWORD(&buffer[i],trn); i+=2;
NBR_ADDWORD(&buffer[i],0x0110); i+=2;
@@ -203,9 +203,9 @@ static BOOL UNC_SplitName(LPSTR unc, LPS
static BOOL NB_Lookup(LPCSTR host, struct sockaddr_in *addr)
{
- int fd,on=1,r,len,i,fromsize;
+ int fd, on=1, r, len, i, fromsize;
struct pollfd fds;
- struct sockaddr_in sin,fromaddr;
+ struct sockaddr_in sin, fromaddr;
unsigned char buffer[256];
fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
@@ -288,7 +288,7 @@ err:
static BOOL NB_SessionReq(int fd, char *called, char *calling)
{
unsigned char buffer[0x100];
- int len = 0,r;
+ int len = 0, r;
struct pollfd fds;
TRACE("called %s, calling %s\n",called,calling);
@@ -571,7 +571,7 @@ static BOOL SMB_NegotiateProtocol(int fd
static BOOL SMB_SessionSetup(int fd, USHORT *userid)
{
unsigned char buf[0x100];
- int pcount,bcount;
+ int pcount, bcount;
struct NB_Buffer rx, tx;
memset(buf,0,sizeof buf);
@@ -667,7 +667,7 @@ static BOOL SMB_TreeConnect(int fd, USHO
{
unsigned char buf[0x100];
int slen;
- struct NB_Buffer rx,tx;
+ struct NB_Buffer rx, tx;
TRACE("%s\n",share_name);
@@ -731,7 +731,7 @@ static BOOL SMB_NtCreateOpen(int fd, USH
DWORD attributes, HANDLE template, USHORT *file_id )
{
unsigned char buffer[0x100];
- int len = 0,slen;
+ int len = 0, slen;
TRACE("%s\n",filename);
@@ -886,9 +886,9 @@ static BOOL SMB_Open(int fd, USHORT tree
DWORD creation, DWORD attributes, USHORT *file_id )
{
unsigned char buf[0x100];
- int slen,pcount,i;
+ int slen, pcount, i;
USHORT mode = SMB_GetMode(access,sharing);
- struct NB_Buffer rx,tx;
+ struct NB_Buffer rx, tx;
TRACE("%s\n",filename);
@@ -944,8 +944,8 @@ static BOOL SMB_Open(int fd, USHORT tree
static BOOL SMB_Read(int fd, USHORT tree_id, USHORT user_id, USHORT dialect,
USHORT file_id, DWORD offset, LPVOID out, USHORT count, LPUSHORT read)
{
- int buf_size,n,i;
- struct NB_Buffer rx,tx;
+ int buf_size, n, i;
+ struct NB_Buffer rx, tx;
TRACE("user %04x tree %04x file %04x count %04x offset %08lx\n",
user_id, tree_id, file_id, count, offset);
@@ -1285,7 +1285,7 @@ done:
static int SMB_GetSocket(LPCSTR host)
{
- int fd=-1,r;
+ int fd=-1, r;
struct sockaddr_in sin;
struct hostent *he;
@@ -1390,7 +1390,7 @@ HANDLE WINAPI SMB_CreateFileA( LPCSTR un
{
int fd;
USHORT tree_id=0, user_id=0, dialect=0, file_id=0;
- LPSTR name,host,share,file;
+ LPSTR name, host, share, file;
HANDLE handle = INVALID_HANDLE_VALUE;
name = HeapAlloc(GetProcessHeap(),0,lstrlenA(uncname));
@@ -1540,7 +1540,7 @@ BOOL WINAPI SMB_ReadFile(HANDLE hFile, L
SMB_DIR* WINAPI SMB_FindFirst(LPCSTR name)
{
int fd = -1;
- LPSTR host,share,file;
+ LPSTR host, share, file;
USHORT tree_id=0, user_id=0, dialect=0;
SMB_DIR *ret = NULL;
LPSTR filename;
1
0
On Sat, 3 Aug 2002, Lionel Ulmer wrote:
> This should hopefully fix bug :
> Bug 936 - Incorrect placement of DirectDraw output (offset outside the Windows 'window')
>
> Basically, the logic to compute the clipping window was wrong (or at least I
> did not understand all the subtilities of the code :-) ). At least with this
> fix, this particular application now runs fine.
I'm 99% sure I fixed this in my last patch submission to winehq a while
ago. Seems Alexandre applied it after 20020710, though. So I don't think
your patch applies on top of CVS.
2
1
Howdy,
I just built a new CVS version--the first one in a while. I got
caught by the -managed and the -winver options going away--a little
searching through the list archives, and the problems were solved!
Anyhow, I generally run with two instances of Forte Agent v1.9 open.
Since I've built the new CVS, there's a change in behavior that I
thought I'd the devel community know about. When pressing the
shortcut buttons on the Agent instance that was first opened, nothing
happened. When pressing on the buttons in the second instance, they
worked normally. I closed the second instance, and the buttons in the
first instance now work normally.
Perhaps the messages are being captured and sent to the wrong place?
(They're not being sent to the wrong instance of Agent.) Also there
was no obvious output messages in the console window.
That's the only change in behavior I've found so far. It still runs
great. Thanks to the devel community!
Oliver
====================================================
Oliver Sampson
olsam(a)quickaudio.com
http://www.oliversampson.com
1
1
DJ Lucas wrote:
>I dont' know if this has been brought up before or not, haven't searched
>the archives or anything, but this seems to be dependant on how perl was
>installed.
>
>For some reason, when perl, 5.6.1 or 5.8.0 is configured with
>./configure.gnu, when you go to build wine, in the winetest Makefile,
>the ccflags variable (leftover from perl install) is included in
>LDFLAGS. Obviously this is in error, but attempting to figure out if
>this should be brought to Wine or Perl Developers. :-$ See the
>following URLs for archives of the LFS mailing lists where this has been
>previously discussed. The second seems to be more relevant.
>
>http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/07/0547.h
>tml
>
>http://archive.linuxfromscratch.org/mail-archives/blfs-support/2002/08/0
>024.html
>
>Thanks in advance
>
>DJ Lucas
>
>PS, if this has been previously identified, please CC me in the first
>reply, no need to flood the mailing list. ;-)
>
>
>
>
>
This issue seems to be delt with in bug 787 and there is even a patch
for it.
http://bugs.winehq.com/show_bug.cgi?id=787
It seems this patch is not in CVS and I do not recall it being submitted
to wine patches either. Any coment?
This patch is from Mike Castle dalgoda(a)ix.netcom.com
Index: winetest.c
===================================================================
RCS file: /home/wine/wine/programs/winetest/winetest.c,v
retrieving revision 1.5
diff -u -r1.5 winetest.c
--- winetest.c 10 Mar 2002 00:21:20 -0000 1.5
+++ winetest.c 1 Aug 2002 20:38:29 -0000
@@ -152,7 +152,7 @@
/* perl extension initialisation */
-static void xs_init(void)
+static void xs_init(pTHX)
{
extern void boot_wine(CV *cv);
newXS("wine::bootstrap", boot_wine,__FILE__);
2
1
Hi!
Some time ago I did send the rpcrt patches from ove ported to the cvs.
It didn't got included. Are there any special reasons?
The epmapper was implemented in the wineserver. Should it be a standalone server?
1) If it would be a win32 process we would need 2 context changes for every call. If it would be a server like the wine-server there would only be 1 context change per call.
2) What IPC should we use locally? We could implement LPC like reactos.
3) We need a process for managing services and COM out-of-process servers (the SCM). Any ideas how to do this?
To many questions for one mail? ;-)
juergen
2
1
Looks like a window what is in destruction gets the focus from WINPOS_ActivateOtherWindow and don't like it...
juergen
08073ff8:Call user32.DestroyWindow(00010022) ret=5d34c141
trace:win:DestroyWindow (10022)
08073ff8:Call x11drv.ResetSelectionOwner(00010022,00000000) ret=4069f640
08073ff8:Ret x11drv.ResetSelectionOwner() retval=02800003 ret=4069f640
08073ff8:Call x11drv.ShowWindow(00010022,00000000) ret=406a4127
08073ff8:Ret x11drv.ShowWindow() retval=00000000 ret=406a4127
trace:win:DestroyWindow (10024)
08073ff8:Call x11drv.ResetSelectionOwner(00010024,00000000) ret=4069f640
08073ff8:Ret x11drv.ResetSelectionOwner() retval=02800007 ret=4069f640
08073ff8:Call x11drv.ShowWindow(00010024,00000000) ret=406a4127
08073ff8:Ret x11drv.ShowWindow() retval=00000000 ret=406a4127
trace:win:WINPOS_SetActiveWindow (10022, 0, 1)
trace:win:WINPOS_SetActiveWindow no current active window.
08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000)
08073ff8:Call user32.GetWindow(00010025,00000005) ret=5d30c073
08073ff8:Ret user32.GetWindow() retval=00000000 ret=5d30c073
08073ff8:Call user32.SendMessageA(00010025,0000030f,00000000,00000000) ret=5d30c0be
08073ff8:Call window proc 0x5d34dfc9 (hwnd=00010025,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000)
08073ff8:Call user32.DefWindowProcW(00010025,0000030f,00000000,00000000) ret=5d34e274
08073ff8:Ret user32.DefWindowProcW() retval=00000000 ret=5d34e274
08073ff8:Ret window proc 0x5d34dfc9 (hwnd=00010025,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000) retval=00000000
08073ff8:Ret user32.SendMessageA() retval=00000000 ret=5d30c0be
08073ff8:Call user32.DefWindowProcA(00010022,0000030f,00000000,00000000) ret=5d34c99a
08073ff8:Ret user32.DefWindowProcA() retval=00000000 ret=5d34c99a
08073ff8:Ret window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000) retval=00000000
08073ff8:Call window proc 0x42f35c40 (hwnd=00010024,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000)
08073ff8:Call user32.GetWindowLongA(00010024,00000000) ret=42f35c91
08073ff8:Ret user32.GetWindowLongA() retval=42ff0408 ret=42f35c91
08073ff8:Call user32.DefWindowProcA(00010024,0000001c,00000001,00000000) ret=42f36426
08073ff8:Ret user32.DefWindowProcA() retval=00000000 ret=42f36426
08073ff8:Ret window proc 0x42f35c40 (hwnd=00010024,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) retval=00000000
08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000)
08073ff8:Call user32.DefWindowProcA(00010022,0000001c,00000001,00000000) ret=5d34c99a
08073ff8:Ret user32.DefWindowProcA() retval=00000000 ret=5d34c99a
08073ff8:Ret window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) retval=00000000
08073ff8:Call window proc 0x77a67048 (hwnd=00010021,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000)
08073ff8:Call user32.DefWindowProcW(00010021,0000001c,00000001,00000000) ret=77a67087
08073ff8:Ret user32.DefWindowProcW() retval=00000000 ret=77a67087
08073ff8:Ret window proc 0x77a67048 (hwnd=00010021,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) retval=00000000
08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_NCACTIVATE,wp=00000001,lp=00000000)
08073ff8:Call user32.DefWindowProcA(00010022,00000086,00000001,00000000) ret=5d34c99a
08073ff8:Ret user32.DefWindowProcA() retval=00000001 ret=5d34c99a
08073ff8:Ret window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_NCACTIVATE,wp=00000001,lp=00000000) retval=00000001
08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_ACTIVATE,wp=00000001,lp=00000000)
08073ff8:Call kernel32.GetLastError() ret=00402238
08073ff8:Ret kernel32.GetLastError() retval=00000578 ret=00402238
08073ff8:Call kernel32.TlsGetValue(00000000) ret=00402246
08073ff8:Ret kernel32.TlsGetValue() retval=429e0100 ret=00402246
08073ff8:Call kernel32.SetLastError(00000578) ret=0040229a
08073ff8:Ret kernel32.SetLastError() retval=00000578 ret=0040229a
08073ff8:Call kernel32.UnhandledExceptionFilter(40464900) ret=0040172a
=>0 0x5d30bf01 (HHCTRL.OCX..text+0xaf01 in C:\WINNT\SYSTEM32\HHCTRL.OCX) (ebp=40575064)
1 0x5d34c7b2 (HHCTRL.OCX.DllGetClassObject+0x22159 in C:\WINNT\SYSTEM32\HHCTRL.OCX) (ebp=405760fc)
2 0x406a54db (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=40576120)
3 0x406a557e (WINPROC_CallWndProc+0x8e(proc=0x5d34c6f6, hwnd=0x10022, msg=0x6, wParam=0x1, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=40576150)
4 0x406ab84b (CallWindowProcA+0x3b(func=0x5d34c6f6, hwnd=0x10022, msg=0x6, wParam=0x1, lParam=0x0) [winproc.c:2779] in user32.dll.so) (ebp=40576178)
5 0x406bb830 (call_window_proc+0x100(hwnd=0x10022, msg=0x6, wparam=0x1, lparam=0x0, unicode=0x0) [message.c:1372] in user32.dll.so) (ebp=405761c8)
6 0x406bc4f8 (SendMessageTimeoutA+0xe8(hwnd=0x10022, msg=0x6, wparam=0x1, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x40576250, hwnd=0x10022) [message.c:1784] in user32.dll.so) (ebp=40576220)
7 0x406bc679 (SendMessageA+0x39(hwnd=0x10022, msg=0x6, wparam=0x1, lparam=0x0) [message.c:1829] in user32.dll.so) (ebp=40576254)
8 0x406a4a96 (WINPOS_SetActiveWindow+0x476(hWnd=0x10022, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1359] in user32.dll.so) (ebp=405762a0)
9 0x406a39c1 (SetActiveWindow+0xd1(hwnd=0x10022) [winpos.c:723] in user32.dll.so) (ebp=405762d0)
10 0x406a4cfd (WINPOS_ActivateOtherWindow+0x13d(hwnd=0x10024) [winpos.c:1463] in user32.dll.so) (ebp=405762f0)
11 0x4069f6f6 (DestroyWindow+0x1f6(hwnd=0x10024) [win.c:1504] in user32.dll.so) (ebp=4057630c)
12 0x4069f6b6 (DestroyWindow+0x1b6(hwnd=0x10022) [win.c:1492] in user32.dll.so) (ebp=40576328)
13 0x5d34c141 (HHCTRL.OCX.DllGetClassObject+0x21ae8 in C:\WINNT\SYSTEM32\HHCTRL.OCX) (ebp=4057690c)
1
0
Hello All,
Last week I sent an email about a problem with a serial printer that
used DTS/DTR hardware flow control.
I later understood that DTS/DTR was not supported in linux , and
therefore not in wine. Linux [and wine] support RTS/CTS hardware flow control.
Since the protocols are similar, an ideia that I received was to construct a
cable that made the computer think it was using RTS/CTS and the printer think it
was using DTR/DTS.
Today, I received the cable from the printer manufacturer and the initial tests
with wine/linux worked.
****************************
RTS - Ready To Send
CTS - Clear To Send
DTR - Data Terminal Ready
DSR - Data Set Ready
****************************
Here is a snippet of mytestapp --debugmsg +comm
trace:comm:COMM_Init COM1 = /dev/ttyS0
trace:comm:COMM_Init LPT1 = /dev/lp0
trace:comm:COMM_Init COM2 = /dev/ttyS1
trace:comm:COMM_Init COM3 = /dev/ttyS2
trace:comm:COMM_Init COM4 = /dev/modem
trace:comm:BuildCommDCBAndTimeoutsA (COM2:9600,N,8,1,0x4002af48,(nil))
trace:comm:COMM_BuildOldCommDCB (COM2:9600,N,8,1), ptr 0x4002af48
trace:comm:COMM_BuildOldCommDCB baudrate (9600)
trace:comm:COMM_BuildOldCommDCB parity (N)
trace:comm:COMM_BuildOldCommDCB charsize (8)
trace:comm:COMM_BuildOldCommDCB stopbits (1)
trace:comm:SetCommState handle 52, ptr 0x4002af48
trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1
trace:comm:SetCommState ~IXON ~IXOFF
trace:comm:SetCommState CRTSCTS
trace:comm:SetCommMask handle 52, mask 10
Thanks every one from wine-devel for all the prompt answers I received.
Miguel Feitosa
-------------------------------------------------
This mail sent through IMP: webmail.vmn.com.br
2
1