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