August 2004 - Wine-Devel - list.winehq.org

Re: Win API Stats

by Francois Gouget

On Thu, 12 Aug 2004, Tom wrote: > Hello, > > The Win API Stats page is broken in a bad way! > See: http://www.winehq.org/site/winapi_stats Actually I now have a cron script that updates my page regularly. However it's been failing since 2004/06/05 witht he following error: ./tools/winapi/winapi_extract --pseudo-stub-statistics --no-verbose --no-progress loader/preloader.c: 226: syntax error: 'ElfW(auxv_t) *av' Unfortunately I have not had the courage to go dig in winapi_extract to find out how to get it to cope with this construct. (consider this a call for volunteers) This error is probably the same reason why the WineHQ page is in a bad state (except my script leaves the last good version instead of wiping out the page<g>). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

Aug. 12, 2004

Re: Acknowledgment page

by Jeremy White

Hmm. I have several thoughts on this. First, I think that corporate sponsors get enough 'props'. While I appreciate the gesture, I'd rather the acknowledgements page highlight the many people who do good work for Wine without pay or other recompense. I'm not suggesting you remove credit for corporate sponsors (Corel's contribution, in particular, I have long felt has been under appreciated by the larger community), but I'd think that all parties should be treated equally, and with perhaps a shorter blurb about their contributions. Now add $1.48 to that $0.02, and you can get a cup of coffee... Cheers, Jer Tom wrote: > Hello everyone, > > A couple months back I voulenteered to do a Acknowledgment page > and to say the least i'm a bit stuck. I have a first draft/alpha that i'm > going to attach here. > I would like to know if there is anyone who would like join me in doing > this page? > Or if anyone here has some ideas on how to improve, complete this page? > > I would like to see a discussion on setting a criteria for this page. > As this will be a very important page on the winehq site. > So any and all feedback is most welcome. > > Tom > > > ------------------------------------------------------------------------ > > > business that donated significant code to Wine > > http://www.codeweavers.com/site/services/accomplishments > > 1. Made Wine work with Microsoft Office, Adobe Photoshop, Lotus Notes and Quicken > 2. Made Wine work with QuickTime, Windows Media Player and Shockwave > 3. The Wine 1.0 Initiative > 4. Wine Bugs Database > 5. Wine Application Database > 6. WineHQ Redesign > 7. Wine Documentation > 8. Winemaker, or making Winelib actually useful > 9. Easy to use Configuration > 10. Address Space Separation > 11. Unicode/code pages support > 12. Dramatic window management revision > 13. Shared Window handles > 14. Most of the DLL separation work > 15. Debugging API > 16. Lots of work on the common controls > 17. About a gazillion bug fixes > 18. Making many more installers work > > http://www.corel.com/ > > Corel dedicated a team of paid engineers to the Wine project in January 1999. This team > focused on adding functionality to Wine that let Corel applications, such as WordPerfect, > CorelDRAW, and Quattro Pro run on Linux and be ported to native Linux applications. In the past, > Corel relied on conventional porting techniques to move some of its applications > (Corel WordPerfect 8) to Linux. This provided a fast way to get these applications to > Linux, but meant that porting had to be repeated with each new version. Otherwise, > development had to be maintained on two separate code bases, which required considerably > greater resources. Although there is an up-front investment in time and energy required > to make Wine viable, once it reaches a high enough level, the facilities it provides > can be used repeatedly to port many applications with minimal engineering effort. > > http://www.macadamian.com/column/wine101.html > > macadamian got involved with the Wine project through partnership with Corel Corporation. > > http://www.transgaming.com/ > > 1. 2D DirectDraw > 2. DirectSound > 3. DirectInput > 4. DCOM, RPC > 5. WIDL IDL compiler > 6. Wininet code, including SSL support. > > > http://www.deneba.com > > worked on winelib extensively in order to make Canvas work. > > http://www.fujitsu-siemens.com/index.html > > Implementation of Windows-style asynchronous I/O over sockets in Wine. > As well as small contributions to advapi32 and netapi32. > > http://www.reactos.com/ > > 1.Wine Registry Editor (regedit) contributions. > 2.Shell32.dll code contributions > 3.Am I missing anything ?????????????? > > > People that donated money > > Lindows.com helped to put on the first Wine developer's conference in 2002, by both hosting it > and paying travel expenses for many major Wine developers. > > Codeweavers.com helped to put on the second Wine developer's conference in 2004, by both hosting > it and paying some expenses for major Wine developers. > > Below is a short list of people who have given money to the wpf. > If you have given money to this fund and would like to be included > on this page just send a e-mail to wine-devel and ask for inclusion. > > * Dimitrie O. Paun > * Michael Stefaniuc > * Nick Capik > * Tom Wickline > * Gregory M. Turner > * Sylvain Petreolle > * Dan Kegel > * John Alvord > * Kirk Ruff > * David L. Harper > * Bob Hepple > * Mark A. Horton > * Kevin P. Lawton > * The Syntropy Institute > * James Woulfe > * VMWare Inc. > > Major code contributors > > Okay this is where I'm really stuck... First off I was not here the first eight years of this project > so I have no idea of who was the guru of the day. Also some may say if you list one person > you should list everyone. But that is the job of the Authors page. So should I just say here is the full > list of people who have given there time and work and link to the Authors page ?

Aug. 12, 2004

Re: Win API Stats

by Dimitrie O. Paun

On Thu, Aug 12, 2004 at 03:36:38AM -0400, Tom wrote: > Hello, > > The Win API Stats page is broken in a bad way! > See: http://www.winehq.org/site/winapi_stats > I think we should just go with > http://fgouget.free.fr/wine/winapi_stats-en.shtml No, we should just fix it, it was working fine some time ago. It is, in fact, running the same code as Francois'. -- Dimi.

Aug. 12, 2004

Re: dsound mixer speedup

by Robert Reif

Joerg Mayer wrote: >On Thu, Aug 12, 2004 at 12:24:20AM -0400, Robert Reif wrote: > > >>Speed up mixing and unmixing by moving sample size and buffer >>wrap tests to outside the loop. The code is not as compact or >>pretty >>but it should be faster. >> >> > >Just out of curiosity: *IS* it really faster? Maybe gcc already did >the optimization? > > Ciao > Joerg > > > for both 8 and 16 bit samples (no optimization) the new code executes in about 48% of the time of the old code (twice as fast) 8 bit -O3 75% of old code (1.5 times as fast) 16 bit -O3 50% of old code (twice as fast) This is with a 32k buffer and a 1k chunk size.

Aug. 12, 2004

Re: Future of .wine/config

by Mike Hearn

> Although this increases simplicity, it also narrows the user in his > possiblities to adjust wine to his needs. How many options in the config file do you adjust? I mean, really, options like: * PerfectGraphics: what does this do? Hands up anybody who can tell me without grepping the source. How many people set it? * DesktopDoubleBuffer: This is "necessary" only until the WM rewrite is complete, at that point we can make the right choice on the fly depending on the applications requests instead of requiring the user to somehow know what it is and how to set it. * UseTakeFocus: I never did find out what this is :) etc etc. There are a lot of options in there that are "bogus" options, the user cannot know how to set them correctly without a god-like understanding of the Wine/Windows/X11 internals. These are what I am referring to when I say we are removing them. Options like your drive mappings, what Windows version to emulate (as our heuristics often get this wrong) and whether to use desktop mode are being left in. Though actually the plan for desktop mode is to (eventually, I hope) integrate AJ Pasydns patch to make it a separate app so you can run "winedesktop foobar.exe" if you want to swallow it in a desktop. > To take away configuration options from the user seems to be a trend within > the wine developers' community ;-) Why do you do this? Wine users are Linux > users (although they run Windows applications). They _want_ to be able to > configure their software to the limit (while at the same time being able to > install a package and start working - but this is no contradiction!). It's a trend within the whole open source community really, because people woke up and realised that our software was full of stupid options where the cost outweighed the gain (or as is the case with Wine, where even the developers no longer knew what they did!). > In fact I try to do as much work as I can within a terminal. If I have the > (reasonable) choice between GUI and TUI, I choose TUI (and I'm not an old > Linux guru). That's fine, so edit the reg files with emacs or whatever. > 1. It has to be written. While a developer writes winecfg, he could also > hack wine and improve it. Yes, but ease of use does take time .... > 2. It has to maintained. Whenever there is a new option, winecfg has to be > updated. No. Whenever there is a new option it should have a smart default and really Wine is not something users should interact with directly. It should Just Work and be invisible in the background. They interact with their applications. Very, very few options should be exposed to the user - most of our current options are covering up for the fact that Wine sometimes doesn't have enough information to make the right decision on a per-app basis (or that we can't know at runtime). With smart coding most of these bugs can be fixed so Wine makes the decision for the user (and is always right). > 3. It has to be documented as well as config file has to be documented. So > this is no pro for winecfg. Most config file options are currently undocumented anyway, and many are very tricky to explain even if they were documented. > 4. It narrows choices. If the user wants some unusual config, he will have > to edit the registry files manually. This problem already appears at the > very beginning with wineinstall: If I don't want to install wine in > /usr/local but in /home/addy/wine (because wine changes so often that it's > easier and more secure not to have to be root every time I update it), I > have to edit wineinstall. (wineinstall is just an example of the overall > trend) Well you can always use the graphical regedit tool. This was a requirement for 0.9 for exactly this reason. Wineinstall is not meant for users like you, it's meant to be a single "install me" command. If you want to control the defaults just do what you'd normally do: ./configure --prefix=/whatever && make depend && make install That's all there is to it these days. > It has > one BIG advantage also, namely that we can write a graphical editor for > it! It's really hard to do that with the current config file even though > they have the same syntax. > > > Why (just curious)? The code to load/save/lock/read registry files is already written and is well tested. That's why the config file is internally accessed via the registry APIs in Wine (though I sometimes wish it wasn't, the win32 registry API is very awkward). To do that for the config file whilst preserving comments, whitespace etc would be very difficult and require separate code. > First you have to find all places containing wine's configuration. Then you > have to copy/paste all those pieces and hope you didn't forget one ;-). Not really, it's all under one branch. And you can use the graphical regedit tool (shipped as part of Wine) to do the export if you really want. >>Importing becomes "regedit myconfig.reg". > > > So you have to start wine in order to setup the configuration in order to > start wine. Do you think this is a good way? Sure. Like I said, I have been running with no config file for some months now -> no problem :) Wine should not require configuration. Therefore if it needs a config file, we're doing something wrong!

Aug. 12, 2004

Development model/versioning stuff: Interesting essay on why decentralised versioning is a bad idea

by Mike Hearn

http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot What are peoples thoughts on this? It's not (despite appearances) an argument against BitKeeper due to licensing concerns, but rather a short paper on why the author believes the "pyramid" patch/development system is a bad idea. Alexandre has shown a strong preference for Arch being the future of Wines development, which basically implies a pyramid development model. So I thought this document would be of interesting. thanks -mike

Aug. 12, 2004

Re: config converting problem

by Mike Hearn

> Ahhhh..... well, fine, I suppose we could argue all day over what "most > users" might do, but I myself certainly run more than "one or two apps" > under Wine, because 1) I play games and 2) there are currently about 4 > apps that are more convienient for me to run under Wine atm than to try > to understand the Linux alternatives (assuming they exist), and at least > 1 that might be replaceable, but I haven't done the research yet, and it > is essential to maintain in its current configuration, as I still need > its functionality. OK, I consider myself corrected :) I had no idea people ran so many apps at once in Wine. > That would be a start, and that's a good thing. A basic "Optimal way to > configure and use Wine" document would be even better (and yes, I'll get > to work on one myself, and submit it to Bugzilla for review; I'd not say > "you all ought to do this" like that. I'm a Linux user). Sure, though post it to wine-devel or wine-patches, bugzilla isn't watched all that closely compared to the mailing lists. It also tends to kick people into action more. > It would be > nice to have a clue what was going on from one month to the next, > especially since-- as noted here on the list-- many users are making a > big jump from any "last stable" version installed with their distro > (which may well be from late 2003 or early 2004) to the current version > found on the site, in which time there have been significant changes, > and much of the documentation on how to configure Wine they may have > previously seen could be obsolete. We try and keep the docs up to date but of course once a user has read them (if they do at all) they tend to consider it "read" and don't do so again. I don't blame them, I'm just as guilty of this as anybody else! So I don't know how we can communicate this stuff better. A brief summary of each months changes is put into the release notes by Alexandre but I do not know how many people read them. There is also the Wine Weekly News. > No, I can see how there might have been good reason for it originally. > After all, how could you expect to auto configure Wine to map drives to > my system when you actually know very little about important aspects of > my system (most notably the mount point for my CD-ROM and floppy drive, > which change across distributions, but are generally essential for the > installation and/or operation of the vast majority of Windows programs). We need to fix that. It's not hard, parsing the fstab can tell you this. Marcus has some code for it I think. > Surely the Wine and CX teams are not under the > impression that your userbase is so completely separate and distinct > from the Transgaming userbase, that it does not have similar needs, or > confusions? So I've gotta say, I don't get why this issue is "news" to > you all insofar as you're just now thinking of how to patch/rectify it. > It raises all kinds of questions for me as a user, which can be > generally summed up as, "Don't you care about me at all?" and > supplementally as, "Don't you all even use Wine?" Of course we do, but there are a million little things we could to Wine to improve it for users - simply saying it and actually doing it are different. Now it's been suggested, somebody has to write a patch to change the default location, test it, make sure that it works, convince Alexandre to merge it, hope it doesn't annoy people and so on. > Why or how, btw, is this a beneficial change? I'm a user, I just live > with it, but no one has actually told me why making the config more > inaccessible to me, and more difficult to work with, is better for me > than the (admittedly confusing, but at least available) configuration > file of the days of yore..... We're not. Please, it's a very pretty tinfoil hat but it's not necessary here. Try running "winecfg" sometime - it's in your current release. It's not finished, and until we flick the switch it won't change your actual configuration (not to mention the UI love it needs) but doing this sort of graphical configuration is very tricky if the config file isn't inside the registry. By moving it there, we allow graphical configuration (which is a good thing). As explained elsewhere, take a look at the .reg files in your .wine directory. They are text just like the config file is. Now do an i-search in your favourite editor for Wine\Config : when we switch it over that will put your cursor on the first line of the config file which you can copy/paste/edit/share to your hearts content. It also makes it easier for people to do "canned" configurations. For instance you could send people a foobar-app.reg file which contains appdefaults for FooBar 2000. Then people can install it by running "regedit foobar-app.reg", which means we can associate it with the .reg extension in file managers and so provide 100% graphical configuration sharing (for the importer). The problems with upgrade aren't to do with binary vs text (Wine does not use binary registries). They are to do with things like modifications to the default configuration wiping out the users changes. That's why recently I've been running with no config file at all and submitting patches to fix bugs found in that mode. The aim is that the default configuration choices are all made in the code so whatever is in the config registry branch is the users choices - that way we can leave it alone. Up until now we've always done such changes my altering the default config file, but users don't typically replace their config file with the default when they upgrade Wine so this is a poor way of doing things. >> Currently once the users .wine is created their registry is "static" >> and even if we improve the default registry it'll never be recreated. >> Ditto for COM registrations, they are only done at wineprefixcreate >> time as well. This is the other problems with upgrades. We only run wine.inf when a new .wine is created, so new COM servers won't be registered in the upgrade scenario. That can lead to the user not receiving new/fixed code. It's a tricky problem. > I > don't think I even dare to ask about the relationship between drive > mappings and the Registry (what if I get a new giganto HDD and want to > move my Wine installation over to it? Do at least changes to the > /dosdevices/ folder migrate into the Registry? In which case, it's not > totally static, and if not, how can that ability be expanded?) dosdevices is entirely separate from the registry. > "Please specify a location for your fake_windows directory" is > technical? Geez, even Windows installers let you specify a location for > their Start Menu entries-- they don't seem to find *that* too technical. > And if the install process has stopped on that question, you *have* to > read it. Don't you? No, we don't control the install process (RPMs can't ask questions, for instance). > Why? Yes, I know there's an answer below this, but it doesn't answer. > Auto-configuring doesn't much help if the auto-config is wrong (just > look at Samba. Is there so much as a single soul who has ever been able > to connect to their Windows network using the default configuration, and > has not needed to edit /etc/smb.conf to-- at the very least-- correct > the workgroup name?). I have yet to have anything but fake_windows > (hardcoded to a hidden directory), /tmp, / (sometimes), and ${HOME}$ > automatically mapped. > > No CD-ROM. I have to do that myself. That's just a bug. > No outside partitions (one of which is the one where I commonly keep > Wine-installed programs, so that I can just say I want the app in D:\ > and know where it's going). Have to do that myself, too. Yeah, yeah, I > know, I could just use / and drill down, but 1) that's a pain and 2) > that assumes that the installer works properly and allows me to move > around in the "semi symlinked" directory tree, which some installers > barf at-- and if the installer actually requires me to type a path, I > have to remember the entire tree from / all the way to wherever I have > mounted the partition, somewhere in my home directory. Hopefully the > pathname is not too many characters. At least winesetuptk used to map > all the FAT32 partitions it found, meaning I only had to map the one > "extra" ext3 partition. Of course, since I'm eliminating my FAT32 > partitions now, even that wouldn't help me anymore. winecfg can do drive editing (in theory, it's kind of buggy right now) > And that ${HOME}$ evar has never worked for me, in the year and a half > that I've been using various versions of Wine, so I have to manually > change it to /home/username anyway. Really? I never used it (the default config doesn't, it seems). Why was this never reported? > There are most definitely programs that do ask you one or more questions > during install; I guess they're mostly servers, which I'm not too > experienced with, but I did (by mistake) install apache or postfix or > something that wanted me to set a password before it would finish the > install. You're probably using Debian or Gentoo. Quite a few distros can't/won't do this. > I mean, fine; I can't speak for "the requirements of packaging > technologies" (although my impression is that none of those blasted > distros should be packaging Wine anyway, as they all muck it up), nor am > I a distro developer who specifies requirements for inclusion into > anybody's base package-- but why do you "have" to be a part of any > distro's base package? Is there something wrong with being in contrib? > Admittedly, Wine is usually in "unstable contrib" making it hard to > track down the current version under some distros, but how is > "stability" related to user interaction in the post-install? Well, at least one of my personal goal is that long term Wine becomes an "OS subsystem" as much as the kernel or X is, and that it's always present so when the user clicks and EXE it magically just works. We're a long way from that today, but that's how I think it should be. By definition that means it has to be auto-configuring. That means sensible defaults that can be easily changed later if the user desires it. > I guess what's been confusing me for some time is just whose needs the > project is aiming to serve. Is Wine really just a cover for a free and > unregarded technological testbed for the paid project (more naievete > from me), and we should be quietly grateful that it's available to us at > all (operative word, "quietly")? Is it just an interesting exercise for > cross-platform developers, and we should be quietly grateful that we are > able to run any Windows programs that we might value at all? Where is > the focus? It definitely doesn't so much appear to be on those who, for > financial, philosophical, or intellectual (they don't know any better) > reasons, choose to use Wine (as opposed to the alternatives) and expect > it to be understandable, and-- dare I say-- relatively easy. <stock open source answer> It is focussed on those who focus on it. It works in the way the developers make it work. Some developers choose to try and address end-user issues like configuration, some do not. For instance I once worked on winecfg even though it's useless for me, because I think it's necessary for Wine to become easier. I'm planning on doing more work on it soon. > Because that is the sort of feature that I, as just a regular user, > actually care about, it is the kind of thing I notice when developers > add all kinds of *other* features *but* that-- and that's why I'm > definitely confused as to who these users everybody is catering to are. > > Maybe I should hang out at more Linux bars.... Well now I'm just confused. Wine already auto-configures itself to a massive extent, presumably you never noticed or don't care about the things it automatically does. Making it go all the way just makes a great deal of sense, it doesn't mean you have less control though.

Aug. 12, 2004

Re: Future of .wine/config

by Mike Hearn

Adrian Willenbücher wrote: > 1. Even if the registry keys and values of wine's configuration should be > well documented, it's easier to set some values using a text editor than to > use regedit and look for the keys. We know that, this is why we're: a) Eliminating as many config options as possible b) Writing winecfg to configure the rest graphically > 2. Although it might be convenient to access both, wine's and the Windows > programs' data, using the same functions, this should not be done as there > should be a clear distinction between wine and the programs it runs. You realise that the config file was already mounted into the registry on startup right? This is just about moving files around really. It has one BIG advantage also, namely that we can write a graphical editor for it! It's really hard to do that with the current config file even though they have the same syntax. > 3. If a program misbehaves and messes up your registry and/or if you decide > to start again with a clean installation, you just delete some registry > files and directories and have a new system (I think of the case you don't > work in a native Windows installation) without to setup wine's configuration > again. > > 4. To put wine's configuration into the registry is a step towards a > "Wine-is-Windows", i.e. not just providing Windows' functionality but also > behaving like Windows (and this should be avoided under all circumstances > ;-) ). Wine is "just" an emulator for Windows, it is not supposed to be a > new "Open Source Windows". > The Windows' handling of configuration data (every application puts its data > into the same two files: the registry) is inferior compared to the Unix' > one's (every application has its own configuration file/directory in a > common place). This makes it difficult e.g. to manually deinstall a > program/software package. > Well, my opinion. What do you think about it? I think you need to open up ~/.wine/system.reg in a text editor and observe that it has a nearly identical syntax to the config file ;) Exporting a configuration is just a matter of copy/paste. Importing becomes "regedit myconfig.reg". There are currently no plans to move to a binary registry format. thanks -mike

Aug. 12, 2004

Re: developers-hints.diff

by Mike Hearn

> It looks odd because the existing lines have tabs, but the added lines > have 8 spaces instead. Yes, it's a very annoying problem, but I think it's purely aesthetic. Once applied the code should look OK in CVS. If anybody knows some emacs magic to figure out if the buffer seems to use tabs rather than spaces that'd be useful, thanks (a bit like guess-c-offset-mode).

Aug. 12, 2004

Win API Stats

by Tom

Hello, The Win API Stats page is broken in a bad way! See: http://www.winehq.org/site/winapi_stats I think we should just go with http://fgouget.free.fr/wine/winapi_stats-en.shtml and link to it. and kindly ask Francois to update it from time to time. And it has always been far better than the page on winehq... just my $.02 Tom

Aug. 12, 2004