Author Topic: Happy WarpINning!  (Read 9569 times)

Oxyd

  • Guest
Happy WarpINning!
« on: November 18, 2016, 02:02:18 am »
WarpIN is very popular installer for warp-like OS-ses.

Many software developers distribute their products in WarpIN format. But many developers do not use all the features of the installer, as well as being make a errors in the descriptions of the packages. As an example I will give diff of wis script of the lSwitcher(v2.8.1) archive: See diff

Hardcoded paths(to \ECS\... of course), errors in "<PCK>"'s, don't use "<GROUP>" for localisations and what annoying me biggest ... XWorkplace X(e)Center plugin does not distribute as separate package. They offer to put it the hands  :-\ , as in the good old days, when the software was distributed in ZIP format.

No, it is not our method! ;) So, on court of the community proposed a project "WarpIN-Scripts-and-tools".
In this, active development package:

In plans:
  • WPI distribution of QS LDR(with backup feature of original IBM OS2LDR), and script for repack developer's zip distrib.
  • WPI distribution of OS/4 "Phoenix" kernels(with the function of automatic addition of the installed kernel to the boot menu and the ability to simultaneously install different versions of the kernels, and script for repack developer's zip of course).
  • Continue adding to the database corrected WIS scripts of popular products. If you have such products, you can send me their scripts by e-mail (oxyd76 (at) gmail (dot) com) (and a direct link to download wpi of course!) with Subject: WarpIN Or join me on the GitHub! WarpIN it's easy! ;-)

Disqus?

Highwinder

  • Guest
Re: Happy WarpINning!
« Reply #1 on: October 06, 2017, 01:49:11 am »
Good for you.  As my first post in this forum, and after having recently re-discovered OS/2, and being a developer myself (such as it is with the VB-style stuff I use), I currently have no intention of supporting YUM, RPM or related repositories as an OS/2 developer.    While all versions of OS/2 in use can use WarpIn, not all of them can use the YUM/Repository feature that is so far exclusive to ArcaOS, which itself will still support WarpIn just fine.

Since I have no intention of shutting any doors on previous versions of OS/2, I'm sticking with WarpIn, at least for the foreseeable future.
« Last Edit: October 06, 2017, 01:50:57 am by Robert Hodges »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Happy WarpINning!
« Reply #2 on: October 06, 2017, 03:06:16 am »
Any version of OS/2 that can use Warpin, can use YUM/RPM

Andy Willis

  • Sr. Member
  • ****
  • Posts: 292
  • Karma: +7/-0
    • View Profile
Re: Happy WarpINning!
« Reply #3 on: October 06, 2017, 05:06:55 pm »
While all versions of OS/2 in use can use WarpIn, not all of them can use the YUM/Repository feature that is so far exclusive to ArcaOS, which itself will still support WarpIn just fine.

A point of clarification... Yum repository feature is far from exclusive to ArcaOS.  Arca Noae does have subscription only repositories but Netlabs hosts the original repositories which contains most of the applications that are distributed via rpm/yum for OS/2 and the Arca Noae channels being much narrower in scope.  Arca Noae also has open repositories as well which are available without subscription.
There are advantages and disadvantages to both Warpin and rpm/yum.  Though, rpm/yum does offer a way to take on the advantages of Warpin because it is possible to wrap a wpi into an rpm so that the warpin package is installed by yum/rpm.   As you state, Warpin does work in ArcaOS, in fact Arca Noae is working on adding Warpin support into ANPM (the GUI for yum) with the intent to eventually have the ability to pull a wpi from a repository.

Andy Willis

  • Sr. Member
  • ****
  • Posts: 292
  • Karma: +7/-0
    • View Profile
Re: Happy WarpINning!
« Reply #4 on: October 06, 2017, 05:18:05 pm »
WarpIN is very popular installer for warp-like OS-ses.

Many software developers distribute their products in WarpIN format. But many developers do not use all the features of the installer, as well as being make a errors in the descriptions of the packages. As an example I will give diff of wis script of the lSwitcher(v2.8.1) archive: See diff

Hardcoded paths(to \ECS\... of course), errors in "<PCK>"'s, don't use "<GROUP>" for localisations and what annoying me biggest ... XWorkplace X(e)Center plugin does not distribute as separate package. They offer to put it the hands  :-\ , as in the good old days, when the software was distributed in ZIP format.

No, it is not our method! ;) So, on court of the community proposed a project "WarpIN-Scripts-and-tools".
In this, active development package:

In plans:
  • WPI distribution of QS LDR(with backup feature of original IBM OS2LDR), and script for repack developer's zip distrib.
  • WPI distribution of OS/4 "Phoenix" kernels(with the function of automatic addition of the installed kernel to the boot menu and the ability to simultaneously install different versions of the kernels, and script for repack developer's zip of course).
  • Continue adding to the database corrected WIS scripts of popular products. If you have such products, you can send me their scripts by e-mail (oxyd76 (at) gmail (dot) com) (and a direct link to download wpi of course!) with Subject: WarpIN Or join me on the GitHub! WarpIN it's easy! ;-)

Disqus?

The diff is incomplete as it stands, it checks for eCS but not ArcaOS but a ticket in the lswitcher trac:
http://trac.netlabs.org/lswitcher/report/1
would go a long way towards getting the project updated.
Your project to help build WPIs is admirable.  The dates in github show 11 months old.  lswitcher 2.9 will probably be released in the not too distant future, but not sure if there will be time to incorporate changes before the release or not for the wpi at this point.

Highwinder

  • Guest
Re: Happy WarpINning!
« Reply #5 on: November 28, 2017, 06:15:18 pm »
I'm just a VB developer, and like others, have re-discovered OS/2 Warp (ArcaOS and ECS) for hobby purposes.  Would LOVE to develop for OS/2, but quite honestly, the installer tools are just as complex as learning any of the horrible dev tools, especially after being spoiled rotten with Visual Studio and InstallShield.

Willing to give VX-REXX a try after I get REXX into my head (never used it before).  But that's only if I decide that using VB3 Pro or IBM's VisualAge for BASIC for OS/2.  VABASIC, particularly the stabilized v1.2, is actually a lot more amazing than people seem to be willing to give it credit for.

I have had a lot of respect for the WarpIn project over the years, particularly out of pure shock that no real InstallShield equivalent was ever produced for OS/2.  Warp3 was released in the Windows 95 days, and I would have thought Warp4 would have added decent installer support to follow suit.  I find it rather sad that we have to pick the bones of linux (which I can't stand for 100 different reasons) to breathe new life into OS/2.

ak120

  • Guest
Re: Happy WarpINning!
« Reply #6 on: November 28, 2017, 10:30:31 pm »
I have had a lot of respect for the WarpIn project over the years, particularly out of pure shock that no real InstallShield equivalent was ever produced for OS/2.
Who needs an equivalent when the original is available? Stirling Group's InstallShield for OS/2 was sold since 1992. Even IBM used it for some products.

Neil Waldhauer

  • Hero Member
  • *****
  • Posts: 1024
  • Karma: +24/-0
    • View Profile
    • Blonde Guy
Re: Happy WarpINning!
« Reply #7 on: November 29, 2017, 04:56:44 pm »
I have had a lot of respect for the WarpIn project over the years, particularly out of pure shock that no real InstallShield equivalent was ever produced for OS/2.
Who needs an equivalent when the original is available? Stirling Group's InstallShield for OS/2 was sold since 1992. Even IBM used it for some products.

I've used both, but WarpIN is a lot better.
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

Alfredo Fernández Díaz

  • Jr. Member
  • **
  • Posts: 55
  • Karma: +0/-0
    • View Profile
Re: Happy WarpINning!
« Reply #8 on: November 29, 2017, 06:48:54 pm »
OK, let's see how late I am for this party...

I started a somewhat similar, but bigger, and in some ways more ambitious project called 'WPI-Distro' ages ago (last updated in 2004), it was even hosted in an earlier incarnation of os2world.com. The project went into deep freeze due to nearly-zero feedback after I stopped deploying new OS/2 systems (mind you, I got some very positive feedback and encouragement from a few enthusiasts, but it simply wasn't enough to keep me pushing it any further).

I still have everything in a top-level directory of my data drive. From the old website:
----8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<----
The power of self-contained, non-compulsory,  hierarchic installations.

Hierarchic installations:

Installations of many packages are meant to be as tidy as possible, making packages re-use information from others higher in the hierarchy: if you install a 'base' package for some package group, it will establish a base installation directory and a base folder in the Desktop folder where all files and program objects of its descendent packages will be put or created by default, respectively. Similar or complementary applications/packages are grouped together likes this from 'parent' packages to ease organization. This categorization can be more obviously useful for programs like system utilities or tools, grouping games or archivers, etc. Still, you may find it unnecessary to have, say, a directory and Desktop folder for 'Office suites', and then under them the directory and folder of the only office suite you want to use. What then? Keep on reading:

Non-compulsory

The point is, you may not like this hierarchical organization at all, or that package B is defined as a child of package A and therefore is going to be installed to xxx. Not a problem. You are NOT forced to install files to a specific path
 or keep objects in a certain folder. We even have anticipated two solutions for this problem of yours without making you go somewhere else:

 1. If you don't like package B being defined as a child of A, just install it anywhere you like to and move the objects to where you like. In future updates of package B, its components will be placed exactly where you specified. Of course, you will be generally allowed to install to / have objects created in different locations on a per-package basis (defaults are established for all descendent packages of A, but each of them can still ignore them).
 2. You still don't need/want all this 'hierarchical crap'. Keep on reading:

Self-contained:

Each package is self-contained, so if you don't need (or like) the whole 'tree' business, you don't need to look somewhere else for a different packaging of the same programs. You can install them as their previous (non Wpi-Distro) counterparts; they'll skip altogether any 'ancestor' default settings if you don't install whatever 'ancestors' have been defined for them.

Still, and whenever possible, packages can keep their own independent configuration data while being able to pull information from others so as to cut down as much installation / configuration time as possible. This is especially important for unattended installation of many packages, where you want to cut down both user interaction time and individual package configuration time as an admin.

Each package in the Distro has been carefully crafted to meet the equally important goals of lifting effort from your hands when installing stuff, while at the same time giving you as much freedom as possible in installing that stuff on YOUR computer, so please don't hesitate to report any errors.
----8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<----

So, if you think this might be of interest and still wanna disqus, count me in to discuss ; )

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: Happy WarpINning!
« Reply #9 on: November 30, 2017, 03:18:51 pm »
WarpIN is very popular installer for warp-like OS-ses.

Many software developers distribute their products in WarpIN format. But many developers do not use all the features of the installer, as well as being make a errors in the descriptions of the packages. As an example I will give diff of wis script of the lSwitcher(v2.8.1) archive: See diff

Hardcoded paths(to \ECS\... of course), errors in "<PCK>"'s, don't use "<GROUP>" for localisations and what annoying me biggest ... XWorkplace X(e)Center plugin does not distribute as separate package. They offer to put it the hands  :-\ , as in the good old days, when the software was distributed in ZIP format.

No, it is not our method! ;) So, on court of the community proposed a project "WarpIN-Scripts-and-tools".
In this, active development package:

In plans:
  • WPI distribution of QS LDR(with backup feature of original IBM OS2LDR), and script for repack developer's zip distrib.
  • WPI distribution of OS/4 "Phoenix" kernels(with the function of automatic addition of the installed kernel to the boot menu and the ability to simultaneously install different versions of the kernels, and script for repack developer's zip of course).
  • Continue adding to the database corrected WIS scripts of popular products. If you have such products, you can send me their scripts by e-mail (oxyd76 (at) gmail (dot) com) (and a direct link to download wpi of course!) with Subject: WarpIN Or join me on the GitHub! WarpIN it's easy! ;-)

Disqus?

Hm ...,
1) I see no easy way for an installer framework to prevent the packager to make errors by introducing hard coded paths. It's up to the packager to use macros and the like to allow for variations. That said it is always never a good idea to mark an installation path as FIXED. Simply because that leaves the user no choice to correct the path if desired. I have only used FIXED if things where best placed in \OS2\DLL as that is guaranteed to exist in every OS/2, ECS, AN installation, Same holds true for mandatory paths like \OS2\BOOT for basedev device drivers, \OS2\SYSTEM\TRACE for trace files etc.

2) as to the REXX support in WarpIn, I am undecided. On the one hand you can do in REXX whatever you want, on the other hand, sometimes you'd wish that WarpIn supports some features in a "native" way.
For example, checking if a file exists in some dir:

      <REXX NAME="PrepareInstallation">
         rc = rxFuncAdd('SysLoadFuncs','REXXUTIL','SysLoadFuncs')
         rc = SysLoadFuncs()
         fullName = SysSearchPath('ETC','usb.ids')
         if ('' == fullName) then
         do
            fullName = SysSearchPath('DPATH','usb.ids')
         end
         if ('' == fullName) then
         do
            fullName = SysSearchPath('PATH','usb.ids')
         end
         if ('' == fullName) then
         do
            call WirexxShowMessage 'Error','File "usb.ids" neither found on ETC, nor DPATH nor PATH. Installation cannot continue.',0
            call WirexxCancel
         end

         BootDrive = SysBootDrive();
         rc = SysFileTree(BootDrive'\ecs\dll\usbcalls.dll','stem.','FSO')
         if (0 == stem.0) then
         do
            rc = SysFileTree(BootDrive'\os2\dll\usbcalls.dll','stem.','FSO')           
         end
         if (0 == stem.0) then
         do
            call WirexxShowMessage 'Error','File "usbcalls.dll" neither found in \ecs\dll nor in \os2\dll. Installation cannot continue.',0
            call WirexxCancel
         end
    return 'This will install the WPS class replacement.'
      </REXX>
.... and later in the script ....
   <BODY>
      <PAGE INDEX=1 TYPE="README">
         <TEXT>=("PrepareInstallation")</TEXT>
      ...
     </PAGE>
   </BODY>






3) Be aware that there are subtle bugs in WarpIn when it comes to modification of CONFIG.SYS and restoration of the original CONFIG.SYS entries on package deinstallation. More often than not you do NOT get the result that you would want to see. That's because WarpIn does NOT preserve (in DATABAS.INI) the CONFIG.SYS entries before modification by the script. It only preserves the change syntax that is uses when it modifiies CONFIG.SYS. Unfortunately the change syntax is not "symmetric", that is, the original content cannot always be restored by applying the "reverse" of the modification done.
Example:

      <PCK INDEX=1
         PACKAGEID="Lars Erdmann\SYSENTER-SYSEXIT Ring-0 direct call mechanism\DriverBinary\1\0\0"
         TITLE="Driver and Sym File"
         TARGET="?:\OS2\BOOT" NODESELECT FIXED
         CONFIGSYS="BASEDEV=SYSCALL.SYS | REMOVELINE"
         CONFIGSYS="BASEDEV=SYSCALL.SYS | ADDAFTER(CHKDSK.SYS)"
      >This is the Driver binary and is required
      </PCK>
      <PCK INDEX=2
         PACKAGEID="Lars Erdmann\SYSENTER-SYSEXIT Ring-0 direct call mechanism\DriverTrace\1\0\0"
         TITLE="Driver Trace Formatting File"
         REQUIRES=1
         TARGET="?:\OS2\SYSTEM\TRACE" FIXED
         CONFIGSYS="TRACEBUF=2048 /M=W,Q,NODTI /D=ALL | UNIQUE"
         CONFIGSYS="TRACE=ON | REMOVEPART"
         CONFIGSYS="TRACE=ON 10 | ADDAFTER(TRACEBUF) | UNIQUE"
      >This is the driver trace formatting file (needed to format trace data)
      </PCK>
 
is supposed to set up the "TRACE" keyword in config.sys to exclusively set trace code 10 with the TRACE statement. That works but if you deinstall the package you will NOT get the TRACE line as it existed before this modification was done. I have tried all kinds of different other statements to achieve that but I was never successful.

Given this initial config.sys:

REM TRACE=ON 224,225,226
REM TRACE=ON 227
REM TRACE=ON 227,239
REM TRACE=ON 238
REM TRACE=ON 239
REM TRACE=ON 254
TRACE=ON 255
TRACEBUF=1024 /M=W,NQ,NODTI /D=ALL

installing and deinstalling leads to this:
REM TRACE=ON 224,225,226
REM TRACE=ON 227
REM TRACE=ON 227,239
REM TRACE=ON 238
REM TRACE=ON 239
REM TRACE=ON 254
TRACE= 255;ON
TRACEBUF=1024 /M=W,NQ,NODTI /D=ALL

which leads to invalid syntax and is certainly not expected. Things can get worse if you install yet more packages that modify the same CONFIG.SYS statements.

I like WarpIn. The best thing about it is that you can extract the install script from the package and fix it if you need and put it back in :-)



ak120

  • Guest
Re: Happy WarpINning!
« Reply #10 on: November 30, 2017, 05:05:20 pm »
That said it is always never a good idea to mark an installation path as FIXED. Simply because that leaves the user no choice to correct the path if desired.
I habe to agree.

Quote
I have only used FIXED if things where best placed in \OS2\DLL as that is guaranteed to exist in every OS/2, ECS, AN installation,
At least in the most cases, or dependable on definition of the term "installation". From a standalone DASD perspective it could be anticipated.

Quote
Same holds true for mandatory paths like \OS2\BOOT for basedev device drivers, \OS2\SYSTEM\TRACE for trace files etc.
Here I would treat them optionally. They have never been mandatory but widely spread.

Quote
2) as to the REXX support in WarpIn, I am undecided. On the one hand you can do in REXX whatever you want, on the other hand, sometimes you'd wish that WarpIn supports some features in a "native" way.
For example, checking if a file exists in some dir:

      <REXX NAME="PrepareInstallation">
         rc = rxFuncAdd('SysLoadFuncs','REXXUTIL','SysLoadFuncs')
         rc = SysLoadFuncs()
         fullName = SysSearchPath('ETC','usb.ids')
         if ('' == fullName) then
         do
            fullName = SysSearchPath('DPATH','usb.ids')
I don't see any advantage over installation methods already provided with OS/2. It's easier to use a DDP for this task with much less key-strokes.