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 ... 27 28 [29] 30 31 ... 85
421
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 27, 2021, 12:09:34 am »
As to controller,hub,device info: I assume you are quoting what the testlog from AN returns.
For debugging purposes, David added an interface to USBD.SYS to completely query all USB devices, including hubs. Since USBD.SYS of course knows about all USB devices, including USB hubs.

But USBCALLS (and USBRESMG) does not have access to that interface.

Anyway, libusb is using USBCALLS to implement its functionality, so that is the proper way to go. Because that is what usbhid obviously uses.

422
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 26, 2021, 01:24:58 pm »
I am currently working on libusb (for various reasons).
I did some updates on what port you will find what device. That'll hopefully solve it. We will see.

Note that our implementation of libusb will NEVER be able to list the whole bus hierarchy (which encompasses root hubs and chained hubs) because USBD.SYS (and therefore USBRESMG.SYS and also USBCALLS.DLL) does not publicly expose hub information.

EDIT: now I see that "libusb_get_port_numbers" tries to resolve the whole bus hierarchy, from the plugged in device upstream up to the root hub port. As I said, that cannot work. Unless we modify USBD.SYS, USBRESMG.SYS and USBCALLS.DLL.

423
Hardware / Re: New ArcaOS USB driver.
« on: November 25, 2021, 10:48:11 pm »
I'll try and knock it together. As time permits.

424
Hardware / Re: New ArcaOS USB driver.
« on: November 25, 2021, 12:59:42 pm »
I can build a test version of OS2DASD.DMD to prove that the error can at least be circumvented in the described way (it's a good question what consequences this error has on system behaviour as it should not occur in the first place).

However, there is the other problem that ArcaNoae will likely not be able to distribute a fixed version of OS2DASD.DMD due to legal reasons.

But maybe you can add this info to your ticket and AN can deduce what they need to do so that this error will never occur.

425
Hardware / Re: New ArcaOS USB driver.
« on: November 25, 2021, 01:19:14 am »
The error happens here in OS2DASD.DMD, in routine "VOID _loadds FAR NotifyDoneIORB (fpIORB)":

...
   if ( ((PRPH)pDMWork->pRequest)->Cmd == PB_REQ_LIST)
      NotifyDoneIORB_RLE(pIORB, (PPB_Read_Write) pDMWork->pRequest, pUnitCB);
   else
   {
      NotifyDoneIORB_RP (pIORB, (PBYTE) pDMWork->pRequest, pUnitCB);
   }
...

It happens because "pDMWork->pRequest" is NULL. This is an error within OS2DASD.DMD because it should itself save a request packet pointer to "pRequest" (it is not the ADD [USBMSD.ADD in this case] calling into OS2DASD.DMD, invoking this routine, that sets this pointer, but rather OS2DASD.DMD itself).

The only fix I see is to update OS2DASD.DMD to check if that pointer has a valid value:

if ((PRPH)pDMWork->pRequest)
{
   if ( ((PRPH)pDMWork->pRequest)->Cmd == PB_REQ_LIST)
      NotifyDoneIORB_RLE(pIORB, (PPB_Read_Write) pDMWork->pRequest, pUnitCB);
   else
   {
      NotifyDoneIORB_RP (pIORB, (PBYTE) pDMWork->pRequest, pUnitCB);
   }
}

One of the gazillion bugs that still linger in OS/2 code ...

Cheers,
Lars

426
Hardware / Re: New ArcaOS USB driver.
« on: November 24, 2021, 03:47:51 pm »
Yes, I saw that 12.10 is out. Ok, let's assume that is the version that Remy is talking about ...

I am just too lazy to update stuff that still does not work reliably. But maybe I'll give it a try in a VM (ArcaOS guest) and see if it solves that problems that I have in a VM.

427
Hardware / Re: New ArcaOS USB driver.
« on: November 24, 2021, 08:52:21 am »
What version is "the new USB driver"?

428
Web applications / Re: QT5 simplebrowser
« on: November 15, 2021, 07:37:26 am »
Roderick stated the beta is advancing, so let's hope for the best.

About setting a new goal: I could image that it is difficult to port this application in a stepped approach, for example with reduced functionality as an initial drop and then adding things. That is possibly more work than porting it all at once.

429
Applications / Re: Where does the program "name" come from?
« on: November 14, 2021, 10:35:28 pm »
Thank you for correcting me. The world would be a worse place without you.

430
Applications / Re: Where does the program "name" come from?
« on: November 14, 2021, 12:02:20 pm »
As Dave said, for EXEs as well as DLLs, it is the module name in the binary that determines the "module" name. And yes, you better keep it to the exact same length it had before: clip the new name if it is too long and fill up with blanks if it is too short.
If you want to understand the OS/2 LX module format, see the OS/2 toolkit HTML file:
"IBM OS/2 16/32-bit Linear eXecutable Module Format (LX)"
and I seem to remember, the module name is the first entry in the "resident name table" (which is pointed to by the "RESIDENT NAME TBL OFF" in the LX header).

<quote>
The resident and non-resident name tables define the ASCII names and ordinal numbers for exported entries in the module. In addition the first entry in the resident name table contains the module name. These tables are used to translate a procedure name string into an ordinal number by searching for a matching name string. The ordinal number is used to locate the entry point information in the entry table.
</quote>

Any resource objects (linked to the EXE/DLL) do not have any bearing on the module name.

If you want to hack the binary, do not forget to unpack it first (with lxlite), then apply your changes and finally pack it again (with lxlite).

431
Applications / Re: VIDEO_MODE_RESTRICTION
« on: November 12, 2021, 09:14:32 am »
I am just guessing but maybe you also have to set UMB to TRUE in config.sys.

432
Applications / Re: XWP v1.0.14
« on: November 11, 2021, 07:23:52 am »
If a USB MSD device is already connected during boot up, it will be treated as a non-removable disk (just like a built-in hard drive) which also precludes the possibility to eject it via the WPS (however, the "eject" utility can properly eject such medium). And for those, there never is a warning that the filesystem is not accessible.

433
Programming / Re: QBASIC POKE IN REXX is possible?
« on: November 08, 2021, 12:57:02 pm »
As to self and cross modifying code:
the proper explanation is given in the "Intel Software Developer's Manual", volume 3 in chapter "Handling Self- and Cross-Modifying Code".

Therefore, the caching issues do not apply, but the multi-core issues do.

434
Programming / Re: QBASIC POKE IN REXX is possible?
« on: November 08, 2021, 10:09:23 am »
Judging from what Roberto tried in the past, it looks like he wants to overwrite code of DLLs that are loaded into memory (for example by overwriting instructions that load the flat selector value into a register).

That by itself is already a problem because DLLs are NOT guaranteed to load at a specific memory address, at least not in general (if he wants to poke at linear addresses).

Then, there is the issue that any code already cached in the instruction cache will know nothing about the changes in code that have been done in memory (I seem to remember and I also seem to remember that this is DIFFERENT from data access as that will lead to cache update of the data cache on modifying memory). That is why it has become so difficult if not impossible to write self-modifying code: you would need to invalidate the cache lines in the instruction cache that hold that modified code and therefore force a reload of the instruction cache when again accessing that code (and potentially enforce cache coherency amongst multiple cores if that does not happen automatically !). This is nothing for the faint hearted.

435
Programming / Re: QBASIC POKE IN REXX is possible?
« on: November 07, 2021, 07:39:04 pm »
There can never be a POKE that can touch any arbitrary memory address. That would completely ruin the OS memory protection.
And then, it is unclear from the question, if we are talking about physical addresses or linear addresses.
If you really want to ruin your system, you would need to write a device driver which can be called via IOCTL and then call that from a REXX DLL.
Of course I would never,ever install such a driver or DLL.

Pages: 1 ... 27 28 [29] 30 31 ... 85