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

Re: ADVAPI32: implement SetThreadToken using NtSetInformationThread
by Dmitry Timoshkov 13 Aug '04

13 Aug '04

"Mike McCormack" <mike(a)codeweavers.com> wrote: > @@ -545,6 +545,12 @@ > case ThreadBasePriority: > case ThreadAffinityMask: > case ThreadImpersonationToken: > + { > + const HANDLE *phToken = data; > + if (length != sizeof(HANDLE)) return STATUS_INVALID_PARAMETER; > + FIXME("Set ThreadImpersonationToken handle to %p\n", *phToken ); > + return STATUS_SUCCESS; > + } Probably ThreadImpersonationToken handling should be isolated from other thread class identifiers otherwise FIXME will be printed for all them as well. -- Dmitry.

1 0

Win API Stats
by Tom 12 Aug '04

12 Aug '04

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

5 4

Re: ATL: DllRegsterServer
by Mike McCormack 12 Aug '04

12 Aug '04

Steven Edwards wrote: > Note: While this does allow my test app to install and run I dont think > this is correct because I dont have the ATL CLSID. > > Changelog: > Implement DllRegsterServer and DllUnregsterServer Windows 2000 has: ["CLSID\\{44EC053A-400F-11D0-9DCD-00A0C90391D3}"] @="Registrar Class" ["CLSID\\{44EC053A-400F-11D0-9DCD-00A0C90391D3}"\\InprocServer32] @="c:\winnt\system32\atl.dll" "ThreadingModel"="Both" Mike

1 0

Re: dsound mixer speedup
by Joerg Mayer 12 Aug '04

12 Aug '04

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 -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

2 1

Re: Future of .wine/config
by Mike Hearn 12 Aug '04

12 Aug '04

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

1 0

Re: config converting problem
by Mike Hearn 12 Aug '04

12 Aug '04

PS I've added wine-devel back as from the wording it sounded like it was meant to go there: wine-devel is one of these annoying old-skool lists which don't rewrite Reply-To, but that rant is something for another time :) Holly Bostick wrote: > Yeah, fine, "it sucks"-- and I admit that I myself never install to > "C:\Program Files", under Windows or Wine, but geez guys-- who do you > think your users are when you say things like this? > > They're *Windows users*. And that means they probably use the defaults, > and that means that their whole data tree is in ./wine. And if that data > tree meant so much to them that they installed Wine in the first place, > it's kinda cold to say "just blow it away". Well, I'd guess that most users run perhaps one or two apps in Wine at the most, unlike Windows users who run lots and lots of apps. So every so often reinstalling these programs is not such a big deal, unless you have things like the Office XP activation scheme which don't like that. > They're non-technical (a behaviour encouraged by being a Windows user). > So while I'm sure they're used to "blowing away" their Windows > installation regularly (due to the "non-technical" nature of things like > My Documents rather than putting your bloody docs on another partition > rather than C:\, for example), since half the reason to move to Linux is > to put an end to that necessity, it seems a bit odd to reinstate it here. Yeah, I agree that at minimum we should force My Documents elsewhere, and maybe have wineprefixcreate link H: to $HOME along with putting a label on that drive saying "Save Your Files Here" (or whatever). > Wouldn't it just make more sense to *separate the config files from the > (wine) system files*?? Why in the heck is fake_windows in the ./wine > directory anyway??? Good question. I suspect the answer is "because it's always been there" :) > 1) it's hidden, so if I'm inexperienced and non-technical, I don't even > know where my programs are; Yes this is a fairly common question. TransGaming put a ~/Transgaming_Drive symlink in the home dir. Proposal: patch wineprefixcreate to build "~/Virtual C Drive" as the users fake windows tree (notice the lack of ugly underscores)? Cons: - Some users may not like it (really there's not much useful stuff in there except the program EXEs) - Are there issues with spaces in the paths used for these drives? I don't think we want to have underscores here - Localization: do we really want to translate "Virtual C Drive" into a bazillion languages? If so is the support hassle of having everybodies C drive in a different place worth it? OTOH you can say "the C drive is always in ~/.wine/dosdevices/c:/*" and be done with it. > 2) there is no reason I should have to "blow away" my data just because > I have to blow away the config. Reinstalling a program over itself is > far far easier than reinstalling it from scratch, and that doesn't even > cover the pure data that might be in "C:\My Documents". Well by "config" we mean: * Drive mappings * Registry * Config file, or what's left of it :) In future the config file will disappear and you'll only have the registry. The problem is we don't have a good way to upgrade it. 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 comes back to the discussions me, Dimi and Alexandre were having a while ago. So for now the easiest way to make sure you're up to date is just to reinstall stuff because if you delete the registry, you also lose app settings and quite a few programs don't like their registry trees disappearing. > And I don't see why we don't gently educate the users in the importance > of this issue (as a dedicated dialog would certainly do), but instead > just let them keep on doing things the same old crummy Windows way, as > if it was ever a good idea. Many users don't read info/error dialogs especially when technical, likewise Wine has to be auto-configuring. Not only is it required by most packaging technologies (they don't allow user interaction, often by design) but if we want Wine to ever stabilise and become a part of most distros base sets again it has to involve zero user interaction to setup.

3 3

Re: Future of .wine/config
by Mike Hearn 12 Aug '04

12 Aug '04

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

1 0

Re: developers-hints.diff
by Ivan Leo Puoti 12 Aug '04

12 Aug '04

> I dont think so....... I know, sorry about that, but in the wine-patches archives there appears to be an extra space amstream/ - MultiMedia Streams + atl/ - Active Template Library avicap32/ - AVI capture window class but if I do the diffing on my pc I don't get this. But patching works with both your patch, that appears to have the extra space, but doesn't, and with my patch that doesn't appear to have an extra space. I have of what is going on. BTW the patch that I sent was edited manually, so had a missing space at every added line. Ivan.

3 2

Re: X11DRV: Fix signed/unsigned comparison warnings
by Rein Klazes 12 Aug '04

12 Aug '04

On Wed, 11 Aug 2004 23:10:29 +0200, you wrote: > static int LookupEntry(LFANDSIZE *plfsz) > { > - int i, prev_i = -1; > + unsigned int i; > + int prev_i = -1; > > for(i = mru; i >= 0; i = glyphsetCache[i].next) { ^^^^^^^ Hey, this comparison is now always true, does gcc does not warn about this? I am afraid that this exercition is in many cases changing perfectly valid C code, but with warning, to possibly buggy code without warnings. I do not like this idea at all. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

RESEND CryptEnumProviders a->w cleanup and tests
by James Hawkins 12 Aug '04

12 Aug '04

Hi, I'm not sure whether these two patches were misplaced or they were considered not good enough to be committed, but I've included the patches now. I spent a lot of time hunting down any bugs in my unicode version of CryptEnumProviders as well as writing tests of its functionality. All the tests succeed except for one (wrong error message being sent back from undersized buffer) but that bug is a part of the original CryptEnumProviders as well and as soon as this patch can be committed, I can submit a fix for that bug. If there turns out to be problems with the patch, or the style is not up to par with wine coding standards, please let me know, because I really want to get this committed. -- James Hawkins

1 0