On Tuesday December 18 2007 22:55, Markus Hitter wrote: > I well rembember, a few weeks ago I suggested getting my Intel 3D > graphics to work and got flamed. You can flame me again, but flaming > interested people isn't the best way to increase the user base. No, you wasn't flamed - just many people tried to explain you why Intel card work very bad and there is very little of what WINE team can do with that fact. I'm sorry if I was a little rude in my previous messages but you should understand that I or someone else cannot magically implement what you want. This is same as with Intel card - only Intel can make it better. In case with Windows programs only developers of that programs can make them better - for example to support installation-less launching. And there is some Windows programs that do support this. In fact even if the program is using registry it may support installation-less launching just by recreating all necessary registry keys from scratch. But problem here that most developers of Windows programs simply don't care and don't want to spend their time for supporting such configurations. > > (and you will not be able to use the program on Windows and WINE > > simultaneously) > > Such a situation can't exist, as desktop PCs can run only one OS at a > time. Actually it can, for example I can run multiple operating systems from one hard disk on multiple hardware (either real or virtual). And in fact I do it on my diskless computer (it loads OS from hard drive on another computer via Ethernet network). But of course most users don't do this. However if something prevent sync or monitor process from running this will be equivalent to running Windows and WINE simultaneously on one partition: you may get broken configuration as a result (some programs might stop working correctly). > > (read: extremely hard to implement, so hard that no one will do it) > > Sure, it might be hard. Have you already thought about syncronising > when Wine/Windows is effectively shut down, i.e. no apps running? The real technical problem here isn't synchronization. Real problem is to find out what keys should be imported and what shouldn't. I explained this in details in my previous messages why this is so hard. And you cant just blindly import whole Windows registry to WINE (read: you can but it will not work correctly and many programs will fail to work). I'm just trying to explain why I or any other developer are unlikely to even try to implement such functionality - even outside of WINE Project as a separate tool. I understand all your points, I understand that this functionality might be useful for some users. But you should understand that this is extremely hard to implement, and that this is by definition is a very complex hack (remember, WINE team will not going to accept even simple hacks so such tool for importing Windows registry will never be a part of WINE and unlikely to be implemented by WINE developers). Even if someone try to make it possible this might harm WINE Project indirectly by preventing some users from writing proper bug reports (we already have some problems because of ies4linux project). However, this project will be much harder to implement than ies4linux! Personally I even don't imagine how to find all necessary registry keys in Windows registry *without* constant monitoring after clean Windows installation. But if you will require to reinstall Windows and all its applications and monitor registry constantly most users will not use such a tool for obvious reasons. Even in this case you will need to deal with registry keys conflicts (what to do if some keys are already existed but with different values, etc.) and this is impossible to do *properly* - you will need to implements additional hacks. If you still want this functionality you really need to think about how you are going to find out what registry keys are necessary to import/export and if you want this process to be user-friendly it must not require Windows reinstallation from scratch or any other complex actions from users. As I have said I even don't imagine user-friendly way to implement this *reliably* without complex actions on user side. And I think that this is practically impossible (without monitoring Windows registry as described above). > A lot better, but not yet ideal is to run Windows in qemu. Moving > data between OS's without stop gap is possible already, but the > complexity of the situation is immense. Complexity of implementing and support a tool we talking about (for syncing WINE and Windows registries) is even more complex and hacky, even from user's point of view (for developer's point of view this is even worse). And this is exactly the problem. > Sometimes, you don't even know in which OS the cursor currently is. Personally I don't have Windows on real hardware at all but I have it in virtual machine (VMWare). I have it opened on one of my desktops and its window is have such size so I can see whole Windows desktop exactly below KDE panel (therefore it looks more natively and there is no waste of screen space for VMWare window decorations). I use this virtual machines for some Windows programs that don't work on WINE. For example recent AutoCAD and 3ds max don't install on WINE and even worse: they will not work even if I try to bypass installation. Therefore I use virtual machine for this because there is no replacements (for example I need some specific tools and functions in 3ds max that aren't available on any other 3D-modelling programs). Yes, virtual machine is less convenient than WINE but its use isn't too hard if you setup it conveniently as I did. By the way, if you need free VM you better should try VirtualBox instead of QEmu - it is far more convenient and it has a feature that VMWare lacks - Seemless Mode (as I described above I just override VMWare window size to occupy whole screen space below KDE panel with Windows desktop - this in fact pretty good alternative to Seamless Mode). I'm talking about this so you understand that I have personal experience when something doesn't work in WINE (for example, installation of some Windows programs that I really need) and cannot be fixed quick and easily for one reason or another. And therefore I understand well all of your points but I have described already what technical and social problems are prevent functionality you want in WINE to be implemented (even as a separate tool outside of the WINE Project). Please note that we are talking here *not* about is it necessary or useful, or not (sure, there is some users who will find this useful) but about problems why this can be done easily and why it is unlikely to be done at all. I'm sorry but I cannot change that... Someone should solve *at least* all technical problems that I described to create such a tool otherwise it will be neither reliable nor useful for simple users. And don't forget about social problems (like with ies4linux project). However, in this case social problems even aren't so important (and therefore there is no need to discuss them) because, unfortunately, there is more than enough of technical problems that will prevent reliable implementation of this functionality. Also, if you aren't a programmer you either need to become one or find someone who are and will agree to spend his/her time for trying to implement this somehow - this is unlikely to happen though (yes, this is social problem) unless you are paying money for the programmer' work. _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
