March 2007 - Wine-devel - list.winehq.org

Winebot
by Vit Hrachovy 23 Mar '07

23 Mar '07

Hi all, first thanks for a lot of comments. I interpret this as a creative discussion helping to shape WINE project attitude to Winebot and Winebot project itself. I'll let Karl Lattimer to state his attitude with his Wine-Doors project. In the following words, I'm going to discuss my personal point of view, as I'm representing Winebot project. I'll first summarize some points extracted from the previous discussion: -------------------------------------------------- 1. My goal in writing Winebot is to help Wine succeed 2. I pledge to use only the bare minimum of native DLLs in any Winebot recipe 3. I pledge to remove native DLLs from Winebot recipes as soon as Wine fixes the bugs that keep Wine's DLLs from being sufficient for that app 4. I will report bugs to the Wine project in the course of working on Winebot 5. Installation of "basic compatibility programs" sounds like it would clash with "only use the bare minimum of native DLLs / hacks in any Winebot recipe". Winebot shouldn't install anything that the application does not need. 6. I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts 7. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster. 8. If you are making it extremely easy for users to run with native dlls and hacky workarounds, then you are hurting Wine. Wine is still beta, and we need as much testing and bug reporting as possible. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact). -------------------------------------------------- Analyzing the objections written in discussion, I've found that you are missing the following: a) Clear statement, which will specify Winebot project's goals and attitude to its parent project - WINE. Sort of manifest. b) Results - working and actively supported regression testing scripts suite. c) Forwarding bugs and list of 'unclean' fixes to bugs.winehq.org. As I'm Debian and Ubuntu user I actively borrow knowledge from the Debian project. Each Winebot package shall have a maintainer responsible for package quality and for interfacing with WINE project(AppDb, Bugzilla, Testing, Fixing). Every official Winebot maintainer will be bound by sort of Winebot manifest stating the Winebot project's attitude to WINE project. I'll write the manifest (a),(c) and post it onto Winebot Wiki. To create (b) I gladly accept any input to create a regression test repository, would You be so kind and point me to some list of programs / test miniprograms to make a reference implementation? -------------------------------------------------- 1. My goal _is_ to help Wine succeed. Hours I'm investing in Winebot are hours I'm spending on learning Wine. Recent discussion about missing reg.exe implementation originated from work on Winebot. I'm application maintainer on AppDb. I'm testing application compatibility on WINE versions back to 0.9.9. I've written Winebot especially to make the testing easier. I often install and uninstall Windows programs from WINE bottles, I'm used to bottles (WINEPREFIX) system, too. Having the installation of programs (and their dependencies) scripted is the first step for making automated testing. 2., 3., 4. All Winebot packages should install only minimum neccessary dependencies and their install scripts should be ideally only using normal application Windows installer. Any hacks above will be reported (in case they weren't reported already) to WINE bugzilla. 5. That's a relict from winetools project. 'bottle initialization' will be removed soon as unnecessary. Working package dependencies allow to reconstruct every step of setup and every 'hack' in used packages. 6. Yes, I'm planning to set up a regression tests repository for WINE (and for Winebot too). As Winebot is using AutoHotKey system for installer automation, it can also run programs, check window properties and contents, click on specified button or areas, etc. For more information, see http://www.autohotkey.com 7. Actually I consider my Winebot work is a work for WINE project and WINE users. If I find some error in WINE, I report. Same when I need new functionality. If I'm capable, I'm trying to discuss, implement and send a patch for WINE. Actually Winebot could help more WINE developers with testing, with testing environment setup and with duplicating bug cases, IMHO. 8. User simply wants his application to work. Package maintainer, who prepares the package, should interface with WINE developers whenever he spots a glitch. Package maintainer goes with new WINE versions and prepares a package for each WINE version. Package maintainer is therefore dedicated regular WINE tester and bug reporter. Package maintainer also filters user feedback to create a useful bug report, probably with a patch proposal in ideal situation. Best regards Vit Hrachovy

2 1

re: Road to 1.0
by Dan Kegel 23 Mar '07

23 Mar '07

Rob wrote: > I think the only viable way to drive for 1.0 is feature or applications > targets, with applications compatibility driving test cases and bug fixing. Yes indeedy. And the only reason I haven't jumped up and posted a proposed list of applications to support for 1.0 is that real app testing is gobs of work, more than we have resources for. The tests at http://cxtest.org could be an important part of the equation. FWIW, a couple of us have been puttering away on a scheme to make writing application regression testers easier. No promises, though. - Dan

10 23

Is anyone using "wrc --verify-translation"?
by Mikołaj Zalewski 23 Mar '07

23 Mar '07

For my translations statistics (http://pf128.krakow.sdi.tpnet.pl/wine-transl/) I use a patched wrc that has a different output for "wrc --verify-translation". Could I send this patch to wine-patches or is there someone other using "wrc --verify-translation" and would be upset if the format changes (in such a case I could try to keep both formats lauched by different options)? I'm asking because I've contacted Jeremy Newman about integrating the statistics with WineHQ and having the patch in the official tree would probably simplify the maintenance. Mikolaj Zalewski

1 0

Re: Add d3drmdef.h header file - try 4
by Dmitry Timoshkov 23 Mar '07

23 Mar '07

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: > Fix the D3DRMAPI definitions (Dimitry's Comments) > Fix the inclusion of d3dtypes.h (Francois' Comments) Where other comments has gone, into a black hole? > Changelog > ---------------- > Add d3drmdef.h header file, required for d3drm implementation This version is absolutely broken and unusable. -- Dmitry.

1 0

WinRAR installer icon creation, and the Start Menu folder
by Tom Spear 23 Mar '07

23 Mar '07

Yet another topic about the start menu, I know. This one is just a curiosity really. Why, if we create folders like Desktop and My Documents, under the fake windows directory, do we not create a Start Menu folder? I ask because WinRAR's installer looks for the Start Menu folder in various locations, but does not create it. If it doesn't find it, then it falls back to placing the WinRAR folder that should go under Start Menu\Programs into the Program Files\WinRAR folder, same for the WinRAR icon that should go under the main Start Menu folder. This causes the icons to not get created under the xorg menu, even during wineboot. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

2 4

Re: wined3d: Implement support for projective textures in ps 2.0 and later
by H. Verbeet 23 Mar '07

23 Mar '07

On 23/03/07, Fabian Bieler <der.fabe(a)gmx.net> wrote: > +#define D3DSI_TEXLD_PROJECTED 0x00010000 This should be called WINED3DSI_TEXLD_PROJECTED, and should be added to wined3d_private_types.h, together with the other WINED3DSI defines. Also, please add a comment that texldp always divides by the fourth component.

1 0

Re: [netapi32/tests] Use LoadLibrary where needed and skip
by Kai Blin 23 Mar '07

23 Mar '07

On Friday 23 March 2007 11:38, Paul Vriens wrote: > access.c currently has fixed tests for 'Administrator'. This will > obviously fail on systems with a different locale or system where > Administrator has been renamed. (Added a FIXME). I'll be looking into that shortly. Thanks for the other fixes. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Review of wine/crossover
by Dan Kegel 23 Mar '07

23 Mar '07

Another "jouralist tries linux" article. This one's pretty good. http://www.computerworld.com/action/article.do?command=viewArticleBasic&art… Her first complaint is that NoteTab Pro doesn't start when installed with Crossover. The app is $30 at http://www.notetab.com/ and sadly the free demo doesn't show the problem. The exact page where she complains about NoteTab Pro is page 3, http://www.computerworld.com/action/article.do?command=viewArticleBasic&art… - Dan

2 1

Re: [1/7] - [6/7] wined3d: Implement linear fog with pixel shader and some other patches
by Mirek 23 Mar '07

23 Mar '07

Perfect work!! nVidia VertexMorph demo is fixed and some other games too. Mirek

2 1

Re: Allow enabling/disabling Direct3D usage of GLSL in Winecfg
by H. Verbeet 23 Mar '07

23 Mar '07

On 22/03/07, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> wrote: > Hi, > according to thread 'WineCfg and DirectX options' at wine-devel, I'm > proposing a patch for winecfg to allow enabling/disabling usage of GLSL > for Direct3D applications rendering. Patch will add a checkbox into > Graphics -> Direct 3D section of Winecfg. > IMO this doesn't belong in winecfg. Nevertheless, if you want to do this, you should change the resources for languages other than English as well.

2 1