wine-devel

wine-devel@winehq.org

9 participants
84457 discussions

Re: Edit control notification fix
by Andreas Mohr 09 Mar '01

09 Mar '01

On Fri, Mar 09, 2001 at 03:52:56PM +0800, Dmitry Timoshkov wrote: > Hello. > > Andreas Mohr privately reported that some old 16-bit installer > started to not update its edit control after my patch entitled > "Do not notify parent of the Edit control on WM_SETTEXT when Edit > is part of the ComboBox." Investigation has shown that installer > has its main dialog window defined in resources, and DIALOG_GetControl16() > gets edit control with style ES_COMBO (0x200) defined there. > My first attempt to fix the trouble was to simply mask out not > allowed styles in the DIALOG_GetControl16(): i.e. for edit control > do style &= ~ES_COMBO. That hack cured the application, but Andreas Well, that's not exactly true. You did not do it "for edit control". You did it for *all* controls in DIALOG_GetControl16() (at least in the patch you sent me). That's why I objected. I just had to :) > didn't like that approach. After some thinking, I added yet another > test into my "Edit Control Test Suit". And here is the result of it. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Do not send notification to parent of an edit control, > if parent is a child window. Remove old and not correct patch. OK. I can't really judge whether that's correct, as I'm not too much into these kinds of things. Hopefully it's correct :) Thanks again, Andreas Mohr

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 08 Mar '01

08 Mar '01

David Howells <dhowells(a)cambridge.redhat.com> writes: > Not so... The file offset must also be page aligned! OK, this has apparently changed in kernel 2.4; in kernel 2.2 block size alignment is enough. That's unfortunate, but I guess it was necessary to support large files or memory sizes. Then yes, in 2.4 your patch will be more useful. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 08 Mar '01

08 Mar '01

David Howells <dhowells(a)cambridge.redhat.com> writes: > My main gripe is the slow speed of access to files... Every Read/WriteFile > goes to the wineserver to convert the handle into a file descriptor and to > check for locking. The FD is then passed back over a UNIX domain socket, used > once and then closed. Note that we are no longer doing that in the latest versions; the file descriptor is only transferred once, and all further requests are done on a pipe which is faster than a socket. > Gavriel State <gav(a)transgaming.com> wrote: > > In my experience Alexandre far prefers incremental change to kind of > > approach you're taking. Using that kind of approach will improve the > > chances that your code will make it into Wine at some point. > > Hmmm... It's difficult to determine how to do it incrementally without making > for even more work, but I think I know what you mean. The kernel module itself may be hard to do incrementally, but you should really consider reusing the existing server API so that your module can be plugged in easily. For instance your module entry points should be the same as the server requests, and use the same request structures. > Context switching is the main element of it. Going to the wineserver and back > again just for a ReadFile() call or a Wait*() function incurs a fairly serious > penalty (particularly on an X86, I think). Plus there's no requirement for the > kernel to pass the remains of your timeslice to the wineserver and back > again. I still think that it should be possible to improve that by a small kernel hack. It will never be as fast as doing everything in the kernel of course, but it may just be fast enough to avoid the need to reimplement the whole server. > Look at the VM size of something like MS Word, and think of not having to > allocate buffers to store all those DLLs, thus eating a massive chunk out of > your machines total VM. Have you measured how many dirty pages you can avoid with your change? It seems to me that in most cases, when the dll is loaded at its preferred address, the number of pages made dirty by the fixups should be quite small anyway. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 08 Mar '01

08 Mar '01

Gavriel State <gav(a)transgaming.com> writes: > Looking at the kernel sources, it appears to be page-alignment, not > filesystem block size that mmap needs to match. Rereading old wine-devel > archives, it appears that the notion that the filesystem block size is > involved is either from a very old kernel, or a misreading of some kernel > comments. Page alignment is needed for the address in memory, not for the offset inside the file on disk; since section virtual addresses in PE files are always page-aligned the memory address is never a problem. The only problem comes from the alignment of the data inside the PE file, and this is where we only need block-size alignment to make mmap possible. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 07 Mar '01

07 Mar '01

David Howells <dhowells(a)cambridge.redhat.com> writes: > So this saves you the cost of the fd transfer net packet. Though you still > have to do the two context switches, which is my main contention. I suspect we are doing more than two switches (though I haven't proved it), which is why I think there is a margin for improvement. You'll obviously always have the context switch cost unless everything is in the kernel. > True, but I'd have thought that the context switches involved are still a cost > you can't get rid of so easily. Out of interest, how do you plan on doing the > locking stuff for Read/WriteFile? Cache it locally? It is unfortunate, but you > can't really make use of UNIX file locking, since this is mostly advisory and > as such doesn't actively stop read/write calls. Yes, we'll need to store the locks in the server and check them before each read/write (and probably also release them afterwards if necessary). There may be some optimisations possible, but we should probably do it the easy way first. > Seriously, though, whilst this'd be a lot easier in many ways (and it would > allow you to avoid the context-switch penalties), you wouldn't be able to take > full advantage of the available support in the kernel, which is more capable > than the standard UNIX userspace API suggests. I don't see why. I'm not suggesting keeping the current socket stuff, just reusing the structures. So basically instead of passing the address of the stack arguments (which is really ugly IMO) to your ioctl, you pass one of the server request structures. This allows your changes to be localized to wine_server_call and doesn't require changing any of the routines that make server calls. Obviously you'd need some more changes for a few calls like ReadFile/WriteFile, but most operations could switch to your mechanism without needing any change. You simply cannot require people to recompile all of Wine to use your module. > > I still think that it should be possible to improve that by a small > > kernel hack. It will never be as fast as doing everything in the > > kernel of course, but it may just be fast enough to avoid the need to > > reimplement the whole server. > > If you want to suggest exactly what you'd like to see as a hack... I don't know exactly, there are many ways of doing it; you can have a specialized fifo, a network protocol, an ioctl, etc. Basically any mechanism that ensures that we do the strict mimimum number of context switches and schedule() calls for a server call. And probably also a way to transfer chunks of memory from the client address space so that we don't need the shared memory area. > As far as I've observed (I've got Win2000 available), most Windows DLL's have > 512-byte (sector) alignment internally, _not_ 4096-byte (page) alignment for > the sections. This means that the separate sections can't be mmap'd (or else > they'd lose their required relative relationships): Actually the file alignment doesn't need to be 4096, it needs to match the filesystem block size. On a FAT filesystem the block size is 512 so Linux will happily mmap every section. On a 1k-block ext2 fs it will be able to mmap about 50% of them. > Also, since DLLs and EXEs are not compiled as PIC (the MSDEV compiler not > having such an option as far as I can recall), the fixup tables usually seem > to apply to just about every page in the code section. Only if the dll cannot be loaded at the preferred address, which shouldn't happen too often. I'm not saying your patch is useless, but I doubt the gain is as large as you seem to think. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by David Howells 07 Mar '01

07 Mar '01

Gavriel State <gav(a)transgaming.com> wrote: > As it stands, your approach won't be useful for general Wine usage until > you've got *everything* done. True. But I think there are valid reasons for doing it this way. One major problem is handles. Either the kernel must allocate all handles, or userspace must allocate all handles. Take something like the implementation of DuplicateHandle() - dead easy really in kernel space, including duplication to another process. If userspace tells the kernel to use handle X for a mutex, say, and handle Y for a semaphore, then userspace still has to go to atomic management code to (a) allocate a handle, and (b) access a handle. And to implement cross-process duplication, you either need some sort of interrupt & IPC mechanism, or an external process (the wineserver). This being the case, you lose any gains by putting the stuff in-kernel. Alternatively, if userspace is allowed to implement arbitrary handles that are allocated by the kernel, then the kernel waiting mechanism can get a little tricky. However, that said, for non-waitable objects, this might not be so bad. In fact, I'm planning on implementing the registry access handles this way and may well do some of the process and thread control this way too. Furthermore, the kernel would have to be given object handles not object pointers, otherwise you have a gaping security hole. And another major problem is context switches... they are horribly expensive really. They currently make Wine with at least 20 times the system call latency that the kernel method is capable of. > And then there will be boatloads of debugging to do. Perhaps not as much as you think... I'm doing as much debugging as I can as I go along, just making sure the kernel objects work as I'd expect (not necessarily the same thing, true, as having "compatible" behaviour). > If there's any way that you can implement your kernel module more within the > context of the existing server architecture - replacing objects on a piece > by piece fashion rather than all at once - that might make it easier to > adopt. See above for why the piece-by-piece method is difficult. One alternative would be to invent a new network protocol (say AF_WINE), but that again requires a complete implementation before it is really useful. > For example, you might try implementing the core object/handle management > and waiting code in the kernel module, and have the wine server rely on the > kernel module for that low-level functionality. By this, do you mean actually having the wineserver process talk to the kernel module on behalf of the Wine application? > Waiting for objects would be implemented on the client side through a call > to the kernel module. That's what I'm currently doing, though it's not fully implemented yet. > When something needs to be done with an object, we would call either the > wineserver or the kernel module, depending on how that object is > implemented. > For example, you could do mutexes entirely within the kernel module, but > leave file objects on the wine-server side initially. My main gripe is the slow speed of access to files... Every Read/WriteFile goes to the wineserver to convert the handle into a file descriptor and to check for locking. The FD is then passed back over a UNIX domain socket, used once and then closed. I suspect it can't really be done otherwise, particularly if ZwCloseObject (or whatever it is called) is implemented, since this allows handles in another process to be closed. Actually, I've done a fair amount of the file object stuff... Most of it involves mapping down to a "struct file *", which is how the kernel views files, and then invoking appropriate kernel method. > In my experience Alexandre far prefers incremental change to kind of > approach you're taking. Using that kind of approach will improve the > chances that your code will make it into Wine at some point. Hmmm... It's difficult to determine how to do it incrementally without making for even more work, but I think I know what you mean. > One thing I've been wondering that you might be able to answer is this: > exactly why is the current Wine Server architecture so slow? Is it just the > context switching? Context switching is the main element of it. Going to the wineserver and back again just for a ReadFile() call or a Wait*() function incurs a fairly serious penalty (particularly on an X86, I think). Plus there's no requirement for the kernel to pass the remains of your timeslice to the wineserver and back again. Also, you have to bundle lots of data through AF_UNIX network packets and/or copy lots of data into and out of _shared_ memory without killing other threads. One of the problems with the context switch is that you have to flush all the CPU caches, muck around with the MMU and execute scheduling algorithms. > Is it that the kernel isn't giving the wineserver a high enough priority > once the client blocks after having written to the socket? I don't think priority has anything much to do with it. A more convenient scheduling algorithm might help a little, though. > Is it other socket overhead (routing, perhaps)? Simply speeding up the > communications path between the clients and the server would remove the need > for most of the kernel level services. I don't think so... To communicate with the wineserver you have to use some sort of waitable UNIX object (ie: a socket, a pipe, or a SYSV semaphore or message), do busy waiting (& kill your CPU), or send signals (context switch _and_ signal overhead). To do it without a wineserver (ie: using shared memory) is also tricky... You have to be able to, for instance, recover from processes going away without releasing mutexes. > Also, just FYI, the PE image mapping work is nice, but isn't likely to affect > speed all that much, since Wine can just mmap in most PE images created with > recent compilers. WordPerfect, for example, launches in around 10-12 seconds > on my machine (down from 45-60 seconds before the mmaping). I can't imagine > that doing the fixups when paging instead would do too much better. Look at the VM size of something like MS Word, and think of not having to allocate buffers to store all those DLLs, thus eating a massive chunk out of your machines total VM. Plus, it should be even quicker launching because fixups don't have to be done unless they're necessary. You certainly don't have to go through an fixup a few tens of megs of DLL. Cheers, David

1 0

Re: Wineserver semantics
by Alexandre Julliard 07 Mar '01

07 Mar '01

Ryan Cumming <bodnar42(a)bodnar42.dhs.org> writes: > What about having the file descriptor cache explictly invaildated? Like, > the server keeps track of which file descriptors the various wine > processes have cached, and if a process closes or performs some locking > operation on a file descriptor, all the other wine proceses that are using > that file descriptor are explictly notified. This way processes can assume > a file descriptor is valid unless told otherwise... would this be any > better performance-wise? Does it fit in to the wineserver architecture > nicely? ;) Not really; you'd either need to callback into the client, which creates a lot of synchronisation issues, or use a shared memory area which implies locking. Either way doesn't really fit in the current model. And as mentioned already we'll probably still need a server call on each file access to implement file locking. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Wineserver semantics
by Alexandre Julliard 06 Mar '01

06 Mar '01

Waldek Hebisch <hebisch(a)math.uni.wroc.pl> writes: > There is ongoing disscusion on how to seed up the wineserver. > So I have question concerning correctness of corrent implementation. > Namely, for reading or writing files I have not found any locking in > wineserver when issuing file descriptor to clients. On the other > hand the client closes file descriptor just after use, and also > disscusion in the group suggests that client is supposed to have > exclusive acces to file. So I would like to know what is the case: > 1) client is allowd to cache the descriptor > 2) current implementation depends on winning a race > 3) I missed locking in wineserver I'm not sure what you mean by 'exclusive access to the file'. If you mean file locking then this is not implemented, so there cannot be any race ;-) Currently the client is allowed to cache the descriptor, but before each read/write it checks with the server that the cache is still valid. There is a race that the handle can be modified between the check and the actual read, this will cause either a bad handle error or a read from the wrong file; but this is no different from what happens under Windows if the client is manipulating handles concurrently with a ReadFile. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winelauncher patch
by Jeremy White 06 Mar '01

06 Mar '01

Ove, I have in fact determined why I did not use which: On Suse (and Caldera, I believe), which /usr/bin/wine returns an error string, making the whole script go straight down the drain. What was wrong with the previous implemenation? Are you getting a $0 value that doesn't include the path? In all of the test cases I have, invoking wine seems to bring in a $0 that includes enough of the path for the find logic to work. Jer > Hunk 2: > real_name=`find $0` don't find anything if the user typed "wine" or > something, wine is in /usr/bin, which is in PATH, but the cwd is ~... > rather run it through `which $0` first. Also, the symlink it's reading > don't have to be absolute (my symlinks are relative), deal with that. > > -real_name=`find $0 -type l -printf "%l\n"` > +argv0_path=`which $0` > +if [ -z $argv0_path ] ; then > + argv0_path=$0 > +fi > + > +real_name=`find $argv0_path -type l -printf "%l\n"` > if [ ! $real_name ]; then > - real_name=$0; > + real_name=$argv0_path > +elif [ ! -x $real_name ]; then > + real_name=`find $argv0_path -printf "%h\n"`/$real_name > fi > + > argv0_dir=`find $real_name -printf "%h\n"` > > if [ -z $argv0_dir ] ; then > @@ -130,7 +138,7 @@ > WINESERVER=$WINEBIN/server/wineserver > fi

2 1

Wineserver semantics
by Waldek Hebisch 06 Mar '01

06 Mar '01

There is ongoing disscusion on how to seed up the wineserver. So I have question concerning correctness of corrent implementation. Namely, for reading or writing files I have not found any locking in wineserver when issuing file descriptor to clients. On the other hand the client closes file descriptor just after use, and also disscusion in the group suggests that client is supposed to have exclusive acces to file. So I would like to know what is the case: 1) client is allowd to cache the descriptor 2) current implementation depends on winning a race 3) I missed locking in wineserver -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

WinCE/PocketWindows?
by Robert & Jennifer Hartley 06 Mar '01

06 Mar '01

Hi, (Please forgive me if this has already been examined, as this is my first post.) I am curious to know if a version of WINE has been considered that would be made to run WinCE (CE) and PocketWindows (PW) applications on Linux PDAs. I have been working with the Agenda VR3 PDA from www.agendacomputing that runs Linux very well on a MIPS processor. I also received a free set of Embedded Tools CDs from MicroSoft that have VC++ and VB on them for building CE and PW applications. The platforms it supports are X86, MIPS, ARM, and SH3, and I believe there are others. There is a compatability layer that runs on WinNT to test before deploying. If we had that emulated in Linux, then we would be most of the way towards being done. (Or so I would imagine.) Naturally, since I am a Linux/Unix guy, I was thinking that it would be neat to have these CE/PW apps running on my X86 Linux box, my NetWinder, my venerable old Indy, and finally, once debugged, on this Agenda Linux PDA. The WINE community has already done a huge amount of great work, so I thought that maybe a cut down version of WINE would work on the CE/PW subsets of Windows. Being an outsider, could someone let me know if I am totally out there in LaLa Land? Thanks, Rob (here around Ottawa, ON) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = Robert Hartley Mail: 201 Broadway = = Central Region Systems Engineer Cambridge, MA 02139 = = Integrated Computer Email: rhartley(a)ics.com = = Solutions, Inc. Web Site: www.ics.com = = Tech Support: support(a)ics.com Phone: 800-800-4271 = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Visit the MotifZone (www.motifzone.org) for info on Motif!

1 0

Re: Perl/Wine extension for perusal
by Niki Spahiev 06 Mar '01

06 Mar '01

Hello, Two small suggestions: 1. python has very good WIN32 bindings and also generic DLL interface CALLDLL. 2. VNC has alpha of macro recorder which can be used for interactive tests. Regards, Niki Spahiev

1 0

Re: RFC: client side implementation of async I/O
by Alexandre Julliard 06 Mar '01

06 Mar '01

Michael McCormack <mccormac(a)aals27.alcatel.com.au> writes: > This patch moves responsibility for asynchronous I/O to the client process. > i'm posting it to wine-devel because i want to know what other developers here > think about the technique i've used to make this work... Your approach is not going to work with the latest changes I made to the server. The good news is that the changes I'm making are in part to allow making server calls in signal handlers, so when this works you should be able to use SIGIO to do async IO. > i think this implementation is more efficient, as it makes fewer server calls > and duplicates fewer file descriptors, while maintaining correctness. It's not clear to me that it is more efficient; it seems it will do a lot more work on every single server call if an async IO is pending. Of course the only way to tell is to run benchmarks. -- Alexandre Julliard julliard(a)winehq.com

3 2

TCP/IP networking and registry keys
by Alan Chandler 06 Mar '01

06 Mar '01

I spent most of the weekend trying to get Grand Prix Legends GPL to work. I achieved my first goal of getting it to run in server mode. One of the things I needed to get the game to do, was to recognise that there where some interfaces it could talk TCP/IP out of. It took me some time to realise that under windows it was doing this by looking for the key [System\\CurrentControlSet\\Services\\Class\\NetTrans] and was then enumerating the keys under it to establish an IP address ie the following [System\\CurrentControlSet\\Services\\Class\\NetTrans\\0000] "IPAddress"="10.0.10.100" The thought occurred to me that maybe the tool the builds the registry during wine install could actually create these keys - since it is essentially a key part of the system (and other similar keys are also built in the same way). I don't think I have the skills to do it myself yet. Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com

3 2

Wine Press
by Eric Pouech 05 Mar '01

05 Mar '01

http://linux.cnet.com/linux/0-2136864-7-4961586.html worth the reading, even if Wine gets the lowest ranking my reading of it is that Wine is not yet a product (compared to the two others). I definitively think we should focus more on a release target. It of course means that we have to make choices (do not include some functionnalities), spend pretty much more time on testing... but that's the way to go if we want to have Wine 1.0 around on of these days A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

3 2

Re: RESUBMIT: afm
by Gavriel State 05 Mar '01

05 Mar '01

Back in Febuary, Marcus Meissner wrote: > > Changelog: > fixed one NULL ptr problem > added loading of .afm files from several common locations > (ghostscript, a2ps, enscript, (teTeX), X11) > > Index: afm.c > =================================================================== > RCS file: /home/wine/wine/dlls/wineps/afm.c,v > retrieving revision 1.4 > diff -u -r1.4 afm.c > --- afm.c 2001/01/02 20:30:16 1.4 > +++ afm.c 2001/02/03 18:50:42 > BOOL PSDRV_GetFontMetrics(void) > { > int idx = 0; > char key[256]; > char value[256]; > + char *path; > + DIR *dir; > + > + /* some packages with afm files in that directory */ > + PSDRV_ReadAFMDir("/usr/share/ghostscript/fonts/"); > + PSDRV_ReadAFMDir("/usr/share/a2ps/afm/"); > + PSDRV_ReadAFMDir("/usr/share/enscript/"); > + PSDRV_ReadAFMDir("/usr/X11R6/lib/X11/fonts/Type1/"); We just did an integration with WineHQ, and this code has started to grate on me (mostly because of the fact that the AFM parser spits out a bunch of error messages while trying to parse my AFM files. Rather than hardcoding the paths into the code, could we do this instead: while (PROFILE_EnumWineIniString( "afmdirs", idx++, key, sizeof(key), value, sizeof(value))) PSDRV_ReadAFMDir(value); This has the added benefit of allowing the user to specify only those AFM directories that their rasterizer knows about too. With the above, I get a whole bunch of printer fonts listed as available in wine that I can't actually print if Ghostscript isn't configured to find the font files. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

[RESEND] Re: faster 8bpp to 24 bit depth conversion in SetImageBits_8
by Vedran Rodic 04 Mar '01

04 Mar '01

On Sun, Mar 04, 2001 at 01:51:16PM +0100, Ove Kaaven wrote: > > > Since this is a 32-bit move (movl), you should use %%eax, not %%ax. The > assembler doesn't complain about this now, but technically it should, and > might someday. > > Since you're converting to 32bpp, not 16bpp, you should multiply "left" by > 4, not by 2, or strange things may happen in some apps. Thanks. Fixed patch attached. I did change left multiplicator from 2 to 4 in my earlier patches, but I forgot to include it in my final patch being 3 AM and so... I'll try to be more careful next time. Vedran

1 1

Re: for loop fixes
by Francois Gouget 04 Mar '01

04 Mar '01

On Sat, 3 Mar 2001, Andreas Mohr wrote: [...] > - changed all terminating ";" of isolated for loops to " ;" to indicate the > loop's isolation. IMHO, for such loops the following would be much clearer: <init_expression>; while (<test_condition>) { <update_expression>; } (ok, you can also put '{' on the next line) > Please do the same for these for loops in the future. ??? > Somebody might want to write a Wine coding guidelines article... $ wg . -E 'for *$' | grep -E '$ *; *$'` | wc -l 96 (wg is my recursive source grep script) Maybe we should ask people to put the for and the instruction it applies to on separate lines. Combined with the suggestion above this would make it easier to check for this kind of bug. > P.S.: I just *knew* that at least one other for loop in Wine would be wrong, > too ;-) Yep, I should have done that myself (if you find a generic bug, always check for other similar bugs). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

4 4

RFC: client side implementation of async I/O
by Michael McCormack 04 Mar '01

04 Mar '01

Hi all, This patch moves responsibility for asynchronous I/O to the client process. i'm posting it to wine-devel because i want to know what other developers here think about the technique i've used to make this work... i've relaxed some of the assumptions wineserver makes about client processes. i think this implementation is more efficient, as it makes fewer server calls and duplicates fewer file descriptors, while maintaining correctness. Mike -- __________________________________________________________________ mailto:Michael.McCormack@alcatel.com.au phone: (+8232) 667 0425 (h) (+8211) 430 0425 (m)

1 0

Re: Add explicit WM_CLOSE processing in the edit control
by Alexandre Julliard 04 Mar '01

04 Mar '01

Dmitry Timoshkov <dmitry(a)sloboda.ru> writes: > Since handler of WM_CLOSE in DefWindowProc calls DestroyWindow, > which eventually sends WM_DESTROY, EDITSTATE gets destroyed before > call to EDIT_UnlockBuffer in the end of processing of WM_CLOSE, > therefore EDIT_UnlockBuffer gets confused. This is not specific to WM_CLOSE, it can happen with other messages too; any time we transfer control back to the application the window can be destroyed. I think it would be better to either unlock the buffer before calling DefWindowProc, or make EDIT_UnlockBuffer cope with a destroyed window. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: erase bkgnd on page scroller control
by Alexandre Julliard 04 Mar '01

04 Mar '01

Susan Farley <susan(a)codeweavers.com> writes: > @@ -720,7 +721,8 @@ > PAGER_INFO *infoPtr; > DWORD dwStyle = GetWindowLongA (hwnd, GWL_STYLE); > > - dwStyle |= WS_CLIPCHILDREN; > + /* background color of the child should be the same as the pager */ > + dwStyle &= ~WS_CLIPCHILDREN; Shouldn't we simply leave WS_CLIPCHILDREN alone and use whatever the app specified when creating the window, instead of forcing it one way or another? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: ListView fix
by François Gouget 03 Mar '01

03 Mar '01

Ok, so now that I've got the patch out, there's a weird problem that I've been having with this piece of code. Apply the following on top of my previous patch and you'll get the weirdest traces: --- cut here --- Index: dlls/comctl32/listview.c =================================================================== RCS file: /home/cvs/wine/wine/dlls/comctl32/listview.c,v retrieving revision 1.99 diff -u -r1.99 listview.c --- dlls/comctl32/listview.c 2001/02/28 05:31:02 1.99 +++ dlls/comctl32/listview.c 2001/03/02 23:45:09 @@ -1542,10 +1545,22 @@ item.stateMask = LVIS_SELECTED; item.state = LVIS_SELECTED; + TRACE("nSelectionMark=%d nItem=%d nFirst=%d nLast=%d\n",infoPtr->nSelectionMark,nItem,nFirst,nLast); +#if 0 + i = nFirst; + while (i <= nLast) + { + TRACE("i=%d\n",i); + LISTVIEW_SetItemState(hwnd,i,&item); + i++; + } +#else for (i = nFirst; i <= nLast; i++); { + TRACE("i=%d\n",i); LISTVIEW_SetItemState(hwnd,i,&item); } +#endif LISTVIEW_SetItemFocus(hwnd, nItem); infoPtr->nSelectionMark = nItem; --- cut here --- Now if I click on item 3 I get the following trace: ... trace:listview:LISTVIEW_AddGroupSelection nSelectionMark=-1 nItem=3 nFirst=3 nLast=3 trace:listview:LISTVIEW_AddGroupSelection i=4 trace:listview:LISTVIEW_WindowProc hwnd=1908 uMsg=1006 wParam=0 lParam=405b6c30 trace:listview:LISTVIEW_AddSelectionRange Add range 4 - 4 ... Now, last I checked (i.e. a few minutes a go), 'for (i=3;i<=3;i++) printf("%d\n",i);' prints 3 and certainly not 4. Also, if I'm not mistaken this code is strictly equivalent to the while loop in the '#if 0' branch. Yet the while loop works fine but not the for loop. In a word this looks like a gcc bug to me! $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs gcc version 2.95.2 20000220 (Debian GNU/Linux) How do we normally deal with those? -- François Gouget fgouget(a)codeweavers.com

2 1

WinMM/MMSystem & registry
by Eric Pouech 02 Mar '01

02 Mar '01

I'm currently investigating moving all multimedia setup into the registry as current WINMM/MMSYSTEM implementation is rather close to the WIN3.x/9x model, I started looking at their native implementation. The main goal is to use no longer the hard coded drivers name, but rather get them from the registry basically, it goes like this: /* * The Windows registry settings are as follows: * - the drivers are defined by sets, each set has an index * - the sets are loaded in the set index increasing order * - a set is divided by classes (wave, midi...), and several drivers can be * defined in each class * - the keys are spread into two locations: * HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\MEDIA\%idx%\Drivers\%class%\%name% * where %idx% is the set index, * %class% is the class (midi, wave...) * %name% is the name of the device (which can be different from * the actual name of a the driver's filename (even if, * in lots of cases it's the same)) * these keys mainly describe what to load, and in which order * This key shall also contain some configuration options for the driver (if * needed...) * - each entry under the Services\Class has a corresponding entry in another part * of the registry * HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaResources\%class%\%namen%<%idx%> * Under this location is stored information regarding how to load the * driver (like if it's enabled, PnP information...) */ there are some other keys (like the PnP devices enumeration) which use the index to refer to the driver implementing this under Wine is not too difficult. The hairy part is the configuration (setting up the keys in the registry) since the first step of the configuration (for this scheme) is to get the first unused index, this can be a bit tricky (especially when a registry exists, and has been copied from a native one) the possible solutions are: A/ implement this mechanism and provide an ad hoc tool for this purpose. The hard part is, in some cases, that the data to add to the registry have to be determined at installation time: the number of DSP available for the wave output, or the list of MIDI playback devices (synthesizer, midi out...) - current WineOSS implementation gets its name from the kernel -. A1/ create a specific (winelib) tool to take care of it A2/ make use of Windows installation capabilities (setup API) and provide a .INF file for each. I'm not quite sure that's feasible with the semantics of the API (mainly for the naming issue described above) B/ do not implement this mechanism B1/ provide a Wine specific easy set of keys B2/ same as above, but upon startup, Wine (or winmm/mmsystem) partially recreates the native keys as needed I'd rather go the A1 or B1. As of today, the only drawback of B1 is that some native DLLs (multimedia control panel, the midi mapper) will not work. I haven't (yet) run against a program using this poorly undocumented set of features (which, of course, will not work on Win2k with WDM in place). any comment is welcome. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

file descriptor problems
by Rein Klazes 02 Mar '01

02 Mar '01

Hi, With today's CVS I get problems with the Agent newsreader after 0.5 to 1 hour of use. Sometimes I get this: > wine client error:0x8063890: no fd received for handle 264 and the wine service tread has exited. In other cases the program shows a message box showing: cannor write <filename>. DOS error 4. and the program goes crazy. Dos error 4 means "too many files open", which seems related to the first message. Rein. -- Rein Klazes rklazes(a)casema.net

1 0

Protocol error
by Andreas Schultz 01 Mar '01

01 Mar '01

Hi, I'm getting repeatable error's with the latest CVS version: Protocol error:0x8066ae0: read : Resource temporarily unavailable The application that is causing is the Gunman Chronicles Dedicated Server. I tried to find out what is going on, but couldn't find anything usefull. Has anybody ales seen a similar behavior? Andreas -- -------------------- professional INTERNET services -------------------- EastLink GmbH Niederlassung Magdeburg voice: +49-180-5432060 Lorenzweg 42 fax: +49-371-4320626 D-39110 Magdeburg http://www.eastlink.de

1 0

Jump to page:

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