Uninstalling using warpin removes X:\os2\dll from libpath and X:\os2 from path

[Gregg Young]

While it removes the ifs and the cache it adds them back at the end of the file. See attached diff between the config.sys created by the uninstall and the one before the uninstall.

[erdmann]

Yes I experience the same. The minimum that needs to be achieved is that the WPI does NOT change the LIBPATH and PATH statements and that the installation paths for the relevant components are fixed to (bootdrive)\OS2\DLL and (bootdrive)\OS2 respectively. That will avoid the problem that on deinstallation these ESSENTIAL path components are removed from config.sys.

For the IFS and CACHE statements I think these are WARPIN shortcomings that cannot be changed by changes to the WPI script: when you have the IFS and CACHE statements already in config.sys when you run the installation and they are replaced by the new installation, the original statements will be readded on a deinstallation and will always be appended to the end as WARPIN does not remember where they were initially.

[Gregg Young]

the original statements will be readded on a deinstallation and will always be appended to the end as WARPIN does not remember where they were initially.

It isn't the placement I care about. They shouldn't be readded at all.

[erdmann]

That is a limitation of Warpin which cannot be worked around in the WPI install script: if you had IFS and CACHE Statements BEFORE installing the new FAT32 WPI and you then deinstall the new FAT32 WPI then Warpin will READD the initial IFS and CACHE statements that where replaced on installing the new FAT32 WPI.

It's easy to test: remove IFS and CACHE Statements manually BEFORE you run the new FAT32 WPI Installation. If you subsequently deinstall FAT32 no IFS and CACHE statements will be readded.

[Valery V. Sedletski]

Looking into the .wis script, I see the following warning:

<P>WARNING: IF INSTALLED TO YOUR OS2 DIRECTORIES,THE OS2 AND OS2\DLL
ENTRIES FOUND IN THE LIBPATH AND PATH STATEMENTS IN THE CONFIG.SYS FILE WILL
BE REMOVED WHEN THIS DRIVER IS UNINSTALLED.  THE END RESULT WILL BE THAT YOU
CANNOT BOOT TO YOUR eCS OR OS/2 DESKTOP. TO PREVENT THIS, IT IS BEST TO USE THE
EXTERNAL SYSTEM EXTENSIONS SUPPORT BASE(ESEs) WHICH NEEDS TO BE INSTALLED FIRST
BEFORE THE FAT32 DRIVER.  THE EXTERNAL SYSTEM EXTENSIONS SUPPORT BASE(ESEs)
CAN BE DOWNLOADED FROM
<P>

ftp://ftp.netlabs.org/pub/wpidistro/download/ESE/00-Base-ESES.wpi


<P>IF ONE DOES NOT WANT TO INSTALL (ESES), THEN YOU WILL NEED TO MANUALLY EDIT
YOUR CONFIG.SYS AFTER REMOVING THE FAT32 DRIVER AND ADD THE "DRIVE:\OS2"
DIRECTORY TO YOUR PATH STATEMENT AND YOUR "DRIVE:\OS2\DLL" DIRECTORY TO YOUR
LIBPATH STATEMENT.</B>
<P>

Never used these ESE's, though they may be an option for someone. So, it looks like it's a WarpIN limitation anyway. I prefer to avoid using automatic installers which modify CONFIG.SYS. Instead, I modify it manually (or, at least, check the changes they made to CONFIG.SYS and fix them manually). When installing a newer FAT32 version, it is not required to touch CONFIG.SYS at all. Instead, it's sufficient to:

1) Unlock CACHEF32.exe by UNLOCK.EXE, or by just quitting it: CACHEF32 /Q 2) Overwrite \os2\*.exe 3) Overwrite \os2\dll\*.dll 4) Overwrite \os2\boot\* That's it. It is much quicker than rerunning WarpIN each time.

The only valid reason to run a .WPI is installing FAT32.IFS during the OS installation. But this does not involve uninstalling, so the current issue doesn't apply.

[aschn]

A workaround might be: Use a script called with EXECUTE to alter the CONFIG.SYS. It could also be used for uninstall, but then with another parameter.

BTW: It's not handy to have to install Alfredo's otherwise unknown package first. (BTW: I've never heard before of it, but I never tried to install a FAT32 .wpi.)