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 ... 11
Hardware / Re: Hardware Reports / Reviews - More - MORE !!!!
« on: December 09, 2017, 02:02:01 pm »
May I add that Wim and me we are currently working on a fix for USB 1.0 audio devices to being able to control playback volume/mute setting. But this is only a minor issue.

That said, ANY USB audio standard version 1.0 compatible device that supports sampling rates <= 48000 Hz should work with USBAUDIO.SYS. But you are limited to wave playback: MIDI does not work and properly never will (unless you use a SW emulation like Timidity). I have yet to come across an USB audio device that supports MIDI in HW. Wave Recording will also work but the current driver does not bother to support any controls regarding recording (like automatic gain control on/off etc. etc. etc.).
One of the reasons for this is that OS/2 does not have a user interface that would allow the user to control all that stuff (and the standard is very generic, it supports all kinds of odd controls, from compression to reverb, echo,  mixing, etc.)

Beware that more and more USB  audio devices now follow the standard version 2.0 because Microsoft has started to deliver such a driver for the Windows OSes (a few years ago). Unfortunately these standard versions are not backward/forward compatible which eventually will leave OS/2 behind (unless someone starts writing USB audio version 2.0 driver). As so often.

Hardware / Re: Mouse weirdness
« on: December 05, 2017, 12:23:57 pm »

can you post your PCI info for the machine in question ?
Just run PCI.EXE and dump the output to a text file.
I am only interested in any block that has "UHCI", "OHCI" or "EHCI" in it ...

There is a possibility that you have some very old USB hardware that potentially has the wrong PCI id. In that case, there is a chance that the UHCI driver might misinterpret the "overcurrent" bit setting (as I said, there is a disagreement between VIA and Intel) and bug you with reporting overcurrent where in fact there is no problem.

Hardware / Re: Mouse weirdness
« on: December 05, 2017, 11:17:37 am »
ok, thanks.

I am slowly progressing in preparing version 10.220 of the USB stack. There are functional updates to USBAUDIO.SYS (from Wim Brul: adding automatic sampling conversion support for 24-bit,48 kHz USB target devices and fixes to computed/displayed play time in particular if multiple streams are started in parallel), USBMSD.ADD (minor fixes in freeing "virtual floppy" emulation structures if the attached device does not need emulation), USB(U|O|E)HCI.SYS (revert back to 10.218 as Wim Brul had problems with the changes done in 10.219).
That said, if you have 10.219 in use you might want to revert back to 10.218 for the time being in order to rule out any issues in USB(U|O|E)HCI.SYS (if you have them).

Utilities / Re: Manual for eFTE/2 / eFTE / FTE (Folding Text Editors)
« on: December 04, 2017, 02:32:29 pm »
Ok, first things first:
I sincerely hope you don't get run over by a truck. Not for a piece of SW anyway :-)

My questions were not meant as an insult. But I thought you had been working on eFTE all along.
And for eFTE, I can at least find it on Hobbes. For NEPMD, I can only find a very old version on Netlabs.
I know that Andreas Schnellbacher is working on NEPMD but I have no clue how he can be contacted or where to get the most recent version.

As to Netlabs: ok, I have been working on the USB repo for the last 7 years on a fairly regular basis. Maybe that is the reason why I would "pick up" all the proper transitions. But Adrian Gschwend has and will always be helpful to get you access to the SVN repo you need to work on. In particular if you already contributed in the past (let me know if you need his email address ...).
For you updated documentation, I'd put that in the eFTE repo right away. It's important that things don't get lost or spread all over the place in an uncontrolled fashion. Even if the documentation is not completely ready yet ...

Hardware / Re: Mouse weirdness
« on: December 04, 2017, 01:03:06 pm »
As to USB mouse: have you tried an updated USB driver stack ? I consider the eCS 2.1 supplied USB drivers to be hopelessly outdated. Either use the driver stack from AN or try mine (on Hobbes).

For PS/2 mouse and keyboard: the usual advice applies, always plug in PS/2 mouse or keyboard before you power on the PC. Everything else can damage the electronics (I cannot remember if it would work at all if connected to an already powered system).

I remember that USBD.SYS will issue a beep on an overcurrent situation (if a device draws too much current).
Bad, bad bad.
On the other hand: if you have a UHCI controller (which I strongly assume you do) then the problem is that the "overcurrent bit" was not properly defined between the Intel UHCI and the VIA UHCI controller. VIA has defined it logically negated to Intel. But then I remember (in the USBUHCD.SYS driver) I am flipping the bit on VIA to match that on Intel (same holds true for the AN stack) ...

I assume you can also neither see nor use your USB pendrive, correct ?

Finally: AMouse (at least older versions) comes with their own USBMOUSE.SYS driver. Don't use it. Make sure you use the one in the AN stack (or my stack). These will be located in the \OS2\BOOT directory.

Utilities / Re: Manual for eFTE/2 / eFTE / FTE (Folding Text Editors)
« on: December 03, 2017, 10:33:05 pm »
1) Where is the latest version of nepmd ? What is the latest version of nepmd ?
2) Why is there no coordination in development of eFTE ? You appear in the netlabs eFTE "Direct Contributors to eFTE2" section. How come you don't know what has been going on in the last 6 years ? Why did you not add the documentation to the netlabs repo ?
3) Who is "I" or "they" in the description of eFTE on the "" page ?

For this reason I have been using EPM. Since EPM is lousy, I wrote myself two simple EPM REXX macros that allow me to indent and unindent text according to the tab settings and added keyboard shortcuts and menu entries for them.

Unfortunately there seems to be no coordinated effort in anything. Welcome to the Warpcave.


Programming / Re: Happy WarpINning!
« on: November 30, 2017, 03:18:51 pm »
WarpIN is very popular installer for warp-like OS-ses.

Many software developers distribute their products in WarpIN format. But many developers do not use all the features of the installer, as well as being make a errors in the descriptions of the packages. As an example I will give diff of wis script of the lSwitcher(v2.8.1) archive: See diff

Hardcoded paths(to \ECS\... of course), errors in "<PCK>"'s, don't use "<GROUP>" for localisations and what annoying me biggest ... XWorkplace X(e)Center plugin does not distribute as separate package. They offer to put it the hands  :-\ , as in the good old days, when the software was distributed in ZIP format.

No, it is not our method! ;) So, on court of the community proposed a project "WarpIN-Scripts-and-tools".
In this, active development package:

In plans:
  • WPI distribution of QS LDR(with backup feature of original IBM OS2LDR), and script for repack developer's zip distrib.
  • WPI distribution of OS/4 "Phoenix" kernels(with the function of automatic addition of the installed kernel to the boot menu and the ability to simultaneously install different versions of the kernels, and script for repack developer's zip of course).
  • Continue adding to the database corrected WIS scripts of popular products. If you have such products, you can send me their scripts by e-mail (oxyd76 (at) gmail (dot) com) (and a direct link to download wpi of course!) with Subject: WarpIN Or join me on the GitHub! WarpIN it's easy! ;-)


Hm ...,
1) I see no easy way for an installer framework to prevent the packager to make errors by introducing hard coded paths. It's up to the packager to use macros and the like to allow for variations. That said it is always never a good idea to mark an installation path as FIXED. Simply because that leaves the user no choice to correct the path if desired. I have only used FIXED if things where best placed in \OS2\DLL as that is guaranteed to exist in every OS/2, ECS, AN installation, Same holds true for mandatory paths like \OS2\BOOT for basedev device drivers, \OS2\SYSTEM\TRACE for trace files etc.

2) as to the REXX support in WarpIn, I am undecided. On the one hand you can do in REXX whatever you want, on the other hand, sometimes you'd wish that WarpIn supports some features in a "native" way.
For example, checking if a file exists in some dir:

      <REXX NAME="PrepareInstallation">
         rc = rxFuncAdd('SysLoadFuncs','REXXUTIL','SysLoadFuncs')
         rc = SysLoadFuncs()
         fullName = SysSearchPath('ETC','usb.ids')
         if ('' == fullName) then
            fullName = SysSearchPath('DPATH','usb.ids')
         if ('' == fullName) then
            fullName = SysSearchPath('PATH','usb.ids')
         if ('' == fullName) then
            call WirexxShowMessage 'Error','File "usb.ids" neither found on ETC, nor DPATH nor PATH. Installation cannot continue.',0
            call WirexxCancel

         BootDrive = SysBootDrive();
         rc = SysFileTree(BootDrive'\ecs\dll\usbcalls.dll','stem.','FSO')
         if (0 == stem.0) then
            rc = SysFileTree(BootDrive'\os2\dll\usbcalls.dll','stem.','FSO')           
         if (0 == stem.0) then
            call WirexxShowMessage 'Error','File "usbcalls.dll" neither found in \ecs\dll nor in \os2\dll. Installation cannot continue.',0
            call WirexxCancel
    return 'This will install the WPS class replacement.'
.... and later in the script ....

3) Be aware that there are subtle bugs in WarpIn when it comes to modification of CONFIG.SYS and restoration of the original CONFIG.SYS entries on package deinstallation. More often than not you do NOT get the result that you would want to see. That's because WarpIn does NOT preserve (in DATABAS.INI) the CONFIG.SYS entries before modification by the script. It only preserves the change syntax that is uses when it modifiies CONFIG.SYS. Unfortunately the change syntax is not "symmetric", that is, the original content cannot always be restored by applying the "reverse" of the modification done.

      <PCK INDEX=1
         PACKAGEID="Lars Erdmann\SYSENTER-SYSEXIT Ring-0 direct call mechanism\DriverBinary\1\0\0"
         TITLE="Driver and Sym File"
      >This is the Driver binary and is required
      <PCK INDEX=2
         PACKAGEID="Lars Erdmann\SYSENTER-SYSEXIT Ring-0 direct call mechanism\DriverTrace\1\0\0"
         TITLE="Driver Trace Formatting File"
      >This is the driver trace formatting file (needed to format trace data)
is supposed to set up the "TRACE" keyword in config.sys to exclusively set trace code 10 with the TRACE statement. That works but if you deinstall the package you will NOT get the TRACE line as it existed before this modification was done. I have tried all kinds of different other statements to achieve that but I was never successful.

Given this initial config.sys:

REM TRACE=ON 224,225,226
REM TRACE=ON 227,239

installing and deinstalling leads to this:
REM TRACE=ON 224,225,226
REM TRACE=ON 227,239

which leads to invalid syntax and is certainly not expected. Things can get worse if you install yet more packages that modify the same CONFIG.SYS statements.

I like WarpIn. The best thing about it is that you can extract the install script from the package and fix it if you need and put it back in :-)

Internet / Re: Experimental build of SeaMonkey
« on: November 27, 2017, 03:39:07 pm »
I've uploaded an experimental build of SeaMonkey 2.42.9ESR,

The link does not point at your new build. It is identical to your build of August 17, 2017.

Also, this is OS/2 where the mozapps were specifically designed to be installed wherever the user chooses. Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

These types who go on and on and on about their unyielding hostility to any semblance of a unix directory structure certainly are tiresome (in extremis), but they do have a point. Me, I'll say it only once:  ONU !!!!

It's funny that you say that. I thought it was AN's idea to come up with the splendid "sys", "etc" and "usr" directories.
As arrogant and authoritarian BWW might be: if they pull the plug on application development for OS/2 then ArcaOS is dead in 2 years flat.

Article Discussions / Re: Large Floppy Support Discussion - USBMSD.ADD
« on: November 27, 2017, 07:45:10 am »
Unfortunately your answer is as wrong as you think my answer is:

1) OS/2 only supports "large floppy" if the file system is formatted with FAT16. Yes, there should be no special dealing in USBMSD.ADD to support "large floppy" (no matter what filesystem is in use). But it's the kernel (or OS2LVM.DMD/OS2DASD.DMD) that has this limitation and this can only be worked around by fixing the kernel (DMD drivers) large scale. By the way: USBMSD.ADD does not care a bit about the filesystem. It only cares about the difference of partitioned vs. "large floppy" media. It does that by reading the very first sector of a media which contains the MBR (master boot record) or the VBR (volume boot record), the latter containing the BPB (bios parameter block). This is also a dead end because with EXFAT Microsoft decided they are going to drop the BPB for good and describe the media layout at another place on the media. Another nail in the coffin of OS/2.

2) even the "large floppy" support for FAT12/16 media is done half-heartedly. The kernel has a bug in that it wants to write a DLAT sector to this kind of media nonetheless (if LVM is in use) if you tell lvm.exe (or minilvm.exe) to do that. What happens is that this will corrupt your USB stick as the kernel will blindly write that sector as sector 63 which will usually either fall into the FAT or into the data section of a "large floppy" formatted stick. Believe me, I have been testing and experiencing exactly this problem.

From the last comment you can tell why USBMSD.ADD is so paranoid about avoiding to mess with the real contents of a "large floppy" type stick. Changing data: Ok but changing vital disk structures: No.

In short: the kernel has never been written to support a layout without an MBR (that is: "floppy") on anything else than floppy disks (that's why FAT12/16 is supported for this layout). It has nothing to do with FAT32.IFS (or any other filesystem driver) whatsoever.

As to Mr. Kohl's response:

a) USBMSD.ADD deals with removable media as much as with permanently attached USB hard disk, USB CD-ROM drives and USB floppy drives. I am not focussing on anything, neither does USBMSD.ADD.

b) In the year 2017 it only makes sense to support systems with LVM. It's too late to make USBMSD.ADD compatible to an OS of the year 1996. There would be too many limitations.

c) it is true that even IBM writes in their JFS release note that JFS should not be used with removable media. Nonetheless it is the only filesystem that is usable on large partitions, with large files. It seems to work ok (at least for me) but of course you need to take care when removing a USB device formatted with JFS. You better do a proper eject or you are asking for trouble.

General Discussion / Re: Good Bye Net Neutrality
« on: November 26, 2017, 08:07:29 pm »
Having the internet under your control is as having all newspaper and radio media under your control.
You can manipulate/fake/alter/interpret news the way you need. If you can do that on a large scale then you have influence on many people's opinion.

And that's the real threat. There are prominent examples from the past and also from the present.

Article Discussions / Re: Large Floppy Support Discussion - USBMSD.ADD
« on: November 26, 2017, 05:56:13 pm »
Actually the most important problem WAS and IS solved. I agreed with David that if you want to change a large floppy stick to a partitioned stick under OS/2 you have to use DFSee (or its engine) to write all zeros for the first sector. (Think about why it requires a user decision to do that). USBMSD.ADD will detect that and will drop "large floppy" support so that you can subsequently partition and format the stick.

You can try that. It will work:
1) use DFSee to "write zeros to start of media"
2) eject the stick
3) run a lvm /rediscoverprm to have the system redetect the stick.
4) you can now freely partition the stick etc.

Not allowing to change the "large floppy" layout is a deliberate decision. If you think about it: you would not want OS/2 to mess around with your "large floppy" stick because that is a layout that stems from Windows. There are some subtleties in blindly formatting a "large floppy" stick to a different file system. Think about what would happen if someone deciced to format a "large floppy" stick to JFS.


Programming / Re: Custom OS/2 Kernel Debugger
« on: November 25, 2017, 09:19:05 am »
Of course the OS/2 KDB NET Driver was introduced with the LAPS included with TCP/IP 4.1. It's some kind of embedded terminal server functionality. It removes the need of a physical terminal server and it's cabling. And it works quite reliable in TR or switched Ethernet segments. But requires matching debug kernels.

I don't see a need for some match of debug kernel version. The driver (KDBNET.SYS) just uses the Dev Help to register itself with the kernel. From then on the kernel will know which driver to call and what address to pass debugging data to.

Programming / Re: Custom OS/2 Kernel Debugger
« on: November 24, 2017, 07:10:43 pm »

Ploughing through my pile of paper I found the notes:

dh = RegisterKDD (0x83)
eax = Command Code (1 = valid value)
es:di control buffer address (4 DWORDS)
DWORDS in control buffer:
1. DWORD: ???
2. DWORD: lower WORD: IRQ number (what IRQ ?)
3. DWORD far pointer to code -> Handler routine (into the code segment of the invoking driver)
4. DWORD: far pointer to buffer (into the data segment of the invoking driver)

Control Buffer is then copied to symbol address _KDDC (segment "c" of DOSCALLS at offset 1233c)

USHORT FAR HandlerRoutine(USHORT arg1=ax, USHORT arg2=cx)
arg1 = function code 1,2,3
arg2 = KDB function ?

The Device Helper "RegisterKDD"  (dh_RegisterKDD) can be found at 3:1528 (3. segment of DOSCALLS module, offset 1528) in the 14.104a SMP debug kernel (the latest available apart from what AN offers)
You can use Theseus disassembly to have a look into how it operates. You can also use Theseus module view to find out at what target address the various DOSCALLS segments are loaded.
Of course, the retail kernel contains no operational code (even though it also exports symbol dh_RegisterKDD) it only returns with the carry flag set to indicate an error:

push ds
mov eax,5
pop ds

I remember there was some way to find out which driver registered with the KDB (that's how I found out that KDBNET.SYS indeed calls this Device Helper to register with the debug kernel) but I cannot remember how I found out. I guess I looked at symbol _KDDC ...

Article Discussions / Re: ArcaOS Wishlist - 6 months !!
« on: November 24, 2017, 05:04:49 pm »
Ok, I apologize.

But given the fact that I have implemented this more than 1 year ago and that AN did not pick it up (which would finally allow me and everyone else to have only one USB stack,same holds true for all changes Wim Brul and me did to USBAUDIO.SYS) you might understand my frustation a little better. Whatever I did has always been visible and accessible by AN and in the past I communicated to them whatever I did. Since they have full access they could have also taken it and fix whatever they think is wrong with it.
Unfortunately I have been ignored for the most part.

Programming / Re: Custom OS/2 Kernel Debugger
« on: November 24, 2017, 04:53:33 pm »
Does anybody know if there are kernel APIs which would allow a custom OS/2 debugger driver/PSD to be created?  And if so, are there any open source examples I could look at?

There is a more or less undocumented Device Helper (DevHlp_RegisterKDD, function code 0x83) that allows a remote debugger to send commands to the debug kernel and receive the returns and also events. For example, this Device Helper is used by KDBNET.SYS to support debugging via UDP network connection.
The "Control Programming Guide and Reference" contains a chapter "Kernel Debugger Communications Protocol" that sheds some light on the commands you can send and also the returns and events you will receive.

At one point in time I dug into this stuff to find out what registers are used in the Device Helper and what format the input and output buffers have to be. Unfortunately I lost my notes (they were incomplete anyway).

You'll need to delve into KDBNET.SYS and do some reverse engineering.

Pages: [1] 2 3 ... 11