Am Sa, Mär 12, 2005 at 10:48:54 +0100 schrieb Roman Stöckl-Schmidt: > 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). If you have donwloaded files you can just copy them to ~/winetools/sys (fonts for font-files). That's all. So this feature is already there. For IE6 you can also place the folder of downloaded files (for the english version it's c:\windows\Windows Update Setup Files, for other languages you have to look for a translated directory) into sys. > > 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. As I do not know which DLLs from where for what it is hard to implement this feature. But you can do this on your own if you want them for your install. For supported software of WineTools, which is the main purpose of this software, WineTools will care fro this in it's own way. > > 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. Yes, WINEPREFIX is the glue and it will be supported sometimes by WineTools. > 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. Nice idea. Until now there is no include for the config file. This should go to the development list and not to wine-users. Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!" _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users