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 ... 96
1
Hi

The 'kLIBC Pathwriters' that I installed (klibccfg_1_0_2_1.exe) did not added TEMP, TMPDIR, LOGFILES on the config.sys.

I add those manually and the D: drive issues are gone.

Thanks. I will keep testing the ANPM.

I had updated to this:
https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/util/misc/prewrite2.wpi

which will set the common profile values and circument a problem with the existing klibccfg.dl. I replaced it with a "prewrite.dll", just like AN does.

2
Hardware / Re: URGENT Need for OS/2 Compatible Inkjet Printer
« on: May 30, 2025, 06:53:36 pm »
Looks like the HP Deskjet 6122 has a USB connection which is good to start with.
The easiest will be to buy a Postscript capable printer with a USB connection or even Ethernet connection.
Postscript was and is still pretty well supported by OS/2. I am using a Postscript Printer (Brother MFC-L8650CDW: but this is a Laserprinter) and that works well with the OS/2 supplied Postscript Driver.

3
Setup & Installation / Re: Cannot update python
« on: May 29, 2025, 08:14:47 am »
I still cannot update python.
I tried:
1) updating via ANPM
2) run "yum update python3" from a commandline
3) run "yum update python3 python2.7" from a commandline

All to no avail, each ends with a version conflict, for example from ANPM:
Quote
ERROR with transaction check vs depsolve:python(abi) = 3.9 wird benötigt von (installiert) python3-dateutil-1:2.8.1-3.oc00.noarchBitte melden Sie diesen Fehler unter http://yum.baseurl.org/report

Is there any "force" mode to force the update ?

4
Programming / Re: EDM/2 - The API Project - Undocumented
« on: May 28, 2025, 11:34:41 am »
Hello Steven.

You know more than me on this area.
My references are:
1) DevHlp_AddTraceEvent
-- "SMP Programming Addendum" on the "STRACE - DevHlp Functions"

-- sg244640: "Trace Events for DEVHELP Major Code: 0X0006, Sorted by Tracepoint"
--- OS) DevHlp_AddTraceEvent Post-Invocation 00132 (0X0084)
--- OS) DevHlp_AddTraceEvent Pre-Invocation 00004 (0X0004)


2) DevHlp_SysTrace
-- "Programming Guide and Reference Addendum"  on the "Device Helper (DevHlp) Services and Function Codes" at "DevHlp_SysTrace".

There it says "DevHlp_SysTrace is synonymous with DevHlp_RAS."

On "devhlp.inc" from the DDK it has:
Quote
DevHlp_RAS              EQU     40      ; 28    Put info in RAS trace buffer
DevHlp_SysTrace         EQU     40      ; 28    Synonym for DevHlp_RAS   f180062

This is why I guess that DevHlp_RAS and DevHlp_SysTrace  are the same. No idea about "DevHlp_AddTraceEvent".

Regards

Looks like we are spinning around in circles:

you will realize that major trace code 0x0006 neither lists DevHlp_RAS nor DevHlp_SysTrace. That said, it looks like DevHlp_AddTraceEvent = DevHlp_RAS = DevHlp_SysTrace as that is what this devhelp does: it adds a trace event to the trace buffer.

5
Programming / Re: EDM/2 - The API Project - Undocumented
« on: May 27, 2025, 01:47:34 pm »
DevHlp_AddTraceEvent    -  Not found in pddref.inf

DevHlp_AddTraceEvent = DevHlp_SysTrace = DevHlp_RAS

6
Setup & Installation / Re: Cannot update cups
« on: May 24, 2025, 10:32:19 am »
My initial thought was that the running cups daemon process would be the problem.
But that was not the case. It was that stupid EA problem.
But thanks for the hint. Because as you said, I was not able to kill it and I was not aware that I would need to try several times.

7
Setup & Installation / Re: Cannot update cups
« on: May 22, 2025, 08:02:11 am »
I found the cause:

the system claimed that:

E [21/May/2025:07:44:23 -0100] "/@unixroot/var/run/cups/certs" is not a directory.


That was obviously wrong as this directory does exist and in fact, it is a directory. It turned out that this directory was "contaminated" with the usual Unix EA crap (UID, GID, MODE, etc.). Once I completely removed all EAs from the directory, I was able to properly update CUPS.

Sigh ...

8
Setup & Installation / Cannot update cups
« on: May 22, 2025, 07:21:37 am »
Looks like I am out of luck when it comes to updating packages.

I tried to update CUPS, the package download succeeds (I can find it under \var\cache\yum) but finally I get this:
Error unpacking rpm package 1:cups-2.2.13-2.oc00.pentium4

When I use the commandline, I get this:

Quote
{1}[d:\] yum install cups-2.2.13-2.oc00.pentium4
Geladene Plugins: changelog, fastestmirror
Loading mirror speeds from cached hostfile
Einrichten des Installationsprozess
Löse Abhängigkeiten auf
--> Führe Transaktionsprüfung aus
---> Paket cups.pentium4 1:2.2.13-1.oc00 markiert, um aktualisiert zu werden
---> Paket cups.pentium4 1:2.2.13-2.oc00 markiert, um an update zu werden
--> Abhängigkeitsauflösung beendet

Abhängigkeiten aufgelöst

================================================================================

 Paket       Arch            Version                   Repository         Größe
================================================================================

Aktualisieren:
 cups        pentium4        1:2.2.13-2.oc00           netlabs-exp        2.0 M

Vorgangsübersicht
================================================================================

Upgrade       1 Package

Gesamtgröße: 2.0 M
Ist dies in Ordnung? [j/N] :j
Lade Pakete herunter:
Running Transaction Check
Führe Verarbeitungstest durch
Verarbeitungstest erfolgreich
Führe Verarbeitung durch
  Aktualisieren: 1:cups-2.2.13-2.oc00.pentium4                              1/2

Error unpacking rpm package 1:cups-2.2.13-2.oc00.pentium4
Warnung: /@unixroot/etc/cups/classes.conf erstellt als /@unixroot/etc/cups/classes.conf.rpmnew
Warnung: /@unixroot/etc/cups/cupsd.conf erstellt als /@unixroot/etc/cups/cupsd.conf.rpmnew
Warnung: /@unixroot/etc/cups/lpoptions erstellt als /@unixroot/etc/cups/lpoptions.rpmnew
Warnung: /@unixroot/etc/cups/printers.conf erstellt als /@unixroot/etc/cups/printers.conf.rpmnew
Fehler: Entpacken des Archivs fehlgeschlagen bei Datei /@unixroot/var/run/cups/certs: cpio: unlink
1:cups-2.2.13-1.oc00.pentium4 was supposed to be removed but is not!

Fehlgeschlagen:
  cups.pentium4 1:2.2.13-1.oc00          cups.pentium4 1:2.2.13-2.oc00

Komplett!

So: is there a way for force an RPM installation ?

If all of this is a problem because CUPS is running, how can I stop CUPS (without manipulating config.sys and rebooting) ?



9
Setup & Installation / Cannot update python
« on: May 12, 2025, 08:34:13 am »
Hi there,

I am offered python3 update to 3.13.2.-1. ANPM properly download all dependencies but fails with a "depsolve" problem.
I have tried both, copy python2.7.exe to python.exe and also python3.9.exe to python.exe but it fails anyway.
How do I force installation ? Obviously, I cannot do that from ANPM but a simple "yum update" does not offer such a thing as a --force switch.

10
Setup & Installation / Re: Troubleshooting process trap/dump...how?
« on: May 05, 2025, 06:12:12 pm »
1) you will need LOGDAEMON.EXE so that (Ring 3) applications can use the "LogAddEntries" API to write to the System Log. Not many apps need it but it does not hurt to have it running. "LogAddEntries" API is only documented in the Debugging Handbook.

2) you will need LOG.SYS so that Ring 0 device drivers/IFS etc. can use the DevHlp_LogEntry device helper to write to the System Log. It is also required by LOGDAEMON.EXE to operate. Not many device drivers use it (if any) but it does not hurt to have it running

3) You can safely remove all that EP... stuff as it is the outdated FFST stuff which has been superseded long ago, see here:
https://www.edm2.com/index.php/First_Failure_Support_Technology/2
From the list, only keep the following as actually, that is the new FFST stuff (I will need to recheck just to be sure):
FFST.EXE
FFSTCONF.EXE
FFSTPCT.EXE
ERRLOG.DLL
FFCONFIG.DLL
FFDUMP.DLL
FFGUI.DLL
FFIPC.DLL
FFPCT.DLL
FFPROBE.DLL
FFST.DLL
FFST.HLP

4) FFST.EXE is the system log daemon, it is started by SMSTART.EXE (see what THESEUS.EXE reports). It seemingly replaces EPWDDE3.EXE, EPWROUT.EXE, EPW.EXE.

5) Finally, FFST.DLL contains routine "FFSTProbe" which effectively supersedes "LogAddEntries" (see above) to write to the System Log but both still coexist where "LogAddEntries" is easier to use but requires a handwritten DLL to format the logged data where "FFSTProbe" uses a text template formatting approach that however is overly complicated.



11
Setup & Installation / Re: Troubleshooting process trap/dump...how?
« on: May 05, 2025, 08:06:04 am »
Hi Dariusz,

you are not alone with the "my system suddenly reboots without any trace" problem. I have experienced the same more than once.

1) you are using a very outdated version of FFST (RUN=G:\OS2\EPWDDR3.EXE, DEVICE=G:\OS2\EPWDD.SYS) that predates the stuff that came with  Warp 4 (and after, of course). Do not do that. I suggest to deinstall it. >= Warp 4 comes with everything you need.

2) Lower your VIRTUALADDRESSLIMIT value. I suggest to start with 512 (which is the lowest value and equivalent to having no high memory at all) and then, raise up to a value that is still lower than your current value. If 512 is too low, you will need to start with a value that works for your system. VIRTUALADDRESSLIMIT can only be raised in chunks of 512 MB (0x20000000). XWorkplace kernel object will only select values that are possible. The default value for VIRTUALADDRESSLIMIT is 1024 (MB).

My suspicion is that 2) is the most likely culprit. The problem with a too high value is that OS/2 seemingly can run into problems on memory allocation (be it the system arena located above the VIRTUALADDRESSLIMIT value, or the user area below this value). And OS/2 does a very bad job of detecting this problem with the result that it does not even stop with a critical error message and a system trap dump. Obviously, the failure to allocate memory in the system arena is a fatal problem that renders the system completely unusable.
An alternative behaviour to these sudden reboots seems to be a complete system freeze (with the same effect as if all HW interrupts are being disabled).

Lowering this value has still not completely eliminated the problem for me but it has lowered the frequency with which these sudden reboots occur.

12
Setup & Installation / Re: PYTHON - v2 vs v3 and dependencies...
« on: April 27, 2025, 07:36:47 pm »
ANPM comes with Python2 scripts to begin with.

13
Setup & Installation / Re: PYTHON - v2 vs v3 and dependencies...
« on: April 27, 2025, 05:34:42 pm »
You have already identified the problem: your python.exe is the same as python3.9.exe.
Just copy python2.7.exe over python.exe and you are fine.

14
Setup & Installation / Re: PYTHON - v2 vs v3 and dependencies...
« on: April 27, 2025, 05:03:28 pm »
Make sure that in your \usr\bin directory, you copy python2.7.exe to python.exe (if not already done). Nothing else ever worked for me.
And yes, I also have python 3 installed as I can find python3.9.exe within that same directory. But as I said, using Python3 will only get you into trouble.

15
Applications / Re: EXIFTool
« on: April 23, 2025, 05:40:38 pm »
I think that would just ask for desaster if you already have Perl installed via YUM/RPM.

You would have an outdated Perl installed via WarpIn alongside an up-to-date installation via YUM/RPM without really knowing what is being used by the EXIF tool.

The best way would be to remove the idiotic dependency in the WIS script. Unfortunately, I have no time to do it and for the time being, Steve's suggestion is likely the way to go forward.

Pages: [1] 2 3 ... 96