August 2001 - Wine-devel - list.winehq.org

Re: documentation make fix
by Mike McCormack 21 Aug '01

21 Aug '01

Yeah, that looks better, and seems to work too. thanks, Mike Original message from: Francois Gouget <fgouget(a)free.fr> > >On Tue, 21 Aug 2001, Mike McCormack wrote: > >> >> Not that anybody uses the documentation anyway... :-) >> >> ChangeLog: >> * recurse all directories when making docs. >> Don't fail if C_SRCS is empty. > > Maybe the attached patch would be a better way to do this: > - use the regular make trick for recursing > - test whether we have targets before entering the for loop > > Note that I did not really test it. > > > Well, I have done a little testing now. And c2man is not happy if you >don't create documentation/man3w beforehand... > So I added an mkdir too, same for doc-html. > > >-- >Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > "Utilisateur" (nom commun) : > Mot utilis� par les informaticiens en lieu et place d'"idiot". ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: reaktivate
by Malte Starostik 21 Aug '01

21 Aug '01

Am Montag, 20. August 2001 08:59 schrieb Per Wigren: > I get this when I'm trying to load an Active-X component in konqueror: > > konqueror: /usr/lib/libreaktivate: could not load library > '/usr/lib/libreaktivate.so' as Winelib application: > /usr/X11R6/lib/libXv.so.1: undefined symbol: XGetErrorDatabaseText > > Any ideas what to do? Using cvs from today of both wine and reaktivate. Never seen that one before, but it's IMHO rather a wine problem. Has anyone seen this before? Or, did you by any chance update some but not all X libraries? -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787]

1 0

Re: ReadFile and other issues
by Alexandre Julliard 21 Aug '01

21 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > no, reading of input_records would be sone as it is today, with > the specific console request 'read_console_input' OK, we agree then. > the only thing we'd have to have is another request to get the fd from > a console input handle (get_handle_fd would no longer work), and we > still need a (background) mechanism to convert the unix xterm characters > into INPUT_RECORD (a get_console_fd should do). Anyway, those fd are > even rather static (they only change on Alloc|Free Console and at > process startup if we inherit them from parent), so we can savely keep > them around, process wide I'm not sure we should be converting xterm input into INPUT_RECORD. It may be better to have two modes, a simple console that returns an fd to ReadFile and no input records (and then ReadConsoleInput could generate them on the fly if necessary), and a complex console that supports all the features but that doesn't have an associated fd at all. IMO the current xterm-based console support is a ugly hack; we should do a proper Windows console using a normal Wine window with a message loop to retrieve input events. And usage of stdin/stdout should be limited to programs that don't need special console features, and should only support ReadFile/WriteFile. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: ReadFile and other issues
by Alexandre Julliard 21 Aug '01

21 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > to implement properly this (mainly the ability to forward ReadFile calls > to ReadConsole for console handles), I'd like to do the following: > - extend the get_handle_fd to also return an id corresponding to the > type fd being used. As of today, handle / fd relationship mainly > assumes that we can map a Windows operation on a handle onto a similar > operation on a unix fd. The ReadFile/ReadConsoleInput doesn't fit in > this category. I'm not sure I understand you right; are you suggesting that get_handle_fd should return an fd from which you can read input records in the case of a console? It would seem preferable to have get_handle_fd simply fail with a special error code saying that the handle is a console, and then ReadFile can fall back to using ReadConsoleInput which doesn't require an fd at all. > - this type of feature would help in other areas too. For example, we > never check that Comm functions really get a Comm handle... Well, we check by the fact that we then do a serial ioctl on the fd, which will fail if it isn't serial. I'm not sure we need more checks. -- Alexandre Julliard julliard(a)winehq.com

2 1

Archive of overlapped serial I/O example code, experiences
by Dan Kegel 21 Aug '01

21 Aug '01

For what it's worth, here is some example test code I wrote for win32 demoing overlapped serial I/O: http://www.alumni.caltech.edu/~dank/serio/serio.zip It might be of some use to people testing wine. I haven't tried it yet there. Also, http://www.alumni.caltech.edu/~dank/overlap.htm chronicles the problems many people have had with serial I/O under win95. The messages there get into interesting details of how people use overlapped serial I/O, and how serial I/O really behaves under various flavors of windows. Again, might be of some use, who knows. - Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

1 0

ReadFile and other issues
by eric pouech 21 Aug '01

21 Aug '01

while we're at talking about the ReadFile implementation with overlapped data, there's (an unrelated) point about ReadFile I'd like to discuss I've started looking at implementing proper console input in Wine (mainly the line mode editing). Apart from providing the functionnality, it would also allow to remove this unneeded code from the debugger the Win32 console input API is made of two layers 1/ the low level : each input event is stored into an INPUT_RECORD struct 2/ the high level which uses the low level events to make strings of them 1/ two functions are used: ReadConsoleInput(A|W) 2/ three functions are used: ReadFile and ReadConsole(A|W) the current implementation in Wine, makes the handle to the console input a file handle to the fd gotten from the console hence, the current implementation is broken in several ways - ReadFile is implemented as a raw read on the input fd, whereas it should be a higher level of function (forwarded from ReadFile to ReadConsole) - wait operations on handle are wrong: currently the handle is signaled as soon as a char is read (at the unix level) from the stdin fd, whereas it should be done at the level of the INPUT_RECORD queue to implement properly this (mainly the ability to forward ReadFile calls to ReadConsole for console handles), I'd like to do the following: - extend the get_handle_fd to also return an id corresponding to the type fd being used. As of today, handle / fd relationship mainly assumes that we can map a Windows operation on a handle onto a similar operation on a unix fd. The ReadFile/ReadConsoleInput doesn't fit in this category. - this type of feature would help in other areas too. For example, we never check that Comm functions really get a Comm handle... would such a mechanism be acceptable ? if so, should we do for every handle in the server, or just the ones we might convert into unix fd (file, consoles, pipes, sockets, "serials"...) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: icons uncoloured
by Gerard Patel 21 Aug '01

21 Aug '01

At 01:39 PM 21/08/2001 GMT, you wrote: >I've just done a cvs update and recompiled and now the icons come up in >gray, if at all. > >Is this a known issue? I suspect it could be solved by this one I just sent to wine-patches Gerard Index: graphics/x11drv/bitmap.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/bitmap.c,v retrieving revision 1.32 diff -u -r1.32 bitmap.c --- graphics/x11drv/bitmap.c 2001/08/20 19:19:18 1.32 +++ graphics/x11drv/bitmap.c 2001/08/21 14:17:07 @@ -73,7 +73,7 @@ if (hbitmap == dc->hBitmap) return hbitmap; /* nothing to do */ if (!(bmp = GDI_GetObjPtr( hbitmap, BITMAP_MAGIC ))) return 0; - if (bmp->header.dwCount) + if (bmp->header.dwCount && (hbitmap != GetStockObject(DEFAULT_BITMAP))) { WARN( "Bitmap already selected in another DC\n" ); GDI_ReleaseObj( hbitmap ); ~ ~

2 1

icons uncoloured
by Bill Medland 21 Aug '01

21 Aug '01

I've just done a cvs update and recompiled and now the icons come up in gray, if at all. Is this a known issue? Bill

1 0

Re: documentation make fix
by Francois Gouget 21 Aug '01

21 Aug '01

On Tue, 21 Aug 2001, Mike McCormack wrote: > > Not that anybody uses the documentation anyway... :-) > > ChangeLog: > * recurse all directories when making docs. > Don't fail if C_SRCS is empty. Maybe the attached patch would be a better way to do this: - use the regular make trick for recursing - test whether we have targets before entering the for loop Note that I did not really test it. Well, I have done a little testing now. And c2man is not happy if you don't create documentation/man3w beforehand... So I added an mkdir too, same for doc-html. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

1 0

Re: fix for Lawson's CLOCAL problem
by Mike McCormack 21 Aug '01

21 Aug '01

Hi Alexandre, >Of course, I have no problem with that. The create_file request takes >attributes, so create_serial can do the same (it would be better if >create_serial were done inside create_file, but that's another >story...) agreed. >> Another question: do you think it would be possible to implement a >> "write memory" message from the wineserver to the client? .. >But that would require multiple copies of the data (and many context >switches for large reads); that wouldn't be very efficient. I think >the current approach is much better. What is the problem with doing >CancelIo? IMO it would be messy to implement CancelIo with the current architecture. If it were all in the server (including actual read and write calls) it might be simpler... but probably not efficient, like you say. i think most of the data transferred from a serial port is pretty small though... but if the scheme was expanded to handle overlapped socket operations that wouldn't be true. Additionally, i though it might be useful to have a way to write small chunks of data to the client's memory. For example, when implementing WaitForNamedPipe and ConnectNamedPipe, i need to write a result code into an overlapped structure... it's only 4 bytes, but i need to create a new type of APC to deal with it. If i had a method to write directly into client memory, it would be simpler. Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0