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 4 ... 28
Applications / Re: XWP v1.0.13 Beta 1
« on: September 04, 2019, 08:08:23 am »
After installing 1.0.13 beta, Warpin still shows 1.0.12. Is that intentional ?

Background: back in the past something screwed up my Warpin Database and that happened AFTER I installed XWorplace 1.0.12 but BEFORE I installed 1.0.13. It is possible that on installation of 1.0.13 there was no entry in the Warpin database for 1.0.12.

Nonetheless the side effect for the AMouse plugin installation remains: you will have to RERUN the AMouse plugin installation (deinstall and then reinstall) after installing XWP (to a different directory). Or fiddle around with files.

Applications / Re: XWP v1.0.13 Beta 1
« on: September 03, 2019, 07:51:53 pm »
No, I did not. I would have expected this beta to install over the old version.

Applications / Re: XWP v1.0.13 Beta 1
« on: September 03, 2019, 07:30:27 am »
The reason for the trouble with Widgets not being found is this:
for some reason XWP 1.0.13 Beta1 does not install into the same directory as 1.0.12 did. And therefore you need to copy over the widgets from the "plugins\xcenter" directory of 1.0.12 to the 1.0.13 directory tree (in the "plugins\xcenter" directory).

1.0.12 did install to \tools\WPS\XWorkplace
1.0.13 beta did install to \tools\xwp

The AMouse plugin is also affected as the AMouse installation queries the install location of XWorkplace. Not surprising, it will use the location of XWorkplace that is valid at the point in time of AMouse installation.

Storage / Re: How to Format a Hard Drive
« on: September 02, 2019, 12:17:45 pm »
Forgot: judging from the error "Internal error: devices.c(532): Verify error 87 (INVALID PARAMETER)" I would also suspect that the /L parameter for JFS means to overwrite each sector (with zeros !?) and then to do an additional verify of each sector (what does that do ? Likely a readback to check if the sector was properly written, I forgot ...). Which would explain why the /L parameter will increase the formatting time substantially.

Storage / Re: How to Format a Hard Drive
« on: September 02, 2019, 12:01:03 pm »
Coming back to "ujfs_rw_diskblocks" returning with ERROR_INVALID_PARAMETER:
I had a look at the OpenJFS code and yes, "ujfs_rw_diskblocks" seems to work in units of "tracks". That would imply that a partition needs to be cylinder aligned at the partition start and partition end. If it is not, "ujfs_rw_diskblocks" will fail with ERROR_INVALID_PARAMETER because either the number of sectors to read/write/verify will not match the "sectors per track" or will potentially point past the partition or ahead of the partition start. All these cases will lead to ERROR_INVALID_PARAMETER in "ujfs_rw_diskblocks".

Storage / Re: How to Format a Hard Drive
« on: September 02, 2019, 11:36:41 am »
1) The parameters supported by "" should be taken as "suggestive". They are more of a mutual agreement. They are passed verbatim to the corresponding FORMAT routine in the relevant DLL (UJFS.DLL, UHPFS.DLL etc.). But obviously, these parameters are distinct "per filesystem" and not "per drive type". Therefore, saying that /L was meant for "long format of optical drives" is not really accurate but rather a proposal of what it should do.

2) /F:3 for chkdsk means that even the free space is checked for errors / remainings of deleted files. If my assumption is right, this would mean that /L for JFS format means it will not only wipe the beginning of the partition (to wipe out whatever would interfere with JFS structures to manage directories and files) but would wipe the complete partition (for example, overwrite every single sector of the partition with zeros) before writing the necessary basic filesystem structures.
If "ujfs_rw_diskblocks" returns with ERROR_INVALID_PARAMETER, then my guess would be that the format routine is trying to access sectors that it should not. I would image that this could potentially happen if partitions are not cylinder aligned (which in the year 2019 is ridiculous but enforced by OS/2 up to this day) and the formatting routine tries to access sectors past the partition end.

Storage / Re: How to Format a Hard Drive
« on: August 31, 2019, 11:16:27 pm »
I seem to remember that it prevents chkdsk c: /F:3 from finding anything. If you want to have the exact technical detail you will need to look at the OpenJFS implemenation at Netlabs and analyze the source code ...

"format" for JFS is implemented in UJFS.DLL. At least the filesystem specific implementation. FORMAT.COM just queries which DLL to load for a given drive letter (UHPFS.DLL, UJFS.DLL, UFAT32.DLL etc.) and then invokes the "format" entry point.

Events / USB maintainer wanted!
« on: August 09, 2019, 08:40:10 am »
In October I will be working in a foreign country for 2 years.
That will also be the moment in time where I will move away from OS/2.
If there is interest to take over the USB repository and if you have the necessary skills to maintain/further develop the drivers then please let me know and I can help you to quickly pick up.

Applications / Re: XWP v1.0.13 Beta 1
« on: August 06, 2019, 07:33:31 am »
It also works here.
I do like the automatic setup of the reboot menu but would it be possible to remove/avoid the entries for USB sticks/HDDs (that had been plugged in on system start) and only keep those for fixed disks ?

Applications / Re: XWP v1.0.13 Beta 1
« on: August 06, 2019, 07:21:44 am »
Hi Rich, it is working fine here for the moment.

Thanks for the full version, I got used to the "Pack this tree" and I use the "WPS Class List" also.

It is not a bug. About "WPS Class List", where can I suggest some text for some undocumented classes?
Like "CWBubblepad": "This is a replacement class for LaunchPad included in the Bubblepad package. Reduces the size of the original launchpad. The drawers may be hidden and every action button may be independently removed. "


\tools\wps\xworkplace\help\xfclsXXX.txt where "XXX" is your language code.

General Discussion / Re: Email address of Dave McKenna ?
« on: August 05, 2019, 07:18:27 am »
I now have it, never mind.

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


Hardware / Re: ArcaOS Hardware Support Discussion
« on: August 04, 2019, 12:21:18 pm »
Unfortunately, I know too little about UEFI. The only things I know:

1) I have a machine with UEFI and CSM (compatibility support module = legacy BIOS support). It does have legacy USB support and even though the support is a bit buggy it works well enough for the USB keyboard to be usable without native USB drivers taking over support (I can boot to an OS/2 commandline without ANY USB drivers loaded and still use the keyboard)

2) I know of at least one other person that does have a machine with a legacy BIOS (or UEFI and CSM, I cannot remember) that however does NOT have legacy USB support. On this system, you will NOT have any USB support unless a native USB driver takes over support. My belief is that if this machine is a UEFI+CSM machine that then, ONLY UEFI USB drivers are provided along with the BIOS so that you can enter the BIOS (to change settings) or boot to a UEFI console and use the USB mouse/USB keyboard.

However "UEFI USB drivers" work completely differently: they are completely implemented in the BIOS FW and they DIRECTLY support USB mouse and keyboard (in the same way that the OS/2 SW drivers support that USB HW). In contrast, "legacy USB" support uses USB host controller HW support and also SMI to "fake" to the BIOS that an USB mouse/keyboard is a PS/2 keyboard/mouse. In short: this works completely differently. And the USB HC HW support for "legacy" operation is optional (USB HC HW does not have to provide this support).

That said, I DO believe that "legacy USB" support as we now it today will die sooner or later.


Hardware / Re: ArcaOS Hardware Support Discussion
« on: August 04, 2019, 12:11:50 am »
Some info:

1) I think there is no chance that booting from a USB device attached to a plug-in USB card will actually work. I seem to remember that there are some HW limitations that will prevent this from working (some necessary HW signal line not wired via the PCI slot).

2) yes, VIA UHCI host controllers are supported. As far as I understand from ivan, the USB keyboard and trackball work if they are attached to the 2 "USB 2.0 only" USB ports for "normal" operation, that means, way past the boot stage. If the mouse and keyboard support does not work in the booting stage (that is, while you are presented with a fullscreen text mode with the driver signon messages showing etc.) then that either means that the system does not have USB legacy support in the "conventional" BIOS/UEFI CSM layer (that is, disregarding USB support via the UEFI BIOS which does not help OS/2 as OS/2 does not boot up via UEFI) or that the USB support breaks when switching from USB legacy support to native USB support.
What you could try out: back up \os2\boot\config.x and then remove all USB support from this file.
Then, restart the system, hit Alt-F1 and then F2 which will get you to a full screen commandline. Test the USB keyboard, it should work. If not, you are hosed and your system does not support legacy USB (via the "conventional" BIOS / UEFI CSM layer).
Don't forget to reinstate the original \os2\boot\config.x file after the test !


Hardware / Re: ArcaOS Hardware Support Discussion
« on: August 03, 2019, 03:09:03 pm »
I had to borrow a keyboard with a PS/2 plug to get everything up and working again

This is one of the main problems with using USB keyboards. They don't work after the BIOS loses control (sometime early in the boot sequence), and before the driver initializes (right at the end of the boot sequence). At that time, USB keyboards cannot be used to do simple things like hit <enter>. This is not new with new USB drivers, it has always been the case.

No this is not true. The idea is to prevent the HC drivers from resetting the host controllers until finally the system is up and running in order to not prematurely break legacy USB support. It is the job of USBD.SYS to call into the HC drivers to trigger the host controller reset and once this is done to start the enumeration process (as then the HUB HW is able to properly do its work and react to port checking requests etc.). So, the idea is to delay this process until finally the system has booted far enough to no longer need USB legacy support.

I have modified my USB drivers to do just that: USBD.SYS queues the HC driver registration requests with a timer. It additionally checks if the system has already notified (via USBMSD.ADD calling into USBD.SYS) that INT13 boot support for USB MSD is no longer needed. If the timer expires (no more HC drivers asked for registration + the system has signaled it no longer needs INT13 boot support), then USBD.SYS will go ahead and reset the HC controllers.
I can easily boot to a commandline via Alt-F1 and F2 and then use my USB keyboard. There is a short moment where the keyboard will not work from the point in time where the HC drivers have been reset (and legacy USB support ceased) until native USB support has been enabled but you can continue to type and it will eventually continue to work, in practice I have no problem using a USB keyboard from a booted up commandline.
If I additionally run "lvm /rediscoverprm" from that commandline, I can also use attached USB MSD devices.

But of course, the BIOS has to provide legacy USB support. I wonder how long that will still be the case.

The upcoming 10.229 version of my drivers will have the rest of changes I have missed in the past to support the behaviour mentioned above.

Pages: 1 [2] 3 4 ... 28