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 ... 27
Applications / Re: About bldlevel
« on: September 14, 2019, 09:16:00 am »
Be careful with various versions, because original bldlevel has a limit on searching string in a file.

Not sure about the exact limit, but looks like only first 500 or 512kb of file is scanned. Signature placed after this position is just "invisible".
...which would explain why IBM linkers place this string into the resident name table ...

Applications / Re: About bldlevel
« on: September 06, 2019, 09:16:19 am »
Hi Martin

If you have a copy of USbcfg installed then you should also have a copy of GETDESC.DLL which USBcfg uses to extract buildlevel information. However, this DLL is built to work with Pascal coding so would probably need a bit of reworking to work with "c" code.

The DLL was put together by Lars, of USB drivers fame, so you could ask him if he could build a "c" version.

Later Edit: The zip file Lars sent me contains source (cpp, def files) and makefile so you could probably modify it yourself. Let me know if you want a copy.



Err,  I have to admit that in the end, GETDESC.DLL also uses a direct call to "bldlevel.exe" to extract the description info. The DLL just pipes the output into a memory buffer, extracts the description string and passes it back into the string buffer provided by the caller.

The reason for this: Initially (on my first attempt) I determined that the description would end up (for the compiler and linker toolset that I used) in the resident name table of the DLL (that's a place in the DLL file that serves a special purpose).  I was done and everything was fine. Unfortunately, another compiler and linker toolset would NOT place the description info into the resident name table but "somewhere else" into the file.
In short: there was no common way to determine this info and therefore I used bldlevel.exe which just scans the complete file for the description string template.

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.


Pages: [1] 2 3 ... 27