December 2005 - Wine-Devel - list.winehq.org

Re: [lostwages] Remove winetools from download page

by wino＠piments.com

On Fri, 23 Dec 2005 17:33:05 +0100, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > I'm still insisting...........and in most cases against the law. Everyone is responsible for thier own actions. Someone who makes a hammer is not responsible for a murder comitted with it. How does wine ensure that everyone who uses M$ Orafice CoralDraw or PhotoShop has a valid licence? Be a bit careful of the ingenuous arguements you use, they could backfire on you and the wine project as a whole. And perhaps not taking it as personal challenge to your authority may help further the collective effort. In your post about the download page you refer 3 times in one sentence to "wine development" and not once to "user". That is the crux of this discussion . Is wine dev an end in itself , an intellectual challenge , or does one of the developement goals include the user? You may not think so but maybe you should check with others before insisting too hard. [sorry Tom , I cut your gmail from the to header but you'll probably a copy on the list ;) ]

Dec. 23, 2005

Re: [lostwages] Remove winetools from download page

by Chris Morgan

I'm going to have to side with Vitaliy on this one. I've helped dozens of users in #winehq that have had problems with wine due to winetools since we made the changes to remove the .config file. Apparently winetools has been upgraded to work with 0.9x versions of wine, this is great news although I don't think we want to promote winetools to users if the authors aren't going to help out in #winehq and provide better overall support. Chris On 12/23/05, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Friday, December 23, 2005, 6:13:30 AM, Tom Wickline wrote: > > The Wine Tools maintainers have agreed to look into the problems that > > you have brought to the surface, can we please drop this subject? > > No. I'm still insisting on removing winetools from the download page. > They are against the wine development goals, wine development practices, > wine development and in most cases against the law. > > Authors could fix winetools, but that hasn't happened yet, and didn't > happen for so long time. > > > Vitaliy. > > > > > >

Dec. 23, 2005

Re: [lostwages] Remove winetools from download page

by Vitaliy Margolen

Friday, December 23, 2005, 6:13:30 AM, Tom Wickline wrote: > The Wine Tools maintainers have agreed to look into the problems that > you have brought to the surface, can we please drop this subject? No. I'm still insisting on removing winetools from the download page. They are against the wine development goals, wine development practices, wine development and in most cases against the law. Authors could fix winetools, but that hasn't happened yet, and didn't happen for so long time. Vitaliy.

Dec. 23, 2005

Re: mscms: unregistered color profiles?

by Saulius Krasuckas

* On Fri, 23 Dec 2005, Hans Leidekker wrote: > * On Friday 23 December 2005 14:11, Saulius Krasuckas wrote: > > > > I see some XP [1] and W2k3 [2] boxes fail on every > > GetStandardColorSpaceProfileA() using valid parameters until > > SetStandardColorSpaceProfileA() is called for the first time. Then > > all those GetStandardColorSpaceProfileA() tests succeed. > > In that case these tests have served their purpose. Are you sure they have given all they can already? I am not. > We should remove them because it is now clear that applications cannot > depend on any color profile being registered for a standard color space > in a Windows installation. Tests confirms such unability only for SPACE_RGB. To see if that's right in all other cases we should test all known SPACE_* constants. No? OTOH, I am not sure how should behave Wine itself - I guess it is registering some profiles during Wine installation process now. And my question remains unanswered - is there a way to unregister standard color space profile under win32?

Dec. 23, 2005

(no subject)

by ethereal＠centrum.cz

Hi! I have some reminds about your product "Wine" 1. When wine changes screen resolution, it changes resolution of desktop and that move my icons and i must arrange it manually after game exit and that is the problem. Please make that resolution switching like "cedega". Cedega changes the screen resolution, but desktop dimensions are unchanged. 2. Where is the config? Implementation of "winecfg" isn't good choice. Config file was good so why you have removed it? Existence of that config file will be welcomed for many users, which wants to edit some options, which they can't edit now. 3. The "-workdir" option. When i try to run some programs or when i try to install something, sometimes wine can't find files needed by installer or installed game. Cedega uses "-workdir" parameter which sets the directory, where are that files. I couldn't install or run many games and programs because of Wine can't find that files, which are needed. (e.g. wine -workdir "/root/.wine/drive_c/warcraft III/" "C:/warcraft III/Frozen Throne.exe") Thats all what i wanted to write. U have done good work so good luck forever.

Dec. 23, 2005

Re: [lostwages] Remove winetools from download page

by Tom Wickline

On 12/23/05, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > On a slightly related note, in CrossOver we force a whole bunch of DLLs > > to be builtin, like ole32, oleaut32, rpcrt4 and msi. Maybe we should do > > the same for Wine? > Well we could add them to the override list I guess. But I think it's the > part of the same problem. We seems not doing it the same as windows does. > We went from one extreme (using as much native dlls as possible) to > another extreme (use builtins only). Exactly! And if you force ole32, oleaut32, rpcrt4, msi and im sure others to builtin a lot of programs that currently run in wine will stop working. I'm 100% sure you will get all the feed back you ever wanted. And i'm sure you will see a lot of cuss words included in that feed back! The Wine Tools maintainers have agreed to look into the problems that you have brought to the surface, can we please drop this subject? Pretty Please :-) Merry Christmas, Feliz Navidad, frohe Weihnachten, Joyeux Noël, vrolijke Kerstmis Tom > > Vitaliy >

Dec. 23, 2005

mscms: unregistered color profiles?

by Saulius Krasuckas

Hello devs, I see some XP [1] and W2k3 [2] boxes fail on every GetStandardColorSpaceProfileA() using valid parameters until SetStandardColorSpaceProfileA() is called for the first time. Then all those GetStandardColorSpaceProfileA() tests succeed. I guess that mean SPACE_RGB color profile isn't registered on those boxes. Failures are just because of missing GLE codes, but IMHO we need to test this both cases. (when SPACE_RGB is registered and when it's not) The problem is that if we test the unregistered color profile and we register it later using *A functions, then repeating same tests for the *W functions won't do OK, as I found no way to unregister Standard Color Space Profile. Any ideas on how to do that? [1] http://test.winehq.org/data/200512221000/xp_punt/mscms:profile.txt [2] http://test.winehq.org/data/200512221000/2003_w2k3/mscms:profile.txt

Dec. 23, 2005

Re: mscms: unregistered color profiles?

by Hans Leidekker

On Friday 23 December 2005 14:11, Saulius Krasuckas wrote: > I see some XP [1] and W2k3 [2] boxes fail on every > GetStandardColorSpaceProfileA() using valid parameters until > SetStandardColorSpaceProfileA() is called for the first time. Then all > those GetStandardColorSpaceProfileA() tests succeed. In that case these tests have served their purpose. We should remove them because it is now clear that applications cannot depend on any color profile being registered for a standard color space in a Windows installation. -Hans

Dec. 23, 2005

RE: _itow tests in ntdll/tests

by Paul Vriens

> Hello, > I am the author of the _itow tests and the _itow function. > > As far as I can remember when I tested the _itow functions under WIN2000 > and under XP (No SP or just SP1) it was allowed to call _itow with > > _itow(123, NULL, 10) > > and the result of this call was NULL. > > The wine _itow function implemented this functionality because of > "bug by bug" compatibility (Some Applications might be based on this > "Feature"). The Test was done to find regressions or changes in the M$ > operating systems. In my opinion testing corner cases is important. > > What does "there is failure" mean. Does it crash or return something > different from NULL. When it crashes under XP SP2 the function _itow > should remain unchanged. When some other value (different from NULL) is > returned it might be necessary to change _itow. > Hi, the tests show failed on tests.winehq.org. When running the tests by themselves a nice Microsoft Error box is shown (dwwin.exe). How come the tests have to remain unchanged when crashing? After the first crash the rest of the tests are not run anymore, hence no tests ! I don't think we want that either. Paul.

Dec. 23, 2005

continuosly calling the function from winelib failing - stack overflow

by Ananth M

Hi I am able to successfully convert the windows dll into .so file and I am able to call the functions exported by dll from the winelib application. But if I call those functions from winelib application continuously for 1000 times , in a loop, then wine is crashing with the following error err:seh:setup_exception stack overflow 28 bytes in thread 0025 Then I tried calling the stub function itself in the loop (commented the code in stub function such that , it wont call the dll function ) Still I am getting the same error. Can any one faced this problem ? Can any one help on the same Thank you Regards aJAY

Dec. 23, 2005