March 2001 - Wine-Devel - list.winehq.org

WinCE/PocketWindows?

by Robert & Jennifer Hartley

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!

March 6, 2001

Re: Perl/Wine extension for perusal

by Niki Spahiev

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

March 6, 2001

Re: RFC: client side implementation of async I/O

by Michael McCormack

Hi Alexandre, The patch can be further optimised, for example by keeping active asyncs in a seperate list from inactive asyncs. i think it is more efficient because the number of server calls and context switches is reduced. What i'm more interested in is whether having waiting clients running concurrently with wineserver and those clients waking themselves from wait is a good idea. Similarly, we could create a client side file handle cache that is alerted by the wineserver when it becomes invalid. Before each fd is used, the cache implementation would poll on the wineserver communication fd to confirm the cache is valid, which would further improve the speed of file I/O. (a single poll vs. a full server call) i'm not using CVS so i'll have to wait until your next release to see the new changes. Mike On Mon, 5 Mar 2001, Alexandre Julliard wrote: > 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. > > -- __________________________________________________________________ mailto:Michael.McCormack(a)alcatel.com.au phone: (+8232) 667 0425 (h) (+8211) 430 0425 (m)

March 6, 2001

Re: TCP/IP networking and registry keys

by Chad Kitching

"Ove Kaaven" <ovehk(a)ping.uio.no> wrote: > On Mon, 19 Feb 2001, Alan Chandler wrote: > > > [System\\CurrentControlSet\\Services\\Class\\NetTrans\\0000] > > "IPAddress"="10.0.10.100" > > Nah... the IP address can change between Wine invocations (PPP, DHCP, and > things like that), so it would have to be a dynamic key, generated at Wine > startup or something like that (I think we already have a couple of > those?), but then there's a question of how to get the OS's network > interface IPs portably... I just checked on Windows 98, and when the system is set for DHCP, the IPAddress and IPMask fields are "0.0.0.0". I doubt that you'd really need to set the correct, assigned IP address (since Win98 doesn't). The other side effect of this would be for a rather brain dead program like this, the call would succeed since it would be listening on all interfaces.

March 6, 2001

Re: Speeding up wineserver syncronization objects with shared memory

by David Howells

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

March 6, 2001

Re: RFC: client side implementation of async I/O

by Dan Kegel

Alexandre Julliard wrote: > > 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. IMHO the path to optimize is not async I/O in general, but async I/O through completion ports. This is the preferred method for doing high performance I/O under NT, I think. And it might be easier to optimize because it doesn't focus on async actions visible from userspace; the main way the user code knows the async I/O is done there is by polling the completion port. cf. http://www.kegel.com/c10k.html - Dan

March 6, 2001

Re: RFC: client side implementation of async I/O

by Alexandre Julliard

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

March 5, 2001

Re: Wine Press

by Jeremy Newman

Francois Gouget wrote: > > (Okay, the glasses are really champagne flutes, but we won't > > quibble. After all, it's a work in progress.) > > Looks like one of wine-dev's favorite subject :-) > Hey, that reminds me. I am going to put up a survey. I just need a few more variations of the logo to pick from. -- _ _ WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com/ | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com/ | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 -=- Yahoo: laxdragon

March 5, 2001

Re: RESUBMIT: afm

by Gavriel State

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

March 5, 2001

Re: for loop fixes

by Andreas Mohr

On Sun, Mar 04, 2001 at 06:21:22AM -0600, David Elliott wrote: > Why, what's wrong with a for loop? > > So far we have these choices: > for(init,test,update); /* original */ > for(init,test,update) ; /* with space */ > init; > while(test) > { > update; > } > > What about simply: > for(init,test,update) > ; > > Putting the semicolon on the next line indented makes sense IMHO. Solves the > problem of confusing it with a for loop accidently having a semicolon at the end > and these kind that intentionally have one and is visible to a human at a very very > quick glance. The only expense is ONE line. Yep. I've been thinking of that, too. > > > > Please do the same for these for loops in the future. > > > > > > ??? > > Well, I just meant that they should always use " ;" instead of ";". > > But your proposal is probably much better. > > > > I dunno, I like mine but shit we are gonna start a really bad coding-style war here > if we continue with this. *g* > > > > 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. > > Correct. > > Just don't specify an indentation style, lest we be stuck with 2 or 3 spaces for an > indent instead of a nice single 8-space tab (am I the only one here who prefers > tabs to spaces?) Yep, specify anything, but please stay far away from indentation rules. Else the coding style war will strike again... Personally I prefer 4-spaced indentation in order to prevent 80 char limit overflow, but that's probably not such a good choice, as you should create a new function anyway if you get into overflow mode due to tabbed indents. > As far as specifying using while instead of for, I am not such a big fan of that > either. Personally I feel whoever is writing the code should decide. Requiring a > space between the ) and ; or requiring the semicolon on the next line indented once > more is probably the best way to go. Even an either-or approach on this would be > acceptable. ACK. I just want to make sure that we do NOT have the ); combo usually used for function call termination, so that it's obvious that the coder intended something different with this for loop. Andreas Mohr

March 4, 2001