From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Fri, 1 Feb 2002 04:14:10 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 122 ************************************************** Thursday 31 January 2002 Number 122 ************************************************** Subjects for today 1 Re: XINE : Steve Wendt" 2 Re: XINE : jimmy 3 Re: XINE : jimmy 4 Re: installpkg bin.zip ? : frank schmittroth" 5 Re: installpkg bin.zip ? : John Poltorak 6 Re: XINE : Adrian Gschwend" 7 Re: XINE : Adrian Gschwend" 8 Re: cdio.h : Pete Milne 9 Re: cdio.h : John Poltorak 10 Re: cdio.h : csaba.raduly at sophos.com 11 Re: cdio.h : John Poltorak 12 Re: cdio.h : Holger Veit 13 Re: cdio.h : Holger Veit 14 Re: cdio.h : csaba.raduly at sophos.com 15 Re: installpkg bin.zip ? : John Poltorak 16 Re: installpkg bin.zip ? : Holger Veit **= Email 1 ==========================** Date: Fri, 01 Feb 2002 01:05:11 -0800 (PST) From: "Steve Wendt" Subject: Re: XINE On Fri, 01 Feb 2002 09:44:41 +0100 (CET), Adrian Gschwend wrote: >I doubt that the SDD driver will provide any 2D acceleration >(DIVE/EnDIVE). SciTech does not have the time/money/will to implement DIVE with SDD is pretty fast. Have you tried benchmarks? ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 2 ==========================** Date: Fri, 01 Feb 2002 02:49:06 -0500 From: jimmy Subject: Re: XINE HI John What a great idea! I recently installed Xine and divx4, codecs, binaries etc in Slack and to my great surprise on the very same machine it is actually superior to WinXP Media Player 7.whatever. I have a really great mpeg of Pink Floyd doing "Comfortably Numb" Live at Pompeii whose orig resolution was 320x. In windoze it is good but heavily pixellated in Full Screen mode and the audio/video is not a perfect synch. In Slack using Xine, Full Screen , even my son exclaimed "It looks like TV!" So now I think I will see if I can get it going on OS/2. Interestingly enough, after I installed the updated codecs etc. found on the xine site, my other linux players improved substantially, so my guess is the drivers/decoders are written well and also nVidia is "getting the hang" of accelerated drivers in *nix. In fact, I will be very interested to see if SciTech's video driver can even come close, considering that presently IBM et al do not offer any free drivers that will operate with GeForce chipsets. **= Email 3 ==========================** Date: Fri, 01 Feb 2002 05:18:03 -0500 From: jimmy Subject: Re: XINE --------------916333523F54E480D7B7BFFD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Adrian Certainly I need to make it clear that I in no way meant to disparage the commitment nor quality of Scitech. More to the point I am heartily sorry it is so lonely out there that w/o them we would be stuck indeed. So first ,deserved kudos go out to SciTech. Now on to much more exciting things however, your idea. I am no longer a programmer. At best I write a few cool scripts but Assembly plus 2nd generation Pentiums cured me of that particular learning curve. I had wanted to learn to write device drivers for OS/2. Again, kudos to those who have even attempted to keep up with on-the-metal coding in such a complex environment. However the logic of your idea is very interesting, even a little thrilling. It would seem there would be problems to overcome in such low level hardware calls but my guess is it bears consideration. I sincerely someone with more ability than I looks into this. Best of Luck Jimmy Adrian Gschwend wrote: I had another interesting idea but I'm not sure if this could work: > > SciTech is using a generic driver called Nucleus. XFree86 4.x also has > a generic interface which allows us to use the same display driver > binary on all platforms. I have *no* idea about this binary format but > think about this: > > We write a GRADD-based generic display driver which provides a loader > for the XFree86 4.x format. That means the core-driver itself would be > the same like the one X is using on Linux/OS2/whatever. > I don't know if this is possible, it might be that the binary-format > relies on X, mabe there are a lot of kernel-modules needed which can't > be implemented on OS/2 that easy but I think this idea might be worth a > try. > > If it would work we could have 2D/3D acceleration and support for all > new chipsets from X-friendly companies. > > Does anyone have more know how about the binary format of XFree86 4.x > display drivers? I once tried to find some docu about it but without a > lot of luck so far. > > --------------916333523F54E480D7B7BFFD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Adrian
  Certainly I need to make it clear that I in no way meant to disparage the commitment nor quality of Scitech.  More to the point I am heartily sorry it is so lonely out there that w/o them we would be stuck indeed.  So first ,deserved kudos go out to SciTech.  Now on to much more exciting things however, your idea.
  I am no longer a programmer.  At best I write a few cool scripts but Assembly plus 2nd generation Pentiums cured me of that particular learning curve.  I had wanted to learn to write device drivers for OS/2.  Again, kudos to those who have even attempted to keep up with on-the-metal coding in such a complex environment.  However the logic of your idea is very interesting, even a little thrilling.  It would seem there would be problems to overcome in such low level hardware calls but my guess is it bears consideration.  I sincerely someone with more ability than I looks into this.
Best of Luck
Jimmy

Adrian Gschwend wrote:
I had another interesting idea but I'm not sure if this could work:

 
SciTech is using a generic driver called Nucleus. XFree86 4.x also has
a generic interface which allows us to use the same display driver
binary on all platforms. I have *no* idea about this binary format but
think about this:

We write a GRADD-based generic display driver which provides a loader
for the XFree86 4.x format. That means the core-driver itself would be
the same like the one X is using on Linux/OS2/whatever.
I don't know if this is possible, it might be that the binary-format
relies on X, mabe there are a lot of kernel-modules needed which can't
be implemented on OS/2 that easy but I think this idea might be worth a
try.

If it would work we could have 2D/3D acceleration and support for all
new chipsets from X-friendly companies.

Does anyone have more know how about the binary format of XFree86 4.x
display drivers? I once tried to find some docu about it but without a
lot of luck so far.
 
 

--------------916333523F54E480D7B7BFFD-- **= Email 4 ==========================** Date: Fri, 01 Feb 2002 08:24:39 -0800 (PST) From: "frank schmittroth" Subject: Re: installpkg bin.zip ? On Fri, 1 Feb 2002 09:13:55 +0000, John Poltorak wrote: >> I have been following this maillist for awhile and thought I'd see if I >> could try to install something. I followed the instructions and installed >> ux2_base.zip, successfully it appears. >> > >Thanks for giving it a try and providing feedback. > >Please bear in mind that we are still at a very early stage with UnixOS/2 >packages and their installation. > Understood. >Also the packages are basically ZIP files with embedded paths using the >recommended directory structure so you should be able to simply UNZIP >them. > I guessed that. I thought that installpkg.cmd might work on a simple test as with bin.zip; and it comes very close. One advantage of installpkg, even at this early stage, is that one could remove a package if one wanted to start over. I may spend a bit of time staring at the rexx code, if you think that installpkg/removepkg are likely to be part of a more developed unixos2 system. Frank. ----------------------- Frank Schmittroth franks at owt.com **= Email 5 ==========================** Date: Fri, 1 Feb 2002 09:13:55 +0000 From: John Poltorak Subject: Re: installpkg bin.zip ? On Thu, Jan 31, 2002 at 04:14:50PM -0800, frank schmittroth wrote: > I've done some c progamming, but I'm basically an end user. > > I have been following this maillist for awhile and thought I'd see if I > could try to install something. I followed the instructions and installed > ux2_base.zip, successfully it appears. > > As a next baby step I downloaded the bin.zip package and tried to install > it as follows from the root directory: > > [D:\unixos2]installpkg -s bin.zip > 221 > 419 +++; > REX0014: Error 14 running D:\unixos2\usr\sbin\installpkg.cmd, line 419: > Incomplete DO/SELECT/IF > > It looked to me as if the rexx script, installpkg.cmd, had a missing "end" > statement for a corresponding "do". I added another "end" at line 286, and > the installation apparently created directories and unzipped various programs. > > If I type "which which", for example, it successfully finds which.exe. > > I then tried a simulated remove installation with the following result: > > [D:\unixos2]removepkg -s bin.zip > No such package: d:\unixos2\var\log\packages\bin.zip. Can't remove. > > Either I don't understand what I'm doing (highly likely), or something is wrong. > > Is installpkg a recommended way to install unixos2 packages? Thanks for giving it a try and providing feedback. Please bear in mind that we are still at a very early stage with UnixOS/2 packages and their installation. Installpkg is modelled on SlackWare and its installation and maintenance of packages and the aim is to provide the same functionality in the UnixOS/2 environment, although there may be a few glitches as yet. Also the packages are basically ZIP files with embedded paths using the recommended directory structure so you should be able to simply UNZIP them. Currently there are no additional scripts included with any packages so if any particular environment variable needs setting or any initialisation needs doing this involves a manual process by the user, but in the longer term this will be done automatically via an included install script. > Frank. > > ----------------------- > Frank Schmittroth > franks at owt.com > -- John **= Email 6 ==========================** Date: Fri, 01 Feb 2002 09:44:41 +0100 (CET) From: "Adrian Gschwend" Subject: Re: XINE On Fri, 01 Feb 2002 02:49:06 -0500, jimmy wrote: > So now I think I will see if I can get it going on OS/2. >Interestingly enough, after I installed the updated codecs etc. found on >the xine site, my other linux players improved substantially, so my >guess is the drivers/decoders are written well and also nVidia is >"getting the hang" of accelerated drivers in *nix. In fact, I will be >very interested to see if SciTech's video driver can even come close, >considering that presently IBM et al do not offer any free drivers that >will operate with GeForce chipsets. I doubt that the SDD driver will provide any 2D acceleration (DIVE/EnDIVE). SciTech does not have the time/money/will to implement all the code into their generic drivers. First they would have to add that to the nucleus part and second they would have to implement it in each chipset driver. I had another interesting idea but I'm not sure if this could work: SciTech is using a generic driver called Nucleus. XFree86 4.x also has a generic interface which allows us to use the same display driver binary on all platforms. I have *no* idea about this binary format but think about this: We write a GRADD-based generic display driver which provides a loader for the XFree86 4.x format. That means the core-driver itself would be the same like the one X is using on Linux/OS2/whatever. I don't know if this is possible, it might be that the binary-format relies on X, mabe there are a lot of kernel-modules needed which can't be implemented on OS/2 that easy but I think this idea might be worth a try. If it would work we could have 2D/3D acceleration and support for all new chipsets from X-friendly companies. Does anyone have more know how about the binary format of XFree86 4.x display drivers? I once tried to find some docu about it but without a lot of luck so far. cu Adrian -- Adrian Gschwend at OS/2 Netlabs ICQ: 22419590 ktk at netlabs.org ------- The OS/2 OpenSource Project: http://www.netlabs.org **= Email 7 ==========================** Date: Fri, 01 Feb 2002 10:14:15 +0100 (CET) From: "Adrian Gschwend" Subject: Re: XINE On Fri, 01 Feb 2002 01:05:11 -0800 (PST), Steve Wendt wrote: >>I doubt that the SDD driver will provide any 2D acceleration >>(DIVE/EnDIVE). SciTech does not have the time/money/will to implement > >DIVE with SDD is pretty fast. Have you tried benchmarks? yeah no doubt about that but EnDIVE is still nice to have (well not that important like two years ago). But 3D won't be implemented I guess... For sure I appreciate the work of SDD but in a long term I don't think we get what we want/need. Actually I can't imagine my TP without SDD, I remember the black days before SDD, display driver were a major problems on OS/2. cu Adrian -- Adrian Gschwend at OS/2 Netlabs ICQ: 22419590 ktk at netlabs.org ------- The OS/2 OpenSource Project: http://www.netlabs.org **= Email 8 ==========================** Date: Fri, 01 Feb 2002 10:39:45 +0000 From: Pete Milne Subject: Re: cdio.h John Poltorak wrote: > Has anyone come across a cdio.h ? > > I'd tried to build a program for generating a CDDB ID using:- > > http://family.zawodny.com/jzawodn/c/discid/discid-freebsd-1.3.tar.gz > > but I'm stuck without this header... > > -- > John http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/sys/sys/cdio.h Pete **= Email 9 ==========================** Date: Fri, 1 Feb 2002 11:07:36 +0000 From: John Poltorak Subject: Re: cdio.h On Fri, Feb 01, 2002 at 10:39:45AM +0000, Pete Milne wrote: > > > John Poltorak wrote: > > > Has anyone come across a cdio.h ? > > > > I'd tried to build a program for generating a CDDB ID using:- > > > > http://family.zawodny.com/jzawodn/c/discid/discid-freebsd-1.3.tar.gz > > > > but I'm stuck without this header... > > > > -- > > John > > http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/sys/sys/cdio.h Thanks for the pointer. Somehow I didn't expect it to work. I got:- gcc -o discid discid.c In file included from discid.c:29: c:\emx\include\netdb.h:123: parse error before `int' In file included from discid.c:35: c:\emx\include\sys/cdio.h:15: parse error before `u_int32_t' c:\emx\include\sys/cdio.h:15: warning: no semicolon at end of struct or union c:\emx\include\sys/cdio.h:17: parse error before `}' c:\emx\include\sys/cdio.h:31: field `addr' has incomplete type c:\emx\include\sys/cdio.h:26: duplicate member `addr_type' c:\emx\include\sys/cdio.h:27: duplicate member `control' c:\emx\include\sys/cdio.h:53: duplicate member `addr_type' c:\emx\include\sys/cdio.h:54: duplicate member `control' c:\emx\include\sys/cdio.h:65: duplicate member `mc_valid' c:\emx\include\sys/cdio.h:74: duplicate member `ti_valid' c:\emx\include\sys/cdio.h:92: field `absaddr' has incomplete type c:\emx\include\sys/cdio.h:93: field `reladdr' has incomplete type c:\emx\include\sys/cdio.h:87: duplicate member `addr_type' c:\emx\include\sys/cdio.h:88: duplicate member `control' c:\emx\include\sys/cdio.h:106: duplicate member `mc_valid' c:\emx\include\sys/cdio.h:122: duplicate member `ti_valid' discid.c: In function `read_toc': discid.c:44: storage size of `tocentry' isn't known discid.c:51: `CDIOREADTOCENTRY' undeclared (first use in this function) discid.c:51: (Each undeclared identifier is reported only once discid.c:51: for each function it appears in.) discid.c: In function `main': discid.c:94: warning: return type of `main' is not `int' make: *** [discid] Error 1 Is there anything I can do to correct this? > Pete -- John **= Email 10 ==========================** Date: Fri, 1 Feb 2002 11:41:52 +0000 From: csaba.raduly at sophos.com Subject: Re: cdio.h On 01/02/2002 11:07:36 owner-os2-unix wrote: > >Somehow I didn't expect it to work. I got:- > >gcc -o discid discid.c >In file included from discid.c:29: >c:\emx\include\netdb.h:123: parse error before `int' That's u_long. You need to include *before* netdb.h >In file included from discid.c:35: >c:\emx\include\sys/cdio.h:15: parse error before `u_int32_t' >c:\emx\include\sys/cdio.h:15: warning: no semicolon at end of struct or union >c:\emx\include\sys/cdio.h:17: parse error before `}' >c:\emx\include\sys/cdio.h:31: field `addr' has incomplete type [snip "duplicate member" errors] >discid.c: In function `read_toc': >discid.c:44: storage size of `tocentry' isn't known >discid.c:51: `CDIOREADTOCENTRY' undeclared (first use in this function) That's odd. grep for CDIOREADTOCENTRY (on FreeBSD 4.4) gives: /usr/include/sys/cdio.h:#define CDIOREADTOCENTRYS _IOWR('c',5,struct ioc_read_toc_entry) /usr/include/sys/cdio.h:#define CDIOREADTOCENTRY _IOWR('c',6,struct ioc_read_toc_single_entry) >discid.c:51: (Each undeclared identifier is reported only once >discid.c:51: for each function it appears in.) >discid.c: In function `main': >discid.c:94: warning: return type of `main' is not `int' >make: *** [discid] Error 1 > > Maybe it's an old cdio.h ? -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 11 ==========================** Date: Fri, 1 Feb 2002 12:11:41 +0000 From: John Poltorak Subject: Re: cdio.h On Fri, Feb 01, 2002 at 12:29:33PM +0100, Holger Veit wrote: > On Fri, Feb 01, 2002 at 11:07:36AM +0000, John Poltorak wrote: > > > http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/sys/sys/cdio.h > > > > Thanks for the pointer. > > Oh no!!!!!! Oops... > You have taken a kernel header file from BSD. Even if you can get stuff to > compile somehow (see below) there is essential support missing which is > regularly in a BSD kernel. Don't uncritically import header files > that you "found somewhere on the net" into the code. This won't work. > > discid.c: In function `read_toc': > > discid.c:44: storage size of `tocentry' isn't known > > discid.c:51: `CDIOREADTOCENTRY' undeclared (first use in this function) > > This relates to an IOCTL command which BSD has, but not EMX. Is there any technical reason why not? It is possible to read audio CDs on OS/2, I just can't think of anything which provides source code for deriving CDDB IDs, and this looked to be just what I wanted. > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 12 ==========================** Date: Fri, 1 Feb 2002 12:29:33 +0100 From: Holger Veit Subject: Re: cdio.h On Fri, Feb 01, 2002 at 11:07:36AM +0000, John Poltorak wrote: > On Fri, Feb 01, 2002 at 10:39:45AM +0000, Pete Milne wrote: > > > > > > John Poltorak wrote: > > > > > Has anyone come across a cdio.h ? > > > > > > I'd tried to build a program for generating a CDDB ID using:- > > > > > > http://family.zawodny.com/jzawodn/c/discid/discid-freebsd-1.3.tar.gz > > > > > > but I'm stuck without this header... > > > > > > -- > > > John > > > > http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/sys/sys/cdio.h > > Thanks for the pointer. Oh no!!!!!! You have taken a kernel header file from BSD. Even if you can get stuff to compile somehow (see below) there is essential support missing which is regularly in a BSD kernel. Don't uncritically import header files that you "found somewhere on the net" into the code. This won't work. > Somehow I didn't expect it to work. I got:- > > gcc -o discid discid.c > In file included from discid.c:29: > c:\emx\include\netdb.h:123: parse error before `int' EMX netdb.h needs certain other files included before, like , for instance. Other platforms might require a different header ordering. > In file included from discid.c:35: > c:\emx\include\sys/cdio.h:15: parse error before `u_int32_t' This type is an internal BSD type (effectively the same as unsigned long). > c:\emx\include\sys/cdio.h:15: warning: no semicolon at end of struct or union > c:\emx\include\sys/cdio.h:17: parse error before `}' > c:\emx\include\sys/cdio.h:31: field `addr' has incomplete type > c:\emx\include\sys/cdio.h:26: duplicate member `addr_type' > c:\emx\include\sys/cdio.h:27: duplicate member `control' > c:\emx\include\sys/cdio.h:53: duplicate member `addr_type' > c:\emx\include\sys/cdio.h:54: duplicate member `control' > c:\emx\include\sys/cdio.h:65: duplicate member `mc_valid' > c:\emx\include\sys/cdio.h:74: duplicate member `ti_valid' > c:\emx\include\sys/cdio.h:92: field `absaddr' has incomplete type > c:\emx\include\sys/cdio.h:93: field `reladdr' has incomplete type > c:\emx\include\sys/cdio.h:87: duplicate member `addr_type' > c:\emx\include\sys/cdio.h:88: duplicate member `control' > c:\emx\include\sys/cdio.h:106: duplicate member `mc_valid' > c:\emx\include\sys/cdio.h:122: duplicate member `ti_valid' These are errors resulting from some incorrect declaration (like a missing type u_int32_t) elsewhere. > discid.c: In function `read_toc': > discid.c:44: storage size of `tocentry' isn't known > discid.c:51: `CDIOREADTOCENTRY' undeclared (first use in this function) This relates to an IOCTL command which BSD has, but not EMX. > discid.c:51: (Each undeclared identifier is reported only once > discid.c:51: for each function it appears in.) > discid.c: In function `main': > discid.c:94: warning: return type of `main' is not `int' > make: *** [discid] Error 1 > > > Is there anything I can do to correct this? No. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 13 ==========================** Date: Fri, 1 Feb 2002 13:53:12 +0100 From: Holger Veit Subject: Re: cdio.h On Fri, Feb 01, 2002 at 12:11:41PM +0000, John Poltorak wrote: [...] > > > discid.c: In function `read_toc': > > > discid.c:44: storage size of `tocentry' isn't known > > > discid.c:51: `CDIOREADTOCENTRY' undeclared (first use in this function) > > > > This relates to an IOCTL command which BSD has, but not EMX. > > Is there any technical reason why not? No technical reason, it is just not implemented, or not implemented the way cdio.h excepts the interface. > It is possible to read audio CDs on OS/2, I just can't think of anything > which provides source code for deriving CDDB IDs, and this looked to be > just what I wanted. Check the correspondig DosDevIOCtls for CDs and rewrite the call to read the TOC above. The docs on the CD device should be either in the official IBM toolkit Dos* docs or in the DDK PDDREF.INF. Unix device emulation, as intended in libemu, will do exactly this. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 14 ==========================** Date: Fri, 1 Feb 2002 15:47:14 +0000 From: csaba.raduly at sophos.com Subject: Re: cdio.h On 01/02/2002 12:11:41 John Poltorak wrote: >On Fri, Feb 01, 2002 at 12:29:33PM +0100, Holger Veit wrote: [snip] >> >> This relates to an IOCTL command which BSD has, but not EMX. > >Is there any technical reason why not? > Implementation is left as an exercise for the avid coder :-) -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 15 ==========================** Date: Fri, 1 Feb 2002 17:23:53 +0000 From: John Poltorak Subject: Re: installpkg bin.zip ? On Fri, Feb 01, 2002 at 08:24:39AM -0800, frank schmittroth wrote: > On Fri, 1 Feb 2002 09:13:55 +0000, John Poltorak wrote: > > >Also the packages are basically ZIP files with embedded paths using the > >recommended directory structure so you should be able to simply UNZIP > >them. > > > I guessed that. I thought that installpkg.cmd might work on a simple test as > with bin.zip; and it comes very close. One advantage of installpkg, even > at this early stage, is that one could remove a package if one wanted to > start over. I may spend a bit of time staring at the rexx code, if you think > that installpkg/removepkg are likely to be part of a more developed unixos2 > system. The package management was based on SlackWare and there are no plans to change that. Of course, a GUI front end may evolve if someone wants to develop something. Personally, I'm hoping to be able to use some of the standard SlackWare Dialog screens from SETUP, to install packages now that we have an OS/2 port of Dialog, but that should simply be a front end for InstallPkg. > Frank. > > > ----------------------- > Frank Schmittroth > franks at owt.com > -- John **= Email 16 ==========================** Date: Fri, 1 Feb 2002 21:36:05 +0100 From: Holger Veit Subject: Re: installpkg bin.zip ? On Fri, Feb 01, 2002 at 08:24:39AM -0800, frank schmittroth wrote: [...] > > >Also the packages are basically ZIP files with embedded paths using the > >recommended directory structure so you should be able to simply UNZIP > >them. > > > I guessed that. I thought that installpkg.cmd might work on a simple test as > with bin.zip; and it comes very close. One advantage of installpkg, even Infact, I also thought that :-) > at this early stage, is that one could remove a package if one wanted to > start over. I may spend a bit of time staring at the rexx code, if you think > that installpkg/removepkg are likely to be part of a more developed unixos2 > system. I think so, unless someone suddenly comes with a more powerful solution; Debian deb or FreeBSD ports come to mind. But I think these will need certain parts of a Unix(-like) system already in place to bootstrap - REXX is attractive because it is already present when you are installing OS/2 from scratch (before new listeners to this list bring up WarpIn again - this has been discussed to death: the installpkg/removepkg stuff is supposed to work on (annotated) ZIP files, so you could also lift a system without them: just unpack the ZIPs. If you like to spend some time on the code: your help is greatly appreciated. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection)