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
General Discussion / Email address of Dave McKenna ?
« on: August 04, 2019, 03:14:07 pm »
Can anyone provide me with his email address ?
If yes, please do not post it publicly on this forum but send it privately via email:
lars dot erdmann at arcor dot de


I always had the problem that closing and restarting the Volume applet repeatedly while a video (with sound) was playing in Firefox would eventually blow up the whole system with a subsequent reboot.

I have now found the reason: the CWMM classes (which the volume applet is part of) come with 2 resource DLLs: MMRES_EN.DLL and MMRES_DE.DLL ( in the \MMOS2\MMCLASS\BIN directory).
On my system which has set LANG to de_DE, the volume applet would attempt to load MMRES_DE.DLL, for all others that would be MMRES_EN.DLL.
Apparently, somebody decided to just copy the file MMRES_EN.DLL over to MMRES_DE.DLL as a shortcut to producing the german resources DLL.
However that leads to the following: the file is called MMRES_DE.DLL but the internal module name (set during link time) is MMRES_EN.
The volume applet attempts to load the resource DLL dynamically. It fails because the filename (stem) does not match the internal module name. But what's more: this mismatch between the filename and the internal module name will eventually massively confuse/screw up the module loader (if done repeatedly) until the whole system reboots without showing any trap screen or the like.
My solution was to LXLITE /X (unpack) the DLL, use a hex editor to modify the internal module name from MMRES_EN to MMRES_DE and do an LXLITE to pack it again. Now the proper resource DLL is loaded (even though it still contains english resources ...).
Now my system does not reboot anymore on running the volume applet.

If someone has an AN account I suggest to raise a problem report against this module loader oddity.

Hardware / WLAN to LAN Adapter that works under OS/2 available ?
« on: November 26, 2018, 08:27:17 am »

I changed my telephone/internet provider. As a result, my router now moved from my work desk into the living room.
Because of that I can no longer connect to the router via LAN cable but need to use WLAN. I have a desktop PC that does not have built-in WLAN anyway. I know that USB is not an option as we have no USB WLAN drivers.

Does anyone know of a WLAN-to-LAN Adapter that works under OS/2 (or is likely to work) ?

I hope that these adapters are generic enough to look like an ethernet cable to the built-in LAN HW.
If not, I guess that will the final curtain for OS/2 on my computers ...

Hardware / USBDRV 10.225 - full support for USB audio
« on: November 14, 2018, 07:27:49 am »
The new package now contains drivers for USB audio standard 1.0 and also audio standard 2.0 (has nothing to do with USB 1.x vs. USB 2.0).
That should cover all current sound devices. The supported bit depths and sample rates are what is in use today, more details in the contained "readusb.txt" file.
Really, only playback has been tested, I am not sure in how far or to what extent recording will work.

If you need sound and if UNIAUD does not work for you then you might consider buying a set of USB speakers or a USB audio stick for plugging in earphones instead.


Applications / OS/2 memory manager: memory corruption ?
« on: November 04, 2018, 01:11:20 pm »

look here:

Could anyone confirm that he also sees this problem on his system ? I even doubt that it is Firefox specific.
I have the bad feeling that there is a general flaw in OS/2's memory manager, in particular with regard to high memory.


Hardware / USBKBD now supports multimedia keys and system keys, but ...
« on: October 28, 2018, 07:07:43 pm »
I finally managed to get USBKBD.SYS to properly recognize and translate the additional keyboard keys (like fast forward, WWW home etc.).
USBKBD.SYS will now properly read these keys and translate them to the proper PS/2 make and break scancodes as defined in this document:

But we now have this limitation: the created PS/2 scancodes are passed to IBMKBD.SYS. It now appears that the scancode range that is now possible exceed that of what IBMKBD.SYS can handle. There are now scancodes that need 2 bytes to be fully represented which IBMKBD.SYS does not properly handle.

Is there an interest to have the full key range ? That would require to rework IBMKBD.SYS.

What does work already is to register these keys as new function keys if you have XWorkplace installed.
And use them from the "symbol" page in the setup notebook. For example I have registered the "WWW home" key to start my Firefox object.

Hardware / USB 10.221 is out
« on: February 06, 2018, 09:58:53 pm »

It contains fixes to USBD.SYS and more importantly the completely updated USBAUDIO package to support higher sample rates and bit resolutions.

Article Discussions / AN changing USB driver stack to 32-bit
« on: January 26, 2018, 10:35:46 am »
AN is currently working on XHCI. Along with that there is a decision to make the USB driver stack (mostly) 32-bit.
The stated reason for this was to increase data throughput.
Today, the USBxHCD.SYS and USBD.SYS drivers have been changed. Along with that change came a change in driver interface between these drivers that is no longer publicly documented (The driver interface of the old 16-bit drivers is documented in a HTML document as part of the DDK and therefore available to anyone with a DDK license).

Currently, the client drivers (USBPRT.SYS, USBMSD.ADD, USBAUDIO.SYS etc.) have not been changed and the driver interface of USBD.SYS still allows the use of 16-bit client drivers with the new 32-bit components.

However, there are ideas to also change the driver interface of all client drivers and make them 32-bit also.
What that means in practice is that you will no longer be able to combine say USBMSD.ADD and USBAUDIO.SYS from my driver set with the AN driver set.

Since AN has only little interest in offering audio and video support in OS/2 (it's not their business use case) that effectively would mean that development of USBAUDIO.SYS would be terminated and also that ArcaOS is become more and more proprietary, effectively a new OS next to OS/2.

Please speak up now if you don't want that to happen. I have always provided free USB drivers to the community and Wim and me we have invested considerable effort in making USBAUDIO.SYS what it is today. I see AN's need to make money from ArcaOS but I also see that with an ever diminishing user base, this step will be the last nail in the coffin of OS/2.
While there might be technical reasons I think that changing the driver interface will lock out anybody else in developing a USB driver (think about Wim's USBECD.SYS driver for example) and the OS/2 community is already short on driver developers.


Wim and me, we have been working on updating the MMPM subsystem so that it will finally support WAV files with 24-bit and > 65535 Hz (there was a limitation in the MMPM subsystem components that would restrict the sample rate to a 16-bit value).

In fact, we updated the MMPM subsystem to support these sample rates beyond 48000 Hz:
64000, 88200,96000,176400,192000,352800,384000 Hz.

The MMPM subsystem still has an inherent limitation to only support a discrete number of sample rates but we picked the rates that are in common use today. But I think we can live with that and the supported rates can be extended if necessary (but will require an updated USBAUDIO installation, see end).

With this support you can finally use more recent USB audio devices and exploit their full capabilities.
While 16-bit, 44100 Hz stereo (CD-ROM quality) was about the best you could get in 1996, more than 20 years later this is about the minimum sample rate /bit-depth used. It will also pave the way to support USB audio 2.0 devices which normally only offer these higher sample rates.

By the way: UNIAUD would also need this MMPM subsystem update to support WAV files with sample rates higher than 48000 Hz.

Once we have everything nice and polished I will release a new version of my USB device drivers.
It will be necessary to rerun the USBAUDIO driver installation to get everything updated properly.



I have created an experimental version of USBD.SYS that will place attached devices under the corresponding hub they are attached to instead of placing them under the host controller they are attached to.
I think that makes it easier to determine where a device is plugged in. For example, if you use an external USB hub you will see the attached devices under "USB Hub Device_x.y.z" instead of under the host controller the external USB hub is attached to.
I think this logic also better follows the Windows logic.

Would anyone want to try out ? Unfortunately it will not work with the AN stack yet so you will need to (temporarily) install my 10.220 stack. If people prefer this I will try and convince AN to put it in their USBD.SYS.
It's not a big change to USBD.SYS and my HWMAN.DLL extension will still show the proper device names without any change !


Storage / oddities with OS2AHCI version 2.04
« on: December 16, 2017, 03:17:48 pm »
I recently installed version 2.04 which indeed fixes the problem with the system freezing on invoking smartahci.exe which happened with version 2.03.

But now I have this oddity: if I invoke smartahci.exe more than once in a row, the first invocation will work fine but the second invocation will again freeze the system.
I tried this commandline: smartahci.exe -i hd0

Before I open a problem report at AN: Does anyone experience the same problem ? Or is it just me ?

Storage / About FAT32 and AN
« on: June 10, 2017, 11:10:01 am »
Looks like quite a few people are having probs with FAT32 as it comes with AN:

the new version that is being worked on still needs some fixes. What I fixed with SVN revision 250 was some prob with extended attributes in conjunction with the /largefiles switch which would lead to a complete system hang when opening a FAT32 drive object. Currently we are working on a problem when double clicking on a file with a program association​ (say a zip file associated with the arcview.exe utility).
We know where the resulting system hang occurs but we don't yet know why ...

For the time being the solution is to revert back to version 0.9.13 which you will find at Hobbes.

To find out about what SVN revision is delivered with AN:
open a commandine, change to directory \os2\boot and do a "bldlevel FAT32.IFS" (without the quotes).
The returned info contains a 3-digit value (apart from other info) which is the SVN revision.

If it is older then 250 you can try newer version here (as I said:not yet ready for prime time):


I have uploaded to Hobbes version 5.0 of VFDISK.SYS. It contains a fix so that the FAT12/FAT16 support that comes with the new FAT32.IFS can peacefully coexist with VFDISK.SYS.

VFDISK.SYS is a device driver to emulate floppy media.


Multimedia / recent developments for USB audio
« on: April 08, 2017, 10:22:54 am »

Wim Brul and me have made some significant progress in enhancing support for USB based audio:
1) we have fixed quite a few bugs in USBAUDIO.SYS so that finally it will work reliably
2) I have implemented on-the-fly sample rate conversion in an IOProc (USBWAV.DLL) for these conversions:
   16-bit signed PCM, stereo, 44100 Hz
   8-bit unsigned PCM, mono, 11025 Hz
   8-bit unsigned PCM, stereo, 11025 Hz
   8-bit unsigned PCM, mono, 22050 Hz
   8-bit unsigned PCM, stereo, 22050 Hz
   8-bit unsigned PCM, mono, 44100 Hz
   8-bit unsigned PCM, stereo, 44100 Hz
   16-bit signed PCM, mono, 11025 Hz
   16-bit signed PCM, stereo, 11025 Hz
   16-bit signed PCM, mono, 22050 Hz
   16-bit signed PCM, stereo, 22050 Hz
   16-bit signed PCM, mono, 44100 Hz
"on-the-fly" means you no longer have to manually convert audio files to the 16-bit signed PCM, stereo, 44100 Hz target format.
The IOProc will instead do that on the fly when you open an audio file (double click a WAV file under the Workplace Shell for example).
3) additionally I have added Codecs for A-Law and Mu-Law
4) for audio compressed files, I have added support to the IOProc to use any audio codecs that are installed to decompress audio from the compressed format to 16-bit PCM (if a suitable codec can be found)
5) Wim has picked up the functionality in the IOProc as listed in 2) and added the same to USBAUDIO.SYS. This is for those applications that use DART directly and bypass the MMIO file support. An example of direct DART use would be the "libkai" library.

This will greatly improve the usability of USB audio under OS/2. What's left to be done is to also support "48 kHz sampling rate only"  USB devices. However that will require additional effort.



Apache Office 4.1 needs libicu in Version 4.2 (it is looking for DLL icuuc42.dll).
However Firefox needs libicu in Version 56.1 (it is looking for DLL icudt.dll I seem to remember).
The problem is: if I install the newer version, the older version is removed. I had to manually zip all files from the old version package, install the new one and then unzip the saved DLLs.

What is the correct way to deal with this ? Do I need to copy over that old stuff into the Apache Office application directory ?
I admit that I am lost.


Pages: 1 [2] 3