Mail Archives: djgpp/2000/07/20/12:16:13
I hope this might present interest, at least informational, for DJGPP community.
PW32 the Posix-over-Win32 version 0.6.0 has been released.
PW32 is an implementation of the (subset of) POSIX/Unix API for Win32
systems. Its main concerns are efficiency and full platform coverage,
including adequate support for low-end Win9x systems. PW32 is based
on DJGPP's runtime library by DJ Delorie. PW32 is licensed under LGPL.
Also, PW32 is a collection of software ported with PW32 library. The aim
is to have comprehensive GNU/Win32 distribution, easily installable,
and correctly and efficiently working.
Homepage: http://pw32.sourceforge.net
Some statistical bragging:
This is 5th PW32 release, while being in public for 4 months.
PW32 (including ported software) was downloaded 2600+ times.
PW32 is in top 3% of most active SourceForge projects.
Changes since 0.5.0:
Overall:
Binary incompatible:
PW32 0.6.0 is not binary compatible with previous versions. This
means you need to reinstall (rebuild) all packages for (with) new
version.
Ported software:
Almost all core and development GNU packages have been built
(though, gcc/binutils still used from Mingw32 distribution).
So, selfhosting within reach.
Workability/testing:
PW32 0.6.0 has undergone extensive testing under Win95 and
Win2000. Most package run with no or little problems. For
example, all 'simple' packages (grep,sed,m4,textutils) have
regression testsuite fully passed, gawk has 1 failed (of 88)
total, bash 6 failed, autoconf 1 failed (of 98), automake
2 failed (of 249), perl 20 (of 6440), etc. Many of these
failures are due to inavailability of some tested feature
(bash compiled without readline) or dependence on non-PW32
program (mingw32 gcc outputs dependencies with native path
syntax and don't understand symlink, what confuses automake).
Packaging conventions:
Packages format and conventions seem to be settled. They are
based on DSM (DJGPP Software Manifest),
http://www.phekda.freeserve.co.uk/richdawe/zippo/dsm.htm ,
augmented and generalized a bit. There's currently no
package manager, but all 0.6.0 package come in this format
(and there's utility to help create packages). Using/choosing/
inventing yet another package format dicated by following aims:
- package must be simple archive (zip or tar/gz), so it can be
installed manually by simple unpacking in the proper place.
- simple unpacking is valid installation method (i.e. package
manager can work properly with packages installed in such way)
(btw, in this I seem to deviate from Zippo, "native" DSM package
manager).
Documentation:
Documentation tries to explain all these (and many other) things
in more detail ;-)
Runtime library:
Runtime-configuration:
I was opponent of allowing runtime configuration of
such thing as POSIX layer, but I surrender. New
environment variable, PW32_OPT, contains list
of comma-separated options which control some
PW32 features, either resource expensive or working
in non-obvious ways. So far there's two options:
'inode' and 'fncase' (see below).
File subsystem:
File information:
stat() functions now have method to return
proper inode number (i.e. two pathnames
identify the same file/directory on the
same device, it will have same inode number).
This is however works with finite level of
robustness: it seems to work ok for all
95/98/NT/2000 on FAT/NTFS, but doesn't work
on network drives (either "native" or samba).
Figuring out this proper inode number takes
some time, so currently it is enabled only
by PW32_OPT=inode settings. However, my
timings show that slowdown is not so big,
so maybe later this will become default.
Filenames:
Added support for using characters in
filenames, not allowed by Win32 (for example,
* or :). They are simply urlencoded/urldecoded
on the fly.
There was attempt to add case-sensitivity to
filename operations (PW32_OPT=fncase).
Unfortunately, it turns out that
case-sensitivity support of NT systems is fake,
and urlencoding capitals leads to many problems.
So, it's there, but doesn't work as it should.
Global system variables:
More global runtime library variables, such
as tzname was moved to namespace of the
client application (versus namespace of pw32.dll).
This allows to build programs which doesn't
include proper header, but declare such variables
themseleves.
Compliance/Compatibility:
Many changes were made, mostly to headers,
to be more POSIX/SUSV2/Unix compatible than
DJGPP is. As usually, Linux was used as the
reference in such cases.
Shared libraries:
Shared libraries (well, DLLs) now can be built.
- Raw text -