wine-announce

wine-announce@winehq.org

1 participants
668 discussions

Start a nNew thread

Wine Weekly News is suspended
by eric pouech 10 Apr '01

10 Apr '01

1 0

Wine release 20010326
by Alexandre Julliard 26 Mar '01

26 Mar '01

This is release 20010326 of Wine, a free implementation of Windows on Unix. This is still a developers only release. There are many bugs and unimplemented features. Most applications still do not work correctly. Patches should be submitted to "wine-patches(a)winehq.com". Please don't forget to include a ChangeLog entry. WHAT'S NEW with Wine-20010326: (see ChangeLog for details) - Serial async I/O improvements. - Support for app-specific dll overrides in config file. - Lots of bug fixes. See the README file in the distribution for installation instructions. Because of lags created by using mirror, this message may reach you before the release is available at the ftp sites. The sources will be available from the following locations: http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/Wine-20010326.tar.gz ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/Wi… ftp://ftp.fu-berlin.de/unix/linux/mirrors/sunsite.unc.edu/ALPHA/wine/develo… ftp://orcus.progsoc.uts.edu.au/pub/Wine/development/Wine-20010326.tar.gz It should also be available from any other site that mirrors ibiblio.org. For more download locations, see http://ftpsearch.lycos.com. These locations also hold pre-built documentation packages in various formats: wine-doc-html.tar.gz, wine-doc-txt.tar.gz, wine-doc.pdf.gz and wine-doc.ps.gz. You can also get the current source directly from the CVS tree. Check http://www.winehq.com/dev.html for details. If you submitted a patch, please check to make sure it has been included in the new release. If you want to receive by mail a patch against the previous release when a new one is released, you can subscribe to the mailing list at http://tiger.informatik.hu-berlin.de/cgi-bin/mailman/listinfo/wine-patches. Wine is available thanks to the work of many people. See the file AUTHORS in the distribution for the complete list. -- Alexandre Julliard julliard(a)winehq.com

1 0

Wine Weekly News #86 (2001 Week 11)
by Eric Pouech 14 Mar '01

14 Mar '01

enjoy this week edition. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Wine Weekly News All the News that Fits, we print. Events, progress, and happenings in the Wine community for March 12, 2001 . _________________________________________________________________ _________________________________________________________________ Headlines _________________________________________________________________ Daniel Schwarz' web site ([1] http://www.winecentric.com/) has been completely revamped and now has expanded coverage: in addition to the existing coverage of Lotus Notes, info for Microsoft Excel '97 have been added (How to install, how to use, tips and tricks, etc). _________________________________________________________________ Keeping track of Wine _________________________________________________________________ * Andreas Mohr contributed a winecheck script that lets users check that Wine is configured somewhat correctly. * Alexandre Julliard made the wineserver protocol reentrant. * Ian Pilcher moved the PostScript AFM loader's previously hardcoded font paths into .wine/config instead. * Other Workers/Bugfixers: Marcus Meissner (KDE2 support), Gerard Patel (misc dialogs and menus), Mike McCormack (overlapped I/O), Rein Klazes (message conversion), James Juran (win98/2000 stubs), Nerijus Baliunas (Latvian), Hann-huei Chiou (Chinese) + CodeWeavers: François Gouget (winemaker), Dmitry Timoshkov (edit/combobox control), Huw D M Davies _________________________________________________________________ Discussions on wine-devel _________________________________________________________________ This week, 30 posts consumed 128 K. There were 16 different contributors, 4 (25%) posted more than once, and 6 (37%) posted last week too. The top posters of the week were: * 9 posts in 31 K by "Alexandre Julliard" <julliard(a)winehq.com> * 5 posts in 28 K by David Howells <dhowells(a)cambridge.redhat.com> * 2 posts in 7 K by Gavriel State <gav(a)transgaming.com> * 2 posts in 24 K by Michael McCormack <mccormac(a)aals27.alcatel.com.au> Enhanced asynchronous I/O Evolution Michael McCormack provided a first version of a patch to enhance the I/O operations in Wine: This patch moves responsibility for asynchronous I/O to the client process. I think this implementation is more efficient, as it makes fewer server calls and duplicates fewer file descriptors, while maintaining correctness. However, Mike requested some feedback on his patch. Alexandre Julliard objected several points: * first of all, the patch conflicted with underway work from Alexandre: "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." * secondly, Alexandre really doubted the patch improved the performance. Mike tried to defend a bit his changes (especially, in the area of performance, where Mike thought he drastically reduced the number of context switches and the number of server calls), but Alexandre remained dubious: "Reducing the number of server calls but making them more expensive is not necessarily a gain. Show me the numbers..." Later on, Mike provided a second patch (a derivation of the first one, making use of Alexandre's latest improvements on the server communication protocol). Here are the final results of a simple test program Mike wrote (against Wine 2001/03/05): Wine's patch average write time for "AT" command average read time for response vanilla 675 µsec 634 µsec Mike's patch 362 µsec 322 µsec Sounds like a big gain!!! However, this doesn't fix one of Alexandre favorite topics: getting rid of the service thread (it's only use as of today is the handling of asynchronous requests). Using (SIGIO) signals should help getting rid of it. So, this discussion is likely not finished yet. We'll keep you posted with its follow-up. Wine's speed up (cont'd) Evolution Following [2]last weeks' discussions , David Howells, Alexandre Julliard and Gavriel State resumed their exchanges. David re-iterated his "main gripe against 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." Alexandre Julliard explained this had just been enhanced: the file descriptor is only transferred once. All subsequent accesses only check if the file descriptor on client's side is still valid, hence reducing the complexity and the length of the server call (but, not the number of calls). The latency of the Wine server call is rather high as David explained: 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. Since the context switch also implies that "you have to flush all the CPU caches, muck around with the MMU and execute scheduling algorithms", this can explain some of the latency. However, Alexandre thinks "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." and that "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." By a small kernel hack, Alexandre means " having a specialized fifo, a network protocol, an ioctl, etc. Basically any mechanism that ensures that we do the strict minimum 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. ". David already suggested a new protocol (AF_WINE) which could nicely fit into this category (and also let the ability to use the internal API on non Linux platforms, although the kernel module had to be rewritten). David also asked Alexandre how does he "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.". Alexandre quickly replied "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 optimizations possible, but we should probably do it the easy way first.". This would, of course, require some more server calls. Later on, Gavriel explained that Alexandre would unlikely accept a huge patch at once, and that he'd rather have an incremental approach. Alexandre answered, but also spoke out some directions for adding such a kernel module David is working on into Wine: 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. As a reminder, David used the int 0x2E trap (as any NT system does) to hook the kernel module up to the Wine code, putting more into the Linux kernel than Wine currently does with its wineserver. However, this introduces another API into Wine, and makes it quite difficult to maintain the two APIs (the INT 0x2E and the wineserver's). Alexandre explained what he had in mind a bit more clearly: "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." David also pointed out some strange issues with Wine loader. After some discussion, it turned out that alignments required by mmap did change between Linux 2.2 and 2.4. Wine did made the assumption that "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." David also proposed some enhancements for the Linux 2.4 kernel. As a (temporary) conclusion, the area of optimizing the Wine architecture is still under heavy discussion. Many tracks are available, and the potential results/benefits are still not 100% clear. On the bright side, there's still lots of space for improvement. Credits: [3]Doug Ridgway, [4]Eric Pouech, and [5]Ove Kåven. _________________________________________________________________ References 1. http://www.winecentric.com/ 2. http://www.winehq.com/News/2001-10.html#0 3. mailto:ridgway@winehq.com 4. mailto:pouech@winehq.com 5. mailto:ovek@winehq.com

1 0

Wine Weekly News #85 (2001 Week 10)
by Eric Pouech 06 Mar '01

06 Mar '01

-- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Wine Weekly News All the News that Fits, we print. Events, progress, and happenings in the Wine community for March 05, 2001 . _________________________________________________________________ _________________________________________________________________ Headlines _________________________________________________________________ Wine-20010305 has been released. Main changes include: * Some improvements to the wineserver protocol. * The usual common controls fixes/improvements. * Version information in builtin dlls. * Lots of bug fixes. _________________________________________________________________ Keeping track of Wine _________________________________________________________________ The following changes from the last two weeks made it into the 20010305 release. * Alexandre Julliard optimized wineserver communication some more (including better file descriptor caching), and strived for more DLL separation cleanliness. * Dmitry Timoshkov (CodeWeavers) added version resources to the core built-in dlls. * Eric Pouech implemented some shell32 rundll features (making the control panel starting to work). * David Grant added some copy and delete functions to the shell filedialog. * Workers/Bugfixers: Andreas Mohr (misc), Gerard Patel (16-bit print dialog, misc), Michael Stefaniuc (Winsock routing table query), Ian Pilcher (PostScript driver), Johannes Schindelin (German keyboard layout), Ove Kåven (winelauncher), Lionel Ulmer (OpenGL support), Vedan Rodic (DIB depth conversion), Przemyslaw Bruski (Mac codepage in locales), Valery Kartel (Ukrainan locale), Dominik Strasser, Chris Jacobson + CodeWeavers: François Gouget (winelib, winemaker, listview control), Dmitry Timoshkov (controls, windows, ANSI fileapis), Susan Farley (pager control), Aric Stewart (clipboard), Chris Morgan (mousewheel sysparam) _________________________________________________________________ Discussions on wine-devel _________________________________________________________________ This week, 45 posts consumed 190 K. There were 20 different contributors, 11 (55%) posted more than once, and 9 (45%) posted last week too. The top posters of the week were: * 7 posts in 17 K by Eric Pouech <Eric.Pouech(a)wanadoo.fr> * 6 posts in 38 K by "Alexandre Julliard" <julliard(a)winehq.com> * 5 posts in 17 K by Ian Pilcher <pilcher(a)concentric.net> * 3 posts in 9 K by lawson_whitney(a)juno.com * 3 posts in 23 K by Michael McCormack <mccormac(a)aals27.alcatel.com.au> * 2 posts in 9 K by David Elliott <dfe(a)infinite-internet.net> * 2 posts in 8 K by Andreas Mohr <a.mohr(a)mailto.de> * 2 posts in 6 K by Vedran Rodic <vedran(a)renata.irb.hr> * 2 posts in 5 K by Francois Gouget <fgouget(a)free.fr> * 2 posts in 4 K by "Ove Kaaven" <ovehk(a)ping.uio.no> * 2 posts in 0 K by Robert O'Callahan <roc+(a)cs.cmu.edu> Wine's speed-up Evolution (EdNote: resurrecting [1]old article) Gavriel State put out a speed issue in current Wine code: We've recently been working on getting American McGee's Alice (a visually stunning game, if you haven't seen it before) running well under Wine, and we've run into a serious speed issue with synchronization objects like Mutexes. Currently, Alice runs at about 50% the framerate it gets in Windows with the same graphics driver (NVidia). When we started investigating, it turned out that the reason for this is that it's spending half of it's time in the WineServer. At first we assumed that this was due to the fact that the GL thunks need to grab the X11 lock. We realized that this wasn't necessary for most GL calls if we're using a direct rendering GL implementation, and turned off the locks. There was no effect - because there really wasn't much contention for the x11 lock. After going through a number of similar Wine internal possibilities and getting nowhere, we finally realized that the problem was the app itself. It's grabbing and releasing a mutex of it's own bazillions of times each frame. Since there's nothing much we can do about that we started thinking about the proposed linux kernel module approach. After re-reading the thread (EdNote: you call also look at [2]WWN coverage part #1 and [3]WWN coverage part #2) and looking over the prototype, I have to concur with Alexandre's judgement - the prototype that exists is trying to do too much work. Gavriel and Ove Kaaven proposed to use a shared memory section between every process and the Wine server to help speeding up the lock/unlock operations. Alexandre Julliard didn't like the approach at all: I don't see how you are going to make this work reliably. A basic design principle of the server is that no matter what a client process does, it cannot break either the server or other clients; given the number of bugs Windows apps contain, I feel this is very important. As soon as you introduce a shared memory area, you need the collaboration of all clients to ensure the stability of the whole system, since any client can corrupt system data structures. This is very bad. Also since the server is single-threaded its data structures don't need to be protected; but as soon as you manipulate them from multiple threads you need locking mechanisms, which will probably cost a lot in performance too. Gavriel tried to minimize the impact on system stability of his proposal, but he couldn't convince Alexandre of it. Robert O'Callahan put on the table some other algorithms to tackle the issue. Unfortunately, they either required some "ugly" (read not accepted by Alexandre Julliard features) like letting the wine server call back some function on the client side, or using the already rejected shared memory approach. As a conclusion (since none went out of the discussion), it may be possible that Gav (with TransGaming) writes an almost right but quick implementation of the mutexes, but which wouldn't be commited into the main Wine tree because it wouldn't be completely right. Wine press coverage Report Eric Pouech posted a link to a [4]C|Net article, making a comparison of three Linux products, letting Windows applications run on Linux. Those products are Wine (of course), VMware and Win4Lin. The article is pretty much product (and end user) oriented, hence the final bad ranking for Wine (so far, the Wine had put more effort into adding feature, rather than putting a 1.0 version). However, the potential for Wine is here. It just needs some more (oouch) work to terminate the developments. Here are the overall comparison from the CNET Linux Center's review by Bill O'Brien:" Product Overall rank (1..10) The good The bad The bottom line VMware Workstation 2.03 9 Provides a self-contained Windows environment that makes its Linux host platform nearly immune to collateral damage. It's expensive. VMware is an essential IS tool for multiplatform application management. NeTraverse Win4Lin 2.0 7 Simple installation; good documentation; works as promised. No DirectX or Windows networking support. Win4Lin is a bargain Windows emulation platform if you need just the basics. Wine 5 Runs Windows apps without Windows; strong user community Difficult to use; spotty application support; still under heavy development. With its innovative approach to Windows compatibility, Wine is destined to play a major role in the world of Linux. But for now, it's not quite ready for prime time. " C Code style Evolution After an unwanted semi-colon had been found where it shouldn't: loops of the form: for (i = nFirst; i <= nLast; i++); { /* do something */ } , Andreas Mohr proposed several things. First of all, he wanted to add a space between the closing parenthesis and the semi-colon to indicate clearly the intent of putting an empty C expression. François Gouget replied he preferred the writing of such cases as <init_expression>; while (<test_condition>) { <update_expression>; } Alexandre Julliard more than agreed: he converted such cases into the while form of the loop. Andreas also looked for other places plagued with the same default and found another one (which he of course fixed). Unsurprinsignly, this almost started a flame war on coding style (how many spaces for a tab, which indentation style...). But it didn't happen. Wine developers seemed to like sticking to the rule of letting the developer do what best fits him (her), even if this doesn't provide a consistent coding style across the source files. Credits: [5]Doug Ridgway, [6]Eric Pouech, and [7]Ove Kåven. _________________________________________________________________ References 1. http://www.winehq.com/News/2001-08.html#4 2. http://www.winehq.com/News/2000-36.html#3 3. http://www.winehq.com/News/2000-37.html#0 4. http://linux.cnet.com/linux/0-2136864-7-4961586.html 5. mailto:ridgway@winehq.com 6. mailto:pouech@winehq.com 7. mailto:ovek@winehq.com

1 0

Wine release 20010305
by Alexandre Julliard 05 Mar '01

05 Mar '01

This is release 20010305 of Wine, a free implementation of Windows on Unix. This is still a developers only release. There are many bugs and unimplemented features. Most applications still do not work correctly. Patches should be submitted to "wine-patches(a)winehq.com". Please don't forget to include a ChangeLog entry. WHAT'S NEW with Wine-20010305: (see ChangeLog for details) - Some improvements to the wineserver protocol. - The usual common controls fixes/improvements. - Version information in builtin dlls. - Lots of bug fixes. See the README file in the distribution for installation instructions. Because of lags created by using mirror, this message may reach you before the release is available at the ftp sites. The sources will be available from the following locations: http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/Wine-20010305.tar.gz ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/Wi… ftp://ftp.fu-berlin.de/unix/linux/mirrors/sunsite.unc.edu/ALPHA/wine/develo… ftp://orcus.progsoc.uts.edu.au/pub/Wine/development/Wine-20010305.tar.gz It should also be available from any other site that mirrors ibiblio.org. For more download locations, see http://ftpsearch.lycos.com. These locations also hold pre-built documentation packages in various formats: wine-doc-html.tar.gz, wine-doc-txt.tar.gz, wine-doc.pdf.gz and wine-doc.ps.gz You can also get the current source directly from the CVS tree. Check http://www.winehq.com/dev.html for details. If you submitted a patch, please check to make sure it has been included in the new release. If you want to get the new releases faster, you can subscribe to the wine-patches mailing list by sending a mail containing 'subscribe wine-patches your_address' to majordomo(a)tiger.informatik.hu-berlin.de. You will get a patch against the previous release when a new one is released. Wine is available thanks to the work of many people. See the file AUTHORS in the distribution for the complete list. -- Alexandre Julliard julliard(a)winehq.com

1 0

Wine Weekly News #84 (2001 Week 09)
by Eric Pouech 01 Mar '01

01 Mar '01

please find enclosed the latest WWN issue A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Wine Weekly News All the News that Fits, we print. Events, progress, and happenings in the Wine community for February 26, 2001 . _________________________________________________________________ _________________________________________________________________ Discussions on wine-devel _________________________________________________________________ This week, 67 posts consumed 246 K. There were 32 different contributors, 12 (37%) posted more than once, and 14 (43%) posted last week too. The top posters of the week were: * 9 posts in 20 K by "Ove Kaaven" <ovehk(a)ping.uio.no> * 6 posts in 26 K by Eric Pouech <Eric.Pouech(a)wanadoo.fr> * 6 posts in 23 K by "Alexandre Julliard" <julliard(a)winehq.com> * 5 posts in 28 K by Ian Pilcher <pilcher(a)concentric.net> * 4 posts in 12 K by FT Rathore <mawali(a)news.icns.com> * 3 posts in 7 K by Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> * 3 posts in 10 K by Andreas Mohr <a.mohr(a)mailto.de> * 3 posts in 0 K by Robert O'Callahan <roc+(a)cs.cmu.edu> * 2 posts in 7 K by "Patrik Stridvall" <ps(a)leissner.se> * 2 posts in 6 K by gerard patel <gerard.patel(a)asi.fr> * 2 posts in 5 K by David.Goodenough(a)dga.co.uk * 2 posts in 23 K by Martin Pilka <mpilka(a)codeweavers.com> local IP and registry Issue Alan Chandler wrote: "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 recognize that there where some interfaces it could talk TCP/IP out of. It took me some time to realize 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). " Ove Kaaven agreed on the utility of the key itself, but noted that "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." There is already some keys which are dynamically generated (like the processor information - Pentium, stepping... - or copying the contents of the init files into Wine specific registry keys to ease the reading of those configuration afterwards), so the approach could be extended. However, Ove wondered how the network interfaces could be gotten from the OS in a portable way ? There hasn't been any answer so far. Setting up a Wine's test harness Evolution John Sturtz (re)-opened the long awaited issue of bringing up a test harness for Wine (and its implementation of the Windows API). I work for CodeWeavers here in St Paul. Awhile back, I was set to the task of working on winetest, a Wine application which provided a flex/bison-based parser for a little scripting language from which Wine API functions could be called. The idea was that one could write test scripts which would call Wine API functions and examine the results, and the scripts could be used for regression testing of Wine. The scripting language began life with a rather Perl-ish syntax, and as functionality got added, it got more so. Eventually (about the time I had implemented a pack function, and wanted an unpack), I decided to see if I could write a Perl extension that provided a gateway for calling Wine API functions. That way, scripts for regression testing could be written directly in Perl instead. John then provided a first implementation of this (you can find it at [1]ftp://wine.codeweavers.com/pub/other/perlwine.tar.gz). Basically, what you can do with this is invoke some tests like: $atom = kernel32->GlobalAddAtomA("bark"); Joshua Thielen pointed out that some existing Perl modules for Win32 (from the [2]ActiveState site) allowed to provide the same interface as John's work (which was Linux based only). Alan Gonzalez also noted that this "will work out of the box on cygwin for windows using the perl 5.6.1 that is bundled with it." Jeremy White then started to figure out what the test harness should contain: "I think it would be great if we could start to define (and build) a test harness. I think that there are a lot of people who would help write test scripts, who might otherwise be unable to help with Wine development. The more the merrier, I always say... " Jeremy started to split out the test cases into two categories: * non-interactive: no user interaction is needed * interactive: user interaction is needed As already covered (see [3]this article ), a free test tool for X11 regression test has not been found yet, making the second category a bit difficult to run. Eric Pouech proposed to have a two pass approach to run the test. First the test case is run and outputs some results which are stored into a file. Then, the contents of this file is compared against a reference file. This would allow, beyond the simple regression idea - running twice the same program should provide the same results -, to compare the output between running the program under Windows and running it under Wine. Eric also liked to idea of writing test cases in C which would allow to test three cases: * test case compiled and run under Windows, * test case compiled under Windows, and run with wine * test case compiled under Unix as a Winelib application Alexandre Julliard really backed up the idea of the Perl test scripts: "The idea of using an interpreter like Perl is precisely that you don't need to compile anything to run tests. I think this is important because not everybody has a Windows compiler. It also allows using the exact same test script under Windows and Wine, so that you don't have to worry whether your Windows binary exactly matches your Winelib binary. " Eric and Alexandre further argued whether it was more common not to find a compiler or not to find a Perl interpreter on a PC/Windows box. François Gouget also liked the C/C++ tests because " The downside of interpreter-based tests are: * they won't test the Winelib headers or Winelib specific issues * I imagine that some of our potential test writers would be windows programmers (after all these tests would be nothing more than simple Windows applications). They would probably be more comfortable writing tests in C/C++. " The thread ended with Eric and Alexandre still arguing on some other points. All the details of the test harness are not settled down yet, but the effort of providing such an environment has started. We'll keep you posted with the advances. Wine .so files' names Issue Andreas Mohr asked whether all the Wine libraries shouldn't be renamed to libwineXXX to avoid any conflict with existing libraries. Wine already had a clash with libole.so and gnumeric. After some discussion on how the current distributions were doing their packages (Debian, RedHat...), Ove Kaaven explained what should be the final scheme. The Wine DLL files (to be semantically correct, read the .so files containing Wine's DLLs ; see [4]for the details) should be stored in /usr/lib/wine (as FSH suggests). All the other .so files (like libwine_unicode, libwine_tsx11...) should be stored into /usr/lib (or any directory pointed by /etc/ld.conf). /usr/lib/wine shouldn't be referenced by the /etc/ld.conf configuration file. Any program (winelib or wine itself) which wants to import a file will do it through the import directive of its .spec file (and will not require the support of the linker (like using -lfoo) for that). In other words, all is already in place for a proper storage, avoiding any naming conflicts. Credits: [5]Doug Ridgway, [6]Eric Pouech, and [7]Ove Kåven. _________________________________________________________________ References 1. ftp://wine.codeweavers.com/pub/other/perlwine.tar.gz 2. http://www.activestate.com/ 3. http://www.winehq.com/News/2000-43.html#0 4. http://www.winehq.com/News/2000-51.html#FTR 5. mailto:ridgway@winehq.com 6. mailto:pouech@winehq.com 7. mailto:ovek@winehq.com

1 0

Wine Weekly News #82 (2001 Week 07)
by Eric Pouech 14 Feb '01

14 Feb '01

please enjoy this week issue A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Wine Weekly News All the News that Fits, we print. Events, progress, and happenings in the Wine community for February 12, 2001 . _________________________________________________________________ _________________________________________________________________ Keeping track of Wine _________________________________________________________________ After two weeks away from Wine, Alexandre returned to a truckload of patches... * John R. Sheets (CodeWeavers) documented the SGML documentation. * Andreas Mohr (CodeWeavers) adapted wineconf for the new config file format. * Ove Kåven (TransGaming) fixed some DIB section and DGA2 bugs, and started adding a DirectDraw HAL to the x11drv. * Marcus Meissner made the PostScript driver able to automatically find .afm files provided by software like GhostScript and others, so the user doesn't have to configure .afm file locations manually. * James Abbatiello (CodeWeavers) implemented QueryPerformanceCounter using the Pentium's RDTSC instruction. * * Other Workers/Bugfixers: Marcus Meissner (printing, ddraw, misc), Guy Albertelli (common controls), Lionel Ulmer (ddraw), Jon Griffiths (locale hashes, shlwapi), Rein Klazes (Malayan locale), Patrik Stridvall (winapi_check), Duane Clark (print dialog), Peter Ganten (afm fixes), Lawson Whitney + CodeWeavers: Andreas Mohr (various), Huw D M Davies (print dialog, enh.metafiles), James Abbatiello (shell, common controls, file mappings), Dmitry Timoshkov (enh.metafiles, MDI, Unicode), François Gouget (winemaker, Winelib, common controls), Susan Farley (pager control, window handling), Chris Morgan (listview/shellview control), Josh DuBois (portability), Aric Stewart (clipboard), Eric Kohl + Macadamian: James Hatheway (multimedia) _________________________________________________________________ Discussions on wine-devel _________________________________________________________________ This week, 87 posts consumed 335 K. There were 36 different contributors, 17 (47%) posted more than once, and 15 (41%) posted last week too. The top posters of the week were: * 6 posts in 26 K by "Patrik Stridvall" <ps(a)leissner.se> * 6 posts in 22 K by Francois Gouget <fgouget(a)free.fr> * 6 posts in 19 K by gerard patel <gerard.patel(a)asi.fr> * 6 posts in 19 K by Andreas Mohr <amohr(a)codeweavers.com> * 6 posts in 14 K by Eric Pouech <Eric.Pouech(a)wanadoo.fr> * 5 posts in 16 K by David Elliott <dfe(a)infinite-internet.net> * 4 posts in 14 K by Alan Chandler <alan(a)chandlerfamily.org.uk> * 4 posts in 13 K by Thomas Flynn <flynnt(a)acm.org> * 4 posts in 12 K by Jon Griffiths <tntjpgriff(a)tsnxt.co.uk> * 4 posts in 12 K by James Sutherland <jas88(a)cam.ac.uk> * 4 posts in 12 K by "Ove Kaaven" <ovehk(a)ping.uio.no> * 3 posts in 7 K by Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> * 2 posts in 8 K by Huw D M Davies <h.davies1(a)physics.ox.ac.uk> * 2 posts in 5 K by Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> * 2 posts in 5 K by "David D. Hagood" <wowbagger(a)sktc.net> * 2 posts in 28 K by Ian Pilcher <pilcher(a)concentric.net> * 2 posts in 11 K by Marcus Meissner <marcus(a)jet.franken.de> Wine and reverse engineering Announce Paul Merrell posted an article from PlanetIT about some recent decisions made in the USA regarding the legal aspects of reverse engineering ([1] http://www.planetit.com/techcenters/docs/security/news/PIT20010123S000 1/1?spsubcat=bugs_flaws). Paul even quoted some part of the article " Hypothetically, similar efforts taken by others to reverse-engineer Microsoft Windows could be deemed justifiable if the aim of those efforts were to make other companies' programs, designed for Windows, run on an operating system other than Windows. This assumes that the 9th Circuit ruling holds up."" In non legal terms, this would mean that Wine developers could reverse-engineer Windows without fearing some troubles from Microsoft layers horde. Robert Cunningham shed some more lights on this matter: Unfortunately, this decision applies directly only to those bringing such cases within the California 9th Circuit Court. While other courts may "take note" of this decision, it has not yet risen to the level of a "precedent". Unless, of course, the case gets appealed all the way to the Supreme Court, they decide to hear it, and they then decide to affirm the decision. Then (and only then) would the decision become the law of the land. Until that time, it will likely first have to be pursued on a case-by-case basis in all other Circuit Courts. Which means we can expect all similar cases to avoid the 9th Circuit like the plague so long as they have other venues to run to. As Paul mentioned in the quote he selected, the key item involves moving an application to a different platform. Application "portability" may legally no longer require "porting"! It may instead allow for "OS Compatibility Layers" to be written instead. This may also drive a needed wedge into the notion of migrating applications into the OS, a strategy MS has evolved into a fine art. This affects far more than Wine: One project that comes to mind is MAME (games). There are many more seemingly similar projects that are NOT affected, such as MOL(Mac-on-Linux), Win4Lin, Plex86, VmWare and probably several others that actually run the target OS, not emulate (clone) it. An extreme interpretation of this decision could be as follows: If I need a reason to legally clone a new feature in some market-leading desktop OS, all I need to do is find an app (any app) that uses that feature, then declare my intent to make that app run under some other (any other) OS. It does not matter if the feature being emulated is "documented" or not. Taken further, it may even be possible to dispose of the specific API used to implement the feature, and use a different one instead. Eventually (assuming this decision survives), the courts will see that ALL such forms of reverse engineering should be legal WITHOUT the necessity of an app to port. However, this notion still needs to be more fully explored via additional cases before its full scope can be determined. Presently, the scope appears to be very restricted: The article points out that the DeCSS decision would probably not be affected in any way. In the current environment, this is probably true. But what if you can convince the courts to view DVD "content" as a "program"! While this may seem obviously true to technical folks, especially those who create multimedia apps and content for a living, it may take many visits to court to properly communicate this understanding to the legal system. Anyway, since most of the available content security systems ARE software, and MS has already migrated theirs into the latest versions of Windows, this entire issue already has the potential to snowball completely out of the control of OS and content companies, and possibly even Congress itself. With the major media companies trying to tie software protection and content protection together under copyright law (via laws such as DMCA and UCITA), this may be just the wedge needed to pry them back apart. This could help Wine in the long term on some legal aspects when needed. However, as Robert pointed out, this is just a first step, and many more still have to be made. PS printer driver and fonts Evolution After Huw Davies submitted a patch were he hardcoded some font mappings (from Windows' Courier New to Courier) in the Wine postscript driver, Ian Pilcher started asking a few questions: Hmm. I haven't been able to get Courier to scale properly. (It prints way too large from Lotus Notes.) I was actually thinking of doing exactly the reverse. What do you think of the idea of user-configurable mappings, a la the X font aliases? Huw agreed that having this kind of substitution list would be a nice thing. Regarding the scaling issue, Huw continued: " Note if you're using ghostscript to process the output then the fonts will look about 15% larger, that's because GS's fonts are rather bigger than Adobe's and you're probably using Adobe's AFMs. Other than that then I'm seeing Wine's Courier to be about another 15% larger than the output from Windows." Gav State added:"Just FYI, the corelwine tree has support for psdrv font mapping that you might be able to use. In general, it would be nice to move the psdrv font work that was done in the corelwine tree into main CVS. While the x11drv/psdrv cross-dependency issue will have to be fixed, I suspect that it shouldn't be that hard to convert the FontTastic API calls into appropriate FreeType calls - there are only 11 places where a FontTastic API is called, and about 15 more where font properties specific to the FontTastic font server are accessed - most of which are just for added accuracy in the calculation of internal and external leading. The printing code that's in that tree is really quite good - when we were testing it, we were often able to hold the Wine generated output and the Win32 generated output up to the light and see no significant differences between them. Only after several pages of output would the cumulative error in character widths build up to the point where WordPerfect would break a line at a different word. " Note: FontTastic is a TrueType server that Corel did embed in its Linux distribution and allowed the Wine port of the Corel tools to get information about TT fonts - which still needs to be done in Wine (see [2]Xfree 4.02 and Winefor more info). Ian and Huw then discussed the details of the implementation. Ian was a bit confused with all the possible fonts (and type of fonts like TrueType, X11 Type1...) and searched a way to help the configuration. Huw answered "I anticipate that most people will just be happy using TT/Type1/.fon fonts all served by FreeType and will not bother using XLFD fonts at all. This makes font configuration quite easy, we just tell the FreeType font driver which font files we want it to serve and that's it. The psdrv may still want to substitute builtin type1 fonts, but that seems to me to be psdrv's role and thus its configuration is unique to that; this becomes more obvious when you think that the user may install 2 instances of psdrv that print to different printers which may have different fontsets installed, therefore font substitution would be on a printer by printer basis. " Part of the modifications discussed here have been added to the CVS tree. Messages and pointers Issue Marcus Meissner ran into an interesting issue: I have an application that handles several text edit controls. At one point it flips from the first to the second (after you have entered the fourth character). This is done by a function, which does (simplified) this: { DWORD startsel,endsel; PostMessageA(hwnd1,EM_GETSEL,&startsel,&endsel); SetFocus(hwnd2); PostMessageA(hwnd2,EM_SETSEL,0,0); /* ... */ CallWindowProcA(hwnd,....); return; } According to the +relay,+edit trace the EM_GETSEL is executed way _AFTER_ the return from the function, so, since it uses stackvalues, it then smashes the stack somewhere else. Ove Kaaven proposed a possible explanation: I remember Ulrich have been talking about [3]message parameters conversion ; there's the possibility that Windows recognizes that it's a message known to contain pointers, and so just drops the message, so that EM_GETSEL is simply never dispatched? Ulrich Weigand gave some further explanations: Yes. EM_GETSEL is classified as 'pointer message', and the 32-bit PostMessage in Win9x simply drops it. (The 16-bit PostMessage doesn't appear to care, but if a 16-bit message with pointers is about to be received by a 32-bit app, the Get/PeekMessage call drops the message...) You get DebugOutput messages like "PostMessage: ignoring posted message with pointer" or "GetMessage: ignoring retrieved message with pointer" when this happens. Later on, Marcus implemented the dropping of messages with pointers. Importing Wine to North America Report Well, WWN normally doesn't cover the OffTopic mails. But we'll do an exception this week. Wine-devel was posted with the following message: "I found your benchmark... it wasn't exactly what I was looking for, but do you maybe have an idea on how I can find information about the demand for wine in Canada, or North America on the internet? I'm writing my thesis on importing german wine to Canada and need to go over the demand part too of course. " This of course produces lots of sarcasm from the developers. Andreas Mohr started with: "I just had to approve this one. It's just way too funny :-) "Wine benchmark"... ROTFD (ROTF drunkenly)" Eric Pouech (from France) kept going on with the sarcasms "hmmm I ROTFL:ed mainly because of "German Wine"... isn't that on oxymoron ?." This, of course, fired some discussion about Germany being able to produce some rather good Wine, and beer too... Anyway, all the Wine team wishes the best of luck to this fellow with his thesis... Startup directory and resulting behavior Issue Alan Chandler popped up some nasty behavior: I am trying to debug a game called Grand Prix Legends, running on Wine with the TransGaming patch. If just spent all day getting nowhere in winedbg because I couldn't get hold of what the game was doing. If I cd to the directory in which the game is installed (ie ~/win/sierra/gpl) and then run wine gpl.exe The program starts and fills the whole of my screen with a single black window. It sits there until I move the mouse, at which time it exits. I have just discovered that if I cd to the root of my c: drive (ie ~/win) and then run wine c:\\sierra\\gpl\\gpl.exe The program starts and I get a 640x480 window with the correct startup screen (I have "Desktop" = "640x480" in my config file). It is not managed (even though I have "Managed" = "Y" in my config file). However the program appears to partially work - in that * The program responds to the mouse when I click on the correct parts of the screen, * It runs a race with computer AI cars when I tell it too. Gav State was puzzled but somehow confirmed the issue: I can't think of why this is happening, but I can confirm that we've seen this with a few other programs, including 3DMark2000. I don't believe that it's an issue particular to the TG patch, but I don't know of any examples of this happening with, say, a pure OpenGL game that doesn't require the TG patch. The discussion then evolved in some more detailed explanation on graphics integration in Wine. But the problem describe here shall have to be looked at. Credits: [4]Doug Ridgway, [5]Eric Pouech, and [6]Ove Kåven. _________________________________________________________________ References 1. http://www.planetit.com/techcenters/docs/security/news/PIT20010123S0001/1?s… 2. http://www.winehq.com/News/2000-52.html#2 3. http://www.winehq.com/News/1999-48.html#2 4. mailto:ridgway@winehq.com 5. mailto:pouech@winehq.com 6. mailto:ovek@winehq.com

1 0

Wine Weekly News #81 (2001 Week 06)
by Eric Pouech 07 Feb '01

07 Feb '01

please find enclosed this week slim edition... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Wine Weekly News All the News that Fits, we print. Events, progress, and happenings in the Wine community for February 05, 2001 . _________________________________________________________________ _________________________________________________________________ Keeping track of Wine _________________________________________________________________ Since Alexandre Julliard has been away most of the week for LinuxExpo in Paris, very few patches have been commmited: _________________________________________________________________ Discussions on wine-devel _________________________________________________________________ This week, 70 posts consumed 277 K. There were 28 different contributors, 16 (57%) posted more than once, and 10 (35%) posted last week too. The top posters of the week were: * 11 posts in 45 K by Ian Pilcher <pilcher(a)concentric.net> * 9 posts in 70 K by Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> * 6 posts in 24 K by Huw D M Davies <h.davies1(a)physics.ox.ac.uk> * 5 posts in 18 K by Eric Pouech <Eric.Pouech(a)wanadoo.fr> * 3 posts in 6 K by gerard patel <gerard.patel(a)asi.fr> * 3 posts in 10 K by Jon Griffiths <tntjpgriff(a)tsnxt.co.uk> * 3 posts in 10 K by Gavriel State <gav(a)transgaming.com> Delphi and Kylix Announce Marcus Meissner posted some report about a Borland announcement ( [1]http://yahoofin.cnet.com/news/0-1003-200-4642327.html?tag=pt.yahoof in.financefeed..ne), even quoting some parts: Borland will unveil its Delphi programming kit for Linux, called Kylix. The product is designed to let people write software that works with Linux and Windows, sources said. The software has been developed with help from CodeWeavers, a group working to commercialize the Wine software for running Windows software on Linux machines. From various reports, it seems that Wine is used for porting the IDE to Linux, however, the compilation toolchain seems to be a raw port to Linux. DirectDraw & TransGaming Announce Gavriel State announced a new version of the TransGaming D3D patch ( for more details): Just wanted to mention that a new TransGaming patch is available from our web-site now. This patch is mostly just to bring our AFPLed D3D work into sync with the DirectX changes that we've contributed to WineHQ CVS lately. There's not much new on the D3D side, though we're working hard with some hardware and sofware vendors to improve performance there, which you'll see in upcoming releases. The nicest thing about the latest release is that we've incorporated Andreas Mohr's SetWindowLong patch, which along with the work he did on CreateProcess now allows InstallShield installers to work properly. The other big news item is that with our recent DirectInput work, and a minor tweak to Wine's OpenGL thunking layer, American McGee's Alice demo now works perfectly. The full version won't work, due to SafeDisk copy protection, but we're starting to talk to engineers at Macrovision to help us resolve that issue. Credits: [2]Doug Ridgway, [3]Eric Pouech, and [4]Ove Kåven. _________________________________________________________________ References Visible links 1. http://yahoofin.cnet.com/news/0-1003-200-4642327.html?tag=pt.yahoofin.finan… 2. mailto:ridgway@winehq.com 3. mailto:pouech@winehq.com 4. mailto:ovek@winehq.com Hidden links: 5. http://www.winehq.com/News/2001-01.html#1

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-announce