Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Lars

Pages: [1] 2 3 ... 56
1
Applications / Re: Running old OS/2 Software - Issues
« on: September 17, 2021, 01:26:58 am »
I have attached opendlg.lib from th V1.3 toolkit.
That is no longer needed for 32- bit code.

2
Applications / Re: Running old OS/2 Software - Issues
« on: September 17, 2021, 01:25:50 am »
OK, that made the compiler dislike C++ type comments :) After fixing and adding a missing include, seems to work.
I'll package it after work and post the fixed package.
The /Ss switch did the trick. That allows C++ comments in C code. I did not say to remove that 😂

3
Applications / Re: Running old OS/2 Software - Issues
« on: September 16, 2021, 12:15:38 pm »
What I normally use is this:
/Ge+ (when building an Exe)
/Gm+ (using the multi threaded libs, see following explanation)
/Gd+ (linking the RTL dynamically and therefore cut down on Exe size)

If you use these switches, the final step that you can do is to replace the name of the multi threaded RTL with one that comes as part of every OS/2 installation.
On the created Exe, run this:
Code: [Select]
dllrname.exe present.exe CPPOM30=OS2OM30
Of course, you could add this to the makefile.

That will replace all references to CPPOM30.DLL with OS2OM30.DLL which is always present in OS2/DLL directory.

I am talking about VAC 3.0 and not VAC 3.65 or VAC 4.0.

4
Applications / Re: Running old OS/2 Software - Issues
« on: September 15, 2021, 03:10:02 pm »
1) I suspect that OPENDLG.LIB was a library that was necessary to build a OS/2 version 1.3 PM application. Of course, the question is, why is it still listed in the makefile ? Maybe that was an omission to remove it.

2) I suspect that problem with CPPOS30.LIB is that it follows a newer OMF library format than what LINK386 understands. The easiest thing is to replace "link386" with "ilink /NOFREE". /NOFREE will force ilink to follow the same command line syntax as LINK386 but it will be able to link to CPPOS30.LIB.
In any case, it is not wrong to link to the RTL dynamically (but it might be a better idea to link against CPPOM30.LIB, that is, specify /GM+ as compiler switch: link multi-threaded).

David, can you post the makefile as you have corrected it ?

5
Setup & Installation / Installing Python 3 (from netlabs exp) does not work
« on: September 09, 2021, 10:15:48 am »
I had nothing better to do so I attempted to install python 3 via ANPM.
I get this error:

python-pycurl-7.19.5.1-2.oc00.pentium4 benötigt python27.dll

However, I do have a file "python27.dll" in \usr\lib and I have no probs at all with the currently installed python 2.7.

I then tried:

yum install python3 and get this:
Code: [Select]
Einrichten des Installationsprozess
Löse Abhängigkeiten auf
--> Führe Transaktionsprüfung aus
---> Paket python3.pentium4 0:3.9.5-5.oc00 markiert, um installiert zu werden
--> Verarbeite Abhängigkeiten: python3-libs = 3.9.5-5.oc00 für Paket: python3-3.9.5-5.oc00.pentium4
--> Verarbeite Abhängigkeiten: python39.dll für Paket: python3-3.9.5-5.oc00.pentium4
--> Führe Transaktionsprüfung aus
---> Paket python-libs.pentium4 0:2.7.6-25.oc00 markiert, um veraltet zu werden
--> Verarbeite Abhängigkeiten: python-libs = 2.7.6-25.oc00 für Paket: python-2.7.6-25.oc00.pentium4
--> Verarbeite Abhängigkeiten: python27.dll für Paket: yum-metadata-parser-1.1.4-7.oc00.pentium4
Package python-libs is obsoleted by python3-libs, but obsoleting package does not provide for requirements
--> Verarbeite Abhängigkeiten: python27.dll für Paket: python2-rpm-4.13.0-19.oc00.pentium4
Package python-libs is obsoleted by python3-libs, but obsoleting package does not provide for requirements
--> Verarbeite Abhängigkeiten: python27.dll für Paket: python-2.7.6-25.oc00.pentium4
--> Verarbeite Abhängigkeiten: python27.dll für Paket: python-pycurl-7.19.5.1-2.oc00.pentium4
Package python-libs is obsoleted by python3-libs, but obsoleting package does not provide for requirements
---> Paket python3-libs.pentium4 0:3.9.5-5.oc00 markiert, um obsoleting zu werden
--> Führe Transaktionsprüfung aus
---> Paket python.pentium4 0:2.7.6-25.oc00 markiert, um veraltet zu werden
--> Verarbeite Abhängigkeiten: python(abi) = 2.7 für Paket: yum-metadata-parser-1.1.4-7.oc00.pentium4
Package python is obsoleted by python-unversioned-command, but obsoleting package does not provide for requirements
--> Verarbeite Abhängigkeiten: python(abi) = 2.7 für Paket: urlgrabber-3.10.1-10.oc00.noarch
Package python is obsoleted by python-unversioned-command, but obsoleting package does not provide for requirements
--> Verarbeite Abhängigkeiten: python(abi) = 2.7 für Paket: python2-rpm-4.13.0-19.oc00.pentium4
Package python is obsoleted by python-unversioned-command, but obsoleting package does not provide for requirements
--> Verarbeite Abhängigkeiten: python(abi) = 2.7 für Paket: yum-3.4.3-13.oc00.pentium4
Package python is obsoleted by python-unversioned-command, but obsoleting package does not provide for requirements
---> Paket python-libs.pentium4 0:2.7.6-25.oc00 markiert, um veraltet zu werden
--> Verarbeite Abhängigkeiten: python27.dll für Paket: yum-metadata-parser-1.1.4-7.oc00.pentium4
Package python-libs is obsoleted by python3-libs, but obsoleting package does not provide for requirements
--> Verarbeite Abhängigkeiten: python27.dll für Paket: python2-rpm-4.13.0-19.oc00.pentium4
Package python-libs is obsoleted by python3-libs, but obsoleting package does not provide for requirements
--> Verarbeite Abhängigkeiten: python27.dll für Paket: python-pycurl-7.19.5.1-2.oc00.pentium4
Package python-libs is obsoleted by python3-libs, but obsoleting package does not provide for requirements
---> Paket python-unversioned-command.pentium4 0:3.9.5-5.oc00 markiert, um obsoleting zu werden
--> Verarbeite Abhängigkeiten: /@unixroot/usr/bin/python2 für Paket: cmake-rpm-macros-3.15.3-1.oc00.noarch
Package python is obsoleted by python-unversioned-command, but obsoleting package does not provide for requirements
--> Abhängigkeitsauflösung beendet
 Sie können versuchen mit --skip-broken das Problem zu umgehen.
 You could try running: rpm -Va --nofiles --nodigest

This gives me the impression that there is a conflict with the already installed python 2.7

Unfortunately I cannot catch all screen output of "yum install python3" but I also get this:
Code: [Select]
Fehler: Paket: yum-3.4.3-13.oc00.pentium4 (installed)
            Benötigt: python(abi) = 2.7
            Entfernen: python-2.7.6-25.oc00.pentium4 (installed)
                python(abi) = 2.7
            Überholt durch: python-unversioned-command-3.9.5-5.oc00.pentium4 (netlabs-exp)
                Nicht gefunden

However, attempting to install "python-unversioned-command-3.9.5-5.oc00.pentium4" again gets me to this error:

python-pycurl-7.19.5.1-2.oc00.pentium4 benötigt python27.dll

Needless to say, running with "--skip-broken" or "rpm -Va --nofiles --nodigest" does not make a difference.

What further confuses me is that I have "python" (and various related packages) installed but I now see that there also exists a "python2.7" in netlabs-exp with various related packages. So how would I be able to replace "python" with "python2.7" ?


6
Very odd, I have this:

Code: [Select]
{0}[d:\usr\lib] bldlevel gtls30.dll
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#bww bitwise works GmbH:3.6.12-1.oc00#@##1## 04 Apr 2020 12:06:06     ECS26154618:
:::0::@@gnutls
Vendor:          bww bitwise works GmbH
Revision:        3.06
Date/Time:       04 Apr 2020 12:06:06
Build Machine:   ECS26154618
File Version:    3.6
Description:     gnutls

So, it looks like the exact same version but I have a different build time ...
It's from "netlabs-rel" and the gtls30.dll DOES contain the "_gnutls_fips140_set_mode" exported function:
Code: [Select]
{1}[d:\usr\lib] exehdr gtls30.dll | find "_gnutls_fips140_set_mode"
 943    1  00055983  _gnutls_fips140_set_mode   exported

I am not using CUPS but I can say that:

http://localhost:631/admin

works (it sees my printer etc.). I then printed a test page via the admin GUI and that also worked.

7
Games / Re: OS/2 - ArcaOS - Native Games
« on: July 28, 2021, 06:11:09 pm »
But in BWWs version, I fixed an init error in the display structures, which should be applied to Digis version, if not already done.

I didn't find your fix.

https://github.com/bitwiseworks/SDL2-os2/commit/f5057a506716d15c405a545403b316e807d7069e

8
Multimedia / Re: Updated Uniaud32 build
« on: July 27, 2021, 09:00:21 am »
Looks good. Just to be sure you can remove the Sequencer= lines.
I don't think it will be necessary to install the drivers from scratch once MMPM2.INI is correct (of course, the drivers will need to be loaded via config.sys). MMPM2.INI has always been the weak spot of the video/audio system.

9
Multimedia / Re: Updated Uniaud32 build
« on: July 26, 2021, 09:09:53 am »
Post it here or attach and I will fix it for you.

10
Applications / Re: Creating some apps RPM packages
« on: July 05, 2021, 04:31:10 pm »
But I still haven't full started with the RPM installers. On my last attempts I got stuck with the WPS integration to create icons and set the properties of WPS objects (Path, working directory, etc). I usually get the answer that it works, but I'm doing it wrong, but nobody tells me how to do it right.

I do this using REXX scripts. This is called from the %post section of the .spec file for installation and from the %postun section for uninstallation. My restartwps.exe utility is also used to restart the desktop correctly.

My .spec:
ftp://os2.snc.ru/pub/freerdp/RPM/ofreerdp.spec

REXX scripts and restartwps.exe:
ftp://os2.snc.ru/pub/freerdp/RPM/spec-tools/

(see "restartwps.exe -?" for help)

How to create a WPS object from an RPM spec is explained here (as source code comments):
http://trac.netlabs.org/rpm/changeset/91
http://trac.netlabs.org/rpm/browser/spec/trunk/SPECS/os2-rpm/macros.wps

and a practical example:
http://trac.netlabs.org/rpm/browser/spec/trunk/SPECS/qtcreator/qtcreator.spec

11
Hardware / Re: Hardware Wiki report
« on: June 27, 2021, 11:27:52 am »
I think that product is targeting the daughter.

12
Applications / Re: patched PmMerge
« on: June 24, 2021, 08:29:01 pm »
Actually, it might indeed be a memory problem: a couple of secondary windows are created (and closed with exit) until I get a bunch of memory error messages, obviously one error message per attempt to open an additional window.

It's possible that PM (including the PM drivers) has some problem allocating memory. Potentially, because they have to allocate from some limited memory pool or region.

13
Applications / Re: patched PmMerge
« on: June 24, 2021, 08:22:25 pm »
With the already mentioned config and with the ORIGINAL pmmerge, I do not get a hang on either testcase.
However, teststart2 eventually reports this:

SYS0008: There is not enough memory available to process this command.
All available memory is in use.

However, I cannot see memory depleting, therefore I think the root cause if something else. In any case, this seems to be a bug in the REXX interpreter.

What I can also see for testcase2 is that the initial window does not properly draw which might be a PM problem.
If this stuff crashes for you then there might be an SMP issue with PM (as I am only running on one core). I wouldn't be surprised.

14
Shared folders are for a completely different purpose.
They allow folders on the host to be accessible from the guest. And not the other way around.
I have a download folder (NTFS) under Win10 that I make accessible in the OS/2 guest. That works fine. The OS/2 guest needs to assign a drive letter for this folder. This is exactly what the shared folder support allows to do.

15
Applications / Re: patched PmMerge
« on: June 18, 2021, 07:06:03 pm »
kernel W4, 14.201_a, eCS 2.2 beta, running with 1 core unter Virtualbox:

directly traps with a Ring 0 trap on boot. The trap triggers in DOSCALL1.DLL, but the actual Ring 0 trap happens in PMDD.SYS:

 Slot  Pid  Ppid Csid Ord  Sta Pri  pTSD     pPTDA    pTCB     Disp SG Name
*0019# 0015 0014 0015 0001 run 0300 f9f9f000 fefb59e0 feef840c 0ee8 00 DHCPSTRT
 
eax=7cd00047 ebx=0000efc0 ecx=00000007 edx=00000020 esi=0004a338 edi=26cb0000
eip=0000c541 esp=0008ef98 ebp=0004a30c iopl=2 -- -- -- nv up ei pl nz na pe nc
cs=ffef ss=0047 ds=0053 es=0053 fs=150b gs=0000  cr2=00000000  cr3=00200000
ffef:0000c541 66ea6477fc1f5b00 jmp       005b:1ffc7764


# ln ffef:c541
 
ffef:0000c53c DOSCALL1 UT32_TARGET + 5


# ln %1ffc7764
 
%1ffc7764 DOSCALL1 UT32_RETURN

The instruction directly before the "jmp" is an (indirect) call to DOSDEVIOCTL, in case that matters. But I would think it is a IOCTL call into PMDD.SYS.
 



# .maamc ffef:c541
 
 
*har     par      cpg        va    flg next prev link hash hob   hal
 0119 %feb98830 00000010 %1ffd0000 3d9 0118 011a 0000 0000 0132 0000  hco=00164
 hob   har hobnxt flgs own  hmte  sown,cnt lt st xf
 0132  0119 0000  0838 012a 012a  0000 00  00 00 00 shared    c:doscall1.dll
 hco=00164 pco=ffe0970f  hconext=00130 hptda=0531 f=1c  pid=0016 c:dhcpcd.exe
 hco=00130 pco=ffe0960b  hconext=000e3 hptda=0469 f=1c  pid=0015 c:dhcpstrt.exe
 hco=000e3 pco=ffe0948a  hconext=00107 hptda=0459 f=1c  pid=0014 c:dhcpstrt.com
...


#
                        TRAP SCREEN INFORMATION
OS/2 Kernel Revision 14.201_W4
Exception in module: PMDD   
 TRAP 000d       ERRCD=0000  ERACC=****  ERLIM=********
EAX=7cd00000  EBX=f9f902f2  ECX=00000020  EDX=0000005b
ESI=feef0000  EDI=26cb0010  EBP=00045bf8  FLG=00012292
CS:EIP=0d00:00000a8b  CSACC=009b  CSLIM=00000d10
SS:ESP=0030:00005b8c  SSACC=1097  SSLIM=00004ebf
DS=0cf8  DSACC=0093  DSLIM=000000d0  CR0=8001003b
ES=0000  ESACC=****  ESLIM=********  CR2=1fec9b80
FS=0000  FSACC=****  FSLIM=********
GS=0000  GSACC=****  GSLIM=********

I have a full trap dump, in case that helps.


Pages: [1] 2 3 ... 56