<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <pre wrap="">Joachim,</pre> <tt>Than you for your maintenance of WineTools!<br> <br> Some ideas for future development.<br> <br> Targeting alternative directories other than ~/.wine perhaps in a shared area or in ~/.wine1 ~/.wine2, etc... <br> <br> It would also be nice to have a common winetools/sys directory where cached downloads can be retrieved. <br> <br> A feature of installing useful Windows DLLS from Windows CDs.<br> <br> Restructuring the WineConfigurations to allow multiple users to run applications from various wine environments. I'm beginning to see how this might be done. Each user having different dosdevices files, command lines specifying different wineservers, configuration files, etc...<br> <br> For instance, I might want to have three "Windows Installations" because I have three versions of a program that I need to run, and they don't want to co-exist on the same Windows installation. <br> Now I have say 40 users who need to be able to run all three programs at the same time.<br> <br> I've been mulling over the permissions matrix in my head for some time. I think it is a simpler issue than I have been perceiving it to be.<br> A file system overlay tool for Linux is beginning to be used which could prove useful for having multitudes of users having write access to the same drive_c while being able to delete, modify and add files to it without conflicting with other users' changes.<br> <br> It's called UnionFS and it plays a big part in the upcoming Knoppix 3.8 by allowing you to overlay modifications to system files by writing to ram. This is really a cool tool and I can see it having a huge benefit to multiuser Wine implementations.<br> <br> UnionFS Home Page (Part of the FiST project - </tt><tt>Stackable File System Language and Templates</tt><tt>)<br> <a class="moz-txt-link-freetext" href="http://www.fsl.cs.sunysb.edu/project-unionfs.html">http://www.fsl.cs.sunysb.edu/project-unionfs.html</a><br> <br> UnionFS is mentioned here:<br> <a class="moz-txt-link-freetext" href="http://www.linux-live.org/">http://www.linux-live.org/</a><br> <br> -Joe Baker<br> <br> <br> <br> </tt> </body> </html>
Roman Stöckl-Schmidt
2005-Mar-12 03:48 UTC
[Wine]Thanks for WineTools! - Ideas for improvement
Joe Baker schrieb:> Some ideas for future development. > > Targeting alternative directories other than ~/.wine perhaps in a > shared area or in ~/.wine1 ~/.wine2, etc... > > It would also be nice to have a common winetools/sys directory where > cached downloads can be retrieved. >I'd like to second that: It might just be useful to ask the user wether he has an already downloaded version of the program he is trying to install and give him the option to enter the path in case he has one. This is very useful if someone has e.g. tried to install ie6, dcom98 et.al. without winetools before; has it on his native windows partition; has a cd containing it, etc. For dial-up users like myself this would be a huge relief. If for example with ie some components winetools wants to have installed initially haven't been downloaded yet, the installer will automatically get them anyway and there's no need for the user to have to find out where winetools looks for the already installed files (e.g. ~/winetools/sys I think for dcom98).> A feature of installing useful Windows DLLS from Windows CDs.It would be of great importance for this feature to use something like cabextract, otherwise one wouldn't be able to get the stuff from a windows installation CD-ROM.> Restructuring the WineConfigurations to allow multiple users to run > applications from various wine environments. I'm beginning to see how > this might be done. Each user having different dosdevices files, > command lines specifying different wineservers, configuration files, > etc... > > For instance, I might want to have three "Windows Installations" > because I have three versions of a program that I need to run, and > they don't want to co-exist on the same Windows installation. > Now I have say 40 users who need to be able to run all three programs > at the same time.Setting aside the permission thing you were talking about after this I'd like to add something else. This is not really winetools but rather wine specific but I think it would definitely improve the users (and developers, since they naturally use it to) experience. I'd love to see programs and their configs installed to their own path instead of everything to ~/.wine/[c_drive | fake_windows]/Program Files and ~/.wine/config like Transgamings Point2Play does (yes there is some good to learn from commercial wine adaptions =)). To be more precise one would still have ~/.wine/config and ~/.wine/[c_drive | fake_windows] as the default setup but every program installed would create their modifications to that in thier own path, like ~/.wine/$program/config and ~/.wine/$program/[c_drive | fake_windows]. Additionaly for multi-user environments one could install the programs to /opt/wine/$program, /usr/share/$program /usr/local/share/$program depending on your distros/personal preference. This way if you run into problems with an application installation were you would normally have backed up ~/.wine before and would now remove it and replace it with the backup version you could just remove the $program directory and everything would be clean. $program should be a unique identifier so when you execute for example internet explorer 6 (id: ie6) which would need e.g. dcom98 (id: dcom98) wine would first read the normal config and make it's default [drive_c | fake_windows] available then the program specific config/path is read: $wineroot/ie6/config and in here you'd have a line like "include '$wineroot/dcom98'", I guess you all get were I'm aiming at so I'll just stop here. The goal is just to have a really modular installation were you can have programs run from your own or the shared directory every user in your network uses and to avoid the hassle that presently exists when using programs that cause problems... What do you think about this? Cordial greetings, Roman.