Unzip Version 6.0 hangs when booting to a commandline

[Lars]

prewrite.dll still expects %ETC%\klibcfg.ini to exist and contain the path transfomation rules. As much as I can tell from looking into prewrite.dll.
Which is the reason why it still fails when booted to commandline and a Unix ported app is invoked because it tries to use the "Prf" API to read the ini file which does not work without PM up and running.
I am going to glean binary parsing of INI files from  XWorkplace and implement a solution that can work without PM.

[Pete]

Hi Lars

I do not have an %ETC%\klibcfg.ini file but unzip works when booted to the Desktop so I doubt klibcfg.ini is involved in any way.


Regards

Pete

[Steven Levine]

As Alex mentioned, prewrite.dll has replaced klibccfg.dll.  I forget the exact reasons, but one was that defects showed up and the sources had gotten lost.  This happened early 2017.

FWIW, unzip from a command line boot should run normally when prewrite.dll is the hook DLL.  Prewrite checks if pmwp.dll is loaded and exits silently if pmwp.dll is not loaded.  This means that libcn0.dll will use only the built-in mapping rules.

[Lars]

Hi Steve,

yes I saw that you have come up with a replacement (the exact reason was that forked processes would not properly call the path rewriter DLL):
https://trac.netlabs.org/libc/ticket/190
https://trac.netlabs.org/libc/ticket/360

But even with prewrite.dll, when booting to a commandline, any Unix style app will hang, at least on my system.
The moment you call "PrfOpenProfile" will lead to a hang when you execute this from a boot commandline. Running without any prewrite hook dll will also lead to a hang but can be terminated via Ctrl-C.


@Pete: Note that I said "booted to a commandline" and not "booted to the desktop and using a commandline". This is as completely different pair of shoes as in the latter case, you have a fully working Presentation Manager environment.

Just give me some time of trial and error and I see where I end up.

@Steve: as a side question, can I assume that our gcc port has "__cdecl" as the standard calling convention ? Or would that be "__syscall" ? I assume the former but I am not sure.

[Pete]

Hi Lars

I was just pointing out that klibcfg.ini is not involved.

I also tried when booted to the command line: unzip hangs, Ctrl-C kills it.
I would guess some required DLL files are not found when booted to command line.


Regards

Pete

[Steven Levine]

Lars,

It appears you are not aware that the sources are available at https://svn.arcanoae.com/prewrite.   See \sys\doc\PREWRITE\prewrite.txt on an ArcaOS install.  Prewrite is effectively part of kLIBC, so this is required.

Are you sure you are running prewrite.dll v0.2.1?  Earlier releases did not check if PM was running.

The calling convention for the hook entry point is whatever kLIBC requires.  It's probably cdecl.  It's been a while since I looked at the sources.

Since you still get a hang if you remove LIBC_HOOK_DLLS from the environment, it would indicate you have two, possibly unrelated, issues.

[Lars]

By now I have written my own prewrite.dll. That works (I am directly parsing klibcfg.ini) but the inital problem remains:
Having booted to a commandline, the Unix ported unzip.exe will still hang but can be killed with Ctrl-C.
As you said, there must be yet another issue because having no HOOK DLL at all leads to the same hang.

[David Graser]

Just curious, how do you tell which version of unzip.exe you are using?  When I use bldlevel, I get no useful information.

[E:\usr\bin]bldlevel unzip.exe
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
unknown return code 4 from FileVerGetVersionStringFromFile
File unzip.exe has no LAN component-style version string.
No driver EA's were found

[E:\usr\bin]

Why does't pmdll show the prewrite.dll as one of the dll's used by unzip.exe?

[Lars]

1) Just run unzip without any parameters, and you get this:

UnZip 5.52 of 28 February 2005, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

or this:
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

What you need to know (or find out via exehdr.exe giving you some hints on what UNZIP imports) is that UnZip 5.52 is built the conventional way via VAC or Watcom compiler and UnZip 6.00 is built with kLIBC with gcc compiler.


2) prewrite.dll is not loaded via loadtime linking (that is, together with the start of the application) but via runtime linking (that is dynamically, via a call to DosLoadModule). PMDLL can only show DLLS that are loaded via loadtime linking because for these, the executable contains information with the names of the DLLs to load and the names of the function entry points into the DLLs.

[Dave Yeo]

Makefile.os2 actually supports a lot of targets, most of which are not maintained,

Code: [Select]

"Enter `make -f os2/makefile.os2 target' from the main"
"UnZip directory, where target is one of:"
"   msc mscdebug mscdos ibm ibmdyn ibmdebug ibmprof"
"   ibmdll ibmdyndll ibmdebugdll ibmprofdll"
"   metaware borland gcc gccdyn gccdebug gccdos gccwin32"
"   klibc watcom watcom16 watcomdos watcom16dos pmodew watcomwin32"

Previously I have built earlier versions with GCC.
Thought I'd try building with OW and VACCP3.08. Both fail on ctype.h,

Code: [Select]

wcl386 -bt=os2v2 -zq -Ox -s -I. -c -Zp1 -DOS2 -DASM_CRC   unzip.c
g:\WATCOM\h\ctype.h(72): Error! E1009: Expecting ')' but found '('
g:\WATCOM\h\ctype.h(72): Error! E1094: Function cannot return a function
g:\WATCOM\h\ctype.h(72): Error! E1094: Function cannot return a function
g:\WATCOM\h\ctype.h(72): Error! E1044: Variable 'IsUpperNLS' has incomplete type
g:\WATCOM\h\ctype.h(72): Error! E1026: Invalid declarator
g:\WATCOM\h\ctype.h(72): Error! E1009: Expecting ',' but found ')'
g:\WATCOM\h\ctype.h(72): Error! E1026: Invalid declarator
...
more similar errors for isxdigit(), ToLower(), ToUpper(), isblank() with some using the NLS version.

Code: [Select]

        icc -Q -O -Gs -I. -c -Sm -Sp1 -DOS2   unzip.c
os2/os2cfg.h(29:11) : warning EDC0236: Macro name tzset has been redefined.
os2/os2cfg.h(152:8) : warning EDC0234: Expecting a new-line character on #endif directive.
G:\OS2TK45\H\LIBC\ctype.h(50:33) : error EDC0275: Unexpected text '(' encountered.
G:\OS2TK45\H\LIBC\ctype.h(50:23) : error EDC0033: Function IsUpperNLS is not valid. Function cannot return a function.
G:\OS2TK45\H\LIBC\ctype.h(50:33) : error EDC0172: Parameter type list for function IsUpperNLS contains parameters without identifiers.
G:\OS2TK45\H\LIBC\ctype.h(50:33) : error EDC0276: Syntax error: possible missing '{'?

with more errors in stdlib.h and lots of syntax errors as well as others in unzpriv.h and then in unzip.c

I guess I just don't understand C++ very well as the ctype.h errors seem weird. Also very little experience with the compilers.

nmake or make with MAKESHELL=cmd.exe work, wlink even with the recommended parameters like -ms fails, differences from Watcom?

[Lars]

Hi Dave,

my experience with VAC 3.08 is that you need to use the header files that go along with it instead of using the header files of the Toolkit.
But I think this whole case is hopeless. The only solution is to avoid kLIBC built binaries when having booted to a commandline.

[Rich Walsh]

Attached is a standalone version of 'unzip.exe' v6.0 compiled with VACPP 3.65. I have only done minimal testing on this.

Also attached is a diff of the changes. Most of the compile errors came from "#include <ctype.h>" being mispositioned in 'os2cfg.h'; moving it up in the file fixed them. I also added a "vac" target to 'makefile.os2'. It's set up for VAC 3.65 but should(?) work with 3.08.

[Lars]

Thanks Rich, this is really appreciated, Ill give it a try.
A general fix for this problem would be great, I looked into libc but the process startup/DLL init/term code is so complicated that I cannot follow.
I already found it kind of frustrating that you have to build the rewriter DLL with gcc because of fork support but oh well, it's the way it is.

[Dave Yeo]

Rich, your patches work with VACPP 3.08 plus the os2tk45 headers and libs. Adding #include <ctypes.h> to the Watcom section of os2cfg.h also fixed the OpenWatcom build, which compiled with only a few warnings about comparisons always equaling zero.
Attached, OW build of unzip

[Martin Iturbide]

Hello

What is causing that the gcc unzip works on normal boot and does not run on F2 boot?
Is it prewrite? or it remains a mystery?

Regards