Re: Best way to overlay a filesystem for a Wine app?

[Vit Hrachovy]

Hi Scott,
I've been addressing similar issues with my DosBoxed games project.


More complicated Windows applications, however, won't be doable with
this basic approach.  Specifically, Windows applications might:

1) Be distributed as installer files


Debian packaging rules state the program should be installed ready to 
use. Most installers can be scripted, though. You're probably aware of 
the problems rising from distributing installer only:

  * packaging mechanisms won't be leveraged
* you'll have to write and maintain install/uninstall scripts
* you'll have no way to detect and repair possible corrupted files
* you'll delegate package security mechanisms someplace else
* in case of multiuser system the program data would be duplicated 
across their homes



2) Have self-updating mechanisms


The approach that fits best with system packaging mechanisms would be to 
leave package updates on distro maintainers and disable autoupdating in 
the application.



3) Expect their own folder to be user-writable


I've solved that by app run script that creates app folder in user's 
home, symlinks all RO data from /opt and copy RW data to the folder. 
This approach is tightly app-specific. It addresses RO data sync problem 
during package update. However it requires taking care of syncing shared 
RW data from /opt to user home in the app run script.




One ugly not-quite-solution would be to just have the package put the
installer in opt, provide a link to it, and expect the user to install
like he would a downloaded application (and then use a different
.desktop file to actually run the program).


See comment to #1. This might work for single user machine, but not for 
multiuser server. Also it makes most security features of packaging 
system unusable for these apps.



Slightly better is to just copy an entire /opt prefix template into user
space on first run, and then let it go on its own way after that.  An
app which didn't self-update, however, would then be unable to benefit
from an updated version of the system package.


Same like before - security problems + disk space requirements rise  per 
user base. Consider multiuser system with user quotas on /home. It may 
seem an overkill until you realize that for example modern game installs 
consists of 4-8GB of static data. In case of system with 4-5 users who 
want to play the game, this multiplies the storage space requirements as 
well as prolongs the first run startup time.



A more complete solution would have a prefix in the user space, but
files inside it would actually be those residing in /opt.  A system of
symlinks might work, but if a package update introduced new files those
would not be available without complicated scripting to add the links.


That was my solution for apps that need RW access to their dir or need 
RW access to their binaries. App run script ensures symlink health at 
each start (solves package update problem). However, each app has to 
have its own crafted and maintained app run script.



To me, this sounds an awful lot like an overlay file system.  Would
unionfs-fuse be the correct solution here?  The .desktop file that sets
the Wine prefix and also launches the app could mount the FUSE
filesystem, and the user-space Wine prefix's files could take priority
over those in /opt.  Stuff like user-modding and update/repair systems
could work properly in that context as well.


This seems elegant and easy solution to me. It may address most of the 
problems, except the one when app needs to open its own data/libraries 
in RW mode and writes to them. In that case those data/libraries won't 
benefit from package system update features and their syncing would need 
to be handled somewhere in crafted app-specific script.


Regards
Hark

Re: RFH: Solaris users with IPv6

[Vit Hrachovy]

Hi Juan,
feel free to send me the patch, I'll test it.
Regards
Hark

On 11/15/2011 09:08 PM, Juan Lang wrote:

Hi all,
in the tidy up I've been doing to iphlpapi, I notice that on Solaris
it's possible to enumerate IPv6 addresses using SIOCGIFCONF.  I've got
a patch written that does that, but I have no way to test it myself.
If anyone here has some version of Solaris with a machine with IPv6
addresses, even autoconfigured ones, and feels like testing a patch,
please let me know.  I'll send the patch and a small test program.

Thanks,
--Juan

Re: Wanted: TestBot maintainer

[Vit Hrachovy]

Hi Greg,
I'm interested.

I'm pretty confident in Perl and have experience with VMware 
server+player/VirtualBox/XEN so I hope to learn vSphere quickly.


Regards
Hark

On 04/ 5/11 08:23 PM, Greg Geldorp wrote:

Due to personal circumstances I won't be able to maintain the TestBot
much longer. I'm looking for a volunteer to take over this
responsibility. I can offer the hardware on which the bot runs for
another 2 years or so. You'll get full access to the hardware. It
helps if you have a bit of experience with VMware vSphere, but that's
not absolutely required.

Day-to-day operations have been running pretty smooth for the last
couple of months, so the demand on your time won't be that great.
There's the occasional account request that needs to be approved and
that's pretty much it. Every now and then the VMs should be updated
using Windows Update. The code itself seems to be reasonably stable.
It's all Perl.

If you're interested or would like more info, please let me know.

Greg.

Re: RFC: Sharing a wineprefix

[Vit Hrachovy]

Hi Paul,
as usual admin of home PC server with few users sharing installed games, 
I'm really missing feature similar to this in Wine.

You've got my vote and should you need testing, I'm glad to help.
Regards
Hark

Re: DIB Engine : passing all tests

[Vit Hrachovy]

Massimo Del Fedele wrote:

Btw, sorry all but I begins to be tired of telling same stuffs again and
again. I made a proposal for something that *could* help the migration to
final design, a *working* proposal, not just a prototype, and I believe 
on it.

If that's not what most devels think, for me is ok.
The engine will be available as a patch for whom needs/likes it, point.


Hi Max,
would it be possible to craft a wikipage on Wine Wiki, that would encompass
 * official DIB implementation requirements
 * high level description of Huw's solution
 * description of Your solution incl. proposed integration plan

It would ease the orientation, prevent repeating the same stuff again 
and again and it could also serve as a solid base for further discussion 
about DIB integration requirements.


Regards
Hark

Re: Wine on Solaris 10 and SXCE

[Vit Hrachovy]

Austin English wrote:

On Wed, May 6, 2009 at 5:15 AM, Vit Hrachovy  wrote:

Austin English wrote:

 OpenSolaris
   package wine in repository http://pkg.opensolaris.org/contrib

Is the contrib repository enabled by default? I haven't noticed it
when using OpenSolaris...or is it new for 2009.06?

No, you have to add contrib repo manually. contrib repo exists since 2008.11
release.


Ahh, thanks.

Do you know if there's any plan on OpenSolaris's end to include Wine
in its repository?


There are no plans to add Wine to /release repository by now (no ARC 
case I'm aware of).


However, anyone can use SourceJuicer [1] and SFE wine spec file [2] to 
contribute latest Wine release to /pending repo and ask /contrib repo 
maintainers to update the package here.


*rumour*
IMO one of technical barriers preventing Wine in /release repo could be 
 that Wine doesn't compile with SunStudio compiler, only with gcc.

*eof rumour*

Regards
Vit

[1]http://opensolaris.org/os/project/sourcejuicer/
[2]https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk/SFEwine.spec

Re: Wine on Solaris 10 and SXCE

[Vit Hrachovy]

Austin English wrote:

On Wed, May 6, 2009 at 3:56 AM, Vit Hrachovy  wrote:

Hi people,
Apostolos provided me links to download Sun packages of latest Wine (1.1.20)
at sunfreepacks. Could someone responsible please update WineHQ page with
the following info:


The sources are available at http://source.winehq.org/git/


Ahh, thx. will send patch.




  OpenSolaris
package wine in repository http://pkg.opensolaris.org/contrib


Is the contrib repository enabled by default? I haven't noticed it
when using OpenSolaris...or is it new for 2009.06?


No, you have to add contrib repo manually. contrib repo exists since 
2008.11 release.


Cheers
Vit

Wine on Solaris 10 and SXCE

[Vit Hrachovy]

Hi people,
Apostolos provided me links to download Sun packages of latest Wine 
(1.1.20) at sunfreepacks. Could someone responsible please update WineHQ 
page with the following info:


http://winehq.org
  Run Windows applications on Linux, BSD, Solaris and Mac OS X.

http://winehq.org/download/
   Solaris
 http://www.sunfreepacks.com/listing/?limit=1000&offset=0
   Solaris 10
 http://www.sunfreepacks.com/pkgpool/ASwine-1.1.20.pkg.7z
   Solaris SXCE
 http://www.sunfreepacks.com/pkgpool/ASwine-SXCE-1.1.20.pkg.7z
   OpenSolaris
 package wine in repository http://pkg.opensolaris.org/contrib

Thank you very much!
Regards
Vit Hrachovy


 Original Message 
Subject: Re: wine web pages update
Date: Fri, 1 May 2009 11:31:53 -0700 (PDT)
From: Apostolos Syropoulos 
To: Vít Hrachový 


  Hello there,

  We have exchanged a couple of messages back in March about the 
inclusion of
Solaris/OpenSolaris download link in the wine pages, but still there is 
no progress.

If you visit the following URL

http://www.sunfreepacks.com/listing/?limit=10&offset=20

you will be able to download binary packages for both platforms. Could 
you please

update your web pages?

Kind regards,

Apostolos


--
Apostolos Syropoulos
Xanthi, Greece

Re: NTFS filesystem features -> WONTFIX?

[Vit Hrachovy]

Paul Vriens wrote:
Even 'df -T /home/user/.wine/dosdevices/c:' will give you the correct 
mountpoint and filesystem type.


df -T is not portable (tested - does not work on Solaris).

IMO Autodetection code is too much overhead here, given the Wine 
multi-platform support.


Providing unixfs as default and drop-down box for user override seems a 
bit more viable path.


Cheers
Hark

Re: NTFS filesystem features -> WONTFIX?

[Vit Hrachovy]

Ben Klein wrote:

But his bug raises an interesting issue. If an application has sanity
checks on FAT32 vs NTFS (e.g., I need a 4GB file ... I've detected no
NTFS therefore it's FAT32 which doesn't support more than 2GB files),
then we might just have to make this configurable, possible on a
per-app basis.

My suggestion is a drop-down box in the "Advanced" tab of "Drives" to
control filesystem type (separate from disk type, as is suggested in
Comment #7 on 17938). It shouldn't be important for floppies or even
CD-ROMs, but the options could be:
- Default (autodetect, fall-back to unixfs)
- FAT12 (floppies)
- FAT16
- FAT32
- NTFS (probably don't need different versions on NTFS)
Possibly restrict these to CDROM type:
- ISO9660
- UDF

Unless someone can come up with a better default than unixfs :)


How about having the per-application entry in registry to simulate the 
fs type for? It's in the same spirit like already implemented simulation 
of Windows version per application.


This way it won't affect 'drive' settings, but only the information 
passed to that certain application.



Hark

Re: Simple but awesome demos of Wine?

[Vit Hrachovy]

Ben Klein wrote:
> 2009/2/24 Vit Hrachovy :
>> Mmmm. According to AppDB Runescape is said to work well in Wine ;)
>> That's another layer-within-layer - Runespace is an MMORPG written in
>> JAVA/OpenGL as browser-embedded application.
> 
> Sounds like something that could work equally well natively ...

Hi Ben,
surely it works natively well. Tested on people!

The $subj tells about simple and awesome demos ... 'of complexity Wine 
can handle'.

One sample of complexity is gaming GUI automation mentioned in the 
previous posts.

Another sample of elegance could be JAVA and DotNet apps embedded in 
browser. Imagine if Wine could handle MS SharePoint 3.0 installation...

Hark

Re: Simple but awesome demos of Wine?

[Vit Hrachovy]

ACK, I like it too :)
VirtualDesktop is one workaround, second is using 'xrandr -s 0' past 
wine exit. As I have each game installed into individual WINEPREFIX, 
I've got game start scripts in ~/bin that handle WINEDEBUG=-all before 
start and 'xrandr -s 0' after exit.

Although, on Linux I usually play with Wine Virtual desktop (to be able 
to listen on ICQ and for easier app switching).

Mmmm. According to AppDB Runescape is said to work well in Wine ;) 
That's another layer-within-layer - Runespace is an MMORPG written in 
JAVA/OpenGL as browser-embedded application.
Cheers
Hark

Tom Wickline wrote:
> Hello Dan,
> Maybe run the game in a Virtual Desktop?
> Tom
> 
> On Tue, Feb 24, 2009 at 1:57 PM, Dan Kegel  > wrote:
> 
> 
> Wow.  I just tried LOTRBFME2 :-) and it's impressive.
> Only problem so far is that it doesn't restore video resolution on exit.
> Otherwise it's the coolest game of the sort I've ever seen.
> (I don't get out much :-)
> - Dan

Re: Simple but awesome demos of Wine?

[Vit Hrachovy]

Tomasz Sałaciński wrote:
> Hello,
> me too). You can try Oblivion too (does have a demo, but requires a
> decent graphics card and lots of memory). All games have a demo version,
> so you don't have to own them.

Hi Tom,
I'm too sorry to correct you, but both Morrowind and Oblivion don't 
provide playable demos. Only demo movies.

Please correct me if I'm wrong and provide me download links - I'd 
gladly mirror them.
Hark

Re: RFC: Proposed new web site design

[Vit Hrachovy]

Roderick Colenbrander wrote:
> The look of the website has improved a lot and it feels a lot more
> modern. Personally I don't like the front page much. I find it a bit
> empty. I would like to see what Wine is. I would suggest to look at
> http://www.go-mono.com the website of the Mono project. On their
> website your directly see on a banner what Mono is and a list with
> important features is shown in a column on the left. I think Wine's
> main features could be shown in a similar way. Sure you could have an
> information page but I think doing what the Mono guys did is enough
> for 90% of the people. News could be shown in a similar way. I'm not
> saying we should clone their website but personally I don't like the
> 'openoffice.org'-like design much.
> 
> Roderick

Hi Roderick,
I consider the Mono example developer-oriented page. There is too much 
irrelevant information packed on one page for usual user or tester.

As Wine is targeting broader audience than developers, I think the 
Jeremy's mockup is much more to the point.
Cheers
Hark

Re: RFC: Proposed new web site design

[Vit Hrachovy]

Hi all,
I'm really excited about the new redesign effort.
Overall the first attempt seemed more consistent.

I like the vertical alignment more.
I've got troubles to get oriented in the second attempt.

Black background of search dialog seems more consistent with the page style.

I'm absolutely happy with the top buttons:
   WineHQ, Wiki, AppDB, Bugzilla, Forums

That would make winehq my default site instead of using 3 addresses.

I'd vote for hover hints in Wiki left menu.
Cheers
Hark

Scott Ritchie wrote:
> Cesar Izurieta wrote:
>> Here's a quick relayout with some of the ideas posted in this thread:
>>
>> http://caih.org/wine/WineHQ.html
>>
>>
> 
> Ewww.  The vertical alignment is much better, and the news dragging to
> the bottom is just tacky.
> 
> Scott Ritchie

Re: Patchwatcher security improvements

[Vit Hrachovy]

Francois Gouget wrote:
> On Mon, 8 Sep 2008, Ambroz Bizjak wrote:
> 
>> Hi,
>>
>> I've abandoned my chroot aproach to improving security in patchwatcher.
>> Instead I've implemented the ability to run untrusted code as a user
>> different than the one running patchwatcher. This is because creating a
>> chroot where Wine could be compiled and tested proved to be too difficult
>> and platform-dependent.
> 
> This seems like an almost perfect task for a virtual machine:
>  * set up you virtual machine to taste
>  * take a snapshot
>  * to test a patch, fire up the virtual machine
>  * have it test the patch
>  * after the test or when it times out, revert it to the snapshot
>  * rinse (done in the step above), repeat
> 
> This could be done with VirtualBox, but maybe other alternatives based 
> on Xen or KVM or some such would be better. The main issue I see with 
> this is that the OpenGL / DirectSound tests will not run on the real 
> hardware (as usual), but maybe a Xen-like approach could help there.
> 
> It would also make it easy to test on FreeBSD / Solaris, at least if 
> based on something like VirtualBox (not sure about the Xen-like 
> approaches).

Yep. Virtualizaion has 3D shortcomings.

I can see the way how to use pbuilder/pdebuild toolchain on dedicated 
user account in Debian to automate this in pretty safe and easy way.

pbuilder uses fakeroot/chroot for this and its use is a nobrainer, 
hellish easy and effective.

But this is limited to Debian systems only.
Positive is that we still have access to 3DHW (although not 
concurrent/parallel).

Anybody has experience with User-mode Linux kernels for that?

~*~

Another environment is OpenSolaris.
There we can leverage technologie of zones & ZFS for cheap 
pseudovirtualization and fast FS recovery using FS snapshots.

~*~

IMO there is no silver bullet to bite all problems on all OS.
We can build OS-specific toolchains around patchwatcher and I think 
that's more viable alternative.

Cheers
Hark

Re: Appdb has no rc5 choice

[Vit Hrachovy]

Hi,
this is never ending story.

Can we automate adding the new release AppDB entry along with new 
release announcement?

Cheers
Vit

Leslie Viljoen wrote:
> Hi people
> 
> I am testing some games with Rc5 and wish to submit results in the
> AppDb but there is no Rc5 choice.
> 
> Les
> 
> 

Re: Can't determine disk space, install fails

[Vit Hrachovy]

Hi Pavel,
I've ran into similar issues when, for example, I've got more than 64GB 
free space on the partition, and the old Win installers just told me 
there was -1 bytes free. I'd vote for some Wine (or 3rd party tool) 
functionality that would decrease the reported bytes available per 
user's request.

As a temporary solution for such problems, I've used a small partition 
for installation with just 2GBs free and it worked for me. I've then 
moved the wineprefix into the target partition.
Regards
Vit Hrachovy

Pavel Troller wrote:
> Hi!
>   We have a long-persisting problem there. It persists for many wine versions
> and prevents some programs from installing.
>   As an example, today my son complained about impossibility to install WoW.
> The installer was not able to determine the free space on the disk (there was
> a dash instead of a number in the box) and the Continue button was greyed out,
> so it was not possible to proceed.
>   There are other cases, in which the installers say that there is not enough
> space on the disk and fail. Of course there is enough space, but the installer
> is not able to find it.
>   Especially WoW has Gold rating and these problems are not mentioned, so I
> don't think that this is a common wine problem, thus I'm not going to open
> a bug for it. I'm begging for a hint instead, what to try to find the cause
> of the problem.
>   Wine is always manually compiled and it runs on a "generic Linux system",
> not on any particular, publicly known distro.
> 
>   With regards, Pavel Troller
> 
> 

Re: WineHQ should discourage the use of cracks

[Vit Hrachovy]

Dan Kegel wrote:
>>  "Gold: Application works flawlessly with some DLL overrides or other
>>  settings, etc. Copy protection issues are not considered as issues here."
> 
> Sorry, that doesn't do it for me.  Apps that need cracks are simply
> not convenient or safe enough to merit a gold rating, IMHO.
> - Dan

O.K. So I don't agree with Your opinion.

Gold means for me the application works for me as I expect it to work.

Copy protection is for me just an obstacle to skip through - I crack all 
the legal SW I've bought, because I need comfort using the application, 
not being whipped up by stupid DRM.

My priority is SW FUNCTIONALITY.

For copy protection functionalities we shall then have separate entries 
in AppDB - as I'm interested in my app functionality, not its DRM.

I'm happy with the current AppDB state - AppDB is for users, not for 
patent holders.

Regards
Vit

Re: WineHQ should discourage the use of cracks

[Vit Hrachovy]

Dan Kegel wrote:
> I've been fighting against the notion that the
> wine project encourages cracks for some time now.
> Cracked versions of apps are bad because they are
> a) illegal (at least in the US),
> b) disrespectful of the author of the app, and
> c) much more likely to be infected with malware.
> 
> One place we still do it is in our appdb ratings definitions;
> http://appdb.winehq.org//help/?sTopic=maintainer_ratings
> which say
> "Gold: Application works flawlessly with some DLL overrides or other
> settings, crack etc. "
> 
> I propose that we change the appdb ratings definitions
> so that an app that only works with a crack gets no higher
> than bronze.
> 
> Any objections?
> - Dan

Hi Dan,

in fact a DLL override may be another form of 'crack' - given the 
situation I'm not owner of a Windows copy and need to override MS DLL 
which is not free to use without Windows license.

I think we should not mix up the functionality ratings with legality 
ratings. I consider this a politicspeak, not techspeak.

Given the problem above - we can solve it by rewording in a similar 
spirit but leaving the bad word out:

"Gold: Application works flawlessly with some DLL overrides or other
settings, etc. Copy protection issues are not considered as issues here."

Regards
Vit

Re: AppDB: cannot submit a screenshot even when logged in

[Vit Hrachovy]

Hi Alexander,
it suddenly started working - I blame wrong cache or TTL :-(
It was strange, because I could Delete the image, but couldn't post.
Anyhow, please forget the issue.
Thanks and regards
Vit

Alexander Nicolaysen Sørnes wrote:
> Do you have cookies enabled?  I have looked at the code and I cannot see a 
> reason why you should see that message if you are logged in.  If it still 
> does not work, please post the URL of the page which shows the error.
> 
> 
> Alexander N. Sørnes

AppDB: cannot submit a screenshot even when logged in

[Vit Hrachovy]

Hello everybody,
I may missed something, but I cannot submit a screenshot to the 
application I maintain in AppDB and I'm logged in.

There's always a nasty 'Log in to submit screenshots' instead of Submit 
button.

Is it planned downtime?
Regards
Vit

P.S. It's http://appdb.winehq.org/screenshots.php?iAppId=4025

Re: DirectDraw opengl renderer

[Vit Hrachovy]

Grand news, and thanks a lot for pointing this out - Zork: Nemesis and 
Zork: Grand Inquisitor are now finally playable using these two options 
opengl/readdraw. There is a small glitch with screen redrawing, but hey 
- it works after YEARS!

Regards
Vit

Roderick Colenbrander wrote:
> If you are interested in using DirectDrawRenderer=opengl also make sure to 
> play with the RenderTargetLockMode (default=readdraw). In case of Tiberian 
> Sun 'readtex' is a lot faster.
> 
> Regards,
> Roderick

Re: A script for automatic regression testing

[Vit Hrachovy]

Hi Mikolaj,
see winebot - a console Wine package tool for Windows programs for how 
to automate AutoHotkey installation for given wineprefix.


http://winebot.sandbox.cz

Regards
Vit

Mikolaj Zalewski wrote:
 I wrote a small script that automates regression testing. It requires 
an Autohotkey script that tests the program and creates a file 
C:\Test-failed.txt if the test failed. The bash script will then do the 
regression testing. It starts with copying the source tree and 
wineprefix so it should be possible to do some normal work during 
compilations.
At the beginning of the script there are some variables that needs to be 
configured before running it. The wineprefix has to have Autohotkey 
installed and associated with *.ahk. The attached script's settings will 
find the regression for bug #9249.

If anyone is interested in it I'd be interested in some feedback.

Mikołaj Zalewski

Re: Direct3D Game test framework

[Vit Hrachovy]

On Tue, Jun 26, 2007 at 01:06:02PM +0200, Stefan Dösinger wrote:
> > I second Vit's recommendation.  We're using Autohotkey
> > scripts in our test framework
> >   http://code.google.com/p/yawt/
> > and I've been meaning to work with Vit to get his scripts
> > incorporated into our framework.
> Appart of controlling the apps we'll need some programs to start the 
> application scripts, extract the results and do something with them. That 
> could be some bash or perl scripts.
> 
> We also need some database to collect the results. This could be something 
> webserver based with some simple SQL database, or just another set of perl 
> scripts on a server. Here I'd like to look how much cxtest infrastructure we 
> can reuse. Any volunteers for writing such a thing?

Since yawt may be used as a part of cxtest framework, how about that,
Dan? It may be less work to set up the cxtest pool than to create a new
testing framework.

If cxtest shows some great architectural weaknesses, Vincent Povirk and
me can do the necessary infrastructure tailored to Direct3D specific
needs.

Webserver & PHP for frontend, perl/bash/SQL for backend.

We shall discuss the requirements in more exact manner.

1. Define demo packages
2. Define testing environment configurations
3. Define tracked results data items (SQL db architecture)

The resulting infrastructure shall be human independent in following terms:
human will 
prepare a test 'package' (one application)
prepare test units (individual tests)
machine will 
run the test units per package
interpret the results if possible
store the results and run logs (with screenshots)

This will allow for automated test runs at given time.
AFAIK cxtest passes all defined requirements above.

I'll try to play with cxtest and report back, preferably with some
testing setup.

Regards
Vit

Re: Direct3D Game test framework

[Vit Hrachovy]

On Mon, Jun 25, 2007 at 03:40:42PM +0200, Stefan Dösinger wrote:
> Hi,
> Now that we're facing Direct3D 9 feature completion soon - VTF support coming 
> in from Henri, High order patches and thread safety from me - the d3d work 
> will change a bit soon. Instead of adding new features we'll debug games and 
> improve performance. It would be good if we had some automated testing 
> framework to support the process :-)
> 
> Unfortunately this isn't easy. Games do not render exactly, so verifying that 
> a game doesn't show any visual regressions automatically may be more effort 
> than reward. Here I think we'll have to rely on users testing the games 
> regularly and testing regressions.
> 
> cxtest comes to my mind(www.cxtest.org). It is a test suit built by 
> codeweavers for running regression tests on Windows apps. It can remote 
> control applications using keyboard input and compares screenshots to 
> reference ones. It could be used to start benchmarks automatically. A plus 
> here is that some machines run nightly tests. However, those are VMs, so no 
> 3D acceleration. A problem is also reading back the results. Does anyone know 
> some applications for doing that? Windows or Linux apps, commercial or open 
> source ones(prefered, though).
> 
> Other suggestions?

cxtest has already impressive infratructure (installation, creation of
clean environment) and nice scripting. However, it requires Metacity WM
and VNC.

I'm personally using AutoHotkey(http://www.autohotkey.com) as an
automatic testing framework backend. It's a Windows application, so it 
can be run through Wine itself and it's sandboxed from X11. 

I can imagine Winebot packages to be easily converted to an automatic
testing engine. Winebot actually covers automated installation and
creation of clean independent environment.

Running applications with different log levels, tracing output,
comparing screenshots with different levels of fuzzy comparaion 
- it's not faraway.

AFAIK cxtest has the better functionality now.

Regards
Vit

Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab

[Vit Hrachovy]

On Wed, May 16, 2007 at 06:41:33PM +0200, Frank Richter wrote:
> > just add all
> > "preset" memory sizes, and WM_SETTEXT the value read from the registry.
> 
> Might be code-wise a bit simpler than your GETCURSEL approach, but
> otherswise not much different I think.
> 
> -f.r.

Hi Frank,
I've simplified the code according Your review, see the attached patch.
Thanks for help.
Vit
diff --git a/programs/winecfg/Bg.rc b/programs/winecfg/Bg.rc
index 302bec5..a2580a3 100644
--- a/programs/winecfg/Bg.rc
+++ b/programs/winecfg/Bg.rc
@@ -90,6 +90,8 @@ BEGIN
 COMBOBOX   IDC_D3D_VSHADER_MODE,115,218,125,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Đŕçđĺřč Pixel Shader (ŕęî ńĺ ďîääúđćŕ îň 
őŕđäóĺđŕ)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,237,230,10
+LTEXT   "Video Memory Size (in 
megabytes):",IDC_STATIC,15,232,120,12
+COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,130,232,40,112,CBS_DROPDOWN | 
WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/Cs.rc b/programs/winecfg/Cs.rc
index 5bba698..07ba100 100644
--- a/programs/winecfg/Cs.rc
+++ b/programs/winecfg/Cs.rc
@@ -88,6 +88,8 @@ BEGIN
 COMBOBOX   IDC_D3D_VSHADER_MODE,105,197,140,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Povolit stínování pixelů (spoléhá se na hardware 
podporu)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,216,230,10
+LTEXT   "Velikost videopaměti (v 
megabytech):",IDC_STATIC,15,232,140,12
+COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,145,232,40,112,CBS_DROPDOWN | 
WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
@@ -244,8 +246,8 @@ END
 
 STRINGTABLE DISCARDABLE
 BEGIN
-IDS_SHADER_MODE_HARDWARE"Hardwarový"
-IDS_SHADER_MODE_NONE"Žádný"
+IDS_SHADER_MODE_HARDWARE"Podporováno zařízením"
+IDS_SHADER_MODE_NONE"Žádná"
 END
 
 STRINGTABLE DISCARDABLE
diff --git a/programs/winecfg/De.rc b/programs/winecfg/De.rc
index 8c77b2b..9741a48 100644
--- a/programs/winecfg/De.rc
+++ b/programs/winecfg/De.rc
@@ -84,6 +84,8 @@ BEGIN
 COMBOBOXIDC_D3D_VSHADER_MODE,140,197,105,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Pixel Shader aktivieren (wenn von Hardware unterstützt)", 
IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | WS_TABSTOP,15,212,230,10
+LTEXT   "Größe des Grafikspeichers(in 
Megabytes)",IDC_STATIC,15,232,140,12
+COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,150,232,40,112,CBS_DROPDOWN | 
WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/En.rc b/programs/winecfg/En.rc
index 02d4850..218150a 100644
--- a/programs/winecfg/En.rc
+++ b/programs/winecfg/En.rc
@@ -79,12 +79,14 @@ BEGIN
 EDITTEXTIDC_DESKTOP_WIDTH,64,167,40,12,ES_AUTOHSCROLL | ES_NUMBER 
| WS_DISABLED
 EDITTEXTIDC_DESKTOP_HEIGHT,117,167,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 
-GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,50
+GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,60
 
 LTEXT  "Vertex Shader Support: ",IDC_STATIC,15,199,80,30
 COMBOBOX   IDC_D3D_VSHADER_MODE,100,197,145,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Allow Pixel Shader (if supported by 
hardware)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,216,230,10
+LTEXT   "Video Memory Size (in 
megabytes):",IDC_STATIC,15,232,120,12
+COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,130,232,40,112,CBS_DROPDOWN | 
WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/Es.rc b/programs/winecfg/Es.rc
index 2430b02..d7dea8b 100644
--- a/programs/winecfg/Es.rc
+++ b/programs/winecfg/Es.rc
@@ -83,6 +83,8 @@ BEGIN
 COMBOBOXIDC_D3D_VSHADER_MODE,100,197,145,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Permitir Pixel Shader (si hay soporte por 
hardware)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,216,230,10
+LTEXT   "Video Memory Size (in 
megabytes):",IDC_STATIC,15,232,120,12
+COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,130,232,40,112,CBS_DROPDOWN | 
WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/Fi.rc b/programs/winecfg/Fi.rc
index 16da0ca..f8f8180 100644
--- a/programs/winecfg/Fi.rc
+++ b/programs/winecfg/Fi.rc
@@ -84,6 +84,8 @@ BEGIN
 COMBOBOX   IDC_D3D_VSHADER_MODE,100,218,150,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Salli &Pixel Shader:n käyttö laitteiston 
tukiessa",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,237,230,10
+LTEXT   "Video Memory Size (in 
megabytes):",IDC_STATIC,15,232,120,12
+COMBOBOXIDC_VIDE

Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab

[Vit Hrachovy]

On Wed, May 16, 2007 at 03:18:22PM +0200, Laurent Vromman wrote:
>   case CBN_SELCHANGE: {
>   SendMessage(GetParent(hDlg), PSM_CHANGED, 0, 0);
>   switch (LOWORD(wParam)) {
> - case IDC_D3D_VSHADER_MODE: 
> on_d3d_vshader_mode_changed(hDlg); break;
> - }
> +case IDC_D3D_VSHADER_MODE: 
> on_d3d_vshader_mode_changed(hDlg); break;
> +case IDC_VIDEOMEMORY_SIZE_COMBO: 
> set_from_videomemory_size_changed(hDlg); break;
> +}
> 
> I believe you should align your indentation method on the one the file 
> already uses (ie tabs, not spaces).
> 
> +// vim:sw=4:expandtab
> 
> This has nothing to do with wine
> 
> Laurent

Hi Laurent
citing from: http://www.winehq.org/site/docs/winedev-guide/style-notes
"Tabs are not forbidden but discouraged. A tab is defined as 8
characters and the usual amount of indentation is 4 characters." 

and from: http://www.winehq.org/site/sending_patches
"Don't mix tabs and spaces because it makes the diff output
unreadable, use consistent indentation."

The actual file contents breaks both citations above, my code doesn't
conflict with any one of them.

For vim footer, I agree it shall not be present. If the only comment
regards formatting, I'm happy and I can fix the formatting as You wish.

Cheers
Vit

review: add Video Memory text input to winecfg Graphics/Direct3D tab

[Vit Hrachovy]

Hi,
the attached patch adds new editable combobox input 'Video Memory size'
for Graphics/Direct3D tab of winecfg. 

I've tried to implement Frank's comments to English language only.
Please consider this patch as a proposal, so if it gets positive review,
I'll propagate the changes to all remaining language resources.

May I kindly ask someone for the patch review?
Regards
Vit
diff --git a/programs/winecfg/En.rc b/programs/winecfg/En.rc
index 02d4850..218150a 100644
--- a/programs/winecfg/En.rc
+++ b/programs/winecfg/En.rc
@@ -79,12 +79,14 @@ BEGIN
 EDITTEXTIDC_DESKTOP_WIDTH,64,167,40,12,ES_AUTOHSCROLL | ES_NUMBER 
| WS_DISABLED
 EDITTEXTIDC_DESKTOP_HEIGHT,117,167,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 
-GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,50
+GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,60
 
 LTEXT  "Vertex Shader Support: ",IDC_STATIC,15,199,80,30
 COMBOBOX   IDC_D3D_VSHADER_MODE,100,197,145,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Allow Pixel Shader (if supported by 
hardware)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,216,230,10
+LTEXT   "Video Memory Size (in 
megabytes):",IDC_STATIC,15,232,120,12
+COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,130,232,40,112,CBS_DROPDOWN | 
WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/resource.h b/programs/winecfg/resource.h
index 811a115..cabe783 100644
--- a/programs/winecfg/resource.h
+++ b/programs/winecfg/resource.h
@@ -65,6 +65,7 @@
 #define IDC_DESKTOP_BY  1026
 #define IDC_XDGA1027
 #define IDC_XSHM1028
+#define IDC_VIDEOMEMORY_SIZE_COMBO  1081
 
 /* dll editing  */
 #define IDC_RAD_BUILTIN 1029
diff --git a/programs/winecfg/x11drvdlg.c b/programs/winecfg/x11drvdlg.c
index 8fa183e..48e291a 100644
--- a/programs/winecfg/x11drvdlg.c
+++ b/programs/winecfg/x11drvdlg.c
@@ -36,7 +36,10 @@
 WINE_DEFAULT_DEBUG_CHANNEL(winecfg);
 
 #define RES_MAXLEN 5 /* the maximum number of characters in a screen 
dimension. 5 digits should be plenty, what kind of crazy person runs their 
screen >10,000 pixels across? */
+#define VIDEOMEM_MAXLEN 5 /* the maximum number of characters in a video 
memory input box */
+#define VIDEOMEM_SIZES_LENGTH 6 /* array length */
 
+const char * builtin_videomem_sizes[] = { "", "32", "64", "128", "256", "512" 
};
 
 static struct SHADERMODE
 {
@@ -72,7 +75,7 @@ static void update_gui_for_desktop_mode(HWND dialog) {
 if (reg_key_exists(config_key, keypath("X11 Driver"), "Desktop"))
 {
 char* buf, *bufindex;
-   CheckDlgButton(dialog, IDC_ENABLE_DESKTOP, BST_CHECKED);
+CheckDlgButton(dialog, IDC_ENABLE_DESKTOP, BST_CHECKED);
 
 buf = get_reg_key(config_key, keypath("X11 Driver"), "Desktop", 
"640x480");
 /* note: this test must match the one in x11drv */
@@ -114,6 +117,41 @@ static void update_gui_for_desktop_mode(HWND dialog) {
 updating_ui = FALSE;
 }
 
+static void update_gui_for_videomem_size(HWND dialog) {
+char* buf;
+int i;
+int matched_index   = 0;
+int found_in_defaults   = -1;
+char const * const backup_first = builtin_videomem_sizes[0];
+
+SendDlgItemMessage(dialog, IDC_VIDEOMEMORY_SIZE_COMBO, CB_RESETCONTENT, 0, 
0);
+SendDlgItemMessage(dialog, IDC_VIDEOMEMORY_SIZE_COMBO, EM_LIMITTEXT, 
VIDEOMEM_MAXLEN, 0);
+
+buf = get_reg_key(config_key, keypath("Direct3D"), "VideoMemorySize", 
"64");
+
+for (i = 0; i < VIDEOMEM_SIZES_LENGTH ; i++) {
+if (strcmp(buf, builtin_videomem_sizes[i]) == 0) {
+found_in_defaults = 1;
+matched_index = i; 
+break ;
+}
+}
+if (found_in_defaults == -1) 
+builtin_videomem_sizes[0] = buf;
+
+for (i = 0; i < VIDEOMEM_SIZES_LENGTH; i++)
+SendDlgItemMessageA(dialog, IDC_VIDEOMEMORY_SIZE_COMBO, CB_ADDSTRING, 
i, (LPARAM) builtin_videomem_sizes[i]);
+
+SendDlgItemMessage(dialog, IDC_VIDEOMEMORY_SIZE_COMBO, CB_SETCURSEL, 
matched_index, 0);
+
+builtin_videomem_sizes[0] = backup_first; 
+
+enable(IDC_VIDEOMEMORY_SIZE_COMBO);
+HeapFree(GetProcessHeap(), 0, buf);
+
+updating_ui = FALSE;
+}
+
 static void init_dialog(HWND dialog)
 {
 unsigned int it;
@@ -164,6 +202,7 @@ static void init_dialog(HWND dialog)
   CheckDlgButton(dialog, IDC_D3D_PSHADER_MODE, BST_UNCHECKED);
 HeapFree(GetProcessHeap(), 0, buf);
 
+update_gui_for_videomem_size(dialog);
 updating_ui = FALSE;
 }
 
@@ -208,6 +247,36 @@ static void on_enable_desktop_clicked(HWND dialog) {
 update_gui_for_desktop_mode(dialog);
 }
 
+static void set_from_videomemory_size_edits(HWND dialog) {
+char buffer[1024];
+
+SendDlgItemMessage(dialog, IDC_VIDEOMEMORY_SIZE_COMBO, WM_GETTEXT, 
sizeof(buffer), (LPARAM) buffer);
+
+if (strlen(buffer))
+

Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab

[Vit Hrachovy]

On Fri, Apr 27, 2007 at 12:14:47PM +0200, Stefan Dösinger wrote:
> On a quick look I see a number of whitespace issues in the patch. in the .rc 
> files you are using tabs while the rest of the code uses spaces at some 
> places, in other lines you're using spaces yourself. In the code you add some 
> trailing whitespace(Git warns about that in rebase and git-am
> 
> As for the German translation you could use "Größe des Grafikspeichers(in 
> Megabytes)"


Hi Stefan, 
thanks for comments, I'm including the fixed patch with added German
translation.
Thanks
Vit

diff --git a/programs/winecfg/Bg.rc b/programs/winecfg/Bg.rc
index 302bec5..a3d9860 100644
--- a/programs/winecfg/Bg.rc
+++ b/programs/winecfg/Bg.rc
@@ -84,12 +84,14 @@ BEGIN
 EDITTEXTIDC_DESKTOP_WIDTH,64,188,40,12,ES_AUTOHSCROLL | ES_NUMBER 
| WS_DISABLED
 EDITTEXTIDC_DESKTOP_HEIGHT,117,188,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 
-GROUPBOX" Direct3D ",IDC_STATIC,8,210,244,50
+GROUPBOX" Direct3D ",IDC_STATIC,8,210,244,60
 
 LTEXT  "Ďîääđúćęŕ íŕ Vertex Shader: ",IDC_STATIC,15,220,105,30
 COMBOBOX   IDC_D3D_VSHADER_MODE,115,218,125,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Đŕçđĺřč Pixel Shader (ŕęî ńĺ ďîääúđćŕ îň 
őŕđäóĺđŕ)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,237,230,10
+LTEXT   "Video Memory Size (in 
megabytes):",IDC_STATIC,15,232,120,12
+EDITTEXTIDC_VIDEOMEMORY_SIZE,130,232,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/Cs.rc b/programs/winecfg/Cs.rc
index 5bba698..6a91d54 100644
--- a/programs/winecfg/Cs.rc
+++ b/programs/winecfg/Cs.rc
@@ -88,6 +88,8 @@ BEGIN
 COMBOBOX   IDC_D3D_VSHADER_MODE,105,197,140,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Povolit stínování pixelů (spoléhá se na hardware 
podporu)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,216,230,10
+LTEXT   "Velikost videopaměti (v 
megabytech):",IDC_STATIC,15,232,120,12
+EDITTEXTIDC_VIDEOMEMORY_SIZE,135,232,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/De.rc b/programs/winecfg/De.rc
index 8c77b2b..cc6d43b 100644
--- a/programs/winecfg/De.rc
+++ b/programs/winecfg/De.rc
@@ -78,12 +78,14 @@ BEGIN
 LTEXT   "X",IDC_DESKTOP_BY,114,167,8,8,WS_DISABLED
 EDITTEXTIDC_DESKTOP_HEIGHT,123,167,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 
-GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,38
+GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,60
 
 LTEXT   "Unterstützung für Vertex Shader: ",IDC_STATIC,15,199,120,8
 COMBOBOXIDC_D3D_VSHADER_MODE,140,197,105,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Pixel Shader aktivieren (wenn von Hardware unterstützt)", 
IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | WS_TABSTOP,15,212,230,10
+LTEXT   "Größe des Grafikspeichers (in 
Megabytes):",IDC_STATIC,15,232,135,12
+EDITTEXTIDC_VIDEOMEMORY_SIZE,150,232,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/En.rc b/programs/winecfg/En.rc
index 02d4850..84e77d9 100644
--- a/programs/winecfg/En.rc
+++ b/programs/winecfg/En.rc
@@ -79,12 +79,14 @@ BEGIN
 EDITTEXTIDC_DESKTOP_WIDTH,64,167,40,12,ES_AUTOHSCROLL | ES_NUMBER 
| WS_DISABLED
 EDITTEXTIDC_DESKTOP_HEIGHT,117,167,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 
-GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,50
+GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,60
 
 LTEXT  "Vertex Shader Support: ",IDC_STATIC,15,199,80,30
 COMBOBOX   IDC_D3D_VSHADER_MODE,100,197,145,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Allow Pixel Shader (if supported by 
hardware)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,216,230,10
+LTEXT   "Video Memory Size (in 
megabytes):",IDC_STATIC,15,232,120,12
+EDITTEXTIDC_VIDEOMEMORY_SIZE,130,232,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/Es.rc b/programs/winecfg/Es.rc
index 34993c2..b4a 100644
--- a/programs/winecfg/Es.rc
+++ b/programs/winecfg/Es.rc
@@ -78,12 +78,14 @@ BEGIN
 EDITTEXTIDC_DESKTOP_WIDTH,64,188,40,12,ES_AUTOHSCROLL | ES_NUMBER 
| WS_DISABLED
 EDITTEXTIDC_DESKTOP_HEIGHT,117,188,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 
-GROUPBOX" Direct3D ",IDC_STATIC,8,210,244,50
+GROUPBOX" Direct3D ",IDC_STATIC,8,210,244,60
 
 LTEXT   "Soporte Vertex Shader: ",IDC_STATIC,15,220,80,30
 COMBOBOXIDC_D3D_VSHADER_MODE,100,218,150,70,CBS_DROPDOWNLIST | 

review: add Video Memory text input to winecfg Graphics/Direct3D tab

[Vit Hrachovy]

Hi,
the attached patch adds new textbox input 'Video Memory size' for
Graphics/Direct3D tab of winecfg. Updated every live locale resource to
include this.

Adding this option was discussed on thread 'More Direct3D settings in
winecfg (was: Enabling GLSL in winecfg)' at wine-devel.

changelog entry: Add Video Memory textbox to Graphics/direct3D part of
winecfg

May I kindly ask someone for the patch review?

Regards
Vit Hrachovy
diff --git a/programs/winecfg/Bg.rc b/programs/winecfg/Bg.rc
index 302bec5..8cdf341 100644
--- a/programs/winecfg/Bg.rc
+++ b/programs/winecfg/Bg.rc
@@ -84,12 +84,14 @@ BEGIN
 EDITTEXTIDC_DESKTOP_WIDTH,64,188,40,12,ES_AUTOHSCROLL | ES_NUMBER 
| WS_DISABLED
 EDITTEXTIDC_DESKTOP_HEIGHT,117,188,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 
-GROUPBOX" Direct3D ",IDC_STATIC,8,210,244,50
+GROUPBOX" Direct3D ",IDC_STATIC,8,210,244,60
 
 LTEXT  "Ďîääđúćęŕ íŕ Vertex Shader: ",IDC_STATIC,15,220,105,30
 COMBOBOX   IDC_D3D_VSHADER_MODE,115,218,125,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Đŕçđĺřč Pixel Shader (ŕęî ńĺ ďîääúđćŕ îň 
őŕđäóĺđŕ)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,237,230,10
+   LTEXT   "Video Memory Size (in 
megabytes):",IDC_STATIC,15,232,120,12
+EDITTEXTIDC_VIDEOMEMORY_SIZE,130,232,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/Cs.rc b/programs/winecfg/Cs.rc
index 5bba698..4c82063 100644
--- a/programs/winecfg/Cs.rc
+++ b/programs/winecfg/Cs.rc
@@ -88,6 +88,8 @@ BEGIN
 COMBOBOX   IDC_D3D_VSHADER_MODE,105,197,140,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Povolit stínování pixelů (spoléhá se na hardware 
podporu)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,216,230,10
+   LTEXT   "Velikost videopaměti (v 
megabytech):",IDC_STATIC,15,232,120,12
+EDITTEXTIDC_VIDEOMEMORY_SIZE,135,232,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/De.rc b/programs/winecfg/De.rc
index 8c77b2b..8c8f78e 100644
--- a/programs/winecfg/De.rc
+++ b/programs/winecfg/De.rc
@@ -78,12 +78,14 @@ BEGIN
 LTEXT   "X",IDC_DESKTOP_BY,114,167,8,8,WS_DISABLED
 EDITTEXTIDC_DESKTOP_HEIGHT,123,167,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 
-GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,38
+GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,60
 
 LTEXT   "Unterstützung für Vertex Shader: ",IDC_STATIC,15,199,120,8
 COMBOBOXIDC_D3D_VSHADER_MODE,140,197,105,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Pixel Shader aktivieren (wenn von Hardware unterstützt)", 
IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | WS_TABSTOP,15,212,230,10
+   LTEXT   "Video Memory Size (in 
megabytes):",IDC_STATIC,15,232,120,12
+EDITTEXTIDC_VIDEOMEMORY_SIZE,130,232,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/En.rc b/programs/winecfg/En.rc
index 02d4850..eec9e11 100644
--- a/programs/winecfg/En.rc
+++ b/programs/winecfg/En.rc
@@ -79,12 +79,14 @@ BEGIN
 EDITTEXTIDC_DESKTOP_WIDTH,64,167,40,12,ES_AUTOHSCROLL | ES_NUMBER 
| WS_DISABLED
 EDITTEXTIDC_DESKTOP_HEIGHT,117,167,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 
-GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,50
+GROUPBOX" Direct3D ",IDC_STATIC,8,189,244,60
 
 LTEXT  "Vertex Shader Support: ",IDC_STATIC,15,199,80,30
 COMBOBOX   IDC_D3D_VSHADER_MODE,100,197,145,70,CBS_DROPDOWNLIST | 
WS_VSCROLL | WS_TABSTOP
 
 CONTROL "Allow Pixel Shader (if supported by 
hardware)",IDC_D3D_PSHADER_MODE,"Button",BS_AUTOCHECKBOX | 
WS_TABSTOP,15,216,230,10
+   LTEXT   "Video Memory Size (in 
megabytes):",IDC_STATIC,15,232,120,12
+EDITTEXTIDC_VIDEOMEMORY_SIZE,130,232,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 END
 
 IDD_DLLCFG DIALOG DISCARDABLE  0, 0, 260, 250
diff --git a/programs/winecfg/Es.rc b/programs/winecfg/Es.rc
index 34993c2..6fb8293 100644
--- a/programs/winecfg/Es.rc
+++ b/programs/winecfg/Es.rc
@@ -78,12 +78,14 @@ BEGIN
 EDITTEXTIDC_DESKTOP_WIDTH,64,188,40,12,ES_AUTOHSCROLL | ES_NUMBER 
| WS_DISABLED
 EDITTEXTIDC_DESKTOP_HEIGHT,117,188,40,12,ES_AUTOHSCROLL | 
ES_NUMBER | WS_DISABLED
 
-GROUPBOX" Direct3D ",IDC_STATIC,8,210,244,50
+GROUPBOX" Direct3D ",IDC

Re: WineD3D patch test needed

[Vit Hrachovy]

Hi Stefan,
I've tested the patch using Oblivion and it seems there are no stability 
or rendering issues.

Regards
Vit

Stefan Dösinger wrote:

Hi,
I have a patch which fixes the performance problems introduced with 
c0782603d09807c6ca506948bb4a814a73430184 . I am sure that the patch is 
correct, but I have the bad feeling that it brings up a few other bugs, so I 
send it to wine-devel for testing first.


It only reallocates surfaces when they are either new or the description was 
changed.


Thanks,
Stefan

Re: FAQ moved to Wiki

[Vit Hrachovy]

On Mon, Apr 16, 2007 at 12:00:50AM -0700, Scott Ritchie wrote:
> On Sun, 2007-04-15 at 21:33 -0400, Dimi Paun wrote:
> > On Sun, 2007-04-15 at 15:52 -0700, Scott Ritchie wrote:
> > > I've pasted the content from the FAQ onto the wiki here:
> > > http://wiki.winehq.org/FAQ

Hi Scott,
Wiki is really a good idea. In the past I've been an opposer of Wiki
engines, but nowadays I'm convinced of its usability.

It should be also worhty to make nightly/monthly Wiki dumps to
Wine versioning system to be able to distribute the documentation
offline, for Wine users without net access.

As modern Wiki engines support PDF and TXT page dumps, the only
discussion IMO is how to automate wiki dumps to PDF/TXT/HTML and how to
sync regularly with GIT/CVS repository. Sync should be also made before
each Wine release.

Thanks
Vit Hrachovy

Re: Removal of unused audio drivers

[Vit Hrachovy]

On Thu, Apr 12, 2007 at 01:54:17PM +0200, Marcus Meissner wrote:
> On Thu, Apr 12, 2007 at 01:01:43PM +0200, Vit Hrachovy wrote:
> > I'm using esd actively. There are some audiocard drivers OSS provide and 
> > ALSA don't.
> > 
> > I haven't used NAS at all and the winecfg delay annoys me too.
> > Regards
> > Vit
> 
> What has esound (esd) to do with OSS?
> 
> Ciao, Marcus

AFAIK OSS doesn't provide SW mixing. ESD does. 

Given situation I have OSS-only capable audiocard and I want to use SW
mixing, ESD over OSS is an option for me to hear mixed audio streams
from several applications (mp3 as background and sounds from a game,
from example).

Correct me if I'm wrong :)

Regards
Vit

Re: Removal of unused audio drivers

[Vit Hrachovy]

Maarten Lankhorst wrote:

There are 5 different audio drivers for linux, I think this is a bit
overkill, so I propose to remove the esd and nas drivers, I don't think
anyone uses esd, especially that since for that task alsa can be used
now since dmix addon.

I'm not sure what nas is for, but it seems to be 'network audio system',
I haven't seen any use for it, except that it causes a 30 seconds
slowdown at showing 'audio' tab in winecfg. I don't think anyone uses it.

For esd I think it's best to remove, for nas I'm also for remove, but
I'll settle for removing it from winecfg list same way as winearts was
disabled for a while.

What are your thoughts about this?

Maarten


Hi Maarten,
I'm using esd actively. There are some audiocard drivers OSS provide and 
ALSA don't.


I haven't used NAS at all and the winecfg delay annoys me too.
Regards
Vit


This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

Re: More Direct3D settings in winecfg (was: Enabling GLSL in winecfg)

[Vit Hrachovy]

Hi all,
thanks for a quick survey :-)

I've got patch for adding VideoMemSize textbox prepared, I'll send it
when winecfg Cs.rc patch is accepted as it [partly] depends on the 
changes made in Cs.rc [adding Direct3D groupbox].

Regards
Vit

More Direct3D settings in winecfg (was: Enabling GLSL in winecfg)

[Vit Hrachovy]

Hi,

according to Stefan, Direct X options regarding 
 * Available Video Memory
 * Enable GLSL
will be useful in winecfg / Graphics section.

However there is still missing consensus to how and whether to
implement user accessible way to enable/disable GLSL in winecfg.
Ray Jones, Stefan and me would like this in winecfg. 

Please share Your opinion.

According to the discussion results, I'm going to add either only
Available Video Memory text input box, or both Memory and GLSL toggle
checkbox to winecfg.


Summary of previous discussion follows:

Available Video Memory (text input box)
--
User will input here the RAM size of his graphic card. According to
Stefan: "There are vendor dependent ways to read it, but implementing
them is pretty nasty(requires some private to winex11.drv). Altough we
had that discussion a number of times already and we only agreed on a
registry key so far."

Enable GLSL  (checkbox)
---
GLSL should be made default in 1.0. However, according to Stefan: "some
drivers(*cough* macos *cough*) have serious problems with glsl". Until
there is a specification in 1.0 requirements that these issues have to
be resolved prior 1.0, this checkbox would be useful even past 1.0.

Stefan Dosinger with H. Verbeet pointed out that this option should be
in Vertex Shader dropdown box, but after inspecting code, I've found
wouldn't blend well with the rest of Vertex Shader idea. This is due to
GLSL registry key differs from Vertex Shader registry key. Should they
be merged into one? Ivan Gyurdiev pointed out that GLSL can be both
enabled for hardware vertex shader and software vertex shader, so the
idea of merging GLSL with Vertex Shader dropdown box would result in two
menu options - 'GLSL with HW support' and 'GLSL with SW support'.

Another stance is to make GLSL enabled by default in next Wine versions.

Offscreen Rendering (dropdown box)
---
Default option will be 'fbo', optional is backbuffer. Stefan doesn't
consider it worthy adding to winecfg.


Regards
Vit

Re: Allow enabling/disabling Direct3D usage of GLSL in Winecfg + update Czech locales for Winecfg

[Vit Hrachovy]

Hi Stephan,
GLSL depends on Czech localization update.
Should I split them into two separate patches with different numbers?
Should I send them split in two different requests?
Regards
Vit

Stefan Dösinger wrote:

changelog entry: Allow enabling/disabling Direct3D usage of GLSL in winecfg
changelog entry: Update Czech localization for winecfg
The changelog suggests that you have 2 different changesets in one path. If 
they do not depend on each other, please send them in seperate patches(and 
mails)

Re: Localization resources

[Vit Hrachovy]

On Wed, Mar 28, 2007 at 11:59:45AM +0400, Kirill K. Smirnov wrote:
> Hi,
> 
> Similar question has been discussed before:
> 
> http://www.winehq.org/pipermail/wine-devel/2006-November/052140.html
> http://www.winehq.org/pipermail/wine-devel/2006-November/052142.html
> http://www.winehq.org/pipermail/wine-devel/2006-November/052143.html
> 
> >You only need to add an English resource; the other language files are made 
> by 
> >whoever translates the English strings into their language.
> 
> The better way is to add string untranslated into every resource, otherwise 
> it 
> will not be loaded.
> 
> More info at 
> http://www.winehq.org/pipermail/wine-devel/2006-November/052135.html
> --
> Kirill
Hi Kirill,
what about updating the Developer Guide:
http://winehq.org/site/docs/winedev-guide/adding-languages

It will save precious time during several review rounds.
Regards
Vit

Re: Winebot

[Vit Hrachovy]

Dan Kegel wrote:

Vit wrote:

I'll write the manifest (a),(c) and post it onto Winebot Wiki.


Cool... where is that?


http://winebot.sandbox.cz/tracker/wiki/WinebotManifest

Feel free to comment, propose enhancements.

Regards
Vit

Re: Winebot

[Vit Hrachovy]

Remco wrote:

Will winebot be a win32 app or a linux app? Making it a win32 app and
developing it on Windows would probably reveal more Wine bugs.


Hi Remco,
Winebot is a PERL/Linux code which calls BASH or AutoHotKey scripts. 
AutoHotkey is a Windows application, so I can safely say, that Winebot 
(using AutoHotkey) is both Linux and Windows application.

Regards
Vit

Winebot

[Vit Hrachovy]

ted 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

Re: Allow enabling/disabling Direct3D usage of GLSL in Winecfg

[Vit Hrachovy]

H. Verbeet wrote:

On 22/03/07, Vit Hrachovy <[EMAIL PROTECTED]> 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.




Hi,
I've inspected Cs.rc and other .rc files and I've found that lots of 
them differ greatly from En.rc. Am I missing some process of notifying 
translators that En.rc has been changed?


En.rc seems most up to date, so I've updated this as a reference one for 
translators.


http://winehq.org/site/docs/winedev-guide/adding-languages
states that translators should use En.rc for reference implementation.

It looks like winecfg has a different interface for different languages 
due to this nature of locales implementation.


I understand Your point, but as the .rc files varies so much, I'm not 
sure whether I'll break something if I modify the languages I'm not 
speaking.


I can sync Cs.rc with actual En.rc, if it's enough to address your advice.

Regards
Vit


This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

Re: Road to 1.0

[Vit Hrachovy]

On Tue, Mar 20, 2007 at 03:32:14PM -0700, Dan Kegel wrote:
> >Given list of manual steps required to install Oblivion
> >http://www.uesp.net/wiki/Oblivion:Linux
> >this can be automated easily ...
> 
> The problem that wine developers have with recipies
> like the one you cite is that most of the steps in
> the recipe are there to work around bugs in Wine.
> We would prefer to fix the bugs.  For instance,
> the steps related to sound and winecfg should just
> go away, hopefully this summer.  Likewise with directx
> and registry settings.
> 
> That said, I'm certainly in favor of helping users,
> as long as it's done 'right', for some hard to pin down
> definition of 'right'.
> - Dan

Hi Dan,
I understand the WINE developers' attitude for such temporary fixups as
listed above in Oblivion in Linux Wiki.

However, usage scenarios for automated SW installer applications offer far more.

First, it somehow mirrors info from AppDB. It can display application usability 
for
range of WINE versions and also make available application on older WINE
versions. 

For example Ubuntu Dapper Drake (6.06) will distribute and support Wine
0.9.9 for four years from now.

Second, using automated tools, regression tests can be fully automated,
so building a repository of free game demos or applications is just a
matter of time. Packages can be suited to fit specific WINE versions
or made generic. Install scripts can fully automate / simulate 'normal'
Windows installation process.

Creating regression testing DB is going hand in hand with package
installer creation, so costs are low to nothing.

Automated regression testing could be a big plus of these solutions. 
WINE would profit greatly from this.

Third, having list of 'hacks' stored in 'unified' manner within 
repository simplifies access to 'fixups' for outstanding issues. At
least they will be at one place (similar to AppDB now).

-

I've been thinking heavily before I've started participating on
Wine-Doors and coding on Winebot. I've made conclusion that I cannot
hurt WINE, given the potential of these automation tools.

However, in future it may cause trouble for commercial WINE
implementations, that are selling nice GUI and 'easy installation'.

Regards
Vit

Re: Regedit output to STDOUT / force registry files sync

[Vit Hrachovy]

On Wed, Mar 21, 2007 at 11:38:03PM +0100, Detlef Riekenberg wrote:
> On Di, 2007-03-20 at 21:12 +0100, Vit Hrachovy wrote:
> 
> > Hi Bill,
> > that's not the case I'm searching for. I'm aware that regedit can export 
> >   into files. I simply want registry export to STDOUT nothing else.
> 
> Did you test reg.exe / regini.exe ?
> 
> > I'm going to submit a patch with some sort of new application
> 
> Please try the above first. Both are from Microsoft. 
> 
> Example:
> $ wine reg.exe query "HKCU\Software\wine\MSHTML"
> 
> ! REG.EXE VERSION 3.0
> 
> HKEY_CURRENT_USER\Software\wine\MSHTML
> GeckoUrlREG_SZ  http://source.winehq.org/winegecko.php

Hi Detlef, 
reg.exe is very close to fulfill my requirements. 

However, it's not implemented in WINE yet.

As there is a need for such tool, I propose to implement reg.exe in
future WINE versions. I'll write a prototype.

Thanks a lot for Your help.

Regards
Vit Hrachovy

Re: Regedit output to STDOUT / force registry files sync

[Vit Hrachovy]

Lei Zhang wrote:

Believe it or not, there are UNIXes without /dev/stderr and /dev/stdout.
Having regedit option to flush its output to STDOUT (and to get its
input from STDIN) would be very helpful - and in case of STDOUT output
very easy to implement.

Regards
Vit Hrachovy



Sure, but Unices that run Wine have /dev/stderr.

A better reason for not modifying regedit is that is breaks
compatibility with Windows' regedit. Yes, it can is helpful to have a
tool that can retrieve registry keys from the command line, but we
should not overload that functionality into regedit.


Hi,
thanks for recommendation, I'll send a patch with the new tool for 
review soon.

Regards
Vit

Re: Road to 1.0

[Vit Hrachovy]

Dan Kegel wrote:

In fact complete Wine-Doors / Winebot projects can serve for this
purpose too - as a repository of automated WINE tests.


Yes, when I heard that Wine-Doors used autohotkey, I
realized the same thing.
(I gather winebot is part of wine-doors,
http://www.wine-doors.org/trac/browser/sandbox/contrib/prototype/winebot.pl) 


I am quite skeptical of wine-doors, though, for various reasons.
(For instance, the web site is both overdesigned and amateurish,
the project was founded with way too much self-promotion, and
the goals were both grandiose and poorly explained.  Doesn't
mean they'll fail, but it does mean I find it painful to interact with 
them.)

- Dan


WineBot (http://winebot.sandbox.cz) is a sort of lightweight 
implementation of some core thoughts, but with command line based 
interface and less dependencies. Both projects share some core ideas and 
data file formats.  WineBot goals are much smaller in scope than 
Wine-Doors ones, going in smaller steps.


The main goal is to replace obsolete and almost unmaintainable winetools 
project.


Main idea is to make repositories of supported application packages, 
both installed from CD, HDD or downloaded from net.


For example to install Oblivion by placing CD into tray and entering

winebot install tes_oblivion-1.1.511uk

Or in case of Wine-Doors - insert CD, run wine-doors, select Games 
repository, click to add Oblivion to install queue.


Given list of manual steps required to install Oblivion 
http://www.uesp.net/wiki/Oblivion:Linux
this can be automated easily and comfort would be similar to using Loki 
installers.


Regards
Vit

Re: Regedit output to STDOUT / force registry files sync

[Vit Hrachovy]

Bill Medland wrote:

On Tue, 2007-20-03 at 21:12 +0100, Vit Hrachovy wrote:

Bill Medland wrote:

b) Enhance regedit to be able to output to STDOUT. By default registry 
search output is done to a specified file. It can be redirected to 
STDERR, though. (tested on 0.9.29, 0.9.33)



c) Use the shell
wine regedit -e /tmp/$$.reg  && cat /tmp/$$.reg && rm -f /tmp/$
$.reg

Hi Bill,
that's not the case I'm searching for. I'm aware that regedit can export 
  into files. I simply want registry export to STDOUT nothing else.

My point is that the great thing (to me) about unix-like systems is the
ability to join commands together, which it is why I can write a simple
statement that will use the existing regedit and two standard unix
programs (cat and rm) to generate the output on stdout.


Yes, I understand. I simply don't like an idea of generating unnecessary 
file access. I'd prefer data streams and pipes where possible - another 
great unix thing :-)


As Lei Zhang mentioned such an application would be useful for more 
people than me, I'm going to submit a patch with some sort of new 
application [not to break 1 to 1 regedit compatibility] able to output 
registry entries to STDOUT.




You seem to accept the point that we should not add functionality to the
existing regedit, so that we retain 1-1 compatibility with the Windows
version.

However in creating yet another application I suggest you are
reinventing the wheel.  Either it will use regedit to do the hard work
(in which case it is equivalent to what I suggested) or else it will
access the registry itself (in which case it is going to have a lot in
common with regedit and so you are duplicating functionality and
accepting the maintenance cost).

(Can I also suggest that going back to your original idea we could
accept a filename of - as meaning stdin/stdout, so that we can use

regedit -e - "HKEY_LOCAL_MACHINE."

Then we still have the same arguments as Windows; it's just that we are
a little more free in what we accept as a filename.  After all, we
already accept Unix filenames as well as Windows filenames.)


Yes, simple - as a STDOUT would be sufficient. Currently it doesn't work 
in regedit.


That was the main reason I'm asking here on list - I don't want to 
reinvent the wheel and I'd prefer not to support another application to 
do the same job as regedit. I'm trying to find an elegant solution. 
Support for - as STDOUT file name in regedit is an elegant solution and 
will be sufficient to fullfill my desires.


The question to be answered by the dedicated people is whether it is 
acceptable for regedit compatibility issues.


Regards
Vit

Re: Road to 1.0

[Vit Hrachovy]

Dan Kegel wrote:

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





AutoHotkey (http://www.autohotkey.com) seems to do very well.
I'm using it for automated installation of lots of Windows programs into 
 WINE bottles as an initialization (something similar to winetricks).

It's very well documented, too.

Writing a series of batch scripts for automated testing is very easy.

In fact complete Wine-Doors / Winebot projects can serve for this 
purpose too - as a repository of automated WINE tests.


Regards
Vit

Re: Regedit output to STDOUT / force registry files sync

[Vit Hrachovy]

Bill Medland wrote:

b) Enhance regedit to be able to output to STDOUT. By default registry 
search output is done to a specified file. It can be redirected to 
STDERR, though. (tested on 0.9.29, 0.9.33)



c) Use the shell
wine regedit -e /tmp/$$.reg  && cat /tmp/$$.reg && rm -f /tmp/$
$.reg


Hi Bill,
that's not the case I'm searching for. I'm aware that regedit can export 
 into files. I simply want registry export to STDOUT nothing else.


As Lei Zhang mentioned such an application would be useful for more 
people than me, I'm going to submit a patch with some sort of new 
application [not to break 1 to 1 regedit compatibility] able to output 
registry entries to STDOUT.


Regards
Vit

Re: WineCfg and DirectX options

[Vit Hrachovy]

On Mon, Mar 19, 2007 at 02:07:59PM +0100, Stefan D?singer wrote:
> > Hi,
> > implementing GLSL checkbox, OffScreenRenderingMode dropdown menu and
> > VideoMemorySize textbox into winecfg would be easy.
> GLSL is OK IMO, because some drivers(*cough* macos *cough*) have serious 
> problems with glsl. It could be included into the shader dropdown box. The 
> issue that needs to be dealt with is that we can't combine arb vertex shaders 
> and glsl pixel shaders or vice versa.
> 
> Video memory size maybe too. There are vendor dependent ways to read it, but 
> implementing them is pretty nasty(requires some private  to winex11.drv). 
> Altough we had that discussion a number of times already and we only agreed 
> on a registry key so far.

Hi Stephan,
I've inspected winecfg code closely and the current state is that
implementing GLSL into shader dropdown menu would make it non-elegant.

Shader dropdown box expects the registry value to be only on one place,
in [Software\\Wine\\Direct3D] VertexShaderMode.

GLSL in my opinion uses two registry entries - VertexShaderMode and
UseGLSL. IMO UseGLSL == enabled implicates VertexShaderMode == hardware.

To reflect the current state I could take one of the following two
approaches:

1.  Add a checkbox 'Allow GLSL (if supported by hardware)' after 'Allow
Pixel Shader (if supported by hardware)'. This checkbox would control
only state of UseGLSL registry entry, nothing else.

1.1 Checkbox 'Allow GLSL' would set Vertex Shader Mode to "hardware" when
enabled.

2.  Implement Implement GLSL entry into Vertex Shader Support dropdown
menu and create nasty workarounds like:
--  
  if (strcmp("GLSL" , D3D_VS_Modes[selected_mode].settingStr) == 0) {
set_reg_key(config_key, keypath("Direct3D"), "VertexShaderMode", 
  "hardware" );
set_reg_key(config_key, keypath("Direct3D"), "UseGLSL", "enabled");
  }
  else
  { 
set_reg_key(config_key, keypath("Direct3D"), "VertexShaderMode",
  D3D_VS_Modes[selected_mode].settingStr);
set_reg_key(config_key, keypath("Direct3D"), "UseGLSL", "disabled");
  } 
--

where previous code was only:

--
  set_reg_key(config_key, keypath("Direct3D"), "VertexShaderMode",
  D3D_VS_Modes[selected_mode].settingStr);
--

I'd vote for 1. or 1.1 solution.

There is also another solution - to implement UseGLSL registry entry into
VertexShaderMode entry and discard UseGLSL key completely. However, this 
is far reaching change.

Regards
Vit Hrachovy

Re: Regedit output to STDOUT / force registry files sync

[Vit Hrachovy]

On Mon, Mar 19, 2007 at 09:27:09AM -0700, Lei Zhang wrote:
> On 3/19/07, Vit Hrachovy <[EMAIL PROTECTED]> wrote:
> >Hi,
> >I'm trying to find some elegant method to access registry keys added
> >during one WINE session, i.e. without restarting WINE.
> >
> >Test case description:
> >1. Open WINE session
> >wineconsole --backend=user cmd
> >2. During session, insert some new registry key
> >regedit new-entry.reg
> >3. Try to access the new registry entry from bash
> >cat ~/.wine/system.reg |grep AutoHotkey
> >(fails)
> 
> Accessing the Wine registry directly is probably not the right way to
> do it, you should go through the Windows registry API calls, i.e.
> RegQueryValue.

I'm aware of that it's not the best way. 
According to the documentation at
http://winehq.org/site/docs/wineusr-guide/using-regedit
there are two ways to access the registry - using file access and using
regedit.

AFAIK what You mention these are C API calls. I'm trying to access 
the registry from PERL. If registry access should be done only via 
API calls, then there is Regedit tool which uses the API calls. 
That leads to the second point, enhancing regedit.

> 
> >4. Close WINE session
> >
> >I've found there was at times an option to save registry periodically,
> >but this can't help me here.
> >
> >This problem can be solved in two ways, both of them can be helpful:
> >
> >a) Create small program to force sync of registry in memory with
> >registry files - 'wineflushregistry'.
> >
> >b) Enhance regedit to be able to output to STDOUT. By default registry
> >search output is done to a specified file. It can be redirected to
> >STDERR, though. (tested on 0.9.29, 0.9.33)
> >
> 
> If you can get it to go to stderr, why not just use shell redirection
> to redirect stderr to stdout?

Believe it or not, there are UNIXes without /dev/stderr and /dev/stdout.
Having regedit option to flush its output to STDOUT (and to get its
input from STDIN) would be very helpful - and in case of STDOUT output
very easy to implement.

Regards
Vit Hrachovy

Re: WineCfg and DirectX options

[Vit Hrachovy]

On Mon, Mar 19, 2007 at 10:49:59AM +, Ray Jones wrote:
> H. Verbeet  gmail.com> writes:
> 
> > 
> > On 17/03/07, Louis Lenders  yahoo.co.uk> wrote:
> > > I completely agree with this.This fiddling around with regedit is really
> > > annoying, and moreover you cannot see what keys actually can be added or
> > > changed.
> > >
> > Because it's not something you should have to configure. 
> 
> But "fiddling around" with native and built in DLLs is something that 
> shouldn't
> have to be configured as well, but still, it has to be done and that's why it
> can be found in winecfg. For those who like to configure DirectX thingers,
> the better way (after a setting has become somewhat "useful" of course)
> would be winecfg.
> Even more, what if someone doesn't know about all the registry keys?
> Every user knows winecfg, and I'd say users are more likely tempted to "play"
> with some checkboxes than unknown registry settings, and users who "solved" a
> problem this way are more likely to report this than those who have not been
> successful.
> 
> On the other hand, why not implement switching these registry keys into
> winetricks because it's doing a great job already anyway? ;

Hi,
implementing GLSL checkbox, OffScreenRenderingMode dropdown menu and
VideoMemorySize textbox into winecfg would be easy.

winetricks is IMO going the same way as winetools - too much functions
in one big shell file. This will be very hard to maintain as
functionality grows.

I consider Wine-Doors project more promising as it splits these
hacks into separate 'packages'. Recently it's become really usable :-)

There is also a lightweight command-line PERL based implementation of 
Wine-Doors called winebot at http://winebot.sandbox.cz . Both Wine-Doors
and Winebot share same package sources.

Regards
Vit Hrachovy

Regedit output to STDOUT / force registry files sync

[Vit Hrachovy]

Hi,
I'm trying to find some elegant method to access registry keys added 
during one WINE session, i.e. without restarting WINE.


Test case description:
1. Open WINE session
wineconsole --backend=user cmd
2. During session, insert some new registry key
regedit new-entry.reg
3. Try to access the new registry entry from bash
cat ~/.wine/system.reg |grep AutoHotkey
(fails)
4. Close WINE session

I've found there was at times an option to save registry periodically, 
but this can't help me here.


This problem can be solved in two ways, both of them can be helpful:

a) Create small program to force sync of registry in memory with 
registry files - 'wineflushregistry'.


b) Enhance regedit to be able to output to STDOUT. By default registry 
search output is done to a specified file. It can be redirected to 
STDERR, though. (tested on 0.9.29, 0.9.33)


Enhancing regedit
-

regedit /es 
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App 
Paths\AutoHotkey.exe"


which will be similar to (non-functional)

regedit /e /dev/stdout 
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App 
Paths\AutoHotkey.exe"



Regards
Vit Hrachovy