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.


Topics - Lars

Pages: [1] 2 3 4
1
Applications / Cannot create archive
« on: August 23, 2024, 08:13:35 am »
Whenever I boot up, I get the error message that no new archive can be created.
Does anybody know how to fix this error ? I had this in the past but I cannot remember what I did to make that error go away.

2
Applications / Unzip Version 6.0 hangs when booting to a commandline
« on: July 28, 2024, 01:16:25 pm »
I recently had the need to boot to a commandline (hitting F2 on boot) and to use UNZIP to overwrite a couple of files that would prevent proper system operation.
However, when I called the "unzip.exe" version 6.00 that is installed via YUM, the bootup commandline would hang and the unzip help screen would never show up.
When I instead used the "unzip.exe" version 5.52 that is still in my ECS\BIN subdirectory, it would properly work without such a problem. I am sure it is not a DLL loading problem as the LIBPATH setting is the same as for the regular boot, but of course, the newer UNZIP uses different DLLs (gcc, libcn0) than the older version (which directly uses the OS/2 API).

Anyone knows what's going on or how to fix that ?

Lars

3
Applications / XWP 1.0.17: any availability date ?
« on: March 20, 2024, 06:56:08 am »
Out of interest but also need (I had raised 2 tickets): is there a rough availability date for XWP 1.0.17 ?

I was curious and looked into the XWorkplace/XWPHelpers SVN repos but could not see any checkins from Rich. I therefore suspect that currently, he only has done the changes to his local copy.

4
Applications / Where to upload ?
« on: February 01, 2024, 08:03:15 am »
I have fixed "RAMSCOPE" to work under 32-bit OS/2 (in particular: its device driver PHYSMEM.SYS).
Not that it would matter but it was worth the fun :-)

I have uploaded to "www.hobbesarchive.com" (hopefully,it's unclear if it ever found its way). Is that now the agreed place or what ?

Lars

5
Hardware / The last nail in OS/2's coffin
« on: January 22, 2024, 12:05:09 am »
Sorry, it's in German (unfortunately it's also not free):
https://www.heise.de/select/ct/2023/26/2317912025061981023

I suppose that this has also been.picked up by other IT press articles about the new X86-S architecture.
What it basically states is that Intel will now finally remove all 16-bit support (true for real mode, protected mode and VM86 mode), all segmentation, Ring 1 and 2 of the protection rings.
That means: NO OS/2 device driver will work, NO  OS/2 1.x application will work, no application with an IOPL segment will work, no VDM will work, some parts of the kernel will cease to work.

OS/2 is going to be put to it's well deserved, permanent rest.
The current x86 will likely live on for a couple of years but there clearly is no future for OS/2, not even in a virtualization environment like Virtualbox.

6
Applications / LVM.EXE cannot execute
« on: May 13, 2023, 11:55:42 am »
I know this has been mentioned in the past but I cannot find the forum posts:

When I try to run "lvm.exe" I get this error in response:"Cannot get disk data from the LVM engine".

Strangely enough, if I instead run "minilvm.exe" or "lvmgui", then I have no problem running these two apps even though they also need to open the LVM engine to do their job.

I then had a look in Theseus to find out what is going on, in particular I checked what process loads "IVM.DLL" and "LVM.DLL" (these implement the LVM engine, I believe).
These two DLLs are loaded by PMSHELL.EXE but I could not find out exactly what loads these two DLLs (is it a WPS class ? Or what else ?).

Has anyone else also experienced this problem ?

7
Storage / JFS failing in a disastrous way - without the user knowing
« on: November 30, 2022, 01:01:18 pm »
Hallo,

I thought, I'd share this info with everybody.

Initial info:
0) as a standard case that is likely true for 99.9 % of all OS/2 systems in use today, my system/boot partition is JFS formatted
1) a long time ago, I had installed eCS as german NLS version. What that means for this error case is that some standard directories of the WPS are created with umlauts in their directory names, for example, "Desktop" becomes "Arbeitsoberfläche" in german.
2) as some of you might know, JFS.IFS saves its directory and file names in UNICODE and relies on the services of the UNICODE.SYS driver to properly convert between UNICODE and the default ASCII character set in use because effectively, the IFS interface only supports ASCII directory and filenames. The consequence of that is that you should NEVER hop between different character sets (by using the "chcp" command) when you create directories or files that have special characters in them (anything beyond the US437 character set).
3) for various reasons I have multiple boot configurations with different "config.sys" files, managed by the QSINIT selection menu. These files have different names: config.sys, config.smp, config.w4 etc.

Recently I decided to install this package:
https://hobbes.nmsu.edu/download/pub/os2/apps/wps/xworkplace/widgets/CPUTemp_wdgt_1-1-0.zip
That was the first error, because I have an AMD CPU and therefore this package was useless for me :-)

What followed next was the "cputemp" WPI package updating the default "config.sys" file by placing a driver into it. As it turned out later, it would not only add a driver load entry but also, apparently due to a bug in WarpIn (I later extracted the install script from the WPI file and found nothing wrong or suspicious in it), would remove the load line for UNICODE.SYS from the config.sys file. Because I had booted from a boot configuration that used another "config.sys" file (named, say "config.smp") this problem did not become apparent for as long as I was booting in the alternate boot configuration.

Eventually I booted into the standard boot config using file "config.sys". The base boot of loading all drivers and IFS (including JFS.IFS) went by without any problem but eventually, I was presented by the XWorkplace message that my desktop directory could not be found.
I was not too worried and suspected a simple OS2.INI or OS2SYS.INI corruption and decided to restore this set of files from a boot a few days earlier.

But on the next reboot, the error showed up again. From the commandline of the temporary desktop that had been created I decided to look directly at the filesystem naming of directories and files. And yes, "Arbeitsoberfläche" had been corrupted at the umlaut character. I then took the bad choice (in hindsight) and attempted to rename the directory back to what it was but it turned out that I was unable to do so. I was also unable to delete or rename that directory with any other tool like File Commander.
I decided to copy the desktop from a backup folder and was successful but intimidating enough, now I had two directories with the very same name "Arbeitsoberfläche" (on filesystem level !) but one of it could neither be renamed nor deleted. To remember: UNICODE.SYS driver was not loaded at this point.

It dawned on me that something had gone terribly wrong with the file system.Using DFSee, I triggered a chhdsk for the next reboot. The chkdsk would end without error but now I would directly run into a trap right after chkdsk was done. This was repeatable.

Fortunately, I had a completely different "development" boot partition that was completely intact (and both, UNICODE.SYS and JFS.IFS propery loading). And I had DFSee. But that was installed on the JFS partition that I could not boot from. Fortunately, as turned out later, that did not matter. The "broken" partition had directory naming problems but was intact as such and therefore I was able to readd the UNICODE.SYS load entry to "config.sys" on the "broken" partition.

I fired up the "development" boot partition and started DFSee. In one of its extended menus I found the possibility to rename directories and files on a very low file system level (so to say). Apparently, DFSee understands all low level structures of JFS and can directly overwrite sector content.

Subsequently it turned out that not only "Arbeitsoberfläche" had been "renamed" disastrously but also all OTHER DIRECTORIES below "Arbeitsoberfläche" that contained umlauts (yes there are quite a few directories below the "Desktop" directory ...).

For each of the affected directories, I had to hop back and forth between giving them an intermediate name like "Arbeitsoberflxxxx" and "Arbeitsoberfläche" to force the proper directory name (intermediate reboots required). After multiple reboots and some traps I was finally able to restore the partition to an acceptable state, but I had to recreate quite a few directories under the "Desktop" directory and move things to their proper place.


I think it would at least be helpful if JFS.IFS would, ideally already on bootup, report a warning if it fails in using UNICODE.SYS services instead of reporting nothing. That would have pointed me to the problem and would have saved me hours of work.
(I can understand that JFS.IFS will need to be able to continue nonetheless because otherwise you would not be able to fix the config.sys file and readd the UNICODE.SYS load entry ...).

This behaviour is surely an absolute NOGO for a new user (unless you only accept english speakers or people using the US/UK NLS version as new users).







8
Multimedia / playing/convert AIFF and AIFC files: interest anyone ?
« on: November 10, 2022, 07:47:40 am »
Hi,

AIFF and AIFC are sound formats that were invented by Apple (I think) for the original MAC and the Apple IIe in 1989 or so.
They resemble WAV files but all meta/header info and data is saved in big endian format (because the Motorola CPU used back at the time was a big endian CPU).

Because I was bored, I am currently working on an IOProc to transform these files into the standard WAV format that MMPM understands. Currently I can read (play) AIFF files in 8-bit,16-bit,24-bit and 32-bit sample size (the data as such is plain PCM data, that is: uncompressed) and uncompressed AIFC files in 8-bit,16-bit,24-bit and 32-bit sample size. I plan to add support for A-law and Mu-law for AIFC.

In theory, OS/2 should already support AIFF, but the IOProc (aiffproc.dll) is broken in that it only endian converts the meta/header data but forgets to endian convert the sound data ...

Is there any interest in this ? Is there also an interest to transform WAV files to the AIFF and/or AIFC formats ?

Cheers,
Lars

9
Multimedia / updated USB audio drivers (heading for 10.245)
« on: October 22, 2022, 04:15:57 pm »
I have now made a lot of updates to the USB audio drivers (USBAUDIO and USBAUD2). I have fixed some bugs, implemented balance control, implemented gain control and changed the volume setting to logarithmic scaling (because that better meets the human`s way of hearing). I also updated USBAUDIF so that a gain setting request is properly passed to the audio drivers (for example, WEPM.EXE, the default OS/2 audio edtor, supports gain setting).

Who would like to test ? I can post here of send privately. Once they are ok, I'd build a new USB driver package and upload to Hobbes (as always).

Regards,
Lars

10
Hallo,

I have a RAM disk and environment var "TMPDIR" is pointing to it (other vars like TMP, TEMP and EPFITMPDIR are instead pointing to a hard drive directory).
Effectively it´s "set TMPDIR = Z:\" where Z: is the RAM disk drive letter.
It seems that as soon as I start an app that was ported from Unix (and therefore will in some way use LIBC etc.) then, a directory "runtime-root" is created in the root of Z:

I could care less as it will be gone on the next bootup but it seems to negatively impact the initial run of such an app. Why is this directory created and how can I prevent it from being created ?

11
Applications / Implemented DUMPFS.IFS as a 32-bit IFS
« on: March 29, 2022, 08:09:09 pm »
Hallo,

I am referring to:
https://www.os2site.com/sw/drivers/filesystem/dumpfs.zip

As you might know, this package contains a modified OS2DUMP and a specialized IFS for supporting trap dumps.
I have now reimplemented the "DUMPFS.IFS" contained in that package as a 32-bit version. That means, it supports dumps > 2 GB. I have also added (minimum) EA support so that the partition contents properly display in the WPS and also on the commandline. Of course, you can also use PMDF.EXE on that dump file (without the need to copy it to another partition as was true for the original DUMPFS.IFS).

Additionally I have implemented some reduced write support so that you can copy a trap dump file to that dump partition. Of course, copying the dump file to another partition (for example, a JFS partition) also works.

Would anybody be willing to test ? It does still have a few quirks here and there but in principle it should work (at least, it does on my system).

I have limited its use to an LVM managed system (that is OS2DASD.DMD/OS2LVM.DMD , sorry, but original Warp3 or Warp4 are not supported) in order to have optimal read/copy/write throughput.

Just drop me a note if you want a test version.


12
General Discussion / Email Address Valery Sedletzki ?
« on: March 08, 2022, 08:17:11 am »
Hi,

can anyone provide me with an email address of Valery Sedletzki ?

@Valery: if you listen, just drop me your email address in the private area. I need your help on FSDs :-)

Thanks !

13
Hallo,

for anyone who plans to write an OS/2 IFS, I have found the basis of the OS/2 IFS specification. It goes back to OS/2 1.2 (16-bit OS/2) times but it gives valuable additional info even today.

Download this document
https://patentimages.storage.googleapis.com/23/69/45/f6a4cb501938a9/EP0415346A2.pdf

and you will find enclosed the "OS/2 1.2 IFS Patent Documentation". It's 196 double pages.
I have neatly extracted that into a PDF and also did a page turn of 90°, except for double page 11 that needs a 270° turn :-)

Regards,
Lars

14
Utilities / VirtualBox, OS/2 guest, running with > 1 core. Success !?
« on: January 21, 2022, 07:45:49 am »
Hi,

my past experience with Virtualbox and running an OS/2 guest with > 1 core was that VirtualBox would hang very quickly and I always had to revert back to 1 core.

With Virtualbox 6.1.32 which was recently released, I find this in the change log:
Quote
VMM: Workaround for OS/2 guest unstability on newer AMD CPUs due to a missing TLB flush in OS/2 (bug #20625)

My host OS is Win 10 and my CPU is an Intel 8-core but I thought "so what, just give it a try" and I activated 2 cores for the OS/2 guest virtual machine.
And lo and behold, it seems to work ok. As a test, I rebuilt my complete USB driver stack which starts quite a few parallel processes (I think nmake starts multiple processes if the dependencies allow) and that always used to hang pretty quickly in the past when using > 1 core.

So, I believe this not just fixes a problem with AMD CPUs but a general problem with handling the TLB, at least for OS/2 guests (I suppose this somehow interacts with OS/2 memory management where the OS/2 memory management might have some pecularities which make it distinct).

Can somebody confirm that ?

15
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" ?


Pages: [1] 2 3 4