ClamAV OS/2

[Mike Luther]

Thoughts please?

Yuri moved the ClamAV for OS/2 to RPM/YUM install and update. Which as I
think I understand the process is a master installation and update tool that
focuses at least on Linux, but is also available for OS/2. However, I don't
have a single computer at this point on LInux. As I think I understand what
was posted to me in my comments on the ClamAV for OS/2 Yuri site, and what I
think I got from visiting the RPM/YUM 'site', installing RPM/YUM takes at
least a SIX Gigabyte hard disk partition to even create! Further, per what I
think I got 'told'. that also ought to be the BOOT partition for the OS/2
computer that is involved in this! In theory, as I think I understand this
process, once the RPM deal is done, YUM is the toolset which is used for the
actual update process. However I have no idea if YUM could be used just by
itself with a 'normal' size OS/2 tool to do the updates and so on. That so a
pile full of completely needed and mission critical service could handle
twenty or more years of data and coordinated service that date back to even
DOS and not larger than 2GB partitions which are perfect for what is needed
and even will be OK for even ten more years into the future. Whatever ...

OK, I posted a question about whether the RPM operation could be burned,
placed on a CD/DVD disk so that one could carry it around to the pile of OS/2
machines and thus create and orchestrate the installed ClamAV for OS/2 and the
YUM update process in the 'normal' little space needed on the native OS/2 file
partition. In essence, I guess, the same 'way' that the .WPI operation did
all this for all the previous time back. I got no answer that I know about as
to this.

OK, can anyone here help teach me more about this, plus guide me toward a
successful replacement for the .WPI version of ClamAV for OS/2 needed?

Yes, I do have a fully paid for operation for PANDA for OS/2 that works VERY
well still for file and disk analysis even with the full daily virus updates.
However, it does require an OS/2 REXX poll of the PANDA OS/2 update site
to pick up your full virus update file each time it is released. Which
involves a full file download of about 24MB per file each time you get that
service. Which I have been using for still years now absolutely well, though
there is no real-time interface to protect you for IP on-line connectivity
such as with Seamonkey or whatever. ClamAV for OS/2 involves only a daily
normally small virus update needed virus signature individual file per event
release. Which is much more practical for folks who have to handle updates on
a daily basis.

And for which I guarantee you folks SHOULD still being doing for even OS/2.

Thanks for any help here.

[Peter Brown]

Hi Mike

Post by Mike Luther
Thoughts please?
Yuri moved the ClamAV for OS/2 to RPM/YUM install and update. Which as I
think I understand the process is a master installation and update tool
that focuses at least on Linux, but is also available for OS/2. However,
I don't have a single computer at this point on LInux. As I think I
understand what was posted to me in my comments on the ClamAV for OS/2
Yuri site, and what I think I got from visiting the RPM/YUM 'site',
installing RPM/YUM takes at least a SIX Gigabyte hard disk partition to
even create! Further, per what I think I got 'told'. that also ought to
be the BOOT partition for the OS/2 computer that is involved in this!

I don't think you have to install YUM/RPM to the boot drive.


In

Post by Mike Luther
theory, as I think I understand this process, once the RPM deal is done,
YUM is the toolset which is used for the actual update process. However
I have no idea if YUM could be used just by itself with a 'normal' size
OS/2 tool to do the updates and so on. That so a pile full of completely
needed and mission critical service could handle twenty or more years of
data and coordinated service that date back to even DOS and not larger
than 2GB partitions which are perfect for what is needed and even will
be OK for even ten more years into the future. Whatever ...
OK, I posted a question about whether the RPM operation could be burned,
placed on a CD/DVD disk so that one could carry it around to the pile of
OS/2 machines and thus create and orchestrate the installed ClamAV for
OS/2 and the YUM update process in the 'normal' little space needed on
the native OS/2 file partition. In essence, I guess, the same 'way' that
the .WPI operation did all this for all the previous time back. I got no
answer that I know about as to this.
OK, can anyone here help teach me more about this, plus guide me toward
a successful replacement for the .WPI version of ClamAV for OS/2 needed?
Yes, I do have a fully paid for operation for PANDA for OS/2 that works
VERY well still for file and disk analysis even with the full daily
virus updates. However, it does require an OS/2 REXX poll of the PANDA
OS/2 update site to pick up your full virus update file each time it is
released. Which involves a full file download of about 24MB per file
each time you get that service. Which I have been using for still years
now absolutely well, though there is no real-time interface to protect
you for IP on-line connectivity such as with Seamonkey or whatever.
ClamAV for OS/2 involves only a daily normally small virus update needed
virus signature individual file per event release. Which is much more
practical for folks who have to handle updates on a daily basis.
And for which I guarantee you folks SHOULD still being doing for even OS/2.
Thanks for any help here.

I'm sure I saw a discussion somewhere about YUM/RPM packages being
"rewrapped" as ZIP or WPI files - seems some of us do not want the
necessary *nix file structure on our OS/2 drives and have decided they
will not be using YUM/RPM.

There was a big discussion about using YUM/RPM on os2world.com forums
and I seem to recall that the YUM/RPM porters/developers will also be
offering ZIP packages of any software available for YUM/RPM.

See http://www.os2world.com/forum/index.php/topic,3701.0.html and
http://www.os2world.com/forum/index.php/topic,2929.0.html


Regards

Pete

[Mike Luther]

Thanks Peter

Post by Peter Brown
Hi Mike
I don't think you have to install YUM/RPM to the boot drive.

Researching this from ..below. Which seem to point that there have been
numerous failures to get things working if the massive data and directory
organization impounded by the RPM/YUM process are not put into the 'proper'
directory where IT wants them to be and are NOT a part of the OS/2 well
protected source for them and how to 'modify' or 'not modify' that for evil
purposes.

Post by Peter Brown
I'm sure I saw a discussion somewhere about YUM/RPM packages being
"rewrapped" as ZIP or WPI files - seems some of us do not want the
necessary *nix file structure on our OS/2 drives and have decided they
will not be using YUM/RPM.
There was a big discussion about using YUM/RPM on os2world.com forums
and I seem to recall that the YUM/RPM porters/developers will also be
offering ZIP packages of any software available for YUM/RPM.
See http://www.os2world.com/forum/index.php/topic,3701.0.html and
http://www.os2world.com/forum/index.php/topic,2929.0.html
Regards
Pete

I have now read both these complete massive thread lines as to information and
thoughts on the whole process to which you pointed me. Hmmmmmmmmmmmmm...

I wish I had done this before I posted a reply to the subversion (4) WPI that
was pointed to me be the gentleman below. I would have perhaps posted a bit
different reply to him after reading what you suggested.

I guess at this point we are still in limbo land as to 'generic users' of the
OS/2 systems here. Yes, I can understand why a developer who was working with
a complex differential interface between numerous variations in Linux, Windows
whatever, Mac and OS/2 would badly want to 'standardize' the platform for the
work needed for such as a virus maintenance tool. However at the same time,
even a pretty technical lower level 'developer' of a tool set for such as
OS/2, it seems really still needs something such as the .WPI interface for
OS/2 for one reason which was not really cited anywhere in the threads to
which you pointed.

For certain mission critical applications under certain governmental 'rules'
that exist, it is not allowed that any external data site can modify the data
or information system automatically on any other remote site. It is
absolutely required that a LOCAL professionally qualified person must be
actively involved in the process of transferring data that will be used to
'update' the site or data stored for mission critical use there, from data on
a remote IP source. Thus the entire process of maintaining safety and clean
operations at any number of 'local' sites must also include even a much lower
level 'professional' to update the program executional files or control data,
as well as the data itself such as the updates to the virus files on a daily
or even multilevel daily need.

That noted, there seems no possible way that the forced operation that the
RPM/YUM technique could ever be 'understandable' to the needed lower level of
a 'local' at each site person. Given that this new suggested tool seems to
patch around what IBM really did provide for system safety as to how one could
police unwanted little arrows into mission critical control and data files for
the operating system that have really protected us OS/2er's for so long.

I'm studying things. Thanks for your help Peter. No decision yet, but this
is a huge process to hump around in order to make any decision.

[Doug Bissett]

Post by Mike Luther
Thoughts please?

...snip....

Post by Mike Luther
OK, can anyone here help teach me more about this, plus guide me toward a
successful replacement for the .WPI version of ClamAV for OS/2 needed?

I have tried it with the RPM/YUM thing, with no success. I have also
tried it with the ZIP file, with no success. Curently, I am just not
using any AV software with eCS. I don't like doing that, but it seems
that ClamAV is just not usable with eCS any more. I never had any
problems with the old WPI installed ClamAV, although I did have to
create icons for the ClamDScan, and FreshClam programs, to make them
useful.

...snip...

[Andreas Buchinger]

Post by Doug Bissett

Post by Mike Luther
Thoughts please?

...snip....

Post by Mike Luther
OK, can anyone here help teach me more about this, plus guide me toward a
successful replacement for the .WPI version of ClamAV for OS/2 needed?

I have tried it with the RPM/YUM thing, with no success. I have also
tried it with the ZIP file, with no success. Curently, I am just not
using any AV software with eCS. I don't like doing that, but it seems
that ClamAV is just not usable with eCS any more. I never had any
problems with the old WPI installed ClamAV, although I did have to
create icons for the ClamDScan, and FreshClam programs, to make them
useful.
...snip...

I've just tested clamav and it seems to work. Means clamscan says the database
is more than 7 days old and then starts scanning the current directory.

Installation with 'yum install clamav.i386' worked. Though I had to start the
installation a few times cause our ADSL connection dropped during downloading
the packages. But rpm smoothly started over were it gave up previously. At the
end of the installation I got a few lines like -

clamav-data-0.97.2-5.oc00.i386 was supposed to be installed but is not!
libc-devel-0.6.4-11.oc00.i386 was supposed to be installed but is not!
...

but AFAIK I read this messages which shows up sometimes are wrong.

I got a a

LIBC PANIC!!
_um_free_maybe_lock: Tried to free block twice - block=013ac688 lock=0x1
pid=0x007b ppid=0x007a tid=0x0001 slot=0x00b8 pri=0x0200 mc=0x0000
P:\USR\BIN\PYTHON.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

too. I think this was during creating desktop objects. I've a ClamAV 0.97.2
object with a ReadMe.txt only. No clue if there should be more. But as said
above, I think clamav basically works.

Regards,
Andreas

[Doug Bissett]

On Sat, 26 Nov 2011 18:19:01 UTC, Andreas Buchinger

Post by Andreas Buchinger

Post by Doug Bissett

Post by Mike Luther
Thoughts please?

...snip....

Post by Mike Luther
OK, can anyone here help teach me more about this, plus guide me toward a
successful replacement for the .WPI version of ClamAV for OS/2 needed?

I have tried it with the RPM/YUM thing, with no success. I have also
tried it with the ZIP file, with no success. Curently, I am just not
using any AV software with eCS. I don't like doing that, but it seems
that ClamAV is just not usable with eCS any more. I never had any
problems with the old WPI installed ClamAV, although I did have to
create icons for the ClamDScan, and FreshClam programs, to make them
useful.
...snip...

I've just tested clamav and it seems to work. Means clamscan says the database
is more than 7 days old and then starts scanning the current directory.
Installation with 'yum install clamav.i386' worked. Though I had to start the
installation a few times cause our ADSL connection dropped during downloading
the packages. But rpm smoothly started over were it gave up previously. At the
end of the installation I got a few lines like -
clamav-data-0.97.2-5.oc00.i386 was supposed to be installed but is not!
libc-devel-0.6.4-11.oc00.i386 was supposed to be installed but is not!
...
but AFAIK I read this messages which shows up sometimes are wrong.
I got a a
LIBC PANIC!!
_um_free_maybe_lock: Tried to free block twice - block=013ac688 lock=0x1
pid=0x007b ppid=0x007a tid=0x0001 slot=0x00b8 pri=0x0200 mc=0x0000
P:\USR\BIN\PYTHON.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
too. I think this was during creating desktop objects. I've a ClamAV 0.97.2
object with a ReadMe.txt only. No clue if there should be more. But as said
above, I think clamav basically works.
Regards,
Andreas

I need to find more time to play with this. I had no icons created (no
previous ClamAV installed).

I expect that I might start to figure out how to use RPM/YUM sometime
in the next quarter century, if they don't make some major changes to
it (then it might take longer). There is NO EXCUSE for making a
program that complicated in this day, and age, especially when it also
seems to restrict the user to submitting to a horrible mess in the
\usr directory.

[Andreas Buchinger]

Post by Doug Bissett
On Sat, 26 Nov 2011 18:19:01 UTC, Andreas Buchinger

Post by Andreas Buchinger

Post by Doug Bissett

Post by Mike Luther
Thoughts please?

...snip....

Post by Mike Luther
OK, can anyone here help teach me more about this, plus guide me toward a
successful replacement for the .WPI version of ClamAV for OS/2 needed?

I have tried it with the RPM/YUM thing, with no success. I have also
tried it with the ZIP file, with no success. Curently, I am just not
using any AV software with eCS. I don't like doing that, but it seems
that ClamAV is just not usable with eCS any more. I never had any
problems with the old WPI installed ClamAV, although I did have to
create icons for the ClamDScan, and FreshClam programs, to make them
useful.
...snip...

I've just tested clamav and it seems to work. Means clamscan says the database
is more than 7 days old and then starts scanning the current directory.
Installation with 'yum install clamav.i386' worked. Though I had to start the
installation a few times cause our ADSL connection dropped during downloading
the packages. But rpm smoothly started over were it gave up previously. At the
end of the installation I got a few lines like -
clamav-data-0.97.2-5.oc00.i386 was supposed to be installed but is not!
libc-devel-0.6.4-11.oc00.i386 was supposed to be installed but is not!
...
but AFAIK I read this messages which shows up sometimes are wrong.
I got a a
LIBC PANIC!!
_um_free_maybe_lock: Tried to free block twice - block=013ac688 lock=0x1
pid=0x007b ppid=0x007a tid=0x0001 slot=0x00b8 pri=0x0200 mc=0x0000
P:\USR\BIN\PYTHON.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
too. I think this was during creating desktop objects. I've a ClamAV 0.97.2
object with a ReadMe.txt only. No clue if there should be more. But as said
above, I think clamav basically works.
Regards,
Andreas

I need to find more time to play with this. I had no icons created (no
previous ClamAV installed).
I expect that I might start to figure out how to use RPM/YUM sometime
in the next quarter century, if they don't make some major changes to
it (then it might take longer). There is NO EXCUSE for making a
program that complicated in this day, and age, especially when it also
seems to restrict the user to submitting to a horrible mess in the
\usr directory.

Then there is no excuse for you doing it better and give it away for free too if
you are so much more capable then the other spare time programmer is.

And I for myself do really do not care about an extra usr dir at my programs
partition P:\ cause there are 273 other dirs too...

[L.Soens]

On Sat, 26 Nov 2011 23:51:05 UTC, "Doug Bissett"

Post by Doug Bissett
use RPM/YUM sometime

have fun ;-)

I think Remy did a tremendous good job, as he offers clamav for
download, without a need for the incredible RPM/YUM overload (not for
him, but now for me...). The GUI might be fine, but you'll still have
to fiddle with the config files to meet your wishes - so why not take
his "pure" wpi build straightaway, and add some program objects and
scripts. Like I had with Yuri's former versions. Works for me...

Regards
Lothar

[Allan]

Post by Mike Luther
OK, can anyone here help teach me more about this, plus guide me toward a
successful replacement for the .WPI version of ClamAV for OS/2 needed?

Maybe this one can help you ?

http://remydodin.levillage.org/outils/Clamav-0_96_4-4b.wpi

Notice that this may require changes to your config, due to all that
crazy RPM config, which is stuffed into the executables now.

(I have not yet tested this package myself :-) )

[Mike Luther]

Aha!

Post by Allan

Post by Mike Luther
OK, can anyone here help teach me more about this, plus guide me toward a
successful replacement for the .WPI version of ClamAV for OS/2 needed?

Maybe this one can help you ?
http://remydodin.levillage.org/outils/Clamav-0_96_4-4b.wpi
Notice that this may require changes to your config, due to all that
crazy RPM config, which is stuffed into the executables now.
(I have not yet tested this package myself :-) )

OK .. I downloaded it and it is a bit bigger than the last .WPI installer that
I have here.

Has anyone here tried this one and can comment on what is in it and how it
works or does not work? Or on any documentation for it that I could study?


Thanks!

[Peter Brown]

Hi Mike

Post by Mike Luther
Aha!

Post by Allan

Post by Mike Luther
OK, can anyone here help teach me more about this, plus guide me
toward a successful replacement for the .WPI version of ClamAV for
OS/2 needed?

Maybe this one can help you ?
http://remydodin.levillage.org/outils/Clamav-0_96_4-4b.wpi
Notice that this may require changes to your config, due to all that
crazy RPM config, which is stuffed into the executables now.
(I have not yet tested this package myself :-) )

OK .. I downloaded it and it is a bit bigger than the last .WPI
installer that I have here.
Has anyone here tried this one and can comment on what is in it and how
it works or does not work? Or on any documentation for it that I could
study?
Thanks!

Sorry, cannot comment on this app as I do not use it.

Maybe there is some documentation inside the WPI package. You can always
have a look see using WPIView from
http://svn.netlabs.org/vxapps/wiki/WikiStart

Regards

Pete

[Mike Luther]

Hi Allan

Post by Allan

Post by Mike Luther
OK, can anyone here help teach me more about this, plus guide me toward a
successful replacement for the .WPI version of ClamAV for OS/2 needed?

Maybe this one can help you ?
http://remydodin.levillage.org/outils/Clamav-0_96_4-4b.wpi
Notice that this may require changes to your config, due to all that
crazy RPM config, which is stuffed into the executables now.
(I have not yet tested this package myself :-) )

OK, I got that WPI, took a look inside it from the advice from Peter Brown
with the WPI view utility. As far as I can tell, Remy's WPI did properly
install everything that was shown in it from the viewer. As well, this WPI
did modify my CONFIG.SYS file by placing what I have used for all this time as

Post by Allan
SET UNIXROOT=C:\CLAMAV

As well, the WPI install put what is seemed to be a 'correct' new path in the
C:\CLAMAV install directory as C:\CLAMAV\var\lib\clamav, which now has only
one file in it which is main.cvd there now.

However with every executable I try to run directly or is in a .CMD file at

Post by Allan
[C:\clamav\bin]clamscan
SYS1804: The system cannot find the file Z.

I have also looked at the .CMD file dllcopy.cmd, which is a REXX file. I
think from what I read that it wants to know what that path is as in C:\CLAMAV

Post by Allan
[C:\clamav]dllcopy
REX0006: Error 6 running C:\clamav\dllcopy.cmd, line 25: Unmatched "/*" or
quote

Can someone teach me what else I may be doing wrong and don't understand about
this yet?

Thanks!

[Steve Wendt]

Post by Allan
[C:\clamav\bin]clamscan
SYS1804: The system cannot find the file Z.

That means it can't Z.DLL, which apparent it needs. My guess is that is
a version of zlib, but I can't tell you where to find it.

[Allan]

Post by Mike Luther
Hi Allan

Post by Allan

Post by Mike Luther
OK, can anyone here help teach me more about this, plus guide me toward a
successful replacement for the .WPI version of ClamAV for OS/2 needed?

Maybe this one can help you ?
http://remydodin.levillage.org/outils/Clamav-0_96_4-4b.wpi
Notice that this may require changes to your config, due to all that
crazy RPM config, which is stuffed into the executables now.
(I have not yet tested this package myself :-) )

OK, I got that WPI, took a look inside it from the advice from Peter Brown
with the WPI view utility. As far as I can tell, Remy's WPI did properly
install everything that was shown in it from the viewer. As well, this WPI
did modify my CONFIG.SYS file by placing what I have used for all this time as

Post by Allan
SET UNIXROOT=C:\CLAMAV

As well, the WPI install put what is seemed to be a 'correct' new path in the
C:\CLAMAV install directory as C:\CLAMAV\var\lib\clamav, which now has only
one file in it which is main.cvd there now.
However with every executable I try to run directly or is in a .CMD file at

Post by Allan
[C:\clamav\bin]clamscan
SYS1804: The system cannot find the file Z.

Yeah, these new ClamAV's requires a bunch of extra DLL files,
that seems to be installed as part of RPM shit.

Grab this zip
ftp://ftp.warpspeed.dk/ML.ZIP
and unzip all these DLL's into same dir
as your Clam*.exe files - that should fix it.

[Mike Luther]

Thanks Allan .. however, grin ..

Post by Allan
Yeah, these new ClamAV's requires a bunch of extra DLL files,
that seems to be installed as part of RPM shit.
Grab this zip
ftp://ftp.warpspeed.dk/ML.ZIP
and unzip all these DLL's into same dir
as your Clam*.exe files - that should fix it.
8-26-11 12:41p 33964 124 bz2.dll
11-02-11 4:14p 8574 124 mmap.dll
11-02-11 4:06p 5817 124 pthr01.dll
11-20-10 9:17a 4052 124 pthread.dll
11-02-11 5:11p 2473 124 urpo.dll
8-26-11 3:23p 51834 124 z.dll

OK, did that, even though some of 'these' were already installed by the WPI in

Post by Allan
2-28-11 11:40a 33947 0 bz2.dll
2-28-11 11:40a 739652 0 clamav.dll
2-28-11 11:40a 8516 0 mmap.dll
10-15-10 5:58p 4052 0 pthread.dll
11-20-10 10:23p 51827 0 z.dll

Which sort of leads to the question, and again I'm *NOT* trying to be critical
here, because I really do appreciate and understand the difficulty of cross
platform programming work. If there is already a DLL directory that is
created by the new WPI work, and these 'files' version or whatever are in this
installed directory, why aren't they seen? And what does the wonderful
contributor who is really trying to help us all faced with if the DLL's at
this point have to actually be in the \bin directory?

OK next step too.

After I did what you pointed me toward, now if I just try to run freshclam.exe

Post by Allan
[C:\CLAMAV\BIN]freshclam
SYS1804: The system cannot find the file GCC444.

Interesting! For whatever all else that is need for Ghostview, Ghostscript

Post by Allan
2-23-04 3:40p 28718 0 gcc322.dll
10-03-11 6:05a 32801 0 gcc335.dll
1-26-09 11:32a 24416 124 gcc433.dll
12-16-11 9:01a 131447 124 gcc446.dll
12-29-10 12:27a 21899 124 gcc452.dll

So can you point me toward that GCC444 juicy bit? Grin... Which hopefully can
just be added to all the others... chortle

And really I'm trying to help us all here too with what I post and thank you
for your time too..

[Allan]

Post by Mike Luther
Thanks Allan .. however, grin ..

Post by Allan
8-26-11 12:41p 33964 124 bz2.dll
11-02-11 4:14p 8574 124 mmap.dll
11-02-11 4:06p 5817 124 pthr01.dll
11-20-10 9:17a 4052 124 pthread.dll
11-02-11 5:11p 2473 124 urpo.dll
8-26-11 3:23p 51834 124 z.dll

OK, did that, even though some of 'these' were already installed by the WPI in

Post by Allan
2-28-11 11:40a 33947 0 bz2.dll
2-28-11 11:40a 739652 0 clamav.dll
2-28-11 11:40a 8516 0 mmap.dll
10-15-10 5:58p 4052 0 pthread.dll
11-20-10 10:23p 51827 0 z.dll

Which sort of leads to the question, and again I'm *NOT* trying to be critical
here, because I really do appreciate and understand the difficulty of cross
platform programming work. If there is already a DLL directory that is
created by the new WPI work, and these 'files' version or whatever are in this
installed directory, why aren't they seen? And what does the wonderful
contributor who is really trying to help us all faced with if the DLL's at
this point have to actually be in the \bin directory?

If it should work in a different dir, this dir have to be in libpath. I don't know
if the WPI adds this dir to your libpath. Does the readme perhaps say
anything about these files ?

Post by Mike Luther

Post by Allan
[C:\CLAMAV\BIN]freshclam
SYS1804: The system cannot find the file GCC444.

Interesting! For whatever all else that is need for Ghostview, Ghostscript

Post by Allan
2-23-04 3:40p 28718 0 gcc322.dll
10-03-11 6:05a 32801 0 gcc335.dll
1-26-09 11:32a 24416 124 gcc433.dll
12-16-11 9:01a 131447 124 gcc446.dll
12-29-10 12:27a 21899 124 gcc452.dll

So can you point me toward that GCC444 juicy bit? Grin... Which hopefully can
just be added to all the others... chortle

http://sourceforge.net/projects/ecsports/files/GCC%20Runtime%20DLLs/

Grab all the ones, you are missing.

You'll need them sooner or later for some app.

[Mike Luther]

Thanks again Allan!

Post by Allan
http://sourceforge.net/projects/ecsports/files/GCC%20Runtime%20DLLs/
Grab all the ones, you are missing.
You'll need them sooner or later for some app.

Aha! Got them. I copied that gcc444.dll into my C:\OS2\DLL directory and
poof, freshclam.exe connected and .. more or less .. updated my viri file.
It still says it is 'out of date' but at least has moved forward from the 6.2
version to the 6.4 version.

OK now to further experiment with test scans for floppy disks, hard drive test
bits and so on to see what might be needed next to go forward. At this also,
perhaps the thankful contributor to this newer WPI version might be able to
pick up some info that would help too. Haven't tested yet, but with the
gcc444.dll in there maybe it even will see the newer C:\CLAMAV\Dlls direftor
as well.

I'll report back with what I find later today hopefully.

[Mike Luther]

OK, Next step Allan I think!

Post by Allan
Maybe this one can help you ?
http://remydodin.levillage.org/outils/Clamav-0_96_4-4b.wpi
Notice that this may require changes to your config, due to all that
crazy RPM config, which is stuffed into the executables now.
(I have not yet tested this package myself :-) )

OK with what we have discussed before, I now have freshclam.exe apparently
working without 'error's showing up at least at times for the update. So I'll
try a simple scan to test things.

I have had an OS/2 .CMD file that I can mouse click which I added to my CLAMAV
folder which I can click to scan Drive A: if I want. In essence, from the
'normal' C:\CLAMAV\bin directory it was simply:

clamscan "A:/"

Now, even with a 'current' update from the sig server via IP, I cannot get it
to work unless I use:

clamscan "A:"

Plus when I do, I get three rounds of the 'warning message' then, if run from
an OS/2 window object I get (top two alerts clipped) from a 3-1/2" floppy for

Post by Allan
LibClamAV Warning: *** This version of the ClamAV engine is outdated. ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq ***
LibClamAV Warning: ***********************************************************
A:/ktx120-1.zip: OK
A:/ktx120-2.zip: OK
A:/ktc120.nif: OK
A:/ktc120.os2: OK
A:/rtsnd323.zip: OK
WARNING: Can't open file A:/ea data. sf: Permission denied
A:/rtl8139.txt: OK
A:/dx10000.txt: OK

Curiousity strikes me. Is this whole thing now scrambled into checking things
with OS/2 extended attributes that could somehow really cause us OS/2 puppies
troubles down the line? Plus even though it looks like I have a 'clean'
signature file, why THREE of those error messages in a row?

Puppy wants to know, chuckle..

[Allan]

Post by Mike Luther
OK, Next step Allan I think!

I can try :-)

Post by Mike Luther
OK with what we have discussed before, I now have freshclam.exe apparently
working without 'error's showing up at least at times for the update. So I'll
try a simple scan to test things.

Very good idea !

Post by Mike Luther
I have had an OS/2 .CMD file that I can mouse click which I added to my CLAMAV
folder which I can click to scan Drive A: if I want. In essence, from the
clamscan "A:/"
Now, even with a 'current' update from the sig server via IP, I cannot get it
clamscan "A:"

Strange. I don't have any floppies around to test drive A: currently; but when I
test same on Y: (My RAM drive), I can use Y: or Y:/ or Y:\
In all 3 cases it scans whats there - output looks (as it has always done) more or less
funny.

Post by Mike Luther
Plus when I do, I get three rounds of the 'warning message' then, if run from
an OS/2 window object I get (top two alerts clipped) from a 3-1/2" floppy for

Post by Allan
LibClamAV Warning: *** This version of the ClamAV engine is outdated. ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq ***
LibClamAV Warning: ***********************************************************

Just read the URL, and you know the answers to that.

Post by Mike Luther

Post by Allan
A:/ktx120-1.zip: OK
A:/ktx120-2.zip: OK
A:/ktc120.nif: OK
A:/ktc120.os2: OK
A:/rtsnd323.zip: OK
WARNING: Can't open file A:/ea data. sf: Permission denied
A:/rtl8139.txt: OK
A:/dx10000.txt: OK

Curiousity strikes me. Is this whole thing now scrambled into checking things
with OS/2 extended attributes that could somehow really cause us OS/2 puppies
troubles down the line?

Which planet do you live on ?
NO NO NO NO NO app have EVER EVER EVER EVER ..............
been able to access/read/write/delete/OR_DO_ANYTHING
with ea.data. sf file on any FAT volume - the file is hard locked
and controlled by the filesystem (for FAT that is the kernel).
You will see same error for SWAPPER.DAT on any boot volume.

You have seen these 'errors' with every version of ClamAV.

The --exclude parameter is invented for such files - use it.

Post by Mike Luther
Plus even though it looks like I have a 'clean'
signature file, why THREE of those error messages in a row?

Since you never noticed it before - they have now trippled it !

[Mike Luther]

Good new Allan..

Post by Allan
Which planet do you live on ?
NO NO NO NO NO app have EVER EVER EVER EVER ..............
been able to access/read/write/delete/OR_DO_ANYTHING
with ea.data. sf file on any FAT volume - the file is hard locked
and controlled by the filesystem (for FAT that is the kernel).
You will see same error for SWAPPER.DAT on any boot volume.
You have seen these 'errors' with every version of ClamAV.
The --exclude parameter is invented for such files - use it.

Yes. I, the offensive little puppy dog, hangs his head and whimpers apology.

Post by Allan

Post by Mike Luther
Plus even though it looks like I have a 'clean'
signature file, why THREE of those error messages in a row?

Since you never noticed it before - they have now trippled it !

And now same little puppy dog sits down with head held low and VERY quiet.

Most important, I've now been able to test this both hand type as a check to
test for problems in hard drive operations such as manual testing for a given
directory. Next step is to use it in test mode for file/message testing in
inbound FTP server work; any way that is normally called from a custom .CMD or
REXX file. I'll try that as soon as I can and report back here, but don't
expect any problems for that.

Following that, I'll create a custom .CMD file that I can testy that first
inserts the needed 444 .DLL into the machine being used for an install. Then
I guess the next step is to do the .WPI for the install. Then follow it with
another 'custom' copy of the needed files to get it working that I did
manually at this point.

I also have never looked at our very respected Remy's web site until now but
I've added it to my 'Monkey-See-Monkey-Do' door list. OK, seeing that this
new WPI is the latest at this from Remy. If what I can get done this way
works on a couple more boxes, my best guess is it would be of use to get this
data to Remy so he can think about how to move forward to the next level of
.WPI for the upward move here.

I'm not other than latest everything MCP2 level OS/2 stuff, although I have
purchased support for eCs and have nothing against that. As well, I also
still have a couple Marp4 FP17 boxes I can test on. So as it moves forward
maybe we all can move forward without all this RPM-YUMmy stuff. Which I do
understand is VERY valuable to folks like Yuri. But still, as I see this,
intensely help a lot more of us OS/2 puppies!

;)

[Remy]

Post by Mike Luther
Good new Allan..

Post by Allan
Which planet do you live on ?
NO NO NO NO NO app have EVER EVER EVER EVER ..............
been able to access/read/write/delete/OR_DO_ANYTHING
with ea.data. sf file on any FAT volume - the file is hard locked
and controlled by the filesystem (for FAT that is the kernel).
You will see same error for SWAPPER.DAT on any boot volume.
You have seen these 'errors' with every version ofClamAV.
The --exclude parameter is invented for such files - use it.

Yes.  I, the offensive little puppy dog, hangs his head and whimpers apology.

Post by Allan

Post by Mike Luther
Plus even though it looks like I have a 'clean'
signature file, why THREE of those error messages in a row?

Since you never noticed it before - they have now trippled it !

And now same little puppy dog sits down with head held low and VERY quiet.
Most important, I've now been able to test this both hand type as a check to
test for problems in hard drive operations such as manual testing for a given
directory.  Next step is to use it in test mode for file/message testing in
inbound FTP server work; any way that is normally called from a custom .CMD or
REXX file.  I'll try that as soon as I can and report back here, but don't
expect any problems for that.
Following that, I'll create a custom .CMD file that I can testy that first
inserts the needed 444 .DLL into the machine being used for an install.  Then
I guess the next step is to do the .WPI for the install.  Then follow it with
another 'custom' copy of the needed files to get it working that I did
manually at this point.
I also have never looked at our very respected Remy's web site until now but
I've added it to my 'Monkey-See-Monkey-Do' door list.   OK, seeing that this
new WPI is the latest at this from Remy.  If what I can get done this way
works on a couple more boxes, my best guess is it would be of use to get this
data to Remy so he can think about how to move forward to the next level of
.WPI for the upward move here.
I'm not other than latest everything MCP2 level OS/2 stuff, although I have
purchased support for eCs and have nothing against that.  As well, I also
still have a couple Marp4 FP17 boxes I can test on.  So as it moves forward
maybe we all can move forward without all this RPM-YUMmy stuff.  Which I do
understand is VERY valuable to folks like Yuri.  But still, as I see this,
intensely help a lot more of us OS/2 puppies!
;)
--
--> Sleep well; OS2's still awake! ;)
Mike Luther

Hello,

I'm Remy and just saw this google group.
About my WPI, I found an error into the dllcopy.cmd (the line is
wrapped which gives the seen error)
In fact, all provided DLLs should be placed under ..\OS2\DLL or
better ..\ECS\DLL

Of course, some GCC and LIBC are required.
I'm going to provide an updated WPI with a corrected dllcopy...
I hope doing it soon including a backup process of existing older
duplicate dll version.

Now, latest ClamAV build uses new Dlls
clamav.dll
bz2.dll
mmap.dll
pthr01.dll
pthread.dll
urpo.dll
z.dll

while 0.96.4 used:
bz2.dll
clamav.dll
mmap.dll
pthread.dll
z.dll

During a backward test, new dll where not compatible with ClamAV
0.96.4 and I had to restore all older Dll's

I could provide a WPI with 0.97.x build for test purpose only due I
have an unresolved error fmap() allocation error during scan which
could be an environment issue...

I hope been able to put updated 0.96.4 WPI on my server soon and
should be named
http://remydodin.levillage.org/outils/Clamav-0_96_4-4c.wpi

Then, a test build http://remydodin.levillage.org/outils/Clamav-0_97_2alpha.wpi
(soon... )
I would be very interested into feedback, please use "write to author"
under GUI or from my web page contact ink.

I upgraded ClamAVGUI to 2.3.1 including some changes needed for 0.97.2
build and some new options
- Included an add-on (xpi) taken from ubuntu forum and updated file to
support thunderbird from 3.1.10 up to v9
- Added paremters into clamd config file to interface with thunderbird
ubuntu add-on (if new install or read tips and trics file for how to)
- Added a "Mscan" direct option to scan all loaded files into memory

cheers/2
Remy

[Allan]

Post by Remy
I'm Remy and just saw this google group.

It is not a Google <anything> - it is a news group, and has existed for
20 years ;-)

Post by Remy
About my WPI, I found an error into the dllcopy.cmd (the line is
wrapped which gives the seen error)
In fact, all provided DLLs should be placed under ..\OS2\DLL or
better ..\ECS\DLL

It is a very bad idea to stuff private dll's into system dirs.
Put them in same place as the exe file, and it works fine.

Post by Remy
Of course, some GCC and LIBC are required.

Docs need to say these are needed, and where to get them.
Don't do your own install of these.

We are looking into getting ClamAV built without RPM requirements.
More will follow....

[Remy]

Post by Allan
Docs need to say these are needed, and where to get them.
Don't do your own install of these.

This is exactly what the WPI does (warning message if Gcc and Klib are
not at correct level)
Other dll are mixed under different kind of rpm package on netlabs
making them difficult to get and of course, no readme exist under
netlabs to tell dlls level requirements.

Cheers/2

[Allan]

Post by Remy

Post by Allan
Docs need to say these are needed, and where to get them.
Don't do your own install of these.

This is exactly what the WPI does (warning message if Gcc and Klib are
not at correct level)
Other dll are mixed under different kind of rpm package on netlabs
making them difficult to get and of course, no readme exist under
netlabs to tell dlls level requirements.

There will be a new 0.97.3 version ready soon. This will not require
all the extra dll's, nor any of the rpm crap. Stay tuned.

[Mike Luther]

Hi Allan

Post by Allan

Post by Remy

Post by Allan
Docs need to say these are needed, and where to get them.
Don't do your own install of these.

This is exactly what the WPI does (warning message if Gcc and Klib are
not at correct level)
Other dll are mixed under different kind of rpm package on netlabs
making them difficult to get and of course, no readme exist under
netlabs to tell dlls level requirements.

There will be a new 0.97.3 version ready soon. This will not require
all the extra dll's, nor any of the rpm crap. Stay tuned.

Oh thank you! Also with *NO* bad thoughts about Remy and his work which is
very much important too. Believe me, I really appreciate what is being done
here and what I've been posting is seriously trying to help at this,

I think the most important point to me and those I know close to me about this
is that we really need to be able to pick whatever actual directory the whole
CLAMAV is in that can be in any drive, boot or whatever. At our choice
completely away from a 'common' program directory. Yes, for SURE not in some
#:/program/ directory that i have now 'learned' is part of the RPM-YUM stuff.
Which I've learned sure can be put in the CONFIG.SYS file. But when it
does, as in C:\CLAMAV which I have to use to now use it, this is a total wreck
if any other Linux-Whatever stuff is 'ported' to OS\2. As I understand this.

We really need to be able to work with all this not only with the eCs level
stuff, but also with the MCP2 latest OS/2 stuff, as well as with the full OS\2
server operations from backwards too. Sure, I really respect what Remy and
others have accomplished. I do, I do. Yet at the same time part of the entire
security process that us OS/2er's do still have is a part of separating it
from a 'forced' format for any op system that absolutely makes us do exactly
the same generic 'notebook' organization for whatever chapter that is forced
on us, like write once read anywhere Java, for example.

Sure, OS/2 can be hacked. No questions about that. But as best we can be,
still sort of quietly remaining under the popularity gambit, we can still, we
hope, be a bit less at risk from the 'frisky's..

;)

And THANKS to you folks for your blessed work.

[Allan]

Mike, you talk toooooo much :-)

Post by Mike Luther

Post by Allan
There will be a new 0.97.3 version ready soon. This will not require
all the extra dll's, nor any of the rpm crap. Stay tuned.

Oh thank you! Also with *NO* bad thoughts about Remy and his work which is
very much important too. Believe me, I really appreciate what is being done
here and what I've been posting is seriously trying to help at this,

I think Remy is doing a great job making it easier for normal people
to adapt ClamAV, and I hope the new build will help him too.

http://sourceforge.net/projects/ecsports/files/clamav-0.97.3-os2-20120131.zip/download

Post by Mike Luther
I think the most important point to me and those I know close to me about this
is that we really need to be able to pick whatever actual directory the whole
CLAMAV is in that can be in any drive, boot or whatever. At our choice
completely away from a 'common' program directory. Yes, for SURE not in some
#:/program/ directory that i have now 'learned' is part of the RPM-YUM stuff.
Which I've learned sure can be put in the CONFIG.SYS file. But when it
does, as in C:\CLAMAV which I have to use to now use it, this is a total wreck
if any other Linux-Whatever stuff is 'ported' to OS\2. As I understand this.

This build unfortunately enforces /clamav/* but I have only tested it in
other dirs, and you can do that, by simply specifying either conf file or
database dir on cmd line.

That said, it should support kLibC Pathrewriter. It comes with new eCS's, or can
be downloaded from Netlabs. If you use that, you can point that fixed '/clamav/'
to anything - even an ENV. Didn't try it myself.

Post by Mike Luther
We really need to be able to work with all this not only with the eCs level
stuff, but also with the MCP2 latest OS/2 stuff, as well as with the full OS\2
server operations from backwards too. Sure, I really respect what Remy and
others have accomplished. I do, I do. Yet at the same time part of the entire
security process that us OS/2er's do still have is a part of separating it
from a 'forced' format for any op system that absolutely makes us do exactly
the same generic 'notebook' organization for whatever chapter that is forced
on us, like write once read anywhere Java, for example.

I'm sorry Paul didn't have the time to fix the path issues any better for now.
If you want it done better quickly, look for the 'Donation' buttom on his site,
and ask for improvements to this - mayby that will help.

[Mike Luther]

Post by Allan
This build unfortunately enforces /clamav/* but I have only tested it in
other dirs, and you can do that, by simply specifying either conf file or
database dir on cmd line.

Which should be fine in all my C:\clamav directories already there.

Post by Allan
That said, it should support kLibC Pathrewriter. It comes with new eCS's, or can
be downloaded from Netlabs. If you use that, you can point that fixed '/clamav/'
to anything - even an ENV. Didn't try it myself.

Guessed OK here too.

Few word question. Do I have to go back into my hand modified CONFIG.SYS and
remove the SET UNIXROOT=C:\CLAMAV I added? Or is it still needed?

*****

Sorry about all the words, but there is also a very bad little understood
issue about that whole deal too. The original 'install' I worked with you
from automatically puts that line at the bottom of the CONFIG.SYS file. Which
actually, in some cases, can cause a fatal boot error in some versions of
MCP2. There are some USB device drivers in which the absolute last line in
your CONFIG.SYS file must be a related line device driver and option choice!
Which we discovered long ago can totally trash later ThinkPad installations.

Post by Allan
SET SNAP_INTCURSOR_DISABLE=Y

Which in the case of at least the ThinkPad issues, to prevent hangups, must be
the line just above the USB driver line I don't have access to on this box. If
you are using SNAP for OS/2.

As well, in some variations of motherboard installations, there is also an
older OS/2 install/boot glitch which makes it necessary that at least one
blank line must be at the bottom of your CONFIG.SYS file. That to prevent
OS/2 networking glitches which were present in up through pretty latest MCP2
installs and FixPacks. Persuant to what we discovered when I was on the
external test site operations for the official OS/2 test team for many years.

Just simply adding a forced UNIXROOT line in CONFIG.SYS this way may not
affect eCS operations. But it can trash a fairly large group of other OS/2
operations from my experience. FWIW ..


--


--> Sleep well; OS2's still awake! ;)

Mike Luther

[Allan]

Post by Mike Luther

Post by Allan
This build unfortunately enforces /clamav/* but I have only tested it in
other dirs, and you can do that, by simply specifying either conf file or
database dir on cmd line.

Few word question. Do I have to go back into my hand modified CONFIG.SYS and
remove the SET UNIXROOT=C:\CLAMAV I added? Or is it still needed?

This build does not use UNIXROOT at all.
You can remove it, if you don't need it for other things.

[Mike Luther]

Thanks for the quick response Allan

Post by Allan

Post by Mike Luther
Few word question. Do I have to go back into my hand modified CONFIG.SYS and
remove the SET UNIXROOT=C:\CLAMAV I added? Or is it still needed?

This build does not use UNIXROOT at all.
You can remove it, if you don't need it for other things.

OK tried this. freshclam.exe and clamscan.exe work just fine from your new
download. That of course with the freshclam.conf set up for my US download mod
in the file.

However, interestingly, clamd.exe will not work at all here without the old
UNIXROOT setup in the CONFIG.SYS for some reason. The test MCP2 system as was
originally set up for your work has the following lines changed in clamd.conf

Post by Allan
#Example
LogFile /tmp/clamd.log
LogFileUnlock yes

But without CONFIG.SYS having

Post by Allan
SET UNIXROOT=C:\CLAMAV

there is no way I can seem to modify the 'new' or 'old' clamd.conf that will
If I put back the SET line in CONFIG.SYS, what was in your .ZIP download will
work with the above settings in your clamd.conf file.

Suggestions very helpful friend to all of us OS/2ers?

[Remy]

Post by Mike Luther
Thanks for the quick response Allan

Post by Allan

Few word question.  Do I have to go back into my hand modified CONFIG.SYS and
remove the SET UNIXROOT=C:\CLAMAV I added?  Or is it still needed?

This build does not use UNIXROOT at all.
You can remove it, if you don't need it for other things.

OK tried this.  freshclam.exe and clamscan.exe work just fine from your new
download. That of course with the freshclam.conf set up for my US download mod
in the file.
However, interestingly, clamd.exe will not work at all here without the old
UNIXROOT setup in the CONFIG.SYS for some reason.  The test MCP2 system as was
originally set up for your work has the following lines changed in clamd.conf

Post by Allan
#Example
LogFile /tmp/clamd.log
LogFileUnlock yes

But without CONFIG.SYS having

Post by Allan
SET UNIXROOT=C:\CLAMAV

there is no way I can seem to modify the 'new' or 'old' clamd.conf that will
If I put back the SET line in CONFIG.SYS, what was in your .ZIP download will
work with the above settings in your clamd.conf file.
Suggestions very helpful friend to all of us OS/2ers?
--
--> Sleep well; OS2's still awake! ;)
Mike Luther

Hi,
Thanks Allan.

All tests succeeded and ok with ClamAVGUI as well as the thunderbird
addon.
I created the WPI package.

I left the unixroot check for compatibility with previous WPI I build
A check is done to verify libc wpi package was previously installed
I left a few dlls under Dlls folder (e.g urpo.dll, mmap.dll..) but no
more do any copy operation (dlls are they if needed)

I also updated my ClamAVGUI (included thunderbird clamav addon) for
compatibility issue with this 0.97.3
You can get all of them on my site (clamav is at bottom):
http://remydodin.levillage.org/ClamAV_GUI.html

Cheers/2
Remy

[Mike Luther]

Thank you so much for your work Remy

Post by Remy
I created the WPI package.
I left the unixroot check for compatibility with previous WPI I build
A check is done to verify libc wpi package was previously installed
I left a few dlls under Dlls folder (e.g urpo.dll, mmap.dll..) but no
more do any copy operation (dlls are they if needed)
I also updated my ClamAVGUI (included thunderbird clamav addon) for
compatibility issue with this 0.97.3
http://remydodin.levillage.org/ClamAV_GUI.html
Cheers/2
Remy
2-01-12 4:58a 2498198 76 Clamav-0_97_3.wpi

I have tried this and it immediately comes up with an 'error' saying that a
file is missing:

netlabs.org\klibc\libc 0.6 runtime \0\6\4\0\

I've looked through the svn\netlabs.org complete reference to this. As far as

Post by Remy
Archive: gccdll.zip
Length EAs ACLs Date Time Name
------ --- ---- ---- ---- ----
28718 0 0 02-23-04 15:40 gcc322.dll
32801 0 0 10-03-11 06:05 gcc335.dll
24416 160 0 01-26-09 11:32 gcc433.dll
23691 0 0 12-29-10 22:24 gcc444.dll
23691 0 0 12-30-10 01:33 gcc445.dll
131447 160 0 12-16-11 09:01 gcc446.dll
21899 160 0 12-29-10 00:27 gcc452.dll
21888 160 0 06-12-11 01:29 gcc453.dll
------ ----- ----- -------
308551 640 0 8 files

All of these are already copied into my 'normal' C:\OS@\DLL directory. If so,
how is the above error being produced? Do I need to also put that gcc446.dll
in the CLAMAV\dll directory? However the 'original' .WPI install did it, that

Post by Remy
Directory of C:\CLAMAV\DLLS
1-06-12 3:43a <DIR> 0 .
1-06-12 3:43a <DIR> 0 ..
2-28-11 11:40a 33947 0 bz2.dll
2-28-11 11:40a 739652 0 clamav.dll
2-28-11 11:40a 8516 0 mmap.dll
10-15-10 5:58p 4052 0 pthread.dll
11-20-10 10:23p 51827 0 z.dll
7 file(s) 837994 bytes used

Maybe this will help solve another point in the .WPI game.

Bless you Remy..

[Peter Brown]

Hi Mike

Post by Mike Luther
Thank you so much for your work Remy

Post by Remy
I created the WPI package.
I left the unixroot check for compatibility with previous WPI I build
A check is done to verify libc wpi package was previously installed
I left a few dlls under Dlls folder (e.g urpo.dll, mmap.dll..) but no
more do any copy operation (dlls are they if needed)
I also updated my ClamAVGUI (included thunderbird clamav addon) for
compatibility issue with this 0.97.3
http://remydodin.levillage.org/ClamAV_GUI.html
Cheers/2
Remy
2-01-12 4:58a 2498198 76 Clamav-0_97_3.wpi

I have tried this and it immediately comes up with an 'error' saying
netlabs.org\klibc\libc 0.6 runtime \0\6\4\0\
I've looked through the svn\netlabs.org complete reference to this.

Looks like it wants the wpi packaged version of libc064 -
ftp://ftp.netlabs.org/pub/gcc/libc-0.6.4-csd4.wpi


Regards

Pete


As

Post by Mike Luther

Post by Remy
Archive: gccdll.zip
Length EAs ACLs Date Time Name
------ --- ---- ---- ---- ----
28718 0 0 02-23-04 15:40 gcc322.dll
32801 0 0 10-03-11 06:05 gcc335.dll
24416 160 0 01-26-09 11:32 gcc433.dll
23691 0 0 12-29-10 22:24 gcc444.dll
23691 0 0 12-30-10 01:33 gcc445.dll
131447 160 0 12-16-11 09:01 gcc446.dll
21899 160 0 12-29-10 00:27 gcc452.dll
21888 160 0 06-12-11 01:29 gcc453.dll
------ ----- ----- -------
308551 640 0 8 files

If so, how is the above error being produced? Do I need to also put that
gcc446.dll in the CLAMAV\dll directory? However the 'original' .WPI

Post by Remy
Directory of C:\CLAMAV\DLLS
1-06-12 3:43a <DIR> 0 .
1-06-12 3:43a <DIR> 0 ..
2-28-11 11:40a 33947 0 bz2.dll
2-28-11 11:40a 739652 0 clamav.dll
2-28-11 11:40a 8516 0 mmap.dll
10-15-10 5:58p 4052 0 pthread.dll
11-20-10 10:23p 51827 0 z.dll
7 file(s) 837994 bytes used

Maybe this will help solve another point in the .WPI game.
Bless you Remy..

[Mike Luther]

Thanks Peter

Post by Peter Brown
Hi Mike
Looks like it wants the wpi packaged version of libc064 -
ftp://ftp.netlabs.org/pub/gcc/libc-0.6.4-csd4.wpi
Regards
Pete

Yes. Correct. However interestingly, for you to be able to look at what is
inside this netlabs package withthe Warpin viewer tool, you have to change the
internal period character marks to an underline character in the Netlabs

Post by Peter Brown
2-01-12 7:18p 1402968 70 libc-0_6_4-csd4.wpi

I did get it to install with the Warpin installer and the period punctuation
marks, didn't try it as changed with the underline characters. Dunno if that
would get things wrong or not.

Thoughts?

[A.D. Fundum]

Post by Mike Luther
I did get it to install with the Warpin installer and the period
punctuation marks

Grab a copy of the Association Editor, and check if there's an entry
which matches a pattern like *.*.*.WPI. Adding it maqy help, including
associating the new entry with WarpIN.


--

[Peter Brown]

Hi Mike

Post by Mike Luther
Thanks Peter

Post by Peter Brown
Hi Mike
Looks like it wants the wpi packaged version of libc064 -
ftp://ftp.netlabs.org/pub/gcc/libc-0.6.4-csd4.wpi
Regards
Pete

Yes. Correct. However interestingly, for you to be able to look at what
is inside this netlabs package withthe Warpin viewer tool, you have to
change the internal period character marks to an underline character in

Post by Peter Brown
2-01-12 7:18p 1402968 70 libc-0_6_4-csd4.wpi

I did get it to install with the Warpin installer and the period
punctuation marks, didn't try it as changed with the underline
characters. Dunno if that would get things wrong or not.
Thoughts?

libc-0.6.4-csd4.wpi opens fine with the WPIView app here :-)


Regards

Pete

[Steven Levine]

On Fri, 3 Feb 2012 00:07:43 UTC, Peter Brown

Post by Peter Brown
libc-0.6.4-csd4.wpi opens fine with the WPIView app here :-)

eCS 2.1 contains a fix for the multiple dot issue. The AssoEdit
workaround is no longer needed.

Steven

[Remy]

Post by Steven Levine
On Fri, 3 Feb 2012 00:07:43 UTC, Peter Brown

libc-0.6.4-csd4.wpi opens fine with the WPIView app here  :-)

eCS 2.1 contains a fix for the multiple dot issue.  The AssoEdit
workaround is no longer needed.
Steven
--
---------------------------------------------------------------------
eCS/Warp/DIY etc.www.scoug.comwww.ecomstation.com
---------------------------------------------------------------------

There is a new klibc_0.6.4 since a few days (works better than
previous one)
ftp://ftp.netlabs.org/pub/gcc/libc-0_6_4-csd4.wpi

I updated clamav 0.97.3 wpi package too (installer works better now)
Cheers/2

I'm working on clamavgui v3 which progressed a lot with end user
feedback like doug, Ed etc...
This version will be a major upgrade
(I hope having it ready soon... )

[Allan]

Post by Mike Luther
Thanks for the quick response Allan

Post by Allan

Post by Mike Luther
Few word question. Do I have to go back into my hand modified CONFIG.SYS and
remove the SET UNIXROOT=C:\CLAMAV I added? Or is it still needed?

This build does not use UNIXROOT at all.
You can remove it, if you don't need it for other things.

OK tried this. freshclam.exe and clamscan.exe work just fine from your new
download. That of course with the freshclam.conf set up for my US download mod
in the file.
However, interestingly, clamd.exe will not work at all here without the old
UNIXROOT setup in the CONFIG.SYS for some reason. The test MCP2 system as was
originally set up for your work has the following lines changed in clamd.conf

Ah, there is a package difference. The new package has put clamd.exe into sbin dir.
You are most likely still trying to use your old clamd.exe in bin dir.
Just move the new one from sbin to bin

Post by Mike Luther

Post by Allan
#Example
LogFile /tmp/clamd.log
LogFileUnlock yes

You might need to set
LocalSocket \socket\clamd
in conf file too

[Mike Luther]

Thanks again Allan

Post by Allan
Ah, there is a package difference. The new package has put clamd.exe into sbin dir.
You are most likely still trying to use your old clamd.exe in bin dir.
Just move the new one from sbin to bin

Yes, but for future thought I just copied it there and it works now.

Which brings another question. Is this an issue with the .WPI install that
gave me an object in the CLAMAV desktop folder that pointed originally to the
the C:\CLAMAV\bin directory as the operating directory with the file as
defined c:\CLAMAV\bin\clamd.exe? That in the 'future' for all this would be
in this sbin directory where it got with your new ZIP overinstaller? Or
would it in final operations actually get normally put in the CLAMAV\bin
directory and not in the sbin directory all by itself there?

Post by Allan

Post by Allan
#Example
LogFile /tmp/clamd.log
LogFileUnlock yes

You might need to set
LocalSocket \socket\clamd
in conf file too

OK, but what does this do in the operation of all this? And should this be
LocalSocket /socket/clamd really? Plus my old documentation for this looks
like it originally was LocalSocket socket.clamd as originally there.

Thanks!

[Allan]

Post by Mike Luther
Which brings another question. Is this an issue with the .WPI install that
gave me an object in the CLAMAV desktop folder that pointed originally to the
the C:\CLAMAV\bin directory as the operating directory with the file as
defined c:\CLAMAV\bin\clamd.exe? That in the 'future' for all this would be
in this sbin directory where it got with your new ZIP overinstaller? Or
would it in final operations actually get normally put in the CLAMAV\bin
directory and not in the sbin directory all by itself there?

There is no 'right' answer to this currently. This ClamAV build was mostly a
'quick and dirty' build - and only checked for ability to run at all. I managed to get
Paul Smedley to do this for us - and I did all the tests.
I can't say how much time Paul can put into this - if any at all - but I am pretty
sure, that a few donations might help :-)

About WPI, I don't really know what we should do right now.
IMO, if we can get Paul to build new versions in future in plain ZIP,
then I think it would be smarter for all if Remy could adopt these into
his own complete WPI package including his GUI.
That makes it easier for him to test and know positions of clamav files too.

But, lets see what future gives us. Only thing I can say is, that Yuri did a great
job for us previously - and it is a shame, he will only deliver RPM-contaminated
builds in future.

Post by Mike Luther

Post by Allan
You might need to set
LocalSocket \socket\clamd
in conf file too

OK, but what does this do in the operation of all this? And should this be
LocalSocket /socket/clamd really? Plus my old documentation for this looks
like it originally was LocalSocket socket.clamd as originally there.

If ClamD does'nt work for you, just try all of them, until you find one that works ;-)

[Paul Ratcliffe]

Post by Mike Luther
Sorry about all the words, but there is also a very bad little understood
issue about that whole deal too. The original 'install' I worked with you
from automatically puts that line at the bottom of the CONFIG.SYS file. Which
actually, in some cases, can cause a fatal boot error in some versions of
MCP2. There are some USB device drivers in which the absolute last line in
your CONFIG.SYS file must be a related line device driver and option choice!
Which we discovered long ago can totally trash later ThinkPad installations.

Post by Allan
SET SNAP_INTCURSOR_DISABLE=Y

Which in the case of at least the ThinkPad issues, to prevent hangups, must be
the line just above the USB driver line I don't have access to on this box. If
you are using SNAP for OS/2.

What a load of of old waffle, bullshit, bollocks and drivel.

Post by Mike Luther
As well, in some variations of motherboard installations, there is also an
older OS/2 install/boot glitch which makes it necessary that at least one
blank line must be at the bottom of your CONFIG.SYS file. That to prevent
OS/2 networking glitches which were present in up through pretty latest MCP2
installs and FixPacks. Persuant to what we discovered when I was on the
external test site operations for the official OS/2 test team for many years.
Just simply adding a forced UNIXROOT line in CONFIG.SYS this way may not
affect eCS operations. But it can trash a fairly large group of other OS/2
operations from my experience. FWIW ..

Oh FFS, shut up.

[A.D. Fundum]

Post by Mike Luther
Do I have to go back into my hand modified CONFIG.SYS
and remove the SET UNIXROOT=C:\CLAMAV I added?

Since C:\CLAMAV isn't "the" Unix root directory and just ClamAV
requires it, one may consider adding such a SET= to a WPS setup string
instead of adding it to CONFIG.SYS. With the added bonus of not
having to reboot to use such a setting.


--

[Mike Luther]

Hello friend!

Post by A.D. Fundum

Post by Mike Luther
Do I have to go back into my hand modified CONFIG.SYS
and remove the SET UNIXROOT=C:\CLAMAV I added?

Since C:\CLAMAV isn't "the" Unix root directory and just ClamAV
requires it, one may consider adding such a SET= to a WPS setup string
instead of adding it to CONFIG.SYS. With the added bonus of not
having to reboot to use such a setting.

Sort of where I was going. As an opinion here, it's obvious to me that if I
do have to put a SE=t+ in the CONFIG.SYS to get this to work at all and in my
case plus others around me that there is no C:\PROGRAM directory at all like
is present in the Windows computers, having to force C:\CLAMAV this way would
very badly contaminate all of the older MCP2-whatever operations. If we
needed to add some other single 'program' application that also might be
already on such a group of systems - water production units - railroad
operations - massive money printing operations; whatever, then we actually
would be, in my opinion, further hurting OS/2 for a future. Obviously anyone
with a ton of heavily dedicated water operations computers that a good future
for CLAMAV might appear for, that had a link toward Linux/Unix/Aix, toward
solid secure OS/2 now, wouldn't want anything like what might be in
'C:\WATEROP' or 'C:\LOCO' next confused with SET= 'C:\CLAMAV' as a patch to
all this.

My thoughts. However as we know here, more words... no smiley ..

[A.D. Fundum]

Post by Remy

Post by Allan
Docs need to say these are needed, and where to get
them. Don't do your own install of these.

This is exactly what the WPI does

AFAIK AFA WPI knows, so it isn't "exactly".

Post by Remy
warning message if Gcc and Klib are not at correct level

That's better, an ignorable warning instead of a fatal error message.


--

[Allan]

Post by Remy
This is exactly what the WPI does (warning message if Gcc and Klib are
not at correct level)
Other dll are mixed under different kind of rpm package on netlabs
making them difficult to get and of course, no readme exist under
netlabs to tell dlls level requirements.

http://sourceforge.net/projects/ecsports/files/clamav-0.97.3-os2-20120131.zip/download

This is 0.97.3
It requires libc064 and no more

it has a builtin forced path as /clamav/... just as it is packaged;
but parameters can override these as usual.

Might be easier to work with than the RPM builds :-)

[Mike Luther]

Hi Allan

Post by Allan
http://sourceforge.net/projects/ecsports/files/clamav-0.97.3-os2-20120131.zip/download
This is 0.97.3
It requires libc064 and no more
it has a builtin forced path as /clamav/... just as it is packaged;
but parameters can override these as usual.
Might be easier to work with than the RPM builds :-)
11-24-11 10:40p 2909132 79 Clamav-0_96_4-4b.wpi

Which as noted worked for me without any SET path in the CONFIG.SYS except for
the clamd.exe which I could still not get to work without the old setting in
the modified CONFIG.SYS as I posted earlier to you. Maybe this post will help
clean things more.

Thanks to all of you!