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 ... 73 74 [75] 76 77 ... 86
1111
Storage / Re: oddities with OS2AHCI version 2.04
« on: December 16, 2017, 10:40:45 pm »
"memory check": I am using also Windows 10 64-bit on this very same HW. I have no apparent issues with it. At least not unexplicable crashes.

"setting NX" bit: I have no such option in my BIOS. I am not sure if my instability is limited to use of high memory. I had set VIRTUALADDRESSLIMIT to 512 MB and I still have these strange reboots etc.
I have the strong feeling that the amount of system memory matters. Unfortunately it is not all that easy to reduce it. And I bought it to be usable with a 64-bit OS like Windows 10 ...

Maybe there is an issue with AMD based systems ? You all seem to have Intel based systems.

What I also realised:
1) when I dump OS2AHCI$ to the console I have a lot of these entries:
port #0 interrupt error status: 0x40000001; restarting port

2) when I run "smartahci.exe -i hd1" and then dump OS2AHCI$ I get:
timeout for IORB da811ea (etc.)

I am beginning to believe that I cannot use OS2AHCI.ADD on this AMD based system.

1112
Storage / Re: oddities with OS2AHCI version 2.04
« on: December 16, 2017, 08:10:38 pm »
1) I have 16 GB of system memory. How much do you have ?
2) I have an AMD 8-core system ("8350 Eight-Core Processor", I think that is Bulldozer architecture). What do you have ?

I have tried to limit memory via VIRTUALADDRESSLIMIT. That works as described and I can also use memory in excess of the 4 GB boundary as memory for the QSINIT ram disk.

But I have the suspicion that there is a bug in the kernel if more than 4 GB physical memory is installed in that the memory management will go bad. I have many odd effects, from sudden reboots to some Theseus working set script (getws.exe) leading to a kernel trap as soon as I execute it.

I have no special SW installed whatsoever.



1113
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 ?

1114
Hardware / Re: Hardware Reports / Reviews - More - MORE !!!!
« on: December 12, 2017, 04:58:27 pm »
Lars

Is this a MIDI in hardware device? It is supposed to be class compliant.

https://www.sweetwater.com/store/detail/mio

Yes, that is a MIDI device. However, I was thinking about a USB device with a built-in synthesizer/wavetable that generates audible output from the input MIDI stream. Much like what normal sound cards did/do.
In short: something you can throw a MIDI file at and then you can listen to some sort of sound output.
I don't know if that exists. Maybe MIDI is dead.

1115
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.

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

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.

1117
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).

1118
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 ...



1119
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.

1120
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 "trac.netlabs.org/efte" 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.

Lars



1121
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! ;-)

Disqus?

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
         do
            fullName = SysSearchPath('DPATH','usb.ids')
         end
         if ('' == fullName) then
         do
            fullName = SysSearchPath('PATH','usb.ids')
         end
         if ('' == fullName) then
         do
            call WirexxShowMessage 'Error','File "usb.ids" neither found on ETC, nor DPATH nor PATH. Installation cannot continue.',0
            call WirexxCancel
         end

         BootDrive = SysBootDrive();
         rc = SysFileTree(BootDrive'\ecs\dll\usbcalls.dll','stem.','FSO')
         if (0 == stem.0) then
         do
            rc = SysFileTree(BootDrive'\os2\dll\usbcalls.dll','stem.','FSO')           
         end
         if (0 == stem.0) then
         do
            call WirexxShowMessage 'Error','File "usbcalls.dll" neither found in \ecs\dll nor in \os2\dll. Installation cannot continue.',0
            call WirexxCancel
         end
    return 'This will install the WPS class replacement.'
      </REXX>
.... and later in the script ....
   <BODY>
      <PAGE INDEX=1 TYPE="README">
         <TEXT>=("PrepareInstallation")</TEXT>
      ...
     </PAGE>
   </BODY>






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.
Example:

      <PCK INDEX=1
         PACKAGEID="Lars Erdmann\SYSENTER-SYSEXIT Ring-0 direct call mechanism\DriverBinary\1\0\0"
         TITLE="Driver and Sym File"
         TARGET="?:\OS2\BOOT" NODESELECT FIXED
         CONFIGSYS="BASEDEV=SYSCALL.SYS | REMOVELINE"
         CONFIGSYS="BASEDEV=SYSCALL.SYS | ADDAFTER(CHKDSK.SYS)"
      >This is the Driver binary and is required
      </PCK>
      <PCK INDEX=2
         PACKAGEID="Lars Erdmann\SYSENTER-SYSEXIT Ring-0 direct call mechanism\DriverTrace\1\0\0"
         TITLE="Driver Trace Formatting File"
         REQUIRES=1
         TARGET="?:\OS2\SYSTEM\TRACE" FIXED
         CONFIGSYS="TRACEBUF=2048 /M=W,Q,NODTI /D=ALL | UNIQUE"
         CONFIGSYS="TRACE=ON | REMOVEPART"
         CONFIGSYS="TRACE=ON 10 | ADDAFTER(TRACEBUF) | UNIQUE"
      >This is the driver trace formatting file (needed to format trace data)
      </PCK>
 
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
REM TRACE=ON 227,239
REM TRACE=ON 238
REM TRACE=ON 239
REM TRACE=ON 254
TRACE=ON 255
TRACEBUF=1024 /M=W,NQ,NODTI /D=ALL

installing and deinstalling leads to this:
REM TRACE=ON 224,225,226
REM TRACE=ON 227
REM TRACE=ON 227,239
REM TRACE=ON 238
REM TRACE=ON 239
REM TRACE=ON 254
TRACE= 255;ON
TRACEBUF=1024 /M=W,NQ,NODTI /D=ALL

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 :-)



1122
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, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9R2esr.en-US.os2_exp1.zip

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.

1123
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.

1124
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.

1125
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.


Lars

Pages: 1 ... 73 74 [75] 76 77 ... 86