[Wine] exporting registry to Wine

Wed Dec 19 05:06:57 CST 2007

Thanks for all these detailed explanations.
I think I understood the pros and cons of that approach.
I understand this is not a goal for the Wine team.
Unfortunately, even if it will be extremely difficult and somewhat hacky, I
must give it a try in my case.
So, if anyone knows about registry monitoring tools, I'll be glad to hear
about it.

Anyway, thanks for answering.
Sebastien.

On 12/19/07, L. Rahyen <research at science.su> wrote:
>
> 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.
>

-- 
www.pleyo.com
Join OWB team on freenode IRC, channel #owb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-users/attachments/20071219/5ddc7741/attachment.htm 