From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 12 Mar 2002 04:19:31 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 161 ************************************************** Monday 11 March 2002 Number 161 ************************************************** Subjects for today 1 Re: Make problem : Jun Sawataishi 2 Re: http://unix.os2site.com/ada : DWParsons at t-online.de (Dave Parsons) 3 zlib 1.1.4 : John Poltorak 4 Re: Make problem with Gettext 0.11 : John Poltorak 5 Re: $UNIXROOT - time for a decision : Holger Veit 6 Re: zlib security advisery : Holger Veit 7 Re: $UNIXROOT - time for a decision : Holger Veit 8 Re: $UNIXROOT - time for a decision : Holger Veit 9 Re: $UNIXROOT - time for a decision : Holger Veit 10 WGET v1.8.1 : John Poltorak 11 Re: giflib : John Poltorak 12 Re: zlib security advisery : John Poltorak 13 Re: $UNIXROOT - time for a decision : Andrew Zabolotny" 14 Re: -funroll-loops and _optlink : Andrew Zabolotny" 15 Re: Gettext 0.11 : Andrew Zabolotny" 16 Re: zlib security advisory : csaba.raduly at sophos.com 17 Re: Using DATE for date conversions : John Poltorak 18 Re: zlib security advisory : Holger Veit 19 Re: zlib security advisory : John Poltorak 20 Re: Make problem : Holger Veit 21 Re: zlib security advisory : Holger Veit 22 Re: WGet URL mangling problems : Dave and Natalie" **= Email 1 ==========================** Date: Tue, 12 Mar 2002 01:30:56 +0900 From: Jun Sawataishi Subject: Re: Make problem John P wrote: >> After consideration, I completely agreed with Holger. >> From now on, I rewrite sources: >> When UNIXROOT env. var. is not set or empty, programs will >> say "set UNIXROOT env. var." and terminate. > >I don't think you should do that. If anything is going to check for the >presence of %UNIXROOT% it should be the LIBEMU runtime environment. That >would be the correct place to have any environment checking. It doesn't >make sense for a single program to have such code. "it should be the LIBEMU runtime environment": Oh, you may be right. I will do a case-by-case approach to port OSSs. For example bash: hard coded path is only one /etc/profile In this case, when $UNIXROOT env. var. is absent or $UNIXROOT/etc/profile is not readable, bash will not terminate. groff: several kind of fixed directories are searched for So, program should terminate when UNIXROOT env. var. is empty. No one will use groff from a boot floppy disk. # OS/2 is not a question, it's a solution. # SAWATAISHI Jun # http://www2s.biglobe.ne.jp/~vtgf3mpr/ **= Email 2 ==========================** Date: Tue, 12 Mar 2002 08:28:30 +0100 (CET) From: DWParsons at t-online.de (Dave Parsons) Subject: Re: http://unix.os2site.com/ada On Sat, 9 Mar 2002 11:43:26 +0000, John Poltorak wrote: > > > Can someone get this Ada page refreshed to reflect the updated port of > GNAT to v3.14p? :- > > http://unix.os2site.com/ada > John M. Cooper has been looking after this recently. He emailed me a few weeks back when 3.14 was announced but I haven't heard from him since. Maybe he has ISP problems again. Dave **= Email 3 ==========================** Date: Tue, 12 Mar 2002 09:11:35 +0000 From: John Poltorak Subject: zlib 1.1.4 Because of the problems that have been discovered in ZLIB, an update is now available from:- http://prdownloads.sourceforge.net/libpng/zlib-1.1.4.tar.gz ISTR some time ago discussing the included OS/2 Makefile although I can't remember where it originally came from and what the problem with it was. Can someone claim ownership of the OS/2 port and get the correct makefile included? There are quite a lot of ZLIB 1.1.3 variants for OS/2 around the place. Maybe we could come up with a single version of 1.1.4 which could be built straight from the distributed archive... -- John **= Email 4 ==========================** Date: Tue, 12 Mar 2002 09:26:45 +0000 From: John Poltorak Subject: Re: Make problem with Gettext 0.11 On Mon, Mar 11, 2002 at 10:33:57PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > Now I get:- > > > > [N:\eval\gettext\gettext-0.11\os2]make > > make: $SHELL changed (was `cmd.exe', now `C:\OS2\CMD.EXE') > > make: *** could not duplicate stdout > > . Stop. > > > > Is this to be expected? > > Definitely not. Could you add "-h256" (or any other large number) > to your %EMXOPT% before calling make? I normally have -h1024 set in CONFIG.SYS but just checked and it was missing completely.... I've added it to the environment and it works OK now. > bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Redmond where the Shadows lie. -- John **= Email 5 ==========================** Date: Tue, 12 Mar 2002 09:45:16 +0100 From: Holger Veit Subject: Re: $UNIXROOT - time for a decision On Mon, Mar 11, 2002 at 10:12:05PM +0100, Andreas Buening wrote: [...] > > so I would like to start (maybe "yet another one") discussion about > > it. > > > > 1. On one hand, if we add $UNIXROOT support to (future) libc, it will mean > > that every application will work compiled "out-of-the-box" (at least without > > issues concerning the filesystem incompatibilities). > > Every _Unix_ application that hasn't got any drive letter support yet > but the world is somewhat larger than Unix. Oh, the Unix world is pretty large, and it is currently the world that is still feeding significant software into OS/2: GIMP, XFree86, StarOffice, Mozilla, to name the bigger ones. Software that is natively OS/2, like WarpIn, Odin, etc. is out of the game, because it will likely need another compiler. > Not only the end user. A lot of scripts or programs currently use > Unix tools with drive letters. These would be broken by Unix only > filesystems (Assume a simple installation program that uses unzip: > "unzip f:\install\xyz.zip" will have bad side effects if "f:" > is a CD ROM drive and unzip supports only the Unix file system syntax). If there is a homogeneous file system (i.e. one without the CP/M anachronism of drive letters (which is itself a lousy port of Digital Equipment's concept of devices - see OS-8, RT-11, RSX-11M, TOPS-10/20, and VMS), a user will no longer need to know about drive letters. It is similar to having the whole system on a large C: boot drive, with the addition that also CD-ROMs, network drives and removable disk drives will fit into the same scheme. As you might know during boot phase there are no drive letters at all; the system is bootstrapped from a virtual boot device which exclusively knows about \, and \OS2 directories. This simple situation is later broken by OS2DASD.DMD, and OS2CDROM.DMD that introduce logical names (drive letters) for file system containers (disk drives). Any OS/2 application could happily live on a big C: disk, without seeing or knowing about any A:, B:, D:...Z: letters. So there is no technical issue with an underlying Unix file system; it is IMHO just a block in the human's brains that wants to tell us it would be natural to assign logical drive names to each physical storage unit. > Additionally, for a normal user it would be very hard to memorize > which programs use drive letters and which ones don't > (gnuplot 3.7 does while 3.8 doesn't?). Exactly. And to add more to this bad situation: a chameleon application that might turn into one to know drive letters or not, by toggling a UNIXOS2_FS variable, will greatly contribute to such confusion. The unzip example is misleading: on a single C: disk you don't have any need to specify an "f:\install\xyz.zip"; you can simply use \install\xyz.zip there - everything is C: . I still hear the complaint "But I want to have C:\install and D:\install and E:\install, etc." like with any book that has its own chapter 1. This is again a block in the brain, because effectively the number of "books" on your OS/2 shelf is limited to 26 (typically even much less), and secondly, there is no reason why one needs to loot everything into the top-level directory layer (same ill attitude as with the domain name system where everyone wants to occupy a 2nd level domain under .COM). The length of the path does not count really as an argument - there are shortcuts if one were really concerned. > > There are two approaches to this problem, and both have their pluses and > > minuses: > > > > - One approach is to emulate a "flat" Unix-like filesystem (/bin, /etc, /tmp, > > /usr/bin and so on) on top of the "drive-letter-based" one. This approach is > > used in CygWin, and seems to work nicely except for the 2nd feature mentioned > > above - you can't use "make" separately (say from File Commander/W) because > > File Commander uses Windows filesystem and make uses CygWin's Unix filesystem > > emulation layer. > > In the worst case you need two versions of every tool, one to > keep the unixos2 environment happy, and another to be used from > commandline by hand or by other (non Unix) scripts. The worst case is the one we have now, concerning porting - we have to touch any file in a port to check for drive letter anachronisms, and fix (or rather circumvent) problems in the code. > > - Other approach is to patch every application separately by adding support > > for miscelaneous environment variables such as GNULOCALEDIR, UNIXROOT, ETC, > > TEMP&TMP and such. > > Yes, but the number of additional variables should be reduced to > the absolute minimum, i.e. UNIXROOT and perhaps TMPDIR (which seems > to be some kind of standard from some GNU programs for DOS/Win). ACK. However, we should base a port for OS/2 on an existing DOS version; the latter has usually numerous deficiencies; including even such 8.3 naming conventions, and bypassed security. > > This approach has been more or less successfully used with > > EMX/OS2 but has the disadvantage that it requires to patch every separate > > application and it is hard to maintain the latest version of patched > > applications. The advantage is that the application looks completely "native > > OS/2". > > Yep. > > [proposal] > > > Also it should be made possible to compile applications in some "hardcoded > > mode", e.g. if you write a 100% native OS/2 application you will want the > > UNIXOS2_FS variable to be ignored and the filesystem to work always in > > "native" mode. > > Definitely yes. If your program needs direct access to the Dos* API > to get access to the drive letters (whether it's a command line > tool, an office suite or a wps extension doesn't matter) > then you'd better use another compiler. Taking into account I don't see this constraint. EMX/gcc does quite well with calls to the Dos* API (with the exception of the WPS functionality). However, the Unix API is quite complete, and you normally won't need direct access. > the number of free or commercial C/C++ compilers that are still > under development (btw, is there any but gcc?) I would say that Watcom. > the future versions of gcc/2 must be able to compile every kind > of application, and I mean _every_ (Ok, except 16 bit stuff, but > that's another story). Giving that JdeBP is struggling to get pure 32 bit CMD and utilities working, we should forget about 16 bit apps altogether. Even if you use Dos* in your apps directly, there is no need to fall back to 16 bit apps (there are replacements for Kbd/Mou/Vio) and I/O access can be managed differently (not through an IOPL segment). > Personally, I really wouldn't like to need a filename conversion > function to use e.g. grep from within a REXX script. REXX knows both worlds of drive letters and non-drive letters - it exists on Unix and mainframe platforms - you should just use the provided REXXUTIL functions, and avoid constructing drive paths manually through string functions. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 6 ==========================** Date: Tue, 12 Mar 2002 09:49:25 +0100 From: Holger Veit Subject: Re: zlib security advisery On Mon, Mar 11, 2002 at 11:17:54PM +0000, Dave and Natalie wrote: > Does this apply to OS/2? http://www.linuxsecurity.com/advisories/redhat_advisory-1963.html It is a memory management bug, so it must be fixed. It will probably crash OS/2 applications under the same circumstances as described, but since there is no real security in OS/2 yet, it is ridiculuous to abuse this bug for an exploit. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 7 ==========================** Date: Tue, 12 Mar 2002 10:25:09 +0100 From: Holger Veit Subject: Re: $UNIXROOT - time for a decision On Tue, Mar 12, 2002 at 09:45:16AM +0100, Holger Veit wrote: > On Mon, Mar 11, 2002 at 10:12:05PM +0100, Andreas Buening wrote: [...] > > Yes, but the number of additional variables should be reduced to > > the absolute minimum, i.e. UNIXROOT and perhaps TMPDIR (which seems > > to be some kind of standard from some GNU programs for DOS/Win). > > ACK. However, we should base a port for OS/2 on an existing DOS version; Correction: we should NOT base a port for OS/2 on an existing DOS version; > the latter has usually numerous deficiencies; including even such 8.3 naming > conventions, and bypassed security. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 8 ==========================** Date: Tue, 12 Mar 2002 11:38:03 +0100 From: Holger Veit Subject: Re: $UNIXROOT - time for a decision On Tue, Mar 12, 2002 at 12:32:40PM +0300, Andrew Zabolotny wrote: > On Mon, 11 Mar 2002 14:30:43 +0100, Holger Veit wrote: > > >particularly for the "native" portion: That is: the applications have to > >deal somehow with a drive letter in the pathname. Almost no app from Unix > >(unless it has been already written portably) does this; typical case of > >code, already mentioned several time is: > > if (path[0]=='/') { > > ... path is absolute > > } else { > > ... path is relative > > } > Yes, I've seen lots of such "code" :) We can either leave the responsability > for running such "don't know about drive letters" programs in > UNIXOS2_FS=native mode on the user (e.g. "you know what to expect"), or > alternatively (if this problem arises too often when using such apps) compile > the application in "hardcoded Unix filesystem mode". The reason I am particularly concerned about exactly this is that XFree86 contains numerous instances of such stuff. So this would nail XFree86 down to "hardcoded Unix filesystem mode" which would be probably the right way, but I expect then endless discussions and complaints "why doesn't X11 allow UNIXOS2?FS=native or =os2 - see: GREP also allow this!" I doubt that such flexibility will really pay off - giving flexibility to a usership who wants fun by the click on a WPI icon to get everything installed correctly will lead to the great confusion that X won't work together with Y - the have just messed up their configuration incompatibly. Increased flexibilty, be it UNIXOS2_FS semantics or CONFIG.SYS/non-CONFIG.SYS environment settings, even EMXFLAGS is poweruser (a)ware only. I prefer to keep things simple. > >You cannot deal with that in libc, because libc does not know what the > >application does with the path. > Sure. But 90% even of "hardcore Unix" applications don't really care about > whether the path is relative or absolute, thus will work in most cases with > OS/2 paths without problems. And of course getcwd() will return just the Absolute vs relative path hacks are one aspect only, I have just taken out as an example. Many Unix apps combine paths from components, like in sprintf(filename,"%s/%s",dirpart,filepart); fd = fopen(filename,"r"); It is again up to the porter to ensure that 'dirpart' works correctly with drive letters as well as with backslashes (XFILESEARCHPATH and regexp rules come to mind). > directory, without drive letter (like in EMX right now). For example, I'm > almost sure GNU Make will work in either filesystem mode without any changes, > disregarding the fact that it does a lot of filesystem work. GNU software is not my primary concern - Unix software is. > >You can have libc translate a "c:\foo" into "/c/foo" (this is your > >UNIXOS2_FS=unix), and we could make this even more flexible easily > I think that the filesystem filter will do the initial translation of current > working directory, PATH and possibly other environment variables and so on > (maybe this could be done by some simple startup script? not shell script I > mean, something simple that can be parsed and executed by libc "fsunix" > filesystem filter). Yes. > >by making the translation "C:" -> "/c" variable - this is an emulation of the > >mount(2) syscall (and you need such kind of flexibility even to get chroot(2) > >correctly done). Also UNIXOS2_FS=os2 is doable, however, we have to take > >old Unix apps into account that themselves rely on TMP/TEMP/ETC variables > >to be set; > So what? If a Unix app queries the TMP environment variable, it will use it > as-is (instead of emulating /tmp->$TMP in libc), and it is not a problem for > us, is it? In fs=os2 mode we can address temporary directory by either /tmp > (which is translated inside libc) or directly by prepending $TMP, which is > okay. The difficulty is to decide which TMP applies: the one set in CONFIG.SYS, the one in /etc/unixos2.conf, or the one set immediately through the shell before the command is started (and here it depends on whether the shell is CMD.EXE or a UnixOS/2 aware Unix shell). Think about potential pitfalls for a while... It is not so simple. > >So: UNIXOS2_FS=unix and UNIXOS2_FS=os2: no real concerns, but > >UNIXOS2_FS=native will require again the same efforts for porting we now > >have to do. > The "native" mode is mean just for 100% OS/2-compatible applications, that's > it. If you run bash or squid or whatever in the "native" mode, you should be > either 100% sure it never will access Unix-like directories when run, or be > 100% sure that the respective adjustments has been made to the code. This > could be even mentioned in the port documentation, e.g. "this port of Squid > can run in either UNIXOS2_FS=unix or UNIXOS2_FS=os2 modes, but won't work with > UNIXOS2_FS=native". Please tell this the "Click-On-WPI" users. > >If it were just a matter of static linking, we could get away with some > >"native" GREP or "native" MAKE (but then you also have the PATH problem - I > That's why I've proposed the default mode to be "os2" and not "native". In > this mode we get a reasonable mapping for most often accessed Unix > directories, and most Unix programs won't have problems in this mode. However, > if there will be applications which never works in os2 or native mode, they > can be hardcoded (during compilation) to use unix mode. > > >can easily imagine a situation where the wrong MAKE will be called with the > >right GCC (or vice versa) - a matter of name space, not of wrapper scripts), > That's why I want to have just one Make which can operate in several different > modes - depending of my current environment. Which of the UnixOS/2 utilities won't be used dual-mode by some individual? The trivial "hello-world" apps are not my problem, and are no problem for anyone to port - the ugly ones with "path[0]=='/'" etc. are the real problems. What you are going to end up is the status quo we have now: you have to touch everything because anything can and will be used inside and outside UnixOS/2 environment. > >but if you want to make the behaviour dynamically changeable, you'll need > >source code changes in the application (beyond those GNUCONFDIR or GNUDOCDIR > >variables that some apps already recognize), which should have been avoided > >with the whole UNIXROOT idea. > Well, my idea is to have 100% Unix filesystem compatibility in UNIXOS2_FS=unix > mode (e.g. no sourcecode changes needed at all), the other two modes are for > either apps that don't analyze filenames at all, or need just some > minimalistic Unix filesystem (e.g. /tmp and /etc). 90% of Unix apps are of > such kind. Which 90% of what are you talking about? 90% of the GNU utilities that have already been ported to DOS/djgpp or DOS/EMX? The Unix world is much larger. Just a simple example: Thought I'd copy 'ci', 'co' and 'rcsdiff' from some Linux host to another where the RCS package was not installed. 'ci' and 'co' work fine in my $HOME/bin, but rcsdiff has '/usr/bin/co' hardcoded. Nice feature, if you encounter it even on a native Unix. There be more dragons out. > In fact, the "native" mode was intended for those who develop 100% native OS/2 > code. They don't need /tmp or /etc, they use getenv() instead. They know what They rather use DosScanEnv then, and run into multiple troubles: which TMP is the real TMP? > drive letters are for. They use OS/2-specific libc extensions for OS2-specific > things. Such people could compile applications in "hardcoded native" > filesystem mode, but alternatively such application could support the "unix" > and "os2" modes (through environment) to allow working in mixed environments > (e.g. running some os2-specific tool from pure Unix makefiles with Unix > filenames as arguments). If I'd write a native OS/2 application - I agree with Andreas on this issue - I'd likely use a native compiler, but at least I excessively call Dos* API calls as they are more appropriate than high-level Unix functions. But this discussion is on Unix porting to OS/2 primarily, and if at all, to a minor degree writing native OS/2 apps with gcc. You can do the latter with gcc, but you have to play its (the Unix) game then more or less. Solve the UnixOS/2 problem first, before doing native coders a benefit which they maybe thanks to alternatives like VAC++ or Watcom never appreciate. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 9 ==========================** Date: Tue, 12 Mar 2002 11:38:03 +0100 From: Holger Veit Subject: Re: $UNIXROOT - time for a decision On Tue, Mar 12, 2002 at 12:32:40PM +0300, Andrew Zabolotny wrote: > On Mon, 11 Mar 2002 14:30:43 +0100, Holger Veit wrote: > > >particularly for the "native" portion: That is: the applications have to > >deal somehow with a drive letter in the pathname. Almost no app from Unix > >(unless it has been already written portably) does this; typical case of > >code, already mentioned several time is: > > if (path[0]=='/') { > > ... path is absolute > > } else { > > ... path is relative > > } > Yes, I've seen lots of such "code" :) We can either leave the responsability > for running such "don't know about drive letters" programs in > UNIXOS2_FS=native mode on the user (e.g. "you know what to expect"), or > alternatively (if this problem arises too often when using such apps) compile > the application in "hardcoded Unix filesystem mode". The reason I am particularly concerned about exactly this is that XFree86 contains numerous instances of such stuff. So this would nail XFree86 down to "hardcoded Unix filesystem mode" which would be probably the right way, but I expect then endless discussions and complaints "why doesn't X11 allow UNIXOS2?FS=native or =os2 - see: GREP also allow this!" I doubt that such flexibility will really pay off - giving flexibility to a usership who wants fun by the click on a WPI icon to get everything installed correctly will lead to the great confusion that X won't work together with Y - the have just messed up their configuration incompatibly. Increased flexibilty, be it UNIXOS2_FS semantics or CONFIG.SYS/non-CONFIG.SYS environment settings, even EMXFLAGS is poweruser (a)ware only. I prefer to keep things simple. > >You cannot deal with that in libc, because libc does not know what the > >application does with the path. > Sure. But 90% even of "hardcore Unix" applications don't really care about > whether the path is relative or absolute, thus will work in most cases with > OS/2 paths without problems. And of course getcwd() will return just the Absolute vs relative path hacks are one aspect only, I have just taken out as an example. Many Unix apps combine paths from components, like in sprintf(filename,"%s/%s",dirpart,filepart); fd = fopen(filename,"r"); It is again up to the porter to ensure that 'dirpart' works correctly with drive letters as well as with backslashes (XFILESEARCHPATH and regexp rules come to mind). > directory, without drive letter (like in EMX right now). For example, I'm > almost sure GNU Make will work in either filesystem mode without any changes, > disregarding the fact that it does a lot of filesystem work. GNU software is not my primary concern - Unix software is. > >You can have libc translate a "c:\foo" into "/c/foo" (this is your > >UNIXOS2_FS=unix), and we could make this even more flexible easily > I think that the filesystem filter will do the initial translation of current > working directory, PATH and possibly other environment variables and so on > (maybe this could be done by some simple startup script? not shell script I > mean, something simple that can be parsed and executed by libc "fsunix" > filesystem filter). Yes. > >by making the translation "C:" -> "/c" variable - this is an emulation of the > >mount(2) syscall (and you need such kind of flexibility even to get chroot(2) > >correctly done). Also UNIXOS2_FS=os2 is doable, however, we have to take > >old Unix apps into account that themselves rely on TMP/TEMP/ETC variables > >to be set; > So what? If a Unix app queries the TMP environment variable, it will use it > as-is (instead of emulating /tmp->$TMP in libc), and it is not a problem for > us, is it? In fs=os2 mode we can address temporary directory by either /tmp > (which is translated inside libc) or directly by prepending $TMP, which is > okay. The difficulty is to decide which TMP applies: the one set in CONFIG.SYS, the one in /etc/unixos2.conf, or the one set immediately through the shell before the command is started (and here it depends on whether the shell is CMD.EXE or a UnixOS/2 aware Unix shell). Think about potential pitfalls for a while... It is not so simple. > >So: UNIXOS2_FS=unix and UNIXOS2_FS=os2: no real concerns, but > >UNIXOS2_FS=native will require again the same efforts for porting we now > >have to do. > The "native" mode is mean just for 100% OS/2-compatible applications, that's > it. If you run bash or squid or whatever in the "native" mode, you should be > either 100% sure it never will access Unix-like directories when run, or be > 100% sure that the respective adjustments has been made to the code. This > could be even mentioned in the port documentation, e.g. "this port of Squid > can run in either UNIXOS2_FS=unix or UNIXOS2_FS=os2 modes, but won't work with > UNIXOS2_FS=native". Please tell this the "Click-On-WPI" users. > >If it were just a matter of static linking, we could get away with some > >"native" GREP or "native" MAKE (but then you also have the PATH problem - I > That's why I've proposed the default mode to be "os2" and not "native". In > this mode we get a reasonable mapping for most often accessed Unix > directories, and most Unix programs won't have problems in this mode. However, > if there will be applications which never works in os2 or native mode, they > can be hardcoded (during compilation) to use unix mode. > > >can easily imagine a situation where the wrong MAKE will be called with the > >right GCC (or vice versa) - a matter of name space, not of wrapper scripts), > That's why I want to have just one Make which can operate in several different > modes - depending of my current environment. Which of the UnixOS/2 utilities won't be used dual-mode by some individual? The trivial "hello-world" apps are not my problem, and are no problem for anyone to port - the ugly ones with "path[0]=='/'" etc. are the real problems. What you are going to end up is the status quo we have now: you have to touch everything because anything can and will be used inside and outside UnixOS/2 environment. > >but if you want to make the behaviour dynamically changeable, you'll need > >source code changes in the application (beyond those GNUCONFDIR or GNUDOCDIR > >variables that some apps already recognize), which should have been avoided > >with the whole UNIXROOT idea. > Well, my idea is to have 100% Unix filesystem compatibility in UNIXOS2_FS=unix > mode (e.g. no sourcecode changes needed at all), the other two modes are for > either apps that don't analyze filenames at all, or need just some > minimalistic Unix filesystem (e.g. /tmp and /etc). 90% of Unix apps are of > such kind. Which 90% of what are you talking about? 90% of the GNU utilities that have already been ported to DOS/djgpp or DOS/EMX? The Unix world is much larger. Just a simple example: Thought I'd copy 'ci', 'co' and 'rcsdiff' from some Linux host to another where the RCS package was not installed. 'ci' and 'co' work fine in my $HOME/bin, but rcsdiff has '/usr/bin/co' hardcoded. Nice feature, if you encounter it even on a native Unix. There be more dragons out. > In fact, the "native" mode was intended for those who develop 100% native OS/2 > code. They don't need /tmp or /etc, they use getenv() instead. They know what They rather use DosScanEnv then, and run into multiple troubles: which TMP is the real TMP? > drive letters are for. They use OS/2-specific libc extensions for OS2-specific > things. Such people could compile applications in "hardcoded native" > filesystem mode, but alternatively such application could support the "unix" > and "os2" modes (through environment) to allow working in mixed environments > (e.g. running some os2-specific tool from pure Unix makefiles with Unix > filenames as arguments). If I'd write a native OS/2 application - I agree with Andreas on this issue - I'd likely use a native compiler, but at least I excessively call Dos* API calls as they are more appropriate than high-level Unix functions. But this discussion is on Unix porting to OS/2 primarily, and if at all, to a minor degree writing native OS/2 apps with gcc. You can do the latter with gcc, but you have to play its (the Unix) game then more or less. Solve the UnixOS/2 problem first, before doing native coders a benefit which they maybe thanks to alternatives like VAC++ or Watcom never appreciate. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 10 ==========================** Date: Tue, 12 Mar 2002 11:57:11 +0000 From: John Poltorak Subject: WGET v1.8.1 There a copy of WGET v1.8.1 built with IBM's VAC available from:- http://hobbes.nmsu.edu/pub//os2/apps/internet/mirror/wget181-os2-bin-vac.zip -- John **= Email 11 ==========================** Date: Tue, 12 Mar 2002 12:07:05 +0000 From: John Poltorak Subject: Re: giflib On Sat, Mar 09, 2002 at 12:09:44PM +0000, Dave and Natalie wrote: > Has anyone ported giflib (ftp://sunsite.unc.edu/pub/Linux/libs/giflib/giflib-4.1.0.tar.gz) ideally with dll lib and headers? GIFLIB sounds like the sort of thing we ought to have have in UnixOS/2 since we already have JPEG6, LIBPNG and LIBTIFF which are based on the Slackware packages, but there doesn't seem to be a package for GIF files in the distro. If anyone is familiar with Slackware can you see a package for providing GIF support? > Dave -- John **= Email 12 ==========================** Date: Tue, 12 Mar 2002 12:20:08 +0000 From: John Poltorak Subject: Re: zlib security advisery On Tue, Mar 12, 2002 at 09:49:25AM +0100, Holger Veit wrote: > On Mon, Mar 11, 2002 at 11:17:54PM +0000, Dave and Natalie wrote: > > Does this apply to OS/2? http://www.linuxsecurity.com/advisories/redhat_advisory-1963.html > > It is a memory management bug, so it must be fixed. It will probably crash OS/2 applications > under the same circumstances as described, How easy is it to reproduce the problem? I've tried to build v1.1.4 and would like to see if it does fix the bug. > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 13 ==========================** Date: Tue, 12 Mar 2002 12:32:40 +0300 From: "Andrew Zabolotny" Subject: Re: $UNIXROOT - time for a decision On Mon, 11 Mar 2002 14:30:43 +0100, Holger Veit wrote: >particularly for the "native" portion: That is: the applications have to >deal somehow with a drive letter in the pathname. Almost no app from Unix >(unless it has been already written portably) does this; typical case of >code, already mentioned several time is: > if (path[0]=='/') { > ... path is absolute > } else { > ... path is relative > } Yes, I've seen lots of such "code" :) We can either leave the responsability for running such "don't know about drive letters" programs in UNIXOS2_FS=native mode on the user (e.g. "you know what to expect"), or alternatively (if this problem arises too often when using such apps) compile the application in "hardcoded Unix filesystem mode". >You cannot deal with that in libc, because libc does not know what the >application does with the path. Sure. But 90% even of "hardcore Unix" applications don't really care about whether the path is relative or absolute, thus will work in most cases with OS/2 paths without problems. And of course getcwd() will return just the directory, without drive letter (like in EMX right now). For example, I'm almost sure GNU Make will work in either filesystem mode without any changes, disregarding the fact that it does a lot of filesystem work. >You can have libc translate a "c:\foo" into "/c/foo" (this is your >UNIXOS2_FS=unix), and we could make this even more flexible easily I think that the filesystem filter will do the initial translation of current working directory, PATH and possibly other environment variables and so on (maybe this could be done by some simple startup script? not shell script I mean, something simple that can be parsed and executed by libc "fsunix" filesystem filter). >by making the translation "C:" -> "/c" variable - this is an emulation of the >mount(2) syscall (and you need such kind of flexibility even to get chroot(2) >correctly done). Also UNIXOS2_FS=os2 is doable, however, we have to take >old Unix apps into account that themselves rely on TMP/TEMP/ETC variables >to be set; So what? If a Unix app queries the TMP environment variable, it will use it as-is (instead of emulating /tmp->$TMP in libc), and it is not a problem for us, is it? In fs=os2 mode we can address temporary directory by either /tmp (which is translated inside libc) or directly by prepending $TMP, which is okay. >So: UNIXOS2_FS=unix and UNIXOS2_FS=os2: no real concerns, but >UNIXOS2_FS=native will require again the same efforts for porting we now >have to do. The "native" mode is mean just for 100% OS/2-compatible applications, that's it. If you run bash or squid or whatever in the "native" mode, you should be either 100% sure it never will access Unix-like directories when run, or be 100% sure that the respective adjustments has been made to the code. This could be even mentioned in the port documentation, e.g. "this port of Squid can run in either UNIXOS2_FS=unix or UNIXOS2_FS=os2 modes, but won't work with UNIXOS2_FS=native". >If it were just a matter of static linking, we could get away with some >"native" GREP or "native" MAKE (but then you also have the PATH problem - I That's why I've proposed the default mode to be "os2" and not "native". In this mode we get a reasonable mapping for most often accessed Unix directories, and most Unix programs won't have problems in this mode. However, if there will be applications which never works in os2 or native mode, they can be hardcoded (during compilation) to use unix mode. >can easily imagine a situation where the wrong MAKE will be called with the >right GCC (or vice versa) - a matter of name space, not of wrapper scripts), That's why I want to have just one Make which can operate in several different modes - depending of my current environment. >but if you want to make the behaviour dynamically changeable, you'll need >source code changes in the application (beyond those GNUCONFDIR or GNUDOCDIR >variables that some apps already recognize), which should have been avoided >with the whole UNIXROOT idea. Well, my idea is to have 100% Unix filesystem compatibility in UNIXOS2_FS=unix mode (e.g. no sourcecode changes needed at all), the other two modes are for either apps that don't analyze filenames at all, or need just some minimalistic Unix filesystem (e.g. /tmp and /etc). 90% of Unix apps are of such kind. In fact, the "native" mode was intended for those who develop 100% native OS/2 code. They don't need /tmp or /etc, they use getenv() instead. They know what drive letters are for. They use OS/2-specific libc extensions for OS2-specific things. Such people could compile applications in "hardcoded native" filesystem mode, but alternatively such application could support the "unix" and "os2" modes (through environment) to allow working in mixed environments (e.g. running some os2-specific tool from pure Unix makefiles with Unix filenames as arguments). Greetings, _\ndy **= Email 14 ==========================** Date: Tue, 12 Mar 2002 12:40:25 +0300 From: "Andrew Zabolotny" Subject: Re: -funroll-loops and _optlink On Mon, 11 Mar 2002 12:45:49 -0500, Henry Sobotka wrote: >> Please understand that I did not implemented _optlink myself. I just have >> adapted EM's code from gcc 2.8.1 to gcc 3.0.3. It is absolutely same >> functionality as in gcc 2.8.1 - _limited_ compatibility with _Optlink. With >> the ongoing move to ELF I don't see much sense in putting much work into it >> (am I wrong?). >Could you please add a note to that effect to the docs for the sake of >anyone who downloads 3.0.3 and hasn't seen this thread? I will add a quote from EM's docs that comes with gcc 2.8.1 and some my comments. >As for speed gains, they only materialize where the callee immediately uses >the values loaded into the registers by the caller. When speed is so crucial people uses inline functions. A inline function gives more gain than optlink; regarding code size - optlink gives some speed increase only on small functions (often called from, say, a loop), large functions will "swallow" any positive effect. If you mark that function as inline, the effect will be much more pronounced - not only the parameters will be passed in the registers, they will be used just in the registers where they were before the call (and won't have to be moved according to optlink specification). And you get rid of the call/return sequence, which is relatively slow per se. Greetings, _\ndy **= Email 15 ==========================** Date: Tue, 12 Mar 2002 12:46:12 +0300 From: "Andrew Zabolotny" Subject: Re: Gettext 0.11 On Mon, 11 Mar 2002 22:12:18 +0100, Andreas Buening wrote: >> I see some people is trying to compile Gettext 0.11 on OS/2. >Why did you use a Makefile at all? Okay, configure is quite >slow but it has some other advantages. (Yes, I've read your >comments within that Makefile.) Well, then you know what I will say :-) The main reason is that I _dislike_ configure. Hell, I *hate* it :-) If I would summarize the number of hours I've spent in fights with this excellent piece of shit, it would equal the summary time I've spent on all other projects. Greetings, _\ndy **= Email 16 ==========================** Date: Tue, 12 Mar 2002 13:56:28 +0000 From: csaba.raduly at sophos.com Subject: Re: zlib security advisory On 12/03/2002 12:20:08 owner-os2-unix wrote: >On Tue, Mar 12, 2002 at 09:49:25AM +0100, Holger Veit wrote: >> On Mon, Mar 11, 2002 at 11:17:54PM +0000, Dave and Natalie wrote: >> > Does this apply to OS/2? >http://www.linuxsecurity.com/advisories/redhat_advisory-1963.html >> >> It is a memory management bug, so it must be fixed. It will probably crash >> OS/2 applications >> under the same circumstances as described, > >How easy is it to reproduce the problem? > You'll probably need to get your hands on one of those invalid PNG (or other zlib-compressed) files. One of the advisory sites might contain a link to an example file. -- 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 17 ==========================** Date: Tue, 12 Mar 2002 16:12:32 +0000 From: John Poltorak Subject: Re: Using DATE for date conversions On Mon, Feb 11, 2002 at 01:21:51PM +0000, John Poltorak wrote: > The GNU DATE utility has a large array of formatting options, but I can't > tell if it will convert between formats... > > There is the option '-d':- > > -d, --date=STRING display time described by STRING, not `now' > > and there is a FORMAT option %s:- > > %s seconds since 00:00:00, Jan 1, 1970 (a GNU extension) > > > However, the FORMAT option appears to be related to the output. Is there > any way I could use STRING where its value is the second number since 1/1/70? In case anyone is interested I just been shown this really neat trick:- date -d "1970-01-01 1015949182 sec" -- John **= Email 18 ==========================** Date: Tue, 12 Mar 2002 16:20:39 +0100 From: Holger Veit Subject: Re: zlib security advisory On Tue, Mar 12, 2002 at 01:56:28PM +0000, csaba.raduly at sophos.com wrote: > > On 12/03/2002 12:20:08 owner-os2-unix wrote: > > >On Tue, Mar 12, 2002 at 09:49:25AM +0100, Holger Veit wrote: > >> On Mon, Mar 11, 2002 at 11:17:54PM +0000, Dave and Natalie wrote: > >> > Does this apply to OS/2? > >http://www.linuxsecurity.com/advisories/redhat_advisory-1963.html > >> > >> It is a memory management bug, so it must be fixed. It will probably > crash > >> OS/2 applications > >> under the same circumstances as described, > > > >How easy is it to reproduce the problem? > > > > You'll probably need to get your hands on one of those invalid PNG > (or other zlib-compressed) files. One of the advisory sites might > contain a link to an example file. Right, but effectively it is irrelevant. The problem is described clearly: same memory free()'d twice under some circumstances; this will definitely have some side effect on OS/2 applications as well for some code, whether a test program might crash or not. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 19 ==========================** Date: Tue, 12 Mar 2002 16:46:47 +0000 From: John Poltorak Subject: Re: zlib security advisory On Tue, Mar 12, 2002 at 04:20:39PM +0100, Holger Veit wrote: > On Tue, Mar 12, 2002 at 01:56:28PM +0000, csaba.raduly at sophos.com wrote: > > > > On 12/03/2002 12:20:08 owner-os2-unix wrote: > > > > >How easy is it to reproduce the problem? > > > > > > > You'll probably need to get your hands on one of those invalid PNG > > (or other zlib-compressed) files. One of the advisory sites might > > contain a link to an example file. > > Right, but effectively it is irrelevant. The problem is described > clearly: same memory free()'d twice under some circumstances; > this will definitely have some side effect on OS/2 applications > as well for some code, whether a test program might crash or not. Sure, but my reason for wanting to reproduce the problem is to see if I've managed to build a fixed program correctly... > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 20 ==========================** Date: Tue, 12 Mar 2002 21:55:39 +0100 From: Holger Veit Subject: Re: Make problem On Tue, Mar 12, 2002 at 01:30:56AM +0900, Jun Sawataishi wrote: [...] > "it should be the LIBEMU runtime environment": Oh, you may be right. > I will do a case-by-case approach to port OSSs. > For example > bash: hard coded path is only one > /etc/profile > In this case, when $UNIXROOT env. var. is absent or > $UNIXROOT/etc/profile is not readable, bash will not terminate. > groff: several kind of fixed directories are searched for > So, program should terminate when UNIXROOT env. var. is empty. > No one will use groff from a boot floppy disk. Hmmm....if bash links against libemu (statically or dynamically doesn't matter) it will require certain functions which are currently bypassed or ignored in the EMX port, notably job control (setsid, set/getpgrp/pgid, set/get(e)uid). These functions will be passed from the libemu library to ix.sys, because they cannot be handled correctly in user code. Thus, ix.sys is definitely in the game whether you ike it or not. And this relies on certain UNIXROOT setting (actually, as a basedev, ix.sys can't do a DosScanEnv to get the environment, but rather expects a command line argument specifying a path for the UNIXROOT value. This should also answer the question how to install a system from a boot CD or floppy - the IX.SYS on the floppy (its current size is about 37K, and we have the option to load a stripped-down version if size is really a restriction) will assume its unix directory tree on the boot media: BASEDEV=IX.SYS /U:/ is sufficient to bootstrap (in the final system this nails down to D:/ if D: were your boot drive). Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 21 ==========================** Date: Tue, 12 Mar 2002 21:58:57 +0100 From: Holger Veit Subject: Re: zlib security advisory On Tue, Mar 12, 2002 at 04:46:47PM +0000, John Poltorak wrote: > On Tue, Mar 12, 2002 at 04:20:39PM +0100, Holger Veit wrote: > > On Tue, Mar 12, 2002 at 01:56:28PM +0000, csaba.raduly at sophos.com wrote: > > > > > > On 12/03/2002 12:20:08 owner-os2-unix wrote: > > > > > > >How easy is it to reproduce the problem? > > > > > > > > > > You'll probably need to get your hands on one of those invalid PNG > > > (or other zlib-compressed) files. One of the advisory sites might > > > contain a link to an example file. > > > > Right, but effectively it is irrelevant. The problem is described > > clearly: same memory free()'d twice under some circumstances; > > this will definitely have some side effect on OS/2 applications > > as well for some code, whether a test program might crash or not. > > Sure, but my reason for wanting to reproduce the problem is to see if I've > managed to build a fixed program correctly... Recently, on the bugtraq mailinglist, the "png_of_doom" that's supposed to trigger the bug has been submitted. But since it results in malloc heap corruption, it is difficult to estimate the side effects that result from it. Anyone to write exploit code for that? Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 22 ==========================** Date: Tue, 12 Mar 2002 22:14:51 -0800 From: "Dave and Natalie" Subject: Re: WGet URL mangling problems On Wed, 13 Mar 2002 05:21:52 +0100 (CET), Christian Hennecke wrote: >When I use WGet to mirror web sites that use encoded unsafe character, >e.g. spaces, I always end up with a local copy that is not browseable. >For instance, a directory "20. Juli 1944" is saved with the filename >"20.%20Juli%201944". Version 1.7 did a translation for some characters, >e.g. %df or á, but used a wrong codepage (probably Latin-1 instead of >OS/2's cp850). The new version 1.8 that is available at Hobbes doesn't >even demangle that URL any more (this is noted in the NEWS file). > >This is really a problem as I don't know any downloading tool that is >also capable of adapting links for a local copy (i.e. from absolute to >relative). > >Any suggestions? > While not a *nix program, you might want to check sslurp (hobbes). It seems to demangle to an absolute address on your harddrive, eg file:///UTILS/sslurp/www.whatever.com/welcome.html. Has a few other neat features such as acting as a simple proxy, both caching and simple filtering. Dave