On 4/1/2010 9:40 PM, Lem wrote:
> John Doue wrote:
>> On 4/1/2010 8:22 PM, Pegasus [MVP] wrote:
>>>
>>>
>>> "John Doue" wrote in message
>>> news:eLMIwwZ0KHA.4168@TK2MSFTNGP02.phx.gbl...
>>>> On 4/1/2010 10:36 AM, Pegasus [MVP] wrote:
>>>>>
>>>>>
>>>>> "setecastronomy" wrote in
>>>>> message news:A2BC5191-42CF-4264-BEEC-E8C43B489312@microsoft.com...
>>>>>> Here we have some legacy applications for windows whose installing
>>>>>> media went
>>>>>> lost. We don't even have any contact with the software houses or
>>>>>> programmers
>>>>>> who developed them. We would like to move some of them to new
>>>>>> computers but
>>>>>> it can be a nightmare. Searching on the net I learnt there are
>>>>>> commercial
>>>>>> software which claim to do that dirty work, but I found no clue on
>>>>>> how
>>>>>> to do
>>>>>> it manually. In the past I tried to solve a similar scenario using
>>>>>> sysinternals tools (ProcessMonitor) to understand what files and
>>>>>> dlls an
>>>>>> application needed but I ended up with total failure. Any
>>>>>> suggestions ?
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Filippo
>>>>>
>>>>> With simple applications it is sufficient to copy the application
>>>>> folders to the new machine and perhaps also some .dll files in case it
>>>>> complains. With complex applications you would have to replicate each
>>>>> and every registry entry, which sounds like an impossible task unless
>>>>> they are all clearly marked as belonging to this particular
>>>>> application.
>>>>> Your best bet may be to replace the applications with new ones that
>>>>> are
>>>>> fully supported and for which you implement a formal register to
>>>>> protect
>>>>> yourself against future loss. Note also that if these are 16-bit
>>>>> applications, they won't run under new OSs such as Windows 7.
>>>>
>>>> One easier -IMHO- option is:
>>>>
>>>> 1/ Run a registry cleaner to get rid of existing issues *after* making
>>>> a backup of it and making sure System Restore is activated.
>>>>
>>>> 2/ Create a restore point.
>>>>
>>>> 3/ Move (not copy) the directory (ies) to their new location, keeping
>>>> the same structure.
>>>>
>>>> 4/ Run again the registry cleaner and make a careful note of what
>>>> comes up as new issues.
>>>>
>>>> 5/ Go into the registry and do a search and replace to replace the old
>>>> locations by the new ones.
>>>>
>>>> 6/ Run again the registry cleaner to see if you missed some registry
>>>> keys.
>>>>
>>>> 7 / Try running the software.
>>>>
>>>> Doing this assumes you are familiar with working on the registry,
>>>> doing backups, and restores. Sorry if this sounds patronizing.
>>>>
>>>> I do not know many tools which can do search and replace in the
>>>> registry. One of them is Powertools, whose registry cleaner and other
>>>> applications I find reliable.
>>>>
>>>> Good luck.
>>>>
>>>> --
>>>> John Doue
>>>
>>> Your suggestion expands on the point I had made: That a transfer could
>>> be feasible if the application had flagged all its registry keys so that
>>> they would be recognisable. This is a tall order for a human and an much
>>> taller order for an automated process. My suspicion is that the registry
>>> cleaner would miss numerous relevant entries and flag numerous
>>> irrelevant entries. Would you care to test the idea on your machine,
>>> e.g. with Acrobat Reader, and report the results here?
>>
>> We are talking legacy applications here. I do not think Acrobat Reader
>> qualifies. If I took the time to expose this process, it is because I
>> have used it previously, even for applications which make extensive
>> (very extensive use) of the registry. Like WordPerfect X4. Involved,
>> but feasible. Worth trying if you value said application.
>>
>> If the application does not make much use of registry keys, it might
>> just work after a move, or editing of ini files might be in order.
>>
>> Any way, this is worth a try. Of course, suggesting to replace legacy
>> applications is less involved: if your car no longer works, just buy a
>> new one. Easier.
>
> Although your process has a certain logical appeal, it depends on the
> repeatability of the registry cleaner that is used. Although the cleaner
> you used may well have worked for the applications that you had, I've
> seen more than one report about registry cleaners that find "registry
> errors" on a second pass *after* they have run, found errors, and been
> permitted to "clean" or "repair" those errors.
>
> As you suggest, it *may* be worth the time and effort to try, but your
> first instruction, to make a backup, is crucial. I'd make a disk image,
> rather than a registry backup. If you manage to corrupt the registry
> sufficiently to prevent Windows from starting, then it probably will be
> easier to restore using an image than using a registry backup utility
> (which likely will require booting into a non-Windows OS).
>
> [Sometimes it *is* more cost effective to buy a new car rather than
> continuing to make repairs to an old one. But that's another story.]
>
My idea of a registry backup is a backup which can be restored, if
needed, out of Windows, otherwise the interest is limited. For that
purpose, my registry backups (daily) are stored on a partition other
than C:. Saved my bacon more than once. Just to boot a CD or diskette,
unpack the zip file, modify as needed the restore batch file to reflect
the drive Windows is installed on, and there I go.
The cleaner I suggested (Powertools) is 100% consistent in its results.
Indeed, I would not trust any such utility without extensive experience
with it.
At the end of the day, the idea is to offer solutions to the OP, not to
attempt to prove your suggestion is the best, or the only one. On the
other hand, sidestepping the question is not answering it
.
Indeed, moving to a more modern application is often a wise solution,
but in some cases, businesses especially, custom critical applications
were developped and for some reason, not updated to follow Windows
evolution. So, this is not always a simple option ... even if it remains
desirable in a longer term perspective.
--
John Doue