- wine-devel - winehq.org

Re: Wininet vs. winsock.h
by Alexandre Julliard 24 Aug '01

24 Aug '01

Francois Gouget <fgouget(a)free.fr> writes: > I recently discovered that xemacs does colorization of diffs when > they have a .diff extension. So I changed the naming convention for my > patches. Also if you modify '/etc/mime.types' to contain 'text/plain txt > text diff' (soon to be the default in Debian) you can read such files > without problem from within pine. If you could convince pine to not encode your patches in base64 that would be even better. It makes my life easier when I can simply pipe the whole mail into patch, instead of having to decode mime stuff first. In fact unless your mailer mangles white space, simply putting the patch inline is better than as an mime attachment. -- Alexandre Julliard julliard(a)winehq.com

1 0

WSAStartup16
by Francois Gouget 24 Aug '01

24 Aug '01

WSAStartup16 seems wrong. As I understand it all the Win16 structures have a 1 byte alignment. Thus the WSASTARTUP structure used by WSAStartup16 should have a 1 byte alignment. But WSAStartup16 uses the Win32 structure! Why is this important? Here's why: - the last field, lpVendorInfo, will be misaligned - the structure will be larger than it should (by 2 bytes). And since we do a memcpy of sizeof(WSADATA) to the pointer provided by the application we could have a buffer overflow - this creates a dependency between winsock16.h and winsock.h which greatly bothers me Or did I miss something? Changelog: * include/wine/winsock16.h, dlls/winsock/socket.c Add WSASTARTUP16 a 1 byte alignment version of WSASTARTUP for win16 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

1 0

Re: dumping utility
by Eric Pouech 24 Aug '01

24 Aug '01

this can be done of course... I think we could start with a bin hex dumper... if has to be checked whether the x86 disassembler from the debugger could be used here... but a bit of tweaking will be required (like taking care of addresses, how opcodes are read, how output is generated...) OTOH binutils' objdump has greatly evolued and now also includes lots of PE facilities... so I think we'd better focus on pure windows areas (IMO resource dumping is perhaps more needed than the disas feature...) than this one A+ > >>>>> "eric" == eric pouech <eric.pouech(a)wanadoo.fr> writes: > > eric> thanks for your effort. I applied your patch and get the > eric> following: > >> > wine/tools/specmaker> ./pedump -x /dosd/cae/gcprevue/gcprevue.exe > eric> this has to be called with ./pedump -x -d > eric> /dosd/cae/gcprevue/gcprevue.exe as the Usage lines (almost) > eric> mention ;-) > > That looks better with the -d. > > Is pedumper expected to get a disassembler too? > > Bye > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Re: dumping utility
by Uwe Bonnes 24 Aug '01

24 Aug '01

eric pouech writes: > this is a first shot at the PE-dump utility for wine > since, lots of code could/will be shared with specmaker (PE image file > browsing, symbol demangling...), I decided to turn specmaker into a > multi-mode utility > > the executable made out of the sources in specmaker dir can now be > launched under 3 different names: > - specmaker: you keep all the old features of specmaker (except -S > option) > - winedemangle: this replaces the -S option of specmaker > - pedump: PE (and .DBG) file dumping utility... lots of PE dir dumping > still > need to be written (like resources or typelib information) > Hallo Eric, thanks for your effort. I applied your patch and get the following: > wine/tools/specmaker> ./pedump -x /dosd/cae/gcprevue/gcprevue.exe > Unrecognized option > Usage: > -h Display this help message > -d <dll> Use dll for input file and generate implementation code > -C Turns on symbol demangling > -f Dumps file header information > -j sect_name Dumps only the content of section sect_name (import, export, debug) > -x Dumps everything Do I do something wrong? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

2 2

Re: dumping utility
by Alexandre Julliard 24 Aug '01

24 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > the executable made out of the sources in specmaker dir can now be > launched under 3 different names: > - specmaker: you keep all the old features of specmaker (except -S > option) > - winedemangle: this replaces the -S option of specmaker > - pedump: PE (and .DBG) file dumping utility... lots of PE dir dumping > still This seems to duplicate a lot of code that is in cvdump. Are there still things that cvdump does that your pedump doesn't support, or should I remove cvdump completely? Also I'm not convinced we need a separate winedemangle binary, we are already installing a bit too many things in /usr/bin. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: _CheckNotSysLevel()
by Alexandre Julliard 23 Aug '01

23 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > It seems Wise installers break inside _CheckNotSysLevel() . I think > every Wise installer I've tried breaks .. The cuteftp package was one of > them .. How about posting a backtrace? -- Alexandre Julliard julliard(a)winehq.com

3 4

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

23 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > anyway, I'd like to get back to simple vs complex consoles if I got > you right, a simple console handle should be in fact nothing more > than a regular file handle which unix fd is set to either 0 or 1 it > means that no enhanced mode is used, nothing but the standard libc > line editing facilities of the input stream so the use would > adequate for a simple program that just uses equivalent of puts/gets > (and associated) functions Exactly yes. > however, I find this very limiting for people who want to use a CUI > exe in a pure unix console mode (either when X11 isn't started, or a > session done over IP in telnet for example) that's why I was > wondering if wineconsole shouldn't also support a (n)curse like > interface (in addition to the USER32 one) to help in this area Sure, once the architecture is in place we can have different implementations of wineconsole, including curses support. The important thing is that this is in a separate application, so that ReadConsole doesn't need to know about things like xterm escape sequences. > last but not least, recent exchanges made a simple < 1kloc patch a more > serious project of several kloc :-/ I can do the wineserver part if you like. -- Alexandre Julliard julliard(a)winehq.com

2 1

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

23 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, the issue here is that, even in line editing mode, ReadConsole > and ReadConsoleInput can be used. the former drops all non keyboard > events and produces a string, whereas the later returns the available > input records... > so, to implement what you propose, the wineconsole would have to know > in advance which one of the two functions will be called next: > - in case of ReadConsole, it has to keep all incoming input records, and > release just the string when it's done editing the line > - in case of ReadConsoleInput, all generated input records must be > available in the server to the calling app OK I see what you mean. Yes this implies that we must be able to tell the server to only return input events to the thread doing the ReadConsole. If I get this right, it also means line editing has to be done in ReadConsole, and that you can't see what you type when the app is not reading. Very annoying, but I guess it's more Windows-like... -- Alexandre Julliard julliard(a)winehq.com

2 1

_CheckNotSysLevel()
by Daniel Walker 23 Aug '01

23 Aug '01

It seems Wise installers break inside _CheckNotSysLevel() . I think every Wise installer I've tried breaks .. The cuteftp package was one of them .. Daniel Walker

1 0

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

22 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > fairly acceptable ;-) except that in line editing mode we need to lock > the input buffer on a single thread (that's the way the queue is > handled, > at least, on NT 2000 - didn't check the others) (the granularity for > getting access to the queue is not the input record, but the line (up to > '\n')) I guess line editing could be done by wineconsole, and the input records would only be sent to the server once we have a complete line. Or do we need more locking than this? > I was thinking of either a anonmymous file or an anonymous mapping for > the content of the screen buffer... with an array attribute and char > may be some additional info on each row to indicate the rendering > program about the rows which have been modified... The problem with a shared buffer is that you need to lock against simultaneous access, which means a hung thread can hang the whole console. I'd prefer to have the server simply report to wineconsole the bounding rect of the screen buffer area that has been modified, and have wineconsole use ReadConsoleOutput to retrieve the buffer contents from the server. It's only a few Kbytes to copy at most so performance should be acceptable. -- Alexandre Julliard julliard(a)winehq.com

2 1

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

22 Aug '01

"Eric Pouech"<eric.pouech(a)voila.fr> writes: > if we want to go into this, there are a few points to agree on first: > - since console handles can be inherited, the Wine console window should > be run in a different process than the one which uses the console (and > add communication means between the first process, and the process > rendering the console) > - how should we know a program needs either a simple or a complex > console (we could use a registry key in the per process area) We need a separate process yes. I was thinking of something like a 'wineconsole' Winelib app. Then if you want to run an app with a separate console you use wineconsole instead of wine to start it. A new wineconsole could also be launched when the app does an AllocConsole, or some other function that requires a complex console. The communication with the console can probably go through the server. Input events can simply be put in the queue by wineconsole using WriteConsoleInput. Output should probably go to a server screen buffer object, which would then signal wineconsole that its contents changed. -- Alexandre Julliard julliard(a)winehq.com

2 1

custom CFLAGS
by mdew 22 Aug '01

22 Aug '01

too my previous subject... err:module:map_image Could not map section .data, file probably truncated the problem was my custom CFLAGS, which havent caused me too many problems...till lately ...(using wine) export CFLAGS="-O3 -ffast-math -fthread-jumps -fcse-follow-jumps -mpentiumpro -march=pentiumpro -mcpu=i686 -malign-loops=2" err:module:map_image Could not map section .data, file probably truncated /usr/local/bin/wine: can't exec './xxx.exe': error=21 gcc 2.95.4-6 (Debian Sid) I havent tried gcc-3.0.1 yet, i trust gcc-2.95.4 still...give it another few versions before i'll look at gcc3. in paticular is the use of -O3 over -O2, -O2 will work, -O3 will fail..why is that? -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

2 3

Re: ReadFile and other issues
by Eric Pouech 22 Aug '01

22 Aug '01

> 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. if we want to go into this, there are a few points to agree on first: - since console handles can be inherited, the Wine console window should be run in a different process than the one which uses the console (and add communication means between the first process, and the process rendering the console) - how should we know a program needs either a simple or a complex console (we could use a registry key in the per process area) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Re: (no subject)
by Alexandre Julliard 22 Aug '01

22 Aug '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > How about returning a function pointer instead of an id? > > When the file handle is registered with the wine-server, we would also > send function pointers for the read and write operations. This way we > could have seperate implementations of ReadFile or WriteFile for > different types of handles... You can't do that. The ReadFile can be done from another process, and the pointer won't be valid there. -- Alexandre Julliard julliard(a)winehq.com

1 0

(no subject)
by Mike McCormack 22 Aug '01

22 Aug '01

Hi Eric, How about returning a function pointer instead of an id? When the file handle is registered with the wine-server, we would also send function pointers for the read and write operations. This way we could have seperate implementations of ReadFile or WriteFile for different types of handles... Mike > - extend the get_handle_fd to also return an id corresponding > to the type fd being used. ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

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@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@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: fix for Lawson's CLOCAL problem
by Alexandre Julliard 21 Aug '01

21 Aug '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > Hmmm. i'm not exactly sure about this. i don't think the server ever > blocked on serial port reads or opens... i think the reason Lawson had > problems was that the client thread was blocking in the overlapped > read code. (FILE_AsyncReadService in files/file.c) I don't know if this was Lawson problem, but open() can potentially block on a serial port, and we cannot have that in the server; so your change to set O_NONBLOCK is good, but it shouldn't depend on FILE_FLAG_OVERLAPPED. > If we use non-blocking fds unconditionally, a non overlapped ReadFile > may result in a busy loop in the client thread. Sure, you need to reset the O_NONBLOCK flag to do blocking reads. > Additionally, overlapped read (and write) requests should fail unless > the handle is opened with FILE_FLAG_OVERLAPPED. There are programs > that depend on that behaviour (as reported by Eric Kohl, 3 Feb 2001 on > this list). This is another reason to propagate CreateFile's > attributes parameter into the wineserver. 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...) > Another question: do you think it would be possible to implement a > "write memory" message from the wineserver to the client? This message > would be carried over wait_fd and would be received by the client > asynchronously in wait_reply(). The message would contain a length, > address and data to be written. If this is possible, i could move > async i/o back into the server, keep it efficient and perhaps > implement CancelIo properly... 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? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winsock stuff
by Daniel Walker 21 Aug '01

21 Aug '01

This seems to work.. Daniel Walker --- server/sock.c 2001/05/14 20:09:39 1.18 +++ server/sock.c 2001/08/21 01:31:04 @@ -113,9 +113,14 @@ { struct sock *sock = (struct sock *)obj; unsigned int emask; + char rBuf; assert( sock->obj.ops == &sock_ops ); if (debug_level) fprintf(stderr, "socket %d select event: %x\n", sock->obj.fd, event); + + if (event == POLLIN && !recvfrom(sock->obj.fd, &rBuf, sizeof(rBuf), MSG_PEEK, NULL, NULL)) + event = POLLHUP; + if (sock->state & WS_FD_CONNECT) { /* connecting */

1 0

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

21 Aug '01

Hi Alexandre, Hmmm. i'm not exactly sure about this. i don't think the server ever blocked on serial port reads or opens... i think the reason Lawson had problems was that the client thread was blocking in the overlapped read code. (FILE_AsyncReadService in files/file.c) If we use non-blocking fds unconditionally, a non overlapped ReadFile may result in a busy loop in the client thread. Additionally, overlapped read (and write) requests should fail unless the handle is opened with FILE_FLAG_OVERLAPPED. There are programs that depend on that behaviour (as reported by Eric Kohl, 3 Feb 2001 on this list). This is another reason to propagate CreateFile's attributes parameter into the wineserver. Another question: do you think it would be possible to implement a "write memory" message from the wineserver to the client? This message would be carried over wait_fd and would be received by the client asynchronously in wait_reply(). The message would contain a length, address and data to be written. If this is possible, i could move async i/o back into the server, keep it efficient and perhaps implement CancelIo properly... Mike > The open on the server side must always be non-blocking, we cannot > have the server block on anything. If there are cases where we need to > block on open, it will have to be done on the client side. ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: winsock stuff
by Alexandre Julliard 21 Aug '01

21 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > How is it unreliable? Why is MSG_PEEK more reliable? I'm not opposed to > using MSG_PEEK , just curios.. FIONREAD is unreliable because you cannot distinguish between an EOF condition and an empty receive buffer. recvmsg(MSG_PEEK) is supposed to return 0 on EOF, and EWOULDBLOCK on empty buffer, so you can determine the real status. > Another issue is why doesn't poll() give > us a POLLHUP? That would be ideal, get poll() to work the way we need it > too. As I understand it poll() returns POLLHUP only when both directions of the socket have been closed; but if you shutdown() only the read or write side, you don't get POLLHUP so that you can continue using poll() for the other direction. This has apparently been changed between kernels 2.2 and 2.4; in 2.2 POLLHUP is returned as soon as the read side of the socket has been closed. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winsock stuff
by Alexandre Julliard 21 Aug '01

21 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > To improve on this patch we could only do the FIONREAD if the sock is > in a non-blocking state. That's the only time that doing the FIONREAD > would be an advantage. Also we wouldn't need to worry about screwing up > blocking sockets. Even further, we could only do the FIONREAD if socket > is non-blocking and looking for an FD_CLOSE event. Using FIONREAD is simply not an option, it cannot be made reliable. A possibility to detect EOF could be a recvmsg with MSG_PEEK flag, though you should probably verify first that it behaves as expected. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winsock stuff
by Alexandre Julliard 20 Aug '01

20 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > I noticed that WSAEnumNetworkEvents() was returning all events that had > occurred and not just the events that had been selected with > WSAEventsSelect(). Win98 will trigger the event object for all events > but WSAEnumNetworkEvents() (in win98) would return zero if the event > hadn't been selected. I was trying to gain compatibility with win98. I'd suggest doing the masking in WSAEnumNetworkEvents then. > An FD_READ event with a zero buffer would mean that the other side > closed the connection so it would be equivalent to a POLLHUP from poll() > .. I didn't find an occasion when poll() actually returned POLLHUP when > the socket closed, on Linux anyway. The application that I was testing > got confused when recv() returned zero. Even though recv() can legally > return zero, I think non-blocking applications are going to be looking > for FD_CLOSE events as opposed to recv() returning zero. But FIONREAD can return 0 bytes even when the socket isn't closed (for instance if another thread got the data first). You can only determine that it was really closed when you do the actual read. So I don't really see how we can avoid having recv() return zero; well maybe we can make it return EWOULDBLOCK and tell the server the connection is closed, but I'm not sure it's any better. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winsock stuff
by Alexandre Julliard 20 Aug '01

20 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > -changed get_socket_event() so it only returns events that > the application is looking for. > -Changed sock_poll_event() to interpret a POLLIN event with > zero bytes waiting to be read as a POLLHUP. This doesn't look really right to me. Could you please explain a bit more what it is supposed to fix? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Refcounting in SelectObject
by Alexandre Julliard 20 Aug '01

20 Aug '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Appended code tries to clean up better by: > - Remembering an unsuccessfull DeleteObject by adding 0x8000 to the Refcount > - Call DeleteObject in SelectObject when the RefCount of the released handle > is 0x8000 > - Decrementing the RefCount when a hBitmap is still selected into a DC when > DeleteDC is called for that DC > - Call DeleteObject in DeleteDC when RefCount is 0x8000 > > For some applications I tested, I always saw the delayed DeleteObject done > after the refused DeleteObject in the first place. Is this approach better? Yes, looks good. Though we can probably safely use the dwCount field in GDIOBJHDR since it is not used for anything useful right now, instead of adding new fields. I've changed that and applied the patch. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: fix for Lawson's CLOCAL problem
by Alexandre Julliard 20 Aug '01

20 Aug '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > Open serial ports with O_NONBLOCK if FILE_FLAG_OVERLAPPED is > specified. The open on the server side must always be non-blocking, we cannot have the server block on anything. If there are cases where we need to block on open, it will have to be done on the client side. -- Alexandre Julliard julliard(a)winehq.com

1 0

-clocal and the wineserver
by lawson_whitney＠juno.com 19 Aug '01

19 Aug '01

Good day! Any time clocal falls out of the modem's termios (say I use cu -l on it) the wineserver hangs trying to open it, or at least the app hangs, and I haven't found a way to kill it without killing the wineserver. Both 16 and 32 bit versions of juno are affected. I haven't really investigated it very thouroughly, but I wasted a lot of time restoring backup versions of the app and wine. Should I look into mickey-mousing the open to avoid the problem, or - is it really a wineserver problem which I am probably not even marginally competent to muck with? I'd be glad to make traces or winedbg output, but it seems the problem should be easy to duplicate. Hmmm, setting clocal back on from another terminal unhangs the app. That is neater than killing the wineserver, I guess. terminal.exe from wfw 3.11 behaves similarly, with an extra twist: it hangs on the Win16Mutex until somebody sets clocal (well, I guess carrier detect would work, too). [whit@giftie user0001]$ wine terminal.exe err:ntdll:RtlpWaitForCriticalSection section 0x400fad6c "syslevel.c: Win16Mutex" wait timed out, retrying (60 sec) fs=008f fixme:pthread_kill_other_threads_np Console: Making console complex (creating an xterm)... fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default xterm: unable to open font "vga", trying "fixed".... Failed to open input method passed master doesn't match slave name passed master doesn't match slave name [whit@giftie user0001]$ Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: PATCH: olepictures black & white
by Alexandre Julliard 19 Aug '01

19 Aug '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > Somehow the loaded JPEGs are now black & white in the IPicture implementation. > > Exchanging CreateCompatibleDC(0) by CreateDCA("DISPLAY",0,0,0); makes > them colored again. > > But I am not sure whether the problem itself was a bug on my side, or > on the WINE side... Maybe a bit of both... I think the patch below should fix the GDI part; but is there any reason you don't use GetDC(0) instead of CreateCompatibleDC? It would avoid creating a new DC every time. Index: objects/dib.c =================================================================== RCS file: /opt/cvs-commit/wine/objects/dib.c,v retrieving revision 1.60 diff -u -r1.60 dib.c --- objects/dib.c 2001/08/17 00:07:42 1.60 +++ objects/dib.c 2001/08/19 19:27:42 @@ -875,7 +875,9 @@ /* Now create the bitmap */ - if (fColor) handle = CreateCompatibleBitmap( hdc, width, height ); + if (fColor) + handle = CreateBitmap( width, height, GetDeviceCaps( hdc, PLANES ), + GetDeviceCaps( hdc, BITSPIXEL ), NULL ); else handle = CreateBitmap( width, height, 1, 1, NULL ); if (!handle) return 0; -- Alexandre Julliard julliard(a)winehq.com

1 0

PATCH: oleauto header problem
by Nikolas Zimmermann 19 Aug '01

19 Aug '01

Hi there, Reaktivate doesn't compile anymore. We need this patch. Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel 19 Aug '01

19 Aug '01

At 02:35 PM 18/08/2001 -0700, you wrote: >For standard controls like buttons it should never be a problem since >there is both an ASCII and Unicode win proc, so in a pure ASCII app we >should never do the conversion. I think the problem is that the >dialog code does a CreateWindowW, so the button is Unicode even though >the app does everything in ASCII. I guess we'll have to maintain both >A and W win procs inside each window, not only inside the class. How about creating Ascii windows when the app calls DialogBox..A variants ? Gerard

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard 18 Aug '01

18 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > How about creating Ascii windows when the app calls DialogBox..A variants ? That could be a workaround, but since dialog resources are Unicode it's better to avoid converting back and forth. Besides, Windows maintains two different win procs for windows of standard classes so we should do it this way too. I'll try to come up with something. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel 18 Aug '01

18 Aug '01

At 01:19 PM 18/08/2001 -0700, you wrote: > >The idea is that 6 Unicode chars can yield more than 6 ASCII chars >with DBCS text. The MSDN doc states that WM_GETTEXTLENGTH can return >more than the actual size when mixing ASCII and Unicode. > >What does the app do exactly? Maybe there are cases where the >conversion can be avoided. WM_GETTEXTLENGTH, WM_GETTEXT, then DrawText with the length returned by WM_GETTEXTLENGTH. If the app had used the length returned by WM_GETTEXT, it would have worked all right of course - maybe that's the reason why the problem does not appear more often ? In the following trace Cancel is the text of a button in a dialog box. Gerard 080682e8:Call window proc 0x5f404ae6 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call user32.GetPropA(000026dc,5f49c94c "AfxOldWndProc423") ret=5f404b09 080682e8:Ret user32.GetPropA() retval=40ac0259 ret=5f404b09 080682e8:Call user32.CallWindowProcA(40ac0259,000026dc,0000002b,00000002,40586474) ret=5f404b4b 080682e8:Call window proc 0x406a7980 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call window proc 0x43d715 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call user32.GetWindowLongA(000026dc,00000008) ret=0043d727 080682e8:Ret user32.GetWindowLongA() retval=40586914 ret=0043d727 080682e8:Call user32.GetWindowTextLengthA(00002e0c) ret=0043bb82 trace:message:SPY_EnterMessage (00002e0c) "Cancel" message [000e] WM_GETTEXTLENGTH sent from self wp=00000000 lp=00000000 080682e8:Call window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 080682e8:Call user32.CallWindowProcA(40ac00f1,00002e0c,0000000e,00000000,00000000) ret=0043d2b8 080682e8:Call window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) trace:message:SPY_EnterMessage (00002e0c) DefWindowProc32: WM_GETTEXTLENGTH [000e] wp=00000000 lp=00000000 trace:message:SPY_ExitMessage (00002e0c) DefWindowProc32: WM_GETTEXTLENGTH [000e] returned 00000006 080682e8:Ret window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=00000006 080682e8:Ret user32.CallWindowProcA() retval=0000000c ret=0043d2b8 080682e8:Ret window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=0000000c trace:message:SPY_ExitMessage (00002e0c) "Cancel" message [000e] WM_GETTEXTLENGTH returned 0000000c 080682e8:Ret user32.GetWindowTextLengthA() retval=0000000c ret=0043bb82 080682e8:Call ntdll.RtlEnterCriticalSection(5f4d0088) ret=5f4020bd 080682e8:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=5f4020bd 080682e8:Call ntdll.RtlLeaveCriticalSection(5f4d0088) ret=5f402103 080682e8:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=5f402103 080682e8:Call user32.GetWindowTextA(00002e0c,413904e0,0000000d) ret=0043bba9 trace:message:SPY_EnterMessage (00002e0c) "Cancel" message [000d] WM_GETTEXT sent from self wp=0000000d lp=413904e0 080682e8:Call window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=413904e0) 080682e8:Call user32.CallWindowProcA(40ac00f1,00002e0c,0000000d,0000000d,413904e0) ret=0043d2b8 080682e8:Call window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=403a7328) trace:message:SPY_EnterMessage (00002e0c) DefWindowProc32: WM_GETTEXT [000d] wp=0000000d lp=403a7328 trace:message:SPY_ExitMessage (00002e0c) DefWindowProc32: WM_GETTEXT [000d] returned 00000006 080682e8:Ret window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=403a7328) retval=00000006 080682e8:Ret user32.CallWindowProcA() retval=00000006 ret=0043d2b8 080682e8:Ret window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=413904e0) retval=00000006 trace:message:SPY_ExitMessage (00002e0c) "Cancel" message [000d] WM_GETTEXT returned 00000006 080682e8:Ret user32.GetWindowTextA() retval=00000006 ret=0043bba9 <snip unrelated painting instructions> 080682e8:Call gdi32.GetTextExtentPoint32A(00000088,413b00d0,00000006,40585f68) ret=0043c022 080682e8:Call x11drv.GetTextExtentPoint(4037c808,4039d238,00000006,40585f68) ret=40747c04 trace:text:X11DRV_GetTextExtentPoint L"Cancel"... 6 080682e8:Ret x11drv.GetTextExtentPoint() retval=00000001 ret=40747c04 080682e8:Ret gdi32.GetTextExtentPoint32A() retval=00000001 ret=0043c022 <snip a few text painting preparation> 080682e8:Call user32.DrawTextA(00000088,413904e0 "Cancel",0000000c,40585f28,00000100) ret=0043c13a trace:text:DrawTextExW L"Cancel", 12 , [(9,4),(51,20)]

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard 18 Aug '01

18 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > WM_GETTEXTLENGTH, WM_GETTEXT, then DrawText with the > length returned by WM_GETTEXTLENGTH. > If the app had used the length returned by WM_GETTEXT, it would > have worked all right of course - maybe that's the reason why > the problem does not appear more often ? For standard controls like buttons it should never be a problem since there is both an ASCII and Unicode win proc, so in a pure ASCII app we should never do the conversion. I think the problem is that the dialog code does a CreateWindowW, so the button is Unicode even though the app does everything in ASCII. I guess we'll have to maintain both A and W win procs inside each window, not only inside the class. -- Alexandre Julliard julliard(a)winehq.com

1 0

WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel 18 Aug '01

18 Aug '01

I don't understand it : case WM_GETTEXTLENGTH: 719 case CB_GETLBTEXTLEN: 720 case LB_GETTEXTLEN: 721 /* there may be one DBCS char for each Unicode char */ 722 return result * 2; This has a bad effect on one of my test apps - returns a length of 12 for a text of 6 characters, displays funny symbols after the text. The Unicode window proc returns 6, why the unicode/ascii conversion should make it 12 ? The Api returns number of chars, not bytes. Gerard

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard 18 Aug '01

18 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > I don't understand it : > > case WM_GETTEXTLENGTH: > 719 case CB_GETLBTEXTLEN: > 720 case LB_GETTEXTLEN: > 721 /* there may be one DBCS char for each Unicode char */ > 722 return result * 2; > > This has a bad effect on one of my test apps - returns a length of 12 > for a text of 6 characters, displays funny symbols after the text. > > The Unicode window proc returns 6, why the unicode/ascii conversion > should make it 12 ? The Api returns number of chars, not bytes. The idea is that 6 Unicode chars can yield more than 6 ASCII chars with DBCS text. The MSDN doc states that WM_GETTEXTLENGTH can return more than the actual size when mixing ASCII and Unicode. What does the app do exactly? Maybe there are cases where the conversion can be avoided. -- Alexandre Julliard julliard(a)winehq.com

1 0

not-yet-connected sockets?
by Daniel Walker 18 Aug '01

18 Aug '01

The problem is that poll returns POLLHUP when a socket isn't connected, then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications? Daniel Walker

3 13

Re: Toolbar background error
by Gerard Patel 18 Aug '01

18 Aug '01

At 06:54 PM 17/08/2001 -0700, you wrote: <snip> >But their solution is still not correct IMO. How about something like >this? All clear for me on this one, tested without problem for all of my test apps - at least the one surviving the Gdi lock slaughter :-) Gerard

1 0

Re:CryptoAPI
by Eric Pouech 18 Aug '01

18 Aug '01

from a pure technical point of view, the crypto API is in a pure WOSA style : - a set of high level API (in advapi) - an extendable set of low level service providers (here for example the crypto algos - RSA....) - the high level maps the fonctional request of the user onto on of the available SP. so, my advice here would be to implement this type of scheme. This would allow to: - use native DLLs if they exist (and go beyond what's supported by Linux) - still allow to use Linux lib (just build a wrapper DLL to that lib) and you should be all set from a copyright point of view: - Wine use a X11 like licence, so make sure all the external libs you use are not GPL (LGPL is fine). If they are GPL, you won't be able to ship the result with Wine. - Use of native DLL is granted as long as you have a Windows licence on the target machine (native DLLs shall not be shipped with Wine, Wine should be configured to use the local resources) from an exportation point of view: - some countries (US as an example) puts lots of contraints on the type of crypto algo to be used outside of the US. So those shouldn't be shipped with Wine's, but be provided as an external resource) > Hi, > > I was going to start implementing the Cypto API (in advapi32.dll) over the > next few weeks. As of yet these functions are no more than stubs. However, > I am finding increased use of this API as more applications becomed > networkable and relying more heavily on internet connections. > > I was hoping to implement these functions by using the OpenSSL library > (if/when available). This library seems to have similar capabilities. > > One of my concerns is about legal issues. What special concerns should I > note about cryptographic software? Are there any special copyright issues I > should be aware of? > > Another question is about design. M$ seems to split the cryptographic > software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.). > Should I do this as well so that, applications can use the native dlls if > necessary or should I simply implement it entirely though advapi32.dll which > and avoid the need to create several new (and very small) dlls under wine? > Because most of the code is already in another library (OpenSSL) creating > extra dlls seems abit unnecessary. > > - Travis > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

2 1

Re: Toolbar background error
by Alexandre Julliard 18 Aug '01

18 Aug '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > I suggest reading the Corel CVS for this part of the code. > > They rewrote this part like _5_ times. But their solution is still not correct IMO. How about something like this? Index: windows/defwnd.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/defwnd.c,v retrieving revision 1.59 diff -u -r1.59 defwnd.c --- windows/defwnd.c 2001/08/10 22:51:43 1.59 +++ windows/defwnd.c 2001/08/18 00:21:43 @@ -461,10 +461,13 @@ HBRUSH hbr = GetClassLongW( wndPtr->hwndSelf, GCL_HBRBACKGROUND ); if (!hbr) return 0; - /* GetClientRect used to be GetClipBox, but it is not what - * Windows does, and it breaks badly with CS_PARENTDC */ - GetClientRect( wndPtr->hwndSelf, &rect ); - DPtoLP( hdc, (LPPOINT)&rect, 2 ); + if (GetClassLongW( wndPtr->hwndSelf, GCL_STYLE ) & CS_PARENTDC) + { + /* can't use GetClipBox with a parent DC or we fill the whole parent */ + GetClientRect( wndPtr->hwndSelf, &rect ); + DPtoLP( hdc, (LPPOINT)&rect, 2 ); + } + else GetClipBox( hdc, &rect ); FillRect( hdc, &rect, hbr ); return 1; } -- Alexandre Julliard julliard(a)winehq.com

1 0

dsound ??
by Bobby Bingham 17 Aug '01

17 Aug '01

Hello all, I completely rebuilt my computer a while back, and updated wine, so I'm not sure which is causing it, but not dsound doesn't seem to work where it did before. Starcraft doesn't play any music, sound, etc, but it's installer still plays it's sound (without dsound). Before this I hadn't updated WINE for a while, so I'm not sure when it broke. Bobby Bingham

1 0

Re: Toolbar background error
by Gerard Patel 17 Aug '01

17 Aug '01

At 11:08 AM 17/08/2001 -0700, you wrote: >That's not what Windows does. If you pass a window DC to WM_ERASEBKGND >it only erases an area equivalent to the client area (shifted to be >relative to the whole window), so GetClientRect is correct IMO. The >non-client area should be painted upon WM_NCPAINT, not WM_ERASEBKGND. How do you test this under Windows ? In my test app, I have a white brush as class brush. So my window is white. If I add after the BeginPaint : GetClientRect(hwnd, &r); r.top += 200; FillRect(ps.hdc, &r, (HBRUSH) COLOR_WINDOW) the lower part of my window is painted with the beautiful window color (brown) Now if I add immediately after : hdc = GetWindowDC(hwnd); SendMessage(hwnd, WM_ERASEBKGND, (WPARAM) hdc, 0); ReleaseDC(hwnd, hdc); I get a window that is completely white; maybe I am missing something but I should see a small brown strip at the lower part of the window, corresponding to the caption + menu height, no ? Gerard

1 0

Re: Toolbar background error
by Gerard Patel 17 Aug '01

17 Aug '01

At 02:33 PM 17/08/2001 GMT, you wrote: <snip> >So how does an application modify the location of the client rectangle >after it has been created? By changing rgrc[0] when responding to WM_NCCALCSIZE. It seems that it is only possible to erase properly the 'custom' nonclient area by using GetWindowDC... So : --- defwnd.c.orig Sat Aug 11 10:23:18 2001 +++ defwnd.c Fri Aug 17 19:47:17 2001 @@ -462,8 +462,12 @@ if (!hbr) return 0; /* GetClientRect used to be GetClipBox, but it is not what - * Windows does, and it breaks badly with CS_PARENTDC */ - GetClientRect( wndPtr->hwndSelf, &rect ); + * Windows does, and it breaks badly with CS_PARENTDC + * GetClientRect breaks too when we are called with a window + * DC (!!) - what next ? */ + rect.left = rect.top = 0; + rect.right = wndPtr->rectWindow.right - wndPtr->rectWindow.left; + rect.bottom = wndPtr->rectWindow.bottom - wndPtr->rectWindow.top; DPtoLP( hdc, (LPPOINT)&rect, 2 ); FillRect( hdc, &rect, hbr ); return 1; What do you think ? Gerard

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel