2Bogdan:
> I only know about the private Github company. Does it mean that BWW offers a similar service for the public?
What do you mean? Most Github projects are opensource and provide sources and binaries
for free, including BWW. So, BWW repos are public, not private (only commercial sources are not
public, like InJoy, for example).
>>> Sorry we are in 2018 now, I cannot see any reason for a fork of 10 year old code, where created binary packages don't follow the terms of the licence agreement and additionally are incomplete or break compatibility in different ways.
>> Do you think that fork is something bad? Anybody can fork any software with opensource license,
and add his own enhancements.
>... under the restrictions of the licence agreement and the copyright. But that depends on local law.
InfoZIP seems to be under BSD-like license. BWW provide packages under the same license. So, what
terms they don't follow?
>> Moreover, forks are encouraged with git, where multiple repositories
with the same program exist, and they may copy changes from one to another.
>git is only a version control software that encourages nobody. I don't know about a special AI improvement or module that would offer this feature.
Git and GitHub makes it easy to create and merge forks. Forks are just a convenient way to create
modified versions of sources. Fork doesn't denote anything bad. So, there's nothing bad that BWW
created a fork. This fork could be in the future merged into an original version, but this requires time.
> InfoZip releases of zip or unzip don't require any patches. They built on native OS/2 supported environments or can be cross-compiled from other development environments.
These patches are old and InfoZip cannot thoroughly test the OS/2 code with newer versions. Simply
because they don't use OS/2 for everyday use. So, they can break something in new versions, without
noticing it. That's why newer versions can cointain bugs (related to combination of old OS/2 patches
with newer InfoZip code). So, this require fixes, which is done by BWW. So, no wonder if they require
modifications.
The OS/2 patches to InfoZip are very old, they were created by Kai Uwe Rommel in 90'ths. And I doubt
that this code was updated much by InfoZip.
>> Also, there are some enhancements like kLIBC symlinks support. I doubt that this feature present in
InfoZip version.
> Please provide the necessary information so I can answer the question. Do you mean symbolic links? The Zip format is from the PC DOS world and has only limited support for UNIX features. Hard link and symbolic link support can be provided with UNIX Extra Field, but seems to be useless for non-UNIX environments. Who wants to restore UNIX device names under OS/2?
This is you are kidding, or serious? Yes, symbolic links. Don't you know that kLIBC contains symlink support?
No, it is not useless on non-UNIX environment. It is very useful in case you backup/restore your UNIX ports tree.
This tree contains many symlinks in /@unixroot/usr/bin subdirectory, for example. I suspect that you'll not like
if after restoring the UNIXROOT from backup, your symlinks are broken? And yes, InfoZIP contains support for
symlinks on UNIX environments (the same as ACL and EA's support on OS/2 platform), so, it can be desirable
to have symlinks support on kLIBC too. This is one reason for creating patches to original version.
>>Did you tried to build InfoZip yourself?
>I cannot count the platforms and different C compilers here, but mostly C/370 or the AIX C set.
So, you didn't tried to build the OS/2 version, ok.
>Which version of OpenWatcom was utilised? I remember of building it 20 years ago with Watcom C compiler for OS/2 and NT with the supplied makefile from an OS/2 hosted environment.
I used OW 1.9 I mean that there were some problems with calling a 16-bit API from netapi.dll for OS/2
ACL support. OW is good with building 16<->32 bits thunks, at least, I was able to create 16-bit wrappers for
32-bit DLL (a FS utility DLL from fat32.ifs, for example). So, this should work, though, I was unable to build
wrappers for ACL code in zip.exe. That's why I wonder how this was worked around in GCC builds. Maybe, they
just dropped the ACL code. I don't know.