OS2.org Forum

Hallo,
ich habe Warp 3, 4 und 4.52 unter Virtualbox 7.0.4 in Arch-Linux als VM installiert.
Alle 3 funktionieren an sich, auch mit 1600x1200 SVGA.
Unter Warp 3 funktioniert auch sonst alles (auch mit SMP), z.B. emx-0.9d.

Unter Warp 4 und 4.52 führt der Aufruf aller Unzip-Versionen zu SYS3170.
Dasselbe gilt für einige andere HIlfsprogramme, die ich getestet habe.
Warpin-1-0-26 läßt sich auch nicht installieren.

Ich habe viele Virtualisierungsoptionen ausprobiert (Nested paging an/aus,
PAE/NX an/aus, Standard/KVM/Hyper, 1-4 CPU's ...): immer das gleiche Spiel.

Ich habe die Config.sys von 3, 4 und 4.52 verglichen und nichts Auffälliges gefunden.

Ich kann kein unzip installieren, damit auch keine gezippten Hilfsprogramme und
alle exe's, die ich aufspiele liefern SYS3170 zurück.

Was mich wundert ist, daß unter dem älteren Warp 3 alles funktioniert (unter jm
Graphik nur das PM-Fenster (VESADLL=VESA_PM), aber immerhin).

Kann mir jemand erklären, was los ist ?

Von unzip kurven etliche Versionen und deren Fassungen in den Archiven... Die neueren "v.6.00" aus ANPM erfordern einiges vorab, mehr (nicht nur) dazu z.B. über https://ecsoft2.org/ zu finden.
Nebenbei: die dort erwähnte "v.6.0.5" hatte sich hier als nicht ganz korrekt gezeigt, weiß aber nicht mehr wieso..

Fürs erste würde ich Dir eine ältere "v.5.52" empfehlen, die hatte hier unter Warp4.x lange gearbeitet und ist m.E. auch heute noch brauchbar - außer für Dateien>2GB, zu finden hier: http://www.os2site.com/sw/util/archiver/zip/unz552.exe (selbstentpackend).
Eine ältere "v.6.0" von hier: https://os2ports.smedley.id.au/?page_id=164.

Aber anscheinend liegt noch ein ganz anderes Problem vor, wenn eigentlich Bewährtes abstürzt. Ja blöd, Unzip und Warpin sollten besser laufen

Vielleicht kann hier jemand was mit dem Trap-Screenshot anfangen? Edit:.. bzw. popuplog.os2

Danke für die schnelle Antwort Lothar.

Dein unzip552 liefert bei den 32-bit Versionen bei Aufruf von unzip.exe und unzipsfx.exe ein hängendes DOS-Fenster und
bei Aufruf von funzip.exe SYS3170 (Screenshot angehängt).

Die 16-bit Versionen liefern bei Aufruf SYS3170.

Die Exe's von unzip60-os2-20100530.zip aus dem von Dir angeführtem Link liefern SYS3170.

Alle von mir probierten selbstentpackenden Exe's verhalten sich wie oben, meist SYS3170.

Heinrich hat geschrieben: ↑Do 22. Dez 2022, 14:25 ... ein hängendes DOS-Fenster ...

tatsächlich, oder nur ein Tippfehler (gemeint "OS/2-Fenster") ?

Es sollten auch Einträge dazu in c:\popuplog.os2 vorhanden sein. Vielleicht stehen noch weitere Infos darin.

Wenn so vieles abbricht, sogar schon auf Kommandozeile, hätte ich eine zum Kernel unpassende DOSCALL1.DLL in erstem Verdacht.

@Lothar
danke,
leider kein Tippfehler: nach dem Aufruf von unzip im OS2-Fenster verwandelt sich dieses in eins mit DOS Titel,
welches hängt. Nach Betätigen von "Close" wird's wieder eines mit OS2 im Titel.

Das mit c:\popuplog.os2 habe ich jetzt - verzögert - mitgekriegt. Werde heute Abend da mal nachschauen.

"... hätte ich eine zum Kernel unpassende DOSCALL1.DLL im Verdacht" - Würde ich gerne glauben wollen, aber wieso
sowohl bei Warp 4 wie 4.52 ? Und woher die richtige nehmen ? Ich kann ja aufgrund der beschriebenen Probleme auch
keine Fixpacks installieren - oder doch ?

Ich vermute, all das hat damit zu tun, dass die OS2's in virtuellen Maschinen laufen. Nach meinen Internetsuchen
scheinen Warp 4 und 4.52 auf realer Hardware ja zu funktionieren. Aber bin ich wirklich der einzige, der Warp 4
und 4.52 in VM's installiert hat ?

Aufruf von unzip im OS2-Fenster verwandelt sich dieses in eins mit DOS Titel,
welches hängt. Nach Betätigen von "Close" wird's wieder eines mit OS2 im Titel.

Dann scheint wohl eine DOS Version von unzip.exe im Pfad vor der OS/2 Variante zu liegen. Nur eine wage Vermutung weil ich grad kein OS/2 System hier habe und deshalb nicht nachsehen kann, was SYS3170 bedeutet - ev. läuft das ganze DOS Subsystem nicht? Wegen unzureichender Graphikemulierung?

Andi B. hat geschrieben: ↑Do 22. Dez 2022, 16:59
Aufruf von unzip im OS2-Fenster verwandelt sich dieses in eins mit DOS Titel,
welches hängt. Nach Betätigen von "Close" wird's wieder eines mit OS2 im Titel.
Dann scheint wohl eine DOS Version von unzip.exe im Pfad vor der OS/2 Variante zu liegen.

Hier zum Vergleich meine Dateien zu unzip v.5.52:

Code: Alles auswählen

 Verzeichnis von E:\tools\packtool\unzip552
24.11.11  8.00          <DIR>      0 ----  .
 9.06.20  9.26          <DIR>    507 ----  ..
18.07.00  0.00         10.245      0 ----  COPYING.OLD
 6.04.05  0.00            132      0 ----  file_id.diz
 6.04.05  0.00         50.227      0 ----  funzip.exe
 1.03.05  0.00          4.180      0 ----  funzip.txt
10.02.05  0.00          3.088      0 ----  LICENSE
 1.03.05  0.00         14.803      0 ----  README
 6.04.05  0.00        147.507      0 ----  unzip.exe
 1.03.05  0.00         52.862      0 ----  unzip.txt
 6.04.05  0.00         95.283      0 ----  unzipsfx.exe
 1.03.05  0.00         15.236      0 ----  unzipsfx.txt
17.02.05  0.00         13.024      0 ----  WHERE
 4.01.96  0.00          2.116      0 ----  zip2exe.cmd
19.07.93  0.00          1.601      0 ----  zipgrep.cmd
 1.03.05  0.00          3.603      0 ----  zipgrep.txt
 1.03.05  0.00         25.291      0 ----  zipinfo.txt
        17 Datei(en)     439.198 Byte belegt

Die ältere v.6.0 stammt hier von http://www.os2site.com/sw/util/archiver ... 100530.zip

Verwenden tu ich aber die (un)zip aus ANPM, melden sich ebenfalls als v.6.00 bzw. v.3.0. eCS und ArcaOS seit Jahren glatt in VBox-VMs.

@Andi
keine version von unzip ausser der jeweils aufgerufenem im Pfad.
DOS-Fenster kann ich benutzen, allerdings nichts darüber installieren.

@Lothar
c:\popuplog.os2 enthält nur SYS3170 Meldungen und ihre Registerauszüge.

Meine unzip552 Dateien sind dieselben. Die (un)zip aus ANPM, habe ich eben auch probiert
- keine Änderung. Was doscall1.dll angeht:

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

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

Folgt daraus irgendwas ?

Unter Warp 4 ließ sich problemlos der Snap Graphiktreiber installieren, der
anscheinend auch einen Fixpack15 mitbringt, aber sonst hat nichts geklappt.

Ich habe die Warp Varianten nach der sehr guten Anleitung
"https://gekk.info/articles/os2.html"
installiert, danach unter Warp 3 emx-0.9-d und Weiteres.

Ich meine SNAP bringt in einer virtualisierten Umgebung nichts. Die GuestAdditions haben meines Wissens eh einen eigenen GRADD Treiber dabei. Könnte man z.B. auf den betreffenden ArcaNoae Seiten nachlesen.

Das unzip welches ich verwende -

Code: Alles auswählen

{0}[m:\] dir p:\usr\bin\unzip.exe

 Volume in drive P is Apps2          Serial number is ECAE:35C1
 Directory of  P:\usr\bin\unzip.exe

12.06.20  20.17          92.069    124   ___A_  unzip.exe
          92.069 bytes in 1 file and 0 dirs
          94.208 bytes allocated
  26.633.547.776 bytes (24GB) free

{0}[m:\] chkdll32 p:\usr\bin\unzip.exe
Loading DLL 'libcn0' --> P:\USR\LIB\LIBCN0.DLL.
Loading DLL 'libcx0' --> P:\USR\LIB\LIBCX0.DLL.
Loading DLL 'bz2' --> P:\USR\LIB\BZ2.DLL.
Loading DLL 'gcc1' --> P:\USR\LIB\GCC1.DLL.
Loading DLL 'doscalls' --> loaded.
Loading DLL 'nls' --> M:\OS2\DLL\NLS.DLL.
All DLL's used by 'p:\usr\bin\unzip.exe' could be loaded.

{0}[m:\] unzip -v
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.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 9.2.0 20190812 (OS/2 RPM build 9.2.0-4.oc00) for OS/2 and OS/2 based
 systems on Jun 12 2020.

UnZip special compilation options:
        ASM_CRC
        COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
        OS2_EAS
        SET_DIR_ATTRIB
        SYMLINKS (symbolic links supported, if RTL and file system permit)
        TIMESTAMP
        UNIXBACKUP
        USE_EF_UT_TIME
        USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
        USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
        LARGE_FILE_SUPPORT (large files over 2 GiB supported)
        ZIP64_SUPPORT (archives using Zip64 for large files supported)
        USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.8, 13-Jul-2019)
        VMS_TEXT_CONV
        [decryption, version 2.11 of 05 Jan 2007]

UnZip and ZipInfo environment options:
           UNZIP:  [none]
        UNZIPOPT:  -C
         ZIPINFO:  [none]
      ZIPINFOOPT:  [none]
             EMX:  [none]
          EMXOPT:  [none]

{0}[m:\]

@Andi
Die GuestAdditions funktionieren nicht unter Warp 3 - deshalb braucht es hier SNAP.
Warp 4.52 bringt einen VESA Treiber mit.

chkdll32 ist bei meinem Warp 4.52 nicht vorhanden - ist das eine native OS2 exe ?
Ich habe schon vermutet, dass dll"s fehlen oder eine falsche Version haben und
so etwas wie ldd unter Linux schmerzlich vermißt.

Was ich nicht verstehe: in einem ! OS2 Fenster ! kriege ich:
[D:\bin]chkdll32-102.exe
SYS1057: The file or path name entered is invalid in a DOS session.

Andi B. hat geschrieben: ↑Do 22. Dez 2022, 20:29 Ich meine SNAP bringt in einer virtualisierten Umgebung nichts. Die GuestAdditions haben meines Wissens eh einen eigenen GRADD Treiber dabei. Könnte man z.B. auf den betreffenden ArcaNoae Seiten nachlesen.

Irrtum, die Gasterweiterungen liefern zwar eine gengradd.dll mit, aber den SNAP-_Treiber_ muss man schon instalieren incl config.sys-Einträgen. Mehr nachzulesen auf dieser ArcaNoae-Seite. Nur die libc*.dll sollte man aus ANPM nehmen so man hat.

Warum die Gasterweiterungen nicht unter Warp3 funktionieren sollen? mag ja sein, aber kaum _des_wegen Snap, sondern in VBox-OS/2-VMs geht vernünftig sowieso nur Snap (neben (S)VGA ). (Hatte einstmals mit Panorama getestet und sofort wieder gelassen.)

Suspekt überhaupt, wieso eine cmd.exe zu einer command.com mutiert und umgekert? Aus Routine einfach mal den Ordner "Befehlszeilen" durchgehen und zu jedem Objekt darin die "Einstellungen->Sitzung" prüfen. Außerdem in der config.sys LIBPATH/PATH-Rihenfolgen prüfen (os2.. sollte vor mdos... liegen). Btw: was passiert, wenn unzip.exe mal mit seinem vollen Pfad aufgerufen wird? Was passiert im Fullscreen-Aufruf, nur zum Spaß?

Oder aber - wohl am saubersten - die Warp4.x schrittweise frisch neu installieren, geht in VBox ja mit *iso-Files ja relativ bequem..Ansonsten hätte ich zu alten Warp' nur Erinnerungslücken zu bieten

LotharS hat geschrieben: ↑Do 22. Dez 2022, 22:44 zu jedem Objekt darin die "Einstellungen->Sitzung" prüfen.

Ließe sich auch mit dem Programmobjekt zu "unzip.exe" usw. machen, ob da was auffällt oder nicht.

Gelöst. Ich habe alles Vorgeschlagene ausprobiert und mehr ... Aber - wie ich insgeheim befürchtet hatte - es war etwas ganz Blödes:

Ich hatte alle Zip- und selbstentpackende Exe-Dateien und Linux heruntergeladen und dann mit dem Ftp-Programm von OS/2 abgeholt. Bei Warp 3 war da auch nichts zu beachten - hat alles geklappt. Beim Ftp-Client von Warp 4/4.52 hätte ich allerdings den Binärmodus explizit einschalten müssen. Als ein warpin-1-0-22 von einem Iso-Image funktioniert hat und das von mir per Ftp übertragene nicht, hat's mir irgendwann gedämmert, daß früher so was gelegentlich nötig war. Deshalb waren bei Warp 4.x alle binären Dateien beschädigt und zwar so, daß es zu den berichteten obskuren Fehlermeldungen kam. Mit der Eingabe von "binary" am Anfang der Ftp-Sitzung hat dann auch unter Warp 4.x alles funktioniert.

Ich benutze seit Urzeiten ncftp für Ftp-Übertragungen. Ncftp schaltet(e) automatisch in den Binärmodus (was der Ftp-Client von Warp 3 entweder auch tut, oder er läuft per default im Binärmodus).

Herzlichen Dank an Lothar S. und Andi B.

Ein gutes Neues,
Heinrich

OS2.org Forum

Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170

Re: Warp 4/4.5 unter Virtualbox: unzip, emx ... nicht installierbar - SYS3170