SCOUG-HELP Mailing List Archives
Return to [ 22 |
July |
2002 ]
<< Previous Message <<
>> Next Message >>
Content Type: text/plain
=====================================================
If you are responding to someone asking for help who
may not be a member of this list, be sure to use the
REPLY TO ALL feature of your email program.
=====================================================
Peter wrote:
> The INI files are very simple. They are like a 3-column
> spreadsheet. The first column is titled Application and
> is the general purpose of that particular line in the
> spreadsheet (for example, "MyFinancialPrograms"). The
> second column is titled Key and is the specific name for
> that particular line (for example, "MyTaxReturnFor2001").
> The third column is the Data (for example,
> "C:\Finance\Taxes\1040-2001.txt").
>
> It looks like this:
>
> Application Key Data
> =================== ================== ==============================
> MyFinancialPrograms MyTaxReturnProgram C:\Finance\Taxes\DuckTax.exe
> MyFinancialPrograms MyTaxReturnProgram C:\Finance\Taxes\1040-2000.txt
> MyFinancialPrograms MyTaxReturnFor2001 C:\Finance\Taxes\1040-2001.txt
_If_ that is pretty much all one finds inside the OS/2 INIs, they are indeed a model of
simplicity & efficiency, esp. compared to the labyrinthine monstrosity that is the Windoze
Registry. (I do believe I have glimpsed other stuff in there, Peter, such as the odd product
registration #.)
This leads me back to an old question I once asked on CIS, but either I did not understand the
answers received, or they were just not very helpful. And this has very practical
implications. When do you absolutely *need* to install an application afresh (to be usable by
a particular Warp partition), vs. just simply trying to migrate it in from some prior install
via "Add a Program ?" I've had pretty fair success with the latter approach when the item in
question was a simple utility, a game, or a legacy DOS program, but I always hesitated to go
that route for a major app. My guess was that it depended on whether the program install had
to modify CONFIG.SYS, or placed anything essential into the OS/2 INIs. In some cases, I have
gotten away with grafting a piece in from a CONFIG.SYS for a Warp partition for which the item
was already installed.
A corollary to this question is the issue of moving programs to another location. In the
simple, individual case, I guess one can just modify the address within the program object, and
ditto for any location reference to it in CONFIG.SYS. But, I don't know of a (reliable) way to
move a whole bunch of programs in one shot, much less relocate the contents of a whole
partition to a new drive letter, and globally change all the program location info so that it
would still work. If such a utility existed, it would represent a huge time savings over
redoing a full app. installation. (PowerQuest had a utility for WIN called Magic Mover, that
claimed to do this, but I don't know how well it worked.) Peter's post suggests the
possibility that such a thing might not be out of the question.
> Resetting the WPS is just a way to get it to write the changes,
> which are held in memory, to the OS2*.INI files on the hard
> drive. If you reset the WPS this will happen.
Is there a distinction between Resetting the Desktop (for which there is an explicit menu
choice in UniMaint), and resetting the WPS ? I'm not sure I've been entirely following what
Steven has been saying on this score, but it has always been my experience that if I don't
Reset the Desktop, the repairs I've just made in UniMaint do *not* stick; if I Reset, they do.
Simple as that. When I Reset the Desktop -- the last thing I do before quitting UniMaint --
the only times it crashed were due to a video driver conflict, back when I still ran an ATI
card. Never since then. With some earlier versions of UniMaint, quite a few of the desktop
items did not come back after a Reset, so I had to reboot, and then they would. Even with
5.10.23, it still always creams the Warp Center in W4 . . . but not in ECS.
> The earlier versions were buggy when you did more than one
> Repair run without restarting the program -- not all of the internal
> program variables were reinitialized properly for the subsequent runs.
> If you have an earlier version you can do _one_ Repair run but you then
> need to restart the program.
Well, I just never did more than one big run per UniMaint session anyway, so it wasn't an issue
for me. I also never used the other two programs, just UniMaint, which has been more than
adequate all by its lonesome for keeping my OS/2 registries functioning. I may try out
CHECKINI some time, but I suspect that what the others do that UniMaint does not do is more
akin to the later-version UniMaint feature "Do Aggressive Repairs," which royally trashed my W4
partition, the one time I did try it. That aggressive a cleanup I'll do without, thank you.
Steven responded (to Svobi ?):
> >I do UniMaint and CHECKINI just as discussed here ...
> >... but restarting the WPS alsways ends with a blank screen !
>
> Exactly. It happens on enough systems that I recommend not doing it.
On the other hand, the process killer / monitor Ctrl-Alt-Delete Commander has a function called
"Restart the WPS." I don't know if this is in fact something significantly different from
UniMaint's "Reset the Desktop," but I can tell you that it has *always* crashed me down to a
frozen black screen, from which there is no recovery other than a hardware Reset. Of course,
if I ever had to pull that ripcord in the first place, it was because OS/2 had _already_ locked
up or gotten into dire straits, so who knows. But it did seem like a very dubious feature, in
terms of any use it has ever been to me.
Jordan
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 22 |
July |
2002 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
| 
